# MQTT Store & Forward

**URL:** <https://forum.inductiveautomation.com/t/mqtt-store-forward/65275>\
**Category:** Ignition\
**Created:** [October 17, 2022, 12:20pm UTC](https://forum.inductiveautomation.com/t/mqtt-store-forward/65275 "2022-10-17T12:20:07Z")\
**Posts on this page:** 17\
**Page:** 1

<div class="post-metadata">

**Author:** ![Bogdan\_Persa](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Bogdan\_Persa](https://forum.inductiveautomation.com/u/Bogdan_Persa)\
**Post date:** [October 17, 2022, 12:20pm UTC](https://forum.inductiveautomation.com/t/mqtt-store-forward/65275/1 "2022-10-17T12:20:07Z")

</div>

Good morning,

Thank you to those who have answered my beginner questions so far, they have been quite helpful in building my confidence with the platform.

The current dilemma I am facing:

I am passing an analog value from ignition edge to the ignition gateway through MQTT. Store & Forward is enabled.

In the designer, on the gateway side, the tag populates under "MQTT Engine", and then I have created a reference tag monitoring the source tag path. The history is enabled on this reference tag, and it properly records history, until there is a connection interruption to the edge node, and the history does not populate when connection is re-established.

The question is, would the reference tag "see" all the values coming in batches, after connection is re-established, and log it to the configured historian? Or would I have to set-up history on the original tag that the MQTT system is publishing ?

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/2/d/2d6836fed6d7371f1f9fdc0865f67881415806f4.png)

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/b/f/bfddc17268cb927a0c80e5ba86fe54558658e624.png)

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/0/4/049aa57a169d1af7c128a83ba290382474fd9bf9.png)

---

<div class="post-metadata">

