JMRI® connects to...
Supported Hardware
Devices, command stations, networks, and protocols:
By the community of
JMRI tools for working with your layout:
Layout Automation
Use JMRI to automate parts of your layout and operations:

JMRI Help:

Contents Index
Glossary FAQ

Donate to JMRI Donate to

Hardware Support: OpenLCB

The support on this page is rapidly evolving; the actual code might be ahead or behind the documentation on any given day.


JMRI provides support for general JMRI Sensors and Turnouts in terms of OpenLCB "events".


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.;" defines a Sensor that follows the "" and "" 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 send 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:

Normally checked, this means that the JMRI Sensor will report its state when a query comes from another OpenLCB node. That will then allow that other node to adjust its own state to be consistent.

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.

Always listen
When checked, all state reports will update local Sensor state. When unchecked, state reports will update local Sensor state only if the local state is UNKNOWN. State change messages (Event Reports) always change local state. Might be helpful to uncheck this if the Sensor state flip-flops multiple times after a query, which means that the Sensor does not have a consistent distributed state.

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 emitting the OpenLCB frames instead of receiving them, and the type letter is "T" instead of "S", e.g. "MT1.;".

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 events to throw/close the corresponding DCC turnout.


The scheme for Lights is similar to Sensors above, except JMRI is emitting the OpenLCB frames instead of receiving them, and the type letter is "L" instead of "S", e.g. "ML1.;".

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.

JMRI OpenLCB Tools


When JMRI is connected to a layout via this system, an OpenLCB menu is shown: