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
There are two common causes for this issue – colliding MQTT Client IDs or colliding Edge Node IDs.
Colliding MQTT Client IDs occur when there are two or more MQTT clients connecting to an MQTT broker using the same Client ID. The broker uses the Client ID to identify the client and the current state of the client and therefore this ID must be unique per client and broker.
Colliding Edge Node IDs occur when there are two or more Edge Nodes publishing with a topic namespace that does not have a unique combination of Group ID and Edge Node ID. In a Sparkplug compliant system, it is this combination of IDs that identifies the Edge Node.
Let’s start by confirming the connection status of the Edge Nodes with your Chariot or MQTT Distributor server instance to identify which issue you have.
From the Chariot UI navigate to Alerts in the left menu bar. Select Types and enable the alerts for MQTT_DISCONNECT
Under Live Alerts, if we can see in the logs that Chariot is logging the DUPLICATE_CLIENT_ID description, as shown below, you have Colliding Client IDs. If not, we have a Colliding Edge Node IDs issue.
From the Ignition UI connected to your instance of MQTT Distributor, navigate to Status > Diagnostic > Logs.
Set the debug level for the io.moquette.spi.impl.ProtocolProcessor logger to TRACE and set the filter of the Logs view to ProtocolProcessor.
If we can see in the logs that the MQTT broker is continually forcefully disconnecting an existing connection to allow another client with the same Client ID to connect, as shown below, you have Colliding Client IDs. If not, we have a Colliding Edge Node IDs issue.
To resolve the colliding Client IDs you will need to review your system configurations on the physical Edge Nodes identified and remove the conflicts.
In the logs if you see different IP addresses for the Edge Nodes attempting to connect with the same Client ID, then the same MQTT Client ID has been set on different physical Edge Nodes. Review the configuration for physical Edge Nodes with these IP addresses.
If using MQTT Transmission, there are two additional scenarios to consider if the logs show the same IP address for the Edge Nodes attempting to connect with the same Client ID.
In either of these two setups, the MQTT connection for each virtual Edge Node requires a unique Client ID. The Client ID in the the MQTT Transmission Configuration should be left blank allowing MQTT Transmission to auto-generate unique Client IDs for each Edge Node connection.
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]
Within a distributed system, the combination of any GROUP_ID and EDGE_NODE_ID 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.
The topic used for tags published to the MQTT Server is a combination of the MQTT Transmission 'Transmitter' configuration as well as the arrangement of tags in the Ignition tag tree. In the Transmitter configuration, the Tag Path points to the folder where the tag tree will start and the next three folders will be picked up as the group_ID, edge_ID and device_ID.
If you have not carefully managed your tag tree structure, you can create duplicate group_id and edge_id combinations.
In the video below we have two transmitters with a tag tree of Company/Location/Process Area/Line/PLC where Line is the physical Edge Node device. With the tag path for the transmitter set to My Company, we can see that both edge nodes will publish on the following namespaces:
spV1.0/Lakeside/message_type/Finished Goods/Line1
spV1.0/Lakeside/message_type/Finished Goods/Line2
Since the 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 likely create a firestorm of rebirth requests across the system.
We will use the logging associated with your Chariot or MQTT Engine instance to determine the physical or virtual Edge Nodes with duplicate Group and Node IDs.
From the Chariot UI navigate to Alerts in the left menu bar. Select Types and enable the alerts for SPARKPLUG_GROUP_EDGE_COLLISION
Under Live Alerts, we can see in the logs the Edge Node ID along with the Client IDs causing the collisions.
The next step is to review and update as necessary the configuration for each of the listed Client IDs. If using MQTT Transmission, see here for how to identify the Client IDs from Ignition Designer.
From the Ignition UI connected to your instance of MQTT Engine, navigate to Status > Diagnostic > Logs.
Set the debug level for the com.cirruslink.mqtt.engine.gateway.sparkplug.SparkplugBPayloadHandler logger to TRACE and set the filter of the Logs view to SparkplugBPayloadHandler.
You will see errors logged indicating that data messages (type of DDATA) are not being handled correctly along with rebirth requests to the duplicate Edge Node ID.
Expanding the Failed to handle DDATA message exposes the sequence number error we would expect in this scenario.
Set the debug level for the io.moquette.spi.impl.ProtocolProcessor logger to TRACE and in the filter search for the NBIRTH messages for the duplicate Edge Node ID. In this example the filter will be for Lakeside/NBIRTH/Finished Goods. Now we can see which Client IDs are responding to the requests.
The next step is to review and update as necessary the configuration for each of the listed Client IDs. If using MQTT Transmission, see here for how to identify the Client IDs from Ignition Designer.