Unravelling the ELV MAX! heating control system protocol

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!

Arduino DMX encoder on the test bench

Today I started testing my DMX project. The ingredients:

  • Arduino Duemilanove with Ethernet shield and DMX shield;
  • DMX decoder PX24500;
  • 24V PSU;
  • 6 x Artecta RGB LED;
  • some wires;
  • a sketch running on the Arduino;
  • UTP cable;
  • software tools.

After connecting all the wires, switching on the PSU, starting the Arduino and checking if the Arduino was succesfully connected to my LAN by pinging it, I was ready. I opened the Arduino IDE Serial Monitor so I could see what my sketch was doing and sent a “command” to the Arduino. For that I used wget, a non-interactive network retriever; most people who know Unix-like OS-es will probably know about its existence but it’s less known among the Windows folks. Well, in just a few words it’s a tool with which you can store the results of a HTTP call into a file and do all kinds of other handy stuff .

I started carefully; the first command sent to the Arduino was:

 wget 

What this should do is change the R-value from its current value to 10 in 0.5 (5*0.1) seconds. G and B values are set to 0 immediately.

What the  Arduino webserver will receive is the following:

 GET /10,0,0,5,0,0 HTTP 1.1

 ....etc, the rest is all standard HTTP headers

After parsing the request and figuring out what to do, the Arduino starts changing the LED colour by issuing DmxSimple commands according to the values received in the HTTP call.

Ok, the moment of truth is here… will the LEDs start producing light or not? Yeah, they did! Tadaa…

This is not Red (nor is it a pipe)

The moment I saw this working, I felt the need for a more sophisticated way to control the RGB values, so I wrote a small tool in Delphi to help me pick the right color:

ColorWheelToEthernet

With a mouse click I can now select the color; the rest is done automatically: calculating the R-, G- and B-value and performing the HTTP call. And all it took was 10 lines of code (with the help of Indy and a very nice Color Lib made by Marco Binic). This allows me to choose a color much quicker and more precise than by editing numeric values on a command line 😉

I did find some issues during my first DMX adventure, so I haven’t reached the phase yet where I can start digging holes in the ground; I’m not totally satisfied yet – more on those issues later, when I’ve hopefully fixed them.

 

Stacked stock

Stacked shieldsHere you see an Arduino Duemilanove, an Ethernet shield and a DMX shield. Well to be honest, the top shield is 1 day old; the rest has been on the shelf for more than a year. I wanted to start using some of the stuff I bought in the past but never used, so with the need for a DMX encoder to control 6 RGB LED spotlights, I decided to do it this way.

It was a bit annoying that I had to deal with how the Arduino platform works with shields and that you have to find out whether you can stack more than 1 of them on top of the Arduino and not have pin conflicts between the shields you want to use; this can happen so it’s always good to have a look at the pins all the shields use and see if there are any conflicts. In my opinion, the JeeNode concept is much smarter and easier in this perspective – and documentation is much better too!

Now back on topic again… as I said, this combination of boards is going to be used as an Ethernet enabled DMX encoder with integrated web server. Sounds difficult? It’s not, actually…

The DMX shield (from the Arduino store, made by Tinker.it) uses the DMXSimple library and indeed, it’s very simple. All the hard work is hidden and all you have to do is use 2 or 3 simple functions to get DMX encoding working.

The same goes for the Web server part; the Ethernet library makes it as simple as it possibly can.

So all I had to do was write some code to parse the values I wanted to send to this DMX encoder (R-, G- and B-values and some time values to soften color changes); and now I’m waiting for the LED spotlights to arrive, cause I’m ready for it! Yep, that’s the other side of the story; you can build cool stuff in a matter of minutes, add your own code for some extras and it works!

Unlocking the Nemef Radaris Evolution lock

Having a remotely controllable door lock is great; being able to unlock the door with a keyfob or access card too. Especially when you compare it to the old-fashioned key method. My front door key is getting rusty, it’s not used anymore! On the other hand, when I’m at home I usually don’t have my keychain with me all the time; key-chain, cell phone and wallet have their own place in the living room so I always know where to find them.

