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!

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

]]> http://blog.hekkers.net/2011/11/22/hydronic-balancing/feed/ 12 http://blog.hekkers.net/2011/11/12/controlling-the-radiators-is-not-enough/ http://blog.hekkers.net/2011/11/12/controlling-the-radiators-is-not-enough/#comments Sat, 12 Nov 2011 22:32:23 +0000 Robert Hekkers http://blog.hekkers.net/?p=2440 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….

]]> http://blog.hekkers.net/2011/11/12/controlling-the-radiators-is-not-enough/feed/ 7 http://blog.hekkers.net/2011/11/06/max-cube-lan-gateway-and-dhcp/ http://blog.hekkers.net/2011/11/06/max-cube-lan-gateway-and-dhcp/#comments Sun, 06 Nov 2011 19:07:34 +0000 Robert Hekkers http://blog.hekkers.net/?p=2425 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 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

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…

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!

With the basic interfacing already finished some time ago, I also started working on the other end sooner than I usually do: the GUI, so I won’t make that same mistake again. Normally the thermostats will run on their weekly program; with 13 switchpoints per day I don’t think that manually adjusting the temperature will be used much, but without the possibility of changing the temperature this way, it’s no fun, right. On the floor-plan of our house, which is the ‘home page’ of our touchscreen GUI (I should update that picture some day, a lot has been added in 2 years!) in the living room, I created a button in every room that will have MAX radiator thermostats. Touching one of these buttons will show a very basic (and still a bit ugly) dialog with a track-bar to override the temperature. This dialog is nearly finished; all I have to add is an additional combo box to set the date/time at which the radiator thermostat should return to the weekly program again. I will not be able to control each individual radiator thermostat BTW; I chose for temperature control per room and not per radiator, cause I think that will be enough.

I also updated my Domotica system yesterday, so I can test all the functions which are finished and ready to use all day long. And since I had to make sure I know exactly where all the Radiator Thermostats are installed (not in a textual way like ‘Bathroom’ in the device description, but by assigning locations id’s), I have finally categorized all my devices (actors, sensors, interfaces etcetera) on building- (we also have a littlle shed in the garden ), floor- and room level.  With more than 200 items to categorize, it won’t surprise you that some of the devices in my database are currently listed as ‘unknown’: I don’t know where they all are anymore?!

All I have to do now is order some more Radiator Thermostats and write code for the weekly program administration.  Coding will probably take less time than waiting for the delivery, so a turnaround of 10 days should be doable… MAX!

The interface for all these wireless devices is the MAX! Cube LAN Gateway; with this you can control, configure and adjust all your MAX! components. Cool..

Not so cool is the web portal that has to be used when you want to control the MAX! system from outside your own house (e.g. via Internet, with your smartphone or whatever). Some people, and I’m one of them, don’t like being forced to use a web portal controlled and secured by a 3rd party; I prefer making my own solution for these kind of  things, especially since every website seems to be hack-able these days and leaking all kinds of information… No, if someone is leaking information about me/us, it should be me doing that, not some company..

Last week someone posted some details about the MAX! Cube LAN Gateway on the Domoticaforum Europe. It seems possible to connect to port 80 of the Cube and even communicate with it. OK that’s a start, now all that’s left to do is finding out how the MAX! Cube works, which can be a tough job. The protocol that’s being used is another proprietary one and therefore nothing has been (and probably never will be) published about it. Time for some good old packet inspection – and for that, it’s better to have a MAX! Cube and a Radiator Thermostat at my disposal, so I bought those 2 items last weekend. After that I started searching for more detailed information about the protocol – but as expected, without result.

I reread the ELV MAX! topic on the Domoticaforum and looked at some lines of MAX! communication that were logged by a member called blb. At first sight I could not tell what it all meant, although I did see some lines that had Base64 characteristics: all characters were more or less human readable and they were ending on 1 or 2 ‘=’ characters. And yes, it’s Base64 encoded; I decoded one of the logged lines and it revealed a url pointing to a portal on the elv.de domain, another decoded line revealed the location and name that forum member blb probably assigned to one of his Radiator Thermostats. Finding out how the temperature had to be set wasn’t hard either. There still are some bytes unknown though

Nevertheless, this is what I call a good start; so as soon as the ELV MAX! stuff I ordered has arrived, I’m gonna start dissecting the protocol, bit by bit – exciting!

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

• Celsius support;
• Support for the IMT series thermostats;
• Support for the IMT series Humidity sensor.

Although I received the code only for adding Celsius support, I’m sure the Homeseer guys won’t mind I added those other 2 items as well

I was fortunate to have a IMT350 here, sent to me by a Domoticaforum member who found out that the IMT350 wasn’t supported by the current version of the Plugin and asked me to have a look at it. So I did, and in the process I added support for the IMT350 to the Plugin.

Together with another Homeseer user who volunteered as beta tester for the Plugin, we accomplished the 3rd item in the list, support for the Humidity sensor. While I was writing the code for the IMT350, I realized that the first thing that would be missing, was support for the humidity sensor and I just couldn’t leave it like that; it felt like delivering an unfinished product, so I decided to throw in some extra lines of code to make the Humidity sensor readings accessible as well. After some ‘research’ (I’m not a Homeseer user, you know) I found out how to do this, and also found a way to get Humidity readings into HSTouch (with the help of that same beta volunteer who tested my findings). Below a HSTouch screenshot, including the humidity:

Another project finished, still dozens to go!