Re: Red Rat 3 / IR Schema

["Michael McSharry" <mcs101main@xxxxxxx>]

------=_NextPart_000_1070_01C450B5.88E4B890
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>As an aside, one thing that Edward initiated I believe was to send out
>.Info messages in response to Queries such as this.

I'm fine with .Info as well.  I just tried to follow the pattern I saw
with=
the Audio-related schema when I selected .Notification.    .Info it shall =
be.
-------------------------------
>Assuming we go with Zone as the subaddress, which works well for the
>RRs, what is Unit exactly? I assume from your description of IR
>location that this is an integer index value?

I looked at my code and did not have a Unit key implemented.  I suspect
the=
provision was made for something like the Applied Digital products.  If on=
e wants to control 20 zones, for example, they would have one ocelot that
h=
as the cpu function and two secu16ir units that each have 16 independent
em=
itters.  Each secu16ir would have a unique unit code and then 16 emitters 
=
Address:UnitID.Zone would be the general addressing scheme where the IR si=
gnal would be in the body of the message.  I suspect that there is so
small=
of an audience that has multiple secu16ir, or equivalents, that the unit a=
spect of the address could be dropped and leave it with Address:Zone.
-------------------------------
>I assume from your description of IR
>location that this is an integer index value?
>This seems a little bit more specialised than a (?) simpler (?)
>device/key identification. Could you do the mapping internally to the
>HS format rather than expose that to the world?

Yes and No.  I suspect we are going to end up with two schema or a schema
t=
hat will support either the Location or Device/Signal for identification. 
=
For a dedicated and new application for which we have design authority
then=
the Device/Signal works just fine.  When legacy items are considered then =
the cleanest way to handle them is with Location.

For example, software already exists to manage the ocelot, as well as
sever=
al other IR interfaces used by Homeseer.  This software was designed to
the=
Homeseer IR interface specification and this specification uses an integer=
index to identify the IR.  I have the technology developed to run virtuall=
y any homeseer plugin inside an xap host. If I maintain the Homeseer
interf=
ace standards then a single xap host software package can support all
Homes=
eer plugins.  This provides considerable power to an xap network with no
ne=
w development.  To maintain the standard in the IR world I need to have
the=
IR index communicated.  If I wanted to make a special connector for each p=
lugin then I could put the location to Device/Signal transformation inside
=
the connector.  This would be just like you did with the RR where the
conne=
ctor contains the database.  I really do not want to manage a bunch of
dedi=
cated applications when the solution is simply to use an existing Homeseer
=
standard interface protocol.

On the more general topic of the Device/Signal database...
If I purchased a RR, or any IR interface, and learned a bunch of codes
then=
I need to characterize them into a database that the RR connector can use.=
How is this accomplished?  How does this database of information become c=
ommunicated over the entire network of xap nodes so any node that has
inter=
est in IR will know what is available?  Homeseer does have such a database
=
which is maintained in two text files.  One for the Device/Signal to
Locati=
on lookup and the other for the Zone information.  Of course Homeseer is a
=
centalized architecture and does not need to be concerned about other
nodes=
having the IR information.


--------------------
>1.1.1.1.1.3     Section: IR.Match
>Not entirely clear what this is for?

This aspect of the schema deals with management of redundancy and
system-le=
vel synchronization.  It is something that we do not need to deal with at
t=
his time since it involves much bigger issues than a simple IR schema.


--------------------
>1.1.1.1.1.1     Section: IR.Notification
>I can easily implement this by querying the device database.

We need to get James involved with this one to get his viewpoint on his
pla=
ns for IR interface in Homeseer.

--------------------
What I have done is implemented both IR-related schema in the mcsXap
Homese=
er plugin to be able to take advantage of both approaches to IR
communicati=
on. I still need to update for use of the subaddress and in general will
ut=
ilize the Class and Section names that were defined for the RR.  The only
r=
eal problem that we need to come to closure on is how to handle new vs.
leg=
acy needs.  I also need to understand how the public information in
databas=
es such as that used for the RR become visible to other xap
applications.=20













----- Original Message -----=20
From: Stuart Booth=20
To: xAP_developer@xxxxxxx=20
Sent: Saturday, June 12, 2004 12:59 PM
Subject: Re: [xAP_developer] Red Rat 3 / IR Schema


On Fri, 11 Jun 2004 21:10:11 -0700, "Michael McSharry"
<mcs101main@xxxxxxx> wrote:

>Someone on the Homeseer Message Board asked about RedRat3 support in
>Homeseer.  I noticed that you just released an xap connector for it and
=
my
>xapPlugin to homeseer will function as an IR interface to homeseer. 
The
>schema that I use, however is different that what you have implemented.

Certainly simple. I have definitely not set this in stone in the xAP
RR Connector yet either. Normally I wrap a xAP schema in some objects
to help simplify the creation and validation of the xAP Messages. I
have not yet done this for these IR schema messages as I anticipated
there would be some sway as I picked up ideas from others.

