The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: Red Rat 3 / IR Schema



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/



xAP_Development Main Index | xAP_Development Thread Index | xAP_Development Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.