I am working on a project that required to use nHaystack.
We are required to reference the equipment to the "serviceRef" and "spaceRef" as
serviceRef: @mechanical and spaceRef: @Level_25.
I know how to do the reference tag. However, when I reference the piece of equipment to its assoicated level, it shows the entire path of that folder, for example
spaceRef: C.Drivers.NiagaraNetwork.Level_25
Does anyibe know a way for it to only show spaceRef: @Level_25 ?
Is this even possible?
Any help would be greatly appreciated.
Thank you
Yong
Usama IqbalToday 7:39am
Short answer: no, not for a space, and the reason is in the id scheme rather than in anything you tagged wrong.
What you are looking at is the entity id, not a name. In nHaystack an id is always space + "." + path, where the space is one character: C for the component space, H for the history space, S for the site-equip-point space. A C id is literally the Niagara slot path with the separators swapped - the code takes comp.getSlotPath(), strips the leading "slot:/", and replaces "/" with "." (and "$20" with "-", "$" with "~"). So C.Drivers.NiagaraNetwork.Level_25 is slot:/Drivers/NiagaraNetwork/Level_25 and nothing more.
That also means you cannot shorten it by hand. Every HRef inside a haystack annotation is passed through a conversion step on the way out: it resolves the ref to a component and then re-emits the id that component is entitled to, so whatever you type in is replaced. Type @Level_25 with no dot in it and it fails to parse, the exception is caught, and the value is handed back exactly as typed - which looks like it worked until you notice nothing resolves it, and there is a "remove broken refs" job in the module for cleaning that up afterwards.
The short ids you want do exist, and they come from the S space. When a ref is generated the code first asks the cache whether the target already has an S ref and only falls back to the slot path if it does not. S refs are built by joining nav names and then applying the same "/" to "." rule, which gives three shapes: a site is S.MySite, an equip is S.MySite.MyEquip, a point is S.MySite.MyEquip.MyPoint. Nav names come from navNameFormat, which defaults to %displayName%, so you have some control over the text.
The catch for your case: the cache assigns S refs to exactly three kinds of component - a site, an equip that references a site, and a point under such an equip. A component tagged as a space is recognised and is filed for navigation under its site, but it is never given an S ref. So a spaceRef pointing at a space will keep the C-and-path form no matter how you write it. (serviceRef is not a tag nHaystack knows at all - there is no mention of it anywhere in the module - so it just gets the generic ref treatment above.)
Two ways forward, depending on what Level_25 really is. If it is the thing your equipment belongs to and you can model it as the site, or as an equip under the site, then tag it that way, invoke Rebuild Cache on the service, and the ref turns into S.Level_25 or S.<site>.Level_25 - which is the short form you were after. If it has to stay a space, then treat the id as opaque, which is what Haystack intends, and put the readable text in dis or navName instead; dis is generated from navNameFormat as well, and for points it is prefixed with the site and equip dis, so a client can show "Level_25" while the ref underneath stays path-shaped.
Worth knowing either way: because a C id is the slot path, it changes if anyone renames or moves that component, and every stored ref pointing at it goes stale. S ids follow nav names instead, which is the better reason to model sites and equips properly rather than referencing components where they happen to sit in the tree.
Source for all of the above is the n4 branch as of the 4.0.0 release-candidate build (NHRef, TagManager, Cache, Nav, SlotUtil, NHaystackConst) - worth a look at your own version if it is older, though the id scheme itself goes back to the original 2013 code.
Yong Teo Mon 29 Sep 2025
Hi There,
I am working on a project that required to use nHaystack.
We are required to reference the equipment to the "serviceRef" and "spaceRef" as
serviceRef: @mechanical and spaceRef: @Level_25.
I know how to do the reference tag. However, when I reference the piece of equipment to its assoicated level, it shows the entire path of that folder, for example
spaceRef: C.Drivers.NiagaraNetwork.Level_25
Does anyibe know a way for it to only show spaceRef: @Level_25 ?
Is this even possible?
Any help would be greatly appreciated.
Thank you
Yong
Usama Iqbal Today 7:39am
Short answer: no, not for a space, and the reason is in the id scheme rather than in anything you tagged wrong.
What you are looking at is the entity id, not a name. In nHaystack an id is always space + "." + path, where the space is one character: C for the component space, H for the history space, S for the site-equip-point space. A C id is literally the Niagara slot path with the separators swapped - the code takes comp.getSlotPath(), strips the leading "slot:/", and replaces "/" with "." (and "$20" with "-", "$" with "~"). So C.Drivers.NiagaraNetwork.Level_25 is slot:/Drivers/NiagaraNetwork/Level_25 and nothing more.
That also means you cannot shorten it by hand. Every HRef inside a haystack annotation is passed through a conversion step on the way out: it resolves the ref to a component and then re-emits the id that component is entitled to, so whatever you type in is replaced. Type @Level_25 with no dot in it and it fails to parse, the exception is caught, and the value is handed back exactly as typed - which looks like it worked until you notice nothing resolves it, and there is a "remove broken refs" job in the module for cleaning that up afterwards.
The short ids you want do exist, and they come from the S space. When a ref is generated the code first asks the cache whether the target already has an S ref and only falls back to the slot path if it does not. S refs are built by joining nav names and then applying the same "/" to "." rule, which gives three shapes: a site is S.MySite, an equip is S.MySite.MyEquip, a point is S.MySite.MyEquip.MyPoint. Nav names come from navNameFormat, which defaults to %displayName%, so you have some control over the text.
The catch for your case: the cache assigns S refs to exactly three kinds of component - a site, an equip that references a site, and a point under such an equip. A component tagged as a space is recognised and is filed for navigation under its site, but it is never given an S ref. So a spaceRef pointing at a space will keep the C-and-path form no matter how you write it. (serviceRef is not a tag nHaystack knows at all - there is no mention of it anywhere in the module - so it just gets the generic ref treatment above.)
Two ways forward, depending on what Level_25 really is. If it is the thing your equipment belongs to and you can model it as the site, or as an equip under the site, then tag it that way, invoke Rebuild Cache on the service, and the ref turns into S.Level_25 or S.<site>.Level_25 - which is the short form you were after. If it has to stay a space, then treat the id as opaque, which is what Haystack intends, and put the readable text in dis or navName instead; dis is generated from navNameFormat as well, and for points it is prefixed with the site and equip dis, so a client can show "Level_25" while the ref underneath stays path-shaped.
Worth knowing either way: because a C id is the slot path, it changes if anyone renames or moves that component, and every stored ref pointing at it goes stale. S ids follow nav names instead, which is the better reason to model sites and equips properly rather than referencing components where they happen to sit in the tree.
Source for all of the above is the n4 branch as of the 4.0.0 release-candidate build (NHRef, TagManager, Cache, Nav, SlotUtil, NHaystackConst) - worth a look at your own version if it is older, though the id scheme itself goes back to the original 2013 code.