Re: Red Rat 3 / IR Schema

[mcs101main@xxxxxxx]

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

In essence the Homeseer plugin then developes its own database of IR
location to IR Device/Signal and this database will grow as then number of
IR servers are increased.  It is independent of the table that homeseer
uses to maintain the same information.  I assume that the homeseer IR zone
is handled as individual IR xap servers.

This should work fine to support the IR interfaces as specified in the
homeseer SDK.  It does not address the characterization handshake which it
looks may not actually make that much difference since it appears that
homeseer hard-codes the map to have 36 IR signals per device.

Since the homeseer database is not being directly used by the plugin then I
assume that there is no desire for autodiscovery for the homeseer plugin to
allow the table to be constructed without the user needing to populate the
database with individual button pushes.  This implies there is not desire
to define/support a schema to do this.

I suspect that most homeseer users actually do not learn their IR codes,
but load a database of codes associated with the equipment being
controlled.  It is often the case that there are discrete remote codes that
are supported by equipment manf, but not available on the remotes.  Usually
there is one toggle button for On/Off, hence one IR code.  The equipment,
however, will often support a discrete On and discrete Off.  These can be
used when the database is populated directly, but not when it is only
learned.

Even without availability of discrete codes it is a lot easier to load a
database than interact with individual  buttons on a remote control unit.

-------------- Original message from James : -------------- >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/>.
>
>