Archive for the ‘HA’ Category

Xiaomi Smart Home

Posted: January 6, 2018 in HA, Hardware
Tags: ,

The OpenHAB community have been taking about Xiaomi and the raft of components that you can get relatively cheaply (even cheaper direct from China!). It’s ZigBee based, so it shouldn’t interfere with current devices.

I’m not keen on the idea of adding another hub/gateway to my setup, but for roughly £20, it might be worth a punt. I always tell myself that “worse case I can sell it on eBay”. Never actually happens though…. So AliExpress and GearBest both list the gateway, but the one on GearBest appears to be the 3rd generation. From reading the notes on the OpenHAB documents and forums it seems that gen 2 or later is supported. AliExpress may have the gen 2 and gen 3, but as all the suppliers use the same stock photo, it’s quite difficult to see. Being Christmas, there’s a sale on, so I’ve also picked up a button and 2 door sensors. Total cost ~ £30 with shipping.

Let’s be honest I couldn’t get 2 Z-Wave door sensors in the UK for that price!

The downside to all this is the time for delivery. I ordered the kit on 21st December and it finally arrived on 4th January. Not long really given the Xmas holidays, but I get impatient waiting for new toys!


When the parcel finally arrived, it contained 4 small white boxes. The largest – probably 10cm a side contained the new hub.


Xiaomi Smart Hub with UK Adapter

The other 3 were the same size, each containing a device.

Each box also contained a small instruction leaflet in Chinese, and if appropriate some spare double-sided tape to mount the device.

The Hub includes a LED ring for light effects, an ambient light sensor as well as a speaker. The idea is to plug it into the wall socket somewhere central and use these features as part of the whole home solution.


The installation of the hub and devices is a little ’round-the-houses’, but is outlined in the OH documentation here.

Slightly disconcerting is the female Chinese voice bellowing out of the hub when you try to add devices. Once you jumped through the hoops of adding the hub to OpenHAB, any new devices appear in the Inbox for inclusion. As per the binding documents, I’ve blocked the hub from any external access. It means I can’t use the app, but I don’t need it as OH handles it all for me.

Using in OH

One of the things that took me a while to figure out was the alarm timer channel for the door sensor.

Number DoorSwitch_AlarmTimer <clock> { channel="mihome:sensor_magnet:<ID>:isOpenAlarmTimer" }

This value needs to be set on the hub by OH and determines how long the door should be in an OPEN state before the ‘isOpenAlarm’ switch to be triggered. I believe it’s currently defaults to 300 seconds, but I recommend experimenting.

In my rules I set the value on system startup

or in the newer format
So the alarm will trigger if the door is open for more than 120 seconds.
I’m happy with the kit so far, but finding somewhere to put the hub is an issue – it only comes with an integrated plug for use in China, so a China -> UK adapter is needed, which adds to the height of the device. With an adapter it is now about 15cm high, so far too big to just plug into the wall!

Next Steps

I’ve got a couple of Z-Wave Fibaro motion detectors that also supply temperature and humidity info that go through batteries at an incredible rate. To be honest, the temperature and humidity data is more important that the motion sensor, so I’ve ordered a couple of temp & humidity sensors to replace them as well as 2 more buttons.


FYI – These devices are NOT always CE certified for use in the UK, so using them is at your own risk.





Posted: June 16, 2017 in Audio, HA, House, Work Stuff

Well, apparently it’s been almost 6 months since I last posted…. where did the time go? New job, new projects and general family I guess.

Anyway, I had been playing with the HiFiPi, but I got sidetracked by trying to get it working with Logitech Media Server that runs on the family server… that way I can integrate it with OpenHAB and control it around the house (read turn off the kids music after bedtime!). That diverted into trying to get a touchscreen working and then the Pi got requisitioned for a different project…

A MagicMirror project…. that then involved me writing a couple of public transport modules – bus stop info and railway info just because I felt the need to write something! The not being a developer/R&D engineer occasionally bites.

That led to me rebuilding OpenHAB (again) using the new OpenHABian RPi image and then trying to tidy up the sprawl that our OH installation had become. Basically trying to make it a bit more ‘logical’; grouping rooms by floor and use, new targeted site maps and stuff like that rather than having one huge file for all items, one for rules, one multi-level sitemap etc etc. I’m now involved in helping to test a new OH binding that is used to control the Honeywell EvoHome system.

I’ve also finally got a reasonable amp and speakers in the lounge… but of course that meant cleaning up the rats nest of cables behind the AV cupboard and retiring as part of installing the amp!

So I have been doing stuff… I’ve just been too busy actually doing it to blog about it.

Migrating to OpenHAB 2

Posted: September 8, 2016 in HA, Hacking and playing, House

With the Beta release of OpenHAB2, I finally decided that it was time to look at the migration path from OH1.8. I also decided to do the proper Veralite integration and use the excellent scripts provide by Guessed to convert everything in my Z-Wave controller and import it to OH2.

So far it has been quite easy to convert from OH1 to OH2, but the following things did catch me out. Most of this revolves around the new hierarchy/architecture of things/items/channels.

The old way to refer to an item:

Switch Hue_GF_Toggle_Snug   "Snug Bloom"  (gGfloor)  {hue="1"}

The new way to refer to a v2.0 item:

Switch Hue_GF_Toggle_Snug   "Snug Bloom"  (gGFloor)  {channel="hue:LLC001:000000000ab1:1:color"}

Device detection and inclusion with the Paper UI

