Re: xAP and JMRI naming

[Kevin Hawkins <yahoogroupskh@xxxxxxxxxxxxxx>]

--------------090901000000060102070301
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Unfortunately I have really no idea what you're trying to do with  xAP
and JMRI - maybe Neil can be more helpful but let me just ask what is
the end functionality you're wanting to achieve ?   Is it for example
that you can use the 'Turnout' commands in JMRI to switch Netiom outputs
on and off ?   ... and also use the Netiom inputs to map into JRMI
sensors  so you could have a switch attached to a Netiom controller or
maybe a speed controller via a Netiom analog input ?  Are you wanting to
control JRMI from HomeSeer - or maybe you already have that functionality ?

This leads to a crucial question - will JMRI only be interacting with
xAP BSC devices or does it need to support all the various xAP devices
and applications which may be using different xAP schema ? eg using the
volume control on your music player , the wind direction from an outside
sensor or an infra red remote button press to control something in JRMI
?  This really is important to clarify now as it will mandate how JRMI
recognises and processes xAP messages....  Handling more than just BSC
will be more complex both in how it is recognised and how the user
configures it.

Assuming it is just BSC devices then the source= line is sufficient to
identify the specific endpoint and the incoming messages that indicate a
'sensor' has changed will include a class=xapbsc.event.  NB this only
arrives on a state change.   Additionally a class=xapbsc.info message
will arrive periodically or when a device is queried, that affirms the
current state    My recommendation would be to initially filter incoming
messages on the class= parameter , accepting only messages that start
with xapbsc. and then you might take a different action based on the
latter part of the class message which could be one of only four values
.event   .info.  cmd or .query.

The first two of these ( .info and .event ) are reporting the status of
a xAP sensor and you would then inspect the source= line as the address
of the sensor and check if it matches one that you have configured in
JRMI . This full source address might have a friendlier name within
JRMI. If the sensor address is recognised you should then inspect the
new values contained within the attached output.state or input.state
body block to recover the sensors values and update JRMI.  Note that
actually the UID will also uniquely identify the endpoint and could be
used instead of the source= parameter but is not so intuitive to a user
when configuring.  You can think of the UID as being a numeric only
version of the source . This is only valid within BSC and some other
specific schema.

If my understanding is correct 'Turnouts' in JRMI will be used to
originate a command message (xapbsc.cmd) destined for a xAP endpoint so
they will originate a message from JRMI with a target= line that
identifies a specific xAP BSC endpoint.  That's fairly easy to do.    It
is important though to consider that the turnout will change the state
of a xAP output , and that may also be changed later by a direct xAP
command - does JRMI need to know that ?

In the above scenario then JRMI is not reporting any of its internal
endpoints (sensors) on xAP, nor is it reporting any internal 'Turnout'
results .  If for example some other sensor caused a turnout on JRMI to
trigger and action a state change then xAP would not see these changes.
Nor would xAP see sensor status'.  If this is adequate then you do not
need to process xapbsc.cmd or xapbsc.query messages and can just drop them.

However I'm thinking you might desire that this JRMI internal state and
event information be notified onto xAP, for example to use a xAP
controller to fully control JRMI, perhaps HomeSeer.  If so then you will
need to create BSC endpoints for these JRMI internals and report their
status via xAP periodically, on request and upon every change.  If you
wish the JRMI endpoint to be directly controllable from xAP (i.e. not
via a turnout)  then they must be presented as a BSC output device on
xAP  (because BSC inputs are not controllable).  You might notice some
similarity here in your 'virtuals' you mentioned and xAP 'virtual'
devices ;-) This will require significantly more coding in JRMI as you
will effectively need to implement a bidirectional conversation
ability.   You would then need to accept incoming xapbsc.cmd messages,
validate that the target= matches one of the internal address within
JRMI and then process the command. Bear in mind that the target= line
may be wildcarded allowing it to address several endpoints
simultaneously.  Likewise an incoming xapbsc.query command needs
processing as it is a request to JRMI to report the status of one of its
internal sensors (or turnouts), and again it might be wildcarded.

Maybe that helps but I think Neil might be the best source as he will
understand the purpose of the xAP/JRMI integration.

The full xAP BSC schema definition is here and it should be adequate for
representing up to 253 internal endpoints within JRMI - if you need more
- then we have an expanded version based around xAP v1.3

http://www.xapautomation.org/index.php?title=Basic_Status_and_Control_Schema



