Two machine values are being published at different times under one MQTT topic. The observed display alternates between the latest machine value and a payload containing both values when their update times align. Treat this as a payload-state and viewer-behavior issue: a later publication does not automatically preserve fields omitted from that publication.
Identify the overwrite condition
Inspect each publication independently. If one message contains only machine1 and the next contains only machine2, the topic viewer may display only the fields in the latest payload. The fact that both values appear when update times align supports this diagnosis, but the evidence does not establish whether the publisher combines those updates or MQTT Explorer merges them temporarily.
| Observed publication | Result to expect in the viewer | Engineering decision |
|---|---|---|
| Each payload contains one machine value | The latest payload may replace the previously displayed structure | Use separate topics or publish a combined state |
| Each payload contains both machine values | Both values can remain side by side after every update | Maintain the last known value for each machine before publishing |
| Sparkplug Edge Node is fully compliant | MQTT Engine is reported to show both current values in the Ignition tag browser | Verify compliance and inspect the tags in Ignition |
Select a publishing structure
If both values must always appear in one payload, maintain state in the publisher: update the changed machine value, retain the other machine's last known value, and then publish the complete structure. Conceptually, every publication should retain both keys:
{
"machine1": "current or last known value",
"machine2": "current or last known value"
}If the publisher cannot aggregate state, publish each machine value on a distinct topic beneath the required folder. This prevents one machine's payload from replacing the other within a single topic, although the values will appear as separate topic leaves rather than one combined payload.
Verify the result in the subscriber
- Capture consecutive publications and confirm whether each payload contains one machine key or both keys.
- After changing only one machine value, verify that the selected design still exposes the unchanged machine's last known value.
- If the requirement applies specifically to MQTT Explorer, confirm with that project's maintainers whether its interface can retain and display fields omitted from the latest payload.
- For a fully Sparkplug-compliant Edge Node, inspect MQTT Engine in the Ignition tag browser and verify that both current values remain available.
Separate confirmed behavior from implementation assumptions
The available evidence does not identify the publisher, payload encoding, topic path, Sparkplug implementation, or MQTT Explorer configuration. Do not assume that a subscriber will merge partial payloads. First determine whether the source publishes complete state, separate partial updates, or Sparkplug metrics; then choose aggregation, separate topics, or Sparkplug tag browsing accordingly.
FAQ
Why does one MQTT value disappear when another value publishes?
Consecutive payloads appear to contain different machine values. If the latest payload omits the previous machine key, the viewer may show only the latest payload structure.
How can I keep machine1 and machine2 visible at the same time?
Publish both keys in every combined-state payload, retaining the unchanged machine's last known value. Alternatively, place each machine value on a separate topic.
Will Ignition MQTT Engine show both Sparkplug values?
The evidence reports that MQTT Engine will show both current values in the Ignition tag browser when the Sparkplug Edge Node implementation is fully compliant. Verify Edge Node compliance and confirm both tags after changing only one value.
