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!

 

Getting closer

Yesterday the last parts for the OpenTherm Monitor arrived, so I could finish that part last evening:

– Adding the last part to the PCB (a 4.7 Ω resistor);
– Removing a diode that was there to power the PCB from the RS232 port that I won’t use;
– Replace the 2nd “RS232 power” diode with a wire;
– Cut away the unused headers.

And this is the end result:

OpenTherm Monitor PCB finished So the OT Monitor part is finished now. As you can see the DTR connection is now unused and the DSR connection doesn’t have a diode anymore.

Next step was to have a close look at the additional parts that are needed to connect it all to a JeeNode:

Additional parts

On this part of the schematic (here’s the complete original), 5 new parts are being used:

  • 2 resistors of 1 kΩ;
  • 2 * 2N7000 MOSFET (available here)
7N2000 MOSFET

7N2000 MOSFETThese 2 pictures and the the datasheet saying that

pin 1 = Source
pin 2 = Gate
pin 3 = Drain

is enough to make no mistake with the wiring, even if  you have no clue what the 2N7000 does 😉

 

  • A SN7432N which is a Quadruple 2 input positive OR Gate and can be purchased here

SN7432N

As can be seen in the schematic, a Single 2 input positive OR Gate would suffice just as well; maybe they exist too, but I didn’t bother to search

 

SN7432N powerBesides the 2 inputs and the output signal, the SN7432N als needs to be powered (pin 7 and 14), so the total number of connected pins results in 2+1+2=5.

 

 

 

With a breadboard, a JeeNode, a 4×20 LCD with a JeeLabs LCD Plug on its back, some wires and the SN7432N I mentioned above, this is the end result for now:

 Almost finished

Yep, I’m waiting for the MOSFETs to arrive. As soon as they arrive and I have some time to finish the breadboard, I’m going to put this OT Monitor between the Honeywell Evotouch Wireless OpenTherm RF module and our Remeha Calenta.

Assuming everything keeps working and that I’m not confronted with errors on the display of the boiler, I can try to have a look at the signal on the data pin – and if that looks OK, the next step will be connecting the data pin to the JeeNode and watch the LCD… exciting!

Preparing for OpenTherm Monitoring

More and more my weblog is becoming an ‘archive’ of what I did and, more important, how I did it. I know that I can find that specific picture or other piece of information I’m looking for on my NAS or a local HDD somewhere, but a search on my own weblog is much quicker, and it works too, more and more. So I decided to write down every step I take with this OpenTherm project on my blog and in more detail than I’ve done before – I think I’ll thank myself for that later 😉

Before heating up the soldering iron, I spent some time reading the OT Protocol Specification v2-2. I won’t go into all the details, but here are some important things to know.

OpenTherm is a point-to-point communication system between boilers and room units (the thermostat). The room unit is supposed to calculate a heat demand which is sent to the boiler; the boiler should act on the information provided (more or less heating) and the boiler can also send back various types of information like diagnostics and other useful stuff (to display on the thermostat LCD, for example).

The physical way in which the boiler and thermostat exchange information over the 2 wires is that the boiler transmits a signal by changing the current (high=17 .. 23 mA, low=5 .. 9mA), while a thermostat does this by changing the voltage (high= 15 .. 18V, low = 7V).  The boiler is also supposed to provide the room unit with power, so no batteries should be needed.

The encoding method that’s being used is called Manchester, where a transition from low to high represents a ‘0’ bit value and a transition from high to low is a ‘1’; more about Manchester code here. OpenTherm uses a bitrate of 1000 bits/second.

An OpenTherm frame consists of 32 bits e.g. 4 bytes and those 32 bits are transmitted with a leading start- and a trailing stop-bit. These 32 bits contain information like parity, message type (read, write, read-acknowledge, invalid data), data identifier and 1 or 2 (used) data bytes. In a OpenTherm conversation it’s always the thermostat (room unit) that acts as master; hence, the boiler is the slave. Communication is therefore always initiated by the thermostat, not by the boiler and the latter is supposed to reply within 800 ms. Furthermore, the protocol documentation states that a master must communicate at least every second. (question for myself: how does this relate to a wireless connection between thermostat and boiler?)