K






On 16/03/2010 18:36, Automation wrote:
>
>
> Anybody help me answer Bobs questions?
>
> In model JMRI terminology a Sensor does just that and a Turnout is
> what the
> layman in UK would call a set of points.
>
> With my NCE DCC system I give each sensor a number xxx and JMRI then
uses
> the prefix N (nce) S (sensor) xxx to refer to that sensor.
> similarly an output (Turnout) would be N (nce) T (turnout) yyy
>
> so, for example, throwing NSxxx could operate NTyyy if NSzzz is ON
> (rudimentary interlocking)
>
> Sensors and Turnouts can also be 'virtual' Route setting on my layout
> can be
> done clicking a (virtual) Sensor on a screen which then interacts with
> other
> Sensors status to instruct the NCE DCC system to operate the
appropriate
> Turnouts (outputs)
>
> VERY powerful systems can be built.
>
> Andy
>
> -----Original Message-----
> From: Bob Jacobsen [mailto:jacobsen@xxxxxxx
> <mailto:jacobsen%40berkeley.edu>]
> Sent: 16 March 2010 15:35
> 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
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.790 / Virus Database: 271.1.1/2750 - Release Date:
03/16/10
> 07:33:00
>
>


--------------090901000000060102070301
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit





<head>

<style type="text/css">
<!--

/* start of attachment style */
.ygrp-photo-title{
clear: both;
font-size: smaller;
height: 15px;
overflow: hidden;
text-align: center;
width: 75px;
}
div.ygrp-photo{
background-position: center;
background-repeat: no-repeat;
background-color: white;
border: 1px solid black;
height: 62px;
width: 62px;
}

div.photo-title
a,
div.photo-title a:active,
div.photo-title a:hover,
div.photo-title a:visited {
text-decoration: none;
}

div.attach-table div.attach-row {
clear: both;
}

div.attach-table div.attach-row div {
float: left;
/* margin: 2px;*/
}

p {
clear: both;
padding: 15px 0 3px 0;
overflow: hidden;
}

div.ygrp-file {
width: 30px;
valign: middle;
}
div.attach-table div.attach-row div div a {
text-decoration: none;
}

div.attach-table div.attach-row div div span {
font-weight: normal;
}

div.ygrp-file-title {
font-weight: bold;
}
/* end of attachment style */
-->
</style>
</head>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">


<!-- **begin egp html banner** -->

<br><br>

<!-- **end egp html banner** -->



