RE: Logic: Distributed or Centralised?

["Andy Laurence" <andy@xxxxxxxxxxxxxxxxxx>]

From: Kevin Hawkins [mailto:lists@xxxxxxx]
>  The model you adopt is really one of personal preference. That's one
> of the great flexibilities of xAP. A xAP device can listen to (any and
> all) messages and action something based on what it hears, so when the
> 'bedroom' light switch is turned ON for example it can choose to do
> something.  The light in the bedroom might listen for such messages
and
> turn itself ON for example, it may listen to several other switches
and
> some 'scenes' too. Alternatively the same switch can instruct the
light
> to turn ON by targeting it specifically with a cmd message.  So a sort
> of 'listen' and/or 'prod' approach.  Here we have the 'originator' and
> 'actioner' in a direct relationship so the system all works
> independently of other devices or controllers and is very resilient to
> problems as there is no single point of failure on the network for
> interconnection of say light switches and lights. A distributed
approach
> which is highly desireable for resliency.  It can however be slightly
> complex to manage as one entity though.

That's what I expected.  Highly flexible.  I've just ordered a xAP-enabled
NetIOM for playing around with before I move house.  I think I'll try and
do as much as possible integrated on the switches and output devices,
whilst using xAP-desktop for other smarts, like accessing it through
t'Interweb and the like!

> The third approach is to involve a controller in the middle between
> devices .   Here a device listens to all messages (or is targeted with
> specific messages) ) and onwardly passes the appropriate device
> actions.  The controller can be a very simple 'mapper' between inputs
> and outputs or more usually will implement logic or scheduling.
> Currently these controllers are PC based applications like HomeSeer,
> MisterHouse, ANother(TBA), xAP BSC Mapper, xAP Desktop and xAP
Floorplan
> . These HA applications generally use VBScript or a variant with xAP
> extensions.

As Misterhouse is Linux-based, I wonder if it could be ported to the Sharp
Zaurus?  It's certainly a low power device with no moving parts, and has a
UPS built-in.  Worth investigating, perhaps.  Fortunately, I'm reasonably
able to fudge things in both Perl and VBscript, so most PC-based apps could
become quite flexible.

> Now the beauty is because of the loose coupling of devices and
> because all devices can hear everything that's happening you can mix
and
> match all these three approaches. This has powerful benefits,  for
> example a controller could monitor light switches and lights that were
> directly interacting. The controller might notice that the light
didn't
> turn ON as requested by a switch and could step in with appropriate
> remedial actions. Perhaps a very fancy light could even report that
it's
> bulb has blown even and a controller could create/email a fault log.
> Multiple controllers can be used each performing different roles and
two
> or more controllers might even be present , as a failsafe, such that
if
> one didn't perform as expected (crashed) the other could step in as a
> backup.    Another benefit might come in 'scenes' or 'groups' where
you
> wish to configure 4 lamps to various brightness settings from one
> switch.   If the light dimmers were very simple (and didn't have
inbuilt
> scene support)  a controller could automatically sense this (as they
> didnt respond to the scene command) and step in as a helper. So 3
lights
> might work correctly but the 4th budget one isn't scene capable - so
> when the controller sees the scene being actioned it manually controls
> that 4th light. A disadvantage of thsi approach is that you create
> bottlenecks and single points of failure if you are not careful, and
> these are running on PC's :-( .   Curiously xPL tends to enforce (or
at
> least encourage) only this mode due to it being xPLHAL centric, it
> doesn't promote a distributed approach or mixing and matching the
three
> alternatives..

Cunning.  It really does show how versatile the protocol is.  Perhaps this
post should go somewhere for reference?

> Ideally I guess some embedded controllers would be nice for xAP -
> and certainly having embedded mappings between inputs and outputs  (eg
> switches to lights) is desirable. Alternatively the switch or light
> needs to be configurable which adds to cost and complexity. I am
working
> on adding xAP mapping support to the xAP to C-Bus controller and have
an
> early version here , and eventually (big maybe) having an embedded xAP
> controller offering schedules/logic and  C-Bus would be optional.   
In
> my setup I've tried to use the distributed approach wherever possible
as
> it's resilient, turn a light switch ON and the light turns ON even if
> the PC/controller is down. However with C-Bus I don't actually do too
> much of this via xAP.  External xAP switches do control C-Bus loads
and
> C-Bus switches do control xAP relays and eventually some DMX dimmers.
> The bells and whistles I have to enlist a PC HA application , and also
> anything involving richer data like emails, AV control, News, TV
> Listings , Weather etc  .   I do have some AMX and Crestron stuff too
> and actually have xAP running (embedded) on them. So to an extent, and
> at a cost  there is a xAP embedded controller available but the
> programming software is not available to 'end users' from Crestron or
> AMX which is a killer (and incredibly stupid IMHO).    It's all still
> very early days for me and nowhere near  a polished system yet .
However
> I went from a state of having a hundred things I wished I could do to
> having 90 things I can now do - but am just short of time , and
impetus
> at some of the messy grunt work. I've only got about a quarter of my
> C-Bus stuff wired so far.....

Solid-state hardware is definitely the way to go for HA.  Hard disks fail
enough as it is!  Thanks for taking the time to produce such a
comprehensively informative post for me.

Cheers,
Andy