Eliminating errors in temperature control

Those who have visited my blog more than once, will probably know about my continuous struggle to get a better control of the temperatures throughout the house, both up- and downstairs.

To demonstrate the biggest ‘problem’ we have here regarding temperature control, I made a chart showing 2 different temperatures. The blue line shows the temperature measured in the living-room, by the internal sensor of our thermostat. The red line shows the temperature measured in the hallway, with an RF temperature sensor.

Oh, and the trends in the chart below could well be just like yours, cause it’s a very common phenomenon:

Temperature charts

Most of the days were sunny, but the last 3 weren’t. The peaks in the blue line (i.e. the temperature in the living-room) are caused by the solar radiation, warming up the living-room to almost 23 degrees! That’s OK of course, but the result is that the central heating will not burn from approx. 12:00 till 18:00. And the whole house, except the living-room, is getting colder and colder.. So no matter what I do, this is the first thing I have to fix -I need a different reference temperature. I know that for quite some time, but never did something about it. Not every thermostat has the ability of connecting a remote temperature sensor to it, I didn’t want to move the thermostat to another location and we sure don’t want to block the sun radiation that’s warming up the living-room for free. (oh and btw: no, the thermostat is not ‘hit’ by direct sunlight).

So last Thursday I added another item to my ever growing collection of hardware to control the temperature inside: a remote temperature sensor.

Honeywell F42010972-001

A week ago I stumbled upon this sensor of which I didn’t even know it existed and immediately decided to buy it and give it a try.

I pulled 2 m. of ‘thermostat wire’ through the wall to my Honeywell Chronotherm Touch Modulation, connected the sensor, configured the thermostat and left the remote sensor dangling in the hallway, near the coat rack and started watching the OpenTherm information.

The remote sensor now replaced the internal sensor of the thermostat and I immediately saw the temperature dropping from 20.5 °C to 19 °C, which is the temperature in our hallway. At the same time, the modulation level of the boiler went up to 100% 🙂 Of course, I’ll have to adjust the ‘room’ setpoint … lowered that one with 1.5 °C as well and things seemed to stabilize again.

That’s part 1 of the story. Part 2 is preventing the heat produced by the boiler flowing to the living-room when it’s not needed there (cause the sun radiation is already produces enough). Well, that’s not that hard – I can control the floorheating pump with an appliance module and switch the pump off@setpoint+0.1°C and back on when the temperature reaches setpoint-0.1°C. Done…

Let’s see what this new setup brings in terms of stability…

Opentherm Gateway statistics

I had a different post in mind (smart meter follow-up) but hey, if questions arise and I’m interested in the answers just as much, I’m flexible 😉

The question to be answered was: how ‘fresh’ is the data that is travelling from the slave (boiler) to the master (thermostat)?

Is it 30 seconds, as suggested in a comment from Maurice? Quick answer: no.

I added some code to my OT_Decoder tool to collect some statistical data about the Opentherm (OT) frames travelling back and forth and I concentrated on a single Message Type, the Read-Ack.

This message type travels from boiler to thermostat and is in fact a response from the slave to a read-request from the master and can contain values for lots of things like status flags, modulation level, return water temperature etcetera. All these different types of values have been given a so-called Data-ID; status flags = 0, modulation level =17 , return water temperature = 28, and so on. The protocol has room for 256 different Data-IDs.

So when the master sends a Read-Data request to the slave for a particular Data-ID, the slave responds with a Read-Ack frame that holds the Data value.

Here are the statistics I collected:

00 :   0,4 seconds, 4678 times,  5 changes, mintime     4
05 :  57,8 seconds,   66 times,  0 changes, mintime
11 :  59,6 seconds,   64 times,  0 changes, mintime
12 :  58,6 seconds,   65 times,  0 changes, mintime
19 :   4,2 seconds,  787 times,195 changes, mintime     3
1C :  59,5 seconds,   63 times, 55 changes, mintime    59
74 : 235,8 seconds,   16 times,  0 changes, mintime
75 : 235,5 seconds,   15 times,  1 changes, mintime
76 : 235,5 seconds,   15 times,  0 changes, mintime
77 : 235,6 seconds,   15 times,  0 changes, mintime
78 : 235,7 seconds,   15 times,  0 changes, mintime
79 : 235,5 seconds,   15 times,  0 changes, mintime
7A : 235,5 seconds,   15 times,  1 changes, mintime
7B : 235,8 seconds,   16 times,  0 changes, mintime

What does this all mean?

00 is the Data-ID in hex and 0,4 seconds is the average interval between 2 frames measured over 4678 ‘captured’ frames for this particuler DataID. In all these 4678 frames the Data-values changed to another value 5 times and the smallest interval between 2 data value changes was 4 seconds (floored).

Conclusions, assumptions?

  1. It’s better to do this analysis during the winter, where the boiler is really doing something and let the data collection run for 24 hours or so.
  2. Data-ID 00 tells me that the boiler must be the limiting factor here, cause the poll rate is much higher then the smallest interval between value changes. But it could also be that the status of the boiler really doesn’t change faster than that; each transition to another phase (going from idle to burning is not just 1 step) will take time; how much?
  3. Data-ID 1C could lead to the assumption that if the master would poll faster,  a lot of data values would show a different value compared to the previous data value.
  4. The master plays the biggest role in the ‘freshness’, cause it’s the master that dictates what data ID’s the slave has to reply with – no matter how often the slave measures its return water temperature, if the master only requests this temperature once a minute than that’s what you get…

By the way, for those who have their OT Gateway hooked up to a serial port of a Windows PC, have a look at this!

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…

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!

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

