0 votes
In this discussion the problems of maintaining decent CPU temperatures in the midst of the Australian Summer were explored.

This prompted the question - Just how hot is the area where the systems are located? Initial searches to find a server connected digital thermometer proved it would be too expensive - until a hit on this article Checking ebay found I could obtain two for $16.18 USD with free shipping - that's reasonable. Why two? The firewall and two modems (cable and adsl) are in the living room, while the majority of the systems are in a home-office at the opposite end of my unit (apartment) connected by Ethernet-over-Power and Wifi.

The units duly arrived - the Linux source code was modified as described in that article on phoronix as my own trial proved it was necessary. Initial tests indicated the temperature was a little higher than it should be when compared to an accurate bulb thermometer. This was not due location as both are connected to USB extension leads so they are not subjected to direct hot air from the system, radiated heat from the cases, or conduction by being directly connected to a USB socket in the system which would be higher than ambient.

Looking at the source we have this

... snipped
static int substract = 0;
... snipped

Obviously a known problem and a simple fix :-) just changed the 0 to my offset and re-compiled.

The next problem found was that very occasionally a read temperature would fail - a simple shell script to retry on failure fixed that - have had no failures after a retry.

With that working - was a simple matter to use mrtg to graph the results. As can be seen with the sharp temperature decline - summer is now over here, but all is set-up and ready for the next one...

Wednesday, April 05 2017, 05:31 AM
Share this post:
Responses (4)
  • Accepted Answer

    Monday, May 11 2020, 04:04 AM - #Permalink
    0 votes

    The original purchases are still in producion and working. Bought another TEMPer
    device. However, found it came with different Windows software and nothing for
    Linux. The older linux software will not work with this newer device.

    Using "lsusb" we find the following :-

    ID 413d:2107 # newer device
    ID 0c45:7401 # original device

    A search on the Internet found This web-site with instructions...

    Substitute "yum" for "dnf" for CentOS 7.x / ClearOS 7.x. ("dnf" is for Fedora)
    If you don't have cmake installed, add that "yum install hidapi-devel bc cmake" You
    also need to have the usual development libraries installed, of course.

    Follow the directions. Don't forget the dot on the line "cmake ."
    You may also need to create the /usr/local/bin directory.

    The web-page script provided may have problems with back-ticks and single quotes depending
    on your code page. You may want to download my version (for /dev/hidraw1 - edit if yours is different)


    It is now in production...
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, April 05 2017, 01:27 PM - #Permalink
    0 votes
    Yes, it was just a technical comment from my dim and distant memory, I remember a blast furnace being used as an example where different thermometers would read 10's of degrees out. I agree over a small temperature range, assuming the response is linear is probably not a bad assumption but I'm not qualified to make a judgement.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, April 05 2017, 01:16 PM - #Permalink
    0 votes
    The bulb thermometer I am using is an expensive one from the days when I worked in a darkroom developing colour film for colour separations used in the printing industry. It only covers a limited range of temperatures, nowhere near 0 -> 100. So far the USB thermometers have tracked closely with my 'standard' over the temperature range encountered so far. The USB thermometers usually use an integrated circuit for measurement but not sure if the ones here are using the bulk resistance characteristics of semiconductor material which changes with temperature or the forward biased voltage across a diode which has a temperature coefficient of about 2.3mV/°C - suspect it is a diode as these are less susceptible to self-heating, cheaper and quite linear over a limited temperature range if the bias current is kept constant, which is easily controlled by the IC. It's more than accurate enough for me - I'm not controlling some sensitive scientific apparatus that requires a reading to within 1/100th of a degree :D Here is a typical readout from the Linux program...

    [root@danda ~]# /usr/local/bin/temperature
    2017/04/05 22:44:46 Temperature 71.94F 22.19C

    This is the script with retry

    #! /bin/bash
    # 28 Feb 2017 - Version 1.0 - created by Tony G Ellis
    # one retry if read failure - if that retry fails do not update value in /tmp/room_temp.txt
    # 01 Mar 2017 - Version 1.1 - removed script debugging
    # 03 Mar 2017 - Version 1.2 - log failures to a separate file


    field_3=`echo $temperature | awk '{print $3}'`

    if [[ $field_3 != "Temperature" ]]; then
    sleep 10
    field_3=`echo $temperature | awk '{print $3}'`
    echo `date` 'USB read failed...' >> $failfile

    if [[ $field_3 != "Temperature" ]]; then
    echo 'USB read failed... for a second time' >> $failfile
    echo $temperature | awk '{print ($5*100)}' > /tmp/room_temp.txt
    echo $temperature >> $logfile

    for mrtg we only want the °C reading multiplied by 100 to eliminate the decimal - the temperature is read every 5 minutes.
    Here's a section of the 'failure' log showing approximately how often a re-read is necessary

    Wed Apr 5 09:49:07 AEST 2017 USB read failed...
    Wed Apr 5 11:09:06 AEST 2017 USB read failed...
    Wed Apr 5 12:29:07 AEST 2017 USB read failed...
    Wed Apr 5 13:49:06 AEST 2017 USB read failed...
    Wed Apr 5 15:09:06 AEST 2017 USB read failed...
    Wed Apr 5 16:29:07 AEST 2017 USB read failed...
    Wed Apr 5 17:49:06 AEST 2017 USB read failed...
    Wed Apr 5 19:09:06 AEST 2017 USB read failed...
    Wed Apr 5 20:29:06 AEST 2017 USB read failed...
    Wed Apr 5 21:49:07 AEST 2017 USB read failed...

    I have yet to record a failure during a retry... not a single 'USB read failed... for a second time' in the 'failure' log for either the machine in the living room or the machine in the home-office that have the USB thermometers connected.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, April 05 2017, 11:21 AM - #Permalink
    0 votes
    Out of interest, from what I learned many years ago, the temperature response of a thermometer is not linear which makes it very hard to compare temperatures measured with different thermometer types. Even bulb thermometers with mercury and alcohol would be classified as different types. If you calibrate them at two known temperatures e.g. 0 DegC and 100 DegC, for temperatures in between they could read slightly differently. The further apart the calibration points, the more the error in between. I wouldn't even hazard a guess to the usb thermometer type. I could be thermocouple, varistor (?) or some device measuring a junction property or something else. Over a small temperature range comparisons should be pretty good but not perfect. Offsets to a known temperature can be calibrated out as you have done by making the bulb thermometer the reference.
    The reply is currently minimized Show
Your Reply