Same Opentherm Gateway, different approach

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:

Opentherm Gateway publishing information

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!

 

Exit Proliphix Thermostat

Time for something new…

Proliphix NT20eThe Proliphix NT20e has been in use for almost 3 years now. The Proliphix thermostat has brought me a lot of fun (integrating it into my Domotica system, working on the Homeseer Proliphix Plugin to add Celsius support) and comfort. But it’s time for a change!

Last year I built a Opentherm Gateway, because we noticed that a modulating boiler performed much better than a on/off controlled boiler -modulation made the “up’s and down’s” in temperatures disappear – the temperature became much more constant, which also made the floor heating much more comfortable than before.

However, the Honeywell Evohome set I used last year didn’t work well with the Opentherm Gateway; I could not override the temperature setpoint with the Gateway, which was the primary reason why I built it 🙁

I don’t know why it didn’t work, but it may have something to do with the EvoHome RF communication being not 100% 2-way?

Honeywell Chronotherm

So yesterday I dismantled the Proliphix and replaced it with a Honeywell Chronotherm Modulation (wired version). The thermostat cable running from the boiler to this new thermostat has been extended so I can give the Opentherm Gateway a place out of sight, connect a Serial to Ethernet server to it and remotely monitor the OpenTherm traffic as well as override the room setpoint.

To be continued…

HB sensors finished and installed

Almost ready to start investigating hydronic balancing (HB) … 😉

 

 

 

 

 

 

 

 

 

 

 

 

Everything is in place and working except for 1 sensor, which is too far away from the receiving JeeNode (which forwards all the data to my Domotica system). So I’ll have to build another RF receiver for that; the missing parts will arrive tomorrow I hope. In the meantime I started creating a webpage to display all the information I want to observe, so I don’t have to switch between browser tabs and go from one page to the other. Another thing that has to be done is program the thermostat, so that the boiler will have to burn at full power for a few hours every day, so that I can see what happens.  I’ve already seen some things that need to be adjusted!

 

Hydronic balancing

This weekend I came to the conclusion that whatever I do, I’ll never get a well performing central heating without hydronic balancing. I’ve been watching how the temperatures in all the rooms of our house react and where the energy goes to – it’s a mess! No matter how well I’ll be able to control the kettle, temperature control in all the rooms will still be a mess without a hydronicly balanced system.

So this weekend I decided to stop what I was doing (building the Opentherm Gateway) and first try to do something about this balancing issue.

Hydronic balancing is not something I’m familiar with, and I certainly don’t have the tools for it ; but what i can do is provide enough information with these sensors; I don’t know if I’ll succeed, but it’s worth to give it a try.

Sensor for Hydronic balancing The first thing I need to know is how much energy flows through the radiators. Well, I can do that, I guess… A JeeNode with RF transmitter and 2 1-Wire DS18B20 sensors can provide me information about how much energy each radiator produces by measuring the flow- and return temperatures of each radiator.

I’ve got a bunch of JeeNode kits still waiting to be used, enough 1-Wire sensors, batteries and all other components needed, so what am I waiting for??

So this weekend I built a first sensor and a RF-to-Zigbee ‘gateway’ so I can receive all the sensors without the need of USB, RS232 or an additional Ethernet port.

The first sensor is operational now; more will follow!

Red = flow temperature, Blue = temperature drop

Remeha interface revisited

Some time ago I received an email from Roel van de Wal. He had been searching for an alternative for the Remeha cable that is listed on page 155 of this document. Price: 90 Euro… Since this cable from Remeha is nothing more than a piece of wire, a USB connector with built-in FTDI chip, it’s not hard to find other places where you can buy this cable; here for instance. And there are numerous others of course.. Adafruit, Sparkfun, you name it. This cable can be very handy – if you don’t need Ethernet or don’t like soldering, this will probably be the easiest/best/quickest option for you.

The only thing left to do was finding out the function of each wire. Last week Roel mailed me the details:

Black – GND
Orange – TXD
Yellow – RXD
Red – +5V
(Brown-CTS &Green-RTS are unused)

The image he sent me shows the wires and a 4P4C connector:

 

Download the FTDI drivers and you’re done, saving you 70 Euro’s!  🙂

Better than the real thing

This time I won’t post about my own Domotica adventures, but someone else’s: Menno van Gennip.  A few days ago Menno posted on the Domoticaforum about his self-made Remeha Calenta interface. For several reasons, his work just needed to be mentioned here.

