Contents
Cirrus Link Resources
Cirrus Link Website
Contact Us (Sales/Support)
Forum
Cirrus Link Modules Docs for Ignition 7.9.x
Inductive Resources
Ignition User Manual
Knowledge Base Articles
Inductive University
Forum
...
Online DateTime | DateTime | The time at which the first NBIRTH message for a connection was received by MQTT Engine |
Rebirth Requests
MQTT Transmission uses the Sparkplug B specification which defines the topic namespace to publish data as spBv1.0/group_ID/message_type/edge_ID/[device_ID]
In a Sparkplug compliant system, it is the combination of Group ID and Edge Node ID that identifies the Edge Node and is the 'Sparkplug Edge Node Descriptor'.
Every Sparkplug Edge Node Descriptor within a Sparkplug environment must be unique because these are used as 'addresses' in the system to identify the edge node. It is a bit like having two houses with the same postal address. It isn't possible for other MQTT clients in the system to tell where messages are coming from and when sending messages to them, they will both receive the messages.
Since the Sparkplug Edge Node Descriptor (group_id = Lakeside and edge_id = Finished Goods) does not uniquely define the edge node, data from these two transmitters will sent with the same topic resulting in the next message sequence number expected by the MQTT client being incorrect.
As a result, the MQTT Client will mark the data as stale and request a rebirth from the transmitter. Depending on the frequency of the published data this manifests as the data from different edge nodes toggling between stale and healthy. If you have multiple MQTT Clients subscribing to the namespace, this will also likely create a firestorm of rebirth requests across the system.
Rebirth (Last) Cause | String | The reason for the last rebirth request (available 4.0.22 onward) Reasons are:
|
...