The question to be answered was: how ‘fresh’ is the data that is travelling from the slave (boiler) to the master (thermostat)?
Is it 30 seconds, as suggested in a comment from Maurice? Quick answer: no.
I added some code to my OT_Decoder tool to collect some statistical data about the Opentherm (OT) frames travelling back and forth and I concentrated on a single Message Type, the Read-Ack.
This message type travels from boiler to thermostat and is in fact a response from the slave to a read-request from the master and can contain values for lots of things like status flags, modulation level, return water temperature etcetera. All these different types of values have been given a so-called Data-ID; status flags = 0, modulation level =17 , return water temperature = 28, and so on. The protocol has room for 256 different Data-IDs.
So when the master sends a Read-Data request to the slave for a particular Data-ID, the slave responds with a Read-Ack frame that holds the Data value.
Here are the statistics I collected:
00 : 0,4 seconds, 4678 times, 5 changes, mintime 4 05 : 57,8 seconds, 66 times, 0 changes, mintime 11 : 59,6 seconds, 64 times, 0 changes, mintime 12 : 58,6 seconds, 65 times, 0 changes, mintime 19 : 4,2 seconds, 787 times,195 changes, mintime 3 1C : 59,5 seconds, 63 times, 55 changes, mintime 59 74 : 235,8 seconds, 16 times, 0 changes, mintime 75 : 235,5 seconds, 15 times, 1 changes, mintime 76 : 235,5 seconds, 15 times, 0 changes, mintime 77 : 235,6 seconds, 15 times, 0 changes, mintime 78 : 235,7 seconds, 15 times, 0 changes, mintime 79 : 235,5 seconds, 15 times, 0 changes, mintime 7A : 235,5 seconds, 15 times, 1 changes, mintime 7B : 235,8 seconds, 16 times, 0 changes, mintime
What does this all mean?
00 is the Data-ID in hex and 0,4 seconds is the average interval between 2 frames measured over 4678 ‘captured’ frames for this particuler DataID. In all these 4678 frames the Data-values changed to another value 5 times and the smallest interval between 2 data value changes was 4 seconds (floored).
- It’s better to do this analysis during the winter, where the boiler is really doing something and let the data collection run for 24 hours or so.
- Data-ID 00 tells me that the boiler must be the limiting factor here, cause the poll rate is much higher then the smallest interval between value changes. But it could also be that the status of the boiler really doesn’t change faster than that; each transition to another phase (going from idle to burning is not just 1 step) will take time; how much?
- Data-ID 1C could lead to the assumption that if the master would poll faster, a lot of data values would show a different value compared to the previous data value.
- The master plays the biggest role in the ‘freshness’, cause it’s the master that dictates what data ID’s the slave has to reply with – no matter how often the slave measures its return water temperature, if the master only requests this temperature once a minute than that’s what you get…
By the way, for those who have their OT Gateway hooked up to a serial port of a Windows PC, have a look at this!