Display all points example

This is a straight-forward example of how to create a hierarchy that displays real-time results from all points configured for three AHU units owned by the same company.
Figure 6.   All AHU Points hierarchy definition setup (left) and resulting hierarchy Nav tree (right)
Image
Image
 NOTE: Red icons displaying in a hierarchy definition indicate the need to save due to the hierarchy being newly created or modified in some way. 

This table explains each property in the hierarchy definition.

Level name Property Where set up Comments
Scope Scope: Station Station selected by default in the hierarchy definition. This property limits the range of the hierarchy to the station database.
Tags Hierarchy Tags Tags added to LevelElems that are not BComponents  None in this example. When the navigation hierarchy is built, tags are applied to LevelElems (nodes) that are not BComponents 
Device (QueryLevelDef) Query Context Selected here in the hierarchy definition. Not used in this example.
  Query : n:device Direct tag added to each AHU. Returns all components tagged as “devices”.
  and hs:ahu Direct tag added to each AHU. Further narrows the search results to only devices tagged with “hs:ahu”.
  Sort: Ascending Selected here in the hierarchy definition. Defines the display sequence.
Points (RelationLevelDef) Outbound Relation Ids: n:childPoint Implied tag on each point. Indicates the outbound relation direction setup on the object (target) component of a relation. Returns all entities with an outbound “n:childPoint” relation from each result returned from the previous QueryLevelDef (named Device). The n:childPoint relation is implied between devices and points underneath the device.
  Inbound Relation Ids: Implied tag on each point. Not used in this example.
  Filter Expression: Set up here in the hierarchy definition. Not used in this example.
  Repeat Relation: true Set up here in the hierarchy definition. When true, this cause entities traversed by the specified outbound “n:childPoint” relation to be added to subsequent levels of the hierarchy, if they existed. n:childPoint is a relation implied on devices so it is unlikely that there would be additional levels unless the relation was added manually.
 NOTE: Referencing the implied n:childPoint relation between devices and their points, you can easily create hierarchy displays that omit of the Points folder. 
 NOTE: In Niagara 4.3 and later, there is added support for multiple relation IDs on a single relation level definition. You can enter more than one comma separated tagID in the Inbound Relation Ids or Outbound Relation Ids properties. The results for any of these relation IDs display in the hierarchy.