I have a TEMPerHUM, 1130:660c #13
Comments
|
Same here |
|
Thank you both for reporting this. The error message you get means that tempered failed to read the subtype identifier (to see if it's temper1/2/hum or ntc) from the device, so apparently the code that I thought would work doesn't. (I don't have one of these myself, or any other 1130:660C device, which makes it difficult to test.) There's one other problem, too, which is that I don't know what the subtype identifier is for the -hum variant, but if we can fix the above problem, that should solve itself (since tempered will print what the identifier should be). Since I don't have one of these myself, could you help me with figuring out how to read data from it? (Obviously, if your device isn't /dev/hidraw1, change that to the correct device path.) The reinserting is because any wrong query usually locks up the TEMPer devices so that they don't respond to correct commands anymore, until the device is plugged out and back in (reset by power cycle). |
|
I got the following for each of the lines: Device /dev/hidraw7 : 1130:660c interface 1 : (null) PCsensor Temper Writing data (9 bytes): No data was read from the device (timeout). James On Sun, Aug 4, 2013 at 1:07 PM, Frode Austvik notifications@github.comwrote:
|
|
Hm, that's too bad, I was kinda hoping one of those would work. Now I have to come up with an idea for something else to try... I don't suppose you have a dump of the USB traffic from the official program (or another one that works) that I could take a look at? |
|
This works https://github.com/olegstepura/temper-hum-hid and this: https://github.com/olegstepura/HID-TEMPerHUM Just it would be very convenient to use only one (TEMPered) software for both my tempers that are different because I ordered it with a year delay or so. |
|
BTW I can provide you dump of USB traffic since you don't have such device. Here is output of the first project I mentioned: |
|
Oh, nice. Thank you. I took a quick look at the code and that output, and I suspect that I simply misunderstood some things in the original code I cribbed the request data from, that seems clearer now. I'll take a closer look a bit later (can't right now), to compare things and try to fix tempered, but meanwhile, could you try another command for me, to check if I've understood things better now?
It's a bit long, but I suspect this is (part of) what's needed. Judging by something I saw in the code I'll probably need to do some changes beyond just that data, but I think it should work at least as far as getting a response, even if it might not contain anything really useful. |
|
Will not help: |
|
Huh. That's weird. I built your temper-hum-hid project (only modified the USB vendor/product IDs so it would try to talk with one of my TEMPers), and ran Wireshark to sniff the USB bus traffic. I also sniffed the traffic for the above command. As far as I can tell, the data they send is identical. (The other program is a bit different, it sends multiple reports(writes) with more zeroes in them, but if both of the programs work that shouldn't be a problem.) I suppose there's the issue that hid-query doesn't wait before it tries to read the response, it just assumes that the device will send data whenever it's ready and does a blocking read. But then, that second program (HID-TEMPerHUM) doesn't wait either, it too just writes and then immediately reads - so if it works, hid-query should work too... Although, maybe the fact that it sends more zeroes using more writes is what makes that work? It's easy to make hid-query wait though, just to eliminate that as a problem. Just edit utils/hid-query.c and add this include at the top: The only other difference I see at the moment is that you tried to send to the wrong interface first, before sending to the correct one, so unless you reinserted the device between those runs, maybe the first query made it stop responding? That kind of thing seems to happen with most of mine anyway. |
|
Hm, I noticed the output of temper-hum-hid is somewhat different for me compared to yours... I'm not sure how it manages to get quite this output though. In particular the temperhum_debug_bytes line for the data being sent is strange, starting with offset 0x2029 and showing some other data... Despite this output though, the bus sniffing shows what it actually sent. |
No, not the case. I rebooted and then run it with first interface then reinserted and then run the second time. Anyways I just rebooted agian and run only the /dev/hdiraw3 and then reinserted and run again and always got timeouts.
Modifies this way: Does not help: |
|
I must also make a note that for my program to work I have to detach kernel driver. And mine (first) was a rewrite of the second one with newer
Mine was my first project in c, so there also may be errors. Both detach kernel driver. Detaching kernel driver is also the reason why I had to reboot before testing. Seems like the it's not possible to reattach the driver back after talking to device. |
|
Ok, so it being frozen should not be the case then. A bit odd that you need to reboot to reattach it to the kernel, as for me it gets attached automatically every time I reinsert it. Btw, I'm pretty sure that the libusb variant of hidapi detaches the kernel driver as well, and if you build tempered with that variant selected you shouldn't need to reattach it (but will have to change the device path you start it with). After a bit of debugging (took a while of looking), I figured out the problem with the debug output - in temper-hum-hid-api.c line 102, current_byte needs to be 4 characters long, not 3, as you later insert two digits and a space into it, and it also needs room for the string terminating zero character. In this case though, I think this only affected the debug output - not the actual functionality. Fairly minor bug, as bugs go, and having one is no surprise - I've been programming for decades (though not usually with C), and bugs always manage to sneak in. With that fixed, my output looks a lot more like yours (up to the first written 80 bytes message at least). For USB bus sniffing, I'm using Wireshark - just make sure to load the usbmon kernel module, and set the permissions on the /dev/usbmonN device so you can read/write to it, before starting Wireshark. To limit it to just the interesting traffic, I'm keeping the TEMPer on a USB bus all by itself (except the root hub of course), and set it to only sniff on that bus. To be honest, I'm kind of out of ideas at this point, so if you can figure out what the difference between them is, that would be great. Once I know what detail I need to fix, I can probably figure out how to implement it. Hm, actually, I do have one more idea - using the libusb variant of hidapi instead of the hidraw variant - but I don't really expect that to make any kind of difference (other than not needing to reattach the device to the kernel). |
Well, I don't know, maybe I can just reinsert it, I think it's same as you. I will try USB sniffing later and will let you know the results. |
|
You try to read the data with hid_read_timeout. The code of olegstepura uses hid_get_feature_report report 0, 256 bytes, 1 extra for hid report handling. |
|
I have |
I have an HID TEMPerHUM.
./hid-query -e
/dev/hidraw3 : 1130:660c interface 0 : (null) PCsensor Temper
/dev/hidraw4 : 1130:660c interface 1 : (null) PCsensor Temper
./tempered
/dev/hidraw4: Could not open device: No data was read from the sensor (timeout).
It has a red light the flashes when it's first plugged in. If I run tempered on it, it flashes about once a second (on/off), but I always get the same answer.
James
The text was updated successfully, but these errors were encountered: