Archive for September, 2015

Presence Detection

Posted: September 21, 2015 in HA, Hacking and playing, House
Tags: , ,

The ‘ol bug bear – how do I see if anyone is home?

I’ve tried OwnTracks, but the app on Android isn’t the most accurate and reliable (although it is being updated). I’ve tried the network health monitoring binding in OpenHAB and asked it to detect the phone when it connects to the home network (spot the flaw #1). I’ve tried using a BlueTooth (BT) dongle in the OH controller and running regular scans for my phone.

But none of them work 100%. OwnTracks just lets me down (waypoints especially). I leave my Wi-Fi off most of the time to save battery (and network health doesn’t seem to detect it when it is on). BT does work, as long as i am in range. But the minute I go upstairs the phone is out of range and the system thinks I’ve left the house. The other gotcha is that my wife doesn’t turn BT on, so that’s a pain as well.

When I’d spoken to SmartThings (some CES trip before Samsung got involved!) we had discussed the presence tag that their system supported. Fast-forward to the UK release of the new Samsung version and the presence tags suddenly are actually available in the UK. Yay!

Boo! They are ZigBee. So absolutely bugger all use to me. I’m not plugging in the Almond+ or building some new Xbee device just to solve this issue.

I need a device that is small enough to be with me all the time, not be intrusive and allows for reliable long term use before requiring battery changing. Oh and the batteries need to be cheap. I’m not spending more on a replacement battery than the actual device cost me. The other driver is that I’ve managed to get some more scripts written that control our heating system. So if I can prove that no one is home, I can automatically turn the heating off!

BlueTooth Low Energy

A long time ago (~2012) I’d done some experiments on presence detection for work. My concept was to use BT, BTLE, Wi-Fi etc etc to try and establish who was in a room during set-top box use. While this wouldn’t give a one-to-one correlation between who actually watched something and who was there, it would narrow the field considerably. If device X was always present when cooking shows were watched, we could start to recommend cooking shows when device X was in the room. The more devices we detected  and more watching data we got, the better the correlation would become.

Anyway, the idea was greeted with enthusiasm and then totally mis-understood and ended up being something to do with localised advertising in bus stops…. No I don’t know how it got to that either!

The point of this is that when I was looking at this, BTLE beacons were just starting to actually be available. Devices like the Fitbit bands used BTLE to communicate with the phone.  What was the state of cheap BTLE devices today?

The Concept

After thinking about it, the only thing that I always have on me when I leave the house is my door keys. When I come in, the door keys get put in the front door lock and that’s where they live. Can I find a device that I can detect in this position in the house reliably? That is also small enough to fit on my keyring? And is tough enough to survive being thrown around as part of the normal lifecycle of a bunch of keys!

Google and Amazon searches revealed several companies selling iBeacons in various size and power formats. After a couple of email conversations with a company called Avvel I ordered a ‘long range iBeacon’.

Avvel iBeacon (long range)

The device turned up the next day and was simple to setup and configure. At this point I’m not really bothered about the Major and Minor broadcast values – this is only for me. Maybe later if it works I’ll look to use these to indicate the device and who has it…

The Code

I’m already using the bluez library via python on my RPi2 to detect the phone via BT. Every 5 minutes I scan for the BT address of our phones. The true false flag is posted into our mqtt broker where OpenHAB uses the value to set the in/out switch. The plan was to do exactly the same except using BTLE.

As usual, it didn’t happen. While i could happily

sudo hcitool lescan

and find the keyfob, the ability to do this in the python script eluded me. Various tutorials talked about using gatttools or adding extra libraries (that failed to either install, compile or run), but none of them worked.  I wanted to use python in order to limit extra packages, libraries and complexity that installing extra things could add to the system. I can’t have a HA controller fall over because of a clash between different bits.

FInally I expanded my search to other languages and found noble for NodeJS.  I’ve actually used noble when I was doing the presence detection work before – that time I was using it embedded in Node RED. As all my recent work has been in NodeJS, I figured I’d try it for this.

The beacon is set to broadcast every 9.9 seconds (at least I think that’s what I set it to be), so the script scans for 25 seconds every three minutes. At the end of the 25 seconds, the script totals up how many times it has seen each of the specific devices and then sends a true or false value to the mqtt broker for each one where it is again picked up by OH and used. The three minute cycle is controlled by a crontab -e while the 25 seconds is a simple JS setTimeOut().

The Result

Well so far it has worked (sort of). The script picks up the keyfob successfully and OH gets the updates as I come and go. The issue is signal propagation. In a straight line with no obstructions I’m able to detect the keyfob up to about 50m (bottom of the garden!). The issue is that between the RPi2 that has the USB dongle doing the detection and the front door where the keys are supposed to live are walls, radiators, kitchen units and potentially small children. This drops the successful detection rate down considerably – it doesn’t stop it completely, but it does drop it enough to make it unreliable.

My next option is to move the OH box to a better location that may have a clearer ‘line of sight’, but that will mean grubbing around behind the AV cupboard and thats not a job to be taken lightly!


As the keyfob is on a big clip on my door keys, it’s actually easier for me to just unclip it and drop it with my other keys in the lounge rather than leave it on the door keys. It’s also safer than me rummaging around in the AV cupboard.


DIY Hue Strip

Posted: September 7, 2015 in HA, Hacking and playing
Tags: ,
When we re-built the kitchen last year, we wanted to add some low level lighting so that we could use the kitchen at night without using the main (excessively bright) ceiling light. As usual, it kept being put off, but with winter rapidly approaching, the need for these lights is now becoming urgent.
I was thinking about installing some Philips Hue LED strips, but various people had reported that they weren’t overly bright, so their suitability for our needs was an issue. I’m not forking out for a Hue kit and strip to find out it isn’t bright enough! Granted now I’ve played with LED strips, the kids have requested some things that the Hue strip might be suitable for….
The excellent forum at Micasa Verde has a tutorial about hacking some ‘cheap’ Ikea Dioder LED strips using a Fibaro RGBW control unit. This allows me to integrate the lights into my existing OpenHAB setup for automation and still allows for local manual control.
With Vesternet having Monday sales throughout August, I was able to pick up the Fibaro unit cheap.
Rummaging around in the Arduino/RPi box provided the necessary jumper wires and we were away.


The above picture shows the Fibaro RGBW (top) unit jumpered into the Ikea Dioder control (bottom) and LED strip distributor (middle).
The manual switch unit allows for local control of on/off and colour select. There are also 2 additional buttons for fast and slow colour changes.

Fibaro RGBW in Veralite Control Panel

Fibaro RGBW in Veralite Control Panel

Once the unit is powered, the Fibaro can be included in the Z-Wave network and will appear in the Veralite (U15) as 6 separate devices (Master (inc power use), On, Red, Green, Blue, White). And no I don’t know why we have a master and a power…. I’m sure someone can explain it, but it probably makes sense if you have a Fibaro controller.
Once I’d mapped the devices across into my OpenHAB controller, I can use the lights from any of the OpenHAB interfaces.
Group gRGBW "RGBW Light" <colorwheel> (Lights)

Dimmer RGBW_GF_Kitchen_DimmerAll "RGBW Light Control [%d %%]" <switch> (gRGBW) {mios="unit:house,device:128/service/Dimming1/LoadLevelStatus", autoupdate="false"}
Dimmer RGBW_GF_Kitchen_DimmerR "RGBW Light Red [%d %%]" <switch> {mios="unit:house,device:130/service/Dimming1/LoadLevelStatus", autoupdate="false"}
Dimmer RGBW_GF_Kitchen_DimmerG "RGBW Light Green [%d %%]" <switch> {mios="unit:house,device:131/service/Dimming1/LoadLevelStatus", autoupdate="false"}
Dimmer RGBW_GF_Kitchen_DimmerB "RGBW Light Blue [%d %%]" <switch> {mios="unit:house,device:132/service/Dimming1/LoadLevelStatus", autoupdate="false"}
Dimmer RGBW_GF_Kitchen_DimmerW "RGBW Light White [%d %%]" <switch> {mios="unit:house,device:129/service/Dimming1/LoadLevelStatus", autoupdate="false"}
Switch  RGBW_GF_Kitchen_SwitchAll "Switch All" <switch>  (gRGBW) {mios="unit:house,device:128/service/SwitchPower1/Status"}
Switch  RGBW_GF_Kitchen_SwitchR "Switch Red"  <switch>  (gRGBW) {mios="unit:house,device:130/service/SwitchPower1/Status"}
Switch  RGBW_GF_Kitchen_SwitchG "Switch Green"  <switch>  (gRGBW) {mios="unit:house,device:131/service/SwitchPower1/Status"}
Switch  RGBW_GF_Kitchen_SwitchB "Switch Blue"  <switch>  (gRGBW) {mios="unit:house,device:132/service/SwitchPower1/Status"}
Switch  RGBW_GF_Kitchen_SwitchW "Switch White"      <switch>  (gRGBW) {mios="unit:house,device:129/service/SwitchPower1/Status"}
After installing the device I realised that I couldn’t mix and match my control methods – if I turned it on using the manual switch, the change of state wasn’t being picked up in OpenHAB and I couldn’t turn it off. The opposite was true as well – turning it on using OpenHAB didn’t allow me to turn it off via the switch. This is a little frustrating, especially as the manual switch feels like a momentary contact type, so the on-off state shouldn’t be fixed.
I’ve queried this with the bright people on the MCV forum, and they confirm that this is expected behaviour – we have 2 switches – and it appears that the manual switch isn’t a momentary contact, so unified control is impossible. BOOO!
Micasa Verde forum –,25549.0.html
Vesternet –