MAX! Cube LAN Gateway and DHCP

  By Robert Hekkers | November 6, 2011 - 20:07 | Domotica
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 | Domotica
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 | Domotica
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 | Domotica
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 | Domotica
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!

Updating the all-in-one remote

  By Robert Hekkers | September 25, 2011 - 21:37 | Domotica
3 Comments
Pronto Media Player Activity

Pronto Media Player Activity

I got some complaints lately, from “the people in the livingroom”…

For me, the excitement is in being able to control everything, but not in actually using it in the most convenient way… so sometimes I just don’t finish what I should, just because it’s not that exciting anymore – it works, right? So on to the next job! But this week I was remembered to the fact that I have to keep that WAF in mind a bit more. OK.. lets see how I can keep everybody happy again.

A new media player and a new A/V receiver make watching TV or listening to the radio a bit more complex, and I still hadn’t updated my Pronto to deal with those 2 new devices. So in June this year, when we started using the new A/V Receiver and media player, the number of remotes went up from 1 to 3 again; that’s a lot of new buttons to remember and too much for some; cause we’re all used to using just one remote for all A/V equipment – our Pronto TSU9600! A great remote, which can be totally customized to your own taste and needs. The complaints forced me to do something about the fact that the usefulness of the Pronto had dropped a lot (or slightly, in Onkyo terms…). Listening to the radio and using the media player were the 2 activities that had to be added to the Pronto and some other activities needed some adjustments.

I created a Prontoscript library some time ago which makes it very easy to communicate with my Domotica system. It’s based on XML-RPC and with some wrapper routines a single line of Prontoscript code ‘under a button’ can do just about anything I want: lights, A/V, viewing webcams, opening doors, whatever; as long as my Domotica system can do it, I can control it from my Pronto. As an example, here’s the script that will do all that’s necessary to listen to the radio (the last selected radio station, that is):

XMLRPC_SetDevice('NR709','POWERON;SEL_FM;VOL=26');

With just a single touch of a button on the touchscreen of the the Pronto, this script takes care of turning on the A/V receiver, selecting FM radio and setting the master volume to a preset value.

Was it hard to do this? No, it took me less than an hour.  But the result is, that now everybody considers this (home) automation project finished..

 

Building the sensor hub

  By Robert Hekkers | September 21, 2011 - 21:53 | Domotica
2 Comments

The basic ideaBecause I’m working on 4 different things simultaneously, all 4 of them are not progressing as fast as they could. And this new sensor hub is not top priority, so sometimes it takes a while before I can spend some time on it. The last few days I came up with some basic idea; this is what I have in mind for my sensor hub.

The lower side of the enclosure will have all the connectors for power and other wires to the sensors and the upper side is where a small 5V power adapter with USB connector (of which I bought a couple recently, for only 5 euro/piece) and cable will provide the necessary ‘juice’ to the Arduino Fio.

The FTDI breakout on the left is just for uploading sketches (and for power, while it’s still here on my desk).

Inside the enclosure there’s a half-size (400 points) breadboard with double-sided tape that will hold the Fio and the required wiring. Cheap and simple; and since this setup will take care of 4 of my all-in-one sensors, I can live with the fact that it’s not battery powered. This certainly doesn’t mean I’ll never build battery powered sensors anymore…

Air power!

  By Robert Hekkers | September 18, 2011 - 12:25 | Family
Comments Off

The Dutch AH-64D Apache Solo Display Team

Yesterday my son and I visited the Royal Netherlands Air Force Open Days. Wow! It has been a long time ago since I visited these Dutch Air Force Open Days; I think the last time was when I just got my driver license, which is about 20 years ago.

It all happened because our son bought a 1/32 Revell model of the Apache last week, for just 5 Euros in a local shop. We were searching for images of the Apache and just accidentily “landed” on the website of the Air Force Open Days. We talked about going there the next time it would take place, looked at the dates and saw the event was yesterday - we were lucky! :-)

We got out of bed at 06:30 and arrived at the Air Force Base Leeuwarden at 08:45. There was just too much to see in 1 day; we were in a constant dilemma of watching the aerobatics or visiting the static show, stands and other exciting things to do, especially for the youth. The image above shows the Dutch AH-64D Apache Solo Display Team in action, one of the most exciting performances we’ve seen yesterday. We had a great time on a well-organized event, with lots of exciting things to see and do -and our son can now redecorate his bedroom with all the posters he took home. I’m sure that visiting the Open days of the Dutch armed forces will become a tradition again!

First sensor finished and working

  By Robert Hekkers | September 13, 2011 - 20:30 | Domotica
6 Comments

Power wiresToday I finished soldering a cable to my first new All-in-one sensor with motion, temperature and light. Phew, after soldering those 7 wires my eyes really needed a break, even though I used a magnifying glass. The very first thing I did was getting rid of the headers for the H/L jumper; I reduced the 2headers I needed to 1 mm and added a drop of solder in between; the unused header was cut away completely. This gave me some more free space  for the black wire which connects the GND pin of the PIR to pin 1 (GND) of the DS18B20. After that I connected DS18B20 pin 3 (Vdd) and one leg of the LDR to each other so that I only needed 1 wire for supplying both sensors with power by connecting those to the + pin of the PIR; this is the red wire.

Now all the sensors were connected with each other in a way that when I would apply power to the PIR pins, the rest of the sensors would be powered as well.

Connecting the cable

As you can see a CAT5 cable was used; I only needed a total of 5 wires for this sensor. First I needed a way to glue the cable to the top cover of the enclosure; I saw there was some space between the PIR PCB and the top cover, so I what I did was remove the outer isolation on one half of the cable but left the other half intact. I added a drop of hot glue to it and quickly pushed it between the PCB and top cover, which made the cable isolation work like some sort of pull relief. Soldering the 5 wires was the last thing I did; cause now it was time to check some things first – does it work??

I wrote a small sketch that would read all the sensors once a second and display the results (do I hear a drum roll? ;-) :

10765455 Motion:no,  Addr:28-98-C9-AF-2-0-0-A3 Temp=25.25 grC, LDR=643
10766546 Motion:no,  Addr:28-98-C9-AF-2-0-0-A3 Temp=25.25 grC, LDR=640
10767638 Motion:no,  Addr:28-98-C9-AF-2-0-0-A3 Temp=25.25 grC, LDR=640
10768730 Motion:no,  Addr:28-98-C9-AF-2-0-0-A3 Temp=25.25 grC, LDR=645
10769821 Motion:no,  Addr:28-98-C9-AF-2-0-0-A3 Temp=25.25 grC, LDR=653
10770913 Motion:no,  Addr:28-98-C9-AF-2-0-0-A3 Temp=25.25 grC, LDR=657
10772004 Motion:no,  Addr:28-98-C9-AF-2-0-0-A3 Temp=25.25 grC, LDR=663
10773096 Motion:no,  Addr:28-98-C9-AF-2-0-0-A3 Temp=25.25 grC, LDR=661
10774188 Motion:YES, Addr:28-98-C9-AF-2-0-0-A3 Temp=25.25 grC, LDR=666
10775279 Motion:YES, Addr:28-98-C9-AF-2-0-0-A3 Temp=25.25 grC, LDR=668
10776371 Motion:YES, Addr:28-98-C9-AF-2-0-0-A3 Temp=25.25 grC, LDR=663
10777462 Motion:YES, Addr:28-98-C9-AF-2-0-0-A3 Temp=25.25 grC, LDR=660

It works! Maybe I’ll put some drops of hot glue here and there to make it all slightly firmer and than I can close this sensor.

The sketch is still very basic; it’s just some Serial.prints you see here, no wireless transmission is done yet and there’s an ugly delay(1000) in the loop() for the 1-Wire delay that I have to get rid of.

And I don’t need temperature and light sent to me every second; but waiting one second before motion is detected is way too long of course. Using interrupts for detecting motion is better I guess… soon I’ll know more about that, cause I need to be able to handle 4 PIRs (on 4 different input pins), but I can’t have 4 ISRs (Interrupt Service Routines); but the ‘solution’ will probably suffice. Sounds like a nice subject for another post.