# JSON missing Properties

**URL:** <https://forum.inductiveautomation.com/t/json-missing-properties/103672>\
**Category:** Ignition\
**Tags:** perspective\
**Created:** [March 14, 2025, 1:48am UTC](https://forum.inductiveautomation.com/t/json-missing-properties/103672 "2025-03-14T01:48:26Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![jacque\_trahan](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/jacque_trahan/32/58886_2.png) [@jacque\_trahan](https://forum.inductiveautomation.com/u/jacque_trahan)\
**Post date:** [March 14, 2025, 1:48am UTC](https://forum.inductiveautomation.com/t/json-missing-properties/103672/1 "2025-03-14T01:48:26Z")

</div>

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

```python
{
  "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:

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/5/0/500b67ff8781f01a0b682ecf30b69b4ce8139ad0.png)  
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.  
 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/c/a/ca51c46f26f4536e2a7b60c2dd765fdb6609068c.png)

### 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.

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/9/2/927f0113c04766d7c624d8c6a98611f1716ce447.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:** [March 14, 2025, 6:03am UTC](https://forum.inductiveautomation.com/t/json-missing-properties/103672/2 "2025-03-14T06:03:17Z")

</div>

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**

> [@Problem with system.tag.getConfiguration() doesn't return dataType](https://forum.inductiveautomation.com/t/problem-with-system-tag-getconfiguration-doesnt-return-datatype/51293/5):
>
> Ok, after some help, you can get the default value from com.inductiveautomation.ignition.common.tags.config.properties.WellKnownTagProps e.g. from com.inductiveautomation.ignition.common.tags.config.properties import WellKnownTagProps propObj = WellKnownTagProps.DataType print propObj.defaultValue print propObj.name print propObj.type \>\>\>\> Int4 dataType \<type 'com.inductiveautomation.ignition.common.sqltags.model.types.DataType'\>

**Alarm Props**

> [@system.tag.getAlarmStates alternative?](https://forum.inductiveautomation.com/t/system-tag-getalarmstates-alternative/27803/13):
>
> Update: You can get the alarm default values using: from com.inductiveautomation.ignition.common.alarming.config import CommonAlarmProperties, AlarmModeProperties properties = {} properties.update(dict((s.getName(), s.getDefaultValue()) for s in CommonAlarmProperties.values())) properties.update(dict((s.getName(), s.getDefaultValue()) for s in AlarmModeProperties.values()))

---

<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:** [March 14, 2025, 6:58am UTC](https://forum.inductiveautomation.com/t/json-missing-properties/103672/3 "2025-03-14T06:58:52Z")

</div>

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

```python
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

```

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [March 14, 2025, 12:38pm UTC](https://forum.inductiveautomation.com/t/json-missing-properties/103672/4 "2025-03-14T12:38:41Z")

</div>

> [@nminchin](#):
>
> `for d in dir(WellKnownTagProps):`

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](https://files.inductiveautomation.com/sdk/javadoc/ignition81/8.1.47/com/inductiveautomation/ignition/common/config/ConfigurationPropertyModel.html)'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.

---

<div class="post-metadata">

**Author:** ![jacque\_trahan](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/jacque_trahan/32/58886_2.png) [@jacque\_trahan](https://forum.inductiveautomation.com/u/jacque_trahan)\
**Post date:** [March 14, 2025, 2:38pm UTC](https://forum.inductiveautomation.com/t/json-missing-properties/103672/5 "2025-03-14T14:38:36Z")

</div>

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.

```python
# 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:

```python
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.