Smart meter installed

Finally! It took 2 days off, 2 months, 5 phonecalls to Liander and 5 men to install the smart meter in our house. But after it was installed, the smart meter was ‘online’ in a matter of minutes! šŸ˜‰ An FTDIĀ TTL-232R USB cable (5V), RJ-11 connector and Maarten’s blog post were all that was needed to get the P1 output logged to a file:



Because I didn’t want to wait till (maybe) 2020, I appliedĀ Ā for a priority installation of a smart meter in our house in June this year. On July 2nd a mechanic showed up, but his visit was a very short one – I didn’t have the right gas valve (the mechanic called it a “wilson” valve…). Apparently this valve wasn’t good enough anymore, so it had to be replaced before the smart meter could be installed. This mechanic told me that over time the grease inside this “wilson valve” would dry up, which increases the friction inside the valve and the valve would not completely close anymore, no matter how hard the valve knob was turned. Result: gas leakage and nothing you can do about it.

The mechanic made some pictures of the valve and sent them to Liander; Liander would call me, he said. Okay, let’s cut them some slack; 3 weeks later we’d go to Italy on holiday, so I decided to postpone this mission till after we returned. But after I went back to work for a week or 2 and still hadn’t heard anything from Liander for 7 weeks, I decided to call them myself.

After 3 phonecalls to get in touch with the right person, the new date was set to september 3rd. The 2 men that came to our house last Monday told me they also had to replace the gas piping, so they started digging a hole in our front yard. Later that morning the electrician arrived; with the wrong meter: 3-phase instead of single phase! Someone else had to bring the right meter – so now there were 4 people working on our smart meter… all for the price of 70 Euro’s šŸ™‚

Around noon everything was working again. Well, not everything… The gas meter doen’t seem to be ‘paired’ with the power meter as can be seen in the output of the P1 port:


The number in red should display the gas usage and the blue number should be a recent timestamp. This could change in a few days, cause from what I’ve heard the pairing can also be done from a distance. I hope this doesn’t take too long, cause I’m in the dark regarding our gas usage now, cause counting the pulses of the rotating mirror is not possible anymore; there’s an LCD on the gas meter now.

I can still monitor the power usage though, with my DIN rail mounted KWh meter with S0 output.

And now it’s time to find a way to feed the P1 output to my system, cause USB is not the best option for that!

Opentherm Gateway statistics

I had a different post in mind (smart meter follow-up) but hey, if questions arise and I’m interested in the answers just as much, I’m flexible šŸ˜‰

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).

Conclusions, assumptions?

  1. 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.
  2. 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?
  3. 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.
  4. 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!