HR92 Observations on temperature and control processing

[g6ejd]

OK thanks, then it must be a thermocouple bead device calibrated via software for linearity as there are no sensors on the market with that resolution, not digital types anyway. Noting resolution is not the same as accuracy.

[paulockenden]

I meant to take a look at the HGI80 code in Domoticz today, because I'm not convinced that the HR92s are reporting with that resolution.

As this is coming via the API it could be a moving average, for example.

Where's Dan when you need him - he'd know.

[DBMandrake]

OK thanks, then it must be a thermocouple bead device calibrated via software for linearity as there are no sensors on the market with that resolution, not digital types anyway. Noting resolution is not the same as accuracy.

I didn't say the accuracy was 0.01 degrees. Resolution is 0.01 degrees over the Ramses protocol but accuracy is probably more like 0.1 degrees.

I've tested both of my DTS92's against a weather station system with indoor sensor and the indoor sensor agreed with both DTS92's within 0.1 degrees after they had both had time to settle to a constant room temperature and were placed next to each other. (The weather station readout only goes to 0.1 degrees)

Actual sensor A/D resolution might be quite a bit coarser than 0.01 though - out of curiosity I exported my Domoticz log for the living room as csv, sorted on temperature then removed duplicates to see what the minimum step size appears to be. This zone uses a DTS92 for the sensor. This is the result:

Temperature
14.8
15.02
15.25
15.32
15.39
15.46
15.54
15.69
15.91
16.06
16.13
16.35
16.57
16.8
17.02
17.24
17.46
17.68
17.91
18.12
18.35
18.5
18.57
18.79
19.01
19.23
19.46
19.68
19.9
20.12
20.34
20.49
20.57
20.64
20.71
20.78
20.93
21.01
21.16
21.23
21.38
21.45
21.6
21.67
21.89
22.12

The smallest interval I see there is 0.07 degrees.

Here is the bathroom, which uses the HR92 as the sensor. There are so many more discrete values from the HR92 that I've only posted a narrow slice of the temperature range as the full data from 10 degrees to 25 degrees included 561 discrete values!

15
15.02
15.03
15.04
15.08
15.09
15.1
15.11
15.12
15.14
15.17
15.18
15.2
15.22
15.23
15.24
15.28
15.29
15.3
15.31
15.36
15.38
15.39
15.41
15.43
15.44
15.46
15.47
15.48
15.49
15.5
15.52
15.53
15.54
15.55
15.56
15.57
15.59
15.61
15.62
15.65
15.66
15.67
15.68
15.69
15.7
15.74
15.77
15.79
15.8
15.81
15.82
15.83
15.84
15.85
15.86
15.88
15.89
15.92
15.94
15.95
15.96
15.97
15.99
16
16.01

The smallest interval I see is 0.01 degrees.

Here is the Evotouch's built in temperature sensor from the hallway zone:

15.02
15.03
15.04
15.11
15.12
15.13
15.16
15.2
15.22
15.25
15.31
15.32
15.34
15.35
15.39
15.4
15.43
15.44
15.45
15.47
15.53
15.54
15.59
15.62
15.63
15.66
15.69
15.72
15.73
15.75
15.76
15.78
15.82
15.84
15.85
15.9
15.91
15.94
15.95
15.97
16

Resolution seems similar to the HR92.

My conclusions are:

1) The Ramses protocol supports sending temperatures to 0.01 degree resolution over the air. I've seen this reported elsewhere by those who reverse engineered the protocol and the above seems to confirm it.

2) The A/D resolution of the DTS92 appears to be about 0.07 degrees as no two readings are closer together than this.

3) The A/D resolution of the HR92 is much greater and appears to be at least 0.01 degrees. Not surprising when the DTS92 came out many years before the HR92.

4) The A/D resolution of the Evotouch sensor is similar to the HR92.

4) Accuracy of the DTS92 seems to be at least 0.1 degrees.

5) Accuracy of the HR92 I'm not sure of - I haven't done critical comparisons like I have of the DTS92 but in more casual testing it appears to be at least as good as 0.5 degrees (when the radiator is cold of course) and I have no reason to believe its not as good as the DTS92. (But in real world use the DTS92 will be much more accurate since its measurement location in the room is far superior)

6) Accuracy of the Evotouch built in sensor is poor without calibration - I find I have to set it to -1.0 degrees to match a DTS92 - this is probably due to the internal heating from the CPU/display backlight/battery charging etc. Once calibrated it seems good though as long as you leave it on the stand/wall mount and don't handle it.

Pity that temperature readings shown by the controller and V2 Web API/phone apps are biased 0.5 degrees towards the set point then rounded to the nearest 0.5 degrees. Full resolution without biasing can be obtained with an HGI80 or using the V1 Web API.

[DBMandrake]

