Articles and whitepapers

PC-based Home Automation (3/1/2006)

By Andy Harris, O2M8

It is a compelling a seductive thought - using a ubiquitous, commodity PC to provide the heart of a home automation system. There are so many things going for the humble PC that it is no surprise that people are developing PC-based HA (Home Automation) solutions.

A collection of PCs for home automation

These days HA means different things to different people. Many think that it is about home cinema, media serving and music in every room. Indeed HA has grown to cover these areas, but we need clarity on the differences in applications.

Mission-critical applications

In a more elemental control sense, HA applications include heating and ventilation, lighting, security and surveillance, access (doors), curtains and blinds, appliances, and custom projects.

As we shall see, you cannot mix mission-critical HA applications with media serving. Media applications are in a tremendous state of flux, with daily improvements and new joiners to the palette. These media applications are ideal for a home PC/client network, as we can now use a wide range of clients to play media such as Xbox and PlayStation, and the Nokia 770 Internet Tablet.

Heating applications however, are mission-critical in a household. The impact of messing about to play a DVD in the right aspect ratio and audio encoding is not the same as waking up on a Monday morning to find that the heating and hot water have not started because a PC is flat on its back after a Windows update.

PC reliability

If you think I am simply being provocative, let us examine the issues. The MTBF (mean time between failures) of a maintained boiler is about 18 months or 500 days. My main home Linux system currently has an uptime of 172 days. It was last down in order to have a very large disk fitted in order to handle both increasing spam and the family photo collection. I have an Apple G4 with an uptime of 22 days (it had to be powered off for a flight), however my Windows XP desktop rarely manages more than 5 days uptime - generally some application or other is demanding a reboot for critical updates.

It seems that no matter what the operating system, a general-purpose computer will not have the uptime required for mission-critical HA applications.

Failure rate of system components

Another drawback of the PC is that it generates heat. PCs have big power supplies, often with fans. Air that gets heated quickly loses its capacity to hold oxygen, which is why a room, with a continuously running PC, feels airless. In enclosed areas, the internal temperature of the PC will rise and considerably shorten the life of its disk drives. An excellent compromise for HA therefore, is a diskless system that runs from flash or USB-connected memory. Diskless systems are based around motherboards that have slots for compact flash (CF) cards. In software terms they are built on kernel-based reduced-application versions of Linux and Windows.

A final point about MTBF concerns networks. Mostly these are an extremely reliable combination of passive cables and solid state electronics, i.e. no disks to fail. Network 'switches' are systems with multiple internal 'backbones'. Systems that are connected to the same switch use these backbones so that no traffic leaves the switch, and so that multiple systems can network at full speed. 'Hubs' on the other hand, have one backbone and traffic is always passed on to the network. You might think that using network switches instead of hubs will protect your network from a rogue device. However, unrecognised packets and broadcasts get passed on by both hubs and switches!

If we want to use the humble PC and a network, the following are some considerations:

Recognising value and weaknesses

This is the way of good network and application architecture design; use systems for their strengths but understand their weaknesses. For example, if a PC can fail, use two, after all, they are cheap enough, but you will need an architecture that recognises that there can be peers rather than a master controller.

In essence if you use a single master controller, it is a single point of failure, and a routing point for all the HA messages. A peer can communicate with other peers and clients simultaneously. In a peer architecture, it is generally organised for all peers to see all the HA messages. Therefore if one peer fails, another can be designated to take its workload.

Local control global intelligence

Imagine that you have a PC which has every switch in a house connected to it, and which can control every device. Lose that PC and you have lost everything - you cannot even switch the light on to start looking for the problem!

Take that same PC, put it on a network, and connect it to a series of sub-controllers, each of which is looking after an HA application. Now you can get the PC to advise the sub-controllers, on the basis of 'this is the schedule now', 'open that garage door', 'boost the central heating in zone 3 by two degrees for one hour'. On this basis, if you lose the PC, all of the sub-systems still carry on doing their job, the only thing you lose is the 'global intelligence.'

Missing is not broken

Imagine that someone hunts around in the cupboard under the stairs and ends up dropping a ladder on the network switch, or ripping out several cables. In some HA systems, once the controller cannot see sensors it just waits forever. This is not good at all. Basically, a good heating system for example, may take feeds from several zone sensors and an outside temperature to optimise the run time of boilers or under-floor heating. Just because it cannot see the zone or sensor does not mean it cannot run, it just means that the quality of decisions will not be quite as good. This is a much better state of affairs than refusing to run!

Do not do mission-critical

If you are building a cinema room and you would like to put together some control sequences that are based on media selection, such as this type of song, that sort of lighting, curtains closed etc, then a PC system is perfect. In architecture terms, you are right on top of the driving application. For example, the Apple iTunes application is very good at talking to the outside world, as is the Microsoft MCE.

