[opensuse] BASH Script Relay Switch
![](https://seccdn.libravatar.org/avatar/e6bc4b5458f9686f6bb7cf02bdd6e1da.jpg?s=120&d=mm&r=g)
Hi everyone. I bought one of these relay switches from ebay so that I can turn on and off the tape drive in the server room: https://www.ebay.co.uk/itm/Intelligent-USB-Control-Switch-With-MCU-Microcont... If you scroll to the item description it gives you the data to send to the switch to control it. I wrote the below little bash script. To change what the relay does I simply change the 4 data values. #!/bin/bash function byte() { printf "\\x$(printf "%x" $1)" } { byte 0xF0 byte 0xA0 byte 0xNC byte 0x54 } > "/dev/ttyUSB0" However some of the values are 0xNC as you can see by my above example. Now when I run the script it works but I get the following output: paul@paul-pc:~$ bash relay2.sh relay2.sh: line 4: printf: 0xNC: invalid hex number Of course the data is obviously hexadecimal and NC is not a hex number. But seeing as there is an error this must not in my opinion be the correct method. Can anyone shed some light on a better way of doing this? Thanks Paul -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
On 06/12/2018 20.21, Paul Groves wrote:
Hi everyone.
I bought one of these relay switches from ebay so that I can turn on and off the tape drive in the server room:
https://www.ebay.co.uk/itm/Intelligent-USB-Control-Switch-With-MCU-Microcont...
If you scroll to the item description it gives you the data to send to the switch to control it. I wrote the below little bash script. To change what the relay does I simply change the 4 data values.
#!/bin/bash
function byte() { printf "\\x$(printf "%x" $1)" }
{ byte 0xF0 byte 0xA0 byte 0xNC byte 0x54 } > "/dev/ttyUSB0"
However some of the values are 0xNC as you can see by my above example. Now when I run the script it works but I get the following output:
paul@paul-pc:~$ bash relay2.sh relay2.sh: line 4: printf: 0xNC: invalid hex number
Of course the data is obviously hexadecimal and NC is not a hex number. But seeing as there is an error this must not in my opinion be the correct method.
The method is correct AFAICS; the data is not. -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.0 x86_64 (Minas Tirith))
![](https://seccdn.libravatar.org/avatar/150bb68600b6f4527c14c79e81e90f53.jpg?s=120&d=mm&r=g)
On Thu, 6 Dec 2018 20:59:47 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 06/12/2018 20.21, Paul Groves wrote:
Hi everyone.
I bought one of these relay switches from ebay so that I can turn on and off the tape drive in the server room:
https://www.ebay.co.uk/itm/Intelligent-USB-Control-Switch-With-MCU-Microcont...
If you scroll to the item description it gives you the data to send to the switch to control it. I wrote the below little bash script. To change what the relay does I simply change the 4 data values.
#!/bin/bash
function byte() { printf "\\x$(printf "%x" $1)" }
{ byte 0xF0 byte 0xA0 byte 0xNC byte 0x54 } > "/dev/ttyUSB0"
However some of the values are 0xNC as you can see by my above example. Now when I run the script it works but I get the following output:
paul@paul-pc:~$ bash relay2.sh relay2.sh: line 4: printf: 0xNC: invalid hex number
Of course the data is obviously hexadecimal and NC is not a hex number. But seeing as there is an error this must not in my opinion be the correct method.
The method is correct AFAICS; the data is not.
In connection with switch contacts NC means 'Normally Closed', and for the other sort of contact NO means normally open. So I'd guess you're supposed to substitute some value there to indicate whether you want the switch to open or close. But you'll need some more documentation to tell you the correct values, or a lucky guess :) Maybe 0x00 and 0x01 ? or 0x00 and 0xFF ? Who knows! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/e6bc4b5458f9686f6bb7cf02bdd6e1da.jpg?s=120&d=mm&r=g)
On 06/12/2018 20:28, Dave Howorth wrote:
In connection with switch contacts NC means 'Normally Closed', and for the other sort of contact NO means normally open.
So I'd guess you're supposed to substitute some value there to indicate whether you want the switch to open or close. But you'll need some more documentation to tell you the correct values, or a lucky guess:)
Maybe 0x00 and 0x01 ? or 0x00 and 0xFF ? Who knows!
I don't think it is related to normally closed or normally open as those commands have values already and as I said before all the commands work fine but I am just presented with the error for commands containing NC, even though they all work. I have emailed the seller to ask what they mean by NC I think perhaps they are using it as a place holder for a null value. Is there a way to do this better that I can test? Paul -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/c8b49a7a57ae09cd5482d4a4ac5bb593.jpg?s=120&d=mm&r=g)
On 2018-12-06 22:27, Paul Groves wrote:
On 06/12/2018 20:28, Dave Howorth wrote:
In connection with switch contacts NC means 'Normally Closed', and for the other sort of contact NO means normally open.
So I'd guess you're supposed to substitute some value there to indicate whether you want the switch to open or close. But you'll need some more documentation to tell you the correct values, or a lucky guess:)
Maybe 0x00 and 0x01 ? or 0x00 and 0xFF ? Who knows!
I don't think it is related to normally closed or normally open as those commands have values already and as I said before all the commands work fine but I am just presented with the error for commands containing NC, even though they all work.
Probably because you're already sending 0x00 in the third byte. If you run your script (without > USB) and pipe the output to hexdump -C you'll see the result. $ source yourscript | hexdump -C ./yourscript: line 4: printf: 0xNC: invalid hex number 00000000 f0 a0 00 54 |...T| 00000004 -- /bengan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/e6bc4b5458f9686f6bb7cf02bdd6e1da.jpg?s=120&d=mm&r=g)
On 06/12/2018 23:46, Bengt Gördén wrote:
On 2018-12-06 22:27, Paul Groves wrote:
On 06/12/2018 20:28, Dave Howorth wrote:
In connection with switch contacts NC means 'Normally Closed', and for the other sort of contact NO means normally open.
So I'd guess you're supposed to substitute some value there to indicate whether you want the switch to open or close. But you'll need some more documentation to tell you the correct values, or a lucky guess:)
Maybe 0x00 and 0x01 ? or 0x00 and 0xFF ? Who knows!
I don't think it is related to normally closed or normally open as those commands have values already and as I said before all the commands work fine but I am just presented with the error for commands containing NC, even though they all work.
Probably because you're already sending 0x00 in the third byte.
If you run your script (without > USB) and pipe the output to hexdump -C you'll see the result.
$ source yourscript | hexdump -C ./yourscript: line 4: printf: 0xNC: invalid hex number 00000000 f0 a0 00 54 |...T| 00000004
I checked and as you explained it has converted NC to 00 I will try sending 00 instead of NC and see if it still works. I have not had to deal with hex files before. Can you please explain to me what the 00000000: on the beginning of the data and the ...T on the end mean? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
On 07/12/2018 17.55, Paul Groves wrote:
On 06/12/2018 23:46, Bengt Gördén wrote:
On 2018-12-06 22:27, Paul Groves wrote:
On 06/12/2018 20:28, Dave Howorth wrote:
In connection with switch contacts NC means 'Normally Closed', and for the other sort of contact NO means normally open.
So I'd guess you're supposed to substitute some value there to indicate whether you want the switch to open or close. But you'll need some more documentation to tell you the correct values, or a lucky guess:)
Maybe 0x00 and 0x01 ? or 0x00 and 0xFF ? Who knows!
I don't think it is related to normally closed or normally open as those commands have values already and as I said before all the commands work fine but I am just presented with the error for commands containing NC, even though they all work.
Probably because you're already sending 0x00 in the third byte.
If you run your script (without > USB) and pipe the output to hexdump -C you'll see the result.
$ source yourscript | hexdump -C ./yourscript: line 4: printf: 0xNC: invalid hex number 00000000 f0 a0 00 54 |...T| 00000004
I checked and as you explained it has converted NC to 00
I will try sending 00 instead of NC and see if it still works.
I have not had to deal with hex files before. Can you please explain to me what the 00000000: on the beginning of the data and the ...T on the end mean?
The first column is the index, or the counter. The second column are the values sent. The third column is the equivalent in text of the values. See "man ascii", then search for 54. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
![](https://seccdn.libravatar.org/avatar/7891b1b1a5767f4b9ac1cc0723cebdac.jpg?s=120&d=mm&r=g)
Paul Groves wrote:
I have not had to deal with hex files before. Can you please explain to me what the 00000000: on the beginning of the data and the ...T on the end mean?
It's the hexdump output format - 00000000: = offset from beginning of file ...T = ascii translation of the hex bytes. 0x54 = T. -- Per Jessen, Zürich (12.2°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/4de30ea19d081e0cb137efdb4fd0ec19.jpg?s=120&d=mm&r=g)
On 12/6/18 11:21 AM, Paul Groves wrote:
Hi everyone.
I bought one of these relay switches from ebay so that I can turn on and off the tape drive in the server room:
https://www.ebay.co.uk/itm/Intelligent-USB-Control-Switch-With-MCU-Microcont...
If you scroll to the item description it gives you the data to send to the switch to control it. I wrote the below little bash script. To change what the relay does I simply change the 4 data values.
#!/bin/bash
function byte() { printf "\\x$(printf "%x" $1)" }
{ byte 0xF0 byte 0xA0 byte 0xNC byte 0x54 } > "/dev/ttyUSB0"
However some of the values are 0xNC as you can see by my above example. Now when I run the script it works but I get the following output:
paul@paul-pc:~$ bash relay2.sh relay2.sh: line 4: printf: 0xNC: invalid hex number
Of course the data is obviously hexadecimal and NC is not a hex number. But seeing as there is an error this must not in my opinion be the correct method.
Can anyone shed some light on a better way of doing this?
Thanks Paul
Have you considered a minicom or expect script? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/7cd8f94c4852691e6be83aff3a1a5322.jpg?s=120&d=mm&r=g)
On 12/6/18 8:21 PM, Paul Groves wrote:
Hi everyone.
I bought one of these relay switches from ebay so that I can turn on and off the tape drive in the server room:
https://www.ebay.co.uk/itm/Intelligent-USB-Control-Switch-With-MCU-Microcont...
If you scroll to the item description it gives you the data to send to the switch to control it. I wrote the below little bash script. To change what the relay does I simply change the 4 data values.
#!/bin/bash
function byte() { printf "\\x$(printf "%x" $1)" }
{ byte 0xF0 byte 0xA0 byte 0xNC byte 0x54 } > "/dev/ttyUSB0"
However some of the values are 0xNC as you can see by my above example. Now when I run the script it works but I get the following output:
paul@paul-pc:~$ bash relay2.sh relay2.sh: line 4: printf: 0xNC: invalid hex number
Of course the data is obviously hexadecimal and NC is not a hex number. But seeing as there is an error this must not in my opinion be the correct method.
Can anyone shed some light on a better way of doing this?
Thanks Paul
Hi, I don't know what data exactly you have to send to your device. But, from the above listed sequence it's clear that you try to send one invalid hex value (0xNC is not a hex number). I am guessing that you might want to send NC as two characters in sequence. If so, than you have co represent them in hex: N ---> 0x4E C ---> 0x43 So, instead of 0xNC you might want to send two bytes: byte 0x4E byte 0x43 Regards, Radule N�����r��y隊Z)z{.�ﮞ˛���m�)z{.��+�:�{Zr�az�'z��j)h���Ǿ� ޮ�^�ˬz��
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
On 07/12/2018 08.54, Radule Šoškić wrote:
On 12/6/18 8:21 PM, Paul Groves wrote:
Hi everyone.
...
Hi,
I don't know what data exactly you have to send to your device. But, from the above listed sequence it's clear that you try to send one invalid hex value (0xNC is not a hex number).
I am guessing that you might want to send NC as two characters in sequence. If so, than you have co represent them in hex:
N ---> 0x4E C ---> 0x43
So, instead of 0xNC you might want to send two bytes:
byte 0x4E byte 0x43
The link he sent has very limited information. It appears to have an USB to RS232 converter, then the rest. The relevant paragraph says: The next step is to send instructions, the command format is as follows. Control command: (hexadecimal transmission, four bytes) 1. F0 A0 00 53 Disconnect command. In JOG control mode, this function is disabled. 2. F0 A0 01 53 Closed command, in different control mode, the effect is different 3. F0 A0 NC 54 Select the control mode as normal control mode 4. F0 A0 NC 55 Select the control mode for jog control 5. F0 A0 NC 56 Select the control mode for delay control 6. F0 TH TL 57 In normal control mode, set the timer time, delay time is between 1 and 65536 seconds. After the delay time arrives, the current state of the relay is inverted. The timing time is TH * 256 + TL. Timing is a one-time, set up only once. When I pose the mouse over the lines get a popup with text in what appears to be Chinese. So maybe what we get is a translation. There should be a link to the actual documentation of the module. As it is, it is incomplete and wrong. Maybe "normal control mode" (NC) has to be replaced with a number from a table of values somewhere. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
![](https://seccdn.libravatar.org/avatar/e6bc4b5458f9686f6bb7cf02bdd6e1da.jpg?s=120&d=mm&r=g)
On 07/12/2018 12:18, Carlos E. R. wrote:
The link he sent has very limited information. It appears to have an USB to RS232 converter, then the rest.
it is a CH341 USB to RS232 converter, then a serial PIC chip which controls the relay switch.
The relevant paragraph says:
The next step is to send instructions, the command format is as follows. Control command: (hexadecimal transmission, four bytes) 1. F0 A0 00 53 Disconnect command. In JOG control mode, this function is disabled. 2. F0 A0 01 53 Closed command, in different control mode, the effect is different 3. F0 A0 NC 54 Select the control mode as normal control mode 4. F0 A0 NC 55 Select the control mode for jog control 5. F0 A0 NC 56 Select the control mode for delay control 6. F0 TH TL 57 In normal control mode, set the timer time, delay time is between 1 and 65536 seconds. After the delay time arrives, the current state of the relay is inverted. The timing time is TH * 256 + TL. Timing is a one-time, set up only once.
These codes all work fine when I send them with my script. I am just confused why they have NC there instead of a hex value.
When I pose the mouse over the lines get a popup with text in what appears to be Chinese. So maybe what we get is a translation.
I checked the translations. They all say the same in English as the line which is hovered over.
There should be a link to the actual documentation of the module. As it is, it is incomplete and wrong. Maybe "normal control mode" (NC) has to be replaced with a number from a table of values somewhere.
Possibly. I have asked the seller but he does not speak great English. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
On 07/12/2018 17.51, Paul Groves wrote:
On 07/12/2018 12:18, Carlos E. R. wrote:
The link he sent has very limited information. It appears to have an USB to RS232 converter, then the rest.
it is a CH341 USB to RS232 converter, then a serial PIC chip which controls the relay switch.
Ok.
The relevant paragraph says:
The next step is to send instructions, the command format is as follows. Control command: (hexadecimal transmission, four bytes) 1. F0 A0 00 53 Disconnect command. In JOG control mode, this function is disabled. 2. F0 A0 01 53 Closed command, in different control mode, the effect is different 3. F0 A0 NC 54 Select the control mode as normal control mode 4. F0 A0 NC 55 Select the control mode for jog control 5. F0 A0 NC 56 Select the control mode for delay control 6. F0 TH TL 57 In normal control mode, set the timer time, delay time is between 1 and 65536 seconds. After the delay time arrives, the current state of the relay is inverted. The timing time is TH * 256 + TL. Timing is a one-time, set up only once.
These codes all work fine when I send them with my script. I am just confused why they have NC there instead of a hex value.
No, they don't work "fine". Look, I created a test program based on yours: #/bin/bash function byte() { printf "\\x$(printf "%x" $1)" } { byte 0xF0 byte 0xA0 byte 0xNC byte 0x54 } > text.bin I then run it: cer@Telcontar:~> cd bin/test cer@Telcontar:~/bin/test> bash echohexttext echohexttext: line 4: printf: 0xNC: invalid hex number cer@Telcontar:~/bin/test> It creates file "text.bin". I now look at it: cer@Telcontar:~/bin/test> hexdump -C text.bin 00000000 f0 a0 00 54 |...T| 00000004 cer@Telcontar:~/bin/test> cer@Telcontar:~/bin/test> l text.bin -rw-r--r-- 1 cer users 4 Dec 7 18:39 text.bin cer@Telcontar:~/bin/test> It contains four (hex) bytes: "f0 a0 00 54". The "NC" has been replaced with a zero. What you appear to be doing is setting control mode zero.
When I pose the mouse over the lines get a popup with text in what appears to be Chinese. So maybe what we get is a translation.
I checked the translations. They all say the same in English as the line which is hovered over.
Ok.
There should be a link to the actual documentation of the module. As it is, it is incomplete and wrong. Maybe "normal control mode" (NC) has to be replaced with a number from a table of values somewhere.
Possibly. I have asked the seller but he does not speak great English.
Well, that explains why the documentation is incorrect/incomplete... -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
![](https://seccdn.libravatar.org/avatar/e6bc4b5458f9686f6bb7cf02bdd6e1da.jpg?s=120&d=mm&r=g)
On 07/12/2018 07:54, Radule Šoškić wrote:
Hi,
I don't know what data exactly you have to send to your device. But, from the above listed sequence it's clear that you try to send one invalid hex value (0xNC is not a hex number).
I am guessing that you might want to send NC as two characters in sequence. If so, than you have co represent them in hex:
N ---> 0x4E C ---> 0x43
So, instead of 0xNC you might want to send two bytes:
byte 0x4E byte 0x43
Regards,
Radule
No the device only accepts 4 hex values so this would not work. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (7)
-
Bengt Gördén
-
Bruce Ferrell
-
Carlos E. R.
-
Dave Howorth
-
Paul Groves
-
Per Jessen
-
Radule Šoškić