Freedomotic logging for development and debugging Part 2

Ok, so now we have all our log messages coded in, with appropriate log levels like warn, info, debug. How do we control where they are sent, and how much we want to see?

Freedomotic  uses log4j to handle its logging output and the config file is at framework/freedomotic-core/src/main/resources/log4j.properties

The default at the moment is to log to the console but I want to log some to the console, and some to syslog. While I am developing, the console should show me important errors from all parts of the application and the output to syslog should show me the most granular output of the module I am working on, but also what was sent to the console. This allows me to see any important errors to do with my interactions with other parts of the application straight away on the console where I started the application, but also to see them in-line with my more detailed errors/debugging log via syslog.

Here is my log4j config:

# root logger
log4j.rootLogger=WARN, sysout, SYSLOG

# Output to console
log4j.appender.sysout=org.apache.log4j.ConsoleAppender
log4j.appender.sysout.threshold=WARN
log4j.appender.sysout.layout=org.apache.log4j.PatternLayout
log4j.appender.sysout.layout.ConversionPattern=%-5p <%t> [%C{1}]: %m%n

# Output to Syslog
log4j.appender.SYSLOG=org.apache.log4j.net.SyslogAppender
log4j.appender.SYSLOG.threshold=DEBUG
log4j.appender.SYSLOG.syslogHost=localhost
log4j.appender.SYSLOG.facility=local1
log4j.appender.SYSLOG.facilityPrinting=false
log4j.appender.SYSLOG.layout=org.apache.log4j.PatternLayout
log4j.appender.SYSLOG.layout.conversionPattern=%p <%t> [%C]: %m%n

# Detailed logging of my plugin
log4j.logger.com.freedomotic.plugins.devices.emoncms=DEBUG, SYSLOG
log4j.additivity.com.freedomotic.plugins.devices.emoncms=false
  • Root logger defines all the places I want to log to, and what starting level to send there. I have it set to WARN which means sysout and SYSLOG will get all messages of levels Warning or Error (since I am not expecting levels Critical, Alert or Emergency from my application – they are for the operating system).
  • The Console Appender is defined with a maximum level of WARN. This means that if I were to alter the root logger to DEBUG, I would still only get WARN and worse to it.
  • The Syslog Appender is defines with a maximum level of DEBUG, which means any log entry can potentially get there.
  • I am sending to the syslog facility ‘local1’ on localhost which I have configured in my syslog config to go to its own file (for tidyness).
  • My conversionPattern of ‘%p <%t> [%C]: %m%n’ is slightly different to what I have seen everywhere else on the internet (clue – it has a colon) and is specifically to stop a formatting error which messes up some entries when syslogging on my Mac. (I was getting spurious ‘Unknown’ and some truncation.)
  • The ‘log4j.additivity.com.freedomotic.emoncms=false’ line basically means don’t double-up messages – only add them if they aren’t already there.

So, now I can debug by tailing my log, or better still I can deal with more awkward problems with my favourite log tool, Splunk:

Splunk log analysis

Freedomotic logging for development and debugging

Debug logOut of the box, Freedomotic logging output currently goes to the console. When you start the application, you see a whole load of messages streaming past you on the screen – very messy.

For me, the logging output should go to a file or what I mean really is that it should be sent to syslog. Ultimately, this is the best way to log applications because putting it into a system designed just for logging means you get access to all the things build specifically for dealing with logging. That probably makes no sense, but I will try to explain by way of my setup.

But firstly, lets look at how the logging happens in Freedomotic. Here is an example of some code from my Resol DL2 plugin:

 LOG.info("Loading Resol DL2 devices..");

..and its easy to see this creates the output of my informative text to the log. Actually I am telling the plugin something else – I have set the log level of ‘info’ which is important too. When you write to the log, you always specify what level you want. Here are the log levels, and Apple’s suggested usage:

  • Emergency (level 0) – The highest priority, usually reserved for catastrophic failures and reboot notices.
  • Alert (level 1) – A serious failure in a key system.
  • Critical (level 2) – A failure in a key system.
  • Error (level 3) – Something has failed.
  • Warning (level 4) Something is amiss and might fail if not corrected.
  • Notice (level 5) – Things of moderate interest to the user or administrator.
  • Info (level 6) – The lowest priority that you would normally log, and purely informational in nature.
  • Debug (level 7) – The lowest priority, and normally not logged except for messages from the kernel.

