Posts Tagged ‘HA’

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.




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 –

I’m playing with consoles or dashboards for use with OpenHAB. OpenRemote is good as a remote, but the ability to display status info is better suited to a dashboard. Earlier attempts have used the Tomcat server to display simple HTML/JS/CSS web pages, but occasionally I need a ‘proper’ web server so I can try out things like PHP.

Normally I’d insert Apache between the browser and Tomcat to allow it to handle redirects and routes when other page types are encountered, but the hassle of installing a memory hog like Apache for playing with the odd PHP page seems pointless.

nginx is a lightweight alternative that is more efficient & faster than Apache in serving requests, but at the cost of less bells & whistles. Given the nature of the work, simplicity is the key here.

So install nginx:

sudo apt-get update
sudo apt-get install nginx

Then MySQL:

sudo apt-get install mysql-server

Then php:

sudo apt-get install php5-fpm php5-mysql

We need to modify PHP to prevent path fixing by changing a flag. Edit the .ini file

sudo nano /etc/php5/fpm/php.ini

Replace the




and then save the .ini file and restart PHP with

sudo service php5-fpm restart

Finally configure nginx to work with PHP. Edit the config

sudo nano /etc/nginx/sites-available/default

We need to modify the server file to use PHP and to prevent bad PHP requests being passed around:

server {
 listen 80 default_server;
 listen [::]:80 default_server ipv6only=on;
root /usr/share/nginx/html;
 index index.php index.html index.htm;
location / {
 try_files $uri $uri/ =404;
location ~ \.php$ {
 try_files $uri =404;
 fastcgi_split_path_info ^(.+\.php)(/.+)$;
 fastcgi_pass unix:/var/run/php5-fpm.sock;
 fastcgi_index index.php;
 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 include fastcgi_params;

Finally, restart nginx

sudo service nginx restart

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….

OpenHAB Update

Posted: March 5, 2015 in HA
Tags: ,

Searching for some information on Google yesterday returned one of my own posts and made me realise that I’ve not posted anything about my progress with OpenHAB for ages.

OpenHAB is still in daily use and is now happily controlling the various simple scenes that the Veralite originally controlled e.g. turning on and off the dehumidifier. It has now also allowed me to migrate simple scenes to more complex rules based on day of the week, school holidays and even family holidays.

My old Veralite system had a table lamp and some fairy lights turned on at a specific time Mon-Fri and at a different time Sat & Sun as a simple alarm for my daughter. I had to remember to enable and disable the specific timers in the Veralite if it was school holidays or if the timing had to change. This lead to a single scene with 3 or 4 specific ‘ON’ timers and an associated 3 or 4 ‘OFF’ timers.

With OpenHAB I now have a single rule that works on the day of the week and 2 simple true/false switches for school or family holidays to control all the morning wake up alarms. Granted I could probably have done it in Lua, but I much rather work in an IDE that gives me error checking rather than try and do everything in the Lua console on the Veralite.

I also have alerting and messaging capabilities that can tell me when I need to do something. By monitoring the on state of the dehumidifier and the power draw I can tell if the bucket needs emptying. If it does I can send a message out to my phone via Pushover, tweet an alert or even display a message on one or all of the Kodi (nee XBMC) boxes that are in various rooms. Sounds like overkill, but it means that the machine actually gets emptied and gets on with the job rather than relying on random checks by either myself or the wife.

By using the Veralite as simply a Z-Wave (& 433MHz) controller and abstracting the control logic into OpenHAB I have managed to reduce the demands on the Veralite, reduce the number of plugins/addons installed and consequently increase the stability of the Veralite.