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 still would like to get James' input on how he is handling the IR
interface capability declaration with his Homeseer plugin.

The plugin creates a database of IR messages it hears.
They are stored in the format server_detector_device_button as files
with in the IR directory. Both the current IR schemas can form into this
construct.
Each of these is an event which can trigger any number of actions. An
action can be xAP, xAP to homeseer or commandline. You can have
unlimited events (within reason) with this part of the system.
If you turn on the IR interface in HS, you get the option of picking the
device/button ratio. Now you can learn and test any button you want.
Pressing a learn button lets you pick one of the code from the database
or you can add the last IR received . So effectively you push learn,
push the remote button and hit the "use this code" under the last
ir
received. I haven't added some auto learning functions but that should
be quite simple, just want to crack the current cpu issue at the moment.
James

> <>
>
> -------------- 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/
>
>
> *Yahoo! Groups Sponsor*
> ADVERTISEMENT
> <http://us.ard.yahoo.com/SIG=12956m1se/M=298184.5022502.6152625.3001176/D=groups/S=1705007709:HM/EXP=1087481957/A=2164330/R=0/SIG=11eamf8g4/*http://www.netflix.com/Default?mqso=60183350>
>
>
>
>
------------------------------------------------------------------------
> *Yahoo! Groups Links*
>
>     * To visit your group on the web, go to:
>       http://groups.yahoo.com/group/xAP_developer/
>
>     * To unsubscribe from this group, send an email to:
>       xAP_developer-unsubscribe@xxxxxxx
>       <mailto:xAP_developer-unsubscribe@xxxxxxx?subject=Unsubscribe>
>
>     * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>




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.