That’s enough info for now; lets have a look at the first thing I want to do: monitoring OpenTherm traffic with the Elektor OpenTherm Monitor. Lets have a look at the schematic of the Elektor Opentherm Monitor (OT Monitor) and what has to be done to connect this OT Monitor to an Arduino (or a JeeNode, in my case) – cause that’s the goal of this first step.

 

(the image can be a bit blurry due to the resizing; clicking it will reveal a better image)

The right side is where the builder of the OT Monitor is supposed to hook up his/her RS232 port. But that’s not going to happen – at least not if I can manage to modify the Elektor OT Monitor to this schematic, which I found on a site I mentioned before: http://www.palebluedot.nl/jml/projects/arduino/24-openthermmon.html

I can clearly see the modifications on the right side of the schematic (duh), but to make sure I don’t forget or oversee any of the modifications, I opened the original Elektor schematic in MSPaint and started modifying the original to get to the end result that I need. All modifications were done in red, so that it would become much clearer to me what had to be changed on the original PCB and what additional components had to be added (on a separate piece of perfboard):

 

It might look ugly or silly (or both), but it works for me and that’s all that counts, right? It reduces the labyrinth..

So, 1 diode needs to be replaced by a wire and the other connection with a diode will (must) not be used anymore – that takes care of the PCB-side of what has to be done. That should not be too hard.

Low Temperatures & OpenTherm

I don’t know why, but the cold weather of the last few weeks makes the word “OpenTherm” go through my mind all the time… temperatures are in control of what keeps me busy, how about that 😉

While the Nemef Radaris Plugin is being tested, I have some spare time to try and make that first syllable in OpenTherm a bit more true. At least for me, cause I don’t know that much about the OpenTherm protocol yet – time to do something about it!

First I spent quite a lot of time searching for sources regarding OpenTherm and what I could do to make OpenTherm work for me. Sure, I’m building the OpenTherm Gateway that is described in detail here, but that’s not enough; I want to know more – everything there is to know! The biggest problem I’m facing is my lack of knowledge of electronics. So when it comes down to building stuff to interface with OpenTherm hardware, I have to fall back to schematics made by others. Sad but true.

So I started off with a document I already know about for a long long time (and that anyone who has ever searched the net for information about OpenTherm must have seen before): the Elektuur/Elektor article about the OpenTherm Monitor that was published in 2001. I’ve always wanted to build this Opentherm Monitor, but there’s a tiny problem with this OT Monitor: it needs to be connected to a serial port; not my favorite way of doing this. However, searching some more resulted in this site. Here you can find detailed information on how to connect a slightly modified OT Monitor and some extra components directly to an Arduino; that’s much better, for me.

Another good source of information is Alex Vieira’s blog, which is also mentioned on the JeeLabs Café. Alex’s approach is (as far as I can remember) different from others, cause Alex is using a JeeNode to act as a Thermostat instead of the ‘man in the middle’ approach that is being used by the Opentherm Gateway (injecting/modifying OT frames  between boiler and thermostat) that I’m building.

This made me wonder what would be the best thing to do; yes, I do want to control my central heating and yes, I do want to be able to change the temperature setpoint. But do I want to take over the role of the thermostat all the way and in fact make the current thermostat obsolete? No, cause in my opinion, our central heating system as a ‘basic facility’ that should always stay operational, no matter what. Computers can break down, the additional (DIY) hardware can suddenly stop working by some unforseen reason, or Murpy’s Law kicks in somewhere unexpected – all these things should never affect the service level of the central heating! OK, comfort level will decrease (cause if not, I’m doing something terribly wrong 😉 ), but we won’t have to be afraid of frozen water pipes, cause the ‘real’ thermostat will still keep the house warm enough. And just as important, problems can be fixed very easily by removing the additional hardware and things are back to how it was – as in a ‘normal house’.