So, in my case the message is ‘purely informational in nature’ – which it is. But why would I want to log this information? Won’t I be filling the log with pointless chatter?

Now, here is the good bit with proper logging inside an application. I can code in whatever log information at whatever level and then at runtime I can decide what logs I want output from the application.  This means I can put debugging log entries in the code and have these enabled for debugging, but turned off when I am not interested in seeing them.

Next lets see how how this is done..

Eight pointers to help you fix your Sonos for big buildings

Sonos FamilyTaking a working Sonos system and moving to a bigger house should be simple. Sonos ‘just works’, right?

Well, away from the Labs I moved house last year to somewhere with a bit more space. The Sonos came with me and the first zone was unpacked early on the morning after the move as we began the unboxing. Since then it has never worked properly.. until this week.

Over the months I have tried various things to attempt to cure the drop-outs, unresponsive controllers and general grief. Here us some useful info to help anyone in the same situation:

1. SonosNet doesn’t like airwave congestion.

Sonos Preferences - AdvancedSonosNet is the built-in wireless networking of the Sonos system (although you can also get it to use your own wifi now). SonosNet is effectively a private, hidden wifi network and operates in the same air-space as your own wifi, DECT mobile phones and other wireless devices in the same waveband. For this reason, you should ensure your SonosNet is not on the same channel as your Wifi. It is simple to set this from the desktop controller preferences screen. Choices are Chanel 1, 6 or 11 and your Wifi should also be on one of these three.

2. Your wired connections aren’t necessarily being used.

Just because you have added wired connections either between Sonos components, or back to your router / switch doesn’t mean Sonos is using them. The next two points relate to this.

3. Sonos tries to keep ‘hops’ to a minimum, doesn’t necessarily use nodes you think it will.

It seems like Sonos components only like to be a maximum of two hops from each other. This means that if you try to improve coverage by adding say a Bridge Sonos Connect between two other components, it will ignore it because it would add another hop and therefore more latency.

4. Sonos uses Spanning Tree Protocol, so your network switch has to play nicely with this.

This is a bit network-engineer-techy. Because a Sonos system can have multiple connection paths between components, it needs a way to decide which one it will use – and it will only use one path at any given time. It uses something called Spanning Tree Protocol (or STP for short) to do this. If you have components connected via a network switch (which would include one built into your router if it has multiple network ports) then it has to play nicely with STP. By this I mean it either has to implement STP (eg. a managed switch), or pass STP information between connected devices. If it doesn’t do either of these, Sonos will ignore your wired network for connecting Sonos components together and just use SonosNet. Also bear in mind that the STP cost may have to be adjusted, depending on the STP protocol your switch is using.

5. If you have any wired connections, it will be using SonosNet, not your wifi.

'About my Sonos System' screen

‘About my Sonos System’ screen

The recent additional option of connecting your Sonos to your Wifi means that you no longer need the first Sonos component to be wired to your router (or network). However, if any of your Sonos components have a wired connection, the whole system will revert back to SonosNet automatically. This is not obvious – the controller won’t tell you. The best way to confirm this is with the desktop controller – go to ‘About my Sonos System’ which shows you a list of your components. There is an option called WM – 0 means SonosNet, 1 means Wifi. If the Sonos component switches from one to the other, it will reboot. I have seen a component connected via a dodgy network cable continually switch between the two, rebooting each time.

6. Your Sonos system provides diagnostics (but they are not really for you to look at).

Sonos components provide a web interface which can give you a better picture of what is going on. Find the IP of a component using the ‘About my Sonos System’ screen above. Then connect to: http://<your IP:1400/support/review for example on my system: http://192.168.1.102:1400/support/review

On a large system (or one with dodgy networking) this can take a while to return a page, or if your system is really bad, it can fail altogether some of the time. The page will show a list of your components, each of which can be expanded to list a whole load of stuff, most of which I ignore. There are two particularly useful diagnostics though.

At the bottom of the list is Network Matrix. This gives a tabular view of your Sonos components. Each one is listed along the top and down the left of the table. Here is what mine looks like now (ignore the undefined columns which are components currently turned off):

Screen Shot 2014-11-07 at 11.31.51

 

