RE: Red Rat 3 / IR Schema

[mcs101main@xxxxxxx]

--NextPart_Webmail_9m3u9jl4l_29875_1087232293_0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit

Welcome Chris, I know when I made my first inputs to both xap and homeseer
I felt like I had nothing to of value contribute, but I had an interest. 
The result was a very supportive community where no question is too dumb.

I know the Zanware in-wall controller has an IR receiver and passes IR bit
streams over the ethernet to the PC so the bit-level candidate option that
you described is doable.  The advantage with this is that the PC is much
easier to program than a dedicated controller so recognition of new codes
and general management of the IR from various remote controllers is easier.

In the general marketplace, however, most of the IR interface devices have
some intelligence built-in and this allows the level of communications to
be elevated one level to a functional communication rather than a
paththrough one.

A control schema that is at the same level as the functions of the
equipment being controlled is quite desirable and I believe we have that
with Stuart's definition of the basic IR schema.

The sharing of the configuration database is really a general problem in
any distributed environment and this one simple case of the IR database is
a good candidate to based a discussion upon.  A good solution for this one
should able to be applied to other situations where system-level
information is needed.

Homeseer uses two forms of data to persist configuration information.  One
is the Window 3.1 style .ini file which is a section name and a set of
key/value pairs in that section.  This is very similiar to an xap message
structure for a given class.  The other is the xml tree structure that
allows for a richer description of the configuration information that is
being maintained.

In my other xap applications I implement a Config class.  It allows a query
mechanism by which a unit's configuration can be queried and the full set
of section/key/value triplets are communicated as a notification.  It
allows a push mechanism by which a central node that contains this
information can deliver it to each remote node.  The configuration
information is stored locally at each node so that during any new startup
it will be able to use the last communicated set of configuration
information.

This is the type of mechanism that I believe is appropriate for the IR case
that is being discussed.  The RR connector, when queried, would deliver the
full set of learned device/function names in its database.  These would
then be picked up by other nodes that have interest in IR control and
stored locally in whatever format the local node needs to be able to use
the data and restore the data on its next startup.  The RR connector should
also have the abiltiy to push the data or indicate that its database has
changed to allow on-line nodes the ability to update their local databases.



-------------- Original message from "Chris Dodge" :
--------------
Hi,

I'm pretty new to the xAP forums, but as the Redrat developer guy, I've
been following this thread with interest. I have to say that as I'm not
that familiar yet with either xAP or HomeSeer yet, so am not really sure
whether I can contribute too much to this thread, but I'm very happy to
look into adding additional ways of doing things to the RR SDK if it
doesn't currently easily support the IR schema you decide on.

Both HomeSeer and the RR core software have been designed for use a single
app, so the idea of a single signal DB and some method of providing a key
to an IR signal in the DB works well - (device, signal-name) for RR or
(index) for HS. xAp is distrubuted so this doesn't work as well.

What about passing the actual IR data itself around? Instead of saying
"here's a key to an IR signal in a DB that may or may not know
about", pass the actual bit of IR data itself so that a connector/app
when it receives the data can see whether it recognizes it and take the
appropriate action? I guess that this is quite a bit more complex -
deciding on an IR format etc., but would mean that IR output devices could
just output the data without having to have a DB setup which could be
useful for embedded xAP devices.

OR: Pass some DB independant, unambiguous desription of the remote control
and the button that was pressed so that a xAP app/connector could say
"when that button is pressed I do this". A unique description
would probably need:

manufacturer, e.g. Technics
device type e.g. CD-player
device model e.g. SL-PG520A
remote model (not so improtant)
button name e.g. Play

Not very elegant and probably error prone (e.g. is slpg520a the same as
SL-PG520A)?

Anyway, these are just a few thoughts, and its probably clear from this
that I'm not very familiar with xAP!

Cheers

Chris
RedRat Ltd.





From: mcs101main@xxxxxxx [mailto:mcs101main@xxxxxxx]
Sent: 14 June 2004 05:36
To: xAP_developer@xxxxxxx
Subject: Re: [xAP_developer] Red Rat 3 / IR Schema


I think we need to decide how we want to manage IR database in general and
then a xap requirements to support this management should flow easily. 
There are about 10 IR interfaces currently available with plugins written
for Homeseer.  Each of these use the IR Index to identify a signal and the
database of signal to index is a pair of text files.
For sake of discussion assume that there are two XAP connectors for IR
devices and each of these has its own database supported by the IR device
supplier and recognized by the respective XAP IR connector.  While
documented well each of these database layouts is unique to the individual
device.
So we have a situation now where in one case the names are maintained by
the unit which is commanding the IR and in the other case they are
maintained by the hardware device/connector  that receives the command.
In a generalized scenario it should be possible to command different
hardware devices at the same approximate time.  Homeseer is oriented to
support only one IR device at time.  This is a restriction that does not
need to be propogated into a genalize IR solution.
The simple solution to adding RR/xap connector to Homeseer is to let the
Homeseer user manually enter the Device/signal pairs using the GUI provided
by Homeseer for this purpose.  The elegant solution would be for James' and
my Homeseer xap plugins to query the xap-IR connector when an xap-IR
interface is selected to be the Homeseer IR interface and then build the
database used by Homeseer from the query response.
There must be other HA engines besides Homeseer that have the ability to
command IR.  How do they handle the situation?
-----------------------
A proposed dual schema shown below uses two section names.  What are the
merit of maintaining a single section name in the schema, but require
either Device/Signal or Location?
Class=IR.Receive
IR.Signal
{
Device=[Name of IR Device e.g. SliMP3]
Signal=[Name of IR signal e.g. Play, Stop, Next]
}
IR.HomeSeer
{
Location=[index value]
}