You might think I don’t trust a DIY thermostat enough to replace the real one? No, that’s not the issue here – it’s more about creating something that can keep on working forever. Without me, my domotica system or any other piece of hardware I installed. Nothing I do should ever create an unusable house; neither should I be needed to fix things – that says it all.

Back to the original plan again, which is getting to know OpenTherm better.

The first step I made was ordering the OT Monitor @ Eurocircuits. Cost: 24 Euro for the PCB and with some components, the total cost is around 30 Euro.

 

OpenTherm Monitor Some components are still missing, but that won’t take long anymore. Next step will be to add the ‘extras’ I mentioned before so I can connect the OT Monitor to a JeeNode. These ‘extras’ have been ordered a few days ago and a JeeNode is already waiting to display some results on the 16×2 display. Total cost: not much.

Another great thing is that I managed to obtain a PCB out of a very small series that was produced for the OpenTherm Gateway I mentioned above; although I already started building this Gateway on perfboard, I’m happy to start all over again now I have this PCB 😉

OpenTherm Gateway PCB


To be continued!

Monitoring the Remeha Calenta

Last week I attached some 1-Wire temperature sensors to the floor heating tubes to monitor flow- and return temperatures. While I was doing that, I looked at my Remeha Calenta again and thought what a pity it was that I failed to monitor the Calenta with the Remeha Gateway. I’ve known for a long time that there’s a 2nd solution to this: Remeha Recom. A “special cable” and the Recom software make it possible to monitor your Remeha Avanta, Quinta, Calenta (and more). However the price for this cable is rather high; you won’t be able to get it below 130 Euros with as only result a Recom window on your screen where you can see all kinds of things being monitored… all you can do is make a screen-dump or log the values to a file… 🙁

And if I would buy that “wonder cable”, would I be able to understand the protocol? I didn’t want to risk the chance of buying that expensive cable and not coming any further than using Recom, so i stopped thinking about it. Untill last week.

I started roaming the Internet for more information; I read about “it” being a null modem cable; I looked at the PCB and saw the RJ-11 connector for the Remeha cable was labeled RS-232; I took a long cable with a RJ-11 plug and stuck it into the connector and started measuring with a voltmeter; I saw the outer 2 were 5V and the other GND; that leaves the inner 2 for the serial part. I started thinking about what this super duper Remeha cable could hide inside to make serial communication work? There has to be something special to it… converting TTL to RS-232 perhaps? Why not give it a try…

I have a MAX3232CPE laying around for some time; so I planted it on a breadboard, added some 0.1 μF capacitors and built this schema I found (click it):

Here’s the result:

TTL <--> RS232

TTL <–> RS232

Guess what… it works!! My Remeha Calenta was recognized immediately and I watched the data arriving in Recom:

Remeha Recom v4.1.1

With no more than 8 Euros I created my own interface cable; too ridiculous… Special cable?  My A!@&%#%^!!!

OK, but this was just the beginning. With a serial port sniffer i saw the Calenta being queried and I started recognizing the flow temperature, return temperature etc. in the responses that came back from the Calenta. These packets look like this:

02 01 FE 06 48 02 01 F0 14 AA 14 00 80 00 80 86 F3 00 80 B7 10

00 80 40 1F 70 17 00 80 00 00 00 00 00 BC 02 00 00 00 00 64 00

00 00 00 C2 0B 10 00 FF FF 00 00 00 00 FF FF 17 00 BC 02 00 00

00 00 00 00 00 00 00 00 00 C5 9B 03

After an hour or so, i knew where to find some temperature values and stuff like that. The F0 14 marked in red for example, means 53.60 degrees Celsius. That was easy… not good enough for a quiz 🙂 But I also saw on the amount of values Recom could produce from the incoming bytes, some things had to be stored in bits; the on/off, yes/no, open/closed values appeared not to be stored in a byte, but ‘hidden’ somewhere in a bit maybe? Hmm, how do I know exactly when the Gas valve opens or closes, so how I can locate the bit for that? If it is stored in a bit? This could become a bit more challenging and time consuming than I would like.

