TEMPered icon indicating copy to clipboard operation
TEMPered copied to clipboard

I have a TEMPerHUM, 1130:660c

Open jimbolaya opened this issue 12 years ago • 16 comments

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

jimbolaya avatar Jan 13 '13 21:01 jimbolaya

Same here

# ./build/utils/tempered
/dev/hidraw1: Could not open device: No data was read from the sensor (timeout).
/dev/hidraw3 0: temperature 23.66 °C, relative humidity 28.2%, dew point 4.1 °C
 # ./build/utils/hid-query -e
/dev/hidraw0 : 1130:660c interface 0 : (null)  PCsensor Temper
/dev/hidraw1 : 1130:660c interface 1 : (null)  PCsensor Temper
/dev/hidraw2 : 0c45:7402 interface 0 : RDing TEMPerHumiV1.1
/dev/hidraw3 : 0c45:7402 interface 1 : RDing TEMPerHumiV1.1

olegstepura avatar Mar 26 '13 13:03 olegstepura

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? Please run these commands, reinserting the device before each of them, and post the output here: build/utils/hid-query /dev/hidraw1 0x48 build/utils/hid-query /dev/hidraw1 0x52 build/utils/hid-query /dev/hidraw1 -r 0x48 0 build/utils/hid-query /dev/hidraw1 -r 0x52 0

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

edorfaus avatar Aug 04 '13 17:08 edorfaus

I got the following for each of the lines:

Device /dev/hidraw7 : 1130:660c interface 1 : (null) PCsensor Temper

Writing data (9 bytes): 52 00 00 00 00 00 00 00 00

No data was read from the device (timeout).

James

On Sun, Aug 4, 2013 at 1:07 PM, Frode Austvik [email protected]:

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? Please run these commands, reinserting the device before each of them, and post the output here: build/utils/hid-query /dev/hidraw1 0x48 build/utils/hid-query /dev/hidraw1 0x52 build/utils/hid-query /dev/hidraw1 -r 0x48 0 build/utils/hid-query /dev/hidraw1 -r 0x52 0

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

— Reply to this email directly or view it on GitHubhttps://github.com/edorfaus/TEMPered/issues/13#issuecomment-22074988 .

jimbolaya avatar Aug 07 '13 13:08 jimbolaya

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?

edorfaus avatar Aug 10 '13 00:08 edorfaus

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.

olegstepura avatar Aug 10 '13 22:08 olegstepura

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:

Init usb context
Found 14 usb devices
Skipping device 22b8:003b
Skipping device 07d1:3c09
Skipping device 05e3:0608
Skipping device 1d6b:0002
Skipping device 051d:0002
Using device 1130:660c @ 008:002
Using config 1
Skipping interface 0
Using interface 1
Opened usb device
Claimed interface 1
Skipping device 1d6b:0001
Skipping device 1d6b:0001
Skipping device 0c45:7402
Skipping device 1d6b:0001
Skipping device 1d6b:0002
Skipping device 1d6b:0001
Skipping device 1d6b:0001
Skipping device 1d6b:0001
Finished listing devices
==== 2013-08-11 01:32:28 ====
Sending 80 bytes of data to interface 1 of USB device at 008:002:
  0x00: 0A 0B 0C 0D 00 00 02 00
  0x08: 52 00 00 00 00 00 00 00
  0x10: 00 00 00 00 00 00 00 00
  0x18: 00 00 00 00 00 00 00 00
  0x20: 00 00 00 00 00 00 00 00
  0x28: 00 00 00 00 00 00 00 00
  0x30: 00 00 00 00 00 00 00 00
  0x38: 00 00 00 00 00 00 00 00
  0x40: 00 00 00 00 00 00 00 00
  0x48: 0A 0B 0C 0D 00 00 01 00
Written 80 bytes
Read 208 bytes of data:
  0x00: 19 96 05 A4 00 00 00 00
  0x08: 19 96 05 A4 00 00 00 00
  0x10: 19 96 05 A4 00 00 00 00
  0x18: 19 96 05 A4 00 00 00 00
  0x20: 19 96 05 A4 00 00 00 00
  0x28: 19 96 05 A4 00 00 00 00
  0x30: 19 96 05 A4 00 00 00 00
  0x38: 19 96 05 A4 00 00 00 00
  0x40: 19 96 05 A4 00 00 00 00
  0x48: 19 96 05 A4 00 00 00 00
  0x50: 19 96 05 A4 00 00 00 00
  0x58: 19 96 05 A4 00 00 00 00
  0x60: 19 96 05 A4 00 00 00 00
  0x68: 19 96 05 A4 00 00 00 00
  0x70: 19 96 05 A4 00 00 00 00
  0x78: 19 96 05 A4 00 00 00 00
  0x80: 19 96 05 A4 00 00 00 00
  0x88: 19 96 05 A4 00 00 00 00
  0x90: 19 96 05 A4 00 00 00 00
  0x98: 19 96 05 A4 00 00 00 00
  0xA0: 19 96 05 A4 00 00 00 00
  0xA8: 19 96 05 A4 00 00 00 00
  0xB0: 19 96 05 A4 00 00 00 00
  0xB8: 19 96 05 A4 00 00 00 00
  0xC0: 19 96 05 A4 00 00 00 00
  0xC8: 19 96 05 A4 00 00 00 00
