Tag Archives: ELV MAX!

MAX! Cube LAN Gateway and DHCP

  By Robert Hekkers | November 6, 2011 - 20:07 |
8 Comments

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

  By Robert Hekkers | November 1, 2011 - 23:40 |
1 Comment

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

  By Robert Hekkers | October 16, 2011 - 11:45 |
Comments Off

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

  By Robert Hekkers | October 2, 2011 - 19:37 |
10 Comments

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

Preparing for the winter

  By Robert Hekkers | September 26, 2011 - 23:15 |
5 Comments

Yep, it’ll be there before you know it. Last week our central heating spent some time in CH (Central Heating) mode, so my ELV MAX project has moved to the top of my to-do list for the next days. No more soldering, sketches or other intermezzo for a few days…

Temperature Dialog

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!

ELV MAX!: dissecting the weekly program

  By Robert Hekkers | September 11, 2011 - 20:00 |
2 Comments

How hard can it be to reverse-engineer a protocol? Very hard. Getting your hands on unencrypted protocol data is the first must-have I guess to have any success at all. From what has been discovered until now, the ELV MAX! protocol seems pretty straightforward; no signs of data obfuscation have been encountered yet. With those 2 conditions, it actually doesn’t have to be that hard to find out what all those bits & bytes mean. Lets take the weekly program as an example.

What is already known about the protocol, the program and what other facts can be useful:

  • Every day can have it’s own program;
  • A maximum of 13 ‘switching points’ can be defined per day;
  • The resolution of the time of a switching point is 5 minutes;
  • A week has 7 days;
  • Currently, only 17 and 21 degrees Celsius are used in the program;
  • I use only 4 different time values as switching point time in the program;
  • For storing temperature values, 6 bits are used and the temperature value is multiplied by 2 (everywhere I’ve seen so far).
I also know that the weekly program has to be inside here somewhere:
00h: D2 00 35 08 01 01 14 FF 49 45 51 30 31 30 39 31  |-.5.... IEQ01091
10h: 32 35 28 28 3D 09 07 28 03 30 0C FF 00 44 48 55  |25((=..(.0. .DHU
20h: 08 45 20 45 20 45 20 45 20 45 20 45 20 45 20 45  |.E E E E E E E E
30h: 20 45 20 45 20 45 20 44 48 55 08 45 20 45 20 45  | E E E DHU.E E E
40h: 20 45 20 45 20 45 20 45 20 45 20 45 20 45 20 45  | E E E E E E E E
50h: 20 44 48 54 6C 44 CC 55 14 45 20 45 20 45 20 45  | DHTlD¦U.E E E E
60h: 20 45 20 45 20 45 20 45 20 45 20 44 48 54 6C 44  | E E E E E DHTlD
70h: CC 55 14 45 20 45 20 45 20 45 20 45 20 45 20 45  |¦U.E E E E E E E
80h: 20 45 20 45 20 44 48 52 6C 44 CC 55 14 45 20 45  | E E DHRlD¦U.E E
90h: 20 45 20 45 20 45 20 45 20 45 20 45 20 45 20 44  | E E E E E E E D
A0h: 48 54 6C 44 CC 55 14 45 20 45 20 45 20 45 20 45  |HTlD¦U.E E E E E
B0h: 20 45 20 45 20 45 20 45 20 44 48 54 6C 44 CC 55  | E E E E DHTlD¦U
C0h: 14 45 20 45 20 45 20 45 20 45 20 45 20 45 20 45  |.E E E E E E E E
D0h: 20 45 20                                         | E

OK.. so where is the weekly program and how to read it? The first 2 lines have already been dissected partially, but from position 20h and further is unknown. I bet that’s the weekly program; what else would it be ;-)

The first thing I notice is that the characters “DH” are repeated 7 times; ahh, 7 days. The interval between these “DH” bytes is constant; 26 bytes each time; ahh, 26/2 = 13; the number of switchpoints. I assume that the information for one switchpoint is stored into 2 bytes aka a word. Nice. Now let’s just take 2 consecutive bytes and see if we can derive a temperature and time value from it. Not an “E ” pair, cause the amount in which they occur makes me think they mean ‘undefined’ or something, cause I don’t have that many switching points in the program. Lets take a word just before an “E ” word, to stay word aligned (since every word seems to contain information for 1 switching point). That would be a “U.”, or in hex values: 55 14.

Some bit math now:

17 degrees Celsius will be stored as 34d = 22h = 100010b

21 degrees Celsius will be stored as 42d = 2Ah = 101010b

Time value 07:00 is (7*60)/5 times = 84 steps of 5 minutes; 84d = 54h = 1010100b

Time value 23:00 is (23*60)/5 times = 276 steps of 5 minutes; 276d = 114h = 100010100b

Etctera, for all time values used….

 

5514h = 0101010100010100b

Look, it fits!

5514 = 0101010100010100
        101010100010100

With this, I now know how to ‘read’ a switching point:

Assuming value = 5514h and using this Delphi code:

time := (value and $01FF) * 5;   // in minutes
hour:= time / 60;
minutes:=time mod 60;
temp:=(value shr 9) and $3F;

The outcome is 21 degrees and time 23:00 … Cool. And correct!

All that’s left to is now is write some code to verify everything. And do some additional research on the day sequence; does it start with Sunday, Monday, …? You know what; I think I already know that too – the first 2 days in the hex dump above have the least number of switching points: typically Saturday and Sunday, so the program starts with Saturday! :-)

Another part of the protocol can be documented!

ELV MAX! first impression

  By Robert Hekkers | September 1, 2011 - 17:22 |
Comments Off

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!

Unravelling the ELV MAX! heating control system protocol

  By Robert Hekkers | August 29, 2011 - 19:29 |
2 Comments

A German company called ELV has a new heating control system since a few months – it’s called MAX!.  With this system you have the ability to control your heating system via Smartphone, Internet and local PC (oh, and manually of course). The MAX! radiator thermostats seem to have all I need: flexible daily switching programs, auto/manual/holiday mode, temperature can be set between 5 and 30 °C in steps of 0.5 °. Other components of the MAX! system are wall switches for Eco mode, window sensors and wall thermostats. Prices are good too; very good actually, when you compare them to alternatives.

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!