**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\
**Post date:** [October 17, 2022, 12:35pm UTC](https://forum.inductiveautomation.com/t/mqtt-store-forward/65275/2 "2022-10-17T12:35:04Z")

</div>

The latter option. Ref tags don't receive backfill data to log into history which is a big issue! And mqtt tags disappear from the tag provider if a connection is down long enough... And when they come back, historic configuration on the tags is lost, so you'll need to setup a script to add the history config again. It's a big pita

---

<div class="post-metadata">

**Author:** ![Bogdan\_Persa](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Bogdan\_Persa](https://forum.inductiveautomation.com/u/Bogdan_Persa)\
**Post date:** [October 17, 2022, 1:03pm UTC](https://forum.inductiveautomation.com/t/mqtt-store-forward/65275/3 "2022-10-17T13:03:43Z")

</div>

Thanks for your reply!

So I should be able to set up tag history on the original MQTT tag, and disable it on the reference tag, and still be able to use the reference tag in components such as a power chart, and it will pull the history from the original tag?

---

<div class="post-metadata">

**Author:** ![Bogdan\_Persa](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Bogdan\_Persa](https://forum.inductiveautomation.com/u/Bogdan_Persa)\
**Post date:** [October 17, 2022, 1:41pm UTC](https://forum.inductiveautomation.com/t/mqtt-store-forward/65275/4 "2022-10-17T13:41:07Z")

</div>

Also, additionally, if I loose the tag history configuration and require a script to reconfigure on it's own, will tagid change in the DB ?

---

<div class="post-metadata">

**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\
**Post date:** [October 17, 2022, 7:21pm UTC](https://forum.inductiveautomation.com/t/mqtt-store-forward/65275/5 "2022-10-17T19:21:12Z")

</div>

> [@Bogdan\_Persa](#):
>
> and it will pull the history from the original tag

😬Nope, you'll need to use the path to the mqtt tag

> [@Bogdan\_Persa](#):
>
> will tagid change in the DB ?

I'm 99% sure the old tag will be retired and a new row will be created, so yes, tag id will change. But it's the tagpath that is used to join history together, not the tag id, so you will still see retired tags' history

---

<div class="post-metadata">

**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\
**Post date:** [October 17, 2022, 9:36pm UTC](https://forum.inductiveautomation.com/t/mqtt-store-forward/65275/6 "2022-10-17T21:36:51Z")

</div>

I'm successfully using reference tags with MQTT data on store/forward, but the catch is that all data must be flushed in chronological order, and the history settings require minimum time between samples set to 0.

See this article for details (there's others as well in the menu to get more info): [MQTT History Back-Fill with Reference Tags - MQTT Modules for Ignition 8.x - Confluence](https://docs.chariot.io/display/CLD80/MQTT+History+Back-Fill+with+Reference+Tags)

Here's another one that explains more as well: [MQTT History - MQTT Modules for Ignition 8.x - Confluence](https://docs.chariot.io/display/CLD80/MQTT+History)

---

<div class="post-metadata">

**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\
**Post date:** [October 17, 2022, 9:42pm UTC](https://forum.inductiveautomation.com/t/mqtt-store-forward/65275/7 "2022-10-17T21:42:55Z")

</div>

> [@michael.flagler](#):
>
> data must be flushed in chronological order

Have you tried the setting on the gateway to allow backfill out of order?

This is good to know though, I speak with 2nd hand experience only

---

<div class="post-metadata">

**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\
**Post date:** [October 17, 2022, 10:16pm UTC](https://forum.inductiveautomation.com/t/mqtt-store-forward/65275/8 "2022-10-17T22:16:16Z")

</div>

Yeah, I tried it, and it didn't work for me, even though it says on 8.1.4 and newer you can flush it out of order. I could be doing something wrong, but I still feel more work needs to be done in coordination between Ignition and CirrusLink on the module and reference tags. I feel like when setting the minimum time between samples is set to 0, of course it's going to record everything as it's flushed even though I really only want slower data for history compared to the live data, I couldn't find a way around it besides having MQTT transmision on the edge poll OPC tags directly using a slower rate since I also can't use reference tags with a slower rate referencing the OPC tags, since reference tags don't respect the polling rate of the tag group they're assigned to.

---

<div class="post-metadata">

**Author:** ![hventer23](https://avatars.discourse-cdn.com/v4/letter/h/bbce88/32.png) [@hventer23](https://forum.inductiveautomation.com/u/hventer23)\
**Post date:** [March 13, 2023, 3:27pm UTC](https://forum.inductiveautomation.com/t/mqtt-store-forward/65275/9 "2023-03-13T15:27:29Z")

</div>

Just wanted to find out if there has been any new development from your side regarding history via ref tag? Thanks for the tip about ref tags not abiding to tag group timing, you saved me a few hours of pointless testing!

---

<div class="post-metadata">

**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\
**Post date:** [March 20, 2023, 12:24am UTC](https://forum.inductiveautomation.com/t/mqtt-store-forward/65275/10 "2023-03-20T00:24:07Z")

</div>

Nothing new. I believe I'm going to have to go back to the edge device to have my MQTT tags point directly to the source with the desired update rate in order to get them to push over MQTT at that rate as well.

---

<div class="post-metadata">

**Author:** ![hunterdg](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/hunterdg/32/67774_2.png) [@hunterdg](https://forum.inductiveautomation.com/u/hunterdg)\
**Post date:** [November 16, 2023, 1:49am UTC](https://forum.inductiveautomation.com/t/mqtt-store-forward/65275/11 "2023-11-16T01:49:26Z")

</div>

I've successfully tested both **out-of-order/direct-to-historian** and **in-order/flush (replay)** S&F modes (on both MQTT Engine tags and reference tags) using 4.0.19 Transmission/Engine modules.

I'm now curious if the latter (replay) method will flush/replay the cached data all the way through Ignition's OPC UA server - and if an OPC client will successfully log those historical values (if it's writing to a CSV or DB, for example).

It seems it should work _in theory_, but testing thusfar has failed to validate that.

Any thoughts on the matter @wes0johnson?

for reference: [Historian and Sparkplug-B - #5 by wes0johnson](https://forum.inductiveautomation.com/t/historian-and-sparkplug-b/28709/5)

![Screenshot 2023-11-15 at 7.54.00 PM](https://us1.discourse-cdn.com/inductiveautomation/original/3X/f/1/f1a586611d1c1fe2fcaaeeab6609142cb6236866.png)

---

<div class="post-metadata">

**Author:** ![wes0johnson](https://avatars.discourse-cdn.com/v4/letter/w/7ab992/32.png) [@wes0johnson](https://forum.inductiveautomation.com/u/wes0johnson)\
**Post date:** [November 16, 2023, 2:52am UTC](https://forum.inductiveautomation.com/t/mqtt-store-forward/65275/12 "2023-11-16T02:52:49Z")

</div>

I would guess it wouldn't because of the polling on the OPC UA side. Because Engine writes the values so fast, a polling application is almost surely going to miss some events. That same thread you linked included a comment from me about 'tag latching' at MQTT Engine. Could this work for you? [MQTT Engine Tag Latching - MQTT Modules for Ignition 8.x - Confluence](https://docs.chariot.io/display/CLD80/MQTT+Engine+Tag+Latching)

I know it isn't OPC UA but it might provide a mechanism to do what you want. Certainly it would allow you to write to a CSV or another DB.

---

<div class="post-metadata">

**Author:** ![hunterdg](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/hunterdg/32/67774_2.png) [@hunterdg](https://forum.inductiveautomation.com/u/hunterdg)\
**Post date:** [November 16, 2023, 4:03pm UTC](https://forum.inductiveautomation.com/t/mqtt-store-forward/65275/13 "2023-11-16T16:03:13Z")

</div>

Thank you for the response!

Should the fact that the OPC UA client is subscribing (as opposed to polling) make a difference?

Perhaps I can mess with MQTT Engine tag group rate?

I’ll check into the Latched solution!

Bit more info:

I’m essentially trying to “tack on” OPC UA HA (Historical Access) server (or similar functionality) to an MQTT+Ignition environment. In other words, I want to be able to ensure an OPC UA Client will be able to receive/see all historical data that might be stored & forwarded

I’ve tested various scenarios and gotten close to what I need, but not quite all the way.

---

<div class="post-metadata">

**Author:** ![wes0johnson](https://avatars.discourse-cdn.com/v4/letter/w/7ab992/32.png) [@wes0johnson](https://forum.inductiveautomation.com/u/wes0johnson)\
**Post date:** [November 16, 2023, 10:06pm UTC](https://forum.inductiveautomation.com/t/mqtt-store-forward/65275/14 "2023-11-16T22:06:36Z")

</div>

I'm not sure on this. OPC UA is not my area of expertise. Maybe @Kevin.Herron can answer this? I can say without latching MQTT Engine can/will write many historical tag events per millisecond.

---

<div class="post-metadata">

**Author:** ![hunterdg](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/hunterdg/32/67774_2.png) [@hunterdg](https://forum.inductiveautomation.com/u/hunterdg)\
**Post date:** [November 16, 2023, 10:09pm UTC](https://forum.inductiveautomation.com/t/mqtt-store-forward/65275/15 "2023-11-16T22:09:23Z")

</div>

Also curious if the third-party "DataHub" I'm trialing is at fault here/not following spec:

Though I have the Primary Host ID configured (`C2C`) and the topic subscription set to `spBv1.0/#`, it's presenting itself to Chariot as only `STATE/C2C`. Presumably it should be `spBv1.0/STATE/C2C`, because the Transmitter with matching PHID refuses to connect to the broker.

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/c/8/c8b7169a111da767d785990d7d5386a0ddd5f48b.jpeg)

---

<div class="post-metadata">

**Author:** ![wes0johnson](https://avatars.discourse-cdn.com/v4/letter/w/7ab992/32.png) [@wes0johnson](https://forum.inductiveautomation.com/u/wes0johnson)\
**Post date:** [November 16, 2023, 10:36pm UTC](https://forum.inductiveautomation.com/t/mqtt-store-forward/65275/16 "2023-11-16T22:36:56Z")

</div>

I don't believe 'DataHub' has submitted a listing request to the Eclipse Sparkplug Working Group confirming they are compliant. The STATE topic was a fairly late change to the spec before it was ratified. So, it is quite possible some haven't updated yet. MQTT Engine and Transmission support both flavors.

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [November 17, 2023, 11:31pm UTC](https://forum.inductiveautomation.com/t/mqtt-store-forward/65275/17 "2023-11-17T23:31:37Z")

</div>

> [@hunterdg](#):
>
> I want to be able to ensure an OPC UA Client will be able to receive/see all historical data that might be stored & forwarded

On the client side you need to make sure it requests the Queue Size for each Monitored Item is set to something large enough to accommodate a burst of values arriving.
