Re: Red Rat 3 / IR Schema

[Stuart Booth <lists@xxxxxxxxxxxxxxxx>]

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=IR.Receive

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


Class=IR.Transmit

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

IR.Pronto
{
IR=[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
specified
>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=KCSoft.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=IR.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,
but 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 = 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
selection

I can easily implement this by querying the device database.

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

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