MQTT Engine, sparkplug values, timestamp not updating

We have some sparkplug devices sending data to a MQTT distributor module.

If the values sent from the sparkplug device are the same as the current values in the MQTT engine. The timestamp in the Ignition tag system(MQTT-Engine) are not updating. Should not the timestamp update, even though the value is the same?

This gives a trend w/ gaps, alot of gaps. see the attached picture of two values always beeing sent at the same time. Here it can be seen that if the timestamp value has not been updated, a gap will occur.

I only want gaps to occure if the quality of the signal is something other than “Good”.

FYI, we use Ignition Historian for storing the values.

Ignition 8.05

Also, if I want to run a tag event script on this. How often will that fire? I guess only when the value received by the MQTT Engine actually differs from the last value?

I am having a similar issue. I would like all of the tags to have an updated timestamp, regardless if it’s changed. Did you find a solution to this?

Not sure if it helps but in all my MQTT transmissions I include the date and time stamp from the device. That way in the message there is always a value that is different.

1 Like

The feedback I got from the devs which I agree with is that the values are not sent if they are the same, which make sense.

The gap problem was never solved I believe. Please reply if you guys find a solution

That is a GREAT Idea!!! @craigb


Has there been any change on this? I’ve got the exact same issue as Tordvd. My architecture depends on being able to send commands with the same contents (but updated timestamp) and I need them to be able to trigger tag scripts.

You may need to rethink things, Ignition’s tag system in general and tag change scripts specifically only act on value or quality changes.

Hi Kevin,
I think I’ve found a workaround for UDTs, I’ve just added a custom timestamp tag within it which can be triggered for this

1 Like

This is also a problem for my use case where we need to be able to tell the last time a value was calculated, even if the result is the same. The only work-around we’ve been able to figure out so far is to periodically write a very small change to the value then write the original value back when we want to update the timestamp with no change in the value.

@Kevin.Herron or anyone else, any ideas?