MQTT Troubleshooting

Symptom	Troubleshooting Steps
ACM cannot connect to a broker	Ensure that an MQTT test client can connect to that broker using the same settings & certificates, from the same machine running ACM.
An existing connection was forcibly closed by the remote host	ACM is secure by default, meaning it requires a certificate at all times. If the broker does not have a certificate configured, it could result in this error.
Alias group items are not polled	Ensure device is assigned to alias group Within the alias group, is the “MQTT” option checked? Is an interval assigned to the alias group? Are items within the Alias Group valid? Test with OPC client Are schedules assigned to devices configured correctly? Does the schedule have an interval defined to match the one in the alias group?
Alias group items are not published via MQTT	Is anything being published via MQTT? Even if no devices/alias groups are configured, you should see NBIRTH published when ItemServer starts up. If not, the issue is in Server Monitor broker settings, not ACM (object) Configuration. Has the device polled yet? Even if properly configured, a DBIRTH will not be sent until ACM has values for at least some of the items. Is ItemServer connected to asiDATA? ItemServer will log when it connects to/disconnects from asiDATA. Upon disconnect, it will issue NDEATH, and all items will then go stale in subscribed MQTT clients. Do any of the alias names contain dots? Alias names with dots are not supported for the 9.1 release. For example, My.Alias would not publish successfully via MQTT.
Only some alias group items are published for a given device	Sometimes ACM will publish a DBIRTH with the items it has values for, then publish a new DBIRTH when additional items come in (perhaps on different intervals). Items on different intervals will likely publish in separate DDATA messages. Even some items on the same interval may publish in separate DDATA messages, depending on poll timing.
ACM just resent DBIRTH messages for every device using an alias group	The Sparkplug B spec is a little ambiguous on what to do if a client gets a DDATA packet without first receiving a DBIRTH (or missing the DBIRTH for whatever reason - restart, object deleted from client config, etc.). If this happens, older clients will issue an NCMD to request rebirth of all devices on a node (ACM). In practical terms, this means if ACM sends a DDATA that an MQTT client doesn’t expect, the client will send an NCMD rebirth request, and ACM will send a new NBIRTH and new DBIRTH messages for every device using an alias group. More recently, clients have begun adding support for DCMD rebirth requests - meaning the client will ask for rebirth of just the device in question. ACM will add this functionality in an upcoming release.
MQTT item (metric) writes are not working	Some MQTT clients have settings to block NCMD & DCMD messages. Changes to these settings may be required for item writes to function.
Device is not showing up in MQTT client	Some MQTT clients have settings to block NCMD & DCMD messages. Changes to these settings may be required for the client to send rebirth messages.