Hello everyone,
We are running a Unified Namespace using Ignition’s MQTT Transmission module with Sparkplug B, publishing into Canary. Our environment includes both high-frequency industrial process tags and very low-frequency quality-analysis results.
Whenever Ignition’s MQTT Transmitter generates a DBIRTH—typically triggered by tag creation, tag edits, module restarts, or minor network interruptions—the transmitter republishes all existing tag values with a new timestamp, even when no real process change has occurred.
From a Sparkplug B protocol perspective this is expected behavior, since a DBIRTH message is meant to provide a complete state snapshot. However, for historians and analytical systems, this creates phantom events:
Tens of thousands of artificial events can be generated during each DBIRTH
These events destroy the natural temporal spacing of low-frequency variables
The result is distorted KPIs, including incorrect average values and inflated standard deviations
At this point, our production team no longer trusts the statistical values produced when Sparkplug B data flows into the historian, and must fall back to the legacy system for quality KPIs.
If you have seen similar behavior—especially when combining Sparkplug B with low-frequency or laboratory-type data—please share your observations or any workarounds you found.
This issue has been reported to the involved vendors, but since it aligns with the Sparkplug B specification, there is limited progress so far. Showing that this affects multiple users may help drive improvements or new options for handling DBIRTH metrics in the future.