# Phantom events generated during Sparkplug B DBIRTH corrupt historian-based KPI statistics

**URL:** <https://forum.inductiveautomation.com/t/phantom-events-generated-during-sparkplug-b-dbirth-corrupt-historian-based-kpi-statistics/112423>\
**Category:** 3rd Party Modules\
**Tags:** perspective\
**Created:** [November 25, 2025, 2:51pm UTC](https://forum.inductiveautomation.com/t/phantom-events-generated-during-sparkplug-b-dbirth-corrupt-historian-based-kpi-statistics/112423 "2025-11-25T14:51:43Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![marco.moiron](https://avatars.discourse-cdn.com/v4/letter/m/e99b99/32.png) [@marco.moiron](https://forum.inductiveautomation.com/u/marco.moiron)\
**Post date:** [November 25, 2025, 2:51pm UTC](https://forum.inductiveautomation.com/t/phantom-events-generated-during-sparkplug-b-dbirth-corrupt-historian-based-kpi-statistics/112423/1 "2025-11-25T14:51:43Z")

</div>

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.