Tag value not updating in SkySpark on export

#1

This environment is Kodaro Haystack 1.0.20 in Niagara 4.6. I am trying to update revisions but there are custom module security access issues I’m waiting to be resolved.

I’ve had to set up multiple disMacro tag values in Niagara to account for different naming structures of connected sites.

For example, on a particular site equips have disMacro: $siteRef $navName while anything that is equip and vav has disMacro: $siteRef $floor $navName. This is all set up correctly in Niagara but won’t change the original tag value in SkySpark. The vav disMacro tags all remain at the original value despite the fact they are all the new value in Niagara.

I’ve cleared hierarchy cache in N4 and manually changed the tag value in the builder app but it just changes back on the next export.

Is there something I’m missing or do I just need to wait until I can get this environment updated to latest revisions and test again?

#2

Could you please provide some screen shots to help illustrate your issue? I am not sure I follow the scenario you are describing.

#3

Sure can!
I actually tried the first time but because I’m a new user I was blocked. Then after posting this I became trusted so I was allowed to :laughing:

For a bit more info, we have 10 or more buildings joined to a central N4/SkySpark server. VAV naming in one building references the central AHU rather than the floor number so I’m trying to get a floor number into the naming convention. We were using displayName / dis tag originally but with such a large deployment we had to exclude the dis tag in favour of disMacro: $siteRef $navName. And so now I’m trying to stick the floor number in there again for this one building so we can identify individual VAVs.

I think my only other option is to rename the VAVs onsite which is probably not an option.

Niagara Tagging
image

SkySpark equip names / tagging
image

#4

You said that when you updated this value in SkySpark, the export changes it to something not in Niagara? Are all 10 stations exporting data directly into the SkySpark installation? Or do all stations aggregate into a supervisor first and then one export from that supervisor into SkySpark? My initial thought is that something other than the export is overriding the value since the export does not manipulate the tag data, it only passes it to SkySpark and would fail if it was rejected for any reason.

Is it possible there is another mechanism within skyspark updating this value and/or a duplicate export happening elsewhere conflicting with your updates?

#5

All sites are gathered in the N4 server with one haystack export.

I will check all functions in SkySpark but I’ve only set up the disMacro tags and displayName exclusion in Niagara recently. Nothing would reference them in SkySpark.
I can manually change the disMacro values in SkySpark to match the value in Niagara. That gives me the naming convention I’m looking for but they then reset to the old value on next export.

So to begin with, all disMacro tags were added to equips in Niagara with a value of $siteRef $navName. When I realised we couldn’t distinguish between VAVs in this one building, I excluded them from that first tag rule and made a new tag rule so the value is $siteRef $floor $navName.

#6

From the screen shots you are showing, these are not the same objected based on the ID. Can you confirm this behavior on a 1:1 comparison between Niagara and SkySpark?

#7

Yep

Niagara object
image

SkySpark object
image

#8

Just to verify, you have confirmed the same behavior exists on this point as well? Can you also confirm the disMacro tag does not appear under the direct tags tab?

#9

Yes and yes.

These are all the direct tags.
image

In SkySpark I tried an axon script to change all the disMacro tags to the value I need to uniquely identify VAVs. It fails saying “string interpolation not supported”.

Then I tested a different string tag from Niagara. This time the floor tag I’ve added directly. It works through the export. I’m going to remove my implied disMacro tags and add them directly through program service to see if that solves it.
image image

#10

So it updates the string value as a direct tag but not as an implied tag. All VAVs are now named in a way we can use. Interesting that the implied string tag wouldn’t change but the direct one will.

image

#11

There is no reason I would suspect implied tags from not working the same way as direct. The reason I was asking about it being a direct tag is because direct tags will override implied tags if there is duplication. If it had already existed there first, then maybe that was the issue. It seems like it wasn’t already a direct tag and you just recently added it? Is that an accurate assessment?

I’m glad it’s working as direct but if you could provide details, images will suffice, of how the implied tag was created, that would help me look into this issue. I would like to determine if there’s something missing in the driver when dealing with implied tags or something else causing the issue with this instance.

#12

Unfortunately I have removed the tag rule used to create the implied tags but this was the series of events:

  1. disMacro tags added to all equips via tag rule with string value of $siteRef $navName

  2. Found VAVs for one site had a naming convention on site that would not uniquely identify them with the above value. Excluded their location from the scope and created a new tag rule which gave them disMacro: $siteRef $floor $navName. The floor string tag was added via program service as a direct tag to each VAV equip.

  3. All tagging in Niagara was correct but I found the disMacro tags in SkySpark for these VAVs remained at the original value in step 1 despite many attempts to update them. Changing them directly in SkySpark worked as intended but they would revert back on next export.

  4. Tested changing the value of the floor tag which is a direct tag in Niagara and successfully noted a change on the next export in SkySpark.

  5. Deleted the tag rule applying disMacro as implied tags to these VAVs and used program service to apply disMacro tags with the desired value as direct tags. This achieved the desired disMacro value and naming convention in SkySpark.