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: xAP Plugin for HouseBot - a touchscreen based frontend.


  • Subject: Re: xAP Plugin for HouseBot - a touchscreen based frontend.
  • From: "Kevin Hawkins" <yahoogroupskh@xxxxxxxxxxxxxx>
  • Date: Thu, 01 May 2008 10:16:08 -0000

--- In xap_automation@xxxxxxx, "Taras" <tartheode@...>
wrote:

>
> I think Premise should prove flexible enough to allow for a full-
> featured xAP interface. It's architecture is object-oriented and it
> contains many classes representing common devices like lights,
> relays, temperature sensors, motion detectors, thermostats, etc.  You
> can also create new classes that inherit from others or a new class
> that extends an existing one.

>
> Premise's architecture adopts the "bridge pattern", where an
object
> (a light) is decoupled from its implementation (UPB/Insteon/Zwave).

Sounds great - in a way very similar to how xAP was intended. For
temperature sensors (which dont dovetail into BSC nicely) you should
use xAPTSC.

I started on a lighting schema for xAP but I have implemented BSC
alongside it as well and find that is mostly what I use as it creates
great interoperability with all xAP applications.  Edward has been
down this route too.  A full lighting schema adds things like ramp
rates and fade times. Ramp rates are usually a time fixed by the
hardware to go from 0-100% and fade times are the time to go from
brightness x to y - if practical.

>
> Based on what little I now know :) here's my plan of attack:
>
> I'll need to create a xAP driver object that exposes the BSC for
> several types of devices.  For example, there'll be a folder
> containing xAP Lights.  Within this folder will be all the instances
> of xAP-based lights discovered by the driver.
>
> .XAP
> ...Lights
> .....KitchenLight
> .....BedroomLight
> ...Relays
> .....SprinklerFront
> .....SprinklerRear
>
> Each instance contains properties that are common to a Premise object
> and a xAP device.  For example, a light's brightness level and
> powerstate.
>
> Am I on the right track here?

Yes - that seems good - Bear in mind too that you should expose your
existing objects within Premis so they can be reported & controlled
from xAP.  eg an Insteon light supported by your driver should send
xAPBSC.events whenever it changes state and should respond to
xAPBSC.cmd messages so that it can be controlled from xAP.  This may
require you binding to two drivers or using an intermediate xAP pass
through or 'snoop'. This way xAP becomes a true eventing/control
interface to Premise which makes it very open to integration
possibilities.

Kevin

PS I've looked at Premise before - but seem to remember it had a
different / channel focussed distribution model. Associated with
Motorola/Lantronix wasn't it ? Is this the website ? - it seems down
currently
http://www.premisesystems.com
>
> Taras
>



------------------------------------


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.