Controlling the radiators is not enough

This is the next episode in the never ending story to get a good central heating; not just in the living-room, but in all the rooms; and totally integrated in my Domotica system. Today I received a box full of parts; diodes, resistors, capacitors, a PIC – 33 different parts in total.

A pile of parts

These parts will be used to build this Opentherm Gateway. I think most people who have ever searched for a way to control their Opentherm controlled central heating system will already know the site I referred to, cause it pops up really quick in the search results of any search engine – it’s one of the scarce good resources that are available when you want to integrate your central heating system into your Home Automation system.

But why do I want to control my central heating system? Do we need it, since we’ve already got Radiator Thermostats on all the radiators in our house? Yes we need it, and I’ll explain why.

The biggest “problem” we’re facing is that we have  a single thermostat that’s controlling the central heating right now, and this thermostat is in the living-room. The influence of the sun on the temperature in the livingroom is huge. Today, with a reasonable amount of sunlight, the 6 m2 of glass on the south side of the livingroom result in producing enough energy to warm up the living-room to a temperature above the thermostat setback. That’s good, very good, and we want to keep it that way of course! But the result of this free energy is that our central heating system stops burning around noon, as you can see below (showing the in- and outgoing water temperature of our boiler):

Central heating behavior

The central heating hasn’t been burning from approx. 13:00, cause there was no need for it anymore. There’s no need to explain what happens to the rooms on the 2nd floor; they all cool down, and there’s nothing I can do about it.

Another problem is that the temperature of the water which flows through the radiators, isn’t high enough for the radiators to radiate enough to heat up the rooms upstairs during the time that the boiler does burn. The result of all this: even if we’d want to, the temperatures upstairs will never reach more than 19° Celsius. We don’t need those higher temperatures, but that can change – and it will.

So how can I change when and (more important) where the central heating pumps energy into our house? I decided to give my Domotica system a role in this. The Opentherm Gateway is part of the solution. More about the ‘how‘ later….

MAX! Cube LAN Gateway and DHCP

Just when I thought I’d seen the worst, the ELV MAX! system manages to surprise me…again!

Last Tuesday I decided to do a factory reset of the MAX! Cube LAN Gateway; it was impossible to work with. Constantly disconnecting, internal time totally wrong and I couldn’t find any other way to resolve these issues.

Because I didn’t want to spend too much time on this factory reset, I left the MAX! Cube network settings set to DHCP, which I normally don’t do – right from the start, when the Cube was delivered, I assigned a static IP to it, cause all my network devices have a static address.

I configured my DHCP server and created a reservation for the MAX! Cube LAN Gateway, so that although the IP address is assigned by DHCP now, the Cube will always get the same IP address, no matter what.

The next day, I went through the firewall logs. Hey, what’s this… the Cube is contacting an IP address 85.25.143.185 on port 123, which is the IANA assigned port for the NTP protocol! I’ve never seen the Cube doing this, from day 1! Does this mean that…? yes, the Cube now synchronizes the time!

Firewall log of day 2011-11-01 with filter 'xx.xx.xx.xx'.

Nov  1 20:59:58 SRC=xx.xx.xx.xx DST=85.25.143.185 PROTO=KEY_UDP DPT=123
Nov  1 21:45:58 SRC=xx.xx.xx.xx DST=85.25.143.185 PROTO=KEY_UDP DPT=123
Nov  1 22:15:59 SRC=xx.xx.xx.xx DST=85.25.143.185 PROTO=KEY_UDP DPT=123
Nov  1 22:45:59 SRC=xx.xx.xx.xx DST=85.25.143.185 PROTO=KEY_UDP DPT=123
Nov  1 23:15:59 SRC=xx.xx.xx.xx DST=85.25.143.185 PROTO=KEY_UDP DPT=123
Nov  1 23:45:59 SRC=xx.xx.xx.xx DST=85.25.143.185 PROTO=KEY_UDP DPT=123

IP address 85.25.143.185 is where http://www.eq-3.de seems to be hosted, the manufacturer of the MAX! system.

Congratulations ELV and/or EQ-3, I found something that does work! 😉 I still don’t understand why the Cube LAN Gateway needs DHCP for that, but I’m past the point of asking myself why every time something doesn’t work on the MAX! heating control system… don’t worry, be happy!

I checked the static IP settings (subnet mask, gateway, DNS) I used and compared them with the DHCP options – they were the same. Of course. I was trying to find out whether I made a mistake or the Cube – silly me!

Another thing that happened was that the sudden disconnections had returned; I hadn’t seen them for a couple of days. Last night, after 00:50, the Cube stopped NTP-ing and some 20 minutes later I got the first socket error 10053 in my Domotica system logs.

Firewall log of day 2011-11-06 with filter 'xx.xx.xx.xx'.

Nov  6 00:20:43 SRC=xx.xx.xx.xx DST=85.25.143.185 PROTO=KEY_UDP DPT=123
Nov  6 00:50:43 SRC=xx.xx.xx.xx DST=85.25.143.185 PROTO=KEY_UDP DPT=123
Nov  6 12:50:45 SRC=xx.xx.xx.xx DST=85.25.143.185 PROTO=KEY_UDP DPT=123
Nov  6 13:20:45 SRC=xx.xx.xx.xx DST=85.25.143.185 PROTO=KEY_UDP DPT=123
Nov  6 13:50:44 SRC=xx.xx.xx.xx DST=85.25.143.185 PROTO=KEY_UDP DPT=123

Later that day, I had to power cycle the Cube to get a TCP connection to it that would last longer than 10 minutes… well, nothing surprises me anymore. What’s next?