Yep, I’m going to build a 3rd Opentherm Gateway 
The first one was built on perfboard and became a mess; I never finished it, because before I could the Opentherm Gateway PCB became available, which looked much better. The first PCB version was built somewhere in February 2012 and is in use since August after I replaced the Proliphix NT20e with a Honeywell modulating thermostat.
There’s only one thing I don’t really like that much about the Opentherm Gateway and that’s the serial interface. I like to have all my hardware network-attached, but I’d also like to keep the number of Serial to Ethernet servers to a minimum – right now, I have 6 Serial ports in the meter cabinet (PLCBUS, X10, GSM modem, etcetera) connected to a Serial to Ethernet server. In total, I think I have around 10 serial devices connected that way.
For the third Opentherm Gateway I’m going to try something else; I’m going to leave the MAX232 IC off the PCB and directly connect a Simplecortex to the TTL level output of the PIC that’s on the OT Gateway PCB. This approach has some benefits, like
- The Opentherm Gateway becomes Ethernet enabled;
- Programmable TTL to Ethernet conversion;
- Less €€€;
- Big reduction on network traffic;
- more fun!
Yesterday I started with the Simplecortex firmware for the OT Gateway. I want the firmware to be versatile, meaning that it should not only support the Data ID’s that I see going back and forth between my thermostat and boiler. Fortunately the Opentherm Protocol is documented well enough to be able to write code for Data ID’s I’ve never seen in my life. In fact, the definition of how the firmware should deal with all the Data ID’s found in the OT protocol 2.2, comes down to the following:
typedef enum {Read, Write, Both} CommandType; typedef enum {both, highbyte, lowbyte} ByteType; typedef enum {flag8, u8, s8, f8_8, u16, s16, dowtod} PayloadType; typedef struct{ uint8_t ID; CommandType rw; ByteType whichbyte; PayloadType format; uint8_t bitpos; char* topic; } OTInformation; OTInformation OTInfos[] = { {0x00, Read, highbyte, flag8, 0, "ch_enable"}, {0x00, Read, highbyte, flag8, 1, "dhw_enable"}, {0x00, Read, highbyte, flag8, 2, "cooling_enable"}, {0x00, Read, highbyte, flag8, 3, "otc_active"}, {0x00, Read, highbyte, flag8, 4, "ch2_enable"}, ... ... {0x7f, Read, highbyte, u8, 0, "slaveproducttype"}, {0x7f, Read, lowbyte, u8, 0, "slaveproductversion"} }; |
That’s all there is to it… add about 150 lines of code and the complete set of Data ID’s defined in the OT Protocol 2.2 documentation is supported – no more switch (DataID) with a long list of cases and repeating code…
But I wanted more – I really don’t need to be told that CH is still enabled twice a second; just a report of a change will do. For that I’m going to add a filter that will only report changes. That filter will reduce the network traffic immensely. And of course this Opentherm Gateway will be transformed into a MQTT Publisher, just like my smart meter. And last but not least, this implies that the Opentherm Gateway will act as a MQTT subscriber too, so that I can control the behavior of the OT Gateway and override the thermostat’s temperature setpoint.
Right now, I’m watching the OT Gateway information on my screen as it is being published:
There’s still a lot to do, but considering the fact that I managed to get this far in only a few hours makes me confident that I can finish this project before it starts to get really cold.
Another good thing is that once this project is finished I can shut down the Remeha Calenta driver which has been running for 2 years.
The biggest disadvantage of that driver was that I had to constantly poll the Calenta and that it was based on a protocol specifically targeted at Remeha boilers.
So it all gets much, much better this way!
http://www.partsim.com/