I've put the current list of goals (culled from past posts) and documents
we need to write (which I made up) on http://ha.ro.nu/official/ and
dissected it below as I have made comments on each point. I've added
two more links to http://ha.ro.nu/links/ and tried to link us to
the Home Automation Webring. The mirror to Rick's site is working at
http://ha.ro.nu/contrib/ so feel free to contribute stuff to rah.at.atdot.org
(or me, robin.at.acm.org).
This has turned in to a long and rambling post I composed over several
hours. It helped me get many of my ideas worked out as I was going along,
so please forgive the length and any inconsistencies. If anyone wants
to reply, *please* don't quote it all! If you fancy summarising it,
that would be great:-)
So, the list of goals:
> * open standards (no proprietary protocols)
This may be more philosophical than practical, but I have an aversion
to using standards where the body setting the standard wants me to pay
for it. They might not want much money, and if it is a good standard,
it might be money well spent for the effort they put in to designing it,
but it still rankles. I would rather make sure that anything we dream
up will be available to anyone who is interested, and that means only
adopting existing standards if they are free, or making up our own.
How free do we want stuff we publish to be? We could place everything
in the public domain. That way, anyone can do what they like with
our ideas, including making products which implement the protocols.
That would be nice. But it does mean that someone could modify it *just
a bit* to make it incompatible and sell it as a proprietary system.
I can't actually see that happening, as it would be further fragmenting
an already very fragmented market, but it is possible. To guard against
that, I think the sentiment expressed in the GNU Public Licence is more
suitable---you can do whatever you like, but if you make changes you are
obliged to share the changes so everyone else benefits. It has a certain
quality of fairness that appeals to me. I don't know if the GPL can be
applied to the sort of things we are planning to produce; certainly it
makes some statements with words that don't fit too well to our situation.
I certainly don't propose we get lawyers in to redraft it though. I
vote we adopt the GPL in spirit and hope we never have to put it to
the test.
How free do we want stuff we use to be? Well, again I have an aversion
to software that I have to pay for. Not because I can't afford to,
but because it usually means that I'm not fully in control and at some
point I'll come unstuck when I find something that doesn't work the way
I want it to. So I use free software, from the operating system up to
the applications. It's sometimes a bit awkard, because I live in a world
where most people seem to think proprietary systems are the norm, but
most of the time I think I'm better off. So I think that with anything we
produce we have to make it *all* available. But that means that we can't
use anybody else's commercial C libraries or real-time operating system
in the end product, and we shouldn't even use any proprietary tools in the
design process if someone following the project couldn't avoid using them
to get to the same place. Mostly that just rules out some sorts of
document files, since there are almost always free tool to do anything
useful (I don't actually know of any free PCB auto-routers though...).
The line gets more blurred the closer you get to hardware though. One of
Rick's suggestions was to use the BASIC Stamp controller. Because I
don't have the source to its innards, I'm wary. But go another step to
the 68HC11, which I use all the time, and I'm quite happy, even though I
don't have the microcode it runs. I suppose it comes to a point where
I can't imagine wanting to redesign what's inside, and at that point
I'm happy to buy it off the shelf.
> * safe (won't hurt people or appliances)
Although I dabble in electronics, I don't know enough about handling
mains electrical design. What I hope we can do, with the expertise
of other group members, is design some simple modules to do all that
stuff safely and hide it away behind opto-isolated I/O. Then anyone who
wants to control their lightbulb or TV or even electric fire can just
pick a suitably-rated module design and use it with any microcontroller
(or PC come to that) they find most convenient without worrying too much
about the mains stuff.
Ideally, I'd like to have all the control units dotted about the house
not have any mains stuff inside but do all their communication by a
dedicated bus that also supplies low-voltage power. However, that is
a bit impractical in most existing homes (including mine), and there
is all that tempting pre-installed mains cable, so another addition to
my wish-list is that we come up with a similarly safe, isolated, mains
communications module.
Another safety issue is that devices should only be switched on when
they are supposed to be. That means some sort of robust error checking
on the protocol, and maybe some additional guards on how easily certain
items can be triggered. This also extends in to areas of what might
be called ``security'': can someone outside subvert your system?
How much of a threat is this? If you share a mains supply with them
they might do it inadvertently. If they set out to cause trouble,
should the system try to protect you? I think it should to some extent,
but to what extent? For instance, requiring that every command packet
be cryptographically signed might be going a bit far, but that each
one have an increasing sequence number would be quite sensible.
> * robust (will cope gracefully with failure)
This is a hard one to quantify. Most of the equipment in my home at
the moment has very simple failure modes. Most devices are either
switched on with switches right next to the power outlet, or by wall
switches maybe a few metres away connected by one thick copper wire.
There isn't much that can go wrong there, so it is going to be impossible
to build stuff that is as reliable as what I have now. I know that,
so I'm prepared to put up with the possibility that sometimes I won't
be able to switch the light off. But one thing that is generally true
now that I would like to preserve in our design is that failure of
one item probably won't affect anything else---even if I can't switch
the light on, I can work the garage door opener. This really rules
out *any* sort of central decision-making device, since its loss would
have widespread consequences. Perhaps a multiply-redundant ``central''
control system might be OK; one where each controller could take over
all by itself if the communication medium gets partitioned, and where one
controller can be outvoted by the others if it seems to be acting oddly.
That's pretty complicated though, and complicated things tend to have
lots of ways to fail in complicated ways. I would still prefer to see
each group of coupled items being able to get on all by themselves.
Another aspects of robustness: physically the modules have to stand
up to day-to-day wear. I expect the prototypes will be lashed up from
whatever bits and pieces make it work, but in the end I want everything
flush-mounted or in nice solid boxes. It needs to be proof against the
sort of hazards that get about in houses: condensation, paint, vacuum
cleaners, dusters, impact with people, pets and other objects.
> * can be built by a keen hobbyist with little or no special equipment
If I call myself a keen hobbyist, I can assume that a multimeter,
oscilloscope, signal generator, soldering iron and (of course) PC are
about the limit. I can't make PCBs and I don't have anything for dealing
with EPROMs. But as I've mentioned before, that doesn't necessarily
mean that we can't use PCBs and EPROMs since other companies (or group
members) can supply these services. Still, I would rather avoid anything
I can't build on plug-in breadboard or stripboard in the early experimental
stages, which means no chips that only come in surface-mount form.
> * modular (will operate without central control)
I have already touched on this in the robustness discussion. I don't like
the word ``modular'' for this concept anyway; to me, that carries other
connotations that are mentioned in the ``safe'' section (the black-box
idea) and the ``extensible'' section further on. I think this point
should drop the word modular and just state what it says in the brackets.
What it boils down to is that most devices should be able to get along
just talking directly to the other devices involved in their local
control loop.
> * simple (can be operated by someone who doesn't know the system)
Again, this is more complicated than it sounds. There are many ways to
interact with the system. I will be tinkering with its innards and expect
to be able to do so with reasonable convenience. Visitors will just
expect the light to go on when they press the light switch. Designing
a ``simple'' interface which does both those things might be hard.
Do the uninitiated want to be able to use the bedroom light switch to
open the curtains? Probably not. But I might want to do exactly that.
I think there has to be some compromise here. The basic controls must
closely resemble the controls that existed before. Even small changes
can be devastating. For example, I installed a touch-operated dimmer
switch some time ago, and my father still cannot operate it reliably
(it needs a short touch to toggle on/off, and a longer touch to adjust
the brightness). So I think that I (at least) am stuck with having real
switches that go click for him. But I want to have a touch-screen LCD
panel with selectable status information and a simple way to control
arbitrary devices. I don't know how to achieve that yet.
> * extensible (can accept all kinds of new device ideas)
This, I think, is the crux of the matter in many ways. All the existing
systems seem to be very inflexible: one communication medium; one (usually
simple) protocol; only a few device types. I know there is a danger that
making things too extensible makes them bloat and become inefficient,
but I think there is a middle ground. But for a counter-example, look at
the Internet: there are many different mechanisms for shifting packets about,
and the packets mean all sorts of different things but there is only one
IP protocol and it is both simple and efficient. I'm not necessarily
suggesting we adopt IP---it had different design goals after all---but it
does show that a multi-layered approach can be both flexible and efficient.
Each layer worries about one aspect of communication, but has a small
and tightly-defined interface to the layers above and below it. That
way, the protocol stack can be built up out of the interchangeable pieces
best suited to the particular situation.
At the very bottom layer, I can easily think of several sorts of
transport. I already mentioned using the mains wiring or a dedicated bus.
I experimented with 418MHz radio and found it works over adequate range
through walls and ceilings. Infra-red is great for short-distance,
high-bandwidth stuff, and my house already has a fair amount of ethernet
around it. So I feel we should support all these at least. Obviously we
will have to lay down some general guidelines, like the node addressing
and the largest and smallest packets that must be accommodated , but
on the whole we can regard the modules that implement this layer as
conceptual black boxes: all that flows in or out is a stream of packets.
The implementation may even work like this in reality, with a module
having all the necessary control logic inside to look after its low-level
transmissions and just a serial port as the up-stack interface.
This seems easy and neat.
The next layer up can depend on getting packets where it wants them,
but it has to worry about where they should go. Information flowing
could be directed to a specific target or broadcast. The scope of
the broadcast would have to be limited somehow, bearing in mind the
possibility that the system might contain many different types of
intermingled communication paths. There are many difficult issues here.
I should think that it will be essential for all our devices to have
a unique address, but that is not necessarily enough. Devices and the
services they provide might be both mobile (consider a lamp: it might
always be addressed as ``the daffodil lamp'', but it sometimes it might
also be ``the right-hand bed-side lamp'' while at others it might be
``the extra light in the hall''). All three addresses make sense and are
appropriate in different contexts. I don't know how complex we should
get here. There seems to be more complexity the more I think about it!
Routing the packets seems like a really difficult thing to do optimally.
The idea that we can support many different types of device is somewhat
problematic since we don't know what sort of services new device types
might provide or require. The most basic service could just be offering
or receiving data. Most devices I can think of are either sensors which
produce boolean or numeric data, or effectors which act on boolean or
numeric data. But even that simple categorisation is inadequate as
many items are a mixture of both; for example, a sensor that needs to
be told when to take a reading, or an effector which has to report on
its progress towards a desired goal. We also need ``decision-makers''
which can listen to data from several sensors and emit commands to one
or more effectors. Decision-makers could be physically part of sensors
or effectors or both, or could be quite separate. Extensibility and
modularity are better served by having them separate, but robustness
is improved if the decisions are made close to the site they affect.
Perhaps the best solution is to do both: build some simple decision-making
in to all devices and have some extra cleverness in dedicated units.
> * does not need a PC for normal operation
What is normal? Is that qualification even correct---should it just say
``does not need a PC''? I think so. The PC, if one is present, is only
there to bring another interface to the system. It can monitor and
control everything if desired, but we don't have to do anything special
to enable this to happen---it just comes naturally from the modular
communications and the flexible packet addressing and routing.
> * easy to install (no need to run new wiring everywhere)
Already covered: this means having a mains or radio communication option.
Those who are able to run new wiring should be able to take advantage of it.
> * low cost for most modules
I've mentioned this before in an earlier email, so I won't go on about
it. I think most people would be put off building a system if the
bread-and-butter modules (which I am regarding as the mains power and
light controllers) are too expensive. The cost of more fancy devices
doesn't matter as much because there won't be nearly so many of them.
> * can be controlled by dedicated units or a PC
I think this is a superset of the earlier point about not needing a PC.
It does have an implication that I have assumed so far but not mentioned:
that all the devices can (at least potentially) talk to each other.
> * supports programming for automated operation
This is getting at the idea that several input data can be used in
deciding what action to perform. The form of programming governs how
complex the automation can be. I envisage some simple ladder-logic or
state-machine scheme that could be input with a few buttons and an LCD.
I think that would be adequate for most purposes, and anything much more
sophisticated would probably be best dealt with by a real programming
language (which could be running on a BASIC Stamp or even a PC).
What do we actually want to support here? Can someone start a list of
applications, then as we propose ideas we can check them off against
the list to see if they are general enough. I'll start it off with
a few of the ideas I've touched on in this post:
one wall switch controls one light
one wall swicth controls two lights
two wall switches both control one light
one dimmer switch controls one light
one dimmer switch controls two lights
two dimmer switches both control one light
thermostat governs electric fire
morning programme opens curtains
dawn-dusk sensor triggers random lighting pattern around house
approach of car opens garage door; timer, beam-break safety sensor
and motor stall sensor close it safely
Phew. Well that took longer a bit than I expected:-) Thank you and
goodnight.
Robin.
-- R.M.O'Leary <robin.at.acm.org> +44 7010 7070 44, PO Box 20, Swansea SA2 8YB, UK