OpenLCB connection options are on a separate page.
The default 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".
You can also assign your own names to EventIDs and use those to create Turnouts, Sensors, Lights, Signal Masts and StringIOs. See the page on OpenLCB names for more information on this.
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".
As a special case, layout sensors connected via a bridge to an OpenLCB network can be addressed as e.g. MSS123. Note the S in the 3rd position for "Sensor addressing". JMRI will then automatically generate the correct well-known events to represent active/on and inactive/off for the sensor.
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 connections can use StringIOs to create shared variables across multiple JMRI instances, and perhaps someday other OpenLCB hardware that supports string input and output. To do this, you create the same StringIO within each JMRI instance, using the same Event ID. Once you've done that, updating the string value in one instance will update the value in all of the others in the different JMRI instances connected to the same OpenLCB network. You can then configure LogixNG or scripts to communicate using that.
The OpenLCB or LCC menu contains:
