JSON missing Properties

jacque_trahan · March 14, 2025, 1:48am

I am unsure if this behavior is intentional. I attempted to find relevant forum posts covering this issue but was unable to locate any.

Issue:

The system.tag.query() function in Ignition does not always return all properties associated with a UDT, tag, or alarm.

Example:

Consider a tag with two alarms defined at the UDT level that are not overridden at the instance level. When I use the system.tag.query() function, none of the alarms are returned, even though they are defined at the UDT level.
EDIT:
This is a right click copy JSON output

{
  "opcItemPath": {
    "bindType": "parameter",
    "binding": "ns\u003d2;s\u003d[{Topic}]null.H"
  },
  "valueSource": "opc",
  "dataType": "Boolean",
  "historyProvider": "HistDB_Maverick",
  "PI_Tag": false,
  "Tag_Description": "High Alarm",
  "historyEnabled": true,
  "deadbandMode": "Off",
  "LongID": "KMT_MIDS.OPCIS04:null_PA_H",
  "tagGroup": "Default",
  "enabled": true,
  "opcServer": "ACM OPC UA Server",
  "name": "HIGH_ALARM",
  "tagType": "AtomicTag"
}

In most cases, this behavior does not cause issues, and updating the tag functions as expected. However, my update process depends on retrieving tag configurations using system.tag.query(). Occasionally, when checking for the existence of an alarm or a built-in Ignition alarm property within the retrieved configuration, the check fails—even though the property is clearly present in the tag definition.

Below is an example of a tag with two alarms:

Has anyone else encountered this behavior? Is there a known explanation or workaround for ensuring that all expected properties are consistently returned?

It appears that my error output file is missing a built-in Ignition property that should be present on every alarm. This issue is inconsistent and does not always occur.

Additional Notes:

I used the Ignition tag report tool to return only alarms and noticed that the "On Change" alarm does not include a priority, despite being set to "Low" at the UDT definition level. However, if I manually update the priority at the UDT definition level, it correctly appears in the same query. This suggests that the issue is not due to a coding error on my part but rather an aspect of how Ignition handles alarm properties in UDTs that I have yet to fully understand.

nminchin · March 14, 2025, 6:03am

I suggest you copy the json of a tag/UDT Instance/UDT Definition and inspect what properties are stored against the tag(s). You will find that only the properties whose values have been overridden are stored with the configuration.

This means:

the configuration of standard tags will store all overridden property values in their config
the configuration of tags within UDT instances will store all property values overridden inside the UDT Instance, not inside this and the UDT Definition, (as well as its name and tag type, since these are important)

To get all overridden property values regardless of where they are overridden (inside of the UDT Instance or inside of the UDT Definition), then you should use system.tag.getConfiguration.

To also include the default values of properties that haven't been overridden is a bit more involved. These might get you started:

Tag Props

Alarm Props

nminchin · March 14, 2025, 6:58am

This might help. I've only briefly tested it, and it doesn't yet work for nested folders.

from com.inductiveautomation.ignition.common.alarming.config import CommonAlarmProperties, AlarmModeProperties
from com.inductiveautomation.ignition.common.tags.config.properties import WellKnownTagProps
import copy

def getAllConfiguration(baseTagPath):
	"""Gets all tag configuration from a tagpath including both overridden values and the default values for non-overridden properties. Currently does not support recursion into sub-folders """
	# get all tag props and their default values (excludes alarms)
	tagPropsAll = {}
	for d in dir(WellKnownTagProps):
		if str(d) != str(d).upper() and str(d[0]) != str(d[0]).lower():
			tagPropsAll[d] = getattr(WellKnownTagProps, d).defaultValue
	
	# get the configuration of the baseTagPath which includes the property overrides applied to the tags
	cfg = system.tag.getConfiguration(baseTagPath)
	
	# get all tag alarm props and their default values
	alarmPropsAll = {}
	alarmPropsAll.update(dict((s.getName(), s.getDefaultValue()) for s in CommonAlarmProperties.values()))
	alarmPropsAll.update(dict((s.getName(), s.getDefaultValue()) for s in AlarmModeProperties.values()))
	
	# update the tag and alarm configs with the default values for props not overridden, to produce a complete tag value list
	cfgNew = []
	for tag in cfg:
		# first copy all of the props and their defaults
		tagNew = copy.deepcopy(tagPropsAll)
		# then update them with their overridden prop values
		tagNew.update(tag)
		
		# do the same for each alarm
		alarmsNew = []
		for alarm in tag.get('alarms', []):
			props = copy.deepcopy(alarmPropsAll)
			props.update(alarm)
			alarmsNew.append(props)
		
		if alarmsNew:
			tagNew['alarms'] = alarmsNew
		
		cfgNew.append(tagNew)
	
	return cfgNew

pturmel · March 14, 2025, 12:38pm

Be aware that there are multiple peers to WellKnownTagProps. That one just gives the props that all types of tags typically have. There are more that depend on the tag type, or that depend on certain values being present in other tag properties, like the properties for history that only apply if historyEnabled is true.

To do this correctly, after you use system.tag.getConfiguration to merge instance properties with definition properties, you would use the tag provider's ConfigurationPropertyModel's .getApplicableProperties() method to render the rules for you. Note that the list items returned are not string property names, but property definitions, typically BasicProperty that can tell you its default value.

jacque_trahan · March 14, 2025, 2:38pm

Thank you all for this valuable information! I’ll be diving into it in the coming weeks.

I should have clarified that this occurs specifically at the instance level and seems to affect only alarms. So far, UDTs and Tags retrieve all the necessary properties from the query results, or at least I haven’t encountered any properties that were missing.

For the UDT definition, I actually use these two for loops, but I would not recommend this approach at the instance level, especially on a live server. It is very gateway resource-intensive at the instance level and has a high chance of causing performance issues or even locking up the gateway. At the definition level, however, it is more manageable, and I haven’t experienced any gateway lockups.

Because of this, I switched to using system.tag.query(), which was a game changer in terms of performance for instance level scripts.

Additionally, I use a dictionary to index all this information, with the tag path as the key. This allows me to store the retrieved data efficiently and perform any necessary operations later without repeatedly querying the system.

# Instance-level tag browsing (not recommended for live servers due to high resource usage)
path = "your path"
udtBrowsing = system.tag.browse(browsePath, filter={'tagType': 'AtomicTag', "recursive": True})

# Use a loop to retrieve the tag path for configuration retrieval
configs = system.tag.getConfiguration(fullPath, True)[0]  # Returns a list of configurations

# UDT-level browsing (suitable for retrieving UDT instances or definitions, including roll-ups)
udtBrowsing = system.tag.browse(browsePath, filter={'tagType':  '_types_', "recursive": True})

# Similar approach: iterate through UDT paths to retrieve configurations

That said, I was able to resolve this issue using an alternative approach. I maintain a stored list of Ignition properties, so I modified my condition to ensure that even if a built-in Ignition property is not included in the query results, it will still be added:

if alarmProperty not in currentAlarmConfig and not alarmProperty in ignitionBuiltInAlarmProperties:

I will use the new information you all have provided to explore a more efficient way to handle this.