How to send xAP messages

[perkijef]

Ok. Basic setup is OK and devices are found.
Now for the advanced stuff.

Now I want to send an xAP message from Homeseer to the RedRat Connector to trigger the RedRat to send an IR code. All my IR codes are in the signal Db and all are tested to work OK directly from RedRat software.

In xAP conduit I create an event, then a sequence OK.
Then its not so clear. There is no RedRat command in the list but there is Raw xAP. Do I need to use that?? If so then what is the format of the command that needs to be sent??

Or should I be able to define the RedRat as the Infrared Interface? Is that possible?

I can really see some great potential with this - just need to get the basics understood.

Jeff

[mi4]

Jeff,

As with anything there is more than one way of sending the IR command. You could use raw mode, scripting or the easy way.
Raw mode
Select raw mode from the dropdown. Now you will have a big box, target and class lines. In redrat connector directory in sample messages open up one of the ir send messages (in notepad). You will see that the class is IR.Transmit and the body would look like this (this is to go in the big box)
IR.Signal
{
Device=Your device name
Signal=Button name
}
That's all that is needed. However if you have more than one red rat and only want the IR to come out of one you will need to use the target line.
This would be in the form KCSoft.RedRat.PCname:Redratname

Via scripts
The same message could be made by doing this:
body="IR.Signal" & chr(10) & "{" & chr(10) & "Device=TV" & chr(10) & "Signal=ChannelUp" & chr(10) & "}" & chr(10)
hs.plugin("xAP Conduit").sendxapmessage "IR.Transmit",body

The easy way.

Goto xAP Conduit> Options and click update schema. I have added red rat to the schema database and will now appear in the drop down

HTH

James

[Stuart Booth]

<BLOCKQUOTE class="ip-ubbcode-quote"><font size="-1">quote:</font><HR>Originally posted by mi4:
The easy way.

Goto xAP Conduit&gt; Options and click update schema. I have added red rat to the schema database and will now appear in the drop down <HR></BLOCKQUOTE>

Cool!

It would be worth noting that the RR Connector is still very early in its development at this stage. Michael McSharry has raised some interesting comments wrt to the xAP Schema that the RR Connector uses (which is very simple).

See http://groups.yahoo.com/group/xAP_de...r/message/1005 for more details. So there's a chance this schema will get updated very soon.

Still, that looks like a lot of flexibility you've got there, James!

[Michael McSharry]

In a homeseer scenario the IR looks like a dedicated interface that has been integrated into Homeseer. When an IR button (e.g. Test IR from the Homeseer menu) is pressed then a command goes to the IR plugin that was selected to be the interface.

Since the xap Conduit does not provide an IR interace capability to homeseer then it will not be possible to use it to handle the general case of the Homseer IR. It is possible to send xap messages using the RedRat3's defined schema via scripting or events as James described since the xap Conduit provides xap messaging, but Homeseer will not be involved with all the IR activity that may be happening.

The IR capability for Homeseer is not difficult to implement and could be added to the xap Conduit if James so desired. It does then get into the issues that Stuart mentioned about how the schema needs to address a generalized IR interface.

When I did the IR for mcsXap I provided the abiltiy to maintain a direct interaface as a passthrough as well as an xap message capabilty. This allowed a standard homeseer configuration to be run while at the same time make the network aware of IR activity that was happening.

[mi4]

&gt;Or should I be able to define the RedRat as the Infrared Interface? Is that possible?

Not currently, but no need. As I described it is very easy to send IR commands via xAP to any number of devices.
Receiving of IR works in a very similar, equally simple way.
(Please note the current plugin only supports the IR signal from the SLimp3,squeezebox. I am soon to release an updated ocx that among other things adds redrat receive support)
Whenever an IR signal is received an event is triggered and if it's the first time the signal has been heard the event will be created for you.
An IR event works in exactly the same way as the event system that you used to send the IR. In the xAP Conduit menu open IR Events and you will see the familiar interface. On the left you will see all the detected ir signals and you can simply click on one and create an event for it. As with all the other events IR events can do anything; send commands to homeseer, send xAP or run programs. These can be in any order and have unlimited steps. One other big advantage of using this event system rather than the homeseer one is that any element in any part of the event can have dynamic data in it. For example a simple on screen display would probably want to pull information from other devices to form the message. Now link this to an ir event and it is very easy to set up a remote button on say a Slimp3 that would make it display the number of unread emails. All with no scripting just 1 event and 1 device or variable to hold the email details.
Look for the advanced event guide @ www.mi4.biz

