Temperature discrepancy
Collapse
X
-
I've got to be honest I didn't really understand all that, it seems like there's some biasing and averaging going on, but I don't really understand why the wall display can't just display what the sensor is reading, would've thought it would be quite simple rather than trying to overcomplicate it with algorithms.
Something else I don't like is why the sensors only display 0.5 degree increments when they are obviously more sensitive than that. I have no issue with set points incrementing in half-degrees but I would actually quite like to know how many tenths away from a set point the actual temperature is, then I might understand the TPI schedule and random boiler firings a bit better. I just feel that 0.5 degrees accuracy is too coarse.
Comment
-
-
Originally posted by therealfronty View PostI've got to be honest I didn't really understand all that, it seems like there's some biasing and averaging going on, but I don't really understand why the wall display can't just display what the sensor is reading, would've thought it would be quite simple rather than trying to overcomplicate it with algorithms.
None of the temperature displays on the Evohome devices including wall thermostats show the real temperature. They are all biased towards the set point up to half a degree then rounded to the nearest half degree after that.
As there are delays in temperature readings being sent between devices it's perfectly normal to see a 0.5 degree discrepancy between what is shown on two different devices for a period of time as well. (Also I get the impression that not all the devices use the exact same algorithm so there could be a few raw temperature readings that result in a different displayed temperature on different devices due to slightly different biasing and rounding algorithms)
Something else I don't like is why the sensors only display 0.5 degree increments when they are obviously more sensitive than that. I have no issue with set points incrementing in half-degrees but I would actually quite like to know how many tenths away from a set point the actual temperature is, then I might understand the TPI schedule and random boiler firings a bit better. I just feel that 0.5 degrees accuracy is too coarse.
My temperature graphs which poll the V1 API show raw temperature to two decimal places, and that makes for much nicer smoother temperature graphs than one rounded to 0.5C.Last edited by DBMandrake; 18 October 2021, 11:52 AM.
Comment
-
-
Originally posted by DBMandrake View Post[...] or poll the V1 Web API for the data.
Comment
-
-
Originally posted by MJNewton View PostDo you know if the Lyric T6 range can be polled via the v1 web API?
I am currently using the v2 API to read various things from mine but might investigate the v1 API if other information is available through it.
In all other regards the V2 API is superior. For example the V1 API doesn't support reading or modifying schedules. The V2 API also uses a better authentication mechanism.
It's possible to poll both API's for data, (temperatures from V1, everything else from V2) however there is some suggestion from my experimenting that the authentication rate limiting that Honeywell applies might apply cross API - so that it would count towards rate limiting as two separate authentication attempts in a short space of time.
Whatever method you use it's important to try to cache and re-use session tokens as much as possible to minimise fresh authentication attempts.Last edited by DBMandrake; 20 October 2021, 07:31 PM.
Comment
-
-
Originally posted by DBMandrake View PostI only have an Evohome system so I don't know. Give it a try! It will either work or not. I use the watchforstock Python client bindings - they work with both API's.
The only benefit in the V1 API, at least for an Evohome is fine grained temperature readings. (Two decimal places with no funky biasing or rounding)
The V2 API also uses a better authentication mechanism.
It's possible to poll both API's for data, (temperatures from V1, everything else from V2) however there is some suggestion from my experimenting that the authentication rate limiting that Honeywell applies might apply cross API - so that it would count towards rate limiting as two separate authentication attempts in a short space of time.
Whatever method you use it's important to try to cache and re-use session tokens as much as possible to minimise fresh authentication attempts.
Comment
-
Comment