How to deal with the Opentherm Gateway

After I installed our new thermostat and put the Opentherm Gateway between the cable from thermostat to the boiler, I got things up and running really fast. I had already developed a small application during my Opentherm Monitor adventure and I could reuse most of the code to display the incoming traffic from the Opentherm Gateway.

Opentherm Gateway dataThe 3rd (B/T) and 4th column (“00000000”) is the data received from the OT (Opentherm) Gateway; the rest is added by the application.

The length of an OT frame is 8 bytes and with more than 100 frames per minute this means I’ll have to process an amount of 2.5 MB of OT data per day.

That might seem not that much, but this would mean the OT Gateway would win the gold medal as data producer in our house! (here you can see a list of all interfaces with their respective in- and outgoing streams, reset at midnight)

Well, I can start polling the OT Gateway with the PS command which will stop the OT gateway from reporting each frame, but I don’t like polling and I want to know what’s going on right away!

OK, another approach to reduce the amount of frames could be to locally filter out duplicates per DataID (that’s OT protocol talk) and only report changes; that would reduce the amount of traffic immensely; sounds like a nice job for a JeeNode; add a Digi XBee and I’m done 😉


Wow, not so fast…. now I’m thinking the way I used to – that’s not good. The integration of Opentherm into my system is a good exercise for my wish of transforming my system into a distributed application based on a messaging system. And that’s where I still have a lot of decisions to make.

ZeroMQ or MQTT (Mosquitto)? What should the topic schema look like? How do I keep it all maintenance free, adaptive to changes, etcetera…

I mean, I’ve seen enough examples of a single sensor publishing it’s value to a hard-coded IP address, but that’s not good enough for me – cause if you have a large system, you don’t want that. Nightmares! And this is just a simple example of the challenges I’m facing.

So I really have to think some things over very thoroughly before I proceed. Fortunately I’m not the only one struggling with these issues.

And maybe the choice for a thermostat with built-in schedule was not such a bad choice after all, cause I like to do things only once; the right way.

Maybe I just have to stop doing things for some time and start thinking a bit harder 😉

Tagged . Bookmark the permalink.

6 Responses to How to deal with the Opentherm Gateway

  1. Maurice says:

    Dear Robert,

    Nice work. I myself are building op some KNX automation in our new house. I’d like to couple my Remeha Calenta boiler to KNX through the OT interface. What I read on the internet is that the update rate of boiler data into KNX by means of a commercial solution (KNX-OT box from Theben) is only 30 sec. Increasing polling rate does not help. I don’t know if this is caused by the boiler, the interface or the combination of the 2. Can you give me some values for update rate you obtain by means of the OT Gateway? So what I mean is not the polling rate or anwering rate of the slave, but the rate the requested data of the OT ID’s is actually updated.

    Regards and thanks in advance,


    • Hi Maurice,
      So you want to know the interval with which each data ID is being updated? easy, I can do that.
      I’ll see if I can produce that list of Data ID’s and related update intervals for you this evening.
      I don’t think the OT gateway has any influence on this; it ‘just’ copies all the OT traffic to it’s serial port.
      I think the thermostat (the master) is the device that has the most influence.

      • Maurice says:

        Hi Robert,

        Thanks for the quick reply. To be more specific about my question:

        * the interval each data ID is being updated is also interesting. This rate is indeed determined by the master, since he is asking for it.

        What I actually mean is the interval at which the data which is send over is refreshed. Wether the data (i.e. moldulation rate) which is send over is really “new” (different from the previous values) is determined by the slave/boiler. According to my info, this refresh rate is only 30 seconds, independent on the polling rate of the master.



  2. Pingback: Opentherm Gateway statisitcs - Digits Domotica Blog

Leave a Reply

Your email address will not be published. Required fields are marked *