[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: Red Rat 3 / IR Schema
- Subject: Re: Red Rat 3 / IR Schema
- From: mcs101main@xxxxxxx
- Date: Mon, 14 Jun 2004 04:35:40 +0000
--NextPart_Webmail_9m3u9jl4l_10639_1087187740_0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
I think we need to decide how we want to manage IR database in general and
then a xap requirements to support this management should flow easily.
There are about 10 IR interfaces currently available with plugins written
for Homeseer. Each of these use the IR Index to identify a signal and the
database of signal to index is a pair of text files.
For sake of discussion assume that there are two XAP connectors for IR
devices and each of these has its own database supported by the IR device
supplier and recognized by the respective XAP IR connector. While
documented well each of these database layouts is unique to the individual
device.
So we have a situation now where in one case the names are maintained by
the unit which is commanding the IR and in the other case they are
maintained by the hardware device/connector that receives the command.
In a generalized scenario it should be possible to command different
hardware devices at the same approximate time. Homeseer is oriented to
support only one IR device at time. This is a restriction that does not
need to be propogated into a genalize IR solution.
The simple solution to adding RR/xap connector to Homeseer is to let the
Homeseer user manually enter the Device/signal pairs using the GUI provided
by Homeseer for this purpose. The elegant solution would be for James' and
my Homeseer xap plugins to query the xap-IR connector when an xap-IR
interface is selected to be the Homeseer IR interface and then build the
database used by Homeseer from the query response.
There must be other HA engines besides Homeseer that have the ability to
command IR. How do they handle the situation?
-----------------------
A proposed dual schema shown below uses two section names. What are the
merit of maintaining a single section name in the schema, but require
either Device/Signal or Location?
Class=IR.Receive
IR.Signal
{
Device=[Name of IR Device e.g. SliMP3]
Signal=[Name of IR signal e.g. Play, Stop, Next]
}
IR.HomeSeer
{
Location=[index value]
}
-------------- Original message from Stuart Booth : -------------- On Sat,
12 Jun 2004 19:43:28 -0700, "Michael McSharry"
<mcs101main@xxxxxxx> wrote:
>I really do not want to manage a bunch of dedicated applications when
the solution is simply to use an existing Homeseer standard interface
>protocol.
As things currently stand I don't have a HomeSeer setup here, so a
Location integer number is unfortunately meaningless to me. I can't
really build it into the signals I send out other than setting such a
field to zero. Could this be an optional field or block in the
message? E.g.
Class=IR.Receive
IR.Signal
{
Device=[Name of IR Device e.g. SliMP3]
Signal=[Name of IR signal e.g. Play, Stop, Next]
}
IR.HomeSeer
{
Location=[index value]
}
I think that's perhaps what you're suggesting in "I suspect we are
going to end up with two schema or a schema that will support either
the Location or Device/Signal for identification."
>On the more general topic of the Device/Signal database...
>If I purchased a RR, or any IR interface, and learned a bunch of codes
then I need to characterize them into a database that the RR connector can
use. How is this accomplished?
There is a utility provided with the RR called a Signal Database
Utility. It creates the signal database file that describes the device
and the signal, the codes which it can learn directly from the RR.
<http://www.redrat.co.uk/RedRat3/Software/SignalDBUtil/index.html>
>How does this database of information become communicated over the
entire network of xap nodes so any node that has interest in IR will know
what is available?
Currently it doesn't. But I have full access to any number of RR
signal databases loaded by the Connector. You can even load a
different database set for each different Rat connected to the system,
or you can share a single d/b between them all. So I could easily add
a query mechanism for this.
There is already a mechanism by which you can query for information on
the RedRats connected, but this is in a specialised message class
rather than in a generalised mechanism.
> Homeseer does have such a database which is maintained in two text
files. One for the Device/Signal to Location lookup and the other for the
Zone information.
Effectively this is what the xAP RR Connector is doing. It has an
association between a particular RR in some location and the
device/signal information. Built inside it has the same lookup system
you describe.
>We need to get James involved with this one to get his viewpoint on his
plans for IR interface in Homeseer.
Yes, I'm coming at it from a different and much simpler PoV than you
guys, never having used HS.
> in general will utilize the Class and Section names that were defined
for the RR.
I'm completely open to alternative suggestions BTW. They all seemed
logical to me, but others might have a different layout/structure in
mind. Very interested in hearing thoughts/requests.
> I also need to understand how the public information in databases such
as that used for the RR become visible to other xap applications.
You request it, I'll implement it... :) Well, after I clear out a few
other requests from Max, James and Kevin that is!
Since I've used the RR Device/Signal association in the generalised IR
schema, adding a query mechanism at this level would fit well.
Perhaps...
Class = IR.Signals[.Info (for the Query results broadcasts)]
Devices.Query
{
}
Devices.Info
{
Devices=[csv list - could be quite large though]
}
Signals.Query
{
Device=[Name of IR Device e.g. SliMP3]
}
Signals.Info
{
Signals=[csv list - could be quite large though]
}
Signal.Query
{
Device=[Name of IR Device e.g. SliMP3]
Signal=[Name of IR signal e.g. Play, Stop, Next]
}
Signal.Info
{
[Some info about the IR signal perhaps?]
}
I believe there may be some scope in using BSC to broadcast the
presence of RedRats and their IR detector status perhaps. I have still
to examine this again in detail but it won't be long now I hope.
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
|