Some important points to look for on your matrix.

  • Look at the colours – green is best, then yellow, orange, and worst is red. These are quality of wireless network to/from the device. An all-grey column/row indicates no wireless connections on that component. You may get for a wired component which is not participating in the SonosNet.
  • Look at the Inbound / Outbound numbers. They give signal strength and go up to 64. Low numbers are worst.
  • Coloured squares in the matrix show what is wirelessly connected to what. This will give you an idea of the path your music data takes.
  • There should only be one empty box per row/column on the matrix. This is where the same component meets on the row/column. If you have more empty boxes, then you have communication problems. Take a look at this matrix. The signal strength is all ok, but there are more blanks than there should be. This will (and does) result in drop-outs, controller delays etc.:

Sonos matrix

7.  Any one poor link in the mesh has the ability to affect the whole system.

Each Sonos zone has a media player which tries to maintain ‘subscriptions’ to all other media players. Also each controller tries to keep tabs of what each zone is up to (think about the Zones screen). If you have one badly connected zone, this will cause problems somewhere, whether its playback, poor controller response etc. The last matrix shows a system in a state where this happens. Everything works great for a while, then picking up a CR200 controller results in playback drop-out from a zone wired directly to the NAS!

8. Sonos provides ongoing support – and its good.

Sonos support have seen all this stuff before, and with access to the diagnostics can pinpoint problems. There is a built-in mechanism for getting this diagnostics to them – the ‘About my Sonos System’ screen (shown above in point 5) has a ‘Submit DIagnostics’ button. This will capture the state of the system and can be used straight after you have a problem to help Sonos Support.

Finally..

From learning all this, out of the many things I tried, I think these are the steps which made it all work in the end:

1. Install a managed switch. Set the STP cost on the Sonos ports to 10 (for 100Mbps) from the default of 19.

2. Wire network connections from the switch to key Sonos components at various points around the house.

3. Make sure the home Wifi was not on the same channel as the Sonos. I ended up with Sonos on 6, and Wifi on 1 and 11 (one at each end of the house).

 Happy Listening!

Ubiquiti Unifi AP-LR repair

We have had a couple of ‘frisbees’ – the excellent Ubiquiti Unifi access points knocking around which were broken. Unusually, they run on 24V POE rather than the more common 48V. One of the minions here in the Labs didn’t realise this and tried to power them straight from a switch with 48V. They broke.

Unifi_ap

The symptoms were that the power supply light would only flash periodically in sync with an orange light in the device. Unplug the ethernet cable from the frisbee and the PSU light comes on solid. This says power supply is fine, frisbee is broken.

There is precious little information on these devices about fixing them, other than a few people who have done the same as us. The usual answer is ‘its broken – buy another’.

On opening the device (4x torx screws), there is no evidence of damage – no black marks, charring, exploded components to give any clues as to the failure.

One comment I read talked about protection diodes which could be the cause. Looking at the circuit board, the power track from the ethernet connector goes to a voltage regulator chip, and on its way, there are some capacitors to ground and a large surface mount diode labelled ‘D1’. The markings on it are ‘129’ and ‘GEZ’. A little research shows this is a SMCJ24A which is a ‘transient voltage suppressor’ or TVS. GEZ is actually the identification of 24V working voltage rating used by Lite-On Semiconductor. This component is there to ‘clamp’ the voltage if it goes above 24V (actually somewhere between 26.7 and 29.5V) in order to protect the more sensitive circuits from voltage spikes (or people plugging in the wrong POE). In our case it had done its job in protecting the rest of the board, but has partially failed in that it won’t pass 24V for any length of time.

Location of D1 on Unifi AP-LR

It is not too difficult to remove D1 using a soldering iron and some long nosed pliers. Plugging in the board with D1 removed shows it works, but D1 is there to protect from spikes and so it is a good idea to replace it. The component costs pence each and is available from RS Components here. When soldering it back in, make sure you get it the correct way round; there is a line on the top at one side – this goes away from the edge of the board – towards the top on the picture above.

Update:

We have two broken APs – with D1 removed, both of them light the LED D29 which indicates power, and both have 3.3V on the JTAG port. One of them shows network activity when the ethernet port is plugged into the network – LED D30 flashes, but the other does nothing else. Sometimes LED D25 (the yellow/green one) lights up orange when it is powered up, sometimes not. I think this one is definitely for the bin. The other one has a working boot loader. If you power it on whilst holding the reset button down, D25 goes green after about 5 seconds, and then cycles orange/green/off after 10+. I think it does need the BIOS reinstalling though..

For anyone following this, I suggest removing D1 (even by cutting it in two with side cutters) and then powering up. You can then assess the condition of the rest of the board before sourcing the replacement TVS. These things aren’t that expensive, so no point in wasting loads of time on it..

Using emoncms for eco-eye data

emoncms is the data storage, graphing and general visualisations for the OpenEnergyMonitoring project.

For some time here at the Labs we have been using Xively for the data collection and graphing of our energy usage and other sensor stuff. It has really good graphing, plus excellent debug console for checking the incoming data. Beyond this, we have not really been making the best use of it.

We have now switched to emoncms for data collection and graphing. This will give us a better ability to graph multiple feeds together and in any case we will be moving to their sensors at some point in the future.

Their system is open source, so we could choose to host/run our own data collection/storage/graphing but for now an account with them will do. At a later date we can choose to migrate by downloading all our data from them.

After creating an account at emoncms  we set about sending them some data. This is described here and the Perl script we used to connect to Xively has been altered to post to emoncms with JSON type data as described on their API input page. It looks like this:

http://emoncms.org/input/post.json?json={power:200}&apikey=xxxxxxxxxxxxxxxxx

Power is in Watts, but you can pass anything to them in this way, including multiple inputs like {power1:123,power2:456}. For graphing with Xively we separately sent current and (calculated) power, but with emoncms there is no point because any ‘visualisation’ – graph / readout / dial – can be scaled and so if we send power consumption, we can back-calculate to current. This means we are not doubling up the collected data.

Once we started posting data to our account, the feed was listed in the feeds page:

emoncms feeds

..where we could tell it to log the data, and then we could get a graph of the data from the visualisations page:

emoncms graph

 

Better still, we could make a dashboard:

emoncms dashboard

Dashboards can be made public and so you can publish them if you want (as can individual feeds). Great stuff!

Perl script for eco-eye serial to emoncms is here on Github.

 

Eco-Eye energy monitor serial data collection

A few years ago my minions installed an Eco-Eye energy monitor in the Labs. We bought it with a serial cable and it has been connected to a Mac Mini to collect data and push it to Cosm (now Xively) via a Perl script. The serial output is 19,200 baud, 8-none-1.Eco-Eye

The supplied serial cable uses a Prolific PL2303 USB to serial chip and so the Mac needs a driver installing which you can get from Prolific here. The current version creates a device named /dev/tty.usbserial (which is much better than the previous cryptic name).

The Eco-Eye data is simple – two bytes which make up the reading are sent every four seconds consisting of msb then lsb representing amps times 100. So, the reading in amps to two decimal places is:

amps = ((byte1 x 256) + byte2) / 100

There is a Perl module to handle posting to Xively called Net::Parchube (because Xively was Cosm was Parchube) which makes that part simple. The hardest part is keeping the bytes in sync – when you start the script you don’t know which one you get first, and sometimes one doesn’t turn up. To handle this, the script has a timeout which makes sure dud readings don’t make it through and corrupt your data. It also averages over seven samples to post a reading about every 30 seconds.

Output will look something like this:

sample: 1, msb: 11, lsb; 18, amps: 28.34
sample: 2, msb: 11, lsb; 36, amps: 28.52
sample: 3, msb: 10, lsb; 244, amps: 28.04
sample: 4, msb: 11, lsb; 24, amps: 28.4
sample: 5, msb: 11, lsb; 28, amps: 28.44
sample: 6, msb: 11, lsb; 8, amps: 28.24
sample: 7, msb: 10, lsb; 240, amps: 28
2014-08-12 10:15:18 avg_amps: 28.28

And on Xively:

xively_data

As you can see, the script also sends a power figure calculated from the amps.

The script runs in the foreground which is not ideal, but it does the job. You can get it from Github here: https://github.com/cllarky/perl-sensor-net/blob/master/eco-eye/serial-cosm.pl

Freedomotic plugin – Resol DL2 reader

The Resol DL2 is a data-logger and web interface for the Resol range of solar controllers, plus some other (similar) stuff they do. The controllers use a proprietary serial bus for communication called VBus, and the DL2 is a way of getting remote access to the information the controller (or group of controllers) connected to it, plus storing this data to an SD card which you can remove or download from.

Resol DL2

There is also an iOS app called VBus Touch which connects to it to give you the current status of the system, plus some short historic data:

Resol VBus Touch screen 1

Resol VBus Touch historic data

 

This is ok, but there are several things I would like to do:

1. Collect more historic data which can be viewed in graph form real-time.

2. Make decisions based on the water temperature at particular times of the day. For example, turn on the heating to top up the tank with hot water, but only on a cold day when I know there is no sun coming.