Sending 80 bytes of data to interface 1 of USB device at 008:002:
  0x00: 0A 0B 0C 0D 00 00 02 00
  0x08: 48 00 00 00 00 00 00 00
  0x10: 00 00 00 00 00 00 00 00
  0x18: 00 00 00 00 00 00 00 00
  0x20: 00 00 00 00 00 00 00 00
  0x28: 00 00 00 00 00 00 00 00
  0x30: 00 00 00 00 00 00 00 00
  0x38: 00 00 00 00 00 00 00 00
  0x40: 00 00 00 00 00 00 00 00
  0x48: 0A 0B 0C 0D 00 00 01 00
Written 80 bytes
Read 208 bytes of data:
  0x00: 19 9A 05 A4 00 00 00 00
  0x08: 19 9A 05 A4 00 00 00 00
  0x10: 19 9A 05 A4 00 00 00 00
  0x18: 19 9A 05 A4 00 00 00 00
  0x20: 19 9A 05 A4 00 00 00 00
  0x28: 19 9A 05 A4 00 00 00 00
  0x30: 19 9A 05 A4 00 00 00 00
  0x38: 19 9A 05 A4 00 00 00 00
  0x40: 19 9A 05 A4 00 00 00 00
  0x48: 19 9A 05 A4 00 00 00 00
  0x50: 19 9A 05 A4 00 00 00 00
  0x58: 19 9A 05 A4 00 00 00 00
  0x60: 19 9A 05 A4 00 00 00 00
  0x68: 19 9A 05 A4 00 00 00 00
  0x70: 19 9A 05 A4 00 00 00 00
  0x78: 19 9A 05 A4 00 00 00 00
  0x80: 19 9A 05 A4 00 00 00 00
  0x88: 19 9A 05 A4 00 00 00 00
  0x90: 19 9A 05 A4 00 00 00 00
  0x98: 19 9A 05 A4 00 00 00 00
  0xA0: 19 9A 05 A4 00 00 00 00
  0xA8: 19 9A 05 A4 00 00 00 00
  0xB0: 19 9A 05 A4 00 00 00 00
  0xB8: 19 9A 05 A4 00 00 00 00
  0xC0: 19 9A 05 A4 00 00 00 00
  0xC8: 19 9A 05 A4 00 00 00 00
Raw temperature bytes: {0x19, 0x9A}
Raw temperature read: 6554, msb: 6400, lsb: 154
Compensated temperature: 25.84
Raw humidity bytes: {0x05, 0xA4}
Raw humidity read: 1444, msb: 1280, lsb: 164
Linear humidity: 47.6212
Compensated humidity: 47.7266
Calculated dew point: 13.90
Temperhum device @ 008:002:
  Temperature: 25.84 C
  Relative humidity: 47.73 %
  Dew point: 13.90 C
  Human perception: Comfortable
Releasing interface 1
Closing usb device handle
Exit usb context

olegstepura avatar Aug 10 '13 22:08 olegstepura

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?

build/utils/hid-query /dev/hidraw1 10 11 12 13 0 0 2 0 0x52 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 10 11 12 13 0 0 1 0

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.

edorfaus avatar Aug 11 '13 01:08 edorfaus

Will not help:

server ~ # lsusb
...
Bus 008 Device 004: ID 1130:660c Tenx Technology, Inc. Foot Pedal/Thermometer
...
server ~ # ls -la /sys/class/hidraw/
...
lrwxrwxrwx  1 root root 0 авг 11 15:07 hidraw2 -> ../../devices/pci0000:00/0000:00:1d.2/usb8/8-1/8-1:1.0/0003:1130:660C.000A/hidraw/hidraw2
lrwxrwxrwx  1 root root 0 авг 11 15:07 hidraw3 -> ../../devices/pci0000:00/0000:00:1d.2/usb8/8-1/8-1:1.1/0003:1130:660C.000B/hidraw/hidraw3
...
server ~ # hid-query /dev/hidraw2 10 11 12 13 0 0 2 0 0x52 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0                                                                         0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 10 11 12 13 0 0 1 0
Device /dev/hidraw2 : 1130:660c interface 0 : (null)  PCsensor Temper

Writing data (81 bytes):
         00 0a 0b 0c   0d 00 00 02   00 52 00 00   00 00 00 00
         00 00 00 00   00 00 00 00   00 00 00 00   00 00 00 00
         00 00 00 00   00 00 00 00   00 00 00 00   00 00 00 00
         00 00 00 00   00 00 00 00   00 00 00 00   00 00 00 00
         00 00 00 00   00 00 00 00   00 0a 0b 0c   0d 00 00 01
         00

