MQTT Transmission - Reducing Tag Pacing Period in a Safe Way

Ignition Modules
1

We are running MQTT Transmission and publishing Sparkplug B messages to HiveMQ, where a Data Hub policy script iterates over payload.metrics and calls addPublish() for each metric. HiveMQ enforces a hard limit of 100 addPublish() calls per script invocation, so any DDATA message containing more than 100 metrics causes the excess to be silently discarded.

We have found that lowering the Tag Pacing Period in MQTT Transmission to 100 ms effectively reduces the number of metrics bundled into each published message, keeping us well under the 100-metric threshold and eliminating the data loss we were seeing on the HiveMQ side.

Is reducing the Tag Pacing Period a safe approach for limiting the maximum number of metrics per Sparkplug B message in a production environment? Are there any known side effects or risks associated with running at a very low pacing interval such as 100 ms? Is there a way to make sure that we keep the metrics bundle under a specific value (e.g. 100)?

2

Is reducing the Tag Pacing Period a safe approach for limiting the maximum number of metrics per Sparkplug B message in a production environment?

Yes - this should be fine. Another option may be to split the tags into more Sparkplug Devices so there are fewer tags under the scope of each Device.

Are there any known side effects or risks associated with running at a very low pacing interval such as 100 ms?

No, this should also be fine as long as the MQTT Server and downstream applications can handle it.

Is there a way to make sure that we keep the metrics bundle under a specific value (e.g. 100)?

No, this is not an option today.

1 Like