I meant to take a look at the HGI80 code in Domoticz today, because I'm not convinced that the HR92s are reporting with that resolution.

As this is coming via the API it could be a moving average, for example.

Where's Dan when you need him - he'd know.

You use Domoticz with an HGI80 - try what I did using the HGI80 instead of the Web API. Export a zone with a particular sensor type as CSV, in Excel sort on the temperature column then remove duplicates based on the temperature column to get data similar to mine.

If we see the same 0.07 resolution from a DTS92 but 0.01 from an HR92 we know that the V1 Web API data is probably not smoothed/averaged/tampered with.

[paulockenden]

With the HGI80 the reported resolution (in the CSV exports) is 0.1, both in the traffic from the HR92s to the controller, and also the setpoint data going the other way.

[DBMandrake]

With the HGI80 the reported resolution (in the CSV exports) is 0.1, both in the traffic from the HR92s to the controller, and also the setpoint data going the other way.

Interesting, when the Ramses protocol itself supports 0.01 degree resolution. I tried to find the my original reference to support this but I can't locate it just at the moment.

So are you thinking the V1 API data is interpolated, or is it possible that the current Domoticz code for HGI80 just doesn't use the full available resolution from the over the air messages and just rounds to the nearest 0.1 degrees ?

The modified high resolution version of the Domoticz Web API script (evo-update.sh) simply retrieves the value as is from the V1 API which includes two decimal places unless the second decimal place would have been a zero.

I think it's more likely that the Domoticz HGI80 code rounds to 0.1 degrees - if it was a case of interpolation on the server creating in between values that weren't sent from the controller I don't think we'd see a granularity of 0.07 degrees for a DTS92 but 0.01 degrees for an HR92.

Where is DanD when you need him.

[g6ejd]

I have concluded the HR92 temperature accuracy is very good, probably achieved by using a bead thermistor with known temperature resistance transfer function that is non-linear but corrected for in software. Using a Flir IR system or Bosch IR temp gun or a cheap temp gun all report the same temperature as the HR92. Recently I have used a precision temperature sensor a Senserion SHT35-D that is certified to 0.1 deg accuracy and that too correlates with the HR92 readings, so it's a good assumption that HR92 temperature reports reflect the real world.

[paulockenden]

There are loads of digital temperature sensors out there with this kind of resolution. I've used the LM95172 on a few projects, but it isn't the only player in town.

Even the ever popular DS18B20 has a resolution of 0.0625°C when working 12 bit mode, but you really need a 15 bit (or higher) device for 0.01 accuracy.

But I'm STILL not convinced that the HR92 is actually reporting with that accuracy. The only evidence so far has taken a journey from the HR92, through the controller, out to the Honeywell cloud servers and then back again. Someone along that path there could be some simple moving average calculation happening, which might be cause of the perceived resolution.

Over the w/e I'll try to actually log the packets from the HR92 so that we can get to the bottom of this.

[DBMandrake]

I have concluded the HR92 temperature accuracy is very good, probably achieved by using a bead thermistor with known temperature resistance transfer function that is non-linear but corrected for in software. Using a Flir IR system or Bosch IR temp gun or a cheap temp gun all report the same temperature as the HR92. Recently I have used a precision temperature sensor a Senserion SHT35-D that is certified to 0.1 deg accuracy and that too correlates with the HR92 readings, so it's a good assumption that HR92 temperature reports reflect the real world.

Just curious, in your testing how were you obtaining the temperature readings from the HR92 when comparing them to your reference devices ? And I'm assuming you pointed the IR gun at the body of the HR92 ?

I think it's fair to say that the HR92's sensor itself is very accurate, far more than it needs to be in fact, however that doesn't necessarily translate into a good measurement of room temperature because there are so many other factors to be considered like localised heating from the radiator (is it mounted on the hot or the warm return side of the radiator ? At the top or the bottom ?) whether there are good convection currents through the room, whether it is obscured by furniture, decorative radiator boxing, towels etc.

