Some time last year, one of the guys at work and I came across a KickStarter project called NinjaBlocks^[1] (I’m lazy so I’ll refer to this unit as NB). The options were limitless… or at least varied enough to make it interesting. Both of us put in an order and a month or so later we had some new goodies to play with.

One of the greatest draw-cards for me was that it could control other devices that use 433MHz, which while it may not sound impressive, included some readily available “remote-control” power sockets. These sockets came with a remote control with a series of 4 on/off buttons – basically you plugged these into your wall socket, then something into them and you could use the remote to flick the switch on and off without going near it. This instantly appealed to me, and my plan was to put the lights of my 2 aquariums onto them, and use the NB rule capability to simply turn the lights on and off on a schedule!

This was a very meagre requirement and setup without any significant problems. But over time a few issues cropped up. The main one being that the NB device interacted with some cloud hosted brains to provide the management interface, and obviously some of the actuators as when the internet connection was down, it wouldn’t trigger anything. It also had an issue that (at least using its wireless connection which was necessary to get it close enough to the devices that needed to be controlled) if the connection dropped to the NB for any reason, it seemed to need to be rebooted to get it to reconnect.

The other real issue is no fault of NB but more a function of the communication style of 433MHz devices – sometimes the NB would tell the socket to turn on or off, but the socket for whatever reason wouldn’t get the hint. The NB had no idea if its command was followed or not; it was a fire-and-forget sort of communication.

Those issues aside, it ticked along for a fair while being my overpriced power timer (I should mention that before the NB I had 2 analogue power timers that did the job fine, they were just a little noisy and if the power was out for a period I had to manually readjust them so their view on time wasn’t offset). It was a geeky, lazy solution and conceptually I loved it.

Then it died.

A couple of months or so ago, the NB stopped doing anything. It wouldn’t even acquire an IP address from the network. And at the time I didn’t have the correct adapter to get a monitor on it to confirm my suspicion that it was just bricked. But I ignored it for a while and just started using the original remote for the sockets, which worked fine but meant that the on and off time for the lights was a little less scheduled, and if I went away, they got no lights (not a huge issue but I liked the idea of a stable rhythm for them!).

At some point along the timeline, I’d played a little attention to some other things in the wild around home automation, initially with the thought I could find something that wasn’t so reliant on internet connection to actually be able to control the thing right next to it.

In this process I got and played with a RaspberryPi (actually the Pi was inspired as an alternative to a computer to display an web based dashboard on a big screen TV for work) and liked it but found it had some limitations in its processing ability (it got bogged down easily). This led me to the BeagleBone Black (BB) – same concept but with a little more grunt, and coincidentally the board that the NB was built on top of. So I got a BB and it sat doing very little for a few weeks until I came across OpenHAB!

The remainder of this post will be about my journey with the BB and OpenHAB, where I am today with it and some of the fun I had along the way that might even help someone else!

I should mention that I’m terrible when it comes to research on these things too. A number of articles I found online that helped me with bits, probably held the answers to the questions I came up with along the way, but due to a terrible habit of skim reading along with a tendency to quickly locate just the bit I need at a point in time then lose track of the rest of the content by the time I hit my next hurdle, a review of some of them leads me to realise there were a bunch of hints that I’d just overlooked. Actually, a bunch of the things that I had read that just really made no sense to me at the time (mainly thanks to some specific terminology) now make perfect sense and show themselves to be answers – I was just to dumb to see it and ended up with a lot of trial and error to realise what they were actually saying.

Right, so OpenHAB is an open source home automation system basically. It’s software that can run on probably endless devices (Java based) and has the ability to interact with a whole raft of devices.

Today, I have it talking to my Philips Hue bulbs, as well as 2 Z-Wave power socket controllers, and a Fibaro motion sensor (which actually does motion, temperature, light metering and an accelerometer). All these along with the control stick required for the Z-Wave were sourced from Smart Things NZ, a Christchurch based supplier of lots of cool home automation stuff run by an extremely helpful guy called Ben Jones.

