LE Sparkplug Edge Node
4 min
litmus edge collects data from plcs and other industrial equipment and publishes it to its internal message broker a scada system or historian reads from an mqtt broker instead, and expects the sparkplug topic namespace, binary payloads, and an explicit online or offline state for every device the le sparkplug edge node reads device, tag, and digital twin metadata from the litmus edge api, subscribes to live values on the internal message broker, and publishes both to your mqtt broker as sparkplug b 3 0 0 https //sparkplug eclipse org/specification/ each devicehub device and each digital twin instance becomes one sparkplug device on an edge of network (eon) node what it does publishes every devicehub device and every enabled digital twin instance as a sparkplug device, declaring each metric with its name, alias, and datatype in a birth certificate streams live tag values as ddata as they arrive from litmus edge publishes ddeath when a device goes offline, and ndeath when its own session ends — itself on shutdown, or from the broker's will message if it stops abruptly rebuilds the birth set when litmus edge topology changes, so a device or tag added, changed, or removed keeps the host's metric view correct accepts ncmd and dcmd commands from the host application key features multiple mqtt brokers with failover primary host application state gating store and forward buffering while the broker is unreachable tls and mutual tls to the broker include and exclude filters per data source prometheus metrics and an http health endpoint birth and death sequence numbers ( bdseq ) that survive container restarts how it works flowchart lr dev\[plcs and devices] > le\["litmus edge\<br/>devicehub, digital twins"] le >|metadata and live values| spb\["le sparkplug\<br/>edge node"] spb >|"nbirth, dbirth, ddata, ddeath"| br\[mqtt broker] br > host\["host application\<br/>scada, historian"] host >|"ncmd, dcmd"| br br >|commands| spb on every startup the node reads configuration from config json , environment variables, or both environment variables win on conflict connects to litmus edge , authenticating to the api with a token and connecting to the internal message broker connects to the mqtt broker , registering the ndeath payload as the will message during connect so the broker announces the node's death even if the node loses power publishes the birth set — nbirth , then one dbirth per device with primary host application support enabled, nothing is published until the host reports online streams values as ddata , keyed by the aliases declared at birth deployment modes the node runs as a container, either on the litmus edge device itself or on a separate machine mode where it runs litmus edge connection typical use internal on the litmus edge device, as a litmus edge application found automatically on the local docker network no hostname or broker credentials needed production deployments external on any other host with docker over the network, using the litmus edge hostname and an api account key central deployments, testing, or one container serving a remote litmus edge instance both modes run the same image and the same configuration keys internal mode is the default; external mode is switched on with edge external=true