In addition to the Tenma driver, I just finished writing a driver for the TEMPer usb temperature sensor. I found that much of the information on the Internet regarding linux drivers for this device was wrong. Perhaps they refer to a different version of the part. The usb device I received uses a customized HID chip. You can find the linux driver here. Note that this driver is based on the libusb user space library and is not a kernel level driver. The driver can be compiled either as a standalone program or as a library to your own application. Permissioning is handled with a udev rule file.
- Comment
- Reblog
-
Subscribe
Subscribed
Already have a WordPress.com account? Log in now.
Relavak Labs 
October 28, 2009 at 10:34 pm |
Rather than TEMPer, I bought a TEMPerHUM (http://usb.brando.com/usb-hygro-thermometer-ii_p01154c035d015.html). First I tried to use the driver provided at http://github.com/lp0/temperhum/, but it doesn’t seem to work. I think that’s because the TEMPerHUM I got uses the USB HID interface.
When I try to use your driver, things don’t work too well either. temper’s output always shows: “temperature -139.90F -95.50C”.
In the function TemperGetTemperatureInC, there are several TemperSendCommands. How do you know what numbers to send? Changing some of those numbers leads to a different temperature output, but I’ve yet to find a combination where the temperature output is not always the same.
October 28, 2009 at 11:38 pm |
This driver is for the device I got in the mail called the TEMPer. It seems that over time the manufacturer has put lots of different products in the market with the same name and very close to the same name all with different underlying implementations.
The way I wrote the driver was by using USB sniffing (try http://www.pcausa.com/Utilities/UsbSnoop/default.htm) on a Windows machine running the included Windows software and then replicating that same USB interaction in Linux. I cannot say what or why it does what it does or what many, if any, of those numbers mean. The 0x54 seems to be a command to get the temperature. 0x52 is a command to get the contents on an onboard NVRAM that seems to serve no purpose. My guess is that 52 and 54 are different devices on an I2c bus so the devices in your product may have a different address map. Try some other addresses or download the sniffing program to see what the Windows software does.
For my device the temperature ended up at the first locations in the data memory. Your device may put them in other locations.
November 3, 2009 at 6:06 pm |
Hello, i got this error :
Found device: 4348:5523
Found deviceNum 0
Trying to detach kernel driver
Device already detached
Detach failed: Invalid argument[22]
Continuing anyway
TemperCreate: No such file or directory
(kernel 2.6.31-14 gcc 4.4.1 libusb 0.1-4 libusb-dev 0.1.12-13 )
November 3, 2009 at 11:07 pm |
Looking at the code in temper.c – the Found deviceNum printf should only get executed if the VENDOR_ID and PRODUCT_ID match, which they should not given the only device found was 4348:5523. I’m not sure why this is happening though. Try commenting out the call to TemperCreate and see what devices it is finding and what the idVendor and idProduct fields are for those devices.
June 3, 2010 at 5:59 pm
I’m getting the same problem. I edited temper.c to change the VENDOR_ID and PRODUCT_ID to the values that my TEMPer uses (4348:5523). I also edited 99-tempsensor.rules and installed this to /etc/udev/rules.d but no luck.
I guess I have a different version of TEMPer that’s not compatible with this driver 😦
November 29, 2009 at 2:13 am |
I’m still trying to adapt Robert’s code to read data from a TEMPerHUM. I haven’t gotten very far yet, but have sniffed USB transfers while the PCsensor Windows program is running. I’ve uploaded a USB log to: http://gist.github.com/244751. The corresponding CSV file produced by the PCsensor program is at: http://gist.github.com/244753. If Robert, or anyone else with a HID TEMPer, finds the time to produce similar files, that might help me orient myself.
November 29, 2009 at 3:57 am |
Looking at the usb transactions:
I see the 0a 0b 0c 0d 00 00 02 command (look at TemperGetTemperatureInC), but the corresponding SetupPacket is different: a1 01 00 03 01 00 00 01 compared to the others: 21 09 00 02 01 00 20 00). That means you should use a different usb_control_msg (SetupPacket is the usb_control_msg) in TemperSendCommand for this transaction. Use usb_control_msg(t->handle, 0xa1, 1, 0x300, 0x01, (char *) buf, 256, t->timeout).
The next difference I see is that the next TemperSendCommand which currently has a 0x54 for temperature changes to 0x48.
Finally, the result seems to be in the two bytes after the temperature reading (i.e. buf[2] and buf[3]).
The question remains about how to interpret the result. Almost all i2c temperature sensors use the same coding. I am not familiar with humidity sensors. You might try to open the unit and see what type of sensor is used (on mine they scratched off the chip markings so that didn’t work). looking at google it may be the SHT series sensor from Sensirion. Based on the csv file it looks like this is the right chip. Try using the formulae: x = (buf[3] & 0xFF) + ((buf[2] & 0xFF) << 8); rh = -2.0468 + 0.0367 * x – 1.5955e-6 * x*x;
Good luck.
December 1, 2009 at 3:45 am
I’ve attempted to make the changes you suggested, but haven’t yet succeeded in seeing reasonable, or even varying output from the TEMPerHUM. You can see what I’ve done at: http://github.com/jeixav/HID-TEMPerHUM. One point that concerns me is that TemperSendCommand2 returns 8 bytes not 32 like TemperSendCommand.
Sample output: http://gist.github.com/246028
December 1, 2009 at 4:28 am
I made a mistake in my previous reply. TemperSendCommand2 is not needed (i.e. you should use TemperSendCommand instead). The SetupPacket comes after the transfered data in the log, not before it. So the only real difference is the 0x48 vs. the previous 0x54. Good luck, again.
December 1, 2009 at 5:17 am
Ah! Yes, I’d wondered a little about that. I reverted to TemperSendCommand everywhere, but still no luck. I thought that perhaps the TemperGetOtherStuff initialization needs have additional TemperSendCommand commands, but that still doesn’t seem to do the trick…
Output at: http://gist.github.com/246080
November 29, 2009 at 8:13 pm |
I haven’t had a chance to try any of the code modifications you’ve suggested, but have opened and taken photos of the HID TEMPerHUM. They are at: http://www.flickr.com/photos/45189490@N08/4144058581/in/set-72157622775719447/
Thanks very much for helping with this Robert; I’ll try to continue working on this soon.
December 6, 2009 at 11:56 am |
Hi, I tried http://github.com/jeixav/HID-TEMPerHUM but I got an incorrect value; I have debian 64.
root@dello:/media/dati/src/jeixav-HID-TEMPerHUM-ef91074# ./temper
Temperature: -39.48°F, -39.71°C
Relative humidity: -4445.23%
December 6, 2009 at 8:14 pm |
The code for the TEMPer with humidity is not working yet. Valerie Moore got a version of the that code to work by putting a delay before reading the data and by using the proper temperature coding for the temperature/humidity chip. I believe she is working on minimizing the delay and should have some final code soon.
December 7, 2009 at 8:18 pm
Actually, the the last few revisions posted on github work with the HID TEMPerHUM I have. Therefore, I’m not sure why paolo doesn’t see reasonable values.
As relavak writes, it’s true the the delay hasn’t been minimized, but I would have expected that having a one second sleep time (see line 202 of http://github.com/jeixav/HID-TEMPerHUM/blob/ef910749393ffa4a7804a7b787828c5017775663/temper.c) would always work.
I’m also using Debian 64, for what it’s worth…
December 8, 2009 at 6:10 pm |
Hi, I tried (http://github.com/jeixav/HID-TEMPerHUM) also with an archlinux (32 bits) and I got the same wrong value; therefore https://relavak.wordpress.com/2009/10/04/tenma-72-7730-in-linux/ works very well
December 8, 2009 at 7:59 pm
Do you have the TEMPer or the TEMPerHUM? The code in github only works with the TEMPerHUM.
December 10, 2009 at 4:05 pm |
I successfully installed your driver. I also modified it a bit for a once only output. Nice code! Thanks!
December 13, 2009 at 4:59 pm |
My TEMPer just showed up in the mail from Hong Kong today! This works for me on Ubuntu Karmic 64-bit. Thanks!
December 16, 2009 at 12:35 am |
Hi.
I am trying to convert the code to work on Windows, using LibUsbDotNet, but I am having difficulties figuring out the parameters used in usb_control_msg.
Using google I can only find calls to usb_control_msg with 9 parameters (eg. http://people.nl.linux.org/ftp/pub/anoncvs/kernelnewbies/documents/kdoc/kernel-api/r11386.html ), but your C-code has 8?
Could I kindly ask you to explain what the parameters mean – or perhaps provide me with a link?
Thanks in advance.
December 16, 2009 at 4:26 am |
According to the usb.h header file in libusb, the calling sequence is:
December 16, 2009 at 4:58 pm |
I think usb_control_msg exists in two unrelated places. libusb, hosted at http://www.libusb.org is used with relavak’s software. For usb_control_msg, for example, see http://libusb.sourceforge.net/doc/function.usbcontrolmsg.html The documentation RBJensen found, for the Linux kernel API is probably completely unrelated.
December 16, 2009 at 11:14 pm |
Ah, sorry – I had also found the correct “8-parameter” usb_control_msg from a libusb reference page, but since I could not see any references to libusb in the source code I assumed it was using something else. As usual, after making a fool of myself I now see that libusb was mentioned in the main description on the top of this page…Sorry…
Well, I have another request for help. My device is a “temperntc”, which is a dual temperature device, and so none of the code here works right off the bat. Could I ask one of you to help me figuring out which parameters to use? I’ve created a log using UsbSnoop, but I am unable to ‘decode’ it.
Link: http://dora2.drunkardswalk.dk/UsbSnoop.log.txt
Thanks in advance.
December 17, 2009 at 5:57 pm |
To help decipher the snooped USB data, it may help if you also provide information on the temperature data logged by the Windows software provided by RDing/PCsensor that corresponds to the USB dump.
Is the device you have this one: http://www.pcsensor.com/Thermometer/1-outer-NTC-sensor-thermometer/prod_27.html ?
Based on the software listing at http://www.pcsensor.com/software/info_5.html it looks like there’s a TEMPerNTC and an HID TEMPerNTC. Do you know which you have?
December 19, 2009 at 5:35 am |
The usb_control_msg calls can be found by looking for SetupPacket in the snoop log. The bytes array is then found above the SetupPacket after TransferBufferMDL. The SetupPacket is coded as: byte requesttype, byte request, word value, word index, word size. All words are 2 bytes in little endian order (i.e. lsb first). It looks like the transactions for your device are very different than those of the HID TEMPer device. You are getting 42 bytes of data for each transaction. I have no idea how it is coded. Try changing the temperature and see what changes in those 42 bytes – that might help figure out what in there is temperature and what is other stuff.
December 19, 2009 at 10:56 am
Thanks, Relavak.
The log I pasted doesn’t make much sense, I agree. I only logged a short time, until the application had updated both sensors, to hopefully make it easier to understand.
However, something is wrong right now, the application does not work anymore when I enable logging – the tray icon shows up, but the main form never does.
And I can’t kill the application – neither task manager or taskkill/F works, only a reboot.
Somehow the snoop filter seems to block the (inbound?) communication, so I’ll try to on another PC shortly.
I did get the “usb_control_msg” working in my own application, using the same values as the HID TEMPer in your code, and I *think* the internal sensor is being read exactly the same way in my HID temperNTC as the “standard” HID TEMPer:
The result from reading the temperature is a 256-byte array with the values “24 32 49 0 0 0 0 0 ” repeated.
24 + 32/256 = 24.125 degrees C – and that value changes to something like 28-30 degrees C when I hold the device in my hand.
So that is half the way to understanding the TEMPerNTC.
I’ve also used Reflector on the TemperNTC application, trying to get some hints, but unfortunately the actual readings from the device is handled by a non-DOT.NET dll, which Reflector cannot disassemble. I saw that the internal temperature is read by only one method call in the dll, so it makes sense that your code also does it in only one method call.
Getting the external temperature is quite more complicated – it seems like the application uses the DLL to read a voltage, dynamically adjusts some sort of gain, and finally uses a lookup table to find the current temperature based on the voltage/resistance characteristics of the NTC. So although it should be possible to snoop the USB communication, making sense of it will probably require tracing the execution of the application simultaneously…
December 21, 2009 at 3:14 am |
Works like a charm, thanks.
December 30, 2009 at 4:04 pm |
Well, it seems like I’ve been able to hack something together that can read both the internal and external sensor on the HIDTemperNTC – on Windows, at least, using LibUsbDotNet, from a C# app.
The code is still quite a mishmash, and some of it makes no sense, although it works. (defining “works” as that it gives results very close to what the original application reports)
I’ll clean up the code a bit and put it somewhere on the Internets, in case one of you Linux people wants to port it.
Thanks for the help, Relavak.
January 2, 2010 at 12:58 am |
As promised, here is some code in case you feel like porting it:
http://drunkardswalk.dk/Files/HIDTEMPerNTCInterface.zip
January 4, 2010 at 10:14 pm |
Thanks for the driver. One note:
I found with the driver, things were fairly inaccurate (only .5 degree steps in temperature).
I did a USB trace of the HID Temper software, and found there was an added command, apparently initialization, that when added, seems to kick things into .04’C accuracy (basically with this fix, the second hex digit of the temperature would vary by steps of 0x10).
The command required is almost exactly as a chunk you have commented out in your code, the 0x43 “command” (I assume it’s some kind of command). Also, your code only had 6 batches of zeros sent with this command, whereas the HID TEMPer software sent 7. When I uncommented this section and changed it to 7 batches of zeros, I started getting the .04’C accuracy.
Looking at more details on calibration, and I should be a happy camper. 🙂
Thanks again…
-dale
January 5, 2010 at 4:29 am |
Huh?
In the “Connect” method, after finding the device, I call “Init()”, which sends the 0x43 and 7 “0-strings”. (I do send 7 – how do count only 6?)
I agree that it must be a initialization command – as the comment for “Init()” states:
“Emulates EntryAPI.EMyInitConfig ” (which is a DLL-call used in the original application)
I may very well have made a mistake – I did: I just noticed that checkGain() should have been private, not public – but apart from that I fail to understand what you mean – so please enlighten me.
January 5, 2010 at 12:39 pm
Sorry, RB, I was referring to Relevak’s code, not yours. Yours seems to do a lot more, and perhaps is more accurate (although I don’t have time to fully port it and try it out).
Relevak: I agree, the added precision might not be that useful, as the device is quite inaccurate.
I’m just wondering with additional code, gain settings, etc., etc. if it can be made more accurate and consistent; perhaps the accuracy problems are due to incomplete reverse-engineered drivers, rather than the device itself.
In any case, while I do like the TEMPer, and you can’t beat the price, I’m thinking I much splurge a few extra dollars on a more consistent unit with a more generic driver interface.
January 5, 2010 at 5:27 am |
Thanks for your comments. I found that the temperature sensor is not very accurate so increasing the precision is not so important. With better calibration, however, you should be able to make use the higher precision.
January 11, 2010 at 2:11 am |
Hi.
I have created an interface to the HidTEMPerNTC and HidTEMPer units in Perl. It will hopefully be release in the near future at CPAN ( hopefully within a few weeks )
Will post back here when the code is available.
January 12, 2010 at 7:28 pm |
Looking forward to that perl interface. It is not available from your homepage? Got TEMPerNTC.
January 26, 2010 at 6:37 pm |
I’m really looking forward for your release… as sooner as better…
i have a lot of probs to get my “HID TEMPerHUM” running…
there should be a wiki or forum or something where people like we can gather…
January 27, 2010 at 1:03 am
What sorts of problems are you experiencing with the HID TEMPerHUM? The code I’ve posted at http://github.com/jeixav/HID-TEMPerHUM has worked quite reliably for me.
January 30, 2010 at 6:49 pm |
Any progress on the perl bits? Found nothing @search.cpan.org yet 🙂
Just to correct myself, I have a HID TEMPerNTC.
Still haven’t found anything else promising to read the external sensor on linux.
Dag B
January 30, 2010 at 9:03 pm
Well, you could try to see if my C# version could work under Mono?
February 2, 2010 at 10:07 pm
Hi.
Doing some final work now, will be published very shortly.
January 14, 2010 at 4:52 pm |
Thanks for the great piece of software… It was easy to modify to suit my needs!
I had to install libusb-dev on debian to be able to compile.
January 26, 2010 at 2:09 pm |
Hey, just thought folks might appreciate a comparison of the TEMPer and the good old 1-wire DS1820 themometer:
When I first got the temper, it was a bit of a bugger to get working with the various linux programs out there, trying to figure out what the darn device was doing, and how to best interface with it. Relavak’s driver was the best bang for the buck for me; not overly complex, did the job as well as the others…
I’ve been using the temper with a tweaked version of his software for a few months, and it seems to work. The main thing was uncommenting some code (and fixing it) to increase the resolution.
The numbers seemed a bit inconsistent with my wall thermostat, but with a few tweaks and adjustments, they weren’t too far off.
I recently received a DS9490 USB-to-1-wire interface ($28 from hobbyboards.com) and a handful of DS1820 themostat devices ($4 each, from the same place). Trivial to wire up, and Ubuntu loaded the 1-wire master/themostat drivers instantly and automatically. A simple read of the device file, and I get the temperature. Pure magic. 🙂
cat /sys/devices/w1_bus_master1/10-000801e175db/w1_slave spits out:
30 00 4b 46 ff ff 0f 10 b8 : crc=b8 YES
30 00 4b 46 ff ff 0f 10 b8 t=23812
23812 is the temperature * 1000. Pretty easy to snag and parse…
Anyhow, having a fondness for my TEMPer, I thought I’d run them in parallel, sitting right next to each other to see how they stack up. The DS1820 is supposed to be accurate to within .5C without any calibration.
The TEMPer was surprisingly consistent with the DS1820. (I often wonder if it uses one internally; I I opened my TEMPer, but the numbers were scraped off the chip. D’oh.)
I adjusted the offset on the TEMPer to align the graphs with the DS1820. For mine, that required subtracting 1.1 degrees C from the raw temperature/256 that the USB calls get from the TEMPer. That is, the value retrieved by this line in Relvak’s code:
temperature = (buf[1] & 0xFF) + (buf[0] << 8);
If I divide that by 256.0, take off 1.1, I get readings that are amazingly consistent with the DS1820.
You can see a graph at http://gass.ca/misc/temper.png
TEMPer is in blue, DS1820 is in black.
Again, within all ranges of household temperatures, they seem bang on. The only difference is that the TEMPer seems to lag behind the DS1820’s readings by 7-8 minutes or so.
The only significant differences are when the temperature is changing rapidly, and the TEMPer will catch up given a few minutes. When the temperature is rising quickly, the TEMPer reads lower, when it’s falling quickly, the TEMPer reads higher. When the changes are gradual, they agree nicely. So it’s really just lag.
The TEMPer does provide a smoother set of numbers, whereas the DS1820 can jump around (if you’re moving the device or such).
I wonder if the TEMPer has some averaging/smoothing code in it. Also, my TEMPer is in it’s USB case, whereas my DS1820 is bare to the air; that alone could explain the delays.
In an earlier discussion, Relavak mentioned that the code to improve the resolution of the TEMPer wasn’t necessary, as it wasn’t a very accurate device to start with. Given my experiments, I’d tend to disagree; calibrated, it seems to be very accurate, so the extra resolution is worthwhile, IMHO.
Anyhow, just thought I’d share. Overall, I love the DS1820’s; being able to string any number of these $4 devices on the same two wires, and get readings so easily from any number of devices is a dream. (The $28 for the USB interface is slightly costly, but you can make your own RS232->1-wire interface with a few diodes, transistors, etc., if you’re prone to that type of thing. 🙂
But I think the main thing that I got out of this “experiment” is how accurate the TEMPer actually is, once you apply an offset. I didn’t need any multiplier, just a constant -1.1C to get very consistent results with the supposedly-more-accurate DS1820.
Cheers!
February 8, 2010 at 12:55 am |
Hi.
The Perl-code has finally been released at CPAN.
http://search.cpan.org/~msulland/Device-USB-PCSensor-HidTEMPer-0.01/
February 16, 2010 at 9:20 pm |
Hi Magnus.
The perl code works great. I haven’t tried verifying the temperature yet, but the readings are at least credible.
Do the perl bits enable the hi-resolution accuracy by default?
Thanks a lot!
Dag B
February 18, 2010 at 7:10 pm
Hi.
My code does, to the extent I know, the same things that the official code does. One thing that is different is that I do not send a config = 0 command (that I can remember), this is done by the official code. The calculation of the external temperature is very different to the official approach. I think this increases the resolution, but more testing is needed.
Feedback on the resolution and accuracy is extremely appreciated. It is possible to use my CPAN email: msulland@cpan.org to contact me directly.
March 15, 2010 at 3:01 pm |
Magnus,
First of all, thanks for coding this up, I’d had a stab at some of the other code out there, but this is something I could get working.
I’ve done a writeup of installing this for Ubuntu (Karmic), that’s up now at:
https://wwwx.cs.unc.edu/~hays/archives/2010/03/entry_25.php
February 8, 2010 at 5:57 pm |
Hi all,
i am wondering about the factor for temperature correction (Table 9). On HID-TEMPerHUM it is -39.7 (equals 3.5V VDD), OpenBSDs uthum uses -40.1 (equals 5.0V VDD).
Could anyone with an already opened case measure the voltage, please?
Regads,
Michael!
February 8, 2010 at 6:52 pm |
In HID-TEMPerHUM, I set -39.7 since that was the middle value in Table 9 of the Sensirion SHT1x datasheet.
It might take a long time before I get around to opening the case of my HID TEMPerHUM, but I’m not sure taking a measurement would help. I think this voltage can fluctuate over time and it can vary from one system to the other. Given that uthum(4) and lp0’s temperhum are set to 5V, I suspect this is the best fixed value. I wonder if values shown by Linux’s sensors(1) could give dynamic readings for this voltage.
February 9, 2010 at 9:07 am |
I think it is directly powered by USB-Bus. So if the supply drops below 4.5V something is wrong with your system.
But as I am not exactly sure, someone should measure it… I’ll do it, but not earlier than end of the week.
February 11, 2010 at 6:25 am |
I measured 3.16V, so -39.6 is probably the best correction Value.
The Pads are
– GND (square one)
– SCK
– DATA- VDD
February 18, 2010 at 9:25 pm |
Hi relavak,
While the driver seems to interact with the device ok, i have found that the temperature that temper.c prints out to be approximately 5C too high. When I use the windows software included with the dongle, the temperatures reported are accurate. Can i fix this simply by manipulating the following:
temperature += 1152; // calibration value
in TemperGetTemperatureInC() ? What does this value represent? I’d also appreciate if you could shoot me your email address so that I can send along an unrelated patch. Thanks.
February 19, 2010 at 5:41 am |
Thanks for the feedback.
The PC program that I received from the manufacturer had a field called something like “calibration value” that was defaulted to 5C. I asked the manufacturer why one needs this 5C offset and they could not explain it to me. I found that I needed this same offset for my device to report accurate temperatures. It is possible that this calibration value is different from batch to batch. Perhaps the manufacturer got a batch of bad parts for the first run of this product and have now fixed the problem? If you have a dump of the eeprom you can post then I can see if there is a check to determine whether to add the 5C or not automatically.
February 19, 2010 at 6:22 am |
I use an Temper V3 (-40 to +120 degrees) and an HIDTemperHUM. When measuring, the Temper is exactly 4 degrees higher than the hidtemperhum (e.g. 15.56 to 19.56 degrees in the attic)
February 24, 2010 at 3:35 pm |
I had to remove the calibration temperature…
The 1152 this value is multiplied by 125 and divided by 32000 which represents 4.5
Without that calibration value, the temperature matches the other thermometer standing next to the temper…
March 15, 2010 at 2:47 pm |
I have buy recently a TEMPer HID and the drivers not work.
The hardware has changed and there some minor modification.
I have use usb sniff under windows and have noticed:
The command send to launch getTemperature is still 0x54.
But the two bytes result is the temperature in the good format.
There is no conversion to make.
The first byte is the value in degrees and the second is the value after the comma with a 256 bit precision+one.
So the function must changed to
int
TemperGetTemperatureInC(Temper *t, float *tempC)
{
char buf[256];
int ret, temperature, i;
TemperSendCommand(t, 10, 11, 12, 13, 0, 0, 2, 0);
TemperSendCommand(t, 0x54,0, 0, 0, 0, 0, 0, 0);
for(i = 0; i < 7; i++) {
TemperSendCommand(t, 0, 0, 0, 0, 0, 0, 0, 0);
}
TemperSendCommand(t, 10, 11, 12, 13, 0, 0, 1, 0);
ret = TemperGetData(t, buf, 256);
if(ret < 2) {
return -1;
}
*tempC=buf[0]+((float)buf[1])/256+1;
return 0;
}
I test with linux and windows at get the exact same value.
So just another point.
There is a other stuff function. I have see that is called one times at the beginning of the software. I have test with a lot of condition and the value dont changed I think that is a serial number or a serial of firmware to detect all the version that exist.
I have see too that the TemperSendCommand(t, 0, 0, 0, 0, 0, 0, 0, 0); is send 7 times in the sniff log. So the executable call seven times in linux too. It's still continue to working great without. So i think this is not fondamental or deprecated.
March 20, 2010 at 7:29 am |
Being a newbie to linux, how do I install the temper software?
March 26, 2010 at 4:35 pm |
Works like a charm for me too on Ubuntu 9.10. The source code is clean straight forward and I really appreciate the support you’ve gave here.
May 3, 2010 at 6:27 pm |
Awesome!!! Works perfect for me.
Tested with ubuntu 9.10 x86_64 ans ydl ppc_32bit
Thank you!!!
May 6, 2010 at 4:16 pm |
Got your program running fine on a Bifferboard (very small embedded system, i486 based SOC – running Slackware 13, kernel 2.6.32).
Had to change it as per mastergb suggestions to get a correct readout for my TEMPer HID.
Thank you very much!
May 16, 2010 at 11:33 am |
Small but crucial addendum to the comment from mastergb:
I noticed a couple of times per day that for a while the reported temperatures were around 1 degree C to high.
I traced this down to the fact that the buffer that relavak’s program reads data in is declared as ‘char’ where it should be ‘unsigned char’.
(Note that the sending buffer is already declared as ‘unsigned char’.)
For some reason a dump of the raw data for buf[1] (decimal fraction of the temperature) produced for instance ‘ffffffb0’ instead of ‘b0’ giving a negative fraction.
With the declaration of ‘unsigned char buf;’ the correct formula for the conversion to temperarure should be:
*tempC=buf[0]+((float)buf[1])/256
(i.e. not adding 1 to the result).
The results are then in line with utac and an analog thermometer.
Ernst
May 16, 2010 at 6:05 pm |
There may be an issue with your formula in that you cannot get negative numbers. A simpler conversion would *tempC = ((buf[0]<<8) + (buf[1] & 0xFF))/256.0;
May 16, 2010 at 9:10 pm
Sorry if I didn’t make it clear; it is *not* the formula that causes the problem. It is the read data itself. The value in buf[1] becomes negative so that the formula *thereafter* miscalculates the temperature.
I left the program running in a loop for a while with a printf(“%02x – %02x”, buf[0], buf[1]) statement *before* the formula.
And it printed for instance for a long while:
10 – B0
10 – B0
10 – C0
which is correct; first the temperature in hex (16 degrees) and then the fraction, for instance B = 11 x 0,06125 degrees giving 16,67 degrees (yes, it is May but still cold here in The Netherlands). Exactly the temperature utac on a Vista notebook also reports using a different TEMPer held close to the first one.
And then suddenly, out of the blue the program prints:
10 – ffffffB0
10 – ffffffB0
etc.
Which is the same fraction but presented as a negative number (integer).
It prints ok and does not cause any problems because by C convention a char is always promoted to an integer in a printf statement.
Again; just adding the explicit ‘unsigned’ to the declaration of ‘char buf’, cured the problem.
This is also confirmed by some other code I saw for the TEMPer where both the receiving and sending buffer were declared as unsigned char.
Why this happens is beyond me, i.e. why the sign of the value of buf[1] changes suddenly and is then maintained for a while (sometimes hundres of TEMPer readings – 1 every minute – until it changes back to a positive number hours later is very, very weird. Must be some bug somewhere…
So again; excplicitly declaring the buffer as unsigned char cured the problem… not changing the formula.
May 16, 2010 at 11:28 pm
Sounds like you got bigger problems if your computer is randomly either sign extending or not sign extending.
May 17, 2010 at 7:42 am |
Ernst > you’re right, about not adding 1 in the formula. When i tested that my office had a temperature that swapped a lot. So to have a better compatibililty i have found that add 1 was the best solution but have changed it because in a non variant environnement its’ not true.
Relavaks as right declared unchar buf is not a good idea because you have not the negative temperature
The formula is correct or not because we dont known how the temperature is coded.
The cast float convert the char buf[1] in float but if it’s > 128 the value become negative and the precision van be never negative….
In this case the correct formula must be in positive temperature.
*tempC=buf[0]+((float)(unsigned char)buf[1])/256;
and if buf[0] negative
*tempC=buf[0]-((float)(unsigned char)buf[1])/256;
The other way is that buf[0] are int and buff[1] the precision signed.
Buf[1] can be negative so when we vant a value of 16,8 for example we have 17 -0.2
the correct formula for this is:
*tempC=buf[0]+((float)buf[1])/256
I cant’t test it because my HID are in production. But the better way to known is to try in negative temperature.
To response of ” 10 – ffffffB0″ i think that’s strange because it’s unsigned char and must not print that. Try to memset zero before get value.
May 17, 2010 at 4:23 pm |
Ok. Thanks for the clarification.
On the group for the bifferboard (the embedded system the TEMPer is connected to) someone noted that the bifferboard has no FPU so it does emulation. There might be some error in that code.
Yes, by declaring the read buffer as unsigned I cannot read negative temperatures anymore I guess, but that is not a problem for measuring my inhouse temperature.
So the best way is to test whether buf[0] is positive or not and then use the proper formula. But this is all guesswork since we indeed do not know 100% how the TEMPer works. I believe the HIDFDll.dll that the manufacturer distributes need to be disassembled to find out.
I am curious, so I will try and see what happens with the data reported if I put my TEMPer in the refrigerator for a while… 🙂
If I find more info on this problem I will let you all know.
May 17, 2010 at 5:27 pm
Just checked after having put my TEMPer in the fridge for a while;
buf[0] = f3
buf[1] = d0
i.e. minus 13 degrees and some fraction, either added to the minus 13 or subtracted; we don’t know at this moment.
So yes, with declaring unsigned char buf, this will translate to around 243 degrees centigrade, instead of -13.
November 3, 2010 at 8:58 pm
Note that on ARM systems such as the bifferboard, char is unsigned by default whereas it is signed on most systems. We need a signed char for buf[0] and unsigned for buf[1] so a cast or two is needed.
Seems odd that the old code was multiplying by 125/32000 instead of simply dividing by 256.
With regard to your figures for the fridge, I doubt that the fraction is subtracted instead of added when the temperature is negative because that’d make it impossible to represent temperatures between -1 and 0. It’s easy to confirm by watching the figures as it gets warmer.
May 18, 2010 at 10:54 am |
Hi Guys,
I’ve picked up on this thread as I have just received a few Temper units to play with (marked Temper1). My plan is to monitor the air temp in an IT office that also contains a rack of servers and some other kit. During the day we turn off the aircon and rely on natural ventilation (saves power and we don’t freeze in the cold airflow!), but sometimes we forget to switch the unit back on when we lock up! As well as emailing me about temp issues, I hope to program a USB-interfaced IR transmitter to turn the aircon back on and I have a learning IR unit on order from the USA (I’m in the UK) from these guys:
http://www.seeedstudio.com/depot/usb-infraed-toy-p-607.html?cPath=61_68
Just thought I’d mention it in case it was of use to anyone around here.
Regards
Nigel
May 18, 2010 at 3:01 pm |
Hi!
I had Ubuntu 9.10 and this drivers works perfectly. Last week I update my system to the new Ubuntu 10.04, and the binary drivers works only with sudo and the temperature showed is always in steps of 0.5ºC (before I have more decimals and accuracy). What happend?
Anyone with my problem? Some solution?
Note: my NSLU2 with Debian and 2.6.26-2 works perfecly.
Thanks
May 18, 2010 at 8:30 pm |
If sudo is required the security settings for 10.04 are apparantly tighter than for 9.10 or you have not installed the udev rule for the the temper program; in that case (as root) do a ‘make install’ in the temper-1.0 directory.
The TEMPER devices tend to loose their 12-bit resolution when powered off – not always but sometimes.
The program by relavak does not contain the command to reset the resolution to 12-bit (i.e. 0,0625 degrees or 1/16 degree).
The code for this would be (to be inserted before the first TemperSendCommand:
TemperSendCommand(t, 10, 11, 12, 13, 0, 0, 2, 0);
TemperSendCommand(t, 0x54, 0, 0, 0, 0, 0, 0, 0);
TemperSendCommand(t, 0x43, 0, 0, 0, 0, 0, 0, 0);
for(i = 0; i < 7; i++) {
TemperSendCommand(t, 0, 0, 0, 0, 0, 0, 0, 0);
}
TemperSendCommand(t, 10, 11, 12, 13, 0, 0, 1, 0);
The extra 0x43 sets the resolution to 12-bit instead of 10-bit.
Ernst
May 18, 2010 at 8:14 pm |
David,
Could you (or someon) post an outline of how you built and installed the drivers?
thanks,
bil
May 18, 2010 at 9:06 pm |
Hi all,
Reading with interest all your successes with the TEMPer….has helped me somewhat in trying to get to grips with what I am trying to achieve but still a little unsure…..hopefully someone can help.
I’m trying to interface a TEMPer1 with a Vinculum VDIP2 USB controller connected to an Arduino.
I can so far get it to regcognise that there is a device connected etc. however I’m stuck at what to ‘send’ to get it to spit out some data.
mastergb above has the closest thing that I think I can use:
int
TemperGetTemperatureInC(Temper *t, float *tempC)
{
char buf[256];
int ret, temperature, i;
TemperSendCommand(t, 10, 11, 12, 13, 0, 0, 2, 0);
TemperSendCommand(t, 0×54,0, 0, 0, 0, 0, 0, 0);
for(i = 0; i < 7; i++) {
TemperSendCommand(t, 0, 0, 0, 0, 0, 0, 0, 0);
}
TemperSendCommand(t, 10, 11, 12, 13, 0, 0, 1, 0);
ret = TemperGetData(t, buf, 256);
if(ret < 2) {
return -1;
}
*tempC=buf[0]+((float)buf[1])/256+1;
return 0;
}
I have to send data serially to the VDIP which then converts it ready to send to the USB device using the command:
DSD i
xx yy zz xx yy zz
where i is the total number of bytes (72?? from the example above) and then the string of data (xx yy zz xx yy zz ).
Is it a case of just sending each byte of data above in the example? Is there anything else required to 'initialise' the TEMPer? or is it just then a case of 'waiting' for a response.
Many thanks,
GS
May 19, 2010 at 4:13 pm |
To be precise; we don’t know exactly. The strings to send to the TEMPer devices have been reverse enigneered from the Windows software that comes with the device.
I reckon you need to send the 10 commands of 8 bytes each more or less in one go, not as seperate 80 bytes. But perhaps it will work.
First 8 bytes is selecting the device, second 8 bytes is the request to send data, next 7 commands of 8 bytes is padding to clear the i2c bus as per the Philips i2c spec, last command of 8 bytes it to close the device.
I am unsure whether the device has some sort of buffer so that the requested data remains available for a longer time… could be that you have to read the data in some time period after the 80 bytes have been sent.
After having given the 10 commands it is a matter of just reading bytes (minimum two bytes) from the device. First byte is temperature in degrees, second byte is the fraction in 1/16 of a degree.
This ofcourse is only valid for the latest HID TEMPer device with built-in temperature sensor. The commands for other types of TEMPer are different…
May 19, 2010 at 10:50 pm |
thanks Ernst…..will probably also have to do another snoop as the device I have has a remote sensor on a lead also (unless someone here has recently done similar?) GS
January 26, 2013 at 5:51 am |
Dear Arduinocoder,
Did you ever get comfortable with running the TEMPer device on arduino? I’m considering doing the same and would like to hear how you did it.
May 23, 2010 at 9:55 pm |
There is an offer on eBay at the moment for second-hand Digi Watchport/H temperature/humidity sensors, complete with USB1-wire converter box.
Bought one of these since these are far more professional so I trust it a lot more. Turns out both the HID TEMPer devices I compared it with report temperatures around 1.5 degrees C too high. So I updated my graphs to compensate for this.
I guess this is caused by internal heating of the TEMPer itself due to the HID USB chip and eeprom in its very tight housing.
Anyone else experience with the actual accuracy of TEMPer devices?
May 23, 2010 at 9:57 pm |
Forgot to mention; these 1.5 degrees C too high is not caused by a wrong calculation within the used Linux program… the error is already in the raw data.
June 5, 2010 at 9:38 pm |
Well, I’ve got my TEMPer running beside a stand-alone digital thermometer ( http://stromboli.crumblenet.co.uk:10080/mrtg/temp.html ), and I can confirm that the values from the TEMPer are roughly 1 degree C higher than the readings on the stand-alone unit.
Of course, it could well be that the stand-alone unit is under-reading, as neither is properly calibrated. It’s also hard to tell exactly how close the two are, as the Temper-Tools software only provides precision to the nearest degree.
May 25, 2010 at 7:37 pm |
I’ve run into bit of a problem, i’ve got another temper that has an internal and external thermometer, I tried changing
say $device->internal()->celsius();
to
say $device->external()->celsius();
but got
Can’t call method “celsius” on an undefined value at ./int.pl line 19, line 1.
June 3, 2010 at 6:42 pm |
Just browsing around for more info, and I discovered that http://www.pcsensor.com are now selling an RS232 version of the TEMPer, called TEMPer232, with the intention of allowing users to write their own applications for the device. The commands to access the device are given on the web site, but it also comes with a Linux driver, so there’s actually no need to write your own code 🙂
I’ve just ordered one 🙂
August 2, 2010 at 3:39 pm |
Well, the TEMPer232 device works, but unfortunately it has a *major* drawback. If the total cable length from the PC to the device exceeds 2 metres, it doesn’t work. Even at exactly 2m, it becomes very unreliable, so realistically it’s not possible to distance the device more than 1m from the host. Even using a USB Hub does not help – if the total distance from PC to Device exceeds 2m, it doesn’t work, regardless of where you put the hub.
So unless you happen to want to log the temperature in the room right beside your computer, they’re totally useless.
June 20, 2010 at 12:16 pm |
I did some more testing comparing the results from the HID TEMPer with a Digi Watchport/H (Dallas DS18B20 based which I trust a little bit more).
The difference between the temperatures reported by these two (with the sensors very close ofcourse) is not constant. At lower temperatures the difference is higher than at higher temperatures.
I analysed the results within Excel and using the Excel trendline function (which in a XY scatter graph gives the mathematical formula, lineair or polynomial that is closest to the data), I came up with a rather good formula for the range between 10 and 25 degrees.
The formula y = -0,0535x + 2,1717 is a close estimate for the difference between the two sensors.
So a calculation of:
c = (get TEMPer temperature)
c = c – ((-0,0535 * c) + 2,1717)
calibrates the TEMPer rather close in the mentioned temperature range to the Watchport/H.
The fact that at lower temperatures the TEMPer is some 1.5 degrees too optimistic and at higher temperatures this goes down to 0.8 degrees to my opinion gives proof that the internal heat from the HID controller within the TEMPer causes this.
Ernst
July 9, 2010 at 11:11 am |
Out of curiosity I disassembled one of my HID TEMPer devices. It contains three IC’s, a LED, a 6 MHz. crystal and some resistors and capacitors.
Although the identifications of the IC’s have been sanded off, it is obvious that the larger IC is a TENX TMU3101 or T66P06. I count on the latter since the device ID of a TEMPer is 660C which sounds familiar. This chip is meant to interface serial/parallel data to an USB port using the Human Interface Device protocol. Datasheet on the tenx website. Intended as a chip for mice, keyboards, joysticks and the like.
The temperature sensor probably is an ADT75 or equivalent 12-bit device. The other 8-pin IC seems to be an 24LC01 or equivalent i2c 128 byte eeprom. Its input is the data from the temperature sensor, its output is connected to the hid chip.
The eeprom probably acts as temporary storage for temperature data from the sensor as a kind of buffer so that the hid chip doesn’t have to control the sensor to find out whether new data is available; it simply reads the eeprom.
Funny to see that the circle painted on top of the TEMPer is not the location of the sensor at all. The sensor is located on the other side near the end of the stick. Also; the stick contains a blob of silicone rubber inside as a sort of insulation or way to avoid opening it (that didn’t work 🙂 between the sensor/memory and the aluminium housing.
With the housing removed the TEMPer is more sensitive to temperature changes; where a temperature curve was flat for hours it now fluctuates a bit more.
Without the housing the TEMPER is even more optimistic on the actual temperature than the digi Watchport/H next to it; previously the difference came to about 1.5 degrees C in the 20 degree C range down to 0.5 degrees in the 30 degree C range; the difference now seems to be a more constant 1.5 degrees C over the total range.
The PCB has two solder points for connecting another sensor. I’ll try and solder an DS18B20 to these spots and see whether the device is then capable of reporting two temperatures like the equivalent two-sensor TEMPer device.
Lots of fun but not a lot of hacking potential 🙂
July 19, 2010 at 9:14 am |
Ernst let me know how you get on as I love to get both sensors on my thermometer working.
July 21, 2010 at 9:28 am |
Hi,
thank you for your programm. The calculation of the humidity contains an error. Here is the fix:
// wrong calculation of himidity:
// *relhum = 2.0468 + 0.0367*rh – 1.5955e-6*rh*rh;
// correct calculation like sensirion datasheet tells:
float c1 = -2.0468;
float c2 = 0.0367;
float c3 = -1.5955e-6;
float rhLinear = c1 + c2*rh + c3*rh*rh;
*relhum = (*tempC – 25.0)*(0.01+0.00008*rh)+rhLinear;
August 3, 2010 at 2:03 pm |
I bought a Temper from dealextreme (sku.7003), this was the HID version without humidity sensor.
I compared what the Relavak program was doing to what the windows app was doing, and made a few changes:
– the windows app delayed 500ms after the 7 repeated commands and before the final command; the C source was doing a 400ms delay *after* the final command
– the first byte of the output is the degrees centigrade; the second byte is 0x80 if 0.5 degrees should be added (it ‘s zero otherwise). So no addition / mulitplication…
– I removed all the humidity code as this unit has no sensor for that (and the USB dump showed no relevant data).
August 18, 2010 at 9:33 pm |
Valarie asks what kind of error one gets using her code at http://github.com/jeixav/HID-TEMPerHUM. I have just downloaded and built it and consistently get the following results
>sudo ./temper
-39.71 -4445.23
From the above I take it that the -39.71 is the base number in Valerie’s code so presume the key is returning zero.
August 18, 2010 at 10:21 pm |
Ok I tried Robert’s version and this works. Like Mike Brown I found that I got more accurate readings if I commented out the calibration line
temperature += 1152; // calibration value
(although even with this I run a bit hot). I am going to see if I can get the HUM code from Valarie’s version integrated and working here.
August 30, 2010 at 4:57 am |
Has anyone managed to get the version with the extra external sensor on the end of a wire working?
September 1, 2010 at 8:49 am |
Hi.
Take a look at my code: http://cpansearch.perl.org/src/MSULLAND/Device-USB-PCSensor-HidTEMPer-0.0201/lib/Device/USB/PCSensor/HidTEMPer/NTC/External.pm
August 31, 2010 at 3:21 pm |
I too second that request. How to read external sensor temperature of HIDTemperNTC in linux?
I can read internal, but not external.
Thanks for the answer.
September 1, 2010 at 8:48 am |
Hi.
The answer to your question about reading the external HidTEMPerNTC can be found in my Perl-driver.
http://cpansearch.perl.org/src/MSULLAND/Device-USB-PCSensor-HidTEMPer-0.0201/lib/Device/USB/PCSensor/HidTEMPer/NTC/External.pm
September 1, 2010 at 4:08 pm
Well. Its not an easy answer. I can’t convert your code in C language. It just doesn’t work.
September 14, 2010 at 5:52 am
I am strill trying to somehow implement your solution in C language but can’t make it work.
I tried your Perl script and its not running either:
Number found where operator expected at /usr/lib/perl5/site_perl/5.8.8/Device/USB/PCSensor/HidTEMPer/Sensor.pm line 96, near “return ( ( $celsius * 9 ) / 5”
(Might be a runaway multi-line // string starting on line 93)
(Do you need to predeclare return?)
Global symbol “$celsius” requires explicit package name at /usr/lib/perl5/site_perl/5.8.8/Device/USB/PCSensor/HidTEMPer/Sensor.pm line 93, line 1.
syntax error at /usr/lib/perl5/site_perl/5.8.8/Device/USB/PCSensor/HidTEMPer/Sensor.pm line 96, near “return ( ( $celsius * 9 ) / 5”
Compilation failed in require at /usr/lib/perl5/site_perl/5.8.8/Device/USB/PCSensor/HidTEMPer/NTC/Internal.pm line 6, line 1.
BEGIN failed–compilation aborted at /usr/lib/perl5/site_perl/5.8.8/Device/USB/PCSensor/HidTEMPer/NTC/Internal.pm line 6, line 1.
Compilation failed in require at /usr/lib/perl5/site_perl/5.8.8/Device/USB/PCSensor/HidTEMPer/NTC.pm line 7, line 1.
BEGIN failed–compilation aborted at /usr/lib/perl5/site_perl/5.8.8/Device/USB/PCSensor/HidTEMPer/NTC.pm line 7, line 1.
Compilation failed in require at /usr/lib/perl5/site_perl/5.8.8/Device/USB/PCSensor/HidTEMPer.pm line 8, line 1.
BEGIN failed–compilation aborted at /usr/lib/perl5/site_perl/5.8.8/Device/USB/PCSensor/HidTEMPer.pm line 8, line 1.
Compilation failed in require at test.pl line 1, line 1.
BEGIN failed–compilation aborted at test.pl line 1, line 1.
Can somone please help me get a reading of external sensor using C language under linux?
Thank you.
September 17, 2010 at 4:08 am |
[…] Este eu utilizo na sala de servidores no meu trabalho para medir a temperatura ambiente. Muito útil. Uso um shell para me avisar caso alguma coisa errada aconteça com os aparelhos de ar condicionado. Extremamente sensível. Para Linux há este driver (que estou tentando aprimorar): https://relavak.wordpress.com/2009/10/17/temper-temperature-sensor-linux-driver. […]
September 24, 2010 at 7:42 pm |
It might be worth mentioning that it needs the 32-bit libraries installing (ia32-libs) on Debian amd_64 at least. Otherwise I get ‘libusb-0.1.so.4: cannot open shared object file: No such file or directory’ even though it’s in both /lib and /usr/lib
Other than that, great. Thanks.!
October 14, 2010 at 10:41 am |
[…] […]
October 26, 2010 at 12:16 pm |
thanks for the nice little program, it works without any problems. one little question, my temperature readings are a bit higher than they should be. the readings on the termostat (is that an english word ?)give me 20.5 degrees celcius, temper gives me 25 degrees celcius. i suppose this is a callibration issue ?
jef
October 26, 2010 at 4:04 pm |
Yes. I add 4.5 degrees in the software to match the software that came with the TEMPer. I think the maker has fixed this calibration issue in newer parts so you can remove that line in the code.
October 26, 2010 at 6:09 pm
thanks relavak,
that fixed it, seems that the newest devices have a good calibration.
cheers
jef
November 25, 2010 at 10:17 am
I had a problem with the sensor not getting below 4 Celsius no matter what the temperature was (which was a problem as it’s supposed to be monitoring snow conditions for the local ski club!)
As I don’t know C, I just deducted -4.5 in the last line of the calculation. It seems to have not only fixed that but allowed the sensor to record the temperature in 0.01 Celsius rather than rounding it to the nearest degree that it did previously.
November 3, 2010 at 7:25 pm |
Hi,
thank you for this nice solution, works fine, the code is well writen, this makes it easy to adopt it to my needs. Thank you for supporting the community by making your code public.
November 4, 2010 at 9:31 pm |
Hi I have written a kernel driver for the temperhum device. It’s limitation is that you have to disable USBHID or find a way to stop it claiming the device. Other than that, it adds two files to your file system /dev/th/t and /dev/th/rh for temperature and humidity. It will output centegrade or fahrenheit. Check out https://github.com/dpstorey/temperhum. Any improvements or suggestions gladly welcomed!!
Dominic
November 25, 2010 at 6:57 pm |
Hi,
I had a look at the USB logs from a temperNTC and modifying the TemperGetTemperatureInC function slightly seems to work. Here’s my code:
—
int
TemperGetTemperatureInC(Temper *t, float *tempC)
{
char buf[256];
int ret, temperature, i;
static int initialized = 0;
// CMD issue -> reset
if (!initialized)
{
TemperSendCommand(t, 0xa, 0xb, 0xc, 0xd, 0, 0, 2, 0);
TemperSendCommand(t, 0x43, 0, 0, 0, 0, 0, 0, 0);
for(i = 0; i get inner (or outer?) temp
TemperSendCommand(t, 0xa, 0xb, 0xc, 0xd, 0, 0, 2, 0);
TemperSendCommand(t, 0x54, 0, 0, 0, 0, 0, 0, 0);
for(i = 0; i < 7; i++)
TemperSendCommand(t, 0, 0, 0, 0, 0, 0, 0, 0);
// Query data
TemperSendCommand(t, 0xa, 0xb, 0xc, 0xd, 0, 0, 1, 0);
ret = TemperGetData(t, buf, 256);
if(ret < 2) {
return -1;
}
temperature = (buf[1] & 0xFF) + (buf[0] << 8);
temperature += 1152; // calibration value
*tempC = temperature * (125.0 / 32000.0);
return 0;
}
—
The readings look valid, but I haven't got any way of verifying them at the moment.
Hope that helps someone,
Dave.
December 17, 2010 at 10:47 pm |
Could you provide youre code fpr TemperNTC.
My internal sensor in working, but external is not.
You can send the code on my mail. (sebek.mac @ gmail.com
Thank you
November 29, 2010 at 3:45 pm |
There must be some errors in the posted source.
For example:
for(i = 0; i get inner (or outer?) temp
Where begins the comment?
—
Jochen
November 29, 2010 at 6:57 pm |
Yeah, this website messed up the code.
Additionally, I discovered that the above code only worked on the inner sensor. I’ve since tweaked the code to work on the outer sensor.
I don’t want to post the code on here and deal with it being messed up, and I don’t want to post my email address, but if you can work out some other way of posting it then you’re more than welcome to it!
Dave.
November 29, 2010 at 7:23 pm |
You can send it to ftp://ftp.hin.de/ for me …
Anonymous ftp in /incoming
Thank you.
Is it possible to show internal and external temperature with your code?
December 20, 2010 at 9:23 pm |
Jochen can you provide the code that reads the external sensor on TemperNTC?
Thank you
December 21, 2010 at 2:19 pm
Yes, here it is:
ftp://ftp.hin.de/pub/Linux/temper.c
December 23, 2010 at 6:38 pm
Thank you!
November 30, 2010 at 12:10 pm |
Hi,
It should be in your incoming directory. There are very few changes from the original code, but the changes I’ve made are messy and a horrible hack. I didn’t have much time to look into this, so once it looked like it was working I left it alone.
The code no longer reads the internal temp, but it wouldn’t be hard at all to modify it to do that again.
Finally, the code might not actually work. It looks about right, but I’m not sure.
Good luck.
November 30, 2010 at 12:37 pm |
I got the code. Should I make it available for everyone?
But the program reports -7.13°C internal and 23.03°C external.
It should be the same temperature and it should be about 0°C …
Jochen
November 30, 2010 at 1:46 pm |
hi,
My code only printed the external temperature. I think I left a misleading function in there for reading the internal temp but it won’t work – I guess you were using that!
I have no idea about the TEMPer1 product. I’d suggest you run it under Windows with the supplied software and intercept the USB traffic, like relavak initially did.
Dave.
November 30, 2010 at 12:42 pm |
Oh, btw my Device is a “TEMPer1”:
http://www.pcsensor.com/index.php?_a=viewProd&productId=49
November 30, 2010 at 1:22 pm |
I just discovered that my Device should only have the external sensor …
I was sure that I had read somewhere that it has two sensors …
Did you know this project:?
http://www.evillabs.net/wiki/index.php/Project_usense
That did work for me …
December 5, 2010 at 8:32 pm |
I did some modifications on the code to read temperature from more than one device. The trick is to select a specific device on the usb-bus, each device on the usb-bus has a unique “address” composed of “bus” ID and “device” ID. Here is the relevant chunk of code (part of the scan-loop in TemperCreateFromDeviceNumber):
strcmp (bus->dirname, busnum) == 0 &&
strcmp (dev->filename, devnum) == 0)
busnum is a string, eg. “003”, devnum is another string, eg “005”;
Together with some additional comman-line parsing it is then possible to print a list of available devices togehter with their bus/device ID and to read the temperature from a specific device.
You can find the modified code at http://zlabinger.at/temper_dz.tar.gz
December 15, 2010 at 7:05 pm |
I’ve installed the linux driver from:http://cpansearch.perl.org/src/MSULLAND/Device-USB-PCSensor-HidTEMPer-0.0201/
I hav a temperNTC…but how can i read the data from it?
Thanks
December 19, 2010 at 4:29 pm |
Has anybody been able to read external TemperNTC sensor?
I’ve thried perl code but it doesn’t work for me…
Can some one provide a working Temper.c for TemperNTC?
Thank you
December 20, 2010 at 9:16 am |
Great driver relavak! I’m using the jeixav version for my temperhum device. I was thinking about to get more temper devices, could you please tell me if the driver can get info from several ones?
Thanks again!
December 20, 2010 at 5:06 pm |
Yes. The call to TemperCreateFromDeviceNumber allows you to specify a deviceNum, which is an index (0, 1, 2, …) of matching devices. The usb subsystem in general has a very poor way on handling multiple devices with the same vendor/product id. You could write your own version of TemperCreateFrom… to match against serial number or specific bus id and device on bus.
December 22, 2010 at 7:54 pm |
I’ve just acquired a TEMPer with an external and internal sensor, and have read through this thread.
My findings and current problems are:
Running the example programs I’ve found that what works as my “internal” sensor is the one connected to a wire, and the “external” is the one inside the TEMPer unit.
Using the C program I got an “internal” temperature of -7.5C, this is almost 5 degrees to high. Commenting out the +=1152 line returned -11.75C, which seems to be pretty accurate. My reference thermometer (of unknown quality says -12.5).
Using the version linked to by Jochen Pawletta I do get a readout from the “external” sensor which seems reasonable. Uncommenting the internal sensor gave incorrect readings.
I also tried the Usense program linked to by Jochen, and it reads my internal sensor ok, I do not believe it can read the external sensor? The reported temperature is -13.74C, which I believe is too cold.
I’ve also tried the Perl module. Only reading the internal sensor seems to work for me and it reports +244.28125C. This is probably due to using the wrong datatype, as per Ernst’s message about “unsigned char buf”.
December 29, 2010 at 3:00 pm |
Just bought one of these. The windows cd that comes with it is useless. The install program displays wacky messed up text and crashes.
Here are some tips for newcomers:
I got it working with the default HID/usb input device drivers supplied by Windows, but the process was not automatic. You have to right click “PC Sensor” under Other devices and then click “update driver”. Choose browse, Point it at “\Windows\Inf” and it will pick up on the default input.inf file… It will then add a “USB Composite Device”. And at this point you will have another “PCSensor” under Other devices. Repeat the process, by right clicking and updating the driver from \Windows\Inf. This time you will get a “USB Input device”. You can then run UTAC. You can repeat this process a 3rd time to get another “USB Input Device”, which I assume is the internal temperature sensor, but I’m not sure… I’ve only been able to get the wired temper1 sensor to read, although there is supposed to be one inside the usb plug in as well…
January 16, 2011 at 9:56 pm |
Is there any way (command code) to alter the inbuilt calibration values?
I have two Temper1 devices. The first is about a year old, gives readings
that are 5.8 degC too low, and has internal calibration value (23,0). The second is brand new, gives readings that are already correct to nearest 0.1 degC, and has internal calibration value (20,0). (I get those values via
command code 0x52.) Are those calibration values things I can alter?
January 17, 2011 at 12:10 pm |
(Actually my devices are Temper not Temper1 — the simple ones with
a single internal sensor)
February 8, 2011 at 4:14 pm |
After fuffing about 2 days with various Kernel based drivers, had it working now within approx. 5 seconds!! THANKS!
(I will use the Temperature sensor in a temperature sensitive soundscape and hence probably use your driver as part of the c++ thing I write for it, using UGen++)
March 17, 2011 at 4:06 pm |
Hi Dom,
Could you elaborate on how you got it to work? Which kernel and drivers are you using?
February 9, 2011 at 10:13 am |
Has anyone managed a working driver for both internal and external sensors of this product http://www.pcsensor.com/index.php?_a=viewProd&productId=49 if so a quick install guide would be greatly appreciated.
February 19, 2011 at 11:49 pm |
Hello All
Just reading though the above….. slightly confused…
Is there are consensus on the correct formula for working out the temperature correctly?
Thanks
February 20, 2011 at 1:39 am |
The original code is quite old now compared to hardware that is shipping. The first round of hardware was off by about 4.5 degrees, hence the adjustment in the software. The newer hardware seems to have fixed that problem, so you should remove 4.5 degree adjustment. Since this software is not from the manufacturer, I recommend testing the actual unit that you buy any adjustments that might have to be incorporated.
February 22, 2011 at 1:58 am |
Does anyone have a software with source code that will read 4 USB Temper devices via Visual basic or vb.net?
February 27, 2011 at 2:34 pm |
I have the following;
http://www.pcsensor.com/index.php?_a=viewProd&productId=27
I would love to be able to get both internal and external temps.. the windows software does this nicely, but I have spent hours trying to get this working…
March 1, 2011 at 7:28 am |
Would it be possible for someone skilled enough to compile this code as a dll for Windows? I’ve got HidFTDll.dll for Win, but without any documentation I can’t figure out how to read temp. and hum from the HID TEMPerHUM.
April 4, 2011 at 10:42 pm |
Hi,
I try to have multiple TEMPer devices connected to a linux box.
Some are connected directly on the usb ports and some thru usb->cat5 extenders.
Is it possible to seperate each TEMPer device..
like usb1 is the living room, usb2 is basement, usb3 is garage etc?
April 5, 2011 at 11:39 am |
Does anyone know about TEMPer2 driver for Ubuntu 10.04
I use temper binary, it works, but shows only internal sensor temperature.
How can I modify sources to show external sensor data or both sensors?
thanks)))
April 14, 2011 at 8:07 pm |
Hi all,
Great driver Relavak, i have it working with me eTRAYz, but when i run the application it spits out 10 “sending bytes” lines followed by the temp in both F and C.
Is this the correct way for the app to be run? or should I be doing something different?
Sorry for being so thick 🙂
Thanks,
Dom
April 15, 2011 at 1:29 am |
The driver is meant to be a start for whatever you might need. It does the basics. Feel free to modify it to suit your application.
April 15, 2011 at 8:13 am
Hi Relavak,
Thanks now I understand, have editied it as required.
Great app! Well done! 🙂
Regards,
Dom
April 15, 2011 at 8:37 am |
Hi All,
Can anyone suggest a simple open source graph tool? Say read a log file and print a graph accessable via a webpage? The smaller the better as it’s to run on my little eTRAYz linux NAS box.
Thanks,
Dom
April 15, 2011 at 8:44 am |
What about munin?
http://munin-monitoring.org/
Jochen
April 26, 2011 at 8:28 pm
Hi Jochen,
Thanks for the heads up. I’ll have a look into this Munin.
I’ll post back once I have something sorted.
Regards,
Dom
April 17, 2011 at 9:45 am |
Hey…I’m also using it with etrayz. THJ wrote a script that does the graphing. Find it on his forum section.
I have TemperNTC, but can’t read the external sensor. Not very good at C 🙂
Whitch device are you using?
April 26, 2011 at 8:27 pm
Hi Sebek,
Thanks for you’re reply. Sorry in getting back to you.
I’ll have a look for THJ thanks. I have the TEMPer1 unit, works like a treat! Might get another so I can monitor the temp of the fish tank! 🙂
Regards,
Dom
April 26, 2011 at 9:12 pm
Hi Sebek,
Great thanks for the heads up cant believe THJ had already done this and it was staring me in the face! lol! Anyway i think i have it outputing the correct temp with version 0.42 just need to work out how to get the graph to work.
For anyone else interested here’s the url to the forum:
http://forum.xtreamer.net/topic/13685-usb-thermometer-reader-package-discussion
Thanks,
Dom
April 30, 2011 at 6:43 pm |
His version works with my temperNTC and does graphing too. Only the external sensor doesn’t read any data.
May 10, 2011 at 10:49 pm |
I’d love to make one api that works with all devices, or even an hwmon kernel driver. I think the key in deciphering features and calibration values lies in the “Other Stuff.”
Would it be possible to get people to Reply and post their device name, features, and “Other Stuff”?
I’m particularly interested in relavak’s “Other Stuff” because we both have a temper 1, but mine (and most it seems) don’t require extra calibration.
The Other Stuff for my Temper 1 is:
57 58 14 00 14 00 53
followed by 00s
It only has the internal sensor and doesn’t need the 4.5C adjustment.
May 16, 2011 at 11:22 pm |
where can i buy the TEMPer and what is a good price for it?
June 4, 2011 at 1:38 am |
Relvak,
I just wanted you to know that I have posted a modified version of the TEMPer driver for Linux on my website. It can be found at http://stevecross.org/wiki/doku.php?id=projects . This modified version has been tweaked in a way that it is easy to integrate with a SNMP server for pulling the temperature on a server using snmpget. Also, this allows for easy monitoring using Cacti. I really hope this is useful for someone!
Steve Cross
June 26, 2011 at 12:04 pm |
Hi,
I’m trying to port your driver to kernel space, but the problem is when I try to send some data to the driver using kernel usb_control_msg function, I get return value -32.
Following is my example code which always return -32:
286 static int temper_probe(struct usb_interface *interface,
287 const struct usb_device_id *id)
288 {
289 struct usb_temper *dev;
290 int rc = -ENOMEM;
291
292 dev = kzalloc(sizeof(*dev), GFP_KERNEL);
293 if(!dev) {
294 err(“Out of memory”);
295 return rc;
296 }
297 dev->udev = usb_get_dev(interface_to_usbdev(interface));
298 dev->interface = interface;
299 dev->timeout = USB_TIMEOUT;
300 usb_set_intfdata (interface, dev);
301
302
303 #ifdef DEBUG
304 char buf[64];
305 int actual_len;
306 memset(buf, 0x00, sizeof(buf));
307 //int rc2 = usb_control_msg(dev->udev, usb_sndctrlpipe(dev->udev, 0), 0x21, 9, 0x200, 0x01,
308 // (char *) buf, sizeof(buf), dev->timeout);
309 int rc2 = usb_control_msg(dev->udev,
310 usb_sndctrlpipe(dev->udev, 0),
311 0x12,
312 0xc8,
313 (0x02 * 0x100) + 0x0a,
314 (0x00 * 0x100) + 1,
315 buf,
316 8,
317 2 * HZ);
318
319 char message2[128];
320 sprintf(message2, “(temper_probe) returned (%d), expected (%d), idProduct=%0x, idVendor=%0x”,
321 rc2, sizeof(buf), dev->udev->descriptor.idProduct, dev->udev->descriptor.idVendor);
322 log_msg(message2, __LINE__);
323 #endif
In my log message I always get:
TEMPer.c:322 (temper_probe) returned (-32), expected (64), idProduct=660c, idVendor=1130
I’ve tried changing paramater, used usb_bulk_msg but still it’s not able to send data successfully, could you please have a look, I’ll be grateful.
Thanks for your help in advance.
ilnli
June 28, 2011 at 6:42 am |
If anyone can help, I’m trying to get the temper232 working on ubuntu. The kernel detects it, and loads the ch341 serial USB driver.
Kernel didn’t create a device for it, but I created an inode myself for /dev/ttyUSB0. So, ok.
According to (very limited) documentation, I need to just net to set the interface to 4800 baud, N/8/1 and write the magic sequence 24, 10, 05, 01, 01, 00, 32, 01, 55
And read back 24, FE, 02, HH, LL, 88, where HH LL is a magic number corresponding to temperature.
And indeed it works… but very rarely.
It’s as if I have some sort of flow control issue or something. Maybe 1 in 10 attemps I get back the desired output. But most of the time I’ll get either just 0x24 back or nothing.
If I try too frequently, I get back a different return sequence 0x24 0x90 0x1 0x0 0x55.
Every so often I get some garbage back ,but it’s usually one of these sequences.
I really have no idea where to go with this. Does anyone know where I can get either a truly working driver or some documentation that might help me document in more details the expectations of this device?
June 28, 2011 at 7:02 am |
I think you may need a delay between sending the command and reading a response.
June 28, 2011 at 5:51 pm
Hmm, since it’s serial shouldn’t the response just sort of come when its ready? Or is there something in that magic sequence “24, 10, 05, 01, 01, 00, 32, 01, 55” that is sort of saying “send the response now” so that I should delay part of the request? I’ve tried experimenting with various timing on sending the individual bytes of that request without a whole lot of success.
Thanks for the help
July 4, 2011 at 6:33 pm |
Hi
I’m trying to have this gadget working on my machines but so far I’m out of luck 😦
I’m able to compile and run your code, both on a Ubuntu 10.04 ans 11.04 machine, but the code end up with a “broken pipe” error.
The Temper1 is seen by the machine :
[25047.105154] input: RDing TEMPer2V1.0 as /devices/pci0000:00/0000:00:1d.7/usb2/2-3/2-3.2/2-3.2:1.0/input/input7
[25047.105270] generic-usb 0003:0C45:7401.0005: input,hidraw4: USB HID v1.10 Keyboard [RDing TEMPer2V1.0] on usb-0000:00:1d.7-3.2/input0
[25047.108465] generic-usb 0003:0C45:7401.0006: hiddev97,hidraw5: USB HID v1.10 Device [RDing TEMPer2V1.0] on usb-0000:00:1d.7-3.2/input1
Of course I did change the ID code in the program for my module.
Here what happens :
./temper
Found device: 1d6b:0001
Found device: 1d6b:0001
Found device: 04a9:2206
Found device: 1d6b:0001
Found device: 138c:0001
Found device: 1d6b:0001
Found device: 0a81:0205
Found device: 1d6b:0001
Found device: 1d6b:0001
Found device: 152d:2338
Found device: 0c45:7401
Found deviceNum 0
Trying to detach kernel driver
detach successful
detach successful
sending bytes 10, 11, 12, 13, 0, 0, 2, 0
sending bytes 82, 0, 0, 0, 0, 0, 0, 0
sending bytes 10, 11, 12, 13, 0, 0, 1, 0
Other Stuff (-32 bytes):
sending bytes 10, 11, 12, 13, 0, 0, 2, 0
sending bytes 84, 0, 0, 0, 0, 0, 0, 0
sending bytes 0, 0, 0, 0, 0, 0, 0, 0
sending bytes 0, 0, 0, 0, 0, 0, 0, 0
sending bytes 0, 0, 0, 0, 0, 0, 0, 0
sending bytes 0, 0, 0, 0, 0, 0, 0, 0
sending bytes 0, 0, 0, 0, 0, 0, 0, 0
sending bytes 0, 0, 0, 0, 0, 0, 0, 0
sending bytes 0, 0, 0, 0, 0, 0, 0, 0
sending bytes 10, 11, 12, 13, 0, 0, 1, 0
TemperGetTemperatureInC: Broken pipe
I tried also to remove the usbhid module and run temper in sudo mode.
No changes.
Any hints to find the problem ?
Thanks
STeve
July 5, 2011 at 7:43 pm |
Me too. Got mine delivered this morning, same exact issue as Steve.
July 5, 2011 at 11:04 pm
Same problem here. I tried to use SnoopyPro to listen to USB in windows.
How can I post the results of the SnoopyPro?
July 6, 2011 at 2:12 am
It seems they created another device .. uff.
I’ll try to analyze what the Windows drivers do with this as soon as I’ll have some time.
July 6, 2011 at 6:36 pm
It looks like there are updated files on their website. Trying to compile and run them now.
http://www.pcsensor.com/index.php?_a=viewDoc&docId=6
July 6, 2011 at 7:23 pm |
good… Will post results soon..
July 7, 2011 at 7:00 pm |
Hi,
I bought this device from deal extreme two weeks ago for use with mi linux, but when it came, i saw that there was not driver for linux, i asked to pcsensor about linux driver or usb protocol but i only got suppor for windows platform.
But as i want to use it in my linux, I wrote a little program based on temper-1.0.tgz for the pcsensor device with ID 0c45:7401 Microdia (the usb protocol has changed from other versions of sensor).
It have the next command line options:
pcsensor version 0.0.1
Aviable options:
-h help
-v verbose
-l[n] loop every ‘n’ seconds, default value is 5s
-c output only in Celsius
-f output only in Fahrenheit
-m output for mrtg integration
I leave here for the people who can need it.
http://www.isp-sl.com/pcsensor-0.0.1.tgz
Enjoy it.
Bye
July 7, 2011 at 9:20 pm |
Thanks…. I will try it today itself… I was waiting for something like this…
July 7, 2011 at 9:28 pm |
Brilliant! This worked perfectly. Thank you, Cray.
July 7, 2011 at 11:25 pm |
It works ! Great job.
There are only two problems and I’ll do more tests in the next days, they can maybe related to the hub or other USB problems.
Problem 1
Sometime the reading is totally wrong. Like 1.8 C instead of 25.
Problem 2
After some time (random) the sensor become unreadable.
It is necessary to unplug it and plug it back
Also it seems the TEMPer I have has two sensors, one internal and one external.
Would be great to be able to read them both.
But as I said is a great starting point !
Thank you Cray.
July 8, 2011 at 5:46 am
Hi,
My device only have one sensor, but modify the code to support two sensors may be easy. If you want, post logs generated in verbose mode, try to change temperature of second sensor while logs are generated.
I think that your device problems can be for a slow or saturated usb system, making a brief pause just after reading from device can solve the problem.
Bye
July 9, 2011 at 12:17 am
Tested on another machine, it works great !
It is probably the hub connected to the other machine that mess up.
July 8, 2011 at 2:26 am |
Thank you Cray, it worked…
July 9, 2011 at 3:18 pm |
Hey thanks Cray – works fine for me under a fresh Ubuntu 11.04 install. I’m playing with the calibration a bit around line 270:
temperature = (answer[3] & 0xFF) + (answer[2] << 8);
temperature -= 500;
*tempC = temperature * (125.0 / 32000.0);
.. which gives better results for me, although I need to take a wider range of values to see if it's anywhere near linear.
BTW, the sensor in my TEMPer (which has "TEMPer2 V11a PCsensor.com 20110331" on the PCB) seems to be an FM75:
http://www.datasheetcatalog.org/datasheet/fairchild/FM75.pdf
..it's marked up as "VG1AF FM75 M8" on the IC – guess they forgot to sand that off 🙂
Laters!
July 10, 2011 at 2:06 pm |
Hi,
I forgot the calibration…
I add -a[n] option where you can specify a value for calibration.
http://www.isp-sl.com/pcsensor-1.0.0.tgz
Bye
July 12, 2011 at 12:56 pm |
Cray,
You’re a legend – works brilliantly. Thanks!
July 12, 2011 at 8:40 pm |
Thanks Cray, works nicely.
Do you have any idea if is possible to port the code to work with the glibc 2.5 ?
July 12, 2011 at 9:17 pm
Hi steve97usa,
I have a Red Hat 5.4 with glibc 2.5-42 and it works for me.
Try to recompile with:
make clean
make
If it don’t work, post the error, and the versions of glibc and libusb.
Bye
July 19, 2011 at 12:59 pm |
pcsensor-1.0.0 works for me, with my 0c45:7401 Microdia device, meaning at least I get a temperature reading but I have no idea how accurate it is.
I have Cacti put the output in an RRD for one night, and it seems that the highest value ever output is 32.0 degrees celcius, it seems to ‘clip’ there. Anyone else seen this?
Best regards,
Martijn.
July 13, 2011 at 3:39 pm |
Hi,
Just wanted to say that the pcsensor program works for me as well.
Thanks for posting. I have the model “RDing TEMPer2V1.0” (which is what show up on my Suse Linux box. The outside of the actual unit says “TEMPer1”. I think this unit has the internal and external sensor, but i’m only getting the external reading with pcsensor. I think this version is usb only, not a serial to usb device, which is why i assume only pcsensor is working.
Thanks again Cray and other devs who got this working on linux.
Now i can monitor my fermentation fridge in real time!
July 13, 2011 at 8:30 pm |
Hi morbo,
Could be interesting that you post the verbose output of your device, may be we can see something about internal sensor.
Bye
July 14, 2011 at 5:19 am |
I have two of the same device.
I assume by “verbose output” you mean from the pcsensor program? And not something like strace or ltrace?
as I said, it’s definiitely giving me the external probe temp, which
is great cause that’s the one I need, but the other would be handy. I downloaded the USB snoop program, i will give that a shoot in the next couple of days, maybe it’ll help.
thanks
here is on one (opensuse 11.4) box:
pcsensor -v
lvr_winusb with Vendor Id: c45 and Product Id: 7401 found.
Detach failed: No such file or directory[2]
Continuing anyway
Detach failed: No such file or directory[2]
Continuing anyway
01 01 02 00 00 00 06 00
01 80 33 01 00 00 00 00
80 02 20 90 20 80 32 46
01 82 77 01 00 00 00 00
82 01 00 00 20 80 32 46
01 86 ff 01 00 00 00 00
54 45 4d 50 65 72 32 46
31 2e 30 50 65 72 32 46
01 80 33 01 00 00 00 00
80 02 20 90 20 80 32 46
2011/07/14 00:13:43 Temperature 90.61F 32.56C
and on the second one(SLED11-sp1):
usb_set_debug: Setting debugging level to 255 (on)
usb_os_init: Found USB VFS at /dev/bus/usb
usb_os_find_busses: Found 003
usb_os_find_busses: Found 001
usb_os_find_busses: Found 004
usb_os_find_busses: Found 005
usb_os_find_busses: Found 002
usb_os_find_devices: Found 001 on 003
usb_os_find_devices: Found 004 on 001
usb_os_find_devices: Found 001 on 001
usb_os_find_devices: Found 017 on 004
skipped 1 class/vendor specific interface descriptors
skipped 1 class/vendor specific interface descriptors
usb_os_find_devices: Found 001 on 004
error obtaining child information: Inappropriate ioctl for device
usb_os_find_devices: Found 001 on 005
usb_os_find_devices: Found 004 on 002
skipped 1 class/vendor specific interface descriptors
skipped 1 class/vendor specific interface descriptors
usb_os_find_devices: Found 003 on 002
usb_os_find_devices: Found 002 on 002
skipped 1 class/vendor specific interface descriptors
skipped 1 class/vendor specific interface descriptors
usb_os_find_devices: Found 001 on 002
error obtaining child information: Inappropriate ioctl for device
error obtaining child information: Inappropriate ioctl for device
lvr_winusb with Vendor Id: c45 and Product Id: 7401 found.
USB error: could not detach kernel driver from interface 0: No data available
Device already detached
USB error: could not detach kernel driver from interface 1: No data available
Device already detached
01 01 02 00 00 00 06 00
01 80 33 01 00 00 00 00
80 02 19 b0 19 a0 32 46
01 82 77 01 00 00 00 00
82 01 00 00 19 a0 32 46
01 86 ff 01 00 00 00 00
54 45 4d 50 65 72 32 46
31 2e 30 50 65 72 32 46
01 80 33 01 00 00 00 00
80 02 19 b0 19 a0 32 46
2011/07/14 00:16:16 Temperature 78.24F 25.69C
July 14, 2011 at 6:27 am |
Hi,
I thing that in the next line:
80 02 | 20 90 | 20 80 | 32 46
20 90 is the external sensor
20 80 may be the internal sensor
could you put pcsensor in verbose mode and loop mode and modify the temperature of internal sensor to see changes on this values?
Thank you
March 8, 2012 at 10:21 am |
I have TEMPer2 with inner/outer sensors (ID 0c45:7401):
.jpg)
I am using slightly modified Cray’s (thank you!) pcsensor software.
in function interrupt_read_temperatura() we have:
temperatureInner = (answer[3] & 0xFF) + ((signed char)answer[2] << 8);
temperatureOuter = (answer[5] & 0xFF) + ((signed char)answer[4] << 8);
Works great with Cacti and my SMS/E-mail alerting daemon..
Thank you all!
March 9, 2012 at 12:47 am
Thank you for providing this information. It tells me at least two things that are useful to me and my project: the offsets of the sensors in your device, and that the 0c45:7401 devices have subdevices just like the 1130:660c ones. (Now all I’m lacking is a way for the code to separate the types… I guess I’ll experiment a bit with the ones I have.)
… sigh. Not that I’m really surprised, but I had hoped the subdevice stuff was only for the 1130:660c ones… This makes me think the exception is devices *without* subdevices, not the other way around as I first thought.
Oh well. On a brighter side, I believe my restructure branch is about on par with the original now, in terms of device support (actually, it should support more devices than my original already) – but it is annoyingly difficult to test when I only have the one type myself. I’m starting to seriously consider spending some money and getting several different types for myself. 😛 (Well, hobbies are /supposed/ to burn money anyway, right?)
Next up (after some minor changes) is probably working multi-sensor support, but I’m considering merging what I have to master first, since it should work at least as well… In case I end up messing up the next bits. But the API will probably change. Again. So I’m not sure.
… Hm, I just realized – I should probably start my own blog for talking about my project, shouldn’t I? Instead of (ab)using relavak’s comments like this? 😛
July 16, 2011 at 6:14 pm |
I just wanted to mention that pcsensor works for me under Ubuntu 10.10. The temper program did not, even after changing the rules to match usb-devices info. I picked mine up from Meritline.
usb-devices says:
T: Bus=03 Lev=01 Prnt=01 Port=04 Cnt=02 Dev#= 5 Spd=1.5 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0c45 ProdID=7401 Rev=00.01
S: Manufacturer=RDing
S: Product=TEMPer2V1.0
C: #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid
I: If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=usbhid
July 16, 2011 at 9:05 pm |
The manufacturer has used a different chipset in these devices, depending on the usb-id can work temper, pcsensor, or none if you have bad luck…
July 20, 2011 at 3:11 am |
Those values appear to change, but I can’t tell in the pcsensor code, how to convert the value from the results “20 90” into actual temperatures?
also, now that i’m looking and I have one with the external probe in a fridge, while the internal probe is outside the fridge, those numbers are the same. That can’t be correct. Maybe these only have 1 sensor. i can live with that.
linux:~ # pcsensor -v
lvr_winusb with Vendor Id: c45 and Product Id: 7401 found.
Detach failed: No such file or directory[2]
Continuing anyway
Detach failed: No such file or directory[2]
Continuing anyway
01 01 02 00 00 00 06 00
01 80 33 01 00 00 00 00
80 02 12 00 12 00 32 46
01 82 77 01 00 00 00 00
82 01 00 00 12 00 32 46
01 86 ff 01 00 00 00 00
54 45 4d 50 65 72 32 46
31 2e 30 50 65 72 32 46
01 80 33 01 00 00 00 00
80 02 12 00 12 00 32 46
2011/07/19 22:09:38 Temperature 64.40F 18.00C
July 20, 2011 at 3:41 am |
Ok. my bad. on the ebay listing for my device, it said two sensors, but from here: http://www.pcsensor.com/index.php?_a=viewCat&catId=6 (i have the temper1) that 1 means one sensor. There is a temper2 with the internal/external.
sorry for the confusion.
July 20, 2011 at 5:19 am |
I’m not sure you have to apologize.
There is confusion, true, but is this company that produces too many type of temperature sensors and change needlessly interface.
Anyway, I have the same model as yours and I believed it had two sensors too, because when you plug it in, it opens two sockets.
Here the dmesg output part I have when I insert the TEMPer1 (on Ubuntu 10.04 updated) :
……………………………….
……………………………….
[60144.323420] input: RDing TEMPer2V1.0 as /devices/pci0000:00/0000:00:1d.1/usb7/7-2/7-2:1.0/input/input7
[60144.323509] generic-usb 0003:0C45:7401.0005: input,hidraw4: USB HID v1.10 Keyboard [RDing TEMPer2V1.0] on usb-0000:00:1d.1-2/input0
[60144.337210] generic-usb 0003:0C45:7401.0006: hiddev97,hidraw5: USB HID v1.10 Device [RDing TEMPer2V1.0] on usb-0000:00:1d.1-2/input1
If it has only one sensor, why open two sockets ?
Mistery … 🙂
C’ya
STeve
July 21, 2011 at 5:42 pm |
Hi,
I have a HID TemperHUM and was using Valiarie Moore’s code, but I have made some changes to it. You can find a patch against latest revision (which I think it’s not going to change) here:
Patch: http://www.ipaste.org/be
Complete code: http://box.jisko.net/d/2f907e78
I have changed several things:
– Fixed a bug in humidity calculation, one of the correction factors should be (according to the SHT1X datasheet) -2.0468 and it was +2.0468 in the original code so RH was always reported a bit too high.
– Included humidity corrections based in temperature different from 25ºC. I used a formula found in the same datasheet.
– Included dew point calculation.
The data I get now is very similar to the data I get in Window programs. ThermoHID reports temperatures 0.3 lower but I thinks that’s because they’re using the factor correction for a sensor VDD of 5V (-40ºC), but several people have measured it and it’s between 3 and 3.5V (so I left the original -39.7 correction untouched as it should be more accurate). Humidity (in ThermoHID and HIDTemperHUM) and dew point (only available in HIDTemperHUM) are basically the same.
Hope it’s useful for someone (I’m having some fun with some scripts and gnuplot).
Regards,
Guillermo.
August 4, 2011 at 8:58 am |
Hello
I just received this device yesterday. When i try to run temper I get this error: Inappropriate ioctl for device
Any ideas?
August 6, 2011 at 7:32 am |
ok i managed to get past the error by changing the vendor/product id to my corresponding id’s.
Now i get another problem:
Found device: 0c45:7401
Found deviceNum 0
Trying to detach kernel driver
Device already detached
Device already detached
sending bytes 10, 11, 12, 13, 0, 0, 2, 0
sending bytes 82, 0, 0, 0, 0, 0, 0, 0
sending bytes 10, 11, 12, 13, 0, 0, 1, 0
Other Stuff (-32 bytes):
sending bytes 10, 11, 12, 13, 0, 0, 2, 0
sending bytes 84, 0, 0, 0, 0, 0, 0, 0
sending bytes 0, 0, 0, 0, 0, 0, 0, 0
sending bytes 0, 0, 0, 0, 0, 0, 0, 0
sending bytes 0, 0, 0, 0, 0, 0, 0, 0
sending bytes 0, 0, 0, 0, 0, 0, 0, 0
sending bytes 0, 0, 0, 0, 0, 0, 0, 0
sending bytes 0, 0, 0, 0, 0, 0, 0, 0
sending bytes 0, 0, 0, 0, 0, 0, 0, 0
sending bytes 10, 11, 12, 13, 0, 0, 1, 0
TemperGetTemperatureInC: Broken pipe
August 6, 2011 at 7:41 am |
ok, tried the http://www.isp-sl.com/pcsensor-0.0.1.tgz one from a comment further up, and now i finally get readings.
The readings don’t seem to change though. it’s stuck at 33,25 C
August 7, 2011 at 3:03 pm |
Ok i think i got everything working now.
A tiny tale about my adventure to make this work: http://bit.ly/nFxo7q
August 23, 2011 at 5:27 pm |
Hey,
I have a RDing TEMPerV1.2 and it works with the ‘pcsensor’ software… Big thanks for that…
I use Nagios to check the temperature about once a minute and to alert me if it rises over 30°C.
Unfortunately sometimes the sensor reports ‘impossible’ values – either ‘0’ or ‘77.31’. Neither of those were correct as it’s impossible for the temperature to jump from 22 to 77 °C or drop from 22 to 0 in just one minute (when I was testing it took 4 hour to rise to 30°C).
Anyone else noticed this problem and found a solution?
August 24, 2011 at 4:36 pm |
I’m not sure about the 0, but the 77.31 is a failed reading from the device. If you run the pcsensor program by hand, it will probably fail 1 out of 10 times. Maybe you can write a wrapper script around your nagios check to not report these bogus results? Or possibly update the pcsensor program to not return them. I don’t think it’s a fault of the pcsensor program, more so a problem with the device and the interface to the device.
August 24, 2011 at 5:32 pm |
I ran the program in a loop with a 1 second sleep:
while true ; do /usr/local/sbin/pcsensor ; echo $? ; sleep 1 ; done
Every 17th invocation failed with an error:
USB interrupt read: Numerical result out of range
Fatal error> USB read failed
The interesting thing – the exit status ($?) of the program was ’17’ as well…
In my Nagios check I already implemented a re-try in case the exit status is non zero – but I can’t know whether the pcsensor program returned a bogus result or it was really that hot. Maybe I’ll change the setup so it won’t alert on a single ‘critical’ value…
Unfortunately my knowledge of C is limited to ‘./configure’ and ‘make’, so I’m afraid I won’t be able to update the ‘pcsensor’ program.
August 30, 2011 at 10:28 pm
I wouldn’t read it every second…I think you’ll have better success if you drop back to every 5 or 10 seconds. You might try using the “-l” option too, so you can just start it and leave it running. I’ve run it for at least several hours straight with a 10-second loop, and it seems to be pretty stable. YMMV.
October 22, 2011 at 11:24 am
A workaround:
pcsensor 2>/dev/null || (sleep 1; pcsensor)
February 7, 2012 at 10:02 pm |
It’s amazing how often the device will disconnect and re-connect:
Feb 7 15:01:14 draco kernel: usb 2-1.4: USB disconnect, address 47
Feb 7 15:01:14 draco kernel: usb 2-1.4: new low speed USB device using ohci_hcd and address 51
Feb 7 15:01:14 draco kernel: usb 2-1.4: New USB device found, idVendor=0c45, idProduct=7401
Feb 7 15:01:14 draco kernel: usb 2-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Feb 7 15:01:14 draco kernel: usb 2-1.4: Product: TEMPer1V1.1
Feb 7 15:01:14 draco kernel: usb 2-1.4: Manufacturer: RDing
Feb 7 15:01:14 draco kernel: usb 2-1.4: configuration #1 chosen from 1 choice
Feb 7 15:01:14 draco kernel: input: RDing TEMPer1V1.1 as /devices/pci0000:00/0000:00:06.0/0000:03:00.1/usb2/2-1/2-1.4/2-1.4:1.0/input/input176
Feb 7 15:01:14 draco kernel: generic-usb 0003:0C45:7401.015B: input,hidraw0: USB HID v1.10 Keyboard [RDing TEMPer1V1.1] on usb-0000:03:00.1-1.4/input0
Feb 7 15:01:14 draco kernel: generic-usb 0003:0C45:7401.015C: hiddev96,hidraw1: USB HID v1.10 Device [RDing TEMPer1V1.1] on usb-0000:03:00.1-1.4/input1
Anyone tried to figure this out?
August 30, 2011 at 9:25 pm |
Hi,
I recently got a few TEMPer devices off DealExtreme, that turned out to be the 0c45:7401 HID version – after trying several other programs mentioned here, Cray’s pcsensor-1.0.0 finally worked.
I would like to say THANK YOU to Cray and relavak for writing and publishing this code.
However, it has a small bug – it does not properly support negative temperatures (below 0 deg C), instead returning values around 240-255.
The fix is simple enough, adding a cast on line 270, changing it from this:
temperature = (answer[3] & 0xFF) + (answer[2] << 8);
to this:
temperature = (answer[3] & 0xFF) + ((signed char)answer[2] << 8);
I've tested this code with the values from Table 1 in the FM75 datasheet Mark linked to (on the assumption that the sensors use the same output values), and it gives the correct results, and also seems to give reasonable values with a TEMPer that's been in the freezer for a little while.
I also have a question, about something that seems to be common in many of the programs here – why would you do temp*125.0/32000.0 when that apparently is exactly the same as temp/256.0 ? (since 125*256==32000)
To me, this seems like needless obfuscation of what is going on, as doing temp/256 shows more clearly that we are moving the decimal point into place (considering the shifting right above this).
In the test I mention above, I also changed this to /256.0, and as mentioned, that seems to work just fine for me, but if anyone knows a good reason not to do this, I'd love to hear it.
August 30, 2011 at 9:50 pm |
Let me explain why I use temp * 125/32000. I got this formula from the datasheet for the temperature sensor. Some versions of the sensor can be put into various modes in which case the 125 changes, but the 32000 is fixed. The temper uses 125, but I have a habit of writing code this way, which can be confusing to some but helps me remember the origin of the formula. Regarding the formula to compute temperature, my original code works fine since “char” and “signed char” are the same thing. I know that many people have taken my code and adapted it and published it here, and to tell the truth I haven’t really looked at most of those derivatives, but I believe my original code works since I have been running that code in my temperature chamber over hundreds of cycles from -40C to +85C.
August 31, 2011 at 10:56 pm
Aaah, I see. Yes, that is a pretty good reason to keep it that way – I simply wasn’t aware that the formula was taken from the datasheet.
As for the negative temperatures, yes, I do believe your original code works just fine in this regard – that part of my comment was pointed at Cray’s variant of it, which uses unsigned chars for the byte array read from USB, and hence needs the cast. I’m sorry if this was not clear. (I tried your original code first, but it didn’t work with my version of the TEMPer, while Cray’s did.)
Thank you for your informative response.
September 17, 2011 at 3:31 pm
I’m using the device, with your software, in an application that ranges from about -5C to 50C. I have the probe strapped to a very accurate RTD probe, so I have a good reference temperature (I don’t have a software interface to pull data from the RTD probe, so I need the TEMPer). From 0-50C it’s very accurate; I made a minor 0.25-degree tweak to your temp calculation code to account for this particular probe’s calibration. Once the probe reading goes below 0C, it “wraps” the hex values–at 0C it reads 0x0, but just below zero it starts at 0xffff and counts down from there. Once it gets to about -1C, though, it stops at ff10 and won’t go any lower. Anyone else seeing this behavior?
August 30, 2011 at 10:54 pm |
Great programs, thanks Cray et al for the work. My unit seems to max out at 39.75C / 103.55F. I’m assuming this isn’t a limitation in the software.
September 14, 2011 at 3:29 pm |
forums which are across the same subject matter? Thank you!
September 22, 2011 at 6:09 pm |
Excellent work Cray et al. Got my 0c45:7401 HID version to work with help here. Monitoring my server closet with this little script running every 15 minutes.
#!/bin/bash
TEMP=$(sudo /home/user/pcsensor-0.0.1/pcsensor | cut -c33-34)
if [ $TEMP -gt 85 ];
then echo “Temp is $TEMP” | mail -s “TEMP ALERT $TEMP” 5551234567@cellphone.net;
fi
September 24, 2011 at 11:29 pm |
Nice post about TEMPer Temperature Sensor Linux Driver « Relavak Labs. I am very impressed with the time and effort you have put into writing this story. I will give you a link on my social media blog. All the best!
October 2, 2011 at 5:42 pm |
Thank you EdorFaus for your apportation (The app updated: http://www.isp-sl.com/pcsensor-1.0.1.tgz).
JLG,I tested my device and reaches temperatures higher than those you indicate. I stopped the test with 110.08F 43.38C, I didn’t want to force the device …
njalk, it’s a very interesting mod, Be carefull with close connections (mysql_close(conn) function). I do not know how it will work at this point the mysql, but in other databases, if not close connections, it can happen that the database runs out of available connections.
Mike, I use the device for that purpose and mrtg integration 🙂
November 27, 2011 at 9:57 am |
I haven’t had any problems yett, but I’ll look into it once I get he time.
But as of now it’s been running non-stop since i posted the other comment, with a reading every minute, and no issues
October 3, 2011 at 1:54 pm |
hi , can I use your soft with http://pcsensor.com/index.php?_a=viewProd&productId=38
http://pcsensor.com/index.php?_a=viewProd&productId=37
from dmesg
[25342.260088] usb 6-1: new full speed USB device using ohci_hcd and address 6
[25342.468659] usb 6-1: configuration #1 chosen from 1 choice
[25342.470721] ch341 6-1:1.0: ch341-uart converter detected
[25342.497655] usb 6-1: ch341-uart converter now attached to ttyUSB0
from lsusb
Bus 006 Device 006: ID 1a86:7523 Unknown HL-340 USB-Serial adapter
Thanks.
October 13, 2011 at 2:40 pm |
Owning a recent TEMPerHUM identified as a RDing TEMPer2HumiV1.0 (USB device 0c45:7402 hooking to USB HID), pcsensor-1.0.1 (from comment https://relavak.wordpress.com/2009/10/17/temper-temperature-sensor-linux-driver/#comment-241 in this very thread) seems to work well for temperature.
Unfortunately, no humidity reading is available; I’m leaving this keyword-rich comment so that other lucky GNU/Linux users find something via search engines 🙂
November 9, 2011 at 5:27 am |
Debian wheezy amd64
TEMPerHUM detected as RDing TEMPer2HumiV1.0 0C45:7402
Thank you wayne, Cray and relavak.
Rough journal of the very basic changes made,
– Tried to run supplied pcsensor binary.
-> Receive error “error while loading shared libraries: libusb-0.1.so.4: cannot open shared object file: No such file or directory”
– Skipped ia32-libs and instead installed libusb-dev. Build pcsensor from source.
– Edited ATTRS{idProduct} in 99-tempsensor.rules from 7401 to 7402
-> Receive pcsensor error “Couldn’t find the USB device, Exiting”
– Edited #define PRODUCT_ID in pcsensor.c from 0x7401 to 0x7402 and again build pcsensor from source.
-> Successful temperature readout but approximately 5C too high.
– Edited *tempC in pcsensor.c to reflect the 5C offset and compile once more.
November 3, 2011 at 6:58 pm |
Can someone tell me if this is the right beast to order for use with pcsensor-1.0.0 ? Thanks!
http://www.dealextreme.com/p/temper-usb-thermometer-temperature-recorder-for-pc-laptop-81105
November 4, 2011 at 12:34 am |
That’s not the product I bought, which I know works with pcsensor-1.0.0, but others have reported success with that program for other devices (at least one, right above your post), so it is possible that it will work.
However, if you want to be sure that the device you buy works with that program, and don’t mind buying a different one than you linked to, you could go for the one I bought:
http://www.dealextreme.com/p/usb-powered-c-f-thermometer-40-120-c-48285
(Note: I’m not giving any guarantee that it will work, as DealExtreme might have gotten in a different batch that aren’t really the same product (though I kinda doubt that would happen), but I still think it’s the best way we have to be as sure as you can be that it will work.)
November 4, 2011 at 5:46 pm
Thanks for the link. I already ordered it so guess I’ll have to keep my fingers crossed until I can plug it in.
November 6, 2011 at 1:41 am |
Well, either way, could you tell us the result (whether it works or not) and some basic info on the device (like its USB device IDs)?
If it does work, that’s useful information, and if it doesn’t, we might still be able to help make it work with some other program…
November 5, 2011 at 3:16 am |
[…] [3] https://relavak.wordpress.com/2009/10/17/temper-temperature-sensor-linux-driver/ […]
November 20, 2011 at 4:51 pm |
I just uploaded a slightly modified version supporting multiple devices here http://momtchil.momtchev.com/html/files/pcsensor-1.0.0-multi.tgz
November 21, 2011 at 1:28 am |
I get a page not found error on that link…
November 21, 2011 at 9:01 am
http://momtchil.momtchev.com/files/pcsensor-1.0.0-multi.tgz
sorry, this is the correct URL
the main problem is that there’s no way to identify which device is which
February 7, 2012 at 9:51 pm |
Here is a patch to support specifying a specific usb device number. This can be matched to a specific physical device via the /sys/device/ tree. For example:
#!/bin/bash
# Called with index #, return that temperature index
# Probes are connected to:
# /sys/devices/pci0000:00/0000:00:06.0/0000:03:00.1/usb2/2-1/2-1.1/devnum
devnum=$(cat /sys/devices/pci0000:00/0000:00:06.0/0000:03:00.1/usb2/2-1/2-1.${1}/devnum)
temp=$(pcsensor -f -d $devnum 2>/dev/null | sed -e ‘s/.*Temperature //’ -e s/F//)
http://www.cora.nwra.com/~orion/pcsensor-devnum.patch
November 21, 2011 at 2:35 am |
Hm, I apparently forgot to mention this here until now…
I’ve written a program (that I hope to turn into a full-fledged library) that currently supports reading temperature from two devices (the 0c45:7401 and, I think[1], 7402), with framework in place for easily adding more – the intent being to end up with one program/library that works for all the known devices, making things easier for users.
It can be found here: https://github.com/edorfaus/TEMPered
I’m hoping to add support for all the variants I can either get help with or my hands on, including those with multiple sensors and humidity. I also hope it will be possible to autodetect some of the calibration values needed for some devices, when I get to them.
The next device I’m thinking to add experimental support for is the 1130:660c device of the original temper-1.0 program, hoping someone will be willing to help me test that it works (since I don’t have that device).
Unlike the temper and pcsensor programs, mine avoids re-implementing the HID standard by using an existing library for that, making the main part of the code simpler. This currently makes it a little bit harder to build (because I didn’t want to copy the code of that library at this point), but that’s fixable.
[1] The 7402 support is based on the comment that it works with the code for the 7401, and has not been tested yet (since I don’t have that device) – help would be appreciated.
November 21, 2011 at 3:23 am |
I tested and EdorFaus’ TEMPered gives sensible values for 0c45:7402; same values as given by pcsensor (which are little too high but I have no reliable way of measuring the real temperature now).
November 21, 2011 at 10:57 am |
I have TEMPer, TEMPerNTC and TEMPerHUM, all identified by 1130:660C.
November 24, 2011 at 8:57 pm
Hmm, I see. And, looking closer at some of the programs found around here, they don’t seem to all use the same code, either – which means that this is a bit more annoying than I thought it would be. I had expected that devices needing different code would at least have different device IDs. Oh well.
I’ve added experimental support for the TEMPer and TEMPerHUM devices (only temp, no hum yet), but it might need a little modification to recognize them, since I haven’t managed to find the exact product strings for those devices.
You can run “enumerate -a” to find the product string (the last part of the device line, after the manufacturer string) and update the string in temper_type.c to match (and also, please, tell me what the exact strings are, so I can fix them here).
It might still not work, as I’ve only made an educated guess about what to send to the device; if you’re willing to test them, that would be appreciated.
December 16, 2011 at 9:22 pm
Sorry for the late reply/
All three show up as:
Device 1130:660c 0 | /dev/hidraw4 | (null) PCsensor Temper
Recognized as ignored part of: TEMPer, TEMPerNTC or TEMPerHUM
Device 1130:660c 1 | /dev/hidraw5 | (null) PCsensor Temper
when running enumerate -a.
./temperhid returns with no output written to console.
I use hidapi straight from git, using the hidraw thing.
December 16, 2011 at 9:40 pm
For what it is worth:
http://search.cpan.org/~msulland/Device-USB-PCSensor-HidTEMPer/lib/Device/USB/PCSensor/HidTEMPer.pm
AKA
Device::USB::PCSensor::HidTEMPer
works for HIDtemper and HIDtemperNTC.(1130:660c), but yeilds no temperature (or humidity) for the HIDtemperHUM (with the same identifier).
Hence, there must be a way to differentiate the devices.
🙂
Dag B
December 17, 2011 at 2:02 am
No worries, thank you for testing at all! (I’m getting a bit busy myself, what with the holidays and all, so may not get much done on this for a while.)
Apparently, this part (device recognition) just keeps getting worse… I guessed the product string would be different between them, but apparently it isn’t, and I doubt any of the other fields I could use are, either (but I’ve made enumerate show (with -a) any possibly-useful values anyway, just in case).
That the temperhid program doesn’t print anything is not surprising, since the enumeration only recognizes the ignored part of the device, because the product strings in the current code are different from the ones the devices actually provide. (The ones in the code was just a blind guess, to be honest.)
If you want to test the temperature/humidity reading code, you can comment out a line (the product string) in temper_type.c and recompile – for the HIDtemper that would be line 60, and for the HIDtemperHUM line 72. Note that only one line should be commented out at a time, or both devices will be recognized as being the former, which probably won’t work with the -HUM.
I’ve read the code of that Perl module, and yes, it does have (and use) a way of distinguishing between the device types – but only after opening/claiming the device. (It reads an identification byte from the eeprom before reading the sensors.)
I was hoping to be able to distinguish between the types before opening it, so the code (and user) could know what features it has, what code to use, etc. before trying to use it, but I guess I’ll just have to accept defeat in that matter and restructure the code a little bit to support dynamic identification / read method selection.
November 24, 2011 at 7:08 am |
Thanks Cray for your work on pcsensor!
Just bought this one from Amazon,
http://www.amazon.com/TEMPer-USB-Thermometer-w-Alerts/dp/B002VA813U/ref=sr_1_1?ie=UTF8&qid=1322118320&sr=8-1
…..and it works fine w/your application.
Ciao.
December 6, 2011 at 3:36 pm |
I have a temperhum device with usb id: 0c45:7402
This works with tempered software to give a temperature reading and works with pcsensor-1.0.1.tgz if I modify the USB ID’s but there is no support in these tools for the humidity.
Other software sources which support humidity do not seem to work with this device and I think are for different models but hopefully the same chipset.
I opened an issue on Tempered git page asking about how to modify that code to include support for the Humidity values. I wrote what I had found in other sources about how the calculation is done.
https://github.com/edorfaus/TEMPered/issues/1
I do not know much about coding so this is as far as I have got so far. Perhaps someone can help? Thanks to everyone for their great work so far.
December 10, 2011 at 9:29 pm |
I’ve added humidity support to the TEMPered code now, for both this device and the 1130:660c TemperHUM.
Unfortunately, it’s all experimental (though for different reasons for each device), since I don’t have any -HUM devices to test with. Feedback is appreciated, as always.
For the 0c45:7402 device, humidity is experimental because I don’t know the offsets for the data, but should work otherwise (assuming it’s done similarly in this device as in the others).
For the 1130:660c device, humidity is experimental because the entire device is – if reading the temperature off it works, humidity should work too, but I’ve not yet seen either confirmed by anyone with these devices.
December 12, 2011 at 6:24 pm
Unfortunately the 0c45:7402 TEMPer2HumiV1.0 constantly reports 0% humidity. A cheap hygrometer nearby gives around 50%.
Removing the clamping statement from the code, I get different values around -511%; rh variable seems stuck at 32772 (temperature seems to be the sole factor making the humidity value fluctuate).
December 13, 2011 at 2:37 am
Right. That most likely means the offsets are wrong. Not entirely unexpected, as I was just taking a blind guess with them, really.
The offsets of the high and low byte of humidity data can be changed on line 27 and 28 of the temper_type.c file.
You can try using the dump-data program I just added to see where the humitidy values are in the returned data (look for values that change with the humidity, other than the temperature values), or if that doesn’t help, just try some pseudorandom offsets (within the size of data read from the device).
If that’s too much work, I can try to help if you post the output of the dump-data program and what the humidity was at the time.
December 31, 2011 at 5:20 pm
I’ve gotten the 0c45:7402 TEMPer2HumiV1.1 device to work now, for both temperature (which was using the wrong formula) and humidity (which was using the wrong offsets), thanks to the help of cyrilpawelko.
This marks a milestone, as it’s the second device that fully works with the project, showing that this is possible in practice, not just in theory. 😀
January 2, 2012 at 8:31 pm |
Is there any progress of the 1130:660c TEMPerNTC (temper with external probe) ? 🙂
February 4, 2012 at 7:46 pm |
[…] my new-found PyUSB skills. I couldn’t find a datasheet for the devices but I did find a C version on Robert Kavaler’s […]
February 4, 2012 at 7:48 pm |
Robert,
I used your C version to create my Python version. It’s at http://wp.me/p2a7aU-X
—
Bill
February 16, 2012 at 7:34 am |
[…] Linuxの HIDドライバは無いみたい。で、見つけたのが relavak Labsと言うページ。どうやら、そのスレッドの中の Crayさんの […]
March 10, 2012 at 9:06 pm |
I just wanted to mention a couple of things here, so interested people can find it.
First, I’ve started a blog of my own, which I’m using to post information about my project (including progress updates), and will probably keep most of my updates there from now on, so as not to spam the comments here. Link is on my name and on the project page.
Second, I’ve merged my restructured code into the master branch, as it should now work better than what was there before.
It should at this time support most of the known 0c45:740x and 1130:660c devices – though only the first sensor of each (multi-sensor is next on my TODO list). For more details, see my blog.
April 16, 2012 at 9:34 pm |
Hi everyone,
I’ve been running into all kinds of issues getting my recently-acquired TEMPer (the 0c45:7401 version) to work with any of the software people have posted. temper-1.0 gives me the apparently-common “broken pipe” error, and all versions of pcsensor time out with a “USB interrupt read: resource temporarily unavailable” error after a few seconds. The second one is apparently uncommon; has anyone else run into it, and is there a workaround?
I did some USB snooping of my own on my device to see if it was doing anything different, but it matches up with what everyone else has observed. The thing may just be DOA, since the stock Windows software couldn’t find it either (oddly it works fine with ThermoHID)
For what it’s worth, I’m using a RHEL 5 box for this.
May 15, 2012 at 1:16 am |
bryan, just to confirm. I got two Temper V2 devices today and the results are exactly the same as yours.
Did you manage to bring it to work?
August 3, 2012 at 3:21 pm |
on redhat 5.8
wget http://www.isp-sl.com/pcsensor-0.0.1.tgz
tar xvfz pcsensor-0.0.1.tgz
cd pcsensor-0.0.1
cp 99-tempsensor.rules /etc/udev/rules.d/
make clean
make
cp pcsensor /usr/local/bin/
/usr/local/bin/pcsensor
2012/08/03 10:15:32 Temperature 72.84F 22.69C
September 5, 2012 at 9:04 pm |
Where is everyone buying the HIDtemperHUM version of this device now?
September 10, 2012 at 3:42 pm |
Hello,
Yes I have bought a HIDtemperHUM (0x0C45 0x7402). I manage to run it properly using libusb.
January 25, 2013 at 5:16 pm |
I bought mine on Chinavasion. http://www.chinavasion.com/china/wholesale/Electronic_Gadgets/Cool_Gadgets/USB_Hygrometer_Thermometer-Server_Room_Temperature_Monitor
Took a full week to fulfill and pack the order, then two weeks shipping. So they must not have them in stock, but probably get them from the factory or a middle-man.
September 14, 2012 at 9:30 am |
Hi,
Iget problem when try tu get my temper1 work on a redhat server here are the commands I tried:
trying pcsensor without compiling:
[ ROOT@hclin10 ~/bin > wget http://www.isp-sl.com/pcsensor-0.0.1.tgz
[ ROOT@hclin10 ~/bin > tar xvfz pcsensor-0.0.1.tgz
[ ROOT@hclin10 ~/bin > cd pcsensor-0.0.1
trying pcsensor without compiling:
[ ROOT@hclin10 ~/bin/pcsensor-0.0.1 > ./pcsensor
./pcsensor: /lib/libc.so.6: version `GLIBC_2.7′ not found (required by ./pcsensor)
GLIB2.7 seems to miss, but I don’t know how to install it so I fooloweds the above commands :
cp 99-tempsensor.rules /etc/udev/rules.d/
make clean
make
[ ROOT@hclin10 ~/bin/pcsensor-0.0.1 > ./pcsensor
USB interrupt read: Resource temporarily unavailable
Fatal error> USB read failed
Any ideas ?
Thank you in advance
October 2, 2012 at 8:01 pm |
How to monitor two sensors ?
October 2, 2012 at 9:24 pm |
Use TEMPered:
# tempered
/dev/hidraw1 0: temperature 20.69°C
/dev/hidraw3 0: temperature 29.50°C
/dev/hidraw5 0: temperature 21.06°C
/dev/hidraw7 0: temperature 21.31°C
December 10, 2012 at 11:12 am |
[…] ・TEMPer Temperature Sensor Linux Driver HIDタイプ向けのドライバのようだ。 […]
January 23, 2013 at 7:44 pm |
The download, as is, has already been called with ‘make’, so the directory is unclean.
I would recommend you ‘make clean’ and reupload the driver, seeing as the binary could be created on a 32 or 64bit system and cause people some confusion as it has me.
Thanks for uploading the driver though.
February 21, 2013 at 11:00 am |
Using your code on a Raspberry Pi to monitor server room temperature and generate SNMP traps.
Unlike the Perl implementation, yours works like a charm!
Thank you!
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=36&t=34354
July 6, 2013 at 2:53 pm |
Hi all,
I bought one of these temperature sensors directly from PCsensor on their ebay store. It looks identical to this:
Unfortunately I haven’t been able to get it working as of yet. I’m getting this messages:
When trying pcsensor-1.0.0:
$ ./pcsensor
USB interrupt read: Resource temporarily unavailable
Fatal error> USB read failed
When using temper-1.0:
$ ./temper
Found device: 1d6b:0003
Found device: 046d:c318
Found device: 13d3:3404
Found device: 051d:0002
Found device: 0c45:7401
Found deviceNum 0
Trying to detach kernel driver
Device already detached
Device already detached
sending bytes 10, 11, 12, 13, 0, 0, 2, 0
sending bytes 82, 0, 0, 0, 0, 0, 0, 0
sending bytes 10, 11, 12, 13, 0, 0, 1, 0
Other Stuff (-32 bytes):
sending bytes 10, 11, 12, 13, 0, 0, 2, 0
sending bytes 84, 0, 0, 0, 0, 0, 0, 0
sending bytes 0, 0, 0, 0, 0, 0, 0, 0
sending bytes 0, 0, 0, 0, 0, 0, 0, 0
sending bytes 0, 0, 0, 0, 0, 0, 0, 0
sending bytes 0, 0, 0, 0, 0, 0, 0, 0
sending bytes 0, 0, 0, 0, 0, 0, 0, 0
sending bytes 0, 0, 0, 0, 0, 0, 0, 0
sending bytes 0, 0, 0, 0, 0, 0, 0, 0
sending bytes 10, 11, 12, 13, 0, 0, 1, 0
TemperGetTemperatureInC: Broken pipe
I’ve also tried the Perl module, Device::USB::PCSensor::HidTEMPer. That doesn’t seem to support the device either.
Here’s the device:
Bus 003 Device 002: ID 0c45:7401 Microdia
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0c45 Microdia
idProduct 0x7401
bcdDevice 0.01
iManufacturer 1 RDing
iProduct 2 TEMPer1V1.4
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 59
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 100mA
It’s saying it’s V1.4, could this be the problem? Has anybody found a solution?
Thanks very much!
July 11, 2013 at 7:15 pm |
I can provide a USB log from Windows of communication with TEMPerV1.4 and the temperatures reported by the Windows program, if anybody is able to use this information to update the driver to support this version. Just let me know.
July 21, 2013 at 6:24 am |
How can I make the output display fahrenheit?
July 27, 2013 at 5:03 pm |
Hi all
The http://www.isp-sl.com/pcsensor-0.0.1.tgz file is not there anymore, dose anyone know where to find it?
Thanks very much
July 28, 2013 at 12:34 pm |
Found it, http://lineurepoye.net/brol/pcsensor-0.0.1.tgz and it worked perfectly for my system centos 5, perl1.10.0.
The version of sersor I got was ID 0c45:7401 Microdia
April 12, 2014 at 1:19 pm |
Greetings,
I’m attempting to use the TEMPer device [ ID 0c45:7401 Microdia ] on CentOS 6.5. I’ve done a fresh compile of the pcsensor source, (which required me to “yum install libusb-devel” FYI) and was thrilled to see the following output:
2014/04/11 22:28:10 Temperature 66.88F 19.38C
Unfortunately, it’ll only work one time. Each subsequent run I receive the following error:
USB interrupt read: Resource temporarily unavailable
Fatal error> USB read failed
Does anyone have a pointer to resolve? The message would imply that the previous execution has not ended, but pcsensor does not show up as a running process.
Other than restarting the machine is there a work around even if I can’t fix it? This is the only USB device on this host, so I could kill and restart USB, for example, if that would clear it. Not sure how to do that.
Thanks,
John
April 12, 2014 at 3:16 pm |
Following up here; I recompiled with debug messages on and got the following pertinent differences when it fails:
lvr_winusb with Vendor Id: c45 and Product Id: 7401 found.
USB error: could not detach kernel driver from interface 0: No data available
Device already detached
USB error: could not detach kernel driver from interface 1: No data available
Device already detached
01 01 1d d2 e9 7f 00 00
01 80 33 01 00 00 00 00
USB interrupt read: Resource temporarily unavailable
Fatal error> USB read failed
So something about the detach seems not to be working, or the logic around the detach is wonky.
At least I found a quick way to restart USB on my CentOS box:
http://www.zedt.eu/tech/linux/restarting-usb-subsystem-centos/
Thanks
John
May 22, 2014 at 7:27 am |
[…] Friday, that project will be immediately dropped and then I will move on to document and test this driver for the TEMPer Thermometer on my […]
August 24, 2014 at 12:31 pm |
I’ve fixed “Resource temporarily unavailable” error in pcsensor.c.
Please down load and test program.
http://toshiokk.dip.jp:8008/pcsensor-1.0.3.tgz
Thanks to the previous authors of the pcsensor.c.
October 30, 2014 at 12:17 pm |
yum install libusb-devel libusb glibc
tar -xzf pcsensor-1.0.3.tgz && cd pcsensor-1.0.3
make clean && make && make install && make rules-install
udevadm control –reload-rules
Tested & working on CentOS 6.5, x86_64.
Thank you!
November 8, 2014 at 5:18 am |
Alex, Thank you for your testing on CentOS, x86_64.
My OS is Ubuntu 12.04(i386). I’m happy hearing it’s woring on 64 bit environment.
Thanks again to the previous works.
November 18, 2014 at 7:27 am |
Did you manage to get it work on Ubuntu 12.04? My 12.04 x64 works for the first time only, the following calls give the error:
USB interrupt read: Resource temporarily unavailable
Fatal error> USB read failed
…and I have to unplug and replug the device to have it working (once) again
Thanks
Andrea
November 18, 2014 at 7:29 am |
Sorry, I did download the http://toshiokk.dip.jp:8008/pcsensor-1.0.3.tgz but actually not tested it.
I tried to use that and… it works!
Thank you
Andrea
January 11, 2017 at 5:21 am |
updated version of original code containing suggestions from threads here at https://github.com/mnalis/TEMPer-DX
September 28, 2017 at 2:16 pm |
Hello, I have modified pcsensor-1.0.0 to support TEMPer2 and TEMPerHUM.
And also, I changed libusb-0.1 -> libusb-1.0 to be able to build on not only Linux but also Solaris.
https://github.com/shakemid/pcsensor-temper
Thank you!
October 26, 2021 at 9:27 pm |
[…] Here is a reference to Brando USB Thermometer. Article reference for the same (do read this through). A derkeiler 2.6 Kernel patch thread from there. And at the end a recent posting reference: TEMPer Temperature Sensor Linux Driver. […]