Some credit to Ben here. After a very disjointed email to him late one night, a conversation started and I found Ben to not just be a sales guy, but a real enthusiast, strong member of the home automation / OpenHAB community who was great with suggestions and eager to help. In fact I was led to his site by links to him from other people whom he’d helped in the past. He even happens to have written some of the bindings for OpenHAB that I was planning to use so overall helped me validate that the concept in my mind actually had some realism in its ability to happen in real life too.

Initially I set up my BB using the default operating system, and got OpenHAB running on it. I set it up with my Hue bulbs and had a play. Great, that’s fun, but I didn’t get much past that. When I tried to install a program called mosquitto to act as an MQTT server (for an iPhone app OwnTracks), I spent hours bashing my head against a brick wall. It was around this time that I started talking to Ben and he mentioned he used MQTT a lot in his setup, and he was running on Ubuntu. I’m pretty used to Debian and not to bad with the quite similar Ubuntu, and the BB can support either of these distros so I went with Ubuntu and flashed my BB, starting from scratch.

With that done, mosquitto was a 30 second apt-get install away and I had OpenTracks talking to it minutes after that.

Then my Z-Wave toys arrived. I concentrated on the power sockets first as getting the timed light control on my fish tanks was the main thing I knew I wanted to achieve. I had to reinstall OpenHAB, which went fine, then plugged in the Z-Stick, put the Z-Wave addons in the right directory and fired up OpenHAB.

Joining the sockets (the actual term for this is ‘including’, but I tend to call it pairing but it’s all the same thing) was as easy as a press on the Z-Stick (although I found that this does need to be done with the Z-Stick unplugged from the USB. Putting it into learn mode while plugged in was technically doable but disconnected it from the BB requiring a reboot). The doco for the Z-Stick actually gives a description of taking the Z-Stick to where you want the new device to be and pair it in there which made more sense to me after I’d got everything setup overall. The manuals with both the Z-Stick and the sockets had some good information even if some of it meant nothing to me at the time, but it was certainly enough to get started.

Anyway, I ramble…

Next, I added these devices into OpenHAB as items. This is pretty much where you define all the things you interact with; all your endpoints of sorts. Getting the Hue bulbs going in the first round had dragged me through the doco for these – the OpenHAB site has some good info on the basics and the doco for most bindings gives good detail and examples.

Problem… How the hell do I define the sockets as items? The Z-Wave binding (actually I think that might be another one of Ben’s) had great doco, so after reading that and another article^[2] (actually where I first found mention of Ben) I ended up stealing some code from Jan-Piet Mens’ article and turned it into this:

Switch Z_Socket1
   "Big Tank"
   (Lights)
   {zwave="3:1:command=SWITCH_BINARY"}

Switch Z_Socket2
   "Small Tank"
   (Lights)
   {zwave="4:1:command=SWITCH_BINARY"}

At this point, I was really just guessing which device was which (the 3 and 4 in those Z-Wave lines identifies which device it is), but during the OpenHAB bootup, I noticed it said there were 4 Z-Wave devices (I’d actually already paired the motion sensor at this point but I’ll detail that later) so I did some trial and error. For the trial and error bit, I had to get them on the sitemap so that I could actually do something with them. My initial sitemap was something like…

sitemap morse label="Main Menu" {
   Frame label="Fish tank lights" {
      Switch item=Z_Socket1 label="Big tank (900L)" icon="switch"
      Switch item=Z_Socket2 label="Small tank (215L)" icon="switch"
   }
}

W00t! It works. I can reliably switch them on and off, and if I do it using the button locally on the actual socket, when I reload the phone app, it shows the correctly updated state. The last bit to get these doing what I wanted was actually done after a munch of frigging around with the motion sensor (I’d thought, that was easy, I’ll just do the same for this and then it’s all in! – boy was I wrong). Here my first “rule” was born. The first one was simply, turn the two sockets (and hence the fish tank lights) on at 7am each day. Not too complex, no multiple criteria or anything like that. A little code acquisition from other examples ended up as:

rule "Switch fishtank lights on at 7am"
when
   Time cron "0 0 7 * * ?"
then
   sendCommand(Z_LightsTank1, ON)
   sendCommand(Z_LightsTank2, ON)
end

And what do you know? 7am the next morning, the lights came on. Easy as!! The lights off rule looks almost identical:

rule "Switch fishtank lights off at 8pm"
when
   Time cron "0 0 20 * * ?"
then
   sendCommand(Z_Socket1, OFF)
   sendCommand(Z_Socket2, OFF)
end

I’m still not 100% sure I’ve got the metering working for the feedback from the switches, but an example of my item for one for now is:

Number Z_Socket1_Power
   "Big Tank Lights [%.1f kWh]"
   (zPower)
   { zwave="3:1:command=METER,meter_scale=E_KWh,refresh_interval=600" }

Nothing to it! Then it was time to come back to the motion sensor. After a couple of evenings of frustration and large quantities of googling (I was determined to work it out without actually having to ask someone like Ben – I’m stubborn like that!) I worked out a couple of key things (these realisations came from reading a number of articles and forums, I’ll put a list of links that I found helpful at the end of the article as all of them added random bits to various pieces of the puzzle)

• Getting the motion sensor “included” is easy. But it’d different in that what it does automatically isn’t enough to get the information flowing back. I’ll give some more detail on that shortly.
• HABMin is a great addon to OpenHAB, and one I ended up using. But on the BB, it KILLS CPU, makes everything lag, causes messages to drop (which I was watching in the log) and actually made me think that the BB wasn’t going to be grunty enough! In the end, when I wasn’t accessing HABMin, CPU usage died down and everything was happy, so if you’re using a BB or other limited resource computer, try not to use HABMin when you don’t have to (Actually having it open in a webpage is all it takes! Having it installed is fine, just don’t open the page too often)
• Battery powered devices work a little differently – you need to be patient.

Patience was not my strong point. I ended up on the right track but got there too early first time around. Battery powered devices spend a bunch of their time sleeping. When they wake up (the motion sensor default was 7200 seconds), the check the queue for messages and then go back to sleep; a little like me on a Sunday. The outcome of this is that it wasn’t until I’d left it overnight that (as far as I can tell) it properly finished the inclusion and I could actually find the bits I thought I was looking for (the next paragraph) so if you’re having trouble, sleep on it! You can hurry it up a bit by “waking up” the device but I obviously hadn’t done that enough so I still suggest the overnight to sort things out. =P

As well as inclusion, the motion sensor requires you to manually sort out some association. Now that’s the term I didn’t understand totally at first when I read it which meant I skipped over that stuff and kept looking – right past the answer! So yes, you need to change the association, basically telling the motion sensor to send info back to the Z-Stick. To do this, you can use a number of apps (apparently) but I used HABMin for it. So, loading up HABMin, I… Chose Configuration along the top -> Chose Bindings down the bottom left side -> Click on the Z-Wave one -> Chose Devices from the stuff that loads up. This gives you (hopefully) a list of all the Z-Wave nodes you have (this would have saved me guessing about the switches) – 3 had a green light, but the motion sensor had a grey light. Expanding the one for the motion sensor, you will find something about Association Groups, and under that you’ll find Controller Updates. Now here’s another bit that after all the reading I was still confused about – some say you have to change all the things you see under Association, others say all under controller updates, and finally I found someone who mentioned the controller – of course, the one you need to update is whatever node your controller (the Z-Stick) is (probably node 1). So, change Node 1 from Non-Member to Member. Make sure it’s taken (I reloaded HABMin to double-check) and then close HABMin go sleep on it again. HABMin has no part in it after this and I suspect the load it was putting on things actually slowed the process down just because I had the page open.

The next day, I opened HABMin again and found a green light where the gray one had been. I think that rated as success. So, closing HABMin again, I mashed together some of the examples I’d found and ended up with this (note, due to me redoing the inclusion a couple of times, instead of its original Node 2, the motion sensor is Node 6):

