OpenLCB Unique Event ID Assignment

The proposed OpenLCB depends on globally unique Event ID numbers (EIDs). This node discusses the assignment of those.

The "globally unique" requirement only refers to the universe of connected nodes; nodes that never need to communicate with each other don't need to have separate Event IDs. In general, however, nodes can move: They can be sold or loaned for use on another layout, nodes on modular layouts can be connected to other arbitrary modules, and few assumptions can be made. Therefore, we require globally uniqueness for all EventIDs.

Ensuring Uniqueness

To ensure uniqueness, the top 6 bytes of EventIDs that you define are required to be within the NodeID space that you control. The low two bytes would be any number you prefer, so long as you use each value for only one event.

This requirement applies equally to events defined by a hardware node, e.g. by button pushing, a software node in a computer, or EventIDs that are defined by a human writing them on a piece of paper. In each case, the thing doing the definition must ensure it has control over the NodeID corresponding to the top four bytes, so it can ensure that the EventID not be reused.

Table 1: Event Number Construction

Using IDs for real nodes

The Node ID part could be e.g. from real nodes that you own. For example, the Blue/Gold algorithm for assigning Event IDs automatically puts the Node ID of the first node to use that event in the Event ID, guaranteeing it to be unique.

Using allocated IDs

Not all Event IDs need to be assigned using the IDs of real nodes that actually exist as hardware. The only requirement is that they be based on a Node ID owned by the allocator.

For example, a software configuration tool might define events and assign Event IDs to them. A board manufacturer may prefer some other pushbutton configuration process. A modular club may decide that certain events form the “boundaries” of modules, and need to be assigned well-known Event IDs to make it easier to create large modular layouts. Whatever the method, the Event IDs need to be globally unique, and we ensure that by requiring that people create EventIDs using node ID numbers assigned to them (and therefore not assigned to anybody else), plus an additional 16 bits that they are responsible for using only once.

Note that the Node ID part of an Event ID doesn't have to correspond to any physical node. So long as you've got some Node ID address space assigned to you, you can use that. For example, a fast-clock manufacturer might want to define a range of EventIDs so that a different event is emitted every fast minute. (This lets e.g. lamp controllers do day-night cycles automatically). For the sake of argument, let's say 24 bits worth of specific events are needed (it's actually smaller, but let's use this). The manufacturer has a large range of node IDs assigned already, so can use 8bits worth of that space, plus the extra 16 bits in the EventID below the nodeID-like-part, to do this. For example, if a manufacturer had a range of Node IDs that included at least 0x123456789A00 through 0x123456789AFF (in other words, all possible values of the low byte), he could create a set of Event IDs with the low 24 bits used to carry a time value:

Table 2: Example of defining a Set of Events

This is guaranteed to be unique, no matter where one of these devices is taken, because the node ID range is guaranteed to belong to the manufacturer, and he'll use it only once.

Well-known Event IDs

Because events are a very convenient way to broadcast information to the entire network, we define some well-known global event IDs to convey certain kinds of events. As examples, “global emergency stop”, of interest to all, and “this node logged a message”, where the specific node can be identified from the source ID of the event message. These use a 6-byte node-ID-part that's reserved to OpenLCB itself, and then globally defined lower 16 bits.

For the entire list, see a separate spreadsheet.

Site hosted by

This is SVN $Revision: 1491 $