Docker revisited: OpenHAB 2.0 on Synology

paper-ui

After testing the OpenHab 1.7.0 on Synology, it came to my mind that having now a working Docker setup would be great environment for trying out the daily snapshots of OpenHAB 2.0 alpha. Its new GUI, the Paper UI looks quite nice, and with it’s built-in autodetection one could configure at least some of the devices without fiddling with config files. I confess – As much I love hacking and tweaking, I’d still prefer devices to “just work”. Fine-tuning can come later, but it would be nice if I could play with devices as much as possible by just plugging them in, and in this regard OpenHAB is going right direction with its Paper UI.

Unfortunately there were no public Docker images for OpenHAB 2.0, so I had to roll my own. Here are the links to the Docker hub page and GitHub repository

Image can be downloaded with command:

docker pull wetware/openhab2

For further instructions for configuration and running the container, please see the Docker and GitHub pages above.

Information about changes in configuration and running between OpenHAB 1.x and 2.0 can be found here

Auto-detection of devices with UPnP

Unfortunately not all things work out-of-the-box when using Docker containers due to the missing multicasting support. Auto-discovery of new devices in Openhab 2.0’s new Paper UI uses mainly UPnP protocol. Also protocol called AllJoyn is listed, but I’m not that familiar with that one, although the supported devices and services list seems interesting (especially Spotify).

Detection is done by sending discovery UDP messages to address 239.255.255.250:1900. Other UPnP devices (such as Philips Hue hub) will response with a message to this same address. Sending the UDP multicast message is done correctly from the container, but receiving them however requires support from Docker to enable MULTICASTING on container network interface, which is not yet implemented (7/2015). You can follow the discussion here at the GitHub issue page There are 2 work-arounds available:

  • Run container with –net=host option. This will use the network interface of the host instead of creating a separate one for the container. In practice it will map 1:1 all ports on the container to the host and enable the container to receive multicast UDP messages.
  • Run container with –net=none option. This defers creating the network interface during the startup. Then on the host use pipework to create the network interface on the container side with IFF_MULTICAST set:
pipework docker0 -i eth0 CONTAINER_ID IP_ADDRESS/IP_MASK@DEFAULT_ROUTE_IP

BTW. If you have Philips Hue, the auto-detection for lights and other devices connected to the hub might not work automatically, since the hub must be first paired with OpenHAB. The Paper UI does not currently explicitly say this, but after the hub is detected, OpenHAB is waiting for the user to press a pairing button on the hub. Before the button is pressed, no devices can be found.

Feedback

As with the previous OpenHAB Docker image, I’d be happy to receive any comments, bug reports or other feedback related to running OpenHAB 2.0 on Docker!

Setting sails with Docker: OpenHAB on Synology

My weekend project has been with Docker. Unless you have been living in a barrel in the middle of Sahara, you might have heard of it. For those who haven’t, please DO check it out – it’s almost the best thing since sliced bread. Up until now, I really hadn’t had time nor a use-case where Docker containers would be useful, but recently few incidents set the ball in motion and I decided to jump in the Docker bandwagon.

First was the trouble with Raspberry Pi SD cards. I thought I would have spared from the rampant file system corruption when I bought a supposedly compatible and reliable Kingston SD card and then made sure that I don’t EVER turn it off without explicit shutdown command from the command line. Also Openhab and Z-Way servers were configured not to trash the SD card with excessive logging (by moving the /var/log to memory using tmpfs). Still, I managed somehow to corrupt the file system on three separate occasions. It was not that funny to discover after rebooting that connections to outside servers were crippled. After some head-scratching I found out that /lib/libresolv.so had just vanished! After re-installing and re-configuring the whole system again it wouldn’t reboot anymore. The culprit was this time missing /etc/inittab … You can guess my frustration. The corruption may have been caused by the shutdown scripts hanging before the root filesystem was un-mounted and causing data corruption when I pulled the plug. Just a hypothesis – I haven’t had trouble after I started to shutdown RPi directly from the console while viewing the logs with a monitor hooked up to the RPi, making sure the system really is halted before switching it off. Solution wise, there are of course ways to make the file system read-only, but the whole incident made me think if I should migrate from RPi to something more robust.

I have a Synology 1812+ 8-bay NAS that serves as a local network provider for music, movies and personal files, as well as backup target for various devices (such as my desktop computer and laptop). I’ve once tried hacking with it, but I remember having trouble installing even such basic stuff as multi-threaded Perl on Synology. Exercises in trying to compile anything more complex than “Hello World” have been getting resistance in the form of dozens missing library dependencies. The custom Linux distro that Synology uses is quite limited, and I wasn’t prepared to brute force it open with the possibility of breaking stuff and data loss lingering in my mind. Just wasn’t worth the fight at that time.

It all changed when I heard the news about the new Synology DSM 5.2 having Docker on its application center as a turn-key solution. Now we’re getting somewhere!

Preparing the Synology

First I needed to update to DSM 5.2. That wasn’t exactly straightforward, since for some reason the update function of web based DSM didn’t work (“Connection failed. Please check you network connection.”) There was nothing wrong with my network settings and this was a known problem with some versions of DSM 4.2. Nor did the instructions on how to update it manually via shell work. My last resort was to boot the Synology to network update mode and only after then could the firmware be updated to 5.2 from desktop computer with pre-downloaded DSM file. Obviously, backups were made of all important files before that.

After that I enabled the SSH shell (it’s there on DSM’s Control Panel / Terminal & SNMP window), logged in and installed bootstrap script to enable ipkg in order to install vim, bash and other more familiar unix tools.

I use 3 * 3 TB Western Digital drives in RAID5 configuration to serve most of my files, but I had an extra 120gb SSD drive laying around that I decided to dedicate to Docker, since there’s never enough speed when moving around these few hundred MB containers. Since containers itself are easily downloadable and disposable, I don’t need to worry about backups so much – only these small data volumes that contain user data and configuration files need to be backupped to the main RAID volume with a regular cron script, so I could just run Docker from single disk configuration.

The Docker can be installed from the DSMs application manager, and even though it’s not the newest version (1.6.2 on Synology and 1.7.0 on Github), there doesn’t seem to be big changes according to changelog, so I took the route of least resistance and used app manager to install Docker. BTW, one nice tutorial for Docker on Synology can be found here, showing how to install GitLab and Jenkins on Synology as Docker containers. I personally tried GitLab but it is a bit memory hog (taking several hundred megabytes of the 1 gig memory on 1812+), so I chose to use the more light-weight Gogs. Also it can be found as a Docker container (my pick was the one by codeskyblue).

Installing Openhab Docker container

I first tried the most popular Openhab container from tdecker, but found out that there was this one bug with managing addons (though easily fixed), but there also was no easy way to turn on debugging and logging, so I customized my own Docker container (wetware/openhab on Docker Hub, wetwarelabs/docker-openhab on GitHub). Also JDK 1.7 was replaced with JRE 1.8 for slightly smaller images and faster execution.

The container can be downloaded with command:

docker pull wetware/openhab

Directories for config files and logs are created (here on my new SSD volume):

mkdir /volume3/openhab
mkdir /volume3/openhab/configurations
mkdir /volume3/openhab/logs

Then it is easy to map the /volume3/openhab as a new Samba network share on a desktop computer if one likes to remotely edit the configuration files or follow logs easily (I did that previously on Raspberry too).

Instrunctions for configuring and running the container can be found on both GitHub and Docker hub pages. You could then either copy your existing Openhab configuration (from Raspberry etc) to configurations directory, or run Openhab in a demo mode.

After configuring addons and timezone, Openhab can be run with command:

docker run -d -p 8080:8080 -p 9001:9001 -v /volume3/openhab/configurations/:/etc/openhab -v /volume3/openhab/logs:/opt/openhab/logs wetware/openhab

This maps configuration and logging directory from the host to the container as well as allows access to Supervisor (in port 9001) and Openhab web page (in port 8080).

