Store & Forward not buffering scripted transmission.publish() messages when broker is offline

We have MQTT Transmission configured (Ignition 8.3.3) with a disk-based History Store enabled. We are publishing messages using:

system.cirruslink.transmission.publish(“abc”, “topic/test”, ‘{“value”: 1}’, 1, False)

system.cirruslink.transmission.publish(“abc”, “topic/test”, ‘{“value”: 2}’, 1, False)

system.cirruslink.transmission.publish(“abc”, “topic/test”, ‘{“value”: 3}’, 1, False)

Test procedure:

  1. Confirm Transmission is connected.

  2. Stop MQTT Distributor (broker offline).

  3. Execute multiple transmission.publish() calls (QoS 1).

  4. Verify MQTT Transmission → Records.

  5. Restart broker.

Observed behavior:

  • No records are queued while broker is offline, indeed.

  • Upon broker restart, only the last successfully published message appears. (value = 3)

  • Earlier publishes executed while offline are not delivered. (value 1 and 2)

Expected behavior:
With History Store enabled and QoS 1, scripted publishes should be queued and forwarded once the broker reconnects.

We observe the same behavior with UNS Transmitter enabled, and writing different tag values when MQTT Distributor is offline.

Question:
Is it possible to use Store&Forward to replay all the messages in the correct sequence when the MQTT Broker is live again?

1 Like

Store and Forward only applies to tags under the scope of a Transmitter in the MQTT Transmission module. The scripted publishes are completely outside of the Sparkplug session used by the Transmitter config. Is it possible for you to change your process to utilize tags that could be under the scope of a Transmitter?

For example, the output of your script could write to tags instead of using the publish API. Since tag writes will result in a tag change, they will be picked up by Transmission. They will also then be under the scope of a Transmitter and as a result, store and forward would apply.

Thanks for the clarification. That makes sense, we’ll shift our approach to write to tags instead…

Can you confirm if the UNS transmitter handles Store and Forward the same way as a “classic” transmitter in this scenario?

The UNS Transmitter does not do this. Store and Forward is a capability provided via Sparkplug. The UNS Transmitter does not use Sparkplug.