If you install version 2.0 compatible bindings – Hue, Sonos, Weather, etc the PaperUI will allow you to discover the real devices on the network and extract the relevant items. However, these items are NOT stored in an item file; they end up in the /userdata/mapdb part of the file system. This makes it a PITA to then refer to them as you need to figure out the correct channel name & reference to make use of them.

So if I need to write a rule to turn on the Hue Bloom from the above example, I need to copy the channel info from the PaperUI interface and paste it into my rule.

Being pedantic, I prefer to have all my items in a single location (currently a loooong .items file) so I can find them again. If I add the ‘discovered’ item to my .items file, I’ll end up with duplicate entry error in the log. Actually writing this post made me realise why I kept getting the error despite repeatedly searching for the item and finding only a single reference in my conf dir!!!!

So I’ll end up using the auto discover and then not enable any of the channels the PaperUI displays, I’ll just copy and paste the value to my own items file.

Using 1.9 binding means using old style item mapping

Using the MiOS binding tools I imported into OH2 all the devices controlled by the Veralite Z-Wave controller. I then spent ages trying to figure out how I could convert


into the correct format that OH2 uses


without success. All the examples talk about using this channel={} format and that the non 2.0 bindings (often called 1.9) will work using the compatibility layer that is built into OH2.

What I didn’t realise was that these 1.9 bindings still use the OH1 item convention, so there was no need to change them!

Import libraries

The migration docs point out that under the new architecture there is no need to include imports at the top of the rules/scripts. So in the past I would have:

import org.openhab.core.library.types.*
import org.openhab.core.persistence.*
import org.openhab.model.script.actions.*
import java.util.Date
import java.text.SimpleDateFormat

So when I copied across my rules, I happily deleted all the import statements.

Stupidly I assumed that as this was a Java environment this included the java libraries. It doesn’t. It only applies to the OpenHAB ones. Thankfully I use git, so rolling back all the changes wasn’t as big a deal as it could have been!

The new imports now include only Java libaries:

import java.util.Date
import java.text.SimpleDateFormat


Eclipse Designer and OpenHAB designer

This is more a moan than a gotcha… Needing to have OHDesigner open to access my OH1 configuration and Eclipse Smart Home Designer to edit the OH2 ones… EclipseSHD won’t open OH1 directories and vice-versa.

At least on ‘nix I can use workspaces and switch between them, on Windows, not so much.


Official OH 2 documentation

Migration guide

OpenHAB WIki

Repurposing Wireless Doorbell Button

Posted: January 14, 2016 in HA, Hardware
Tags: , ,

Because I found myself turning things off or down when I went to bed, I added a simple button on the OH app to run a very simple script to turn off lights and arm the motion detectors. Once I got my head around the heating API I also added calls to turn the heating in certain rooms to night mode.

This was all great, but I still had to go through the hoops of finding a device, opening the app, and pressing the button. I wanted a physical button to do this!

Enter the Nexa Push Button (LMLT-711) from Clas Olson. This is a 433Mhz device that is designed to work with various other Nexa doorbells. BUT as it is 433Mhz, and Nexa is supported by the excellent RFXCom plugin on my Veralite, it should work.

Other Nexa items – several temperature/humidity sensors have al worked perfectly with the Vera and are happily reporting from around the house (and they are a LOT cheaper than the Z-Wave equivalent).

Anyway although the device is supported and appears in the Vera console, pressing the button seems to trigger the ‘group-on’ button that automatically ties itself to Scene 100. Trouble is that scene 100 doesn’t exist… and I’ve never figured out how to create a specifically numbered scene!

Screen Shot 2016-01-14 at 09.07.32

Trying to create a new automation scene and then change the scene that gets triggered didn’t work either; it just reset back to 100. This meant that I couldn’t do much in Vera and then even less in OH.

Anyway – after discussions with Guessed & Lolodomo on the OH forum I figured out a way around the issue.

1. Connect the Nexa doorbell button to the Vera (device #134)
2. Create a virtual switch in Vera (device #140)

Screen Shot 2016-01-14 at 09.07.47

3. Create a new scene & trigger in Vera – the trigger is tied to the actual Group On/Activated event from the doorbell button. When it is triggered it runs the follow LUUP script:

status = luup.variable_get("urn:upnp-org:serviceId:VSwitch1","Status", 140)
 luup.call_action("urn:upnp-org:serviceId:VSwitch1", "SetTarget", {newTargetValue = "0"}, 140)
 luup.call_action("urn:upnp-org:serviceId:VSwitch1", "SetTarget", {newTargetValue = "1"}, 140)

This basically toggles the state of the virtual switch…. an event that I can detect and use in OH very simply.

Switch Bedtime "Bedtime" (gSettings) {mios="unit:house,device:140/service/SwitchPower1/Status"}

4. When OH Bedtime is ‘ON’ – run the script….

I currently just use a timer to reset the switch back to ‘OFF’ after 30 minutes, it doesn’t do anything, just changes the status of the switch across the different devices so it’s ready for use the next night.

Alternatively I could get it to run ‘wake up’ events instead – push on at night and then push off in the morning, but I’ve not really thought about what I could do until now…..


UK Clas Olson Nexa button – here

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 –

Ninja Blocks – End Of The Dream?

Posted: May 15, 2015 in HA

So it looks like Ninja Blocks are shutting up shop. They have announced that they have run out of money and that development of the NinjaSphere will now stop.

While the NinjaCloud will continue to run, it looks like that service could be shuttered at some point in the future when the money finally runs out. No cloud basically reduces the NinjaBlock to paperweight status.

Time to see what else I can run on it I guess… it is a BB after all….