I figure that by collecting this data into Freedomotic I can achieve this at some point. But first it has to be collected..

Now, the DL2 has a page which displays real-time data from the controller:

Resol DL2 data

..which is updated from a URL which returns JSON: /dl2/download/download?source=current&output_type=json

As you can see from the image, the version I am running is 2.03. Resol have a later version which connects to their cloud system but I would have to pay for the upgrade. I asked them if the JSON is still there, but they told me I should use the daily data download function (which obviously won’t give me real-time data).

Here is what the output looks like:

{
  "min_time" : 1406906963,
  "max_time" : 1406906963,
  "sieve_interval" : 1,
  "headerset_count" : 1,
  "unique_header_count" : 1,
  "headers" : [
  {
    "id" : "0010_4278_0100",
    "extId" : "00_0010_4278_0100",
    "channel" : 0,
    "destination_address" : 16,
    "source_address" : 17016,
    "protocol_version" : 16,
    "command" : 256,
    "length" : 28,
    "info" : 0,
    "destination_name" : "DFA",
    "source_name" : "DeltaSol BS/DrainBack",
    "fields" : [
    {
      "id" : "000_2_0",
      "name" : "Temperature sensor 1",
      "unit" : " °C"
    },
    {
      "id" : "002_2_0",
      "name" : "Temperature sensor 2",
      "unit" : " °C"
    },
    {
      "id" : "004_2_0",
      "name" : "Temperature sensor 3",
      "unit" : " °C"
    },
    {
      "id" : "006_2_0",
      "name" : "Temperature sensor 4",
      "unit" : " °C"
    },
    {
      "id" : "008_1_0",
      "name" : "Pump speed relay 1",
      "unit" : " %"
    },
    {
      "id" : "009_1_0",
      "name" : "Pump speed relay 2",
      "unit" : " %"
    },
    {
      "id" : "010_1_1",
      "name" : "Sensor 1 defective",
      "unit" : ""
    },
    {
      "id" : "010_1_2",
      "name" : "Sensor 2 defective",
      "unit" : ""
    },
    {
      "id" : "010_1_4",
      "name" : "Sensor 3 defective",
      "unit" : ""
    },
    {
      "id" : "010_1_8",
      "name" : "Sensor 4 defective",
      "unit" : ""
    },
    {
      "id" : "010_1_16",
      "name" : "Emergency store temperature",
      "unit" : ""
    },
    {
      "id" : "010_1_32",
      "name" : "Collector emergency temperature",
      "unit" : ""
    },
    {
      "id" : "011_1_1",
      "name" : "R1 manual operation",
      "unit" : ""
    },
    {
      "id" : "011_1_2",
      "name" : "R2 manual operation",
      "unit" : ""
    },
    {
      "id" : "012_2_0",
      "name" : "Operating hours relay 1",
      "unit" : " h"
    },
    {
      "id" : "014_2_0",
      "name" : "Operating hours relay 2",
      "unit" : " h"
    },
    {
      "id" : "016_2_0",
      "name" : "Heat quantity",
      "unit" : " Wh"
    },
    {
      "id" : "022_1_0",
      "name" : "Status",
      "unit" : ""
    },
    {
      "id" : "023_1_0",
      "name" : "Programme",
      "unit" : ""
    },
    {
      "id" : "024_2_0",
      "name" : "Version",
      "unit" : ""
    }
    ]
  }
  ],
  "headersets" : [
  {
    "timestamp" : 1406906963,
    "packets" : [
    {
      "header_index" : 0,
      "field_values" : [
      {
        "field_index" : 0,
        "raw_value" : 108.100000,
        "value" : "108.1"
      },
      {
        "field_index" : 1,
        "raw_value" : 61.300000,
        "value" : "61.3"
      },
      {
        "field_index" : 2,
        "raw_value" : 65.600000,
        "value" : "65.6"
      },
      {
        "field_index" : 3,
        "raw_value" : 888.800000,
        "value" : "888.8"
      },
      {
        "field_index" : 4,
        "raw_value" : 0,
        "value" : "0"
      },
      {
        "field_index" : 5,
        "raw_value" : 0,
        "value" : "0"
      },
      {
        "field_index" : 6,
        "raw_value" : 0,
        "value" : "0"
      },
      {
        "field_index" : 7,
        "raw_value" : 0,
        "value" : "0"
      },
      {
        "field_index" : 8,
        "raw_value" : 0,
        "value" : "0"
      },
      {
        "field_index" : 9,
        "raw_value" : 0,
        "value" : "0"
      },
      {
        "field_index" : 10,
        "raw_value" : 0,
        "value" : "0"
      },
      {
        "field_index" : 11,
        "raw_value" : 0,
        "value" : "0"
      },
      {
        "field_index" : 12,
        "raw_value" : 0,
        "value" : "0"
      },
      {
        "field_index" : 13,
        "raw_value" : 0,
        "value" : "0"
      },
      {
        "field_index" : 14,
        "raw_value" : 6883.000000,
        "value" : "6883"
      },
      {
        "field_index" : 15,
        "raw_value" : 0,
        "value" : "0"
      },
      {
        "field_index" : 16,
        "raw_value" : 0,
        "value" : "0"
      },
      {
        "field_index" : 17,
        "raw_value" : 1.000000,
        "value" : "1"
      },
      {
        "field_index" : 18,
        "raw_value" : 3.000000,
        "value" : "3"
      },
      {
        "field_index" : 19,
        "raw_value" : 2.030000,
        "value" : "2.03"
      }
      ],
      "data" : [
        57,
        4,
        101,
        2,
        144,
        2,
        184,
        34,
        0,
        0,
        0,
        0,
        227,
        26,
        0,
        0,
        0,
        0,
        0,
        0,
        0,
        0,
        1,
        3,
        203,
        0,
        0,
        0
      ]
    }
    ]
  }
  ]
}

So, I can take this output to collect the info I need into Freedomotic using a custom plugin, and publish it on the event bus to make use of. I decided to make the module flexible enough to collect data from as many devices as there are connected to the DL2, but also so you could specify which info you wanted. You can set this up in the manifest.xml config file.

The module is in Github: https://github.com/cllarky/freedomotic/tree/resol_plugin

resol_data

Next step is to work out how to log and graph the data..

 

Freedomotic Framework

Freedomotic is described as a ‘Smart Spaces Framework’ and is designed to be the glue to connect together all the elements of your building automation and be the decision engine to control what happens. IFreedomotict is extensible and so any new sensor/actuator/thing you can connect to can be made to work with it. For example it could connect to your Google Calendar to see when you are on holiday, and turn down the heating, or tweet you when the cat comes home.

It is written in Java and can run on Windows, Linux, Mac or anything with a Java environment. Better still, it is open source and has a community of developers supporting and nurturing its growth. Freedomotic is up and running in the Setfire Labs and so we will be hacking about with some plugins and seeing what fun we can have with it.

Somewhere between Arduino and Crestron

So what should a building automation system be like?

At one end, its a hobbyist/geek’s world. You build it, program it and install it. At the other, its a system installed (usually when your house/office/building is built) by a specialist company who then spend a huge amount of time setting it up, and then they return to it every time something needs reconfiguring.

glueWhat is there in the middle?

There are a large number of specialist systems utilising use of cheap micro-controllers which are designed to cover one specific task pretty much in isolation. Some of these systems even do a good job. Their designers then build their own web-enabled extensions so that you can install their app and visit their website to interact with their heating controller/aircon/solar controller/energy monitor/etc./etc.

Something is needed to glue all these different systems together or replace them. But most importantly, any system system must be able to be operated (and configured) by the user. If your partner/wife/mum can’t work it, it’s pointless.

Beyond the ‘lazy man’s light switch’

light switch
A lot of what is classed as ‘home automation’ is nothing more than ‘the lazy man’s light switch’. In other words, a remote control so you don’t need to get up off your bum to switch on a light or some other device. This type of thing has been around for years.

But is this really automation?

Well, after you bought the plug-in remote switch and the remote control, you can buy a box which will allow you to switch on the light by turning on your computer, visiting a web page and pushing a button.

Then the manufacturer releases a feature which allows you to connect your box to their ‘cloud service’ so you can turn on your light from anywhere in the world. Amazing, but still not actually automation.

But, lets go back a step. What we have here is the evolution of the building blocks which can make proper automation – smart building automation work.

Firstly, we have the devices and sensors – the things which collect the information and operate the devices. We have some sort of computer to do the decision-making – “turn the lights on when its dark” or “water my plant when its dry”.

Then we have the internet. This allows us to turn on the heating before we leave work, but actually could allow the home to know what we are up to and decide when the heating should be on.

So – what sort of system controls all these things? Does it even exist? The answer is yes – but it seems only if you fall into one of two groups of people. The super-rich, or geeks.