First of all, the way Menno improved on the TTL-RS232 converter is beyond my knowledge and absolutely a great improvement. Menno added galvanic isolation to protect the Remeha. Second, he added an Ethernet interface based on a Ethernet-serial Wiznet module:

Galvanic isolation

Third, Menno put all the electronics in a nice enclosure including status LEDs:

Inside the enclosure Interface enclosure

Fourth, Menno created 2 Homeseer scripts that makes the whole thing ‘Homeseer-ready’, including CRC checks and all:

Checksum

The screendump below shows the Homeseer status screen with all the information from the Remeha Calenta (click it for a larger view):

And last but not least, the reason why I like Menno’s effort so much is that this is a very good example of what can be accomplished by sharing knowledge; Menno’s knowledge about electronics combined with my earlier findings about the Remeha Recom protocol resulted in a interface that’s even better than the “real thing”, being the Remeha Recom and the Remeha Interface cable ! (for us Domotica enthusiasts, I mean).

Chapeau, Menno!

The surprise-package

As I mentioned earlier, an unexpected package arrived 2 weeks ago. Guess who the sender was: Remeha! That means Remeha must have read my earlier postings about the wonder cable, since this is what came out of the box:

Remeha Recom USB version

The letter that came with it, told me that this cable is a prototype of the Interface cable I wrote about earlier, and that they wished me happy testing with it 🙂

I must admit that this is a very nice gesture of Remeha! Thanks guys!

And of course this prototype is USB; have you ever seen a laptop with RS232 port lately?? No, it’s all USB these days, so if you would ever send out a technician with a laptop to a boiler in trouble, a USB cable is much more convenient than RS-232.

This cable looks very much like the ones i use for my Digi XBees:

3.3V FTDI cable

3.3V FTDI cable

They fit right onto an XBee Adapter and all the stuff that is needed to communicate with a TTL serial device is embedded in the USB connector. That’s why the USB connector is a bit longer than usual. The price of this FTDI cable is around USD 20, so I’m very curious of the price for this new Remeha cable…

Of course, I know why the ‘old’ Recom Interface cable was so expensive; Remeha tries to (partially?) recoup the software development costs by selling it at an unusually high price. But OTOH, these Interface cables are not made for the average consumer, but for professionals; technicians that deal with Remeha boilers on a daily basis and that need the cable for inspection with the use of Recom. I’m curious…

Remeha Calenta connected

The TTL-RS232 converter

The TTL-RS232 converter (click for more detail)

After nearly a full afternoon of soldering, testing, debugging I finished the board shown above. This is not my cup of tea, that’s for sure… 🙁

I forgot to add 1 wire (the red one to the right of the MAX3232) and the whole thing didn’t work… so I checked if all the wires were there, and I still thought they all were; next I checked if the cable coming from the Remeha was 100% OK – it still was; I re-checked all connections; and finally, after 2 hours, I found that capacitor with one leg connected to nothing. That can’t be right.. after I fixed this everything worked as well as on the breadboard. Pfff.. Next time when I solder something similar, I’ll make a hard-copy of the schematic and I’ll mark the components and wires I finished soldering on that hard-copy, so I won’t make this mistake ever again! After connecting the female DB9 to the RFXCOM RS232 module, I was good to go.

This was the hardest part. From this point everything went very smooth:

  • I changed the Calenta Interface settings from using a Serial to using a TCP Connection, as in:
Connection=SER
COMPort=13
Baudrate=9600

to

Connection=LAN
IPAddress=192.168.10.131
IPPort=10002
  • I built my Domotica Delphi project (nothing more than Shift-F9 inside the Delphi IDE);
  • I set the Remeha Interface “AutoRun” property to True in the database, which means it will automatically start whenever my Domotica system restarts;
  • Created a backup of the executable I used until now (v145, with v1 being 5 years old right now);
  • Copied the newly built executable to my Domotica VM;
  • And restarted it…

Ooww yeah, this is it 🙂

A long-cherished wish has been realized; unexpected, relatively simple and cheap!

Calenta charts

Calenta charts

Calendata

Connecting the Remeha Calenta

Normally, connecting a new device means more cables. And I want everything connected to my LAN (or WAN), so I need to convert the RS-232 to Ethernet somewhere.

