crelay icon indicating copy to clipboard operation
crelay copied to clipboard

Relay detection

Open kjatar opened this issue 7 years ago • 32 comments

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!

kjatar avatar Jul 01 '18 02:07 kjatar

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 .

ondrej1024 avatar Jul 01 '18 08:07 ondrej1024

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.

kjatar avatar Jul 01 '18 16:07 kjatar

Did you build crelay with support for the sainsmart driver ? Try to run just the crelay command and check the list of supported relays.

ondrej1024 avatar Jul 02 '18 10:07 ondrej1024

Also check with the lsusb console command if the card is detected by the OS.

ondrej1024 avatar Jul 02 '18 10:07 ondrej1024

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!

kjatar avatar Jul 03 '18 02:07 kjatar

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?

ondrej1024 avatar Jul 03 '18 08:07 ondrej1024

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

kjatar avatar Jul 03 '18 12:07 kjatar

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.

ondrej1024 avatar Jul 03 '18 13:07 ondrej1024

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.

kjatar avatar Jul 03 '18 14:07 kjatar

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.

ondrej1024 avatar Jul 03 '18 15:07 ondrej1024

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.

kjatar avatar Jul 03 '18 15:07 kjatar

Either way, I appreciate you helping me work through the issue here. Much appreciated.

kjatar avatar Jul 03 '18 15:07 kjatar

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!

kjatar avatar Jul 07 '18 16:07 kjatar

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.

ondrej1024 avatar Jul 10 '18 07:07 ondrej1024

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.

kjatar avatar Jul 10 '18 13:07 kjatar

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?

kjatar avatar Jul 17 '18 04:07 kjatar

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.

ondrej1024 avatar Jul 17 '18 06:07 ondrej1024

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.

kjatar avatar Jul 17 '18 16:07 kjatar

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 ?

ondrej1024 avatar Jul 17 '18 21:07 ondrej1024

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.

kjatar avatar Jul 18 '18 03:07 kjatar

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.

ondrej1024 avatar Jul 18 '18 09:07 ondrej1024

I just got the docs from them. It matches up with the above codes but doesn't give anything further.

kjatar avatar Jul 18 '18 21:07 kjatar

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.

ondrej1024 avatar Jul 19 '18 12:07 ondrej1024

Hi @kjatar, did you get any further with this? Were you able to check the response date from the relay card?

ondrej1024 avatar Jul 30 '18 14:07 ondrej1024

Hey there,

I have been on travel and don't have the cards with me. Still on my radar!

kjatar avatar Jul 30 '18 17:07 kjatar

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 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.

beaglebob avatar Jan 12 '19 22:01 beaglebob

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.

ondrej1024 avatar Jan 13 '19 10:01 ondrej1024

SainSmart just shared the source code for the "DO16" command-line tool here. Hopefully this will shed some light?

NadavK avatar Dec 13 '19 12:12 NadavK

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.

ondrej1024 avatar Dec 16 '19 14:12 ondrej1024

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.

haf-decent avatar Jun 08 '20 00:06 haf-decent