Re: Implementing failover of the Home Automation Rule Enforcer (HARE) in a federated environment.

[Marc F Hult <MFHult@xxxxxxxxxxxxxxxxxxxxx>]

On Mon, 26 Jun 2006 12:08:12 -0400, Marc F Hult
<MFHult@xxxxxxxxxxxxxxxxxxxxx> wrote in message
<rvpv92tvohifvi6nqv5e55hd1oveqj3hof@xxxxxxx>:

>In a typical PC-centric Home Automation (HA) system, only one instance of
>the HA program (Homeseer, Premise Systems, CQS, MisterHouse ) is running at
>any given time. However one legacy HA program (Savoy's CyberHouse) has
>intrinsically provided for mutual cooperation of more than one server since
>at least 1998.
>
>The principal function of HA programs is to provide for the development and
>execution of rules that cause specific outputs and outcomes based on a
>variety of inputs: hence the moniker introduced here of Home Automation
>Rules Enforcer and its acronym HARE.
>
>Because of the mission-critical, central importance of the HARE, it is
>useful to consider ways to provide redundancy. One way to accomplish this is
>to provide mirrored HAREs with a thoroughly validated method for failover
>http://en.wikipedia.org/wiki/Failover of one HARE to another.
>
>XP provides for execution of scheduled tasks through individual files with
>.job extensions in the windows\tasks directory. So a network administrator
>can control the behavior of PC's from any device capable of copying .job
>files over a network to the windows\tasks directory on target PC's. One can
>use a remote PCs or Personal Digital Assistants (PDAs), or another HARE to
>cause a remote PC to run most any program that can be started from the
>command line.
>
>One way to effect a failover under XP and Server 2003 would be through the
>use power settings for sleep, hibernation, monitor, cpu and hard disk etc
>using the powerconfig.exe command. ( See Start-->Run-->Cmd-->powercfg /? for
>descriptions of the numerous options.)  Among other things, powercfg
>provides for creation, import and export of .pow files. There are some
>potentially very useful options including text and audio notification of low
>UPS battery, wake on modem ring, as well as the various power management
>features that most folks are familiar with.
>
>I am exploring use of these capabilities for two or more PC's to serve as
>mutual/reciprocal  watchdogs, and to provide for  failover of the active
>HARE to an other PC that may be asleep (to conserve energy) or already have
>another function in the network (e.g. file server). It might also consist in
>reversion to a better-tested, older rule, or simpler rule set for the same
>HA program or to a different HA program (in my case, Homeseer or CQS to
>CyberHouse).
>
>The ability of two or more PC's to provide for structured failover would be
>particularly useful in a 'federated' HA environment with multiple subsystems
>(security panel, thermostats, audio server, video over IP etc).
>
>Ideally the granularity of these subsystems and the functions that they
>provide  should be fine enough that all essential HA Input/Output (I/O) --
>including audio and video and control of devices that communicate using
>TCP/IP, and RS-xxx -- can be accessed/accomplished by more than one PC. This
>makes possible redundancy of the most important element of an HARE-based
>environment, namely the PC running the Primary Rule Set (PRS). How to
>dependably replicate and maintain the PRS is one of the challenges.
>
>Seems to me that this work is sufficiently generic, (i.e. independent of the
>actual HARE program used) that we could share our ideas.
>
>I'll post my own solutions for my Windows XP and Server 2003 environment as
>they are developed and to the extent I don't judge doing so to be a security
>risk.
>
>HTH ... Marc
>Marc_F_Hult
>www.ECOntrol.org


Notes:

1)  A fully federated system allows for the simplest failover, namely
shutting down, sleeping, or hibernating the PC running the HARE and allowing
the security, thermostat, video, audio, IR, pool/spa control, energy and
environmental monitoring and other subsystems continue in standalone mode. In
other words,  failing over to the subsystems rather than another HARE.

2) Another simple mode is the restart/reboot of a single HARE. Users of
CyberHouse and Elk Magic Modules (and presumably Adicon Ocelot) have shared
rule sets for years that program MM443's to serve as watch dogs for the PC
running the CyberHouse server (HARE)  and routers/modems on which TCP/IP
traffic depends. For better or worse, these are hardware dependent
programs/rules.

3) One useful goal would be the adoption/availability of a standardized
language/script/file definition for rule sets. CyberHouse provided for this
between disparate hardware. Perhaps one of the existing HARE programs (CQS,
PERL-based MisterHouse or HomeSeer's SQL/ACCESS ) could be adopted to do this
through program specific parsers/translators/compilers. Or is there another
extant solution?

As a practical matter, I would have given great weight in my
purchasing/adoption decision to a HARE Program (or is that ' Module ', as in
HAREM ;-)  that could have imported rule sets from CyberHouse. How large is
the installed base of  expensive, and now (apparently) moribund Premise
System HARE ?  How many folks would migrate to a HARE that is more stable
than HomeSeer 2.0 if they could easily reuse the time and energy spent in
writing rules for Homeseer by simply importing them ?

... Marc
Marc_F_Hult
www.ECOntrol.org