Index | Prev | Next

Query context example

This example has two buildings, each with a Modbus network and Modbus Variable Air Volume (VAV) controller. The goal is to monitor supply and return temperatures for each controller. Specifically, this example demonstrates how the query context works.

Hierarchy result

The resulting Nav tree hierarchy under the Hierarchy space looks like this:

Figure 7.   Resulting hierarchy Nav tree
Image

The software monitors the same two points for each device. Without the query context all four points would appear below each VAV device.

Building setup

The Site component (from the Haystack palette) was used to represent each building in the Nav tree. The Site component is useful for this purpose since it is pre-tagged with a number of individual site-related tags which can be used to create alternate hierarchies. Building1 and Building2 are arbitrary names assigned to the components. Each building is assigned the following tags:

  • The Haystack tag, hs:site, identifies the object as a physical site.
  • The implied Haystack tag hs:id=h:{identifier} provides unique identification for each building via the alpha-numeric {identifier} notation. For Building1 hs:id is h:9f2 (as shown), and for Building2 it is h:9f3.
    Figure 8.   Implied tag, hs:id, shown in Edit Tags dialog
    Image

Device setup

The network and VAV controllers are set up under the Drivers folder. ModbusVAV1 and ModbusVAV2 are the arbitrary equipment names. Each device is assigned the following tags and relation:

  • The Haystack tag, hs:equip, identifies the object as a physical device.
  • The implied Haystack tag, hs:id=h:{deviceID}, provides unique identification for each device via the alpha-numeric {deviceID} identifier. In the example, ModbusVAV1’s hs:id is h:83d, and ModbusVAV2’s hs:id is h:841.
  • The Haystack relation, hs:siteRef associates each device with the building in which it is located.

Points setup

VAV performance is monitored by two points (ModbusClientPointDeviceExt):

  • SupplyTemp
  • ReturnTemp

Each point is assigned the following Haystack tag and relation:

  • The Haystack tag, hs:point, identifies the object as a point.
  • The Haystack relation, hs:equipRef, associates each point with the equipment to which it belongs

Hierarchy definition

The hierarchy definition consists of three QueryLevelDefs.

Figure 9.   Level definitions for example hierarchy shown in Property Sheet view
Image

This table explains each property in the hierarchy definition.

Level Name Property Where set up Processing
site QueryLevelDef Query Context: siteId=hs:id Implied name, value tag on each building component: hs:Id={identifier} , where {identifier} is a unique string that identifies the site (Building 1 and Building 2) Establishes the context for the equipment level (next level in the tree) by storing the value of each building’s hs:id (Building 1 or Building 2) in the config facet siteId.
  Query : hs:site Name, value tag on each building component hs:site = h:9f2 or hs:site = h:9f3 Returns components tagged with hs:site.
equipmentQueryLevelDef Query Context: equipId=hs:id hs:Id={identifier}, where {identifier} is a unique string that identifies each device. The equipment Id for ModbusVAV1 is h:83d, and that for ModbusVAV2 is h:841. Establishes the context for the points level by storing the value of each device’s hs:id in the config facet equipId.
  Query: 
hs:equip and 
hs:siteRef->
hs:id = {siteId}
 Set up by the site query context in the previous level definition. Query returns all devices assigned the hs:equip implied marker tag, and the NEQL traverse operator “->” instructs the query to “traverse” the siteRef relationship to determine if that Source Ord value matches the unique siteId context setup in the previous QueryLevelDef, the site level definition.
pointsQueryLevelDef Query Context none  
  Query: 
hs:point and 
hs:equipRef->
hs:id = {equipId}
 Set up by the equipment query context in previous level definition. The implied marker tag on each point, hs:point, returns all data for all points in the system, and the NEQL traverse operator “->” instructs the query to “traverse” the equipRef relationship to determine if that Source Ord value matches the unique equipId context setup in the previous QueryLevelDef, the equipment level definition.

Context processing

In this example:

  • The siteRef=h:9f2 outbound relation on ModbusVAV1 matches the site query context value, siteId=h:9f2, for Building 1 causing ModbusVAV1 to appear under Building 1 in the resulting hierarchy.
    Figure 10.   Examining the ModbusVAV1 siteRef relation in the Relation Sheet view reveals the siteId for Building 1
    Image
  • The siteRef=h:9f3 outbound relation on ModbusVAV2 matches the site query context value, siteId=h:9f3, for Building 2 causing ModbusVAV2 to appear under Building 2 in the resulting hierarchy.

Continuing with the processing of points:

  • The equipRef=h:83d relation on two points labeled SupplyTemp and ReturnTemp matches the equipment query context value, equipId=h:83d, for ModbusVAV1 causing these points to appear under ModbusVAV1.
  • The equipRef=h:841 relation on two additional points SupplyTemp and ReturnTemp matches the equipment query context value, equipId=h:841, for ModbusVAV2 causing them to appear under ModbusVAV2.

Without using config facets to store the site and equipment contexts, a query would place all equipment below each building and all points below each piece of equipment regardless of where the equipment and points actually belong.

 NOTE: When adding facets to the Query Context, the facet values for tag names should be Strings.When comparing tag value to values from the Query Context, make sure the resulting types are the same. from the example above with equipId=hs:id and hs:equipRef={equipId}, the types in the values of hs:id and hs:equipRef must be the same (BOrds in this example). 

Related Links

  • Examples (Parent Topic)

    • Index | Prev | Next