Tag Archives: Network commands

Logs, logic and inspiration: Managing a complex home control setup

You know how it goes.  You start with one or two home control devices.  You find it amazing that you can control them from your phone.  You want more.  And more…

Here’s a quick diagram of my current setup at home.


There are at least 77 items for the home control system to control.  Each one has a unique set of capabilities, and inter dependencies with other devices.  Certain groups of these items require different communication protocols, some radio, some infrared, some HTTP and some via a webserver.

As my system has been created from several protocols and brands, I find it engaging and a full-on hobby to ensure they perform perfectly in concert.  Basic scripting has become more in-depth as I attempt to squeeze out the most from every device.  Although adding additional functionality is stimulating for me and ultimately rewarding for me and my flatmate, each iteration adds a new layer of complexity – and like every complex system, the bigger it is, the harder it can fall.

I’ve recently been faced with a problem.  A few times in a row, the Raspberry Pi 2 has frozen overnight. The controls and automatic lighting obviously do not respond, and then something as simple and as taken for granted as getting light and audio into the shower requires scrabbling through phone apps: not good if the water is already running!  Worse, the switches that are supposed to be triggered in the early morning, such as the “it is dawn” variable do not fire.  So with such a complex system how do you diagnose the problem?


The first answer is logs.  Loads of logs.  Ensure each of your subsystems are writing down what they are doing and just as importantly when they are doing it.  You can then rifle through the logs and find anything that is not behaving as you’d planned.

Inter-dependency diagrams

Okay, so this may be the most geeky thing I have said on this blog so far, but I like to keep diagrams and spreadsheets showing which systems and activities are inter-related.  And in the event of a catastrophic failure, they pay dividends.  You can literally trace your finger through the lines and see which scripts you need to check if something is not working right.  You can also keep track of things like ID codes and group codes for all your connected devices.


To do this you need to empty the house of unexpected variables (i.e. the rest of the family and pets large enough to trigger any sensors) and then physically run through each process that you think may be causing the problem.  If you are anything like me this usually involves an embarrassing and potentially uncomfortable period where you are remaining totally motionless right in front of a motion sensor to see what happens when the “no movement here” signal is sent.


You may be surprised by the other users’ perception and understanding of your home control system.  Ask other occupants what they think is happening.  At best they could hit the nail on the head, and if not they just may throw something so left-of-centre out there that is provides you with the fresh outlook you need to trace the problem.


I feel this entry will become outdated very soon.  As consumers we are on the cusp of having our cake and eating it: a fully integrated one-stop solution for home automation that will work seamlessly and without requiring manual programming.  It may even have the ability to provide reasons for failure and suggest ways to work around it, especially if open-source and app-based: a fellow user in the Netherlands could be granted temporary access to help sort out the problem you’re having with your garage door in California.

This new way will remove the complexity involved in getting disparate systems to work together, but will it provide the level of control we ‘first gen’ full home control aficionados will require?  Either way, I’m glad I’ll be able to say “In my day, we had to fumble around to find the solutions to these issues, and sometimes create our own!”




Controlling Sonos via LightwaveRF Mood Controllers

I had a request to write about how I control my Sonos players via my LightwaveRF Mood Controllers.  Actually, it’s a good call: re-engineering the mood controllers from simple light switches to pads which can control both lighting moods and audio more closely reflects the ‘built-in’ panels found in expensive custom installs.  In fact, using the technique below there’s nothing to stop you from controlling any number of home control activities from your mood controllers or handheld remotes.

I can say with authority that without these wall-mounted controllers all over the flat, I would never have been allowed to continue developing the system.  Having a familiar controller in each room ensures that users don’t need to run to the central controller or get out their smartphones whenever they want to make quick and regular changes to the light, heating or audio settings.

What you’ll need:

A summary is that node-sonos-http-api does the vast majority of the work, by ‘listening’ to all connected Sonos controllers and controlling them by very simple http requests.  These http requests are triggered by Domoticz once a signal is received from the mood controller.

How long this will take:

  • If you already have the Pi running Domoticz, and have been using a Sonos player already, and maybe have just bought a LigtwaveRF mood controller or other wall controller compatible with Domoticz, the whole thing will take about 30-40 minutes if you take your time.

Add the mood controller to Domoticz

From the Domoticz interface select the Switches screen, then select Learn Light/Switch at the top.  You should imagine the mood controller as two distinct switches stuck together: as far as Domoticz is concerned the two largest buttons are a completely different device compared to the four smaller buttons.

Immediately press the large OFF button (marked with a zero) on the mood controller.  In the box that appears give the mood controller a name – remembering that this is only the name given to the top two buttons of the controller (e.g Bathroom Lights).