Unfortunately I have really no idea what you're trying to do with&nbsp;
xAP
and JMRI - maybe Neil can be more helpful but let me just ask what is
the end functionality you're wanting to achieve ?&nbsp;&nbsp; Is it
for example
that you can use the 'Turnout' commands in JMRI to switch Netiom
outputs on and off ?&nbsp;&nbsp; ... and also use the Netiom inputs
to map into
JRMI sensors&nbsp; so you could have a switch attached to a Netiom
controller or maybe a speed controller via a Netiom analog input
?&nbsp; Are
you wanting to control JRMI from HomeSeer - or maybe you already have
that functionality ?<br>
<br>
This leads to a crucial question - will JMRI only be interacting with
xAP BSC devices or does it need to support all the various xAP devices
and applications which may be using different xAP schema ? eg using the
volume control on your music player , the wind direction from an
outside sensor or an infra red remote button press to control something
in JRMI ?&nbsp; This really is important to clarify now as it will
mandate
how JRMI recognises and processes xAP messages....&nbsp; Handling more
than
just BSC will be more complex both in how it is recognised and how the
user configures it.<br>
<br>
Assuming it is just BSC devices then the source= line is sufficient to
identify the specific endpoint and the incoming messages that indicate
a 'sensor' has changed will include a class=xapbsc.event.&nbsp; NB this
only
arrives on a state change. &nbsp; Additionally a class=xapbsc.info
message
will arrive periodically or when a device is queried, that affirms the
current state &nbsp;&nbsp; My recommendation would be to initially
filter
incoming messages on the class= parameter , accepting only messages
that start with xapbsc. and then you might take a different action
based on the latter part of the class message which could be one of
only four values .event &nbsp; .info.&nbsp; cmd or
.query.<br>
<br>
The first two of these ( .info and .event ) are reporting the status of
a xAP sensor and you would then inspect the source= line as the address
of the sensor and check if it matches one that you have configured in
JRMI . This full source address might have a friendlier name within
JRMI. If the sensor address is recognised you should then inspect the
new values contained within the attached output.state or input.state
body block to recover the sensors values and update JRMI.&nbsp; Note
that
actually the UID will also uniquely identify the endpoint and could be
used instead of the source= parameter but is not so intuitive to a user
when configuring.&nbsp; You can think of the UID as being a numeric
only
version of the source . This is only valid within BSC and some other
specific schema.<br>
<br>
If my understanding is correct 'Turnouts' in JRMI will be used to
originate a command message (xapbsc.cmd) destined for a xAP endpoint so
they will originate a message from JRMI with a target= line that
identifies a specific xAP BSC endpoint.&nbsp; That's fairly easy to
do.&nbsp; &nbsp;
It is important though to consider that the turnout will change the
state of a xAP output , and that may also be changed later by a direct
xAP command - does JRMI need to know that ?<br>
<br>
In the above scenario then JRMI is not reporting any of its internal
endpoints (sensors) on xAP, nor is it reporting any internal 'Turnout'
results .&nbsp; If for example some other sensor caused a turnout on
JRMI to
trigger and action a state change then xAP would not see these changes.
Nor would xAP see sensor status'.&nbsp; If this is adequate then you do
not
need to process xapbsc.cmd or xapbsc.query messages and can just drop
them.&nbsp;&nbsp; <br>
<br>
However I'm thinking you might desire that this JRMI internal state and
event information be notified onto xAP, for example to use a xAP
controller to fully control JRMI, perhaps HomeSeer.&nbsp; If so then
you
will need to create BSC endpoints for these JRMI internals and report
their status via xAP periodically, on request and upon every
change.&nbsp;
If you wish the JRMI endpoint to be directly controllable from xAP
(i.e. not via a turnout)&nbsp; then they must be presented as a BSC
output
device on xAP&nbsp; (because BSC inputs are not
controllable).&nbsp; You might
notice some similarity here in your 'virtuals' you mentioned and xAP
'virtual' devices ;-) This will require significantly more coding in
JRMI as you will effectively need to implement a bidirectional
conversation ability.&nbsp;&nbsp; You would then need to accept
incoming
xapbsc.cmd messages, validate that the target= matches one of the
internal address within JRMI and then process the command. Bear in mind
that the target= line may be wildcarded allowing it to address several
endpoints simultaneously.&nbsp; Likewise an incoming xapbsc.query
command
needs processing as it is a request to JRMI to report the status of one
of its internal sensors (or turnouts), and again it might be
wildcarded.&nbsp;&nbsp;&nbsp;&nbsp; <br>
<br>
Maybe that helps but I think Neil might be the best source as he will
understand the purpose of the xAP/JRMI integration.<br>
<br>
The full xAP BSC schema definition is here and it should be adequate
for representing up to 253 internal endpoints
within JRMI - if you need more - then we have an expanded version based
around xAP v1.3<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.xapautomation.org/index.php?title=Basic_Status_and_Control_Schema";>http://www.xapautomation.org/index.php?title=Basic_Status_and_Control_Schema</a><br>
<br>
<br>
<br>
&nbsp;&nbsp; K<br>
<br>
<br>
<br>
<br>
<br>
<br>
On 16/03/2010 18:36, Automation wrote:
<blockquote
cite="mid:EPELLGOFBFEIGBHFENEGGECKDIAA.automation@xxxxxxx"
type="cite"><span style="display:
none;">&nbsp;</span>

