Z-Wave power-strip

Yesterday the Z-Wave power-strip I mentioned earlier arrived, in a light-weight large-size cardboard box mostly filled with air. After unpacking the air and reaching the bottom of the box, there it was: the GreenWave Reality PowerNode. Wow, I have never seen such a shiny bling-bling power-strip in my life ūüėČ

Since Maarten Damen already discussed some of the software related aspects¬†of this power-strip, I’ll only talk about my hardware related observations.

The power cord, which is 130 cm long, looks good. Thick and solid, like a power cord should be that has to supply 6 sockets. Personally I prefer straight plugs, but as most plugs are these days, the power cord of this power-strip also ends with a right-angled plug.

The bling-bling level of this power-strip is high; high enough for my son to ask “What’s that??”. ¬†“A power-strip, my son.” ¬†“Yeah dad, I can see that, but is there something else you can do with it as well, or what? Cause it looks so, ehh, unusual?”¬†“Yes, with this power-strip I can switch off the TV in your bedroom from the other side of the world, ain’t that cool?”


The power-strip has a On/Off button and some sort of dial. Pushing the button feels a bit cheap; no real ‘click’; and a very soft push is enough to switch the power-strip on or off. This button works too easy¬†for my taste, which increases the risk of turning the complete power-strip off¬†accidentally. The dial feels a bit cheap too; in my opinion, there’s some imbalance between look and feel here..

The 6 sockets have child protection, feel solid and keep the plugs in place firmly enough. Each socket uses 45 mm of space. With a lot of adapters this can be a problem, as with all other power-strips I have, so this power-strip is neither better nor worse as a standard power-strip in that perspective.

