> The main controller sees this messages
> and plays the role of observer.
The advantage of this scheme is that there need be no main controller at all,
or there could be many ``controllers'' which are actually just observers
(or in the list of targets for the sensor, as justified above).
> Only for complex tasks and to program
> the switches (switches must learn what they should do), the main
> controller is needed.
Exactly. And there could be more than one ``main controller'', say
one per room or per area. These units could also act as routers
so the whole house need not be on a single communications bus. All
intra-room (or area/floor/whatever) traffic would stay local;
the controller would see and think about all the traffic and decide
wha, if anything, to route outside. The same concept could go up to
the house level if we ever net in to neighborhood-automation:-)
Although maybe not very practical, I thought of a way individual light
switches could be configured locally. Suppose the light switch can be
put in learn mode (by an extra button or by toggling/holding the switch
in an unusual way) and that there is a mechanism to find all the networked
devices of a particular type. Then the switch can alternately send ``on''
commands to half the candidate modules and ``off ''commands to the rest.
The user signals when the correct light has been illuminated by switching
the switch. Now the switch can eliminate the modules that it just turned
off, and repeat the alternation/elimination until just one module is left.
In my house, that would mean no more than 5 or 6 steps at worst, even if we
count the wall-socket-powered lights too.
Thinking of wall-socket-powered lights reminded me of a point I
mentioned earlier about addressing. Modules can have several ``names''
depending on their role. There is of course an absolute identifier,
which describes that particular physical module (e.g. ``lamp with the
blue shade''). Then there is the address of the socket in to which it
is currently plugged (``socket in the main bedroom near the window'').
Additionally, there is the logical function it is currently performing
(e.g. ``left-hand bedside light''). Now, a switch could be programmed
to target any of those three addresses. The first sort of address would
be useful if the module performed some unique and specific function that
only it could perform. The switch could then operate it anywhere in the house.
The second sort of address could be used to emulate the way that conventional
wiring works. The third sort comes in handy when it comes to reconfiguring
things: e.g. instead of having to reprogramme all the multi-way switches
that operate the ``hall light'' function when the bulb goes you just
have to redesignate the standard lamp as the ``hall light''.
> -the µ-controllers should have some EEPROM on board (to store the
> address & parameters)
Or be battery-backed. Assuming the switch can get power from the mains
or dedicated wiring, the backup only has to tide it over short outages.
Anyway, most microcontrollerss have at least some protected memory these
days, and an address isn't going to be many bytes even in the most
grandiose scheme.
> and be no bigger than a wallplate (SMD?? I soldered several SMD devices,
> not the fine pitch, and with a bit of practice, this seems to be no
> problem).
Definitely. I'm more worried about the size of the mains stuff (assuming
we use the mains for communications and/or DC power): surely that will
be much more bulky than the electronics. I'd have thought that a DIL
PIC would be adequate intelligence for a simple wall switch, and even
if we get ambitious with the protocol and overflow a PIC, a PLCC HC11
would surely be enough.
> -is it necessary to have a multi master protocol? I would say yes,
> although this complicates the issue a bit.
I would say yes too. I don't think it can be avoided, given the goal
of decentralized control. Every module has to be able to do its bit,
regardless of the state of the rest of the system, so everything
capable of initiating an action (which could be any sensor) has to
be master-capable.
> Maybe the CAN protocol can
> help us to sort this out. CAN is multidrop, multimaster by bit
> dominance, there's no physical layer defined and it has a very robust
> error checking scheme. Disadvantages: small packet size and I never saw
> an implementation in software?
Has anybody used it? I've just read the spec, and it sounds
well-thought-out. I like the bit-priority selection scheme. It has
very limited addressing though, even in the extended mode. I have seen
CANbus-to-parallel or -serial converter chips, but I don't know how much
they do for you. Presumably they knowhow to do the address stuff but
have to be serviced every data byte?
I finally managed to look at the SNAP protocol on www.hth.com (their
PDF file is encrypted for no adequately explained reason), but it offers
very little; it is nothing more than a primitive framing scheme with a
great many unexplained optional bits.
> -what if e.g. a light controller fails? I don't see any solution to
> outguess this.
Well, if the command protocol is robust and can recognise the loss
of a packet (as it must for any sensible control) and maybe the total
failure of a node, it should be possible to have a contingency plan.
For example, if you operate the wall switch, but the main light doesn't
respond, the wall switch could try to operate some other light in the same
room instead. With our decentralized approach, that would mean having
quite a bit of knowledge stored in the wall switch, which might not be
possible if it used, say, a PIC. But if we had a per-room controller,
with display and programming interface, or a central controller, it
would seem quite feasible to have this sort of fallback.
> 2. If the system is really open, then the 1 wire devices from dallas
> should get equal attention.
Certainly they should be supported, but maybe not at the top level
(i.e. expect to have something that speaks ``our protocol'' doing
the translation between Dallas-bus and home-brew-bus).
> 3. If you post gerber files, can you re-import them and change the
> tracks???
I think Gerber files just do layered move, draw and drill instructions.
So conceivably you could import them and make changes, but you would
lose a lot of helpful information in the process.
Is there an open PCB standard? I've used ``pcb'' on Linux which has
a very simple ASCII file format, but it doesn't have any import/export
capabilities built-in (though there may well be contributions from other
users by now). I don't know of any common interchange format.
The PCB production place I mentioned before (www.pcbpool.com) accepts
Eagle, Target, Protel or Gerber files, so presumably these are fairly
common. I don't have any of those packages. Could those who do let
us know what they can import and export? Maybe we can identify a good
interchange format.
> 4. Wire wrap is fine for prototypes, but I wouldn't try to put 230V on a
> wrapped board!
:-)
> 5. My company has some 'not so professional' (protel) and professional
> (cadence, veribest) PCB design tools here. The professional tools are
> 24h/24h occupied. I'm afraid we are stuck with the not so professional
> tools.
Not necessarily a bad thing. I can't imagine any of our designs needing
the sort of sophistication available in the professional packages.
> Question for Robin: I suppose you run Linux. What electronic design
> tools do you use? I only know there is spice for Linux?
I do indeed run Linux. I haven't found a package that does everything
I would like, but my needs are mostly simple. I have used spice (for
simulation), xelen (for schematics) and pcb (for pcb layout). I have
also abused Gimp as a CAD package.
While looking to see if there was anything new, I came across a page of
interesting-sounding links at http://www.mcs.net/~adyer/html/eemisc.html
> 6. Many cooks make a bad kitchen, I know. But in view of the complexity,
> I think we should try to attract more active members.
Is it time for an announcement to comp.home.automation? I was putting
it off until we had something worth looking at on the web, which perhaps
we now do.
Robin.
-- R.M.O'Leary <robin.at.acm.org> +44 7010 7070 44, PO Box 20, Swansea SA2 8YB, UK