Re: Red Rat 3 / IR Schema

[mcs101main@xxxxxxx]

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

The RR-specific changes seem appropriate to me, but I do not have a
specific content to know when I would use them.

After hashing through theIR schema on this forum it dawned on me that all
homeseer IR uses the same Device/Signal to Location definition so support
of Device/Signal vs. Location in the schema is not a big deal.  It only
means that a copy of this database needs to reside with each instance of an
IR interface.  At this stage just a little more bookkeeping.  I will
withdraw my request for a Location key in the schema.

I still would like to get James' input on how he is handling the IR
interface capability declaration with his Homeseer plugin.  It may be the
case that Homeseer always uses 36 functions per device and the number of
devices is based upon the size returned from the IR device.  In any case it
seems reasonable that a characterization of an IR interface capabiltiy
should exist in the general IR schema.
-------------- Original message from Stuart Booth : -------------- I've
tweaked up the IR schema for the RR very slightly. If I don't do
this now then there'll be more inertia later on when it's more
commonly used. Luckily the bits I've changed are not the core IR
receive/transmit stuff, but the RedRat extension stuff, so this
HOPEFULLY won't affect anybody just yet??

Here's the latest schema:

xAP IR Schema v1.1

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


Class = RedRat.Control

Blink
{
}

IR.Detector
{
Enable=[ Yes  No ]
}

RedRat.Location
{
Name=[New name for the RedRat]
Desc=[New location description text]
}

Detector.Query
{
}

RedRat.Query
{
}


Class=RedRat.Control.Event

Detector.Event
{
Enabled=[ Yes  No ]
}


Class=RedRat.Control.Info

Detector.Info
{
Enabled=[ Yes  No  Unknown ]
}

RedRat.Info
{
Name=
Description=
Serial=
Firmware=
Company=
}
RedRat.Version
{
Major=
Minor=
}
RedRat.USB
{
ProductName=
Serial=
VendorID=
ProductID=
}


Basically I've added the Classes of "RedRat.Control.Info" and
"RedRat.Control.Event". In one of the IR discussion posts there
was a
query command. Repeating the query is a good thing as it makes the
response message utterly standalone. But something has to change so
that the query doesn't get acted upon in a loop over and over.

I've taken up Edward's earlier suggestions of a .Info block with the
query response. This nowadays tends to be a compound response rather
than a bitty piecemeal query/response, query-next-bit/response cycle
(as seen in the early edition of the Audio Control schema), which
partially eliminates the need to repeat the query in many cases, but
allows room to retain it in others. And I'd rather be consistent.

So you send:

Class=RedRat.Control
Detector.Query
{
}

And you get back:

Class=RedRat.Control.Info
Detector.Info
{
Enabled=[ Yes  No  Unknown ]
}

Okay, in this case the Query block isn't repeated, it's empty anyway.

When you CHANGE something, such as the IR detector's enabled state,
you send:

Class = RedRat.Control
IR.Detector
{
Enable=[ Yes  No ]
}

And you get later get back an equivalent .Event message when (if) it
gets actioned:

Class=RedRat.Control.Event
Detector.Event
{
Enabled=[ Yes  No ]
}

What do folks thing of this? It's a tiny, tiny little change
code-wise, but I think it looks much better/makes natural sense.

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

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