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:

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:

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)

These 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

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

Besides 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:

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!

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.

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.

 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