Smart Home Control Systems

We started writing and developing our own smart Home Control System (HCS) because there simply wasn't anything available that met all of our needs at the time and this holds even more true now. What started out as quite a simple HCS, has evolved into something extremely powerful. The main reasons for building our own solution are:

• We simply wanted a HCS that delivered the best possible user experience. This along with improving our quality of life should be the primary objective of any HCS.
• We wanted our HCS to be technology agnostic, so that we had no dependencies on any vendor or eco-system.
• We wanted a hybrid technology, so we could use the best technologies available in terms security, reliability, performance, user experience and cost. Mostly this means using wired technologies but it also means we can swap in new wireless technology for old.
• We wanted a system that protected our privacy an kept ALL of our data within our home.
• We wanted a system with an optimal and distributed architecture, for best performance and resilience.
• We wanted a HCS were everything was tightly integrated, to enable a fully contextual smart home. This means we have one single coherent HCS, with one coherent user experience. Everything connected to it can be queried and controlled through all of the user interfaces where permissions allow.
• We wanted full control of the development path, timeline and priorities, to avoid the pitfalls of a HCS that has been "designed by committee" and to allow us to innovate rapidly. Where it makes sense, we use open-source hardware and software and integrate "best of breed" 3^rd party services and devices. We typically add and test new features every day, sometimes several.

A Bit Of History

We started designing and building our own Home Control System (HCS) in 2004, long before there were many consumer 'hubs' or smart home providers about like there are today. The first version was written in Java and ran on a low-power Mini-ITX PC, running the Windows 2000 operating system. It ran flawlessly for over six years as we experimented and extended its capabilities.

In 2010 we upgraded to the Windows 7 operating system, mainly because Windows 2000 was no longer supported by Microsoft. This upgrade required us to install more memory for Windows 7 to run with acceptable performance. The main reasons for choosing Windows 7 were the availability of drivers and our familiarity with this OS. In November 2013, we fully migrated our HCS to Debian Linux.

Our HCS really doesn't require a lot of processing power to deliver all of its core functions. It could easily run on a Raspberry Pi computer and be able to handle millions of events each day. It is only the advanced functionality that requires more processing power (e.g. visual analytics, speech recognition, face recognition, etc.).

What Does It Do?

There are many stages along the path that is the evolution of the smart home. All of the current consumer products on the market have a very long way to go along it. It is possible to have a smart home without a centralised home control system (commonly referred to as a 'hub') but it really won't be very smart. It basically provides the following:

• A local (in home) central point from which you can query and control everything in your smart home. It also exposes secure user interfaces to enable query and control from outside of the smart home.
• Some models of the smart home, its constituent parts and its users. These models make it much easier to configure and allow connected sensors and devices to inherit its capabilities and use its many powerful features.
• Intelligent automation of things within the smart home based on sensors, the people within it, the local context and environment.
• Control over all smart home data and its storage, to ensure privacy is maintained.
• A personalised user experience that enforces access permissions using a simple, common model, across all services and features.
• A single identity to enable consistent, intuitive user experience across a wide range of user interfaces.

If you find yourself in a situation where you have more than one 'hub', then this is not a home control system! What you have is isolated islands of functionality that do not share state information and context. This will also lead to a disjointed user experience spread across multiple, isolated user interfaces. This does not mean that it can't use a distributed architecture though.

Why?

We also have a separate section on why you need a smart home and its benefits. Most of these are only realised when an HCS is present. As previously stated, the primary objective of any HCS should be to deliver the best possible user experience and improve your quality of life.

Our current smart home is also a live test bed, in which we research and develop new features and capabilities.

Configuration

We designed our HCS from the outset to work in any home, small or huge. The use of technology abstraction makes it amazingly simple to configure quickly and no training is required to do it either.

Our diagnostics also gives real-time view of every sensor, device, associated controller, cameras and all the other significant elements of the HCS.

Insight

In the early days of developing our HCS we realised we need extensive activity logging, to understand what was happening in in our smart home and to gain maximum insight and learning. Because it uses technology abstraction, the extensive logs are both machine readable and easily understood by humans. It is really easy to see what has happened and when, with no confusing error codes! The logs give a clear timeline of ALL the important events.

Performance

Our HCS monitors it's own performance and will generate a performance report if any issues occur. If they are significant, it can also send notifications or make voice announcements.

We sometimes get asked a lot about reliability and whether the HCS is a single point of failure. Whilst it could be considered a single point of failure, the quality of hardware used and the redundancy employed within it means that this has yet to be an issue. Our current system has run for many years without failure. Because the hardware is based on standard, commodity components it is cheap. This means it is very simple to employ a cold standby.

We currently develop on a Raspberry Pi computer and run several instances in our home for testing purposes. It is very simple to configure one of these standbys to take over as our core HCS.