The simple answer is that it does very well at sensing room temperature in some rooms and very poorly in others depending on the room and radiator topology. There is nothing further that Honeywell could have done to solve problematic rooms while measuring from the radiator though - sometimes a remote sensor is the only real solution, and unlike some other systems (including manual TRV's!) you always have the option to add a remote sensor to a zone if you desire or require. They're over priced IMHO (a very inexpensive, unobtrusive sensor only unit with no buttons, display or markings of any kind is needed in the lineup) but they are easy to bind and add to the system.

There are loads of digital temperature sensors out there with this kind of resolution. I've used the LM95172 on a few projects, but it isn't the only player in town.

Even the ever popular DS18B20 has a resolution of 0.0625°C when working 12 bit mode, but you really need a 15 bit (or higher) device for 0.01 accuracy.

So the 0.07 minimum increment that I saw from my DTS92 could indicate the sensor in the DTS92 is sampled at 12 bit resolution ?

But I'm STILL not convinced that the HR92 is actually reporting with that accuracy. The only evidence so far has taken a journey from the HR92, through the controller, out to the Honeywell cloud servers and then back again. Someone along that path there could be some simple moving average calculation happening, which might be cause of the perceived resolution.

Over the w/e I'll try to actually log the packets from the HR92 so that we can get to the bottom of this.

I love the nerdy dedication the three of us have to small details like this - the rest of the forum members are probably looking at this and thinking "weirdos".

I found the document that I was thinking of that described how temperatures were encoded in the Ramses protocol, its a partial reverse engineering of the protocol that helped the initial Domoticz support:

http://www.domoticaforum.eu/download/file.php?id=1396

It was linked in this discussion thread:

http://www.domoticaforum.eu/viewtopic.php?f=7&t=5806&start=30#p53269

3.2. Byte order, data formats
For each multi-byte (16 bit unsigned, 16 bit signed, 24 bit) values the byte order
is little-endian (MSB first).
The data format for temperatures is a 16 bit signed integer value, the units are
1/100 Celsius; if not otherwise indicated.

There should be enough information in that document for you to be able to decode a temperature reading packet by hand if you were so inclined. However only logging a lot of readings over time and then finding all unique values (as I did with excel) would give a true idea of what the resolution is.

The other option would be to look at the part of the domoticz code that processes the temperature readings to see how it's handling them and whether it is truncating to one decimal place. I notice that some parts of Domoticz (including the floating value box on graphs) only display one decimal place even when the raw data has two decimal places so it seems certain parts of Domoticz do truncate to one decimal place for temperatures, at least for display.

[killa47]

I love the nerdy dedication the three of us have to small details like this - the rest of the forum members are probably looking at this and thinking "weirdos".

I quite enjoy reading everybody's contributions - often on topics not relevant to my system. Keep being nerdy folks - it's fun and highly intellectual (I think!).

[g6ejd]

The ability of the HR92 to use an external sensor suggest the use of a cheap thermistor just like the CS92, which I have measured at 10Kohm at 20 and when I look up the standard devices or availability of external probes unsurprisingly 10K variant figure widely, so I then suggest the internal sensor is also a thermistor as it would make good design sense to either and external or internal sensor of the same type, keeps costs down too and no RFI issues with the longer cable. Plus they are low cost. Adjusting the non-linearity and calibration (thermistors have good repeatability) in software is easy, so then what controller are they using, most only have 10-bit ADC and assuming a 5v supply (most likely given its design age) gives a typical resolution of (if 5/v per-unit of temperature) of 0.007, but that would be stretching the limits of design, so say a 3v span, then that's a 0.003v resolution, which is more than enough for most purposes. Not seen inside an HR92, but the moment we do we shall know

I measured the HR92 reported temperatures qualitatively by painfully waiting for the screen to transition between readings (having turned the heat up) and measured when they changed, it the only reference I have. When I get time I'll get the RPi up and running to operate the software and get another dimension into the system. Also my use of the SHT35-D sensor with an Arduino (or ESP8266) gave identical results compared with the HR92 and that comes with a calibration certificate to cover its 0.1°C accuracy (actual production spread is up to +/-0.2C, but mine is in the inner quartiles) so I know that's correct, unlike any other devices that have a relatively poor and typical accuracy of +/-3.5°C. From a production designer point of view though, these high resolution chips (and where needed high accuracy) are just too expensive even in volume. The SHT35D is about $40 but a thermistor probably 1$ with some (free) software to make it near identical is how I'd do this.

I've also got 3 IR guns, one I use for my model aircraft engines, one a Bosch PTD1 and a cheap eBay variant and for comparative readings a FLIR Camera attachment for my iPhone, but qualitatively they all read the same, so I presumed I have a good confident knowledge of the HR92 external temperature. But, one only has to move the sensor a few cms and different readings are obtained. I have been comparing two reference temperature chips HDC1010 and SHT31-D both with factory calibration certificates (luckily I did not pay for them ) and could not get them to correlate, often with 0.5C difference, then I applied the simple expedient of placing a plastic cup/cap over them and within minutes the readings were identical and that's on my desk, so micro air currents can give differences in readings of devices that were separated by just 1cms. Now I use that technique I can get them correlate all the time, and it's what I do for other sensor comparisons I'm doing. For my environment this is about the best I can do.

[DBMandrake]

The ability of the HR92 to use an external sensor suggest the use of a cheap thermistor just like the CS92, which I have measured at 10Kohm at 20 and when I look up the standard devices or availability of external probes unsurprisingly 10K variant figure widely, so I then suggest the internal sensor is also a thermistor as it would make good design sense to either and external or internal sensor of the same type, keeps costs down too and no RFI issues with the longer cable. Plus they are low cost. Adjusting the non-linearity and calibration (thermistors have good repeatability) in software is easy, so then what controller are they using, most only have 10-bit ADC and assuming a 5v supply (most likely given its design age) gives a typical resolution of (if 5/v per-unit of temperature) of 0.007, but that would be stretching the limits of design, so say a 3v span, then that's a 0.003v resolution, which is more than enough for most purposes. Not seen inside an HR92, but the moment we do we shall know

Where did you read that you can use an external (hardwired) temperature sensor on the HR92 ? As far as I'm aware this is not possible, so the whole paragraph above is predicated on this misunderstanding of the HR92's capabilities.

You can connect a window sensor to the little connector under the hatch - but this is a simple on/off switch input designed to be connected to a reed switch mounted on a window (or door) frame, it doesn't support a temperature sensor. And for that matter, although a plug/cable is listed in Honeywell documentation I have yet to actually find it on sale anywhere!

I measured the HR92 reported temperatures qualitatively by painfully waiting for the screen to transition between readings (having turned the heat up) and measured when they changed, it the only reference I have. When I get time I'll get the RPi up and running to operate the software and get another dimension into the system. Also my use of the SHT35-D sensor with an Arduino (or ESP8266) gave identical results compared with the HR92 and that comes with a calibration certificate to cover its 0.1°C accuracy (actual production spread is up to +/-0.2C, but mine is in the inner quartiles) so I know that's correct, unlike any other devices that have a relatively poor and typical accuracy of +/-3.5°C. From a production designer point of view though, these high resolution chips (and where needed high accuracy) are just too expensive even in volume. The SHT35D is about $40 but a thermistor probably 1$ with some (free) software to make it near identical is how I'd do this.

I wouldn't place much faith in comparisons done by looking at the HR92 display for a few reasons:

1) The reading is rounded to the nearest 0.5 degrees.