So what happens when someone rings our doorbell? Before I can walk to the front door, I’ll have to get my key-chain cause I can’t open the door without it anymore. The simplest remedy for this is laying a keyfob or access card near the front door (in our case, on the stairs) and use that one to operate the lock. Simple and easy.

But there’s a much better solution for this! The Nemef RF Module has 3 inputs, of which input 1 can be used to temporarily unlock the Nemef Radaris Evolution. So what I did is mount a momentary on switch to the wall and connect the wires to the RF Module. Done! No more badge on the stairs and a simple push of the button is enough to unlock the door.

Momentary lock switch

My Domotica system will be notified of this push by a so-called Hardware Status Response in which a specific bit will have changed from 0 to 1, indicating that input 1 is low. Once the button is released, the same response will be received again but now with a value of 0 for the input1 bit.

After that, when the door is actually opened, Status Responses are received which reflect the changes to the lock  status, caused by opening the door and the subsequent closing of the door again. Normally, when a badge is used to unlock the door, these Status Responses are preceded by Badge Responses, so it’s very easy to detect whether the unlock was caused by using a badge or by pushing the momentary switch.

 

Another great tool is the Lock Action command; this command enables you to temporarily open the lock (the lever can be used to open the door). In our situation, this means the touchscreen in the living room can be upgraded with an extra button for opening the front door. When the doorbell is pressed, the touchscreen automatically switches to the front door camera page so we can see who’s there. From now on, with the Nemef Radaris Evolution lock integrated in our Domotica system, pushing the ‘open’ button on the touchscreen is enough to let that person in 🙂

 

 

The Nemef RF Module

From a Domotica perspective, our new Nemef Radaris Evolution is nothing more than a closed system. No communication, I/O or other ways to interface with it. But there’s a really good solution to this: the Nemef RF Module!

Nemef RF Module

The RF Module can be used for transmitting an ‘open’ command to Nemef Radaris locks, it can act as a wireless interface for RF Controllers and can also be used with products of other manufacturers. Last but not least this RF Module has a RS485 interface for easy integration into existing systems. The open ASCII protocol that is being used for the RF Module makes the combination of the Nemef Radaris Evolution and RF Module a complete solution for integration into any Domotica system, including mine.

The RF Module is also equipped with 4 relay outputs capable of switching max. 24V AC/DC @ 0,8A. On top of that, this RF Module has 3 inputs (the middle terminal block with the 6 connectors) which can be used for various pre-programmed purposes. More on that later.

In my case, the RF Module is connected to a RS48RS485 converter5 to Ethernet converter so that I can ‘talk’ to the Nemef RF Module over Ethernet.

In the last couple of weeks I’ve been working on the software side of things; classes that represent the RF Controller, RF Module and Badges have been developed and an interface class which takes care of handling the protocol and delivering the protocol data to the corresponding device class instances.

A preliminary version of the resulting page showing some of the information that’s available can be found here.

This RF Module enables me to:

  • Lock/unlock the door from my Domotica system (hence, from wherever I am);
  • Badge administration: adding and deleting badges from the RF Controllers memory and granting access to the in- and/or outside readers;
  • Configure the 3 inputs of the RF Module;
  • Switch the 4 relay outputs.

And of course, my system gets notified of all the real life events taking place on the Nemef Radaris Evolution, like

  • a badge that has been detected by a reader (which badge, which reader, whether access has been granted);
  • the status of the controller (deadbolt position, battery condition, latch status);
  • changes on each of the 3 inputs.

All this is done without the need for polling or any other kind of continuous communication; cool ; what more do you want..

More on the advantages of using the Nemef RF Module in an automated (home) environment later!

LED lighting for our gazebo

GazeboDespite all the Domotica stuff going on every day, I was able to find the time to build a gazebo in our garden this summer. I finished this gazebo in late June. Well, not quite; I still have to take care of the lighting. And somehow, everything I build or do in my spare time just has to have a Domotica touch 🙂 This time, it’s the lighting. I could have chosen the easy way and just put a big bright light bulb in the middle for when it gets too dark outside, but that’s too ugly, easy and no fun at all.

So I contacted Marco Versluis of Mood LedLight and he offered to come over and have a look at the gazebo and discuss some options for some nice and good lighting. Although I’m not the type of guy who decorates the entire home inside and outside with flashing lights at Christmas time, I do like to have nice lighting in the garden during the time that it’s dark and we’re still downstairs; an example of this is a previous garden lighting project.

This time we chose to do the lighting with 6 RGB LED spotlights.RGB LED spotlight

At each of the 6 poles of the gazebo there will be a RGB LED spotlight which will light the pole and the inside of the roof. That should be sufficient to give good lighting while sitting under the gazebo on warm nights as well as a nice view from the living room when we’re inside.

OK.. I admit it, I just couldn’t resist buying a DMX decoder for those 6 RGB LED spotlights – so I can produce 256 x 256 x 256 colors, who wouldn’t want that in his back yard? 😉 And of course, these LED spotlights need to be controlled from my Domotica system, otherwise it wouldn’t be much fun, right?

I’m not worried about accomplishing this. I found a Arduino DMX shield that should take care of the DMX encoding. And since it’s an Arduino shield and I have some unused Arduinos here, this will be plug & play, hardware-wise. Developing a sketch to control it all from my domotica system shouldn’t be that hard either.

No, the thing that I’m thinking about most of the time is: what color should these LED spotlights produce? Just pick a color I (ehh, we) like? Neh, too easy. And I certainly don’t like some predictable color scenario that repeats itself every x minutes. Yuck!

