The request path is the Sparkplug device, the network link, the MQTT Distributor module, MQTT Engine, the Ignition tag provider, and finally Ignition Historian. Follow the packet. An unchanged process value can stop producing observable events before or after the broker, while a separate changing device timestamp remains visible through the entire path.
What must the Sparkplug device publish?
Start at the source. The process metric and the time at which the device calculated or sampled it are different pieces of information. A value of 50 may remain valid through hundreds of calculations, while the calculation time changes every cycle. Sending only the process value makes those events indistinguishable downstream.
Add a dedicated device date-and-time metric to every relevant transmission. For a UDT-based design, add it as a custom timestamp member. Update that member whenever the device publishes or completes the calculation that must be observed. Do not create artificial process-value changes by adding a small offset and then restoring the original value; that writes false measurements, creates extra history records, and can trigger control logic.
| Required meaning | Metric behavior | Downstream use |
|---|---|---|
| Process state | May remain unchanged | Display, control, and process history |
| Calculation or publication time | Changes for every required event | Freshness, scripts, and communications monitoring |
| Signal validity | Quality changes when the value is invalid | Bad-quality indication and intentional trend gaps |
Check before proceeding: hold the process at a constant value and confirm at the device that the timestamp metric changes on every intended publication.
Does the physical path carry every publication?
Layer one first. A changing source metric cannot reach MQTT Engine through an unstable device link, switch port, broker interface, or gateway route. Check link state and error counters at each physical interface. Compare device transmit activity with broker receive activity during a test containing several identical process values.
| Hop | Address or port to record | Timing to compare | Proof |
|---|---|---|---|
| Sparkplug device | Configured broker destination and port | Device publication times | Transmit count advances |
| Network path | Device and broker interfaces | Same test interval | No link loss or rising error count |
| MQTT Distributor | Configured listener address and port | Broker receive times | Message count advances with the device |
| MQTT Engine | Configured broker connection and subscription path | Engine receive times | Changing timestamp metric arrives |
Read the actual addresses and ports from the running project configuration; no specific network values are implied here. If device transmissions advance but broker receptions do not, stop at the network or broker listener. If the broker count advances but MQTT Engine does not receive the metric, inspect the Engine connection and subscription path.
Check before proceeding: match one device publication containing the changing timestamp to one broker reception and one MQTT Engine reception.
Where does the identical value stop?
Test the process metric separately from the timestamp metric. A publisher can omit a metric whose value has not changed. Even when an identical value reaches the tag layer, Ignition tag change processing acts on value or quality changes; rewriting the same value is not a dependable event trigger. The reported installation runs Ignition 8.05, but the diagnostic decision comes from observing each hop rather than assigning the behavior to the version.
| Observation | Stopping point | Correction |
|---|---|---|
| Neither process metric nor timestamp leaves the device | Publisher | Make the device timestamp change for each required event |
| Timestamp reaches the broker but not MQTT Engine | Connection or subscription route | Correct the Engine path and verify message flow |
| Timestamp tag changes but process tag timestamp does not | Tag change semantics | Use the timestamp tag as the event and freshness signal |
| Live tags are correct but the trend has gaps | History storage, query, or rendering | Inspect raw samples, qualities, and trend treatment independently |
A changing timestamp member proves that a new calculation or publication occurred. It does not force every unchanged process tag to acquire a new tag timestamp.
Check before proceeding: confirm that several equal process values produce several changes on the dedicated timestamp tag while the process tag remains stable.
How should scripts detect repeated commands or calculations?
Attach the event logic to the dedicated timestamp tag, not to a process value that may repeat. When a command can legitimately carry the same contents more than once, its changing timestamp distinguishes a new command from the previous command. The script can then read the associated process or command members after the timestamp event.
- Add the timestamp member to the same logical device or UDT structure as the related values.
- Update it once for each calculation, publication, or command that must trigger downstream work.
- Configure the tag event on that timestamp member.
- Inside the event, read the related members and reject an older or duplicate timestamp if message ordering matters.
- Log the received timestamp during commissioning so each execution can be matched to a source event.
Keep value, freshness, and quality separate. A changing timestamp proves recent activity; it does not prove that the process measurement is Good. Use tag quality for validity.
Check before proceeding: send the same command contents twice with two different timestamps and verify that the timestamp event runs twice.
How should Historian and the trend handle unchanged values?
Historian storage and trend rendering must not use process-value change time as the communications heartbeat. An unchanged value can be both current and Good even when no new process sample is stored. Conversely, a recent timestamp cannot turn a bad-quality measurement into a valid one.
Use three independent channels in the display and diagnostic design:
- Trend the process tag as the measured value.
- Historize or otherwise retain the dedicated device timestamp so the last calculation or publication time is queryable.
- Use the process tag quality to decide whether the trend should show a valid segment or a gap.
If the trend still shows gaps while quality remains Good, inspect the raw historian rows around a gap. Determine whether the gap comes from missing stored samples, a query interval, aggregation, or the renderer's treatment of sparse data. Select a retrieval or rendering mode that carries the last Good value across no-change intervals only when that representation matches the process. Read the exact setting name from the installed Ignition 8.05 interface rather than applying a setting name from another release.
Check before proceeding: compare the raw process values, archived qualities, and device timestamps over one visible gap.
How do you verify the complete data path?
- Hold the source process value constant for several publication cycles.
- Record each changing device timestamp and confirm a corresponding reception at MQTT Distributor and MQTT Engine.
- Verify that the dedicated timestamp tag advances for every expected event.
- Confirm that any script attached to the timestamp tag runs once per new timestamp.
- Query Historian for both the process tag and timestamp tag over the test interval.
- Verify that the displayed process remains continuous while its quality is Good.
- In a controlled test, introduce a non-Good quality condition and verify that the trend shows a gap only for that condition.
The acceptance record should contain source publication time, broker reception, Engine reception, tag timestamp event, historian result, and displayed quality for the same test sequence.
FAQ
Can I make an MQTT Engine tag timestamp update by writing the same value?
An identical value is not a dependable tag event because Ignition tag change processing acts on value or quality changes. Publish a separate changing device timestamp and use that tag for freshness and event logic.
Does MQTT Distributor create a new timestamp for unchanged Sparkplug values?
Treat the distributor as a hop, not as the source of calculation time. Publish the calculation or transmission timestamp from the device, then verify that the same metric reaches the broker and MQTT Engine.
Can I add a timestamp member to an Ignition UDT?
Yes. A custom timestamp member in the UDT provides a changing event for repeated values and gives scripts a tag that can fire for each new calculation or command.
Does the timestamp fix work if the trend still has gaps?
Run a controlled test with repeated equal values followed by one non-Good-quality interval. Pass the final verification only when the timestamp advances for every publication, the process value stays continuous while Good, and the trend gap appears only during the non-Good interval.