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

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.

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

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!

Large sensor? Neh, I don’t think so; the image above will probably display the enclosure larger than life – well, on my 23″ screen it does The dimensions of the enclosure are 44 x 30 x 16 mm and it houses a PIR, a Maxim DS18B20 and a LDR.

Motion, Temperature, Light. That’s what I think I’ll need for my new sensor. Humidity will be left out; although I do have humidity sensors in my house, I don’t use them that much. For the bathroom a humidity sensor would be nice, but not for the rest of the rooms upstairs. Cause that’s where this new sensor is going to be used; at least 3 of these, one for each room and a slightly different version for the bathroom.

I’ve used this enclosure before with other PIR sensors, but this time I wanted to see if there was enough room for some more; I must say, it’s a bit crowded inside the enclosure now. The PIR has a PCB whose dimensions are 32 x 24 mm and it has lots of components, so I really need the 16 mm depth of the enclosure.

The PIR I’m using has a detachable lens, so after carefully measuring where the center of the 12 mm hole should be drilled through the cover of the enclosure, I could stick the PIR through that hole and put the lens back on the sensor. I did have to cut away some wires on the PIR side of the PCB, cause otherwise the distance between the PCB and the top cover of the enclosure was too large. After that, the PCB was glued to the top cover of the enclosure.

For the 1-Wire DS18B20 and LDR I drilled 5 x 0.5 mm holes, put the legs of these 2 sensors through the holes and fixed the legs with a tiny drop of glue, just enough to keep them in place. The housing of  the DS18B20 sticks out of the enclosure very little; you don’t see the legs sticking out. The LDR sticks out a bit more, so that the LDR won’t be hindered by any shades from the DS18B20.

Well, that all for now – now I’m facing the fact that I have to solder these 3 sensors to a single cable that has to enter this crowded enclosure somewhere… phew, what am I getting myself into?.. I hope this won’t get too messy

Today I continued with my “RGB LEDs for the gazebo” job; what would those 6 LED spotlights bring, in terms of light? How would it look? Well, here some images:

I wanted to see the result before I would start digging holes, laying cables under the pavement etcetera. Based on what I saw after sunset, the conclusion can only be: we have a Go! It’s exactly what I had in mind; which is a big relief actually, cause those 6 LED spotlights were quite an investment. But the result is wonderful, these LED spotlights light up the gazebo just the way I want.

I did have a big issue with controlling those LEDs though.. All the tests I did in my office with the LEDs on the desk next to me never failed. But today, with the LEDs, DMX decoder, Arduino+Ethernet shield+DMX shield outside it didn’t work anymore!? Everything was set up and ready to go, but I couldn’t even ping my Arduino anymore!

My first thought was that the new CAT5 cable of 20m length was broken, or the RJ45 connectors didn’t make good contact; but this was not the case, the cable was OK. Maybe it was the new Gigabit switch I received 2 days ago which hadn’t been used until now? Nope. What is this??

I took the Arduino back to the office, connected it to my PC for power and to the switch. And it worked again, just like it always did… although I did see the LEDs on the Ethernet Shield behave differently. Well, I won’t go into all the details, but eventually I found out that it was the USB connection that made the difference! Without a USB connection, I had to push the reset button on the Ethernet shield to make the shield work. With USB, the Ethernet shield worked immediately. Go figure..

What has USB got to do with a (dis)functioning Ethernet shield?? A lot, so it seems. What is this, a hidden feature? By design? I must have missed the addendum to the manual that says “This shield will only function with your Arduino USB port connected”… After I knew what was causing this problem, it didn’t take long before I found a solution – phew, this issue could have been a real party pooper! I haven’t tried the workaround yet, but I will. Very soon, as in tomorrow first thing!

Here you see me testing some colors, sitting behind my laptop under the gazebo:

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!

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!

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 http://192.168.10.177/10,0,0,5,0,0

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:

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.

Here 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!

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.

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

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!

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 RS485 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!