About persisting fetched tags
In Niagara, there is an added frozen Boolean property on the NiagaraNetwork called Persist Fetched Tags. When set to true for any descendent station proxy
point, it causes the n:history tag (and any other
tags configured for fetching) to persist on the proxy control point
as read-only metadata (as a direct tag).
This is useful in conjunction with the Niagara feature that allows you to add a proxy point to a web
chart I a Supervisor station. The added proxy point resolves the local history
to initialize the web chart. If the connection to the remote station
goes down, persisting the n:history tag finds the
local history (provided you previously visited the point when the
connection was up) and persists the n:history tag
information.
n:history tag is an implied
tag that is also added to local control points if they have an active
history extension child. The tag is not limited only to proxy points
on a Supervisor station.You enable the Persist Fetched Tags property on the client side of the NiagaraNetwork connection. That is to say, whichever is the consumer of the data. Typically, the Supervisor station is the enabled client since it would be fetching from the remote controller. But in a controller-to-controller connection you enable the property on whichever of those clients is the consumer of the data.
Related properties
You may add two optional properties that specify additional remote tags to pull from the remote controller to Supervisor and persist on the corresponding proxy points (or virtual components). The properties are: tagsToFetch and persistVirtualFetchedTags (false by default). These optional dynamic properties are only useful when the Persist Fetched Tags property set to true. To configure either of these optional properties, you must first add the slot to the client side proxy points, and then in the Property Sheet view enter the comma delimited names of additional tags to be fetched.
n:history tag regardless of the value
of these optional properties.