Aha! There’s a config directory belonging to the Recom software package, containing XML files; one of them was named exactly like the model that Recom detected. Let’s have a look inside that file… Bingo! These XML files contain very detailed information; they tell me that I can find that Gas valve value in bit 0 of byte 38… Yeeha!

Now it’s just a matter of finding out some more about the leading and trailing bytes and I can start creating my own Remeha Calenta interface to my Domotica system.

Finally I’ll know what the Gas is being used for: DHW or heating. And when the water pressure drops below a value I find alarming, I can be warned before it’s too late. And I can see how much power is actually being produced; and …

Update: RJ-11 is incorrect; it’s a 4P4C connector!

Remeha: "problem not important enough"

Today, after 5 weeks of waiting, i was called by a Remeha employee about my problems with the combination of Remeha equipment in my house: Remeha Calenta, Gateway and Celcia 20.

I told him the whole story from the beginning; the phone calls i made with Remeha in April this year to be sure that what i wanted would work, the problems i encountered, the emails to Remeha sales support about the problems, more phonecalls and not getting any answer from Remeha for more than 5 weeks now.

The bottom line is that Remeha is to busy with new developments to pay any attention to what problems i might be experiencing with this very rare combination of their hardware. Simply a matter of costs.  Investing time/money into this matter costs more then and the relevance of the problem is very low for Remeha.

So basically the answer i got today was: “we’re sorry”. Ok. Bad answer for me; i’m not happy with it. But in a way, i can understand it. But this was the first time i was talking to a Remeha person who had the guts to say it out loud… it hurt (a bit), but this is 10 times better than getting no answer at all. That’s really irritating and disrespectful; ever heard of after-sales? The Remeha employee apologized for that.

And before i metioned anything about it, I was told i could return the Gateway and defective Celcia without any problem and i would get my money back. Case closed… regarding doing it the Remeha-way i mean : I’m already one step further in accomplishing what i want another way…

Still integrating Remeha Calenta into my Domotica system

Remeha Calenta

Remeha Calenta

It has been a while ago since i worked on this project. After the new central heating had been installed in the first week of april, i spent time to get the combination of Remeha Calenta, Remeha Gateway and Remeha Celcia 20 to work. I failed…

Somewhere there is an unstable factor in this combination that makes these 3 devices not work together as they should, and as was stated that they could by a Remeha technician. So i put this project on hold for a while. But now that holidays have started, and the days will get shorter in a matter of weeks, i would like to have this project finished by the time  we need the central heating again…

Last week i talked to the  person who installed the Calenta and he asked me to write down all my problems in an email that he would forward to Remeha Technical Services department, to see if it was possible to have a Remeha technician coming over to my house to investigate the problems i am having.

After integrating lights, appliances, garage doors, alarm systems, TV, Home theatre, music, the largest piece of equipment that is not yet integrated is the central heating. That has to change… one way or the other! 🙂

All kinds of things are made possible these days in this area, just look at the Danfoss Z-Wave controlled radiator thermostats for example. It’s a sign you can’t ignore. So i hope Remeha has a clue of what is going on in terms of Domotica & HVAC; and i hope they inderstand that the systems they produce can no longer be isolated from the rest; it’s time to connect!

Remeha Calenta or Avanta?

Next wednesday i have a Remeha representative coming over to my house to see what’s the best heating system for our house. Remeha has got a new model since recently, the Remeha Calenta. Probably with a much higher price than the Avanta, my choice so far. Another very important issue is that the Calenta needs to have the ability to be operated with the Remeha Gateway just like the Avanta. The recommended thermostat for the Calenta does like very nice, BTW. And maybe i’ll add a solar water heater to the system, who knows. Alot of questions, hopefully to be answered next Wednesday.

Remeha iSense

Remeha iSense

Remeha solar water heater

Remeha solar water heater

Remeha Avanta

Remeha Avanta

Remeha Calenta

Remeha Calenta