BFormat example: naming histories

This example uses a technique other than the %parent.parent% script to name histories. This method may be called the folder-level-independent method, as explained in this topic.

History extension scenario

Consider a VAV network with replicated device applications. In each VAV zone, you need the histories of several proxy points, all identically named. For example:

  • Each zone requires a numeric interval history on RoomTemp.

  • Each zone requires a numeric interval history on Damper.

To manually configure these requirements you must either rename the parent point(s) or rename the history extensions’ historyName to something unique, as duplicate history IDs are forbidden.

To automatically create unique histories names, before replicating this VAV application, you add a BFormat to the historyName in all history extensions, similar to editing the sourceName when naming points.

Figure 1. Example config structure and history extension property values using edited BFormat scripts


  • VAV1 is a Lon device object.

  • Points is the point device extension.

  • Inputs is a Lon point folder.

  • RoomTemp and Damper are numeric Lon proxy input points each with a proxyExt and a numericInterval history extension as child nodes.

  • historyName is a numericInterval property on each history extension (double-click the numericInterval node to view its property sheet).

Figure 2. Lon device points showing a NumericInterval Property Sheet


Instead of entering a value for this property on each of 60 property sheets, the following BFormat script resolves to a unique name for each VAV:%parent.proxyExt.device.displayName%_%parent,displayName%

This name contains two variable scripts separated by an underscore.

  • The variable script on the left of the underscore uses a special getDevice() method, where it resolves the proxy point’s parent device name regardless of its folder depth under the Points extension. (In this example, proxy point RoomTemp is in an Inputs point subfolder, while the Damper proxy point is in the root of the Points extension).

    Because the points are located in different folders, the %parent.parent% script would work for RoomTemp, but not for Damper. The folder-level-independent method, however, is more fault tolerant as a result of moving a proxy point, especially to change its hierarchy.

  • The variable script to the right of the underscore resolves to the proxy point name (RoomTemp and Damper)

Given the tree structure of this network, the resulting histories appear as VAV1_RoomTemp, VAV1_Damper, and if replicated, VAV2_RoomTemp, VAV2_Damper, and so on.

Here is how this works: %parent.proxyExt.device.displayName%, the parent, steps up one level to the Lon proxy point (say, RoomTemp). The proxyExt is the slot name that walks back down the tree to a different child component, in this case to the LonProxyExt. The device calls the getDevice() method, and the displayName calls the getDisplayName() method.

This example assumes that no other components in the station also have a VAV component with a RoomTemp child, which also requires a history extension. Also, the example uses an underscore instead of a space even though spaces in object names are permitted (history being one type of object), they are escaped in the database using a “%20” string. This can be confusing in certain scenarios.