<div id="ygrp-text">
<p><br>
Anybody help me answer Bobs questions?<br>
<br>
In model JMRI terminology a Sensor does just that and a Turnout is what
the<br>
layman in UK would call a set of points.<br>
<br>
With my NCE DCC system I give each sensor a number xxx and JMRI then
uses<br>
the prefix N (nce) S (sensor) xxx to refer to that sensor.<br>
similarly an output (Turnout) would be N (nce) T (turnout) yyy<br>
<br>
so, for example, throwing NSxxx could operate NTyyy if NSzzz is
ON<br>
(rudimentary interlocking)<br>
<br>
Sensors and Turnouts can also be 'virtual' Route setting on my layout
can be<br>
done clicking a (virtual) Sensor on a screen which then interacts with
other<br>
Sensors status to instruct the NCE DCC system to operate the
appropriate<br>
Turnouts (outputs)<br>
<br>
VERY powerful systems can be built.<br>
<br>
Andy<br>
<br>
-----Original Message-----<br>
From: Bob Jacobsen [mailto:<a moz-do-not-send="true"
href="mailto:jacobsen%40berkeley.edu";>jacobsen@berkeley.<wbr>edu</a>]<br>
Sent: 16 March 2010 15:35<br>
To: Automation; Neil Wrightson<br>
Subject: xAP and JMRI naming<br>
<br>
I think we're pretty close to getting the xAP connection to work,
so<br>
it's time to start thinking about the next step in connecting JMRI
and<br>
xAP.<br>
<br>
Normally, when connecting JMRI and external systems, we connect
status<br>
messages from the system to "Sensors", and use
"Turnouts" to send<br>
status change commands to the external system.<br>
<br>
Using the Insteon control system as an example, when we see a
status<br>
report on Insteon address 12.34.56, we create a JMRI sensor with
the<br>
name PS12.34.56 that matches that status. Another Insteon unit
with<br>
address 45.A3.11 will get matched to a JMRI sensor called
PS45.A3.11,<br>
etc. All the JMRI tools then interact with those. You can give
them<br>
simpler user names, set options with them, etc. Similarly for<br>
outputs, where the names are PTsomething.<br>
<br>
So what's the corresponding thing for an xAP name?<br>
<br>
xap-hbeat<br>
{<br>
source=JMRI.<wbr>test.1<br>
interval=60<br>
port=10000<br>
hop=1<br>
v=12<br>
uid=FFFFFFFF<br>
class=xap-hbeat.<wbr>alive<br>
}<br>
<br>
I can construct a name string from this entire message (class,
uid,<br>
source, etc) but is that all needed? Or is just "source"
sufficient?<br>
Or perhaps source+class?<br>
<br>
If we can get a trace of a xAP installation doing something,
perhaps<br>
that'll help us figure out what a convenient, but sufficiently<br>
powerful, name convention would be.<br>
<br>
Bob<br>
<br>
No virus found in this incoming message.<br>
Checked by AVG - <a class="moz-txt-link-abbreviated"
href="http://www.avg.com";>www.avg.com</a><br>
Version: 9.0.790 / Virus Database: 271.1.1/2750 - Release Date:
03/16/10<br>
07:33:00<br>
<br>
</p>
</div>


<!-- end group email --></blockquote>
<br>




<!-- **begin egp html banner** -->

<br>



<br>

<!-- **end egp html banner** -->


<div width="1" style="color: white; clear:
both;"/>__._,_.___</div>

<!-- Start Recommendations -->
<!-- End Recommendations -->



<!-- **begin egp html banner** -->

<img src="http://geo.yahoo.com/serv?s=97476590/grpId=9674343/grpspId=1705007709/msgId=4622/stime=1268773037";
width="1" height="1"> <br>

<!-- **end egp html banner** -->


<!-- **begin egp html banner** -->

<br>
<div style="font-family: verdana; font-size: 77%; border-top: 1px
solid #666; padding: 5px 0;" >
Your email settings: Individual EmailTraditional <br>
<a href="http://groups.yahoo.com/group/xap_automation/join;_ylc=X3oDMTJmbnY3dXBnBF9TAzk3NDc2NTkwBGdycElkAzk2NzQzNDMEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA3N0bmdzBHN0aW1lAzEyNjg3NzMwMzc-";>Change
settings via the Web</a> (Yahoo! ID required) <br>
Change settings via email: <a href="mailto:xap_automation-digest@xxxxxxx?subject=Email
Delivery: Digest">Switch delivery to Daily Digest</a>  <a
href = "mailto:xap_automation-fullfeatured@xxxxxxx?subject=Change
Delivery Format: Fully Featured">Switch to Fully Featured</a>
<br>
<a href="http://groups.yahoo.com/group/xap_automation;_ylc=X3oDMTJkOWNmc24yBF9TAzk3NDc2NTkwBGdycElkAzk2NzQzNDMEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA2hwZgRzdGltZQMxMjY4NzczMDM3";>
Visit Your Group
</a>
<a href="http://docs.yahoo.com/info/terms/";>
Yahoo! Groups Terms of Use
</a>
<a href="mailto:xap_automation-unsubscribe@xxxxxxx?subject=Unsubscribe";>
Unsubscribe
</a>
<br>
</div>
<br>

<!-- **end egp html banner** -->


<div style="color: white; clear:
both;"/>__,_._,___</div>
</body>
</html>

--------------090901000000060102070301--