-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sainsmart16 HID path is not stable #26
Comments
You are right. When i tried this here I was only looking at the USB path, not at the HID id which seems to be associated differently by the HID driver. Anyway, the best way to identify a relay card would be to use it's internal serial number which is usually supplied by the card itself. All other cards supported by crelay provide such a serial number and a method to access it. The 1/2/4/8 HIDAPI relays for example send this string together with the status report (see For the Sainsmart 16 channel HID relay card @khilman and I were not able to find a way to access the serial number, nor do we know if it actually provides one. There are 2 bytes in the status response which have unknown meaning but it is probably too short for a serial number. There might be another command besides READ and WRITE which provides the serial number in response. Maybe it's worth to do some testing to find that out. |
I tried using the hidapi I'll go explore some more. |
Just an update -- I sent a support request to sainsmart and got a reply back:
So.. Clearly there is a way to obtain it, it's just a question of figuring out how from the "documentation". I can't tell if there is actual source code for the GUI Apps. I'll keep looking, but maybe this will help others (you and @khilman) too? |
Great, this is more documentation than I expected Sainsmart to provide. Can you run the GuiApp and check if it really reads the serial number from the card? If it does it should be possible to sniff the USB traffic of this operation. |
That would imply finding a windows platform to run it. I'll see what I can do -- I don't really have any M$ products lying around. I might have a VM I can leverage -- but then I'm not sure how to sniff the USB bus. This is definitely getting to be beyond my current know-how. But willing to learn ;) |
You could try running the program with Wine under Linux. Otherwise you will have to use a Win VM. Sniffing the USB traffic should be possible with Wireshark, but I never tried that myself. |
Found a VM. Of course the app doesn't run because the VM is missing msvcr100.dll. sigh |
So I finally got it to run, but I don't see an actual "serial number" in there. All it displays is "Realy_NO1" (sic) which doesn't seem very helpful to me. :( I'll go ask them again to clarify. |
Oh. LOVELY. I just plugged the second unit into the VM, and they BOTH return "Realy_NO1". So both units have the same serial number, apparently. :( |
Here is some of the wireshark USB monitor output for supposedly reading the serial number (which I guess is the same on both of my cards). This was a "probe" and then flipping a relay on and then off again. You can see the "response" in packet 33 (although it comes from 1.6.4 instead of 1.6.5 -- and all other communication is with 1.6.5). Maybe this can help? I'm not sure how to decipher this.
|
Ok, that looks good.I'm not on my pc right now but will try to make some sense out of this later on. |
Another thing I discovered is that if there were a way to access the underlying |
With the GUIApp, did you try to connect both your cards and then push "Find Device" ? What happens? |
I did. They both come in as Realy_NO1 (as I reported ~8 hours ago). |
Oh sorry, I hadn't understood that you plugged in both at the same time. So in that case, if they report the same serial (or Id), then it is impossible to control the second card with the GUIApp. You should report that to Sainsmart. I assume your cards were not programmed properly with the serial numbers. |
I figured out how to interpret the USB traces from the traffic between PC and relay card. Basically there are 2 frames for each request and additional 2 frames for a request which expects a reply (e.g. a status read request).
The actual payload of the request is at offset 0040 of the first frame and the response (if any) is at offset 0040 of the third frame. The other stuff is probably the overhead of the HID protocol. To confirm that in your traces there is the read request in frame 35: and the corresponding response in frame 37: A write request in frame 39: and frame 41: These request are according to the format we use in crelay. What most interesting though, there is a new request in frame 31 which we didn't know yet, which is probably the serial number / Id request: And the corresponding response in frame 33: which reports the weird |
So in conclusion that means we could now implement the proper request for the serial number in crelay. But we need to be sure that the cards DO have a real serial number programmed, otherwise we will read only useless data. |
Alas, both cards seem to report the same data. I have requested more information from SainSmart in the interim, but they have to "research" it more and wont get back to me until at least Monday. I think the answer is going to be "uh oh". On the other hand, I have found a workaround, sort of, by modifying |
Sorry, I missed a bit of your response. Where do you see the And yes, with both cards plugged in I could only control one of them with their Gui App! I have (to some degree) reported this to them. I told them both cards showed up as And for the record, yes, Frame 31 and 33 is the serial-id request/response which I got by pushing the "Find Cards" button in their Gui App. Then I selected Relay 1 and turned it on and the off (the two requests you see in 35/37/39/41. |
Ugggh. Got the following reply from Sainsmart:
On to plan B -- changing hidapi to return a stable path. C.f. https://github.com/derekatkins/hidapi |
This response doesn't make sense, of course. If the GUIApp provides a way of selecting the serial number than it should be possible to control each connected relay card. The documentation "HID manual-11.25.doc" explicitely mentions the use of a serial number:
So I'm pretty sure your cards were not programmed correctly and are missing the serial number.
The problem I see with this is that |
FWIW, the response from SainSmart doesn't surprise me. I had a similar conversation with them about the RJ45 network connectors for the relay boards. They ship every one with identical MAC address, so you can't use 2 of them on the same LAN. :( |
It's a shame that they put these kind of faulty products on the market. I'm almost inclined to not support the Sainsmart crap anymore. By working around these defects with tools like crelay we only help them sell even more of that. 😞 |
Sorry for the delay in responding -- been travelling and then the holiday weekend.
Considering the HIDAPI library has not been touched in over 2 years, that might be challenging. I've submitted a PR, but of course there are like 60 or more outstanding PRs to hidapi. I'm happy to have it solved for me.. I agree that right now it's not a problem that crelay can solve. :( |
C.f. signal11/hidapi#406 |
So there's no hacks or workaround with udev rules to make it work without the modified hidapi? |
HIDAPI has two backends, the "linux" backend and the "libusb" backend. Which backend is in use in apparently a compile-time option (which means you're at the mercy of whomever builds it). On Fedora, for example, it uses libusb. When using libusb, the path is a monotonically-increasing number without my patch. If it uses the linux driver then it's a I have not played with udev and libusb to see if it will create a stabilized path. I have a feeling the answer is no. On the other hand, it also appears that hidapi is currently "unmaintained". |
The 16 channel HID compatible relay card which is discussed here has been discontinued by Sainsmart. Therefore no further effort will be spent to support this device. |
For the record, it looks like my changes to libhid/libusb have been pulled into a forked upstream, so I suspect this will take care of itself. Just because Sainsmart isn't selling these now doesn't mean people don't have them (I have multiple of them!). Thanks! |
Apparently the HID path for my sainsmart16 is not stable.
If I unplug the device and then plug it back in again, the path is different.
I can see this in dmesg as I remove and re-insert the device into my machine:
I cannot see a good way in the HID API to find the underlying USB path, which as you can see IS stable "usb-0000:00:14.0-4" (and my second device on "usb-0000:00:14.0-1". I am open to suggestions?
The text was updated successfully, but these errors were encountered: