A tale of a tag configuration property named 'value'

Ignition
,
1

We were noticing some strange history on tags from MQTT Engine whenever we rebooted the whole server or just the MQTT Engine. Some tags were falsely logging an arbitrary value from their past during the time between bootup until the SparkPlug nodes reconnected and provided the correct value.

After a bit of investigating and scratching our heads, we stumbled on the fact that those tags with the weird history also always had a configuration property named ‘value’ containing the exact value that was being falsely logged into the history. You could see it either by doing “Edit (raw)” in the designer or via getConfiguration(). We’ve never intentionally set a property named ‘value’, but we do have several scripts that walk through SparkPlug tags and ensure a certain configuration by doing a getConfiguration(), modifying it, and pushing it back in with configure().

Most of our tags don’t have a property named ‘value’ in their configuration. The best we can figure is that under unknown circumstances (maybe including running older versions of Ignition) a call to getConfiguration() included the tag’s current value as a property accidentally. And then our script happily wrote that back into place which lodged it there forever.

Our workaround to clean things up was to just update those same scripts which adjust the configuration to explicitly remove any property named ‘value’ if one is present.

But then we bumped into a new problem: if a tag has a current value from a node that is connected, and the tag configuration is modified such that the ‘value’ property is removed, then the current value from the node is flagged as invalid and forgotten! Even if the current value and the ‘value’ property didn’t have any relation to each other…

The value thankfully fixes itself the next time the SparkPlug node reports that tag, but our nodes don’t always report all tags on a regular basis. So our script (as a workaround on top of the workaround) now requests a rebirth from the node after re-configuring if it removed a ‘value’ property from any tags.

So, um…

My two inquiries to IA from this whole experience are:

  1. Under what circumstances might getConfiguration() include the current value as a property? Was this a bug in an old version or is this still possible?
  2. Is it a bug that a SparkPlug tag’s current value disappears if you reconfigure the tag and remove the ‘value’ property, even if it isn’t the current value?
2

After scrubbing all of the existing tags, we added a logging print to report if the ‘value’ property ever comes back. That logging print was triggered today when some brand new devices birthed for the first time ever and created their tags. The configuration script removed them as expected, and the nodes seem to be functioning normally.

I’m still looking for guidance on my 2 earlier questions, and the more general question if removing the ‘value’ property from tags will cause any issues.

3

I’ve seen a few more instances of ‘value’ configuration properties reported over the past few days, but I haven’t investigated the circumstances of the new ones yet. Everything in this thread up to this point was happening on slightly older nightly builds: Ignition b2019093002 and MQTT Engine b2019101010.

I’ve just upgraded that server to Ignition 8.0.6 and MQTT Engine 4.0.2. I will keep watching for more ‘value’ configuration properties.

4

On the upgrade reboot, every single tag with history enabled briefly entered a NULL row into the history tables… Is this because I removed the ‘value’ property? Is this going to happen again next time the server is rebooted?

I hand-edited the history table in SQL to remove all the NULL rows. They were very easy to find when I sorted by t_stamp since they were all within seconds of each other. Are there likely to be repercussions or complications from me doing this edit?

5

Hi,

The subsystem that the MQTT Engine uses has a setting to store the last known value in order to have it available when the system starts up the next time (desirable in some cases, not in others). That’s what you’re fighting with- it keeps injecting the “value” property that you see.

We’re working with Cirrus Link to fine tune this behavior, and probably make it ultimately an option the user can change through the settings for Engine. I’ll make it a point to get with them early next week, I’m sure we can fairly quickly make some changes and get you a test build that will help.

You can delete whatever you want from the tag history tables. Unless you’re using “pre-processed” partitions as well, there’s no assumption of what data will be there.