Use hs:id, handle, ordInSpace, or handleOrd instead of slotPath or slotPathOrd to collect timeseries data into SkySpark

[christopher-hartley]

The company I work for has been using nhaystack to collect data out of Niagara instances into SkySpark for many years, and I'd like to request a feature (or at least a discussion!) to prevent something that I see that happens relatively frequently. There are times when an MSI or BAS engineer will move the location of point folders in a Niagara station. If that event occurs, the way we use nhaystack now (either by dropping nhaystack site or equip records, or by using the slotPath [ComponentSpace] ) will cause SkySpark to stop collecting data, and display an "Unknown RecErr" on the point's curErr tag. This requires our project engineers to fix the haystackCur/haystackHis tags inside SkySpark, once it is discovered. This is a costly process, in terms of time required to rebind these points to their new location path, and timeseries data that is not captured by SkySpark.

I've been working with @xVenturi to try and fix this problem, and found that there is a unique identifier that does not change, regardless of what happens to the point record, or the folder that contains the point. I'd like to propose that nhaystack use the "handle" tag, (or ordInSpace, handleOrd, ordInSession, or absoluteOrd tags) to bind the the point's haystackCur/haystackHis tags in SkySpark. This value is unique, and does not change if the record's location changes in the Niagara station. See the "SpaceNode" section below in the attached screenshot. Please let me know if you need further clarification, and thank you for reading! We would be more than happy to test this new functionality if it is made available.

@briansfrank any comments would be appreciated!

[briansfrank]

I will just say that the handle can change. It is reassigned every-time the station is exported/re-imported. Maybe that doesn't happen often (I am too far removed how it is used day to day).

But one other option is to use a slot that contains a UUID as the identifier. But then nHaystack would have to create its own cache/lookup mechanism.

[ci-richard-mcelhinney]

As @briansfrank says the handle ORD is not unique or immutable either, it can change. I believe Tridium have made changes to how the handle ORD works but I still don't have confidence in using it for this application.

nhaystack actually generates 3 different types of IDs. One uses a direct component reference which uses the slot path to identify the component. Another is specific to the History Space and identifies histories directly.

The third way is built of the Site/Equip/Point hierarchy. So if you are setting up the tagging in your station and you relate a point to an equip, then if you move the point around in the station the ID tag should remain the same as long as you maintain the ref or relation in Niagara to the original equip.

That would be worth testing out. Let me know if that's not clear and I'll try to explain further.

[christopher-hartley]

@ci-richard-mcelhinney sorry for the slow reply!

So if you are setting up the tagging in your station and you relate a point to an equip, then if you move the point around in the station the ID tag should remain the same as long as you maintain the ref or relation in Niagara to the original equip.

We have found that this method causes issues when integrators move points and their folders around in the Niagara station. Perhaps what I don't understand is how we should deploy the nhaystack and the site/equip/point records appropriately. I've read the instructions and are following them (https://github.com/ci-richard-mcelhinney/nhaystack, sections 1 and 4). Is there any other way to reference Niagara points from inside SkySpark that will prevent a curErr if they are moved around on the Niagara side?