Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

There are two common causes for this issue – colliding MQTT Client IDs or colliding Sparkplug Edge Node IDsDescriptors.

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 Descriptors 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 and is the 'Sparkplug Edge Node Descriptor'. Every Sparkplug Edge Node Descriptor within a Sparkplug environment must be unique.


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.

...

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 Sparkplug Edge Node IDs Descriptors issue.

Anchor
DistributorClient
DistributorClient
MQTT Distributor

From the Ignition UI connected to your instance of MQTT Distributor, navigate to Status > Diagnostic > Logs.

Tip
Read the user manual Diagnostic Diagnostics - Logs explaining how to use the Logs console in Ignition 

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.

Image Removed

Descriptors issue.

The logging shows both the Client Id and the associated IP addresses.

If running MQTT Distributor 4.0.13 or earlier, set the debug level for the io.moquette.spi.impl.ProtocolProcessor logger to TRACE and set the filter of the Logs view to ProtocolProcessor.

Image Added

If running MQTT Distributor 4.0.14 or later, logging will come out as warnings for the com.cirruslink.chariot.server.core.PacketHandler logger.

Image Added


Anchor
ResolvingCollidingClientID
ResolvingCollidingClientID
Resolving Colliding Client ID

...

Tip
Refer to the MQTT Transmission Transmitters and Tag Trees Tutorial/HowTo for detail on how a virtual Edge Node is dynamically created.

Anchor

...

CollidingEdgeNodeDescriptor

...

CollidingEdgeNodeDescriptor
Colliding Edge Node

...

Descriptors

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 In a distributed Sparkplug compliant system, it is the combination of any GROUP_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 EDGE_NODE_ID must be unique because 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.

...

If you have not carefully managed your tag tree structure, you can create duplicate group_id and edge_id combinationsSparkplug Edge Node Descriptors.

Note
You can override the functionality of pulling the namespace directly from the tag path by setting the Sparkplug IDs directly for the Group ID, Edge Node ID and, optionally, Device ID. If configured, these elements will be used in the topic namespace and the payload will be the folders pointed to by the Tag Path.

...

Transmitter on Edge 2 named Lakeside Finished Goods Line 2           spV1.0/Lakeside/message_type/Finished Goods/Line2

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.

...

Now we can use the logging associated with your Chariot or MQTT Engine/Distributor instance to determine the physical or virtual Edge Nodes with duplicate Group and Sparkplug Edge Node IDsDescriptors.

Anchor
ChariotEdgeNode
ChariotEdgeNode
Chariot

...

From the Ignition UI connected to your instance of MQTT Engine, navigate to Status > Diagnostic > Logs.

Tip
Read the user manual Diagnostic Diagnostics - Logs explaining how to use the Logs console in Ignition 

...

You will see errors logged indicating that data messages (type of DDATA) are not being handled correctly along with rebirth requests to the duplicate Sparkplug Edge Node IDDescriptors.



Expanding the Failed to handle DDATA message exposes the sequence number error we would expect in this scenario. 

...

To identify the MQTT Client ID for each Edge Node in Designer, select the Tag Browser MQTT Transmission and expand the Transmission Info folder tree for each of your transmitters to expose the MQTT Client. ID. 


Anchor
ResolvingCollidingEdgeNodes
ResolvingCollidingEdgeNodes
Resolving Colliding Edge Nodes Descriptors

To resolve the colliding Edge Node IDs Descriptors you will need to review your system configurations which generated each of the conflicting Edge Nodes Descriptors and remove the conflicts.

...

From the Ignition Logs view, select the Download icon to download a copy of the system-name.idb file to your local file system. You will need to compress (zip, 7z or rar) this file before sending to Support.



Excerpt Include
CLD80:FAQ: Ignition Modules
CLD80:FAQ: Ignition Modules
nopaneltrue

...