No data was read from the device (timeout).
server ~ :( # hid-query /dev/hidraw3 10 11 12 13 0 0 2 0 0x52 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0                                                                         0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 10 11 12 13 0 0 1 0
Device /dev/hidraw3 : 1130:660c interface 1 : (null)  PCsensor Temper

Writing data (81 bytes):
         00 0a 0b 0c   0d 00 00 02   00 52 00 00   00 00 00 00
         00 00 00 00   00 00 00 00   00 00 00 00   00 00 00 00
         00 00 00 00   00 00 00 00   00 00 00 00   00 00 00 00
         00 00 00 00   00 00 00 00   00 00 00 00   00 00 00 00
         00 00 00 00   00 00 00 00   00 0a 0b 0c   0d 00 00 01
         00

No data was read from the device (timeout).

olegstepura avatar Aug 11 '13 12:08 olegstepura

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: #include <unistd.h> and then insert this on line 95 (before the read call): usleep(400000);

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.

edorfaus avatar Aug 11 '13 16:08 edorfaus

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.

temper-hum-hid$ ./temper-hum-hid -v
Init usb context
Found 7 usb devices
Skipping device 1d6b:0002
Skipping device 1d6b:0001
Skipping device 1d6b:0001
Skipping device 1d6b:0001
Skipping device 1d6b:0001
Skipping device 04f2:b071
Using device 0c45:7401 @ 002:014
Using config 1
Skipping interface 0
Using interface 1
Opened usb device
Claimed interface 1
Finished listing devices
==== 2013-08-11 18:52:42 ====
Sending 80 bytes of data to interface 1 of USB device at 002:014:
  0x2029: 00 00 00 00 02 02 02 02 00 00 01 
Written 80 bytes
Error: Read of data from the sensor failed at interafce 1: -9
Releasing interface 1
Closing usb device handle
Exit usb context

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.

edorfaus avatar Aug 11 '13 17:08 edorfaus

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

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.

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: #include <unistd.h> and then insert this on line 95 (before the read call): usleep(400000);

Modifies this way:

 87     if ( size <= 0 )
 88     {
 89         fprintf( stderr, "Write failed: %ls\n", hid_error( dev ) );
 90         ret = 6;
 91     }
 92     else
 93     {
 94         usleep(400000);
 95         ret = read_from_device( dev, 4000 );
 96         if ( ret == 8 )
 97         {
 98             fprintf( stderr, "No data was read from the device (timeout).\n" );
 99         }
100         else if ( ret == 0 )
101         {
102             while ( ret == 0 )
103             {
104                 ret = read_from_device( dev, 200 );
105             }
106             if ( ret == 8 )
107             {
108                 ret = 0;
109             }
110         }
111     }

Does not help:

server /usr/src/TEMPered/build :( # time utils/hid-query /dev/hidraw3 10 11 12 13 0 0 2 0 0x52 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 10 11 12 13 0 0 1 0
Device /dev/hidraw3 : 1130:660c interface 1 : (null)  PCsensor Temper

Writing data (81 bytes):
         00 0a 0b 0c   0d 00 00 02   00 52 00 00   00 00 00 00
         00 00 00 00   00 00 00 00   00 00 00 00   00 00 00 00
         00 00 00 00   00 00 00 00   00 00 00 00   00 00 00 00
         00 00 00 00   00 00 00 00   00 00 00 00   00 00 00 00
         00 00 00 00   00 00 00 00   00 0a 0b 0c   0d 00 00 01
         00

No data was read from the device (timeout).

real    0m4.460s
user    0m0.003s
sys     0m0.000s

olegstepura avatar Aug 11 '13 19:08 olegstepura

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 libusb. None of both uses HID as it should, not sure if this is even possible, even that the device is called HIDTemperHum.

the temperhum_debug_bytes line for the data being sent is strange, starting with offset 0x2029 and showing some other data

Mine was my first project in c, so there also may be errors.

Both detach kernel driver. https://github.com/olegstepura/HID-TEMPerHUM/blob/master/temper.c#L68 https://github.com/olegstepura/temper-hum-hid/blob/master/temper-hum-hid-api.c#L131

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. How do you sniff USB traffic? Maybe I can do this with mine TemperHum and a working program?

olegstepura avatar Aug 11 '13 19:08 olegstepura

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

edorfaus avatar Aug 11 '13 22:08 edorfaus

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.

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.

olegstepura avatar Aug 12 '13 06:08 olegstepura

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. If you look at the hidapi source for libusb you see that hid_get_feature_report uses res = libusb_control_transfer(dev->device_handle, LIBUSB_REQUEST_TYPE_CLASS|LIBUSB_RECIPIENT_INTERFACE|LIBUSB_ENDPOINT_IN, 0x01/*HID get_report*/, (3/*HID feature*/ << 8) | report_number, dev->interface, (unsigned char *)data, length, 1000/*timeout millis*/); I have this working in node.js with node-hid

rinie avatar Sep 04 '16 08:09 rinie

I have Bus 001 Device 006: ID 0c45:7402 Microdia TEMPerHUM Temperature & Humidity Sensor temperv14 works on this device. I changed #define PRODUCT_ID 0x7401 to #define PRODUCT_ID 0x7402 wget http://dev-random.net/wp-content/uploads/2016/01/temperv14.zip

tomdean1 avatar Aug 26 '17 06:08 tomdean1