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!

Energy flow in Watt

Now that I have sensors on all the radiators  I can sit back, relax and watch everything happen. I needed some help of the rest of the family to keep the doors upstairs closed, cause that seems to be very hard for some, but after a few days they all knew that when the doors were closed, daddy was doing one of his experiments again.. yep, this house is one big laboratory 😉

However, doing nothing is not really my style, so I went on reading about radiators, calculations etcetera and found some calculation tools for my RADSON Compact and Jaga Tempo radiators. And although it doesn’t add new data, I thought it would be fun to see if I could use the formulas used in these ‘Installer tools’ (in fact Excel sheets) for myself.

And I was right; based on radiator model, dimensions and specific properties it should be possible to calculate the actual heat output performance of the radiators in other circumstances (temperatures) . If you know the heat output conform the European standard EN442 (dutch) for a specific combination of model & dimensions, the so called n-factor (aka the emission line slope) and the air-temperature, you can calculate the heat output for any combination of flow- and return temperature!

So that’s what I did last evening – preparing my system for these semi-realtime heat output calculations.

First I had to add some more flexibility to the database; creating fields for this purpose only didn’t feel right, so I added a free text field in which I could ‘dump’ anything I want – device specific properties. As an example, here are the properties of one of the radiator devices in my system (it feels like ‘Domotica system’ doesn’t quite cover the capabilities anymore):

TYPE=RC
QN=1407
N=1.3404
TAIR=BATHROOM.TEMP

This means this device:

  • is of type RC (as in Radson Compact), 
  • has a heat output of 1407 Watt, based on its dimensions and EN442 at 75/65/20 °C (that’s flow, return and air temperature);
  • has an n-factor of 1.3403;
  • and that the air temperature can be taken from the device value called BATHROOM.TEMP (a foreign key, so to speak)

So every line defines a device specific property, which are dynamically added to the base device class at run-time.

And I had to write 2 Delphi functions to do the math, primarily based on these formulas:

Q is the variable that needs to be calculated, the rest is all known – piece of cake!

Just make sure you take care of unexpected results, like divisions by zero or raising negative values to a power- working with live data can produce strange results, where a radiator can suddenly start cooling instead of heating 🙂

I added the calculated heat output (the “W” column) in the table with all the other sensor data as can be seen below:

real-time calculated radiator heat output

Cool! Although these heat output numbers are based on pretty accurate formulas and properties provided by the manufacturer, the real-life numbers will probably be lower. Dust, bad airflow caused by windowsills and such will always result in deviations. How much? Dunno…

RF to Zigbee gateway

The last piece of missing hardware is finished. The picture below shows the 2nd RF to Zigbee gateway I had to make to be able to receive all the Hydronic balancing sensors I made earlier this week. One of those sensors just couldn’t make it through 3 walls all day long, so I created  a temporary solution on a breadboard to solve this.

A very simple yet effective way (for me) to get the sensor data where I want it (in my Domotica system) with minimal effort.

The JeeNode acts as a RF receiver and just echoes everything with a valid CRC to the Digi XBee; from there it eventually arrives at my Zigbee Coordinator with which I can communicate over TCP/IP.

The JeeNode runs a slightly modified version of the RF12Demo sketch made by Jean-Claude Wippler. I used the NewSoftSerial library to create an additional Serial port, and added a few print statements for the XBee port, right there where the RF12Demo Serial.println()’s the received RF data to the Serial port. Compile, Upload, setting the RF band,  group- and node ID and I’m done!

This JeeNode is powered by a 5V USB adapter and the XBee gets its power from the 3.3V JeeNode ports. The XBee uses a Zigbee End Device AT firmware (2864) with the Sleep Mode set to Pin Hibernate. But because pin 9 is wired to GND, this means that the XBee is permanently on.  Only 3 wires are needed to connect the XBee to the JeeNode: 3.3V, GND and a JeeNode digital pin to the XBee DOUT.

That’s it – moving on with where this all started with: understanding the flow of  heating energy in our house!

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?

MAX!imum irritation level reached

I just don’t get it. The ELV MAX! heating control system is probably the most unfinished product I have ever seen in my life. What were they thinking @ ELV when they decided to start selling it? We’ll fix the remaining bugs with some firmware releases afterwards? Cause this product has not been tested thoroughly, I can tell you that!

I was very close to kicking these Radiator Thermostats right off the radiators; a well-placed kick against those things should be enough, since it’s all plastic.

What happened? When the clock was set back one hour last weekend (Sunday morning @ 03:00 to be precise), the Max Cube LAN Gateway suddenly started closing the TCP/IP connection every 10 minutes. Or maybe it even rebooted itself; I don’t know cause I didn’t bother to check that. I was completely done with MAX!. I can’t think of anything else than the internal time keeping of the MAX Cube being the cause of this.. well done guys, and thanks for this mature and reliable product!

ELV MAX! sucks

 