This time we’re going to learn the lower row of the mood controller (the four smaller buttons). Repeat the above by pressing Learn Light/Switch and this time immediately press any one of the smaller buttons on the controller.  Name these too (e.g. Bathroom Audio).

Back up your Domoticz database

Just in case the next step causes problems for you it might be good to back up your system.  I’ve only needed to restore the system once – when I made a complete mess of installing node and npm.

Install node-sonos-http-api

I did this to install and it worked.  You may have a different setup or you may want to select another way of doing this.

Make sure you have node and npm installed.  If you don’t, search for and follow the instructions on how to install these carefully as I have messed this up more than once, by being all “I know how to do this, I’ll just skip this step”.  When will I ever learn?!

Get to the Domoticz folder and create a folder called sonos.

In the sonos folder, clone the node-sonos-http-api program by typing

git clone https://github.com/jishi/node-sonos-http-api.git

Navigate to the new node-sonos-http-api folder and fix the dependencies by typing

npm install

You can now run the program by typing

node server.js

Now the magic starts!  Open a browser and navigate to, where is the address of your Pi and Kitchen is the name of your Sonos speaker.

The browser will ‘open’ a blank page, but the speaker in the room will start playing (assuming something is in the play queue.  If not use  This time, the playlist “My Playlist” is selected (make sure you use hex codes such as %20 instead of spaces in the URL- this includes rooms, so Living Room becomes Living%20Room).

Use the commands listed here to control your Sonos players.

Create scripts

Consider the commands you will want to send to Sonos via the mood controllers.

In this example my room is called Bathroom and the functions I want to add to the mood controller are play, pause, Radio 4 and a playlist called Harry 1.

I’ll need to create four scripts.  The easiest way to create scripts on the Pi  is to use nano, or off the Pi I use WinSCP.

Make sure the scripts are stored in the domoticz folder (not any subfolder).

The scripts will be called Sonos-BR-Play,.sh Sonos-BR-Pause.sh, Sonos-BR-R4.sh and Sonos-BR-Harry1.sh

Sonos-BR-Play will include the following text (just one line is needed to send an http request via a command called curl):


Where is the address of the Pi and ‘Bathroom’ is the exact name of the Sonos player.

The other 3 files contain very similar commands:





So now I have these files in the domoticz folder.  I need to make them executable by Domoticz, so in the domoticz folder type

chmod u+x *.sh

We’re coming to the last part now!

Create LUA scripts for Domoticz

We need to run the scripts we created when Domoticz detects the button being pressed on the mood controller.  Let’s imagine the 4 small buttons on the mood controller are going to control the 4 functions we’ve just created scripts for.  The four buttons change the Domoticz device to Group Off, Group Mood 1, Group Mood 2 or Group Mood 3.  You can test this by pressing the buttons and waiting to see Domoticz change the status of the device.

I’m going to imagine that the mood controller’s set of 4 buttons is called ‘Bathroom Audio’ in Domoticz.

Go to the domoticz/scripts/lua folder and create a new file called script_device_BathroomAudio.lua

In the script I’m going to put this text in (you should see by the contents how you can change this):

commandArray = {}

if devicechanged['Bathroom Audio'] == 'Group Off' then

print ('Bathroom Play via mood controller')

elseif devicechanged['Bathroom Audio'] == 'Group Mood 1' then
print ('Bathroom Pause via mood controller')

elseif devicechanged['Bathroom Audio'] == 'Group Mood 2' then
print ('Bathroom Radio 4 via mood controller')

elseif devicechanged['Bathroom Audio'] == 'Group Mood 3' then
print ('Bathroom Harry Playlist via mood controller')


return commandArray

That’s it! You should be able to control your Sonos anywhere you can stick a LightwaveRF mood controller.  Let me know how you get on!

Designing a user interface


Something that I give a lot of thought regarding my home control set up to is the interface.  I have changed the ‘look and feel’ of the interface tens of times in the last few years (much to Chester’s frustration) and to be honest I don’t think I’ve ever found the ‘holy grail’.  But what makes a good home control interface and how would we recognise one?  I explore these questions with my guide to designing and implementing your own home control interface.

Step 1: Who will be using your interface, and on what?

One of the first things to think about is which devices will be displaying the interface.  In my household the interface is accessed via a fixed large tablet, a computer screen and smaller smartphone screens.  Therefore I may think about designing two types of interface, maybe that look and behave very similarly, one portrait (for holding a smartphone) and one landscape (for the computer screen and the permanent tablet on the wall).  I have designed two types in the past, but using a 100% web interface means that the content can adapt to multiple display types, therefore saving time and resources.

Step 2: Look at what is out there for inspiration (but don’t get too depressed with what you find).

If you search the internet for images of ‘home control interfaces’, you’ll see a few common themes.  I think the main thing that hits me is that although millions of pounds have been spent on perfectly attuning user interfaces in smartphones and computers (for example with the upcoming Windows 10 operating system), home automation interface design seems to have remained the same since its introduction. Without wishing to offend anyone here, I get the distinct impression that the interface is last on the development list.  It seems to me that the hardware takes priority, and then the interface is designed by someone in the existing team who really did not want the job.  I honestly believe this to be the main reason why home automation has not yet become mainstream.  It’s not the hardware: it’s the interface.

If you look hard enough however, you’ll find some clear and well-designed interfaces out there.  The companies that have chosen to invest in design are clearly the market leaders, and therefore can afford to spent time and money developing a look and feel that homeowners can use and appreciate.

What is the one design element that proves to me that the interface has been developed professionally?  Space.  Too many home control screens are jammed full of buttons, sliders and album art.  It’s hard to know where to look, and although this may be something of a visual trophy for the geek community – think how confusing this will look to others in your household.  This leads nicely on to my next step…

Step 3: Think about the order of things.  How will your commands ‘flow’?

As far as I am concerned, there are two main ways to organise your home control screens: by location or by function.  Organising by location means that you gather all your controls for one room onto one screen, so for the living room you’d have all the lights, the dehumidifier, the air conditioner and the TV controls all together.  Conversely, organising by function means that you’d put the controls for all your lights on one screen, heating and cooling on another screen, security on another screen etc.

I have created dozens of versions of both, and I personally prefer the latter.  For me it means that the user starts from the home screen with a definite decision on what they are intending to do.  The interface becomes less of a show-home piece and more of a practical and logical day-to-day assistant.

There is a balance to be achieved between the number of options displayed on the screen at one time and the number of selections required to perform an action.  Instead of scrolling through one giant page of options, or having to reduce button size down to miniscule proportions, it may be better to increase the number of screens and create a ‘flow’ for the user.  So instead of selecting ‘Audio’ and immediately being presented with a screen full of options, it may be better to then ask ‘Where do you want to the audio to play?’ and further ‘What kind of audio?’.


Step 4: Write it down!  Plan your screens.

I have wasted literally days of my life not following this simple step.  Plan your screens on paper.  Falling out from this step will be all the buttons you will need for each screen.  Don’t worry about what the screens will look like yet, just think about what options you want to show.

Navigation is a consideration here.  How will your users know where they are?  If you provide ‘breadcrumbs’ on your display (Home > Audio > Living Room) you’ll need to reserve the same area on each screen for that.  To get back to the main screen, will the ‘home’ button be in the same place for each screen?

Step 5: Get ‘the look’ and stick to it.

Decide on a look and feel for your interface.  You may choose to compliment your home décor or to stand out as an ultramodern feature.  Either way, this step requires as much external input as possible.  If you’ve found some designs that you liked from step 2, speak to your users about which ones they prefer, and what they’d like to see.

When you’ve selected a look – stick to it.  By that I mean don’t be tempted to bend your own rules.  Future-proof your design.  For each of your screens ensure that there will be scope to add new devices in the future with ease.  Don’t make your icons or buttons so intricate that you’ll not be able to match them easily.

If each of your buttons contains an icon and some text, make sure the icons are roughly the same size and the text is the same size and font.  Little things like ensuring there is consistent capitalisation across your interface can make a huge difference.  “Living Room Lights On” next to “Living room lights OFF” leaves an unprofessional air.


After years of designing interfaces for my own home, I have some pearls of wisdom for you here.  The first is to use perfectly square, flat buttons.  These look modern and will not go out of fashion (if you are reading this in 2020 and flat buttons are out of fashion, then I apologise).  Another reason I prefer perfectly squared icons, is that depending on what interface controller you use, you may be disappointed at how the controller renders curved corners, and your beautiful vision becomes a pixelated mess.  The bigger the button, the better.  Our cleaner visits once a week, and if she needs to use her glasses to see an option, I change the button immediately.  Larger buttons also means that fewer options can fit on each screen, and I am all for that.

Get each button you need from step 4 designed now.  I would recommend you put a selection of these buttons in one mocked-up screen to ensure they are the right size and they look right.  Choose unobtrusive wallpaper or a solid inconspicuous colour for the display.

Step 6: Think about feedback.

The devices your user will be controlling may not be in the same room as the interface, so remember that they may need reassuring that what they have requested has been carried out.  There are a few ways to achieve this.

A button which changes its look depending on the state of the device is one way to go.  This approach is more common in consumer installations and requires constant sensing (called ‘polling’ in home automation terms) to ensure that all interfaces ‘keep up’ with the device’s status.  Don’t forget that someone could switch on a device from their smartphone, so then the corresponding button will need to update on all screens to reflect this.   One such controller that is capable of keeping track of devices is Openremote – more on this in step 8.

Another idea is that a pop-up box could appear to confirm your selection, for example confirming “Fan in Living Room has been switched on.”

The panel itself could speak to you.  I have elected to use this as my primary feedback method in my latest interface design.  The display is not obstructed by pop-ups, and the user can walk away from the panel and will still hear the announcement.

Feedback should also be provided automatically, for example when a security alert is activated or when a user needs to do something that cannot be completed automatically (such as a reminder to close a door).  Users could be anywhere when this feedback needs to be given, so thinking beyond the physical interface of a screen, what other devices could be used?  In our home, we have Sonos speakers in every room, so urgent feedback can be given via spoken word through them.  For smoke alarms triggered by Nest, the Hue lights in each room will flash momentarily, alerting occupants that action needs to be taken.  I also use Notify My Android (NMA) via Domoticz to keep me informed via short ‘texts’.

Step 7: Remember the ‘automation’ in ‘home automation’.

Advanced controls that only you will use can be tucked away at the ‘back’ of your interface.  Settings and variables can be as hidden away as you like, followed by screens for ‘fine tuning’ settings for devices that other users will probably never use.  It’s sometimes useful to control one individual lamp in the living room, to set brightness, colour and saturation until it’s just perfect.  But how often do you actually do that? It would be wiser to initially show a list of pre-set scenes to be selected from, and then have the option to move to a different screen to change individual lights if required.

Just because your system can do something, don’t give it pride of place and assume that every user will want to do it.  I have been guilty of re-building my interface around that a newly-purchased piece of hardware, just to show it off its new features.  This is a waste of time and ultimately confuses other users.

Step 8: Where to host your interface?

This depends on your home control set up.  I have used a few different downloadable options here, one being Openremote which is a program that runs on your computer or Raspberry Pi and ‘serves’ up information to panels around the home.  By polling your home control hardware at intervals you can select, Openremote can keep track of your devices.

Domoticz also has its own user interface that can be used on a plethora of screen sizes, however although I absolutely adore Domoticz and use it as the basis of all my home control activities, I think that the user interface is – dare I say it – where there has been less development.  By no means do I think this is a let-down however, as I would not have been able to thoroughly automate our home without Domoticz.

Another route – which is the one I have taken – is to design a web-based interface from scratch.  As Domoticz has a ‘www’ folder that can serve up any html document in that folder, I don’t need a separate web server.  I just upload all the html screens into a sub-folder of the Domoticz/www folder and then navigate to that page from any panel in the home network.  Here’s the secret.  Controlling Domoticz devices from a web-page is really easy.  You just have to navigate to a specific address and Domoticz will turn on a device.  You can get more information about that on the Domoticz API/JSON URLs page.

The only thing I had to work out for myself is – when I navigate to a URL asking Domoticz to turn on a device, the screen shows a ‘result page’.  The user would have to then click the browser’s ‘back’ button to get away from this result page and then back to the interface.  To solve this, I use a very small frame at the bottom of the screen.  When the user clicks a selection in the main screen, the link is followed in the small frame at the bottom, so as not to disrupt the main window.

Step 9: Testing and Rollout

Before announcing to your loved ones that you have created a masterpiece, I would encourage you to test every function on every page of your home control interface, especially those functions which will affect many devices in the home.  As an example, choose a time when no-one else is around and activate your ‘leave’ function and see if it does actually behave in the way you expect.  It’s too late when your family is ready to leave and you proudly press the button, only for the whole system to crash.  Trust in the system as a whole can also be eroded in this way.

Personally, I have the flat to myself every other Friday, only having to navigate around our cat.  I use this opportunity to test new functions I have added.  Our neighbours must think the flat goes crazy every two weeks, but it’s worth it.

Once everything is ready, you can add links to your interface on every device that will access it.  You can now go back to step one to restart the process.  I say this with confidence because as I stated at the start of this article, there is no ‘perfect’ user interface and there are always improvements to be made.  I truly believe that I will always be in pursuit of user interface perfection.

Speaking to the Pi


I use Putty to connect to the Raspberry Pi, so that I don’t need to connect a screen and keyboard to the Pi.  I just fire up Putty from a computer on the same network and then use that computer’s screen and keyboard to control the Pi.  Read the installation instructions (and the legal information) before installing Putty.

Once you have launched Putty, enter the network address and port of the Pi into the boxes, and click connect.


You’ll then see a login screen.  Enter the login credentials as supplied by the place you downloaded the Raspberry Pi image from (I got my image from the Domoticz website – use the Raspberry Pi file.  More instructions available here).


You’ll then be able to change the folder you are looking in to domoticz.

Type cd domoticz and press enter.

pi@domoticzpi ~/domoticz $

will be displayed.

That’s it!  You’re connected to your Pi and you can command it from any computer with Putty installed on your home network.