MQTT Engine Namespaces: Custom, Not Sparkplug B for UNS Tags

MQTT Engine tag refresh can fail when UNS-style topics are mapped through the built-in Sparkplug B namespace. In an Ignition Maker 8.3.2 test system using Cirrus MQTT Engine and an EMQX broker, the corrective path is to place those tags in a custom namespace and disable the Sparkplug B namespace completely.

Where does the MQTT data path stop?

Follow the packet from the publishing MQTT client to EMQX, then from EMQX to MQTT Engine, and finally into the Ignition tag tree. The observed symptom is downstream of the broker connection: MQTT Engine creates or exposes data under both the UNC namespace and the Edge Nodes folder, but tag values do not refresh as intended.

Layer one first. Confirm that the publisher, broker host, and Ignition gateway have working network interfaces and a viable path between them. Then inspect the broker connection rather than using visible tag folders as proof that current messages are flowing. Existing tag nodes can remain visible even when no new payload reaches the namespace handler.

The label UNC appears in the observed configuration, while the intended architecture is described as UNS tags. Treat those as different labels until the configured namespace definition proves otherwise. The check is complete when one new source change can be correlated with a newly received broker message.

Is MQTT Engine connected to the intended broker session?

Verify the MQTT Engine connection that points to EMQX before changing namespace rules. A valid TCP path alone does not prove that the MQTT client session is subscribed to the intended topic hierarchy. Compare the configured broker address, listener port, security mode, credentials, and topic filters with the publisher configuration. Read the actual values from the MQTT Engine and EMQX configuration; no address or port value is specified for this installation.

Use a controlled payload change rather than a reconnect as the test stimulus. A reconnect proves session establishment, while a changed payload proves that the subscription path carries application data. Compare the MQTT Engine log timestamp with the broker-side arrival timestamp. If EMQX receives the message but MQTT Engine does not, troubleshoot the subscription, authentication, or broker-to-engine connection before touching tags.

Proceed only after the broker and MQTT Engine show the same controlled message on the intended session.

Does the built-in Sparkplug B namespace match the payload?

The built-in Sparkplug B namespace is a special parser and state model for Sparkplug B messages. It is not a general-purpose container for arbitrary UNS topic structures. Editing that namespace to represent UNS tags can direct messages into Sparkplug-specific processing and create unexpected tag placement under Edge Nodes.

Select the namespace from the payload contract, not from the desired folder name. Use the Sparkplug B namespace only when the publisher emits Sparkplug B messages that match that namespace's expected topic and payload semantics. Use a custom namespace when the publisher supplies a custom UNS topic hierarchy that needs direct mapping.

The passing check is an active custom namespace containing the intended UNS mapping, with the Sparkplug B namespace fully disabled when no Sparkplug B traffic is required.

How should the custom namespace be commissioned?

Build the replacement configuration in a controlled order so each change has one observable result.

1. Record the current broker connection, namespace enable states, and the exact topic path used by the publisher.
2. Create a new custom namespace for the UNS tags. Do not repurpose the built-in Sparkplug B namespace.
3. Configure the custom namespace to match the publisher's actual topic hierarchy. Preserve topic levels and separators exactly as received.
4. Disable the Sparkplug B namespace completely if this broker connection is not intended to process Sparkplug B messages.
5. Save the configuration and verify that the displayed state remains disabled after the module or gateway returns to service.
6. Publish one controlled value change and inspect the custom namespace for the corresponding update.

Changing Default Tags Enabled alone is not equivalent to disabling the namespace. The installation already had that option disabled across several restarts while data continued to appear under both locations. The decisive configuration change is separation: custom UNS mapping in a custom namespace, with the special Sparkplug B namespace disabled.

This stage passes when the controlled value first appears through the new custom namespace and no newly processed copy appears under Edge Nodes.

Why do deletion, toggling, and reinstallation fail to fix it?

Deleting generated tags removes an output object; it does not change the namespace that processes the next incoming message. If the same handler remains active, the next matching message can recreate the same structure. Toggling the module changes runtime availability but does not prove that the namespace selection is correct. Reinstalling the module likewise does not demonstrate that the effective namespace configuration has changed.

Separate configuration state from broker state during diagnosis. Existing tag folders, cached values, or messages already present at the broker can obscure the result of a namespace change. Do not judge the fix from folder existence alone. Mark the test with a new source value that has not previously been used, note its publication time, and trace only that update.

The check passes when a unique test value follows only the intended namespace path after runtime recovery.

How is the end-to-end repair verified?

Verification must prove transport, subscription, namespace selection, and tag refresh in one trace. Choose a source value that can be changed safely and identify its exact MQTT topic. Record the tag's current value, then publish a distinct new value.

1. Confirm that EMQX receives the changed value on the expected topic.
2. Confirm that MQTT Engine receives the same post-change message through the intended broker connection.
3. Confirm that the custom namespace processes the message.
4. Confirm that the target Ignition tag changes without deleting tags, restarting the module, or reinstalling components.
5. Repeat with a second distinct value to prove continuing refresh rather than one-time tag creation.
6. Check that no newly processed duplicate appears under Edge Nodes when the Sparkplug B namespace is disabled.

The final passing condition is two successive source changes arriving through EMQX, updating the intended custom-namespace tag, and producing no new Sparkplug B namespace copy.

FAQ