[ADVERT] WebBrick architecture and approach

["andythirtover" <andy@xxxxxxxxxxxxx>]

Dear[est] Group

An enthusiast's guide to a real world affordable approach to home
automation
Andy Harris, CTO, O2M8 Ltd <a href="http://www.o2m8.com";> o2m8
</a>

Article Source [with layout] at:
http://www.o2m8.com/modules.php?name=News&file=article&sid=11

I believe that this should count as a 'one per month advert'.

Regards


Andy


An enthusiast's guide to a real world affordable approach to home
automation

Andy Harris, CTO, O2M8 Ltd

This article was written to help home automation enthusiasts
understand the O2M8 approach. It outlines our architectures along with
discussion of some real world and hardware considerations.

We feel that the current approaches to home automation fall into two
camps:

The multi-millionaire approach -- Whole houses are gutted, structured
cabling installed, decorated and many hours spent programming esoteric
equipment.



The X10 style approach -- Retrofitting at the 'socket' level



Its as if the whole mid range market is missing. The
multi-millionaires will gut and refurbish as a matter of course, this
allows the time and access to wire all cables back to a central
utility point.

The retrofit is a do it now, finish in two hours, no decoration approach.

The closest guide we have to what might happen in middle market is the
activities of the home automation enthusiasts. These are the people
prepared to take a room apart themselves and build in automation. Even
these fine souls find themselves under pressure when they want to sell
their homes due to Part P testing and the need to handover the
controls to a new owner.

In real world homes, rooms get decorated one at a time. This doesn't
give the opportunity to cable back to a central point. Before O2M8 Ltd
was formed I found myself pondering these issues and investigating the
market for suitable products. I had several home automation people
round to make quotes, these as the reader might guess were
astronomical. I'm a bit of a film fan, and in honour of 'Wallace and
Gromit' and 'Thunderbirds' I wanted a sofa to rise out of the floor.
Its the only folly I wanted, I got quotes from 6K to 25K and a real
feel that the companies didn't understand the engineering issues.

I'm an engineer at heart, and life's circumstances meant that I had to
mostly stay at home to look after my two children. I realised that I
could the home automation myself for less than the cost of a nanny!
Therefore I set to thinking about the principles of home automation as
it applied to real world homes. Since I started work years ago as a
power station instrumentation engineer, I wasn't worried about the
electronics and hardware. I'm CTO of a software company so I know a
few software architects.

A good friend of mine is Graham Klyne, a veteran of many an internet
RFC, and a guiding light of the semantic web. I drove over to see him
and much pacing about a copious tea later we (he) come up with some
useful principles, the first of which was:

Local Control -- Global Intelligence




Its so simple but such a useful design principle, it really helps to
guide software development when you get to those jobs where there are
several ways of achieving the same thing.

In essence it means that we need a controller that gets a local job
done under local control; But with guidance from global intelligence.
This means if the global intelligence is not available, local control
is still valid. One of Graham's mantra is "Missing doesn't mean
broken!".

If we transfer this to engineering principles we know that solid state
components are far more reliable than disk drives. We also know that
Microsoft systems are inherently 'extensible' with viruses and
spyware, and that Linux is not immune from a nasty dose of RootKit,
and cables get damaged ....and ....and.

Therefore I set about creating a fairly small component that could be
used on a one per room or one per subsystem basis. Three years ago I
called this my WebBricks.

So the principle of a WebBrick is that it controls a local room or
subsystem, and keeps it safe no matter what global intelligence tells
it to do. Take for example a heated floor, The WebBrick might use one
state machine to dwell the heated floor for say 2 hours. Another state
machine might switch the floor off at 28 deg C. This also shows
'action' precedence, a off action will override a dwell action.
Therefore even if a central intelligence program called for the
heating to be on, the WebBrick would ensure that the temperature did
not go about 28 deg C.

A WebBrick consists of a loosely coupled embedded web server and a PIC
chip. The design principles being that a denial of service incidence
for the web server should not mean that the PIC fails to do its job.
For the software principles I was back drinking more tea at Graham's.

Graham and I both understand network protocols at the standards level.
We can read through BNF and state machine diagrams to see it a bit of
kit or code is compliant. Graham used these ideas to explain:

Deterministic State Machines




This is vital to any system that has global intelligence. In that the
programs that make up the global intelligence rely on the local
controls to get jobs done. Therefore the local controls must be
deterministic, in that if you know the state machine parameters, you
can accurately predict its behaviour. An important corollary of this
is that the local controls become very easy to replace. If for example
you have special case programs running in the local controls, you'd
have to reload those programs when you changed the hardware. This
sounds simple enough, but in the real world it is absolutely not. Home
automation consultants shift from company to company, companies get
bought and sold and a year or so later no-one can remember where the
code was and if they have, have they got the version of the software
to compile it?

None of this matters to the top end market, they get a new one, and a
new programmer whilst they're at it. But to the rest of us it really
does, component replacement is vital.

The WebBrick state machines have a very simple table based configuration:
Trigger Number

Type

Action

Parameters

UDP Notifications

0-7

Digital or Analogue

On-Off-Dwell-DwellCancel-Toggle-Momentary-DMX

Set point or Delay

General-Remote-Alarm



These tables cane be seen by browsing directly to the WebBrick, or by
collecting in an XML format. People can look at the web page and
programs can interpret the XML. This means that the deterministic
behaviour can be transferred to the general programming environment.
By doing some special programmer stuff (RDF and inference) it is
possible to inspect the configurations of many state machines across
many WebBricks and work out what the interactions between elements of
a system would be.

Adding the global intelligence

Once you can be sure that local systems will look after themselves its
time to think about how the global intelligence will function. In the
O2M8 architecture the global intelligence can come from just about any
type of generic computing system. We started with Python interfaces
and then went on to PHP. Its important for the reader to know that we
haven't forgotten Java - its great too.

Python is very well suited to command line and background processes,
whereas PHP is well suited to creating web based interfaces.

The fact that we chose web based interfaces is down to our belief that
HTTP and HTML are universal, and that prices of screens will come down
significantly. In fact, already we are seeing IEEE 802.11 equipped
PDA's at near one per room pricing. Of course should should consider
the PDA as only one of many choices for creating user interfaces.

Perhaps more useful and more reliable than PDA's are the range of
mini-linux systems that are available. These can be combined with
touch screen TFT technologies (particularly those for car usage) to
create robust and rich home interfaces.

We should never forget the humble switch plate. With the UDP
notifications built into the WebBrick it is easy for
'global-intelligence' to read buttons. UDP is particularly useful
since it is effectively a 'local' broadcast. This means two things:

WebBricks do not have to be configured to send button events anywhere
in particular

Multiple systems and programs can respond to the same button events



>From these properties, and knowledge of the state engines we can build
resilience. For example it would be simple to have two how gate ways
systems performing exactly the same functions. For example, when
button 'b' generates a UDP event, switch on selected lights in a
sequence, wait 5 min's and switch them off in a sequence. It does not
matter to a particular WebBrick that it receives two 'ON' commands in
quick succession. Building on generic protocols

There is a lot to be said about this. At O2M8 we're lucky enough to be
working on some of the wireless protocols that may form future
applications. However on down to earth basis there are protocols and
equipment based around DMX that make for rich, robust and inexpensive
lighting control systems.

This is why we've created DMX Passthru and gateway functions within
the WebBrick as well as a direct DMX command for local control. This
allows scenes to be chosed both from a wall plate and via global
intelligence. This is the kind of functionality we used in our
EggNunciator product so that ambient lighting can tell you something
about what's happening in and around your home.