The system letter for OpenLCB connections is "M". OpenLCB event and object names are introduced below, with additional details and formats on a separate page.
JMRI associates OpenLCB Events with individual JMRI objects (Sensors, Turnouts, etc.) via
the JMRI System Names. A System Name like "MS1.2.3.4.5.6.7.8;1.2.3.4.5.6.7.9"
defines a Sensor that follows the "1.2.3.4.5.6.7.8" and "1.2.3.4.5.6.7.9" OpenLCB Events to
change state.
Another format for Event ID's is a continuous hexadecimal string, such as
"x0102030405060709".
These System Names can get very long, in which case the "User Names" become much more useful.
OpenLCB messages coming into JMRI applications can be accessed via JMRI Sensor objects.
The Sensor's System Name determines which OpenLCB Events it
corresponds to.
A Sensor is defined by two Events: The one that sets it ACTIVE, and the one that sets it
INACTIVE.
The Event numbers are essentially arbitrary, and are defined by the OpenLCB Nodes that produce
them. Because Events are not intrinsically associated with specific hardware objects, and
because people can use Event ID's in many ways, the specific Event ID's for a Sensor must be
supplied.
You create Sensors using the Add... button on the Sensor Table. If you supply two
event ID's, the first will set the Sensor ACTIVE and the second will set it INACTIVE. If you
provide just one, it will set the Sensor ACTIVE, and it will automatically reset itself to
INACTIVE shortly after. This can be used for events that indicate momentary things on the
layout like "it's noon".
When "Show System-specific columns" is checked in the table, there are two additional columns shown that are specific to OpenLCB Sensors:
When not checked, JMRI will report the state of the Sensor as "unknown". This will allow some other user of these events to be the authoritative source.
Typically when Authoritative is checked, then this is better unchecked.
If there is only one authoritative source for state, then having this checked is good, because it will make JMRI converge to the correct state irrespective of how long JMRI has been running. This is particularly important if the authoritative producer / consumer of the event does not save its state between reboots.
There's also the case where you have two momentary pushbuttons for setting the Sensor (or more usually, for setting a Turnout), and those input lines believe that they are authoritative. This can confuse JMRI (because typically both are invalid). In this case, "Always Listen" needs to be unchecked.
The scheme for Turnouts is similar to Sensors above, except JMRI is producing the OpenLCB
events instead of receiving them, and the type letter is "T" instead of "S", e.g.
"MT1.2.3.4.5.6.7.8;1.2.3.4.5.6.7.9".
A Turnout is defined by two Events: The one that it produces for THROWN
and the one that it produces for CLOSED respectively.
Turnouts have Authoritative and Always Listen checkboxes that work the same as the checkboxes on Sensors.
As a special case, DCC turnouts connected via a bridge to an OpenLCB network can be addressed as e.g. MTT123. Note the 2nd T for "Turnout addressing". JMRI will then automatically generate the correct well-known events to throw/close the corresponding DCC turnout.
The scheme for Lights is similar to Sensors above, except JMRI is producing the OpenLCB
events instead of receiving them, and the type letter is "L" instead of "S", e.g.
"ML1.2.3.4.5.6.7.8;1.2.3.4.5.6.7.9".
A Light is defined by these two Events: The one that it produces for ON
and the one that it produces for OFF respectively.
Lights have Authoritative and Always Listen checkboxes that work the same as the checkboxes on Sensors.
OpenLCB connections can use many of the usual forms of SignalHeads and SignalMasts that are based on Turnouts. In addition, there's an OpenLCB-specific form of SignalMast that uses Events to change from one aspect to another.
OpenLCB connection options are on a separate page.
When JMRI is connected to a layout via this system, an OpenLCB or LCC menu is shown:
