RE: xAP and JMRI naming

["Neil Wrightson" <neilw@xxxxxxxxxx>]

Hi Kevin,

How does this look?

The uid used in the heart beats should be something like FF123400. Where FF
and 00 are delimiters.
*** With the above set and a valid IP address, I get valid JMRI heartbeats
in the xAP (xFx) message viewer. (I'm running winodws XP) ***


I have not done to much with the JMRI application yet.
So bare with me.
I (NWE) have made a Interface PCB that has 8 inputs and 8 outputs. This
connects to the LAN and uses xAP as the protocol.
Prior to attempting to interface the hardware to JMRI. The interface card
would be given the following configuration
- UID = 1234				(Full UID would look as per
above i.e. FF123400)
- xAP instance ID= "CatsKill" 	(I borrowed this name from a
tutorial on the JMRI site)

To select a turnout you would use the following style of naming convention
target=NWE.MultiIO.Catskill
Where "NWE" is the manufacturer of the interface card that has
all
of the inputs & outputs (Cannot be changed)
Where "MultiIO" is the model of the interface card
(Cannot be changed)
Where "CatsKill" is the system name given to this actual
interface
card by the user.

Now if I had a passing siding at the Catskill section of track. It would be
configured as -
Northern Turnout - "xAPT.Catskill.1"	Where OP1 = Relay Output 1
on the interface card
Southern Turnout - "xAPT.Catskill.2"	Where OP2 = Relay Output 2
on the interface card

Because the turnout had a prefix of xAP, JMRI would know to send the
command
via the xAP interface and specifically targeting the "Catskill"
interface.

Now if there were a panel button that either selected the mainline or
passing siding. The system would send a message to change both points at
once.
So then I thought we could decode this into the following message.

{
v=12
hop=1
uid=FF123400
class=xAPBSC.cmd
source=JMRI.DecoderPro.Central	{ Note the source name, I think something
like this would be appropriate. Perhaps the "Central" bit
editable}
target=NWE.MultiIO.CatsKill:>
}
output.state.1				{ This is just a sequential command
number }
{
ID=01						{ Northern turnout } {Note
these are hexadecimal numbers }
State=ON					{ Select passing siding }
}
output.state.2
{
ID=02						{ Southern turnout }
State=ON					{ Select passing siding }
{Note - if set to OFF the points would be set for straight through (Main
Line) }
}

So now that the train is moving into the passing siding, the a train sensor
picks up the loco. This changes an input IP1 on the interface card.
The interface card then broadcasts the following xAP message to the
network.

{
v=12
hop=1
uid=FF123409			{ Note the 09 at the end. This is the first
input. 01..08 are the outputs } {Again this is a hexadecimal number string}
class=xAPBSC.event
source=NWE.MultiIO.CatsKill:IP1
}
input.state
{
State=ON				{ Train detected }
}

Use the uid i.e. FF123409 as the actual address to link to the sensor
"xAPS.Catskill.9"
Another example would be  FF12340A as the actual address to link to the
sensor "xAPS.Catskill.10"    Note the conversion from hex
"0A" to ".10"

Thoughts??
Doable ???


Regards,

Neil Wrightson.
N.W.Electronics
ABN 76 768 513 867
Embedded Controllers and Home Automation Products
Web     : www.nwe.net.au



>>-----Original Message-----
>>From: Bob Jacobsen [mailto:jacobsen@xxxxxxx]
>>Sent: Wednesday, 17 March 2010 2:35 AM
>>To: Automation; Neil Wrightson
>>Subject: xAP and JMRI naming
>>
>>I think we're pretty close to getting the xAP connection to
>>work, so it's time to start thinking about the next step in
>>connecting JMRI and xAP.
>>
>>Normally, when connecting JMRI and external systems, we
>>connect status messages from the system to "Sensors", and
use
>>"Turnouts" to send status change commands to the external
system.
>>
>>Using the Insteon control system as an example, when we see a
>>status report on Insteon address 12.34.56, we create a JMRI
>>sensor with the name PS12.34.56 that matches that status.
>>Another Insteon unit with address 45.A3.11 will get matched
>>to a JMRI sensor called PS45.A3.11, etc.  All the JMRI tools
>>then interact with those. You can give them simpler user
>>names, set options with them, etc.  Similarly for outputs,
>>where the names are PTsomething.
>>
>>So what's the corresponding thing for an xAP name?
>>
>>xap-hbeat
>>{
>>source=JMRI.test.1
>>interval=60
>>port=10000
>>hop=1
>>v=12
>>uid=FFFFFFFF
>>class=xap-hbeat.alive
>>}
>>
>>I can construct a name string from this entire message (class, uid,
>>source, etc) but is that all needed?  Or is just "source"
>>sufficient?
>>Or perhaps source+class?
>>
>>If we can get a trace of a xAP installation doing something,
>>perhaps that'll help us figure out what a convenient, but
>>sufficiently powerful, name convention would be.
>>
>>Bob



------------------------------------