Today 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);
dowtod:begin
{ TODO : Finish }
end;
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.
http://www.partsim.com/