2) The reading is biased 0.5 degrees towards the set point. This means if the real temperature is 20 but the set point is 23 it will read 20.5, while the if the real temperature is the exact same 20 degrees but the set point is 15 degrees it will read 19.5! Not much use for doing accurate comparisons, and this biasing of the reading towards the set point (which is also done on the controller, iphone app and wall mounted stats) is one of my pet peeves about the evohome as it is completely unnecessary and misleading.

3) The temperature reading from the HR92 is sent to the controller every 4 minutes and at some point after that it is sent back to the HR92 and at some later point than that the display updates. (The motor reacts to new temperature information a good 30 seconds or so before the display updates for some reason) So the reading on the display can easily be 5 minutes or more behind the real temperature because I don't think the temperature reading transmission interval from HR92 is synchronised with the controllers sending back of the temperature. Because of this semi-random round trip delay from HR92 sensor to controller, back to HR92 and then to its display, you're best to only do accurate comparisons with a steady room temperature.

This is necessary anyway because even if there wasn't a transmission delay different temperature sensor have different response times so under a constantly changing room temperature they're going to read differently anyway.

I do my comparisons using a constant steady room temperature, and using the V1 Web API, which I can either check on my Domoticz dashboard, or by running a script I have that will immediately query the Honeywell API readings on demand. (As Domoticz only polls the servers every 5 minutes) Typically the delay between the controller receiving a new temperature reading and forwarding it to the Honeywell servers is less than 10 seconds.

As I don't have an HGI80 the V1 Web API is the only source of unbiased (towards the set point) un-rounded temperature readings from the system I have.

[g6ejd]

I'm an engineer I don't read manuals I look at pictures and saw what appeared to be an external sensor and assumed it a was a remote temperature probe - duh, so it's a simple reed relay contact for detecting if the window has been opened.

I have the HR92 set to display room temperature and the transition was the only reference I had, but as you say there is this rounding and maybe a rolling average going on, so who knows.

Thanks for the insight and for actually reading the manual

[paulockenden]

I've just cracked open a spare (broken) HR92. Can't see anything that looks like a bead thermistor. It's all very tiny surface mount stuff.

I need to get the magnifying glass out!
IMG_20161202_140933.jpg

P.

[g6ejd]

Wifi is bottom right area with the Orange 6-leg device and shielded pcb area. Interesting to see provision for a flexible ribbon cable and a slot through the pcb for it, but why? It looks like a variable resistor top middle which may be for calibration. They could be using a processor temperature sensor as most have that capability but self-heating even by these low power devices would be a problem, but having a sensor near the edge seems favourite otherwise it's sitting in a climate that does not reflect the room temperature and thermal enertia would be high if not near the outer casing. Intruiging insight, thanks for doing this. Lots of automatic test equipment measurement points suggests high volume production rates to me, they have probably built many 1000's of them and at speed.