If you then want to monitor Openhab running status or switch between normal and debug mode, you can do it from Supervisor web page (http://your.host:9001).

Aftermath

Migrating Openhab from Raspberry Pi to Synology has been quite pain-free, and these past few days it has been running happily inside the container. I also think that the extra CPU power doesn’t hurt running the complex Java beast that Openhab is, either. Of course Mosquitto and mqttwarn are still running on Raspberry, but I think I’ll try converting them to Docker containers as well in the near future. That would leave the Z-Way server and Razberry the sole inhabitants on my RasPi, but I think there might be workarounds to get them running on Synology too..!

Anyway, I hope you too try out the Openhab container and let me hear if you have any issues, regardless of whether you have Synology or not!

Wall switch wonderland

wallc-s-e

In my previous post I explained how to connect Z-Wave (Plus) wall plugs to Openhab via MQTT with the help of mqttwarn and Z-Way server. Today is time to do the same with Z-Wave.me WALLC-S wall switches. Some people have been able to get these to work just fine, but I stumbled across to quite many posts where people have been having trouble configuring them especially in DIY installations, such as Openhab.

These too are Z-Wave Plus (Gen 5) devices that require SECURITY class functionality from Z-Wave server and thus there was no way to use them with the Z-Wave stack of Openhab. I did try to turn off the security functionality but in the end didn’t figure out how to do that. Nonetheless, the Z-way server from Z-Wave.me (that we hacked a bit in the previous post) works with these switches just fine. I like also the ability to decouple the handling of Z-Wave communication from Openhab and use MQTT as the interface for as many devices as possible.

WALLC-S can act as a basic on/off switch, dimmer as well as a scene switch. I didn’t want to program any kind of scene handling to devices but instead let the Openhab handle all the logic side, so dumb on/off and dimmer functionality is enough for my needs.

wallc-s-conf

After Z-Wave device inclusion we must first add the Z-Way server (more accurately, the Razberry) to WALLC-S’s control groups A and B (to receive notifications about button #1 and #3 presses) as well as to its “Life line” group (to receive update and battery status messages). Note that we must associate each WALLC-S to unique instance of Razberry to differentiate between switches. So for WALLC-S #1 (and #2), it is added to instance #1 (and #2 respectively) of control groups A and B.

Then we have to configure the button behaviour. I have a single paddle on both of the switches, so I set the switch in a pair mode (uppermost buttons 1 and 2 work in pairs, as well as the lower row buttons 3 and 4). Actually separate mode would work just as well, since we are not interested in the control group C and D messages.

Finally we configure for both control groups the command type which is sent to Razberry, in this case “Switch On/Off and Dim”.

Another Z-Way JSON debugging session…

Now when buttons #1 and #3 of WALLC-S #1 are pressed, the following data structures are updated:

[2015-07-11 01:24:02.944] [D] [zway] SETDATA devices.1.instances.1.commandClasses.32.data.srcNodeId = 22 (0x00000016)
[2015-07-11 01:24:02.945] [D] [zway] SETDATA devices.1.instances.1.commandClasses.32.data.srcInstanceId = 0 (0x00000000)
[2015-07-11 01:24:02.945] [D] [zway] SETDATA devices.1.instances.1.commandClasses.32.data.level = 255 (0x000000ff)
.
.
[2015-07-11 01:25:24.109] [D] [zway] SETDATA devices.1.instances.1.commandClasses.32.data.srcNodeId = 22 (0x00000016)
[2015-07-11 01:25:24.109] [D] [zway] SETDATA devices.1.instances.1.commandClasses.32.data.srcInstanceId = 0 (0x00000000)
[2015-07-11 01:25:24.110] [D] [zway] SETDATA devices.1.instances.1.commandClasses.32.data.level = 0 (0x00000000)

So command class 32 level is 255 for button #1 press and 0 for button #3 press.

Battery levels are received like this:

[2015-07-11 01:31:40.961] [D] [zway] SETDATA devices.22.data.lastReceived = 0 (0x00000000)
[2015-07-11 01:31:40.961] [D] [zway] SETDATA devices.22.instances.0.commandClasses.128.data.history.96 = 1436567500 (0x55a047cc)
[2015-07-11 01:31:40.962] [D] [zway] SETDATA devices.22.instances.0.commandClasses.128.data.last = 96 (0x00000060)

When button #1 is kept pressed (dimmer up)..

[2015-07-11 15:21:11.145] [D] [zway] SETDATA devices.19.data.lastReceived = 0 (0x00000000)
[2015-07-11 15:21:11.146] [D] [zway] SETDATA devices.1.instances.2.commandClasses.38.data.srcNodeId = 19 (0x00000013)
[2015-07-11 15:21:11.146] [D] [zway] SETDATA devices.1.instances.2.commandClasses.38.data.srcInstanceId = 0 (0x00000000)
[2015-07-11 15:21:11.146] [D] [zway] SETDATA devices.1.instances.2.commandClasses.38.data.startChange = True

..and released:

[2015-07-11 15:21:12.650] [D] [zway] SETDATA devices.19.data.lastReceived = 0 (0x00000000)
[2015-07-11 15:21:12.650] [D] [zway] SETDATA devices.1.instances.2.commandClasses.38.data.srcNodeId = 19 (0x00000013)
[2015-07-11 15:21:12.650] [D] [zway] SETDATA devices.1.instances.2.commandClasses.38.data.srcInstanceId = 0 (0x00000000)
[2015-07-11 15:21:12.650] [D] [zway] SETDATA devices.1.instances.2.commandClasses.38.data.stopChange = Empty

Similarily, button #3 is kept pressed (dimmer down)..

[2015-07-11 15:25:11.367] [D] [zway] SETDATA devices.19.data.lastReceived = 0 (0x00000000)
[2015-07-11 15:25:11.368] [D] [zway] SETDATA devices.1.instances.2.commandClasses.38.data.srcNodeId = 19 (0x00000013)
[2015-07-11 15:25:11.368] [D] [zway] SETDATA devices.1.instances.2.commandClasses.38.data.srcInstanceId = 0 (0x00000000)
[2015-07-11 15:25:11.368] [D] [zway] SETDATA devices.1.instances.2.commandClasses.38.data.startChange = False

..and released:

[2015-07-11 15:25:12.440] [D] [zway] SETDATA devices.19.data.lastReceived = 0 (0x00000000)
[2015-07-11 15:25:12.440] [D] [zway] SETDATA devices.1.instances.2.commandClasses.38.data.srcNodeId = 19 (0x00000013)
[2015-07-11 15:25:12.440] [D] [zway] SETDATA devices.1.instances.2.commandClasses.38.data.srcInstanceId = 0 (0x00000000)
[2015-07-11 15:25:12.440] [D] [zway] SETDATA devices.1.instances.2.commandClasses.38.data.stopChange = Empty

So the “StopChange” indicates button release and “StartChange” is true for dimmer up and false for dimmer down. Note that the actual values will be lingering in the JSON tree long after buttons have been released and StopChange doesn’t seem to ever change its value, but only the updateTime tag is updated. Nonetheless, we don’t have to check for changes in values but just bind to the JSON tree to get notifications when the tags have been updated, just like in previous post.

I found out that Z-Way server holds no functionality to contain dimmer value nor there is any way to automatically get notifications on certain intervals that the button is still kept pressed, so we have to implement our on notification mechanism with timers in JavaScript. For the actual dimmer value (e.g. 0-100%), we let Openhab take care of that.

Hooking Z-Way server…

The amount of our extra code in main.js of Z-Way server is getting bigger (see the previous post), so we move it to separate file (mqtt.js) and just put this in the end of main.js:

    executeFile("mqtt.js");

In mqtt.js we define (in addition to Wall Plug code explained in the previous post)


// Here the id:19 and id:22 are hardcoded Z-Wave device ID's. Change them (and associated instance IDs) accordingly to your setup
var dimmers = [];
dimmers.push( { id:19, instance:1, timer:null, timercount:0 } );
dimmers.push( { id:22, instance:2, timer:null, timercount:0 } );

var dimmer_publish_interval = 100;  // in milliseconds

function getById(id, myArray) {
        for ( var i=0; i<myArray.length; i++) {
                if(myArray[i].id == id) {
                         return myArray[i];
                }
        }
        return null;
}

function battery_level_publish (device, theValue) {
        eventString = 'Device' + device + "/battery";
        publish_mqtt(eventString, theValue);
}

function wallswitch_binary (device, theValue) {
        eventString = 'Device' + device + "/wallswitch/binary";
        state = 'on';
        if (theValue == false){
                state = 'off';
        }
        publish_mqtt(eventString, state);
}

function wallswitch_dimmer_publish (device, theValue) {
        eventString = 'Device' + device + "/wallswitch/dimmer";
        state = 'increase';
        if (theValue == false){
                state = 'decrease';
        }
        publish_mqtt(eventString, state);
}

function wallswitch_dimmer_start (device, theValue) {
        wallswitch_dimmer_publish (device, theValue);
        dimmer = getById(device, dimmers);
        if (dimmer != null)
        {
                if (dimmer.timer != null) {
                        clearInterval(dimmer.timer);
                }
                dimmer.timercount = 0;
                dimmer.timer = setInterval(
                        function() {
                                wallswitch_dimmer_publish (device, theValue);
                                dimmer.timercount++;
                                if (dimmer.timercount>20) {
                                        // this is to stop sending updates eventually if for some reason the "dimmer_stop" 
                                        // message is not received and the dimmer gets "stuck"
                                        clearInterval(dimmer.timer);
                                }
                        }, dimmer_publish_interval);
        } else
        {
                console.log("dimmer not found!");
        }
}


function wallswitch_dimmer_stop (device, theValue) {
        dimmer = getById(device, dimmers);
        if (dimmer != null)
        {
                if (dimmer.timer != null)
                        clearInterval(dimmer.timer);
        }
}

// Binding to WALLC-S devices
for (var i=0; i < dimmers.length; i++) {

        var id = dimmers[i].id;
        (function(devid) {
                console.log("MQTT plugin: Configure dimmer " + devid);
                zway.devices[1].instances[ dimmers[i].instance ].commandClasses[38].data.startChange.bind(function() {
                        wallswitch_dimmer_start ( devid, this.value);
                });
                zway.devices[1].instances[ dimmers[i].instance ].commandClasses[38].data.stopChange.bind(function() {
                    wallswitch_dimmer_stop( devid, this.value);
                 });
                zway.devices[1].instances[ dimmers[i].instance ] .commandClasses[32].data.level.bind(function() {
                    console.log("MQTT plugin: wallswitch #" + devid + ": binary " + this.value);
                    wallswitch_binary (devid, this.value);
                 });
                zway.devices[ dimmers[i].id ].instances[0].commandClasses[128].data.last.bind(function() {
                    battery_level_publish (devid, this.value);
                 });
        })(id); // tie device ID so it is referenced correctly from callback funcs
}


And when testing the following MQTT messages are seen:

home/zwave/Device22/wallswitch/binary on
home/zwave/Device22/wallswitch/dimmer increase
home/zwave/Device22/wallswitch/dimmer increase
home/zwave/Device22/wallswitch/dimmer increase
home/zwave/Device22/wallswitch/dimmer increase
home/zwave/Device22/wallswitch/dimmer increase
home/zwave/Device22/wallswitch/dimmer increase
home/zwave/Device22/wallswitch/dimmer decrease
home/zwave/Device22/wallswitch/dimmer decrease
home/zwave/Device22/wallswitch/dimmer decrease
home/zwave/Device22/wallswitch/dimmer decrease
home/zwave/Device22/wallswitch/dimmer decrease
home/zwave/Device22/wallswitch/binary off
home/zwave/Device22/battery 96

It works! ūüôā

Openhab configuration

We can then define the items in .items file..

Switch Kitchen_Light_Switch "Kitchen light switch" (GF_Kitchen)  {mqtt="<[mosquitto:home/zwave/Device19/wallswitch/binary:state:MAP(wallswitchFromMqtt.map)]"}
String Kitchen_Light_Dimmer "Kitchen light switch" (GF_Kitchen)  {mqtt="<[mosquitto:home/zwave/Device19/wallswitch/dimmer:state:MAP(wallswitchFromMqtt.map)]"}
Number Kitchen_Light_Switch_Battery "Kitchen light switch battery [%3f %]" (gBattery,GF_Kitchen) {mqtt="<[mosquitto:home/zwave/Device22/battery:state:default"}

And add appropriate rules in .rules file:

var Integer manualTimeOut = 1800

rule "Kitchen Light Switch"
        when
        Item Kitchen_Light_Switch received update
        then
{
    logInfo("Kitchen Light Switch", "button changed state ("+Kitchen_Light_Switch.state +")")
    if (Kitchen_Light_Switch.state==ON)
        {
        sendCommand(Kitchen_Light_Toggle, ON)  
        sendCommand(Kitchen_Light_CT_Dimm, Color_Temperature.state as DecimalType)
        if (KitchenTimer == null )
            {                       
            // create timer
            logInfo("Kitchen Light Switch", " creating timer for " + manualTimeOut + "sec" )
                        
            KitchenTimer = createTimer( now.plusSeconds(manualTimeOut) )
                [ 
                logInfo("Kitchen Light Switch", "timer expired, switching off ")
                sendCommand(Kitchen_Light_Toggle,OFF)       
                KitchenTimer=null
                ]               
            }
        else
            {
                logInfo("Kitchen Light Switch", " rescheduling timer" )
                KitchenTimer.reschedule(now.plusSeconds(manualTimeOut))
            }
        }
    else
        {
        sendCommand(Kitchen_Light_Toggle, OFF)                  
        if (KitchenTimer != null )
            KitchenTimer.cancel
        KitchenTimer=null
        }
}
end

rule "Kitchen Light Dimmer"
    when
        Item Kitchen_Light_Dimmer received update
    then
{
    logInfo("Kitchen Light Dimmer", "changed state ("+Kitchen_Light_Dimmer.state +")")
    if (Kitchen_Light_Dimmer.state=="INCREASE")
        {
        sendCommand(Kitchen_Light_Dimm, INCREASE)
        }
    else
        {
        sendCommand(Kitchen_Light_Dimm, DECREASE)
        }
}
end

Also add the transformation map wallswitchFromMqtt.map

on=ON
off=OFF
increase=INCREASE
decrease=DECREASE

With this configuration the setup works nicely, except that there's 500-600 millisecond delay between a button press and a change in lighting, most of which can be accounted to Z-Wave (delay inside WALLC-S, Z-Wave transceiver, decoding and Z-Way server). When our JSON binding callback is called, a MQTT message is sent nearly instantaneously and Philips Hue lights react also quite quickly. I have to look into it more deeply in the future whether there's any way to speed up it a bit.

Trouble in Z-Wave paradise: Decoupling Z-Wave from Openhab via MQTT

In the previous post I described how I successfully connected Everspring AN158 (a non-Z-Wave Plus) device to Openhab. However the Z-Wave Plus devices (Aeon Smart Switch and Z-Wave.me WALLC-S) haven’t been that cooperative. It seems that the SECURITY class used by Z-Wave Plus devices is not quite that well supported by Openhab Z-Wave engine. I know that the issue is with Openhab, since I can easily turn the smart switch on and off with Z-Way server GUI.

After configuring the devices with Z-Way server I shut it down (as it cannot co-exist with Openhab since they both use exclusively the /dev/ttyAMA0 device which RazBerry binds to). Then I browesed through the Openhab Z-Wave logs after pushing manually the on/off button on Aeon switch:

2015-07-07 20:40:22.092 [DEBUG] [eController$ZWaveReceiveThread:1528]- Receive Message = 01 11 00 49 84 14 0B 04 10 01 5E 86 72 98 56 EF 5A 82 7A
2015-07-07 20:40:22.096 [DEBUG] [eController$ZWaveReceiveThread:1452]- Receive queue ADD: Length=1
2015-07-07 20:40:22.096 [DEBUG] [b.z.i.protocol.ZWaveController:1210]- Receive queue TAKE: Length=0
2015-07-07 20:40:22.100 [DEBUG] [o.b.z.i.protocol.SerialMessage:233 ]- Assembled message buffer = 01 11 00 49 84 14 0B 04 10 01 5E 86 72 98 56 EF 5A 82 7A
2015-07-07 20:40:22.103 [DEBUG] [b.z.i.protocol.ZWaveController:1211]- Process Message = 01 11 00 49 84 14 0B 04 10 01 5E 86 72 98 56 EF 5A 82 7A
2015-07-07 20:40:22.106 [DEBUG] [b.z.i.protocol.ZWaveController:190 ]- Message: class = ApplicationUpdate (0x49), type = Request (0x00), payload = 84 14 0B 04 10 01 5E 86 72 98 56 EF 5A 82
2015-07-07 20:40:22.107 [DEBUG] [.ApplicationUpdateMessageClass:44  ]- NODE 20: Application update request. Node information received.
2015-07-07 20:40:22.109 [WARN ] [.o.b.z.i.p.c.ZWaveCommandClass:221 ]- NODE 20: Unsupported command class ZWAVE_PLUS_INFO
2015-07-07 20:40:22.111 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:224 ]- NODE 20: Creating new instance of command class VERSION
2015-07-07 20:40:22.114 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:224 ]- NODE 20: Creating new instance of command class MANUFACTURER_SPECIFIC
2015-07-07 20:40:22.116 [WARN ] [.o.b.z.i.p.c.ZWaveCommandClass:221 ]- NODE 20: Unsupported command class SECURITY
2015-07-07 20:40:22.118 [DEBUG] [.o.b.z.i.p.c.ZWaveCommandClass:224 ]- NODE 20: Creating new instance of command class CRC_16_ENCAP
2015-07-07 20:40:22.121 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:63  ]- Sent message Message: class = SendData (0x13), type = Request (0x00), payload = 15 01 00
2015-07-07 20:40:22.124 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:64  ]- Recv message Message: class = ApplicationUpdate (0x49), type = Request (0x00), payload = 84 14 0B 04 10 01 5E 86 72 98 56 EF 5A 82
2015-07-07 20:40:22.125 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:65  ]- Checking transaction complete: class=ApplicationUpdate, expected=SendData, cancelled=false
2015-07-07 20:40:23.053 [DEBUG] [eController$ZWaveReceiveThread:1528]- Receive Message = 01 08 00 04 00 14 02 98 40 3D
2015-07-07 20:40:23.056 [DEBUG] [eController$ZWaveReceiveThread:1452]- Receive queue ADD: Length=1
2015-07-07 20:40:23.056 [DEBUG] [b.z.i.protocol.ZWaveController:1210]- Receive queue TAKE: Length=0
2015-07-07 20:40:23.060 [DEBUG] [o.b.z.i.protocol.SerialMessage:233 ]- Assembled message buffer = 01 08 00 04 00 14 02 98 40 3D
2015-07-07 20:40:23.062 [DEBUG] [b.z.i.protocol.ZWaveController:1211]- Process Message = 01 08 00 04 00 14 02 98 40 3D
2015-07-07 20:40:23.064 [DEBUG] [b.z.i.protocol.ZWaveController:190 ]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 14 02 98 40
2015-07-07 20:40:23.066 [DEBUG] [ApplicationCommandMessageClass:38  ]- NODE 20: Application Command Request (ALIVE:DYNAMIC_VALUES)
2015-07-07 20:40:23.068 [DEBUG] [ApplicationCommandMessageClass:56  ]- NODE 20: Incoming command class SECURITY
2015-07-07 20:40:23.069 [DEBUG] [ApplicationCommandMessageClass:62  ]- NODE 20: Command class SECURITY not found, trying to add it.
2015-07-07 20:40:23.071 [WARN ] [.o.b.z.i.p.c.ZWaveCommandClass:221 ]- NODE 20: Unsupported command class SECURITY
2015-07-07 20:40:23.073 [ERROR] [ApplicationCommandMessageClass:75  ]- NODE 20: Unsupported command class SECURITY (0x98)