As a reference for anybody interested, here are the generalised
messages I'm sending/receiving:

Class=3DIR.Receive

IR.Signal
{
Device=3D[Name of IR Device e.g. SliMP3]
Signal=3D[Name of IR signal e.g. Play, Stop, Next]
}


Class=3DIR.Transmit

IR.Signal
{
Device=3D[Name of IR Device e.g. SliMP3]
Signal=3D[Name of IR signal e.g. Play, Stop, Next]
}

IR.Pronto
{
IR=3D[Pronto IR string of text]
}

>I'm not familiar with the RedRat3, but based upon the schema definition
=
I
>assume that it is programmed externally to associate codes with devices
=
and
>keys.

That's correct. There is a signal database utility supplied with the
RR allowing you to learn IR signals with the RR itself. These are
saved grouped somewhat similarly to your description of HS in that
they have a number of Devices and each device has a set of signals, or
keys. But it isn't indexed in a linear space.

>  The memory of this relationship is then retained within the RedRat3
>and these logical names are then used over the serial/usb port from the
>RedRat3.

The RR actually provides me with an IR signal event containing details
of the signal 'heard'. I then look this up in the device database to
determine if I recognise it or not.

Currently if I don't recognise it (ie the signal is not present in the
signal database) then I don't send out anything very useful (it just
tells me the device and key were unknown). Perhaps something better
can be done here.

So the RR itself doesn't contain the relationship b/w signal and its
device/key tag, but a device database that I load into the RR
Connector.

>Since my homeseer xap plugin can support any number of IR interfaces it
>needs to know what is connected so it can establish a common protocol. 
=
I
>noticed that there is pronto-related support in our schema.  What is
the
>mechanism that can be used to query the network to determine which IR
>connector is available?

Actually there isn't one as such, not in the generalised schema level.
But you can combine detecting the RR Connector h/b(s) with querying
the details of an individual RR, that bit IS supported.

>In my IR.Transmit section I have a Zone key.  Now that I think about
it,
>this probably should be more like a subaddress where the zone is
specifi=
ed
>as part of the header such as you do with the slimp3 player.

This happens with the RR Connector too. The name of the RR, or its
zone e.g. Lounge, or Bedroom1, is used as a subaddress in the address
fields:

Source=3DKCSoft.RedRat.anya:Lounge

>1.1.1.1.1   Class Homeseer.IR
>1.1.1.1.1.1     Section: IR.Query
>Description: Sent to request capabilities of an IR device.  Response
>provided by IR.Notification message.
>
>Keys:
>
>      Required      Item      Description
>      None          N/A      N/A

No problem.

As an aside, one thing that Edward initiated I believe was to send out
.Info messages in response to Queries such as this.

He adopted a .Event message for when something occurs/changes, and a
.Info message when answering a query and perhaps just informing of
current status.

I like .Info rather than .Notification as it's more compact and
equally reusable/readable. Looks good too! :)

>1.1.1.1.1.2     Section: IR.Transmit
>Description: Sent to request an IR-capable device to transmit IR code
at
>specified location.  Header target can be used to select specific IR
>provider.

Okay, I called the Class IR.Transmit to separate the possibilities
from reception messages. I went with IR.Signal as the body block name
as it can be shared with Class=3DIR.Receive, which I liked.

>Keys:
>
>      Required      Item      Description
>      No      Unit      Unit designation for box holding the remote IR
>      No      Zone      Zone designation of IR emitter to be utilized
>      Yes     Location  IR memory location where learned-code is stored

Assuming we go with Zone as the subaddress, which works well for the
RRs, what is Unit exactly? I assume from your description of IR
location that this is an integer index value?

This seems a little bit more specialised than a (?) simpler (?)
device/key identification. Could you do the mapping internally to the
HS format rather than expose that to the world?

>1.1.1.1.1.3     Section: IR.Match
>Description: Used by an xAP application to report results of
>Trigger.Condition message.  Because of the timing associated with event
>condition processing this xap message is not expected to be utilized,
bu=
t is
>included for completeness.
>
>Keys:
>
>      Required     Item     Description
>
>      Yes         Match     IR Number for which match occurred

Not entirely clear what this is for?

>1.1.1.1.1.1     Section: IR.Notification
>Description: Sent by an xAP application that supports IR to describe
the=
IR
>configuration.  Sent in response to a IR.Query message
>
>Keys:
>
>      Required     Item     Description
>
>      No     Zones       Number of zones (assumed =3D 1)
>      Yes    Keys        Number of keys per logical device
>      Yes    Devices     Number of logical devices
>      No     IRMatch     True is able to return IR match
>      No     Options     True if setup form to be invoked with option
se=
lection

I can easily implement this by querying the device database.

S
--=20
Stuart Booth <stuart@xxxxxxx>
xAPFramework.NET - a xAP software development framework for .NET

http://www.xapautomation.org/ 
     http://www.xapframework.net/