Monthly Archives: September 2011

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!

Updating the all-in-one remote

  By Robert Hekkers | September 25, 2011 - 21:37 |
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 |
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 |
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 |
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.

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!

A new all-in-one sensor

  By Robert Hekkers | September 11, 2011 - 08:08 |
10 Comments


All-in-one sensor

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.

What's inside

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

 

Success and failure

  By Robert Hekkers | September 3, 2011 - 22:39 |
Comments Off

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:

 

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!