Consider the same network with “replicated” device applications described previously in the Alarm extension scenario. In each VAV zone, you wish to have histories of several proxy points, all identically named. For example, in each zone you wish to have a numeric interval history on “RoomTemp” and another one on “Damper.” However, you must either rename the parent point(s) or rename the history extensions’ “historyName” to something unique, as duplicate history Ids are forbidden.

Or (more programatically) before replicating this VAV application, you could edit the “historyName” in all history extensions, similar to the “sourceName” in the previous example.

An example “solution” for this application, showing part of the station’s config structure, including the non-default value entered in the historyName property of two history extensions is shown in Figure 3.

This example uses a different technique than the previous “parent.parent” method, and may be preferable because it is “folder-level independent”, as explained ahead.

Note that each of the two history extensions’ historyName has been changed to use two variables: “%parent.proxyExt.device.displayName%” (plus) “%parent.displayName%”, separated by an underscore. This syntax utilizes a special “getDevice() method” in the first variable, where the proxy point’s parent device’s name is resolved, regardless of its folder depth under the Points extension. (Note 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).

This differs from the “%parent.parent.parent.parent.displayName%” value used in the previous example—in this particular case, that would work for “RoomTemp,” but not for “Damper”. Therefore, this method is more “fault tolerant” as a result of moving a proxy point, especially to change its hierarchy.

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

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 the LonProxyExt. The ‘device’ calls the getDevice() method, and the ‘displayName’ calls the getDisplayName() method.

Note also in this example, the assumption is that no other components in the station will also have a “VAV1” component with a “RoomTemp” child (that also requires a history extension). Also, an underscore was used instead of a space in this case—although spaces in object names are permitted (history being one type of object), they are “escaped” in the database using a “%20” string, and this can be confusing in certain scenarios.