Come on, my Domotica system has almost 900 device values, why can’t I create some RGB values out of all that constantly changing data and produce a real geeky lighting? (ah, that reminds me: I need a motion sensor for the gazebo and/or a button to override the geek-lighting scheme with something that’s more moderate and acceptable for non-geeks … 🙂

So basically, I’m looking for “something” that should produce a smooth changing, unpredictable RGB value based on device values originating from our house… There’s enough to choose from I guess… like using door/window open/closed status as bits for one of the 3 RGB bytes, or on/off statuses,  motion detection, total power usage for the R value, water usage for the B value…  well, I’m still thinking what to choose – suggestions are welcome!

 

Visonic interface without a Powerlink

Whoa, some articles I wrote about the Visonic Powerlink a couple of months ago, seem to be rather popular again the last couple of days; I can see that in the WordPress Site Stats panel. And I can also tell you why; it’s because there are a number of people that have joined forces recently to reveal the protocol that’s being used by the Powerlink to communicate with the Visonic Powermax (Plus/Pro) alarm system. And for some reason people land om my blog, although my articles are not really related to the latest progress that is being made on opening up the Visonic PowerMax alarm systems.

It all started by a user named utz who started a topic on the MiCasaVerde forum and started another topic on the Domoticaforum Europe some weeks later, asking for help on reverse engineering the RS232 communication between the Visonic alarm system and the Powerlink. Well, he got some help allright 🙂 A member of the Domoticaforum even started a fundraising to buy a Powerlink especially for this goal – interfacing with the Visonic system without the need for a Powerlink!

Visonic RS232 moduleYes, all you need to communicate with your Visonic alarm system is a Visonic RS232 module, which will save you around 150 Euro on the Powerlink(2) hardware. Another advantage of bypassing the Powerlink is that the RS232 method always works (haven’t read any problems so far), in contrary to the stablity issues and even complete failure to get a PowerMax Pro communicate with a Powerlink2!

By the time I came back from vacation and read about it on the Domoticaforum, some members had already joined in reverse engineering the protocol. There’s even a Wiki for documenting everything that has been discovered about the protocol.  I (and lots of other people) immediately saw the big potential of this RS232 approach, and the decision to buy a RS232 module was made in a split second, cause I wanted to start doing some testing too.

Every now and then you come across a topic of which you think: “Wow, this is cool, very cool!”  This is one of those rare topics… thanks to all the guys that are helping on reverse engineering and documenting the protocol, cause this is a real breakthrough regarding integrating a Visonic alarm system into a Home Automation system!

Since I’m currently working on some other project, I haven’t been able to spend much time on this Visonic RS232 hack yet but I will, soon..ASAP…

I’ve got some great plans with this!

 

The Nemef Radaris Evolution

Nemef Radaris Evolution

Nemef Radaris Evolution

Since about a month we have a new door furniture on our frontdoor; the Nemef Radaris Evolution. It has been a long-cherished wish to have a electromechanic lock and now we have one, with the Radaris Evolution as matching furniture.

The Radaris Evolution that was installed on our frontdoor is equipped with 2 RFID readers; 1 on the outside and 1 inside and also has a lever on both in- and outside. To access the Radaris Evolution you can use keyfobs, remotes or credit-card sized transponder cards.

The lock is a multi-point lock, which means the lock doesn’t just have a single dead bolt; this lock has 3 hook bolts. This lock certainly provides much more security than the one we had before because this lock is SKG ** security rated and also has the dutch police “safe living” hall mark. Free levers on both sides make sure the mailbox isn’t that much of a security issue anymore either.

It’s obvious that this lock has been designed with security and convenience in mind all the time; we’ve had an electronic lock before, but this Nemef is of a  different league; you just can’t compare those 2.

The Radaris Evolution is battery-operated and can be used with 2 AA alkaline batteries, or if you prefer a longer lifetime, lithium batteries of the same size. Alkaline batteries should be able to keep the Radaris Evolution working  for  a maximum of 5 years or 45.000 operations.

Now why is this Nemef Radaris Evolution so important to write about it on a Domotica related weblog? Well, more about the Domotica link later; I have to finish some things first!

Access granted

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Keeping time

This week I had some spare time to finally deal with some things that should have been dealt with a long time ago. Things like checking my backup and performing a restore, tuning various things in my Home Automation system, and all those other things you can’t (or don’t want) to spend time on too much, but that still have to be done sometime. One of those things is time synchronization; keeping all the machines running with the same time.

One of the worst performing virtual machines regarding time synchronization is my CentOS based firewall. I started using this firewall by converting a VMWare virtual appliance to Hyper-V with the vmdk2vhd tool and it has been running flawless ever since – but with 1 irritating issue: time keeping. 2 seconds per minute is a lot! And it looked like the issue got worse when I switched from Windows Server 2008 to 2008R2 in March of this year. Let’s fix this!

I’m neither a Linux nor a Windows expert – I like to think I used to be in the days where Windows 2000 and Linux distro’s like FC3 were considered up-to-date, but since then I gradually lost track of things, primarily due to the fact that I wasn’t spending enough time with these OSes anymore. I found other hobbys ;-). vi is a nightmare for me (on Linux I prefer joe, a Wordstar-like editor), just like I have a big dislike of the recent versions of Windows Explorer – on the other hand, I do know how to configure and use Apache, IIS, Postfix, MySQL and MS SQL Server and such.

So now I had to dig into something fuzzy as time synchronization: NTP, peers, offset, jitter, delays… OMG, why doesn’t it just work like it is supposed to? Well, it seemed the NTP server running on my firewall gave up on syncing very quickly because of the very large time shift of 2 seconds per minute, so I had to find a way to correct that and help the NTP server a bit. And as it happens quite often, I Googled for a solution to my problem and hey, I’m not the only one experiencing this, what a surprise!

Even the exact combination of Host OS and guest OS that I am using is mentioned a lot, like here for example. After reading some more pages regarding this issue it seemed I only had to do some small adjustments here and there and my NTP server would be fine:

  • Disabling Time Synchronization in the Hyper-V Integration Services;
  • Add the parameters “notsc divider=10” to the kernel line in grub.conf;
  • Add “tinker panic 0” as first line in ntp.conf;
  • Remove the lines “server 127.127.1.0” and “fudge 127.127.1.0 stratum 10” from ntp.conf;
  • Restart the VM.
According to the experts, this should do the trick and it did; like clockwork!