Page 3 of 6 FirstFirst 123456 LastLast
Results 21 to 30 of 56

Thread: HR92 Observations on temperature and control processing

  1. #21
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    2,326

    Default

    Quote Originally Posted by paulockenden View Post
    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.

  2. #22
    Automated Home Guru
    Join Date
    Oct 2016
    Location
    Bath, UK
    Posts
    151

    Default

    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.

  3. #23
    Automated Home Legend paulockenden's Avatar
    Join Date
    Apr 2015
    Location
    South Coast
    Posts
    1,718

    Default

    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.0625C 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.

  4. #24
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    2,326

    Default

    Quote Originally Posted by g6ejd View Post
    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.

    Quote Originally Posted by paulockenden View Post
    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.0625C 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/viewtopi...tart=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.
    Last edited by DBMandrake; 1st December 2016 at 11:38 AM.

  5. #25
    Automated Home Guru
    Join Date
    Jan 2016
    Location
    Harrogate, North Yorks
    Posts
    109

    Default

    Quote Originally Posted by DBMandrake View Post
    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!).

  6. #26
    Automated Home Guru
    Join Date
    Oct 2016
    Location
    Bath, UK
    Posts
    151

    Default

    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.1C 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.5C. 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.

  7. #27
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    2,326

    Default

    Quote Originally Posted by g6ejd View Post
    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.1C 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.5C. 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.
    Last edited by DBMandrake; 2nd December 2016 at 11:08 AM.

  8. #28
    Automated Home Guru
    Join Date
    Oct 2016
    Location
    Bath, UK
    Posts
    151

    Default

    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

  9. #29
    Automated Home Legend paulockenden's Avatar
    Join Date
    Apr 2015
    Location
    South Coast
    Posts
    1,718

    Default

    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.

  10. #30
    Automated Home Guru
    Join Date
    Oct 2016
    Location
    Bath, UK
    Posts
    151

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •