Relay detection
I'm having an issue getting crelay to properly detect my relays; I've got a pair of sainsmart 16ch relays. I'm running crelay on a raspi with either of the relays attached, but the code runs through autodetect without finding them. Any recommendations or suggestions?
Much appreciated!
Did you run crelay with root permissions (sudo ...)?
Il dom 1 lug 2018, 04:18 kjatar [email protected] ha scritto:
I'm having an issue getting crelay to properly detect my relays; I've got a pair of sainsmart 16ch relays. I'm running crelay on a raspi with either of the relays attached, but the code runs through autodetect without finding them. Any recommendations or suggestions?
Much appreciated!
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ondrej1024/crelay/issues/21, or mute the thread https://github.com/notifications/unsubscribe-auth/AFPVGYJHr5Lp0PKrEcYmFRwLQYjKGLMXks5uCDF7gaJpZM4U-K3w .
Good morning,
That was my first thought, but yes, I did.
pi@raspberrypi:~/crelay/src $ sudo crelay -i No compatible device detected.
I know the system can see the device, too, because I can communicate with it via pyserial enough to make the serial comms lights flash, even if I can't get any relays to activate.
Did you build crelay with support for the sainsmart driver ? Try to run just the crelay command and check the list of supported relays.
Also check with the lsusb console command if the card is detected by the OS.
Hey there,
Both things appear to be as they should be.
pi@raspberrypi:~ $ lsusb Bus 001 Device 008: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
This is the USB->serial adapter that the Sainsmart uses, I believe.
pi@raspberrypi:~ $ sudo crelay crelay, version 0.12.1
This utility provides a unified way of controlling different types of relay cards. Supported relay cards:
- Conrad USB 4-channel relay card
- Sainsmart USB 4/8-channel relay card
- HID API compatible relay card
- Sainsmart USB-HID 16-channel relay card
- Generic GPIO relays
The 16 is on there, which I believe means it has the appropriate driver files installed inside of crelay for it?
Is there anything else I should check?
Thank you!
You are using a different relay card. The Sainsmart 16-channel card driver of crelay was developed for this relay card: https://www.sainsmart.com/products/16-channel-usb-hid-programmable-control-relay-module As you can see it has VID 0416 and PID 5020 which is different from yours (VID 1a86, PID 7523). Do you have a link to the product page of your card?
Ohhhh. Well. That would certainly explain it. I missed the USB-HID part there and assumed it was the same card.
This is the one that I have: https://www.sainsmart.com/products/16-channel-9-36v-usb-relay-module
Interesting, I didn't know this one. Strange that they sell it without any software which supports it. If you can find information about the communication protocol it uses (and you are willing to test) we could add support for it to crelay.
I'd be happy to help build it out. The problem has been finding the comm protocols for it. I've spent some time fuzzing it so far, but I haven't managed to trigger any of the relays yet.
I don't suppose you have easy reference somewhere for the USB 4/8? It's got to be similar.
You could try to ask Sainsmart directly for documentation, although my experience with them has been quite disappointing in the past. But I wonder how people are supposed to use this relay card if they don't provide any software, driver or at least instructions.
As for the Sainsmart 4/8 channel you find all necessary info in the source file relay_drv_sainsmart.c but I doubt that it's similar because it uses a chip with 8 digital outputs which cannot driver the 16 relays of your card.
Ah, fair enough. That isn't helpful.
And they do actually provide a couple examples and some software, but as far as I can tell the software doesn't actually function; the best I've been able to glean from other people around the net is that they've been able to kluge together solutions from old versions of software from another vendor, but it has been hit or miss, and ugly.
I'll see what I can do. I may end up just picking up a couple of the HID compatible boards.
Either way, I appreciate you helping me work through the issue here. Much appreciated.
Followup question. I grabbed one of the HID compatible cards to try out. It shows up correctly under lsusb (0416:5020), but running "sudo ./crelay -i" segfaults now. I'm assuming that means it gets through detection, sees the compatible board, tried to communicate with it, and dies, but I'm not possible.
Any recommendations?
Thanks!
Well, segfault is not good. Let's try to find out what is happening. Unfortunately I don't have this type of card here. I implemented the driver with the help of @khilman who tested this. So maybe now you can run some tests.
I suggest you put some debug printouts in the function detect_relay_card_sainsmart_16chan() in the source file relay_drv_sainsmart16.c in order to find out where exactly we get the segfault.
Thanks.
Will do! I'll let you know what I find.
I'm honestly wondering if the HID header add-on card might have been damaged in the mail, but this should help figure that out.
Hey there! I was able to find the control codes for the card I linked above and have successfully gotten it working via serial comms. I'm not sure how exactly to integrate with the project here.
Not entirely sure how to integrate with the project but I'm willing to give driver writing a try. I've worked out how to do the set_state portion, but I'm a little less clear on getting the current state from the card.
As far as detection, is that generally just done by looking at the device and vendor ID?
Great, can you post the protocol specs here? Would be interested to have a look. For the driver integration look at the sample code relay_drv_sample.c/.h or the existing drivers.
As far as detection, is that generally just done by looking at the device and vendor ID?
This is the first step. But there could be other USB devices using the same IDs so you should try to check for some unique device feature, like reading some data directly from the device. Also for multiple cards detection we need some kind of serial number which is unique for each card of that type, but this could be done as a second step.
I've looked for a serial number, but I'm not sure that these cards actually implemented one. At the very least iSerial is blank on lsusb -v.
Communication codes are embedded in my relay wrapper here: https://pastebin.com/MuDFSjY4
17 byte hex strings, mostly unchanging but byte 9 counts up from 30 to indicate which relay it is; byte 15 works in the inverse, but indicates whether the command is for on or off. It also skips a couple numbers and overlaps on each relay. It's a little weird. I'm sure it makes sense but I don't quite grasp the logic yet.
Interesting. I think the bytes are the ASCII codes of the hex characters that are sent over the serial line. You can control the relay card via a serial console by typing the hex characters. We just need to find out what they mean. I have translated the binary strings from your code into ASCII characters, and things become a bit clearer:
Relay 1
3A 46 45 30 35 30 30 30 30 46 46 30 30 46 45 0D 0A
: F E 0 5 0 0 0 0 F F 0 0 F E CR LF
3A 46 45 30 35 30 30 30 30 30 30 30 30 46 44 0D 0A
: F E 0 5 0 0 0 0 0 0 0 0 F D CR LF
Relay 2
3A 46 45 30 35 30 30 30 31 46 46 30 30 46 44 0D 0A
: F E 0 5 0 0 0 1 F F 0 0 F D CR LF
3A 46 45 30 35 30 30 30 31 30 30 30 30 46 43 0D 0A
: F E 0 5 0 0 0 1 0 0 0 0 F C CR LF
Relay 3
3A 46 45 30 35 30 30 30 32 46 46 30 30 46 43 0D 0A
: F E 0 5 0 0 0 2 F F 0 0 F C CR LF
3A 46 45 30 35 30 30 30 32 30 30 30 30 46 42 0D 0A
: F E 0 5 0 0 0 2 0 0 0 0 F B CR LF
...
Relay 16
3A 46 45 30 35 30 30 30 46 46 46 30 30 46 46 0D 0A
: F E 0 5 0 0 0 F F F 0 0 F F CR LF
3A 46 45 30 35 30 30 30 46 30 30 30 30 46 45 0D 0A
: F E 0 5 0 0 0 F 0 0 0 0 F E CR LF
Every command starts with a : . The next byte FE is probably the command code and the following 05 the number of data bytes which follow. These are 00 RR SS 00 CC with RR the relay number (from 0 to F) SS the state (00 off, FF on) and CC the checksum. The last 2 characters are just the Return Key (carriage return and line feed).
Does this make sense?
There are probably more command codes other than FE. Can you find out which these are ? Where did you get these command strings from ?
That makes a LOT more sense, and I should have thought of it. I've always thought of hardware communication as a weird world very different from the concepts I already know, but it's the exact same stuff, crooked slightly so.
Okay. So, I found these codes in some off-brand documentation from an expired ebay auction for a slightly different product, if you believe that, but they DO seem to work.
The only other actual code I was able to find is:
| 3A | 46 | 45 | 30 | 46 | 30 | 30 | 30 | 30 | 30 | 30 | 31 | 30 | 30 | 32 | 46 | 46 | 46 | 46 | 45 | 33 | 0D | 0A |
|---|
Which is to turn them all on. But it's also a slightly different length.
I think there's also a status code listed as
| 3A | 46 | 45 | 30 | 31 | 30 | 30 | 30 | 30 | 30 | 30 | 31 | 30 | 46 | 31 | 0D | 0A |
|---|
But I don't know what it does.
It might be worth asking Sainsmart for documentation. They will probably not understand what you are asking for but if they do provide some useful information it could save us a lot of time.
I just got the docs from them. It matches up with the above codes but doesn't give anything further.
I also did some research on the web and found a link to some docs here. It's probably the same that you have and I don't think there is more to find. It also contains a Windows executable file which is supposed to control the relays. This could be used to sniff the data strings which are sent to the relay card but we already have these (also contained in the included .xls file).
So actually we have all the information we need. It's a bit ugly but the command strings for the single relay commands could be just hardcoded in the driver so we can implement the relay settings. For reading the relay states you should try to send the status code to the relay and check the reply you get. I guess it will tell you the relay states. Have to find out the reply format. Please give it a try.
Hi @kjatar, did you get any further with this? Were you able to check the response date from the relay card?
Hey there,
I have been on travel and don't have the cards with me. Still on my radar!
Great, can you post the protocol specs here? Would be interested to have a look. For the driver integration look at the sample code
relay_drv_sample.c/.hor the existing drivers.As far as detection, is that generally just done by looking at the device and vendor ID?
This is the first step. But there could be other USB devices using the same IDs so you should try to check for some unique device feature, like reading some data directly from the device. Also for multiple cards detection we need some kind of serial number which is unique for each card of that type, but this could be done as a second step.
I have the exact same issue with the Sainsmart USB 16 channel 9-36V relay board. Works great on Windows. Rasberian & Ubuntu - "No compatible device detected"
lsusb Bus 001 Device 005: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
I see from the chain you have the documents that Sainsmart provides. Any progress on a Linux driver for this card.
Hi @beaglebob , personally I am not working on this relay cards driver because I don't own that card myself. Don't know if @kjatar is planning to go ahead with this. I can help with the implementation, time permitting, of course.
SainSmart just shared the source code for the "DO16" command-line tool here. Hopefully this will shed some light?
Yes, if this is the complete C source code it should contain all the details we need to implement our own driver. At the moment I don't have any time to dedicate to this, though. So any contributions are welcome.
Hi, I've been using these relay boards with Pi's for just over a year now. I created a nodejs wrapper for them that you can find here. Hope it might help.