Skip to content

Site and Equip tags

Jump to bottom
Richard McElhinney edited this page Jan 29, 2021 · 3 revisions

4. How site and equip tags work

In addition to tagging point recs, you may also want to include site and equip recs in your station, and link everything together via siteRef and equipRef pointers. NHaystack does support creating this [site-equip-point hierarchy][structure]. Let's see how it works.

4.1 Site tagging

Lets use our simple example station from section 2.1, except we'll add an EnumWritable to it. Note that this time we have also listed an entry for the parent "AHU1" folder in our simplified view of the station.

----        station:|slot:/AHU1
{point,cur} station:|slot:/AHU1/NumericWritable
{point,cur} station:|slot:/AHU1/BooleanWritable
{point,cur} station:|slot:/AHU1/EnumWritable
{point,his} history:/my_station/AuditHistory
{point,his} history:/my_station/LogHistory

If you look in the nhaystack palette, you'll see that there are Components for Site and Equip. Drag a Site over and drop it anywhere in the ComponentSpace, and then run rebuildCache. The station will now look something like this:

{site}      station:|slot:/Richmond
----        station:|slot:/AHU1
{point,cur} station:|slot:/AHU1/NumericWritable           
{point,cur} station:|slot:/AHU1/BooleanWritable           
{point,cur} station:|slot:/AHU1/EnumWritable           
{point,his} history:/my_station/AuditHistory 
{point,his} history:/my_station/LogHistory

Site and Equip already have a "haystack" slot, so you don't have to add one via the SlotSheet. Bring up the HDict FieldEditor for the Site, you'll see that there are quite a few tags you can fill out, like the various "geo" tags.

4.2 Equipment versus Controllers

In Niagara, Controllers are modeled as an object of type driver:Device. Generally speaking, all ControlPoints exist underneath one of these Devices.

Howerver, in nhaystack there is no one-to-one relationship between an equip rec and a Device. Any Device can have its points belong to more than one equip, and any equip can have points from more than one Device.

This flexibility allows us to get away completely from the network-centric view of the world that one finds in an N4 Station. You can create representations of your data that reflect the real-world equipment on your site, rather than the layout of your controller network.

The following two sections, 4.3 and 4.4, explain in more detail how this works.

4.3 Explictly tagging points with equipRef

Lets continue with our example station from 4.1, and create an equip which references out site. Then lets have a point reference the equip.

First, drag an Equip over from the palette and place it anywhere in the station. Underneath the Site is a good place for it. Name it "TrashCompactor".

Then edit the equip and assign its siteRef so that it references "Richmond".
Then run rebuildCache. Next, edit "/AHU1/BooleanWritable", and give it an equipRef that references "TrashCompactor". Run rebuildCache again.

The station will now look like this:

{site}                                 station:|slot:/Richmond
{equip,siteRef="/Richmond"}            station:|slot:/Richmond/TrashCompactor
----                                   station:|slot:/AHU1
{point,cur}                            station:|slot:/AHU1/NumericWritable
{point,cur,equipRef="/TrashCompactor"} station:|slot:/AHU1/BooleanWritable
{point,cur}                            station:|slot:/AHU1/EnumWritable
{point,his}                            history:/my_station/AuditHistory
{point,his}                            history:/my_station/LogHistory

We have now successfully created a very simple site-equip-point hierarchy. Our nav tree looks like this:

Richmond
    TrashCompactor
        BooleanWritable

4.4 Implicitly tagging points with equipRef

We could now continue and mark every single point under "AHU1" as belonging to some equip. However, that is a lot of drudgery, and its also prone to error. NHaystack provides us with a better way to do this.

Drag an Equip from the palette, drop it under the "AHU1" folder, and call it "my_equip". Edit the equip so that its its siteRef references "Richmond".

Next, add an optional "Str" tag called navNameFormat to the equip, and set its value to "%parent.displayName%". The reason for doing this will soon become apparent.

Then rebuild the cache. Now observe what has happened:

{site}                                 station:|slot:/Richmond
{equip,siteRef="/Richmond"}            station:|slot:/TrashCompactor
----                                   station:|slot:/AHU1
{equip,siteRef="/Richmond"}            station:|slot:/AHU1/my_equip
{point,cur,equipRef="/AHU1/my_equip"}  station:|slot:/AHU1/NumericWritable
{point,cur,equipRef="/TrashCompactor"} station:|slot:/AHU1/BooleanWritable
{point,cur,equipRef="/AHU1/my_equip"}  station:|slot:/AHU1/EnumWritable
{point,his}                            history:/my_station/AuditHistory
{point,his}                            history:/my_station/LogHistory

Site-Equip-Point Nav Tree:
    Richmond
        TrashCompactor
            BooleanWritable
        AHU1
            NumericWritable
            EnumWritable

All of the points underneath AHU1, except BooleanWritable, have an auto-generated equipRef tag which references "/AHU1/equip". This happens because, during the cache rebuild process, NHaystack noticed that those 2 points had an ancestor which had an equip child. Since those points were not explicitly annotated with an equipRef, NHaystack automatically linked them to that ancestors Equip object.

By implicitly tagging points this way, we can automatically generate large numbers of equipRef tags without having to visit every point.

By the way, the reason that we added the navNameFormat to the equip was so that it would show up in our nav tree as "AHU1", rather than "my_equip". By default the navName of any object is just its N4 displayName, but you can rig the nav tree so that alternate names are used. This is important because you must always ensure that all the children of a nav tree item have a unique navName.

Lets duplicate the "AHU1" folder (an then rebuildCache of course) to show how easy creating large nav trees is.

Before we do though, we'll fix our BooleanWritable so it has a better navNameFormat. Edit the tags for the BooleanWritable and set its navNameFormat to something like "%parent.displayName%_%displayName%". By performing this step, we ensure that all of the points underneath "TrashCompactor" in the nav tree will have a unique navName. Now our nav tree looks like this:

Site-Equip-Point Nav Tree:
    Richmond
        TrashCompactor
            AHU1_BooleanWritable
        AHU1
            NumericWritable
            EnumWritable

Now simply duplicate AHU1 and run rebuildCache. Our station will look like this:

{site}                                 station:|slot:/Richmond
{equip,siteRef="/Richmond"}            station:|slot:/TrashCompactor
----                                   station:|slot:/AHU1
{equip,siteRef="/Richmond"}            station:|slot:/AHU1/my_equip
{point,cur,equipRef="/AHU1/my_equip"}  station:|slot:/AHU1/NumericWritable
{point,cur,equipRef="/TrashCompactor"} station:|slot:/AHU1/BooleanWritable
{point,cur,equipRef="/AHU1/my_equip"}  station:|slot:/AHU1/EnumWritable
----                                   station:|slot:/AHU2
{equip,siteRef="/Richmond"}            station:|slot:/AHU2/my_equip
{point,cur,equipRef="/AHU2/my_equip"}  station:|slot:/AHU2/NumericWritable
{point,cur,equipRef="/TrashCompactor"} station:|slot:/AHU2/BooleanWritable
{point,cur,equipRef="/AHU2/my_equip"}  station:|slot:/AHU2/EnumWritable
{point,his}                            history:/my_station/AuditHistory
{point,his}                            history:/my_station/LogHistory

Site-Equip-Point Nav Tree:
    Richmond
        TrashCompactor
            AHU1_BooleanWritable
            AHU2_BooleanWritable
        AHU1
            NumericWritable
            EnumWritable
        AHU2
            NumericWritable
            EnumWritable
Clone this wiki locally