Cirrus Link Website
Contact Us (Sales/Support)
Forum
Cirrus Link Modules Docs for Ignition 8.1.x
Cirrus Link Modules Docs for Ignition 7.9.x
Ignition User Manual
Knowledge Base Articles
Inductive University
Forum
In the example below, the Connected value 3 of 3 indicates 3 MQTT Clients are connected to the MQTT Server and 3 MQTT Clients are created. 
Let's look at the scenarios when not all your MQTT Clients show as being connected.
Remember that remote MQTT Clients will need to be able to establish a TCP/IP socket connection to TCP/IP ports #1883 and port #8883. On the machine hosting your MQTT Server, you must either turn off firewalls or at a minimum allow inbound connections to these ports.
Review the Microsoft Create an Inbound Rule doc for assistance on a Windows platform
Single MQTT Server configured
If you have a single MQTT Server configured, the clients are not able to connect because either the Server is unavailable, the network connection to the Server is unavailable or the connection to the Server is being refused.
You can confirm this from the Ignition UI connected to your instance of MQTT Transmission by navigating to Status > Diagnostic > Logs.
If the Server or connection to the Server is unavailable, you will see errors logged from the TransmissionClient logger indicating that the clients continually attempting to connect and failing.
If your MQTT Server is available but requires an authenticated connection to be made and the Username/Password configured in your MQTT Transmission server is incorrect, you will also see the error Bad username or password errors logged.
If you have multiple MQTT Servers configured within the same Server Set, the MQTT Clients will only connect to one server in the set. You would expect that only one server would show MQTT Clients connected as in the example below:
If the MQTT Clients lose connection to the connected server, they will attempt to connect to the next server in the set until a connection is established.
If none of the servers defined in the server set are available, you will see errors logged from the TransmissionClient logger indicating that the clients continually attempting to connect and failing.
You can confirm this from the Ignition UI connected to your instance of MQTT Transmission and navigating to Status > Diagnostic > Logs.
If your MQTT Server is available but requires an authenticated connection to be made and the Username/Password configured in your MQTT Transmission server is incorrect, you will also see the error Bad username or password errors logged.
Multiple MQTT Servers not in a server set
If you have multiple MQTT Servers configured in different Server Sets and Transmitters configured to use those different sets, the MQTT Client connections are independent for each Server Set.
Follow the trouble shooting steps for a Single MQTT Server configured for a each server showing MQTT Clients that are not connected.
In this instance, you most likely have an ACL at the MQTT Server that is preventing a specific MQTT Transmission client from connecting.
With the following ACL, the Transmission client My MQTT Group/PLC 1 is able to connect and subscribe but client My MQTT Group/PLC 2 is not authorized to connect with the LWT of spBv1.0/My MQTT Group/NDEATH/PLC 2.
R #, W spBv1.0/My MQTT Group/+/PLC 1/#
If an MQTT Transmission client attempts to subscribe on a topic that is not allowed by the ACL for that client, the connection will fail and the client will not attempt to reconnect.
With the following ACL, the Transmission client is not able to subscribe to the NCMD and DCMD topics
|
With the following ACL, the Transmission client can publish the NBIRTH for PLC 1 but is not able to publish the DBIRTH for edge node device D1
|
In this instance, you most likely have a ClientID collision at the MQTT Server. 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.
Let's confirm by checking the connection status of the Edge Nodes with your Chariot or MQTT Distributor server instance.
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. 
From the Ignition UI connected to your instance of MQTT Distributor, navigate to Status > Diagnostic > Logs.
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.
The logging shows both the Client Id and associated IP address.
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. 
If running MQTT Distributor 4.0.14 or later, set the debug level for the com.cirruslink.chariot.server.core.PacketHandler logger to TRACE and set the filter of the logs to PacketHandler.
Resolving Colliding Client IDs
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 in the logs you see the same IP address for the Edge Nodes attempting to connect with the same Client ID then either:
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.
A unique MQTT Client is created for each valid EdgeNodeID identified by the MQTT Transmission module.
If no MQTT Clients have been created, the MQTT Transmission module was not able to identify any configured EdgeNode. There is no requirement for the Edge Node to contain any any tag data.
As an example, in the tag tree below we have created a two level folder structure. Using the default Transmitter configuration, the MQTT Transmission module will dynamically create three Edge Nodes named Line1, PLC1 and PLC2 each with GroupID = Facility 1.
There will be an MQTT Client for each Edge Node and you will see on the Servers tab the count of the MQTT Clients and their connected status.
If we change the Transmitter configuration to add a Tag Path, say Facility1, the MQTT Transmission module will not identify any Edge Nodes. This is because the first level under Facility1 will be determined as the GoupID and there are no folders below to be used as the EdgeNodeID.
As a result the Servers tab will show 0 MQTT Clients created and connected.
Resolving lack of identified Edge Node IDs
To resolve the lack of identified Edge Node IDs, you will need to review your Transmitter and Ignition tag tree configurations.
If the troubleshooting tips did not help you resolve your issues, please open a ticket with Support making sure to include the MQTT Transmission or MQTT Distributor logs as appropriate.
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.
Additional Resources