Nothing helped to get the Cube going again, so this evening I had to perform a factory reset and teach in all the Radiator Thermostats again. I stopped after teaching in just 2 of the 8 Radiator Thermostats  I have; the fun is completely gone; I have to regain confidence before I teach in the other 6 Thermostats. I don’t like MAX! anymore and for me, ELV has been demoted to a company that sells crap. I’ve just had too much problems with it.

And yes, I was very pissed when I wrote this. Working with products which have so many flaws and for which I payed almost 300 Euro makes me angry, very angry. It sucks away all the fun… I’ve never ever had this experience before, actually. But hey, that’s why I’m writing these posts –  the passion for Domotica and the fun I have with doing what I do, day after day. Disappointments like this seem to come with the territory…

Now it’s time for some soothing soldering therapy 😉

MAX! interface completed

Since last Thursday, I’m now controlling 6 ELV MAX! Radiator Thermostats. Yes! But to be honest, not everything about the the ELV MAX! Central Heating system is that great. Here are some of the ‘problems‘ I had to deal with.

F2 errors.

When a Radiator Thermostat is installed, it will do a so-called adapter run to check whether the pin of the heating valve can be moved and the actuating range is OK. If not, the LCD display will show an error (F1, F2 or F3). Nearly all my Radiator Thermostats got an F2 error; which means the actuating range is too high. Strange, because my Jaga radiators have an actuating range that’s smaller than the 4.2 mm actuating range of the actuator.. I found out that the actuator didn’t make contact in fully retracted position – that’s not good, cause this means that the actuator can’t make use of the full 4.2 mm to control the heating valve. The result is, that the actuator doesn’t reach the position where the heating valve pin can’t be pushed in any further, hence the actuator thinks the actuating range is too high… After measuring some dimensions, I concluded that only a small modification of 1-1.5 mm would suffice, so I took a Radiator Thermostat with me to the garage and used a hacksaw to cut a slice off the Thermostat:

Before...After.

It worked! I’ve done this with all my 6 Radiator Thermostats and they’re all running fine now, no more F errors!

Cube doesn’t know what time it is

This one was even more serious. The Cube doesn’t have a clock; it synchronizes with a time server on the Internet. Right; but if (for whatever reason) that synchronization fails, you could find yourself waking up in the middle of the night with your bedroom temperature set to a day temperature! That’s unacceptable of course. There seems to be a work-around for that, you know… power cycle the Cube on a Saturday at 10:00, and the weekly program will run just fine! Why? Because when the Cube can’t do a time sync, it assumes it’s Saturday 10:00; Bravo! I found this work-around on the ELV forum BTW, where quite a few ELV customers vent their problems with the ELV MAX!.

Actually, if you can’t do what I did (=developing my own weekly program functionality), this problem actually makes the ELV MAX! system completely useless.

Fortunately, I could start using the Radiator Thermostats, despite these issues… 🙂

 

DIY to the MAX

Sometimes it looks like you have to do everything yourself…

While testing the ELV MAX system, I noticed that the Radiator Thermostats were off-schedule quite often. I don’t know why, but it’s a fact, and I have to deal with it.

Totally wrong! The weekly program I used in the past days was specifically created to monitor the accuracy of the Radiator Thermostats. Every 2 hours the temperature set-point was increased with 1°C;  starting with 10°C at midnight, 11°C at 02:00, 12°C at 04:00 and so forth. This way I had enough switch-points to see how these Radiator Thermostats would perform. Well, as you can see, the temperatures are totally wrong! Grr.

Why? I don’t know. But they are, for some odd reason. And the worst thing is, there’s nothing you can do to resolve this. Once the Radiator Thermostats have a wrong sense of time, you’re doomed and you’ll have to wait (for how long?) till the Cube resolves this for you. Hmm.

It seems that the Cube periodically retrieves the date & time from a time server on the Internet, so I wanted to know how often;  I took an old 10/100 Ethernet hub and connected the Cube and a laptop with Wireshark installed to this hub. Even after 36 hours, only 2 IGMP packets were seen. Even a power cycle didn’t make the Cube check to see what time it was. Too bad, I hoped I could find something that would trigger the Cube to check the date & time, but I’m lost. The Cube will probably check date & time once every few days or even a week, probably.

But can I live with Radiator Thermostats that are totally off schedule? No, of course not! So I had to write my own code to handle the weekly program and use that to control the Radiator Thermostats, until there’s another way to get the RT’s (Radiator Thermostats) working the way they should.

Autonomy is good for things like controlling the temperature in the house; it should be able to function all by itself, without the need for a Home Automation system to constantly dictate what the temperature should be – only when the residents want to overrule the default weekly program, Home Automation should kick in in my opinion. For now, that doesn’t seem like an option with the MAX system. It just doesn’t look completely finished yet? So much for the “Deutsche Gründlichkeit”.. I guess this is another examples of a product being pushed to market a bit too soon..

Nevertheless, 4 new Radiator Thermostats are coming this way; moving on! 🙂