Also similar error messages can be seen with WALLC-S when I push one of its buttons:

2015-07-07 20:29:04.626 [DEBUG] [eController$ZWaveReceiveThread:1528]- Receive Message = 01 08 00 04 00 05 02 98 40 2C
2015-07-07 20:29:04.629 [DEBUG] [eController$ZWaveReceiveThread:1452]- Receive queue ADD: Length=1
2015-07-07 20:29:04.630 [DEBUG] [b.z.i.protocol.ZWaveController:1210]- Receive queue TAKE: Length=0
2015-07-07 20:29:04.633 [DEBUG] [o.b.z.i.protocol.SerialMessage:233 ]- Assembled message buffer = 01 08 00 04 00 05 02 98 40 2C
2015-07-07 20:29:04.635 [DEBUG] [b.z.i.protocol.ZWaveController:1211]- Process Message = 01 08 00 04 00 05 02 98 40 2C
2015-07-07 20:29:04.637 [DEBUG] [b.z.i.protocol.ZWaveController:190 ]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 05 02 98 40
2015-07-07 20:29:04.638 [DEBUG] [ApplicationCommandMessageClass:38  ]- NODE 5: Application Command Request (ALIVE:PING)
2015-07-07 20:29:04.640 [DEBUG] [ApplicationCommandMessageClass:56  ]- NODE 5: Incoming command class SECURITY
2015-07-07 20:29:04.641 [DEBUG] [ApplicationCommandMessageClass:62  ]- NODE 5: Command class SECURITY not found, trying to add it.
2015-07-07 20:29:04.643 [WARN ] [.o.b.z.i.p.c.ZWaveCommandClass:221 ]- NODE 5: Unsupported command class SECURITY
2015-07-07 20:29:04.644 [ERROR] [ApplicationCommandMessageClass:75  ]- NODE 5: Unsupported command class SECURITY (0x98)

