Home Control System (HCS)

The purpose of the Home Control System (HCS) is to monitor and control the main features of our home, to improve its efficiency and to reduce its environmental impact. An important aspect is also the user experience. The HCS is designed to overlay the existing infrastructure of our home, to be totally intuitive and not at all intrusive. This means that there is no obvious physical presence of the HCS in our home, other than some additional switches for automated curtains. Everything else, including the light switches work as you would expect.

The HCS serves three main functions:

• Security and safety monitoring.
• Efficiency of space heating/cooling, water heating and lighting.
• Monitoring external environment and weather.

The HCS is under continual development and is being tested out in our current home. It is built using open source software (mainly Java) and runs on a mini-ITX PC, which uses very little power (typically <12W). For the first six years, this machine ran the Windows 2000 operating system and performed flawlessly. In 2010, we upgraded this machine to the Windows 7 operating system, mainly because Windows 2000 was no longer supported by Microsoft. This upgrade required us to install more memory (now 1Gb) 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. I'm confident that everything we have done could be acheived using a Linux OS too. The HCS PC interfaces to various bits of hardware, which are described in the following sections.

The main reasons behind our approach are:

1. Off the shelf, low cost, low power and reliable hardware.
2. Not tied to any one operating system.
3. It provides a totally flexible and extensible platform, which is not tied to any one hardware or software vendor.
4. Can handle multiple automation technologies simultaneously (a hybrid solution).
5. Can be easily programmed to support complex functionality, as well as hardware groups and interactions.
6. Individual automation technologies can be swapped out for new ones.
7. Multiple USB or serial port interfaces are readily available and can be used to interface to any home automation technology.

The HCS itself is actually a collection of Java processes, using interprocess communication at the socket level. This allows us to wrap any technology an abstract away the complexities of the hardware and drivers, exposing a simple, real-time, event driven services at the core. What this means is that we can use any home automation technology and more importantly the best one for each specific task. It also means that we can combine multiple technologies and get them to work seamlessly. Right now, our HCS is using X10, 1-Wire, USB IO, Ethernet IO and we are planning several others. As technology changes we can swap old ones out and new ones in.

The HCS has been developed on the back of many years experience doing real-time systems design, working with real-time operating systems and mission critical systems, whilst working in defence and communications companies.

House Status

As previously mentioned, our HCS is written in Java and models our home, its context and the rooms and main objects within them. The house itself has three states:

• In - Someone is at home.
• Out - Nobody is at home, e.g. at work, school, etc.
• Away - Nobody is at home and won't be for some time, e.g. on holiday.

Alarm

The alarm status has one of two states and this is used to drive two sounders ('Internal Alarm' and 'External Alarm') based upon the house status:

• On
• Off

The alarm sounders are used for both intruders, fires, etc. When the house is occupied the internal alarm is generally used but, this depends upon the cause of the alarm. When the house is unoccupied the external alarm sounder will also go off. The HCS also has the ability to send SMS messages. It will send an SMS alarm when the mains power is interrupted or when a temperature sensor alarms.

Zones

Each zone (room) also a number of attributes:

• A door sensor (open or closed).
• A temperature sensor (some have more than one).
• Occupied (true or false) - depends on whether someone is detected in the room or not.
• Persistence - Detected occupancy also has persistence, configurable for each zone. This is basically the delay between last detected activity and the zone thinking it is now unoccupied.
• Profile - in addition to the detected occupancy, each zone has profiles that enable programmed heating and lighting based upon day of the week and time of day.
• Usage - A flag which stores whether the room is in use or not. This enables detected occupancy and profiles to be ignored.

Space Heating & Cooling

The combination of the house and room context leads to each room having two target temperatures based upon occupancy or lack of occupancy. Control is only possible on a per room basis, if each individual room has a temperature sensor. These sensors are also used to detect fires and an upper limit is set to signal alarm points.

Water Heating

Traditionally, water heating and space heating systems are linked, often by the same boiler. Whilst this is a cheap solution it is often very inefficient as there is little connecting between the two in terms use throughout the seasons of a year and even the time of day. Our HCS models water heating as a separate and isolated capability and also supports the concept of multiple water heaters and hot water tanks. It assumes that there may be many heat sources available such as solar water heaters, ground source heat pumps and electric heaters.

Lighting

Lighting control via the existing wall switches works as expected. Lighting in each room can also be based upon detected and/or programmed occupancy. Room lights can be configured to come on automatically at night, when occupancy is detected and the brightness can also be controlled. Lights can also be switched off automatically if there is no programmed or detected occupancy. These use profiles to achieve this. There are many other types of lighting in our home though.

Curtains

As part of the security system, automated curtains will be closed when dusk is detected. To avoid large load spikes, each pair of curtains is closed sequentially.

Security & Alarms

Our HCS also monitors security of the house using PIR and other sensors in each zone.

Services Usage Monitoring

The HCS will monitor and record usage of electricty, water, etc. It also monitors availability of power, Internet network connections, etc.

Security Images & Video

The HCS will capture, store and share still images and video clips from cameras.

User Interface

The HCS user interface is covered on a separate page.

Architecture

The HCS architected to be extensible to a wide range of existing technologies and new ones as they emerge on the market. This approach also enables us to test out new technologies, to assess their benefits and performance.

Each technology is integrated into the overall HCS design by using a real-time Java process to 'wrap' it and then expose it using socket layer communications.

The HCS is a number of processes that perform real-time communications using inter-process messaging. These structured messages or events are driven by external sensors and sensors networks, in-built clocks and timers and hardware controllers:

HCS

This is the core process with the main intelligence and logic. It is event driven and waits for messages to arrive from the other processes.

All of the processes log debug information and key events.

Clock

As well as dynamic event driven messages, the clock process sends regular 'heartbeat' messages to the HCS process at the start of every minute.

1Wire

This process polls the Dallas 1-Wire sensors on the network and reports any changes back the HCS process, in structured messages.

X10

This process managed the X10 PC to mains interface and accepts action messages from the HCS process. There is no reporting back to the HCS process because the X10 protocol does not really support the monitoring and status polling of X10 modules. This has been removed from our system now and replaced with Z-Wave technology.

USB

This process manages the USB I/O board, which appears to the HCS mini-ITX PC as another serial port. This board has both input and output capability, so the HCS can send commands to this process as well as receive events from it.

Ethernet

This process manages the Ethernet I/O board, which uses a bespoke UDP protocol over the Ethernet network.

HCS Events

As described above, the HCS is a number of processes that perform real-time communications using inter-process messaging. These structured messages or events are driven by external sensors and sensors networks, in-built clocks and timers and hardware controllers. Initially, the messages were sent as serialized objects. To facilitate a number of web apps (run on iPhone and iPod Touch) via Apache web server and PHP and to allow these to communicate directly with the lower level processes, the messages were simplified to strings. PHP does not support the sending of objects over socket level communications.

HCS Database

A database is used maintain persistence of states, enable event logging and to enable status sharing and distribution.