"Network management" means different things to different people. This node discusses some of these.
In general, OpenLCB does not require any central resources at run time. (There are some centralized aspects to the allocation of Node ID numbers) Instead, the various forms of node management can be done by one or more nodes that implement various standard and optional interactions.
A "node monitor" checks to make sure that all known nodes are reachable....
If a device wants to detect nodes that become unreachable, it can periodically poll nodes with a "Verify Node ID" addressed to the specific node. Since every message carries the Node ID of the originating node, these polls are only required to check nodes which are not emitting other messages within the required time interval.
To find all currently accessible nodes, the node monitor can issue an unaddressed (global) “Verify Node ID”, which will generate a response from all accessible and functional nodes. This should be done sparingly, however, as it will generate a lot of unnecessary traffic on a functioning OpenLCB network.
An "error logger" centralizes access to error information from nodes. The note on Logging provides more information on the OpenLCB logging protocol.
An error logger can learn about new log entries either by listening for the well-known EventID that indicates a new entry, or by polling a list of nodes for new entries.
Provides a way to save and restore the state of all or part of an OpenLCB installation.....
See also the "Start of Day" example.
Note that events are not, themselves, indications of state. Rather, they are (possible) transitions of the overall state of the layout. Knowning that two separate producers sent different events (one “on” and the other “off”) doesn't tell you the state of the railroad, because you don't know which order those events occurred or whether anything else changed.
Site hosted by
This is SVN $Revision: 721 $