Smart Home Control System (HCS) Architecture
The basic premise behind the architecture for our Home Control System (HCS) is that it is a single logical entity that maintains full view of our smart home context and state. In order to achieve this, we have created a system that uses multiple processes and threads to receive and process all significant events with minimal latency. Even though our smart home control system is one logical entity, it is physically distributed across several processors.
Our distribution model uses the concept of a single master HCS processor supported by a number of slave HCS processors. The master effectively delegates and slave HCS processors are obligated to report back all significant events, in the same way that each dumb sensor does.
The slaves HCS processors are not an essential part of our architecture. Our home control system has been working perfectly well for many years without them, using just the master HCS processor. It is only fairly recently that we have extended our architecture in this way, to support much more advanced automation throughout our home.
This architecture is based upon a star IP-network topology at the highest level, with each slave HCS processor also employing a star network of physically attached sensors. This reduces wiring to remote locations in our home down to a minimum number of cables. The architecture works well in our current home but it is designed to easily scale up to the largest of homes, including those compromised of many physically separate buildings.
Distributed processors are given the freedom to make some local decisions that relate to their location environment and zone only. Typically, this includes all sensors but where multiple sensors are used, only an average may be reported back as an event.
One major feature that slave HCS processors provide is the ability to collect data from many sensors and only report back the significant changes as events. This massively reduces the number of events passed to the master HCS, whilst maintaining very low latency, good accuracy and high resolution data.
Each distributed processor basically needs just two things:
- 12V power supply from our 12V UPS
- Network connection
These may be combined by utilising Power Over Ethernet (POE).
Each distributed processor sends a regular heartbeat message back to the main HCS processor and it takes action if these do not arrive. Each distributed processor also monitors the local voltage seen (checking voltage drops are not significant). We are also looking at some local power storage capability in case the power supply is disrupted.
Our approach effectively rules out the use of and need for 'smart' sensors, which are typically vendor specific, isolated islands of functionality, which rarely have a well defined and open API to expose their data to other systems, such as ours. Each of our slave HCS processors could effectively be considered a smart sensor cluster.
Distributed Processor Examples
These are the main slave HCS processors that we have deployed or are in the process of deploying. We are also investigating the use of them to manage our bathrooms.
Our conservatory slave HCS processor is our second slave implementation. It handles the climate control and security. It has various occupancy sensors attached and a camera module. It has temperature sensors at three heights, to decide if the ceiling fan should be switched on to minimise the temperature gradient from floor to ceiling. It also has a humidity sensor.
Smart Front Door
Our smart front door project was our first implementation of a distributed processor. The main things that it provides locally are an IP-networked camera for still images and video capture and many digital and analogue inputs. All digital and analogue sensors changes are processed locally and passed on to the master HCS processor if important.
This is a project still in progress.
Our architecture enables our single master HCS processor to maintain a single instance and interface to our database, maintaining optimum performance.
Processes running on distributed processors create their own log files and these are used for test and diagnosis. There are synchronised back to the master HCS processor so that they can be processed.
We have both real-time synchronisation and scheduled synchronisation happening between the slaves and master HCS processor. Log files are synchronised at a scheduled time. Images and video are synchronised using directory change notification, to ensure they are copied to the master HCS processor straight after capture.
HCS Master Processor
Our master HCS processor is a very low power mini-ITX PC running the Debian Linux operating system. The main difference between this and a Raspberry Pi is the addition of a hard disk for storage of data, images and video. It also runs a cloud storage synchronisation client, an FTP server and the Apache web server.
HCS Slave Processor
We are always trying our new technologies but for now, all of our slave processors are implemented using Raspberry Pi computers. All of our deployed slaves also have an on-board camera module for image and video capture.
The Raspberry Pi enables a lot of functionality to be built into a small box and at a low cost. Each deployed slave processor typically costs between £80 and £100 including processor, SD-card, power supply, I/O boards and numerous sensors. This compares amazingly well to the price of an individual wired and wireless sensor from many of the mainstream vendors. We are using off-the-shelf components that are easily replaced and upgraded.
We have a 'standard build' for these slave devices, which supports 8 analogue inputs (using I2C) and 16 digital inputs or outputs. Using this standard build and a well practiced and documented build process means we can have a new one up and running from boxed components in less than an hour. We use an SD-card of at least 8MB capacity. Where we expect many photos and video to be captured, we use larger capacity cards up to 32MB.
We have designed the slave processor and the software that runs on it to be able to handle network disconnections. It will also report anomalies with sensors. It generates a local log of errors and warning, which are synchronised to the cloud when it is available.
Each slave processor also does a significant self monitoring. This includes things like CPU load, CPU temperature, case temperature and disk space used. These things can generate events, resulting in alarms. We have written some Java classes to enable this.
Each slave processor generates a local log file each day and these are synchronised back to the main HCS processor. A summary report is emailed to us at the end of each day too.