Re: xAP Plugin for HouseBot - a touchscreen based frontend.

["Kevin Hawkins" <yahoogroupskh@xxxxxxxxxxxxxx>]

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



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