I have recently made some investigations into the programming interfaces for iTunes. It is very impressive and very open. Both iTunes and MCE have COM (object) interfaces for Windows. This means that you can make the link between playing music collections and the everyday controls of HA. So instead of having to find a remote control, or get to the PC to stop the music before picking up the phone, you can organise a simple pause/play button or even integrate directly with Asterisk (an open source VOIP exchange - see Asterisk@home at http://asteriskathome.sourceforge.net).

Here is an example of PlayPause for iTunes in just three lines:
import win32com.client
iTunes = win32com.client.Dispatch("iTunes.Application")
iTunes.PlayPause()

A serving suggestion

By taking all these principles, we can outline a HA scheme that uses them. For example, we could use a collection of O2M8 WebBricks to create the room interface and controls. The WebBrick is a process control unit with multi-input and -output capability along with a web-server and network interface for providing deterministic system control and monitoring.

The O2M8 WebBrick

The WebBrick will interface to something as simple as an MK switch. Each time the switch is operated it creates a 'trigger' which in turn can create 'actions' i.e. control a light. The importance of a simple switch cannot be underestimated - everyone who can reach a switch knows how to use it, and there are no complex operations for the cleaner! But because we are web-enabled, the triggers can come from the network. So we can install a 'global sleep' button by the front door. This can be organised to switch off all but entry/exit lights, and taking a green view, might relax heating set points by a few degrees for energy saving.

Using the WebBrick 'one per room' approach, scenes can be set for each 'use context' (e.g. a lighting 'mood'). So a cinema room in 'sleep' context might have all the lights set to OFF and the heating control valves operating at an 18 deg C setpoint. 'Pre-film' would have lighting at a low level, curtains closed and 21 dec C setpoint.

Turning to schedules, the heating system would have its own schedule, but with plenty of opportunity for user override. So although our cinema room might be asking for heat, it is not going to get it unless the global schedule for the boiler says so. User 'input' is key to energy saving, after all, it is the users who know if they are going to use a room or not.

So scenes would be set on a per WebBrick basis, so that each room operates independently of any global intelligence. The WebBrick looking after the central hating and hot water boilers may have its own schedule so that it too can operate independently, however that schedule might be continuously updated by global intelligence.

Network architecture using WebBrick and software

For global intelligence, we could use a pair of iDomus Harmony home automation servers that run on Windows. The beauty of this architecture is that both servers see the WebBrick events and both can generate WebBrick events. The Harmony servers would see the 'global sleep' event. They would then send the scene commands to each of the WebBricks. It matters not to a WebBrick that it receives two 'goto scene 1' commands in short succession, the outcome will be the same (known as deterministic, conversely, two 'goto next scene' commands would not be).

Who does what?

Homes change all the time, families change, parties happen. Therefore a system is needed that can adapt to all of these situations.

At the installation stage, it is the installer who knows which switches/appliances are connected to which I/O ports. Therefore the system should allow for this level of internal labelling. This is so that future installers can add to the system by following what is already there.

Initial configuration is generally done by the installer. What happens next is probably the single most important part of our industry Ð the handover. This should be made to the person who will look after the day to day adjustment of setpoints and schedules. More often than not it is made to the person who pays the bill, who just has not factored in the time needed for a proper handover!

As an industry we are quite markedly 'specified by men, used by women' (the hifi industry is similar). We need to make sure that we get the best of both viewpoints. Therefore, operations such as 'include the guest bedroom' in the global schedule need to be made intuitive. Using Harmony, a simple interface could be created to 'enable' the guest bedroom. 'Boost' is also important, i.e. push the setpoint of the guest bedroom up by 2 degrees for an hour, because just before the in-laws arrive, that room is going to get aired by opening the windows.

Children are also very important people. They can cause havoc, use far too much energy, leave stuff on and doors open. A system is needed to let them control what they need to, but either fix issues automatically, or let someone know. In my home, I have buttons for the heated floor in the family bathroom, these are configured as dwell-cancel for 45 minutes. This means that the floor cannot get left on. We have also built some 'Eggnunciator' lights that normally fade between pastel colours, except if the garage doors are open, then there is a full red in the cycle. These lights are in the hallway and landing and I can assure you that there have been many times they have saved me from leaving the garage open all night.

What is being suggested here is a layered approach. This allows the savvy homeowners to configure their own preferences. This is key to moving the HA market from a niche of high-income individuals to the wider market.

The layered approach to system configuration

Conclusion

As a tool for home automation, the humble PC represents superb value for money. It is flexible, adaptable and replaceable. The cautionary note however, is that it cannot be relied upon for mission-critical applications. PCs are good places to hold the knowledge about the people in a household, while sub-controllers are best suited to controlling the devices around the home in a way that is independent of any PC system. For a successful PC deployment think 'Local control, global intelligence' and 'Missing is not broken'.

Andy Harris is the CTO for O2M8 Ltd, provider of affordable and down-to-earth smart home systems for home builders, developers and renovators.

www.o2m8.com