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:

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…

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!

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!

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.

 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

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.

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

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….

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?

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!

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

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:

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…

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.

 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!

Before I start digging up the protocol and will be staring at bits & bytes for quite some time, I thought it would be good to first give a short impression of the ELV MAX! products that arrived yesterday: a MAX! Cube LAN Gateway and a Radiator Thermostat.

The Radiator Thermostat feels good – it’s made of plastic, but it doesn’t make it feel light or cheap. And it’s big, but not too big. The big LCD is a smart choice IMO, cause with radiator valves just 20 cm above the floor you can still read the temperature set-point and the various icons very well - no need to get on your knees. I’m satisfied with the looks so far; the only thing that worries me a bit is the M30 nut which is also made of plastic. I would have preferred a metal one, just like the one on the Honeywell HR-80. But hey, look at the price difference between those two.. well, I guess we’ll know how this plastic nut performs soon enough  The big knob with which the temperature setpoint can be altered works and feels good as well. No complaints so far.

The Cube is ehm, well, a cube. White, with a RJ-45 connector for LAN and a USB connector for power. The power adapter has a USB connector too, so you don’t need a PC nearby; working with the Cube is completely LAN based. 3 green LEDs on the top of the Cube show the status for power, Internet and Battery. Power consumption of the Cube: 0.9 W. That’s acceptable; I’ve seen worse!

After unpacking everything, I started with inserting the batteries into the Radiator Thermostat with the Thermostat still on my desk. After the batteries were inserted, it started doing its ‘adapter run’ so the thermostat can find out how/where the pin of the radiator valve is positioned and how much this pin can be moved. I immediately got an F2 error, which I already anticipated since the Thermostat didn’t get any resistance from a real radiator valve. So I mounted it to a radiator valve, started the ‘adapter run’ again and unscrewed the Thermostat from the radiator after it finished this run. Back on my desk with this Radiator Thermostat, cause I don’t like to walk back and forth between desk and the nearest radiator!

Next I started up the Cube, downloaded a MAX! App from the ELV site, installed, started the App and saw the Cube being auto-discovered. Default mode for the Cube’s LAN connection is DHCP, BTW. The App told me I needed a firmware upgrade before I could proceed, so I let the app take care of that. I teached-in the Radiator Thermostat and looked around in the MAX App; pushed some buttons, changed some settings, turned the Thermostat knob manually, adjusted a schedule etcetera; after 15 minutes or so I had seen enough; this app is not going to be used. Not because it doesn’t work good, has flaws or whatever reason, but it’s not integrated!

Depending on how well the ELV MAX! protocol can be dissected into all the details, I will maybe use it to teach-in new Thermostats; we’ll see. But that should be all, the rest of it all should be doable from my own system.

I’ve already started with decoding the incoming ‘H:’,'M:’ and ‘C:’ messages that are received when a TCP connection is opened to port 80 of the MAX! Cube. Those responses contain very interesting configuration data. More on that later…

Update: I posted some protocol information on the Domoticaforum. Enjoy!