Number FibEye1_Motion
   "Lounge Movement: [MAP(movement.map):%s]" (Fibaro,Motion)
   { zwave="6:1:command=sensor_binary,refresh_interval=600" }

Number FibEye1_Alarm
   "Lounge Alarm: [MAP(earthquake.map):%s]" (Fibaro,Alarm)
   { zwave="6:1:command=sensor_alarm,refresh_interval=600" }

Number FibEye1_Lux
   "Lounge Light: [%.2f Lux]" (Fibaro,Lux)
   { zwave="6:1:command=sensor_multilevel,sensor_type=3,refresh_interval=600" }

Number FibEye1_Battery
   "Fibaro Motion Sensor 1: [%d %%]" (Fibaro,Battery)
   { zwave="6:1:command=battery,refresh_interval=86400" }

Number FibEye1_Temp
   "Lounge Temp: [%.1f C]" (Fibaro,Temp)
   { zwave="6:1:command=sensor_multilevel,sensor_type=1,refresh_interval=600" }

The labels are a bit screwy but I’m actually moving away from defining labels in most of my items, and doing it in the sitemap instead. Speaking of sitemap, a snippet that shows some of that in action there is:

Frame label="Stats" {
   Text item=FibEye1_Battery icon=energy
   Text item=FibEye1_Temp icon=temperature
   Text item=FibEye1_Lux icon=sun
}

It took a while again for info to start coming through. The first time around, I hadn’t put a refresh_interval on the items… That wasn’t helpful, but equally setting too short a refresh time had a notable impact on CPU load, so in the end I settled for 600 seconds (5 minutes) and found that a good balance.

It was a long journey but the things I’ve learnt just from dealing with the motion sensor have given me a much better understanding of Z-Wave and I think will make it easier when (yes when, not if) I get some more devices to add in!

So with all those sensors in the mix, I now have 2 fish tanks with lights going automatically, a sensor that logs (I setup mongodb for persistence) and an interface on my phone where I can see/manipulate all the bits. I’ve added in the OwnTracks stuff but not had much luck yet – I haven’t spent much time to sort it all out but the main issue is updates often not getting back from phone to MQTT which is more a network issue than anything I think. I’ve also setup Network Health and used it for presence (can it see my phone’s wifi IP on the LAN) and monitoring my internet connection is up in general. And Charts have been fun too – I have charts for the power usage from the sockets, and for the light levels and temp from the motion sensor for example. I haven’t yet done anything based on the motion sensor itself but there are plenty of ideas in my head. Next “smart” rule is probably going to be around the Hue bulbs and the light level in the lounge at the time, but I’m still sorting out some niggles with the Hue binding overall. No doubt I’ll post some on that when I’m happy with it.

Expect that I’ll go over this article a few times and re-word, improve some references or just generally tweak bits. Some more images when I have the time perhaps. But this is a start to get it out there at least!

That list of links that I found helpful in one way or another (in no particular order)
https://github.com/openhab/openhab/wiki/Z-Wave-Binding
https://github.com/openhab/openhab/wiki/MQTT-Binding#transport-configuration
https://github.com/openhab/openhab/wiki/Mqttitude-Binding
http://jpmens.net/2014/01/14/a-story-of-home-automation/
http://forum.mysensors.org/topic/302/openhab-mqtt-tips-hints
http://blog.scurb.se/homeautomation/home-automation-an-early-case-study/
https://groups.google.com/forum/#!topic/openhab/8uMM-xT_WoE
https://groups.google.com/forum/#!msg/openhab/bb9bB71zgsM/J2bNY6dnZvsJ
https://groups.google.com/forum/#!topic/openhab/bb9bB71zgsM

Aaand a random selection of screenshots from the OpenHAB app on my phone at the moment…

[1] These were the older style NinjaBlocks; since then they have come up with NinjaSphere that I haven’t looked into much so anything comments I make may no longer be current.
[2] http://jpmens.net/2014/01/14/a-story-of-home-automation/