The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: Logic: Distributed or Centralised?



Hi Andy,

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.

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.

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..

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.....

Kevin



Andy Laurence wrote:
> I'm trying to get a handle on how the logic works with the xap-enabled
> devices/software available today.  I understand that some devices will
> send messages, and other devices will action events based on them.
> What I've not worked out yet is where the logic is applied.  Does the
> input device send a control message?  Does the control device listen
> for status messages from a certain device?  Do I need a piece of
> hard/software that listens for status messages and outputs control
> messages?
>
Essentially yes  - any of 3 options - listen for 'events' , send
'commands' or use a  controller in the middle.
> Using a scenario, if I had a xap-enabled NetIOM, could I configure it
> to send status messages when an input is triggered, and to toggle a
> relay at the same time?  Would I require any external hardware for
> this?
Not within the device itself.  It doesn't have an ability to originate
commands to another device (or itself). It sends realtime events for
everything that happens though.  However inbuilt 'mapping' would be a
great feature and is on the list of feature requests. As a low volume
product though it may be a while before we see it.      Having such a
function running embedded is something I intend adding to the xAP
gateway controller.
> If I do, I've been offered a Sharp Zaurus, which would be an
> excellent piece of hardware for running HA applications.  It's low
> power, has a built-in user interface, and runs Linux, so applications
> are easy to port to it.
>
I'm afraid I have absolutely no nix knowledge but sounds ideal - and
looks nice too .I did upgrade my Tivo and am playing with Asterisk -
when the instructions said "edit the 'configuration file to include
these lines" I was stumped...so there's a big clue..  but getting
better
slowly.  There aren't many xAP controllers  on Linux though (MisterHouse
of which I know very little about the xAP support) ) so not quite sure
about the feasibility of 'porting' anything.
> Cheers,
> Andy
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>






xAP_Automation Main Index | xAP_Automation Thread Index | xAP_Automation Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.