Although I have Ethernet near the Calenta, that single cable I have over there is being used by my HA7Net, which takes care of counting the hot water usage with a 1-Wire DS2423 counter and measuring the Temperatures of the 5 floor heating groups. So that’s a no go; I can’t use that cable without adding another switch; and I don’t want to, for just 2 Ethernet connections.

Then I realised I still have an unused RFXCOM RS-232 module, and it’s put inside a RFXCOM LAN Interface that’s right above my head (between the ceiling and the roof, that is). This RS232 module was once used for one of my Sony EVI-D30 PTZ cameras with VISCA-protocol, but since this cam has been replaced with a fixed one I don’t actively use this RS-232 module anymore. This saves me a RS-232 to Ethernet converter with another power adapter…

So now I had to find a way to get the cable from the Calenta to this LAN Interface. Getting a 4-core flat phone cable through 2 narrow holes in 30 cm thick walls which are already populated with a bunch of other cables is no fun, but after a few hours I managed to get it through without damaging anything. Pffew..

Now it’s time to get the MAX3232 from the breadboard into an enclosure. I was thinking of creating something like this:

Add a few capacitors, wires, female DB9 connector, a small box and I’m done; and that’s what I’m working on right now. The fact that I’m not able to connect the Remeha directly to my PC anymore (to test the new interface) doesn’t really bother me anymore; I’ve seen enough comparisons of results of my Domotica system and the Remeha Recom software (which needs a COM port) that I’m confident enough that I won’t need Recom anymore to check things; and if I do, I can always use an 32-bit XP machine and a virtual COM port driver for that… it’s time to Ethernet-enable my Calenta and move on!

More about the Remeha protocol

This evening i spent some time on trying to figure out the meaning of all the bytes that make up the response. I already knew where to locate the information inside a packet by a brief analysis of the packets a few days ago, but to make things a bit more stable, I knew I had to dig a bit deeper to find out as much as possible. Cause the more you know, the more checks you can build into the software which results in less chance that invalid packets slip through that could possibly crash the system.

When I started analyzing the responses from the boiler, I started with the Sample command. Here’s an example:

0201FE064802018C145A140080008080F3008003100080401F
701700800000000000BC020000006400000010C20B1000FFFF
00000000FFFF1700BC0200000000000000000000002C4303

I already found out that the part marked in blue contains the payload e.g. the ‘interesting stuff’ some days ago, so let’s focus on the remaining bytes:

0201FE06480201 and 2C4303

The 02 at the beginning and 03 at the end are common values for start- and end bytes, so let’s assume this is the case here also, so now the unknown bytes left are:

01FE06480201 and 2C43

The size (2 bytes) and the position inside the packet (at the end) made me think that the 2C43 could very well be a checksum, and it is: it’s the CRC16 (Modbus variant) of the complete packet without the start- and end byte (and of course the checksum value itself); so based on the packet above the bytes of which the CRC is calculated are:

01FE064802018C145A140080008080F3008003100080401F
701700800000000000BC020000006400000010C20B1000FF
FF00000000FFFF1700BC020000000000000000000000

The Modbus variant of CRC16 calculation differs from a “standard” CRC16 calculation in that the initial value isn’t 0 (zero), but $FFFF. Being able to validate the checksum is very valuable and adds a lot to the robustness of this interface.

So now all that’s left are these leading bytes:

01FE06480201

To understand the 01FE part, I looked at some outgoing packets, these look like this:

02FE010508020169AB03

Again, after removing the start- and stop byte and the checksum we see this:

FE0105080201

Compare this  with what is still unknown from the response:

Incoming: 01FE06480201
Outgoing: FE0105080201

The first two bytes seem to be the addresses of the source and destination device; this is not that strange as it seems; although this is a 1:1 communication, since there seems to be some Modbus inheritance in this protocol (the CRC16) and knowing that Modbus allows for more devices to be on the same bus, it ain’t that strange at all. Looking at other packet types (blockings, lockings, counters) I always see these 2 bytes coming back, so it’s fair to assume these are used for addressing. Now we’re down to 4 bytes:

06480201

$48 = 72 decimal. Packet size! Another important item to validate the incoming data stream.

Believe me, (I won’t bore you with examples of all the other packet types) 0201 is the function code or command code or whatever you like to name it. It identifies what the payload is about. 1 byte left, the 06. Protocol version? I don’t know yet. Maybe some day I will…