Opentherm Gateway operational

Opentherm Gateway and SimpleCortex side by sideToday I finished the monitoring part of the OpenTherm Gateway. The code running on the Simplecortex had proven to be reliable enough to start using it, so why not do just that ๐Ÿ™‚

The OpenTherm Gateway you see on the right is my older one, built earlier this year and will be replaced by the new one once it’s finished.

Before I could start on the OpenTherm Gateway, I had to fix some issues which were the result of what I did last week. The MQTT driver was not as stable as I hoped; it worked fine for several hours, but it never made it longer than 48 hours, so I rearranged some code and it has been running fine since then.

Another thing I had to fix was that the Touchscreen, which was transformed to an MQTT client, was disconnected from the broker by the time I came home from work. The reason: the Touchscreen goes into hibernation when nobody’s at home to save energy, which leads to the broker closing the connection! Didn’t think of that one.. before, the touchscreen was a UDP listener, in which case there is no real connection… so I added a timer to the Touchscreen application that periodically checks the connection and re-establishes it when needed.

Back to the OT Gateway. The largest part of the work that still had to be done was preparing my Domotica system. The MQTT topics were already being received, but I had to do something about the payloads. The Opentherm Gateway produces a lot of bit values like for instance CH mode (Central Heating mode); payload ‘0’ means not active, ‘1’ means active. Well, I’m not going to pester users with terms like ‘ch_mode 1’ or ‘dhw_mode 0′; Central Heating mode active’ or ‘Hot water not active’ sounds more like it, right… But again, one of my goals is not to put texts like those hard-coded in any piece of code – not on the Simplecortex which publishes the information, nor in a Touchscreen app, or webpage or whatever.

So I felt really lucky that I started thinking about those things a long time ago and introduced so-called ‘Informationtypes‘ in my system in a very early stage. In a few words, an informationtype can transform a value that represents whatever to something a human can understand. For example with a door sensor, ‘0’ will be translated to ‘closed’ and 1 becomes ‘open’; but the same ‘0’ becomes ‘off‘ in the case of an appliance module. My Domotica system already does that for me and exposes both the ‘raw’ values (0/1 in case of booleans, unformatted data in case of numeric values, etc.) as the ‘formatted’ values (on/off, open/closed, floats with the right number of decimals). Raw data is nice, for computers. But not for humans! Currently, there are 150 informationtypes in my system (in the database, of course) ranging from on/off for a switch to the selected input on my AV receiver (0=”BD/DVD”, 1=”CBL/SAT”…).

So all I had to do was publishing those formatted values as well and I could present those values on a webpage and display something really meaningful … a new MQTT root hierarchy was born:ย /value.

And doing things this way, enabled me to reduce the code for the OpenTherm Gateway Device class to (almost) nothing more than this (the rest is all constants and type defs):

  case DataInfo.Format of
    flag8: Pin(iTopic).AsBoolean:=(Payload='1');
    u8,s8,u16,s16: Pin(iTopic).AsInteger:=StrToInt(Payload);
    f8_8: Pin(iTopic).AsFloat:=StrToFloatX(Payload);
      { TODO : Finish }
  end;  //case

So now, when the central heating starts working, there’s (my system being the point of view) “/sensor/OTGW/flame 1” coming in and “/value/OTGW/flame Yes” going out. Now I can make a webpage without displaying meaningless numbers or having to translate those numbers locally that don’t (have to) mean anything to a human.

And here’s the result, showing parts of the information gathered with the OpenTherm Gateway.


Tagged , , . Bookmark the permalink.

4 Responses to Opentherm Gateway operational

  1. Phil says:

    Looks good, but not sure how useful an OpenTherm monitor would be, other than logging the data. It will be (almost) impossible to control your heating system as just changing the room setpoint will not do anything. The control software of an OpenTherm thermostat will not be easy to emulate, therefore other than logging data does it have any other purpose?

    • Phil,
      The Opentherm Gateway is not the same device as the Opentherm Monitor. The Gateway enables you to control the room setpoint, e.g. a serial command TC=20.5 will override the room setpoint and set it to 20.5 degrees. And from there, the thermostat does the rest (i.e. controlling the boiler). I think that’s very useful ๐Ÿ˜‰
      You can read all about the Opentherm Gateway here.

      • Phil says:

        OK I see it must use ID9 and ID100 to give the thermostat a remote override. Just trying to intercept ID24 (Room Temperature) would not have done anything.
        I am just starting designing my own “OT Gateway/Thermostat” to include Z-wave control. Looking at your OpenTherm data it seems your boiler spends a lot of time in low load and very little time modulating.

        • In fact it’s modulating all the time… it may look like it’s not ,but it still is. Modulating means nothing more than that the heat the boiler produces can be adjusted so that it matches the heat demand – not just 0% and 100%.
          The frequent changes between burning and not burning of the boiler (most seen during daytime) are caused by the fact that the heat demand is even lower than the lowest possible continuous heat production of the boiler.

Leave a Reply

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