While I really like this approach I can see that the Homeseer ir interface has merits and I will add support for that too, with the obvious limits to &lt;500 IR buttons. I could be missing something ( i'm a homeseer newbie really) but IR events in homeseer are all about sending of IR data, you can't setup a trigger for an event based upon received IR? well not with the standard plugins anyway.
In xAP the idea is to distribute the intelligence so things like mapping button to IR code are best handled by the interface, in this case the Redrat connector. Doing it this way means that all devices on the network receive an easy to understand message ( TV,channelup) rather than a huge string of numbers that each device/application would have to have some lookup table for.

James

[Michael McSharry]

In general I believe we will much better acceptance of xap technology in the homseer community if the technology is integrated into the homeseer paradymn rather than trying to fit homeseer into the xap one.

Homeseer has a script interface that is hs.SendIR. We should not expect a user that has implemented scripts using this method to rewrite them to use a hs.Plugins("xap conduit").SendXAPMessage method. Homeseer has an event mechanism and plugins can be written to integrate tightly with this mechanism. One of the native events is IR received. No matter what the IR interface happens to be that sent the IR signal, the same event will be triggered and the user is divorces from the mechanism and particulars of the RedRat vs Slinke, IRT, ocelot, etc. and does not need to know anything about xap schema and variants of this schema to support a specific IR device.

The homeseer IR interface uses a homeseer-to-plugin method during initialization. This establishes the virtual interface that homeseer will use. I use the ocelot for my IR. It has 1024 IR codes and my plugin tells homeseeer that I want to organize these as multiple devices with each having 36 functions. I tell it that if I have multiple zones or just a simple one zone system. I tell it if my IR hardware can recogize IR received.

In your plugin I would expect to see a setup form for IR where each IR schema that you wish to support are available for selection. Once the user has defined the unit that is on the xap network then xap conduit will use the schema that supports that specific one.

In my case I put an xap wrapper around the existing IR plugins written for homeseer. This allows all the legacy stuff to be supported directly while still having all the benefits of an xap environment.

The plugin needs to worry about all the schema that need to be supported or the mechamism of a physical interface. Homeseer will simply give it a command to send a particular IR to a selected zone. If IR is received then the plugin tells homeseer which one it was. If a user has setup an event based upon an specific IR received then homeseer will trigger that event and the waterfall of things that user want to have happen based upon that will be executed.

When the user has a web page showing a button associated with IR function, then all the efforts associated with processing the HTML form button is handled by homeseer. It the tight integration with homseer is not provided then the user would need to write the web server code to recognize the button and send the appropriate xap message.

I suspect you do not see any IR event triggers in your setup because you have not defined any IR interface to homeseer. It really is no different than the plugin interface to support X10, except the X10 does not need an initialization handshake to define what an X10 interface looks like. The X10 "pseudo-standard" is already known.

As an aside, the ocelot looks to homeseer as 128 devices containing variables, 1024 IR devices, and typically a set of 16 devices for each IO unit connected to the ocelot. The ocelot will update all variables at a nominal 2 minute interval and IR Received/Physical Inputs as they change. The output to the ocelot is on demand.

Note that X10 standard contains more than just the simple on/off/dim of BSC schema, but contains extended bytes as well. These really should be supported if xap Conduit is selected as the x10 interface to homeseer. I don't know what this means to the BSC schema or if xap conduit will utilize a different schema if extended information is given by homeseer. I utilized the full X10 schema in my plugin so my receiving nodes would not need to decode two schema.

There are pro's and con's for sending named values for IR signals. What I ending up doing was implementing both schema in my plugin. Now each IR transaction contains two messages. One with a named signal and one with an indexed signal. This just means the lookup information to translate in both directions needs to be maintained in the plugin. (Why does BSC schema use an index rather than a name while the IR schema uses a name rather than an index?)