A standard procedure for everything with a power cord that comes into our house, is measuring the standby power usage. With nothing plugged in, this power-strip uses ‚Čą 3.5 Watt. That’s about 30.5 kWh per year. IIRC that’s about 0.9% of the yearly power consumption of an average household. (in my case, that percentage is much lower ūüėČ

So the first impression is OK. I’d love to see what’s inside,¬†but that will not happen. Yet. First I’ll hook it up to Homeseer to see if and how it works before I open it up; so that when I close it again and the strip doesn’t work anymore, I know who to blame…



Never thought this would happen, but I’m going to try Z-Wave. Yeah! Ow yeah? We’ll see..

Maybe I only read the wrong forum topics and maybe I only talked to the wrong people, but the things I read and heard about Z-Wave never gave me a good feeling about it. Z-Wave users have to deal with scheduled network optimizations, short battery life, incompatibility issues, vaporware, products where the parts have to be held together with some good old DIY with pieces of tape – hell, they sometimes even have to wait for 48 hours before a new device becomes usable… and it’s being accepted¬†by the Z-Wave users?? I don’t get it. I will never accept those kind of things, that’s for sure.

So maybe this Z-Wave adventure will be a very short one. And maybe not. At least I’ll be able to make up my mind about Z-Wave based on my own experiences for a change, once I’ve got my own hardware to test with. Maybe it’s not that bad after all … always an optimist!

The thing that triggered this Z-Wave initiative was a post on the Domoticaforum where this power-strip was discussed as an alternative for one of those vaporware products I mentioned. This powerstrip seems to be a re-branded GreenWave Reality PowerNode and I would really like to have 1 or 2 of those in my house.

So last week I ordered one at the NUON Energy shop (no, you can’t buy Energy in the shop) and ordered a Aeon Labs Z-Stick.

One tiny problem left to solve – the software side of things. From what I’ve read, the best option to get Z-Wave operational is using the OS Open Z-Wave¬†initiative, but how do I make this work in my Delphi based system? Searching for more info revealed very little to start with, and I don’t want to spend too much time on the software side while I haven’t decided if Z-Wave is a go or not… there has to be an easier way for that; at least for this experiment.

HouseAgentAnd there is – HouseAgent. Maarten Damen, the maker of HouseAgent, only lives ‘a few blocks away’ from me and he has also bought this¬†power-strip! And he has made a Z-Wave Plugin for his multi-platform Home Automation software. So why not install HouseAgent, let HouseAgent do the Z-Wave stuff and pull the data I need out of HouseAgent? That would be perfect!

Maarten told me his system has a REST API, which shouldn’t be that hard to interface with, no matter what programming language you use. Right, lets do it!


Hello, is anyone there??

The question in the title of this post can easily be answered by a person – just speak it out loud enough and listen for an answer. For a Domotica system, providing the answer can be a bit more complicated though.

OK, you’ve got motion sensors, but that doesn’t help much during the night. But there’s also an alarm system, of which the status (Off, Arm Home, Arm Away) can help. But not if someone forgot to arm it. Even monitoring water usage can help – everyone has to go to the toilet some time, right? And even leaving outside doors open may be interpreted as someone being at home, right? Another ‘input’ could be switching to another TV channel or a change in volume level of radio/TV. The same goes for the media player playing a movie. Or a change in Thermostat setpoint. Or pinging a smartphone that succeeds. And … so on. ¬†The more ‘input’ your Domotica system has, the more accurate the answer to the question will become.

And that’s what I’m facing right now: the lack ¬†of a single indicator that tells me whether there’s somebody at home or not. Based on 1160 different ‘inputs’ I (my system) should be able to produce something reliable enough to use in events, don’t you think?

But how do I do that? For that I would need ‘something’ to monitor a subset of all the available device values that are in my system. The boiler water pressure won’t be useful, but a motion sensor probably will be. And that ‘something’ should be able to have a ‘yes’ or a ‘no’ (or a ‘maybe’) as output: ‘human presence‘ .

Since nearly everything in my Domotica system is based on Interfaces, Devices and Events, a Device sounds like the best choice to me. A virtual one, in this case.¬†I already started using virtual devices 3 years ago, so the concept is not new to me. But until now, it have been the Events that operated as the ‘glue’ between all the Interfaces and Devices. Now it’s time for something different.

I don’t want to create a static Event that takes care of this ‘human presence’ indicator getting the right value. No, somehow that doesn’t feel right, cause that would mean I’d have to change the Event when a new motion sensor is added to the system, or any other device that can help me to detect whether somebody’s at home. No way, I hate to do those kind of ‘internal’ housekeeping tasks, my system should adapt itself to a new motion sensor!

What I really need is inter-device notifications, as in Device A being notified of a value change of Device B. ¬†And Device A should be able to Subscribe & Unsubscribe itself from value changes of Device B (and C, D, …) in a dynamic fashion – I don’t want anything hard coded stuff in my system, cause sooner or later this will create an inflexible system and even more work.

Another thing that has to be done is that each device (value) has to get an indicator whether it can be used as ‘presence’ information or not.

For example, I have 3 RFXMeter devices in use (in fact just simple pulse counters) for gas, water and power consumption. Gas and power consumption are more or less independent of human presence, but water usage¬†isn’t.¬†For now¬†that is, cause this can change when I’ve built an automatic irrigation system… But the example shows that a device type doesn’t say anything about it being helpful in determining human presence. Nor can I use all the motion sensors, cause some of them could be outside; so I¬†definitely¬†need a ‘can indicate presence’ attribute for every device value instance.

It may sound like this could take some work to accomplish but it’s not that hard actually.

  TDeviceValueChangeNotification = TNotifyEvent;
  PDeviceValueChangeNotification = ^TDeviceValueChangeNotification;


procedure TDeviceValue.RegisterToValueChange(NotifyProc:TDeviceValueChangeNotification);
  N: PDeviceValueChangeNotification;
  if Assigned(ValueChangeSubscriptions)
  then begin
    N^ := NotifyProc;

procedure TDeviceValue.NotifyValueChangeSubscribers;
  i: integer;
  N: TDeviceValueChangeNotification;
  for i:=0 to pred(ValueChangeSubscriptions.Count) do
    N := TDeviceValueChangeNotification(ValueChangeSubscriptions.Items[i]^);

procedure THomeStatus.OnOtherDeviceValueChange(Sender:TObject);
  aDeviceValue := TDeviceValue(Sender);

  Log('Device '+Self.ClassName+':'+Self.Address+
      ' was notified of a value change by '+aDeviceValue.ID);
  Log('Device Value '+aDeviceValue.ID+' hasn''t changed since '
       +IntToStr(aDeviceValue.SecondsSinceLastChange)+' seconds.');
  Log('The current value is :'+aDeviceValue.AsString);



if DeviceValuesList.Objects[i].canDetectHumanPresence
then DeviceValuesList.Objects[i].RegisterToValueChange(OnOtherDeviceValueChange);

Lines 1..10 define a new type for the kind of Notification I need for this and shows how to expand a DeviceValue with a list of Subscriptions.
After that the method to Register a new Subscriber and the method that has to be called whenever a Devicevalue has changed.

The last method shows the beauty of it all – the DeviceValue object where the change took place (A) is completely accessible from the other DeviceValue object (B) that subscribed to that first DeviceValue (A). Simple, very powerful and always available, whether the Devicevalue is used for temperature, a light switch or whatever.

Mounting the roller shutters

Based on a quick scan of my blog it may seem like HomeAutomation / Domotica is all about software and soldering – but it isn’t. ¬†First you have to have the right hardware you want to monitor and/ or control. The roller shutters I installed during the last weekend didn’t need a single line of code ūüėČ

Roller shutters

Roller shutters
Roller shutters

Roller shutters

Drilling holes, using the hacksaw and other ‘power tools’ were needed to create the right ‘setting’ to be able to add another feature to my Domotica system: controlling 12 roller shutters. I installed 8 of them during the last weekend.

After the first rolling shutter I (ever) installed and where everything was new and checked over and over again, the remaining 7 roller shutters were installed with an average time needed of 1- 1.5 hours each. Just do it, I’d say. Once you’ve managed to install the first one, the rest becomes easier and easier.

Last evening I started working on integrating those first 8 roller shutters into my Domotica system. First I had to be able to control the roller shutters with my 16-channel Somfy RS485 RTS Transmitter. For that I used a Somfy Telis-1 remote to get the roller shutter into programming mode and sent a command to the RS485 transmitter so that it would transmit something on the channel on which I wanted to control the roller shutter.

One thing to keep in mind when you’re programming the roller shutters,¬†is that you have to do this one at a time: remove the power from all the roller shutters except the one you’re going to program. If you don’t, you’ll be programming multiple roller shutters at the same time, probably resulting in one big mess!

After that I did some tests from my own system. Cool, the roller shutter started moving. Now it was time to upgrade the touchscreen GUI with a few up- and down buttons. Just 1 line of code was enough for each button to control the roller shutter – a simple XMLRPC call to my system did the job.

And again, total integration of a complete new ‘sub-system’ within a few hours after it was installed… I love it!

Roller shutter events

Touchscreen GUI







Roller shutter Status view

Fritz!Box Voicemail files

An item that has been on my todo list for a very long time, is finding a better way to handle voicemail.

Our Fritz!Box FON 7170 has a built-in Answering machine and a USB stick inserted into the back side. The files related to the answering machine are all stored on the USB stick and those files are all accessible by ftp and/or SMB. So everything is accessible, but finding out what to do with those files just never happened Рuntil recently.

OK, where to start… The voiceboxrec directory contains a lot of small files, called rec.0.000, rec.0.001, and so on. I know these so-called rec files contain the encoded audio of the voice mail, but there’s no information about the phone number of the caller, time & date, the called number etc. I also knew that these ‘rec’ files could be converted to WAV format by a speexdec tool that can be found on the net. Half way there.

The missing information I mentioned above had to be found somewhere else, so I examined the rest of the files in the voicebox directory. ¬†I noticed that a file called meta0 had a¬†time-stamp¬†that was equal to the date & time of the last¬†voice-mail we received, so let’s have a look inside meta0:

00000000h: 5C 01 00 00 00 00 00 00 03 00 00 00 00 53 07 00 ; ............S..
00000010h: 16 1D 00 00 07 00 00 00 01 00 00 00 01 00 00 00 ; ................
00000020h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00000030h: 00 00 00 00 30 31 32 33 34 35 36 37 38 39 00 00 ; ....0123456789..
00000040h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00000050h: 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ...............
00000060h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00000070h: 00 00 00 00 00 00 00 00 00 00 00 00 72 65 63 2E ; ............rec.
00000080h: 30 2E 30 30 30 00 00 00 00 00 00 00 00 00 00 00 ; 0.000...........
00000090h: 00 00 00 00 00 00 00 00 00 00 00 00 2F 76 61 72 ; ............/var
000000a0h: 2F 6D 65 64 69 61 2F 66 74 70 2F 55 53 42 46 6C ; /media/ftp/USBFl
000000b0h: 61 73 68 4D 65 6D 6F 72 79 2D 30 31 2F 46 52 49 ; ashMemory-01/FRI
000000c0h: 54 5A 2F 76 6F 69 63 65 62 6F 78 2F 72 65 63 2F ; TZ/voicebox/rec/
000000d0h: 72 65 63 2E 30 2E 30 30 30 00 00 00 00 00 00 00 ; rec.0.000.......
000000e0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
000000f0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00000100h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00000110h: 00 00 00 00 00 00 00 00 00 00 00 00 13 0B 09 0B ; ................
00000120h: 12 00 00 00 E8 8B 66 25 00 0C AB 2A 50 00 01 00 ; ....√®‚ÄĻf%..¬ę*P...
00000130h: 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 ; ........ .......
00000140h: 30 31 32 33 34 35 36 37 38 39 00 00 00 00 00 00 ; 0123456789......
00000150h: 00 00 00 00 00 00 00 00 00 00 00 00 5C 01 00 00 ; ...............
00000160h: 01 00 00 00 03 00 00 00 00 53 07 00 2D 10 00 00 ; .........S..-...
00000170h: 06 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00 ; ................
00000180h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00000190h: 39 38 37 36 35 34 33 32 31 30 00 00 00 00 00 00 ; 9876543210......
000001a0h: 00 00 00 00 00 00 00 00 00 00 00 00 20 00 00 00 ; ............ ...
000001b0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
000001c0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
000001d0h: 00 00 00 00 00 00 00 00 72 65 63 2E 30 2E 30 30 ; ........rec.0.00
000001e0h: 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; 1...............
000001f0h: 00 00 00 00 00 00 00 00 2F 76 61 72 2F 6D 65 64 ; ......../var/med
00000200h: 69 61 2F 66 74 70 2F 55 53 42 46 6C 61 73 68 4D ; ia/ftp/USBFlashM

Hmm, this is interesting. I see phonenumbers, file names, even including path, so I’m looking in the right file.

Let’s see if I can find a record size or something else with which I can determine the bytes that belong to a single voice mail. The first filename I found starts at position $007C and the second one starts at position $01D8. $01D8-$007C = 472-124=348 ($015C). Hey, that’s the first 2 bytes in the file! And at position $015C those 2 bytes are found again.. and again.. all the way to the end of the file.

So I think this is some sort of data file with variable length records, where the first (2?) bytes contain the length of the record that is following those 2 bytes (in this case, all the records have a length of $015C). If I’m right, the rest of the information I’m looking for per voice-mail, has to be somewhere inside those 348 bytes. Besides 2 phonenumbers and a filename, it would also be nice to have a date & time.

So I asked everybody to not pick up the phone so that I could leave a new message on the Fritz answering machine and examined the meta0 file to see if I could find the known date & time somewhere. Ha! 5 bytes, containing year-2000, month, day, hour and minute, starting at offset $011C. And I also managed to find the voice mail duration in seconds (offset $0014) ¬†and the file size. There are still some bytes of which I don’t know the meaning, but this is¬†enough to start with I guess!

With this information from the meta file and some code I can easily present a grid with voice mail information on the Touchscreen. I can even add a ‘play’ button to listen to those voice mail(s)! Adding a ‘new’ indicator to those voice mails which will be reset once the wav file has been played.


Wait, I can even play this wav file from my cell phone – a notification with a url in the message body and I’m done – lots of new opportunities!

Once I’ve got it all working here at home, I’ll upgrade my Homeseer Fritz!Box Plugin and make a nice web interface for listening to the voicemail.

Opentherm Monitor finished

This post will be the last one about the Opentherm Monitor. OTOH, when is something really completely finished…

Arduino Serial Monitor

I could spend some more hours on the Opentherm (OT) Monitor and in particular the sketch, but for now it’s good enough.¬†I should add some extra code to validate the OT frame but that would also mean I won’t be able to analyze ‘strange’ frames with unknown Data ID etcetera on my PC. So I’ll leave it as-is for ¬†now. The Opentherm Gateway is waiting ūüėČ

From what I’ve seen during the last 24 hours, the ‘quality’ of the frames I receive is quite good; somehow there seems to be an invalid frame on the wires every minute or so, and I can’t find out what it is. This same thing happens with the Opentherm Gateway Monitor, so I think both are having the same problem. The Data ID tells me it’s probably an OEM frame…?

OpenTherm Decoder

The Opentherm Decoder running on my PC receives the 4 OT bytes from a serial port and decodes those bytes to something human readable: whether the frame came from the Thermostat or the Boiler, Message type and the meaning of the Data ID. The 16-bit data value (there where you can find the temperatures, pressure and status bits) is not decoded yet; well, it’s all in the Opentherm Protocol documentation, so that should be no problem.

Now I can use this Opentherm Monitor as an additional display near the boiler! The Remeha Calenta already has a rather large display showing stuff like status, water pressure, whether the pump is running, but it doesn’t display flow- and return temperature, control setpoint and I’m sure I can think of some more interesting stuff I wanna see – that’s what the Opentherm Monitor is going to do for me. I already have a 16×4 LCD, so all I have left to do is finding a suitable enclosure, build everything in there and I’m done!

I really liked getting this Opentherm Monitor to work without errors; in fact, getting it to work was more exciting than building it. Learning on the job about ATMega timers, Manchester decoding and programming the whole thing in C from scratch was one big adventure.

The most important references I used were:

And here‘s the sketch- no additional libraries needed, free to use and no guarantees that it will work for you just as well as it does for me. Have fun!


Controlling roller shutters

6-7 years ago we installed a roller shutter at the window of our sons bedroom. Main reason was to keep his bedroom cool during the summer, but also to make it really dark in there if it was necessary. Roller shutters are very good at keeping the heat out during the summer, but they can also improve isolation during the winter. And of course, they create a delaying barrier for uninvited guests.

So for this year we decided to install roller shutters on almost all of our windows; both up- and downstairs. ¬†This resulted in a total of 12 rolling shutters. Yep, that’s a lot…

So, how are we going to control all these roller shutters? With 12 remotes? Neh. With 1 remote, where you first have to select the shutter you want to control with an average of 6 button clicks? Nope. And where it’s hard to control variable groups of roller shutters at the same time with 1 click of a button? No. Or only lower the shutters that are located on the south side of the house? No! Sounds like horror, home automation-wise..

It does¬†cost a lot of money to automate 12 roller shutters, but I’m sure that if we want to really use these roller shutters efficiently, there has to be some sort of automation involved. And I don’t just say that because I like to automate things ūüėČ

Somfy has a wide range of products to control awnings, blinds, garage doors and roller shutters. Either by wall mounted controls, remote controls; the 3rd option is the Somfy RS485 RTS Transmitter:

This transmitter is not only for roller shutters; it can also be used to control other products like screens, curtains, blinds etcetera. This 16 channel 433 MHz transmitter has a RS-485 to connect this transmitter to non-Somfy systems (like mine), the protocol is well documented, so nothing stands in the way to integrate our dozen roller shutters.

Being the impatient one, I already have this transmitter for a week while the roller shutters have been ordered today – and the software interface is already finished for as far I can see without being able to do a hardware test. Cause the protocol is relatively easy, it didn’t take very long to write the code.

The RS485 protocol works with variable length frames which look like this:

Somfy RS485 frame

Message ID, ACK bit, frame length, node type, source & destination address, payload and checksum. That’s it. Defining this in Delphi could look like this:

  TSomfyNodeID = array[1..3] of byte;
  TSomfyNodeType = byte;
  TSomfyFrameData = TDynByteArray;
  TSomfyChecksum = word;

  TSomfyFrame = class(TObject)
    _MSG : byte;
    _ACKLEN : byte;
    _NODETYPE : byte;
    _SOURCE : TSOmfyNodeID;
    _DEST : TSOmfyNodeID;
    _DATA : TSomfyFrameData;
    _CHECKSUM : TSOmfyChecksum;

  TSomfyRXFrame = class(TSomfyFrame)
    function Validate:boolean;
    constructor Create(const RawData:String); virtual;
    property Valid:boolean read Validate;

An additional ‚Čą200 lines of code and the interface is finished; another 30 lines of code for the ‘RollerShutter’ device class and everything is in place to control the roller shutters from my system: triggered by events, with our own remotes, ¬†touchscreens – whatever we want.

Can’t wait!