Resilient Smart Home Control
Our Home Control System (HCS) has been running since 2004. It has been extremely reliable but, in 2011 the mini-ITX PC that it runs on had a hard disk failure which meant it stopped working. This was the first and only unscheduled down time. It took nearly three hours to rebuild the machine with a new hard disk and get our home control system operational again. It then took another few days to do install all the operating system updates and patches.
The whole process was made much simpler by storing all source code and configuration files in cloud storage. We also have backups of all the software needed stored in our firesafe.
Our chosen architecture means that our smart home has one central processor with all the intelligence that is making all the decisions. This is the right way to do it in our view as it enables a complete picture of the smart home to be used when making decisions and the full context to be considered. Never the less, this approach does mean that the central processor is a single point of failure.
There are number options to address this situation:
- Use a cloud-based HCS - we ruled this option out very quickly as introduces the network as another point of failure and this is not very reliable.
- Use a distributed and resilient processor to run the HCS - this is the subject of a project next year.
- Use a hot-standby processor - this is basically a copy of the HCS that is powered up and ready to run if the first should fail. The advantage of this appraoch is the ability to potentially automate the swap over.
- Use a cold-standby processor - this is the approach we are adopting for this project and is also referred to as N+1 redundancy
We have also been doing a number of projects using the Raspberry Pi and saw the opportunity to port our Home Control System (HCS) software across to this device and migrate from Windows 7 to the Linux operating system. This should not present any major technical issues as all of our code is written in Java and Java on the Raspberry Pi is now well supported.
One advantage of a cold standby processor is that it can reuse the same IP address. This means we don't need to reconfigure other elements (such as Ethernet I/O) that send messages to the fixed IP address of our processor.
The Raspberry Pi requires a 5V dc power but we have used dc-dc converters in many situations. The Raspberry Pi (model B) uses considerably less power and is also fanless (silent).
USB Ports & USB Hubs
Our mini-ITX PC has 4 in-built USB ports, leaving 2 spare after a keybord and mouse are plugging in. One of these is used for our USB I/O board and the other for a USB pendrive on which our HCS logs and database are stored.
The Raspberry Pi has just 2 USB ports, so a USB hub is also required. There is no hard disk, so we could use the SD-card for storage of log data and for the database. To keep things swappable, we use the same USB memory stick.
USB Memory Stick
A quality USB memory stick was used to prevent a continual stream of writes to the hard disk and thus prolong its life. This has been proven to work really well. We have also re-written our database to reduce the number of writes to the USB memory stick, which has been in use for over 8 years. The previous days daily log is copied to cloud storage just after midnight, so that no critical data will be lost should the USB memory stick fail. There is no real point in replacing this device until it actually fails.
T.B.C. - Sorry, still writing this project up.