Documentation regarding Z-Wave Plus security is sparse, but OpenZWave (another z-wave stack NOT used by Openhab) has this very nice and informative page.

So, maybe it’s an issue with Z-Way server setting up a Network Key to manage encrypted communication with Plus devices but now Openhab doesn’t know the Network key and fails?
In /opt/z-way-server/config-zddx/ directory is a file named something like cb2ce85ed-DevicesData.xml that contains an entry such as:

   <data name="networkKey" invalidateTime="1435679337" updateTime="1435679338" type="binary" value="[ 35 c3 34 b2 44 e3 cf ca 23 db b1 3d 15 79 07 12 ]"/>

Bingo! Now, how to configure Openhab with it?

I browsed through the configuration files and their GitHub repository, but didn’t find any real references to implementation of Security Class. Quick search on their Google group provided a discussion about it. It seems (as of July 2015) the Z-Wave Security is still not supported. That’s a bummer.. Now, I could start using OpenZWave since it has preliminary support for it, but there’s no way to use it with Openhab, but instead I would be forced to switch to Domotiga, Domoticz, Jeedom or other system using OpenZWave. Since Z-Wave documentation is behind NDA and open-source implementation requires reverse-engineering it, I wonder why there are two different camps re-inventing the wheel (OpenZWave and Z-Wave stack of Openhab). For historical reasons? Openhab itself is a already a huge monolith, so the reason why they have decided to split the effort and code their own Z-Wave stack is just beyond me..

Anyway, to use Z-Wave Plus devices with Openhab there’s another way..

MQTT cavarly to the rescue!

From a DIY perspective, it’s best to use separate components that each do their own job very well instead of relying on a monolith that tries to do everything on its own. I decided to decouple Z-Wave from Openhab using MQTT, but I wasn’t sure which way to go. There’s one attempt with OpenZWave and MQTT bridge, but without any documentation and it has only one commit 6 months ago. Since I had already set up Z-Way server, I decided to do some hacking with it.

By browsing Z-Way API documentation one can see that the embedded web server offers JSON API, which you can use to configure Z-Wave settings, read device data and also control devices. For example to turn on and off the wall switch (here Z-Wave device #20), these simple HTTP requests can be issued with a browser:

http://192.168.1.80:8083/ZWaveAPI/Run/devices[20].instances[0].Basic.Set(1)
http://192.168.1.80:8083/ZWaveAPI/Run/devices[20].instances[0].Basic.Set(0)

Here we use the Basic command class to control the device. It’s little bit tricky to find out the exact JSON tree to read and control each device, but you can try to mesh the information seen on the GUI of Z-Way server with the Z-Way API doc, or you could decipher the JSON tree itself. You can read all the available command classes with command

http://192.168.1.80:8083/ZWaveAPI/Run/devices[20].instances[0].commandClasses

In my case the Aeon Smart Switch supports following command classes:

  • Basic (32)
  • SwitchBinary (37)
  • SwitchAll (39)
  • SceneActivation (43)
  • SceneActuatorConf (44)
  • Meter (50)
  • CRC16 (86)
  • AssociationGroupInformation (89)
  • ZWavePlusInfo (94)
  • Configuration (112)
  • ManufacturerSpecific (114)
  • PowerLevel (115)
  • FirmwareUpdate (122)
  • Association (133)
  • Version (134)
  • Security (152)
  • DeviceResetLocally (90)
  • Hail (130)

Here the SwitchBinary and Meter classes seem most interesting. It seems that Basic class is just re-mapped internally by the switch to SwitchBinary, since all Z-Wave devices must understand Basic class to facilitate interoperability between dumb sensors and actuators. Also you can reference the class by the number instead of name. Hence, all these four commands work equally:

http://192.168.1.80:8083/ZWaveAPI/Run/devices[20].instances[0].Basic.Set(1)
http://192.168.1.80:8083/ZWaveAPI/Run/devices[20].instances[0].SwitchBinary.Set(1)
http://192.168.1.80:8083/ZWaveAPI/Run/devices[20].instances[0].commandClasses[32].Set(1)
http://192.168.1.80:8083/ZWaveAPI/Run/devices[20].instances[0].commandClasses[37].Set(1)

mqttwarn – a swiss knife of MQTT

Now, how to best translate MQTT messages into JSON HTTP POSTs? There’s mqttwarn, an excellent piece of python software (on Github here), that not only does this, but can also convert MQTT messages into notifications on your cell phone (using Pushover or Instapush), send e-mail, post on your Twitter account, send e-mail, transfer your sensor data over to your remote EmonCMS server and tons more!

To install and configure mqttwarn, just follow the instructions at the end of the (very long) GitHub project description. Then, edit the mqttwarn.ini:

First add the http service provider:

; name the service providers you will be using.
launch   = file, log, http

Then configure the provider. Here the HTTP URL is modified with the MQTT message payload in following way:

[config:http]
timeout = 60

targets = {
                #method     #URL               # query params or None          # list auth
  'dev20set'    : [ "post", "http://192.168.1.80:8083/ZWaveAPI/Run/devices[20].instances[0].Basic.Set({payload})", None, None ],
  'dev21set'    : [ "post", "http://192.168.1.80:8083/ZWaveAPI/Run/devices[21].instances[0].Basic.Set({payload})", None, None ]
  }

Finally we add a list of MQTT messages that trigger the launch of the HTTP provider:

[#]
targets = {
        'home/zwave/Device20/switch/set' : 'http:dev20set',
        'home/zwave/Device21/switch/set' : 'http:dev21set'
        }

After you start mqttwarn, you can test it by sending MQTT messages like this:

mosquitto_pub -t home/zwave/Device20/switch/set -m 1

If you successfully installed mqttwarn you should now have all the required python dependencies set up (such as Paho MQTT Python module). Note that I tested few other python bindings and I remember having first some trouble connecting to the Mosquitto server, but the culprit was an old version of Mosquitto. Since the version in Raspberry Pi repositories is ancient, you should download it straight from Mosquittos repository (instructions here).

Supervisor – the big brother of small scripts

You can add the mqttwarn into your server init scripts, but I prefer Supervisor to handle all these small scripts, since it allows the administrator to monitor their status, see their output log and stop/start/restart them, all combined in a very nice web server UI.

To install it on Raspberry Pi, first install setuptools

wget https://bootstrap.pypa.io/ez_setup.py -O - | sudo python

Then install supervisor via easy_install:

easy_install supervisor

Update the /etc/supervisord.conf and check the http port and add username:password if needed. Also double-check that separate script config files are included:

[include]
files = /etc/supervisord.d/*.ini

Create /etc/supervisord.d/mqttwarn.ini and check that the mqttwarn installation directory and config files are referred correctly:

[program:mqttwarn]
directory = /home/pi/services/mqttwarn
command = /home/pi/services/mqttwarn/mqttwarn.py
user = pi
environment= MQTTWARNINI="/home/pi/services/mqttwarn/mqttwarn.ini"
stdout_logfile = /tmp/mqttwarn.log

Finally restart the supervisord

/etc/init.d/supervisor restart

And browse to http://192.168.1.80:9001/ and you should see the nice web GUI.

supervisord

From Z-Way to MQTT

We have now just configured one-way communication from MQTT to Z-Wave server. To be able for us to receive messages from various Z-Way devices, we must hack the Z-Way server Javascript a bit and bind to the JSON tree changes. I found about this trick from this EventGhost forum discussion and modified the scripts posted there (originals by Walter Krambring)

Edit /etc/opt/z-way-server/automation/main.js (depending on your installation directory) and add this snippet to the end:

var mqtt_host = '192.168.1.80';
var mqtt_port = 1883;
var mqtt_topic_prefix = 'home/zwave/';

// Here the 20 and 21 are hardcoded Z-Wave device ID's for wall plugs/power switches. Change them accordingly to your setup
var powerswitches = [20, 21];

function publish_mqtt (topic, key) {
    try {
        system(
            "mosquitto_pub",
            "-h",
            mqtt_host,
            "-p",
            mqtt_port,
            "-t",
            mqtt_topic_prefix + topic,
            "-m",
            key
        );
        return;
    } catch(err) {
        debugPrint("Failed to execute script system call: " + err);
    }
}

function switch_binary (device, instance, theValue) {
    console.log("MQTT plugin: dev#" + device + " (binary switch): " + theValue)
    state = 'on';
    key = 255;
    if (theValue == false){
        state = 'off';
        key = 0;
    }
    eventString = 'Device' + device + "/switch";
    publish_mqtt(eventString, state);
}

function switch_binary_meter (device, instance, theValue) {
    console.log("MQTT plugin: dev#" + device + " (binary switch meter): " + theValue)
    eventString = 'Device' + device + "/meter";
    publish_mqtt(eventString, theValue);
}

for (var i=0; i < powerswitches.length; i++) {

        var id = powerswitches[i];
        (function(devid) {
                console.log("MQTT plugin: Configure power switch  " + devid);
                zway.devices[ powerswitches[i] ].instances[0].SwitchBinary.data.level.bind(function() {
                        switch_binary (id, 0, this.value);
                });
                zway.devices[ powerswitches[i] ].instances[0].Meter.data[2].val.bind(function() {
                    switch_binary_meter (id, 0, this.value);
                 });
        })(id); // tie device ID so it is referenced correctly from callback funcs

}

This code will bind to changes in the Watt meter and on/off status of my Aeon and Evergreen wall switches and send MQTT message using external python script every time the data changes. The syntax for binding uses exactly the same data format as the Z-Way server JSON API, so we can use again the web interface to find the sub-item to bind with. However finding the correct item will indeed be bit like searching for a needle in a haystack if we use only the JSON tree. Instead of sifting through the giant data tree, we can use the Expert UI to find out clues where the interesting data is. For example in the case of Aeon switch we are interested in the Meter service:
z-way
Here we can see the scaleString of entry #2 is 'W' so .data2 should contain the watt meter reading. We confirm this by plugging in a known load (here 14W) and viewing the JSON tree:

http://192.168.1.80:8083/ZWaveAPI/Run/devices[20].instances[0].Meter.data[2]
returns
{"invalidateTime":1436389382,"updateTime":1436389383,"type":"empty","value":null,
"sensorType":{"invalidateTime":1435686498,"updateTime":1435686499,"type":"int","value":1},
"sensorTypeString":{"invalidateTime":1435686498,"updateTime":1435686499,"type":"string","value":"Electric"},
"val":{"invalidateTime":1435686498,"updateTime":1436389383,"type":"float","value":14.384},
"scale":{"invalidateTime":1435686498,"updateTime":1435686499,"type":"int","value":2},
"scaleString":{"invalidateTime":1435686498,"updateTime":1435686499,"type":"string","value":"W"},
"ratetype":{"invalidateTime":1435686498,"updateTime":1436389383,"type":"int","value":1},
"delta":{"invalidateTime":1435686498,"updateTime":1436389383,"type":"int","value":0},
"previous":{"invalidateTime":1435686498,"updateTime":1436389383,"type":"float","value":0}}

The '14.384' stored in 'val' sub-item looks awfully lot like our load. Thus the correct binding function will be

zway.devices[20].instances[0].Meter.data[2].val.bind

as shown in the example code above.

We must also allow the Javascript to invoke mosquitto_pub by adding .syscommands file to the same directory where main.js resides:

mosquitto_pub 

Openhab binding

Finally you can replace the z-wave binding with MQTT ones in the .items file:

Switch Kitchen_Coffee_Switch "Coffee machine" {mqtt=">[mosquitto:home/zwave/Device21/switch/set:command:*:MAP(switchToMqtt.map)]"} 
Number Kitchen_Coffee_Watts "Coffee machine power consumption [%.1f W]" {mqtt="<[mosquitto:home/zwave/Device21/meter:state:default]"}

Switch Livingroom_Power1_Switch "Living room power #1" {mqtt=">[mosquitto:home/zwave/Device20/switch/set:command:*:MAP(switchToMqtt.map)]"} 
Number Livingroom_Power1_Watts "Living room power #1 consumption [%.1f W]" {mqtt="<[mosquitto:home/zwave/Device20/meter:state:default]"}

We must also map the ON/OFF states to 1/0's that are understood by JSON API. Create configurations/transform/SwitchToMqtt.map:

ON=1
OFF=0

... aaand we're done! That was easy, wasn't it? ūüėÄ

Enter Moteino

Having played few days with Arduino Mini and the NRF24L01+ transceiver I came into conclusion that I wanted something more compact with lower power consumption. After some hours of coffee-powered research two top contesters surfaced: Jeenode and Moteino. Also there’s an upcoming ultra-low power arduino clone ULPNode which uses few quite interesting power saving techniques, that makes it possible to reach nanoampere scale basal power consumption when in deep sleep. Unfortunately prototypes are not yet available for purchasing but I will for sure try those out in the future!

Also one thing to consider is that these levels of ultra-low consumption can be implemented on a real-life sensor only when the sensor part itself can be put to sleep (for example with periodical temperature measurements). Since most of my sensor devices in planning will use at least one active sensor (PIR motion sensor mainly), it is irrelevant whether the board uses few microamps vs few dozen nanoamps when the PIR sensor itself uses 50 microamps in standby-mode.

Both Moteino and Jeenode use the low quiescent current MCP1703 voltage regulator and don’t include any kind of LED to indicate power on status (unnecessary power hogs), so low current consumption and long battery life could be obtained even without modifying the hardware.

In the end, I voted for Moteino for following reasons:

  • Compact and quite nice looking
  • RFM69W wireless chip (vs older RFM12B in Jeenode with no HW level encryption)
  • active user base and forum
  • few euros cheaper than JeeNode (not really a deciding factor, but nice to know if you are planning to spread your house full of these sensors..)

Testing

Testing Moteino on breadboard with FT232 USB adapter

Testing Moteino on breadboard with FT232 USB adapter

Here’s Moteinos sleep mode consumption after some testing:

  • 23 microamps (16 Mhz, BOD off, 5.0V to Vin)
  • 1.3 milliamps (16 Mhz, BOD off, 3.3V bypassing MCP1703).
    Wow, The regulator sure doesn’t like to be left idle ūüôā
  • 22 microamps (16 Mhz, BOD off, 3.3V in, MCP1703 desoldered)
  • 20 microamps (8 Mhz, BOD off, 3.3V in, MCP1703 desoldered)

Note that also the RFM69 needs to be put to sleep (with the transmitter awake but idle I measured 1 milliamp higher values).

Whan transmitting packets the consumption jumps to few dozen milliamps, but this is inconsequential, since the transmitter and CPU will be in deep sleep 99% of the time, awakened only by interrupts from the sensor or hardware watchdog.

So, the setup and assumed current consumption is as follows (values for sensors are from datasheets, I didn’t test sensors separately):
* Moteino @ 16 Mhz: 23 uamps (I didn’t bother with 8 Mhz since at this stage the 2 microamp difference in consumption is negligible)
* 4xAA batteries (calculated later)
* DHT22 temperature and humidity sensor (40-50 uamps)
* PIR sensor (50 uamps)
* Voltage divider setup with a capacitor to measure 4-6V battery voltage (few microamps with 1 Mohm resistor)
* Motion detected LED (0 uamps off)

First prototype

I tossed the parts into left-over junction box. Better looking enclosure would have been nice, but unfortunately I don’t currently have tools nor working area in my current apartment to process suitable materials.

First prototype of bathroom motion sensor. This isn't going to win any beauty contests, but it works :)

First prototype of bathroom motion sensor. This isn’t going to win any beauty contests, but it works :)

Note that the 433 Mhz version of RFM69W seen here needs (or better said, is recommended to have) 17.2 cm antenna and is actually shipped with a 16,5 cm one since the PCB traces make up for the remainder. Now, in my tests I found out that I don’t need that long wire sticking out vertically, but can just route it inside around the edges of the enclosure. Even this gives it plenty of signal strength to transmit through 2 thick walls two rooms across. Good enough.

IMG_0053[1]

I measured the current consumption to be 104 microamps @ 5V, which is quite in the ballpark expected! With ideal situation (0% monthly battery discharge) this sensor would last for 4*2000 mAh / 0.104 = 76923 hours = 8.78 years ūüôā Of course now the self-discharge of NiMH batteries start to matter considerably: Cheap NiMH batteries have as high as 20-30% discharge rate, whereas better Sanyo Eneloops (3rd gen) are specified to hold 70% charge after 5 years! Now this would be an almost set-and-forget situation. Actually I just recently ordered a pack of Eneloops, so I think this is going to end up being a field-test lasting for few years ūüėÄ

Pairing with Openhab

Now, let’s concentrate on software a bit. Since MySensors supports only the NRF24L01+ and it’s libraries seem to be quite tightly coupled with it’s hardware functionality, I had to find a replacement. After some digging I came across this nicely done pack of libraries for MQTT Gateway and Sensor made by Computourist. With just a few tweaks I was able to fire up (not literally) the sensors and get them to communicate with Openhab. Unlike MySensors MQTT gateway, this one isn’t MQTT server but just normal client so no MQTT server bridging was necessary. Just configure the MQTT server IP address:port in the sketch and Moteino gateway connects automatically and will also keep on trying should it lose the connection to the MQTT server.

MQTT Gatewey will send and receive messages in a fixed notation such like these:

pi@raspberrypi:/opt/openhab# mosquitto_sub -v -t '#'
home/rfm_gw/nb/node02/dev02 -61
home/rfm_gw/nb/node02/dev04 5.2
home/rfm_gw/nb/node02/dev48 24.38

Here nb=northbound (messages from nodes/sensors to the server), sb=southbound (messages from server/openhab to nodes). Devices (items residing inside a node) will be defined per-node basis and could be anything from sensors, actuators to node setting containers. For example commands

pi@raspberrypi:/opt/openhab# mosquitto_pub -t home/rfm_gw/sb/node03/dev00 -m "READ"
pi@raspberrypi:/opt/openhab# mosquitto_pub -t home/rfm_gw/sb/node03/dev04 -m "READ"

could be used to read uptime and battery voltage of node #3.

pi@raspberrypi:/opt/openhab# mosquitto_pub -t home/rfm_gw/sb/node03/dev01 -m 60

Could be used to set periodic transmission interval to 60 seconds. Actual implementation depends on sensor, but these libraries give quite nice framework to work upon.

To accept messages from MQTT Gatewey we just define new items in the Openhab .items file to match the new sensors:

Contact Bathroom_Motion_Sensor {mqtt="<[mosquitto:home/rfm_gw/nb/node03/dev40:state:MAP(switchFromMqtt.map)]"}
Number Bathroom_Temperature  "Bathroom temperature [%.1f C]"   <temperature> {mqtt="<[mosquitto:home/rfm_gw/nb/node03/dev48:state:default]"}
Number Bathroom_Humidity  "Bathroom humidity [%.1f %%]" {mqtt="<[mosquitto:home/rfm_gw/nb/node03/dev49:state:default]"}
Number Bathroom_Sensor_Voltage  "Bathroom sensor voltage [%.1f V]"  {mqtt="<[mosquitto:home/rfm_gw/nb/node03/dev04:state:default]"}

We also need to map the state of the motion sensor (ON/OFF) to a state shat the "Contact" item understands (CLOSED/OPEN). That is done in switchFromMqtt.map (referenced above with MAP(switchFromMqtt.map):

ON=CLOSED
OFF=OPEN

PIR sensor and light rules

Then some timer magic is created to turn on the bathroom light when motion is detected:

import org.openhab.core.library.types.*
import org.openhab.core.library.items.*
import org.openhab.core.persistence.*
import org.openhab.model.script.actions.*

var Timer BathRoomTimer = null
var Integer timeOut = 120

rule "Bathroom Motion Sensor Trip"
        when
        Item Bathroom_Motion_Sensor received update
        then
        {
        logInfo("Bathroom motion Sensor", "sensor changed state")
        if (BathRoomTimer == null ) 
            logDebug("Bathroom Motion Sensor","timer==null")
        else                        
            logDebug("Bathroom Motion Sensor","timer!=null")
        if(Bathroom_Motion_Sensor.state == CLOSED)
            {
            if (BathRoomTimer == null ) 
                {                       
                // create timer
                logInfo("Bathroom Motion Sensor", "creating timer: " + timeOut + " sec")
                BathRoomTimer = createTimer( now.plusSeconds(timeOut) )
                    [ 
                        logInfo("Bathroom Motion Sensor", "timer expired, switching off ")
                        sendCommand(Bathroom_Light_Toggle,OFF)      
                        BathRoomTimer=null
                    ]               
                sendCommand(Bathroom_Light_Toggle, ON)
                sendCommand(Bathroom_Light_CT_Dimm, Light_Temperature.state as DecimalType)
                } 
            else
                {
                logInfo("Bathroom Motion Sensor", " rescheduling timer:" + timeOut + " sec" )
                BathRoomTimer.reschedule(now.plusSeconds(timeOut))
                }
            }
        }
    end

Everything seemed to work just fine, but when I took a shower in the morning, PIR sensor couldn't obviously detect any movement behind shower curtain and eventually the light was turned off again, me still in the shower ūüôā Hmm.. Either I could extend that delay period to few minutes (lazy option), OR I could use humidity sensor to detect rise in humidity above a certain threshold (when shower is being used) and extend the delay only then. I chose the latter, more elegant option:

var Integer timeOutWithShower = 300

rule "Bathroom Motion Sensor Humidity"
    when
        Item Bathroom_Humidity received update
    then
    {
        logInfo("Bathroom Humidity Sensor", "bathroom humidity changed")
        if( ( BathRoomTimer != null) && (Bathroom_Humidity.state > 60) )
        {
            logInfo("Bathroom Humidity Sensor", " shower on - rescheduling timer for bathroom in " + timeOutWithShower + "sec" )
            BathRoomTimer.reschedule(now.plusSeconds(timeOutWithShower))
        }
    }
    end             

This required also changes sensor-side, since in normal mode humidity would be measured only every few minutes. I implemented a "perceptive mode" to start measuring temperature and humidity every few seconds after motion is detected. Mode is then switched back to normal after 1 minute. This gives enough time for humidity sensors to react (in fact humidity goes over 50-60% in just 20 seconds after shower is turned on.)

Next coming: Dash of Z-Wave sorcery!

Let there be (dim) light!

There’s no fun in having sensors without being able to manipulate surrounding environment using their input. Like I explained in first post, my main motivation setting up home automation was to control lighting, preferably without minimal human intervention. Main illumination rules should be as follows:

    • Motion sensors should turn on lights automatically after person has entered a room. Lights should also be turned off after no presence has been detected after a while (5-10 minutes perhaps)
    • When on, lights should adjust to local time by dimming and if possible, changing color temperature. From early morning to 6 pm lights should be set to bright and neutral temperature (6000-7000 K), then declining towards the evening (around 2500-3000 K) and finally drop to 2000 K 1-2 hours before bedtime
    • If alarm is set to go off on mornings, bedroom lighting should be turned on automatically 30 minutes before, starting from very dim and slowly reaching full brightness wee bit before it’s time to get up.

Options, options…

I considered wireless dimmer modules (either off-the-shelf or even DIY Arduino hacks), but quickly scrapped the idea, since color temperature could not be then adjusted. Belkin has a family of WeMo¬ģ home automation appliances (using 2.4 GHzZigbee as wireless protocol), including their Smart LED Bulbs. Unfortunately their color temperature is fixed. There are however 3rd party bulbs available from OSRAM that are combatible with Wemo and have tunable color temperature. Osram manufactures also their own Zigbee compatible Lightway gateway. And finally there’s Philips Hue family of lights, that are both color temperature and color adjustable. Hue is also using Zigbee protocol and is the oldest of these three, having been around almost 2 years now already.

Since all three use Zigbee to communicate between hubs and light bulbs, I would assume there’s some interoperability between these products. It seems at least Osram Lightify bulbs can be paired with Philips Hue hub, but I didn’t found anyone mentioning compatibility between Belkin and Hue bulbs. However in the end it is the hub that the rest of the home automation framework is communicating with and not directly with the bulbs, so procurement was done mainly by comparing the existing support for the hubs in Openhab and other home automation systems. In the end I chose Philips Hue since Openhab supports it directly, its protocol is documented and there’s plethora of language bindings available.

philips-hue-blubs-and-station
There were also many success stories around using Philips Hue with DIY installations that encouraged me to shell out the 200 euros for the starter pack with the hub and 3 bulbs. I know, it’s a rip-off but then again, I have so many times found out that cheaping out on these things often cause major headaches later.

Philips Hue

philips hue app
There are many features on their mobile application (available for iOS and Android. Unofficial app also for Windows phones available). Not only can you control manually the lights with the application, but you can also set dimming functions based on timers and alarms which are saved into the hub, so the application doesn’t need to be left on. Then there are other lots of 3rd party apps available (Disco lights etc.) but those just feel utterly gimmicky. And besides, after one has been playing with a new toy such as this for awhile and the initial charm has worn off, who really wants to control his/her lights from a mobile phone?? Anyway, I won’t go into too much details with the features of Philips Hue itself since there are already many nicely done reviews around, such as this by Lester Chan.

Now, coming back to the initial objectives, using the timer feature I could fulfill some of the requirements above, but I still wanted to gather all the automation rules into one single hub (Openhab) to avoid conflicts later. In the end, Philips hub was converted into a dumb router. One last thing I did with the Hue application was to check the IP address of the hub after which I went on to configure Openhab.

Philips Hue hub, emitting exactly the light that would keep me awake at night should I spent too much time glancing it. Fortunately it can be put somewhere out of sight.

Philips Hue hub, emitting exactly the light that would keep me awake at night should I spent too much time glancing it. Fortunately it can be tossed somewhere out of sight.

Openhab coupling

Pairing Philips Hue hub with Openhab was quite straightforward (detailed instructions can be found here), but setting the lightning rules were little bit trickier. I’m not really a big fan of the XTend language that Openhab uses for its scripting, but that’s a topic for another post..

First one needs to define the light bulb items (e.g. in default.items)

// Simple ON/OFF toggles
Switch Kitchen_Light_Toggle    "left bulb"   (Switching) {hue="1"}
Switch Bathroom_Light_Toggle   "center bulb" (Switching) {hue="2"}
Switch Bedroom_Light_Toggle    "right bulb"  (Switching) {hue="3"}

// For setting color values
Color Kitchen_Light_Color    "left bulb"   (Colorize)  {hue="1"}
Color Bathroom_Light_Color    "center bulb" (Colorize)  {hue="2"}
Color Bedroom_Light_Color     "right bulb"  (Colorize)  {hue="3"}

// For setting dimmer values
Dimmer Kitchen_Light_Dimm     "left bulb"   (WhiteDimmer)   {hue="1;brightness;30"}
Dimmer Bathroom_Light_Dimm    "center bulb" (WhiteDimmer)   {hue="2;brightness;30"}
Dimmer Bedroom_Light_Dimm     "right bulb"  (WhiteDimmer)   {hue="3;brightness;30"}

// For setting color temperature values. Note that these accept values (0-100), where 0 is the coldest and 100 is warmest temperature
Dimmer Kitchen_Light_CT_Dimm      "left bulb"   (CTDimmer)  {hue="1;colorTemperature;30"}
Dimmer Bathroom_Light_CT_Dimm     "center bulb" (CTDimmer)  {hue="2;colorTemperature;30"}
Dimmer Bedroom_Light_CT_Dimm      "right bulb"  (CTDimmer)  {hue="3;colorTemperature;30"}

Lighting rules

Then we define a global color temperature setting (also in default.items) as well as target temperature for slow transition:

Number Color_Temperature "Light temperature [%.0f]"
Number Target_Color_Temperature

Next we define a function (I use light.rules files for this and the following rules) that gets called every time a light temperature is updated. It then controls each light bulb accordingly. Note that if a light is turned off, this setting is not propagated to the bulb itself so we must explicitly set the temperature each time when a light is turned on.

rule "Update color temperatures"
when 
    Item Color_Temperature received update  
then
    logInfo("Sensors","new color temperature: " + Color_Temperature.state)
    var Integer temp = Color_Temperature.state
    sendCommand(Kitchen_Light_CT_Dimm, temp)
    sendCommand(Bathroom_Light_CT_Dimm, temp)
    sendCommand(Bedroom_Light_CT_Dimm, temp) 
end

I also tried to address each dimmer in a group (set earlier in the items definition) like this…

//  CTDimmer?.members.forEach[dimmer|
//      Dimmer d = dimmer   // <-- Fails right here..
//      sendCommand(dimmer, Color_Temperature.state )
//      ]

... but it seems that Openhab doesn't store group items as real objects but as some kind of bastard string representation instead.. So, each light has to be addressed individually, which makes maintaining code cumbersome especially when one has many devices of same type in the setup.

Another annoyance has been with default item values. I haven't found a way to initialize values in items file, and when I modify the file and it gets reloaded, values are reset and left uninitialized. This can break many functions and adds overhead since there has to be more checkpoints all over the code to make sure no uninitialized value is addressed. I even wrote another rule to try to circumvent this:

rule "Startup"
    when 
        System started
    then
    if ( (Color_Temperature.state == Undefined) || (Color_Temperature.state == Uninitialized) )
    {
        postUpdate(Color_Temperature, 50)  // default value
    }
    end

, but this is called only during startup or when the rules file is reloaded, but NOT when items file is touched. This can be circumvented by saving first the .items file and then the .rules file. It is of course not a problem when running a stable system but when testing and building your rules, this can become quite a pain in the ass.

To implement a transition from current light temperature to target temperature slowly in 10 minutes, we implement a rule such as this:

rule "Temperature transition"
when
    Item Target_Color_Temperature received update
then
    var Number steps = 0
    logInfo("temp transition","temp:" + Color_Temperature.state + " -> " + Target_Color_Temperature.state )
    var Number delta = (Target_Color_Temperature.state as DecimalType).floatValue - (Color_Temperature.state as DecimalType).floatValue
    delta = delta / 60
    logInfo("temp transition","delta:" + delta)
    while(steps < 60) { 
            postUpdate(Color_Temperature, (Color_Temperature.state as DecimalType).floatValue + delta )
        steps = steps + 1 
            Thread::sleep(10000)
     }
end

Finally, we can add rules to start the transition at certain times (in this example at 8 pm and 7 am)

rule "Dusk"  
when
    Time cron "0 00 20 ? * MON-SUN "
then
    logInfo("Light rules","It's getting darker...")
    postUpdate(Target_Color_Temperature, 100)
end

rule "Dawn"
when 
    Time cron "0 00 07 ? * MON-SUN "  
then
    logInfo("Light rules","It's getting brighter...")
    postUpdate(Target_Color_Temperature, 10) 
end

Evolution of Architecture (Part 1)

My first contact with home automation came via¬†MySensors, an project that combines Arduino with various sensors and NRF24L01+ wireless 2.4Ghz module. Lots of example code for both sensors and transmitter relays can be found on their site and thus deploying working prototype was quite straightforward. In just few hours of work I was able to construct simple wireless temperature sensor and it’s counterpart, a relay hub that receives temperature information wirelessly. I first used Dallas DS18B20 temperature sensor, but then decided to swap it to DHT22 that¬†also gathers humidity values.

MySensors architecture supports plethora of home automation hubs¬†where you can program the actual rules and behaviour of the system. Hub gathers data from sensors, can react to certain values and conditions and then manipulate lights, switches and other devices in the network. Also data storing and charting is possible. I decided to try out Openhab, a quite mature software package that supports various devices and protocols and seems to be quite popular in the DIY home automation scene. It’s written in Java and thus speed isn’t its best feature, but many people are running it in RaspBerry Pi so I figured¬†it can’t be that slow. In fact running it wasn’t that bad and response times to stimuli were so-so but starting and re-starting the server took several minutes. So trying different settings by modifying openhab.cfg made me pull not-insignificant amount of hair out of my head. I will blame Openhab for my baldness later. Luckily Raspberry Pi 2 was released just few months ago and with its faster processor running Openhab turned out to be much nicer for my scalp.

MQTT magic

After some research I decided to pursue the first prototype:

Home automation architecture #1

Home automation architecture #1

MySensors supports most hubs via MQTT¬†and the same goes for Openhab. There are lots of great tutorials around so I won’t go into details, but let’s just say that if there’s one protocol to consider, it’s MQTT. It’s a lightweight messaging protocol that follows publish-subscribe principle and allows devices on different platforms to talk to each other. Sensors can publish sensor data to MQTT message bus and automation hubs can subscribe to those messages. For example sensor might publish it’s temperature with following message:

topic: "/home/sensors/node02/temperature" msg:"23.50"

It’s also possible to control the devices (switching relays or turning on/off the lights) by sending MQTT messages as long as the device can talk MQTT (or there’s a translating gateway¬†sitting between the MQTT bus and the target device). It’s nice to also configure sensors via MQTT:¬†For example if you want to change the sensor update interval, you can just send a message to MQTT bus instead of going through the hassle of deploying a separate configuration tool that talks to the device, or even re-flashing the firmware via direct physical connection (there are wireless flashing solutions but that’s a subject of different post).¬†In a nut-shell, MQTT is the glue that in optimal situation allows us to avoid¬†tinkering with cumbersome ad-hoc DIY protocols as well as¬†to¬†prevent reliance on monolithic systems¬†in which direct support for each device platform and protocol is required.

Do electromagnetic waves talk MQTT?

Now, how to get the sensors talking to Openhab via MQTT? Actually it’s best to not transmit MQTT messages wirelessly, but instead use some even simpler, fixed message structure from sensors to Sensor Relay, which then converts these messages to actual MQTT messages to be sent to MQTT server. This requires little bit more coding on the Sensor Gateway¬†side, but then makes it possible to off-load all the MQTT message parsing and publish/subscribe logic from sensors to the relay. MQTT is simple but not THAT simple, and these low-power and low-memory¬†sensors are best to be kept as simple as possible for obvious reasons.¬†MySensors has a published a simple¬†Arduino MQTT Gateway Broker sketch that can work almost straight out-of-the box with minimal code changes. It is actually a small MQTT server itself, but is not as robust as I would’ve liked, so I decided to install¬†Mosquitto MQTT server¬†on Raspberry Pi that works as a main MQTT hub. Mosquitto was then configured¬†to work as a bridge¬†with Arduino Gateway, i.e. it connects¬†to the Arduino gateway as any normal client, subscribes to all relevant topics (sent by sensors) and publishes then all the messages coming from other devices. Bridging can be done by modifying /etc/mosquitto.conf and adding following snippet:

connection mysensors_mqtt
address 192.168.1.82
topic # both MySensors/ /

This subscribes to all topics (#) and replaces ‘/’ with ‘MySensors/’ in topics coming from Arduino Sensor Gateway and vice-versa. This topic translation makes it easier to distinguish MySensors MQTT messages from other MQTT traffic.

Adding the sensors to Openhab is then pretty straightforward: First install and configure mqtt add-on, then add each sensor sub-device as a MQTT source by editing /opt/openhab/configuration/items/default.items like this:

Contact Bathroom_Motion_Sensor {mqtt="<[mosquitto:MySensors/20/0/V_TRIPPED:state:default]"}
Number Bathroom_Temperature "Bathroom temperature [%.1f C]" {mqtt="<[mosquitto:MySensors/20/1/V_TEMP:state:default]"}
Number Bathroom_Humidity "Bathroom humidity [%.1f %%]" {mqtt="<[mosquitto:MySensors/20/2/V_HUM:state:default]"}

Of course these are just examples, and you have the  modify the MQTT topics above to match those that your sensors are sending.  Sniffing the MQTT traffic is easy with mosquitto_pub:

pi@raspberrypi /home/pi $ mosquitto_sub -v -t MySensors/#

For some reason “-t #” is not accepted, but “-t /#” is, but the latter does match only messages beginning with ‘/’, so if you want to subscribe to absolutely all messages, the ‘#’ must be closed inside quotation marks:

pi@raspberrypi /home/pi $ mosquitto_sub -v -t "#"

Next topic: Actually doing something practical with the sensors. Stay tuned!