Using the module

once the profile is running and tags are historized, factry historian behaves like a native ignition historian this page covers what that gives you beyond plain trending browsing factry data from ignition power chart, easy chart and every tag history binding read through the profile the browse tree has two roots measurements all active measurements, grouped per collector ignition tags, but also everything factry collects itself over opc ua, modbus, siemens s7, rest or manual entry assets the factry asset tree, with asset properties as leaf tags for operator screens, assets is usually the better entry point the hierarchy follows the plant model maintained in factry, instead of the ignition tag provider layout measurements show as a flat list unless the profile's tag path delimiter is set set it to / to get a folder tree that follows the measurement names aggregated queries aggregation is pushed down to factry, so ignition does not pull raw points to compute an average ignition aggregate factry function average, simpleaverage mean minimum min maximum max sum sum count count lastvalue last range spread variance variance stddev stddev minmax min and max, returned as pairs these ten are the aggregates the module advertises to ignition, so they are what the power chart and queryaggregatedpoints offer for a factry profile array tags work as well ignition sends one update per array element, and the module reassembles those into the full array, so factry stores one array value per timestamp rather than a measurement per index scripting scripting is not needed for normal use historize the tag, then chart or bind it when a project does script against history, nothing has to be migrated system tag querytaghistory resolves against a factry profile, aggregation modes included, and the module also implements the system historian functions ( storedatapoints , queryrawpoints , queryaggregatedpoints , querymetadata , storemetadata and browse ) paths are qualified paths, where the profile name is the name given to the historian profile during setup histprov \<profile name> /sys \<gateway name> /prov \<tag provider> /tag \<tag path> the one thing scripting adds over the tag configuration is storing values that have no tag behind them, such as a lab result or a calculated figure, with system historian storedatapoints current limitations tag annotations are not supported by the module history renaming is not supported renaming a tag produces a new measurement on the next write existing data stays under the old measurement name metadata is create time only description and engineering range are taken from the tag when the measurement is created, and only when the tag has include metadata on measurement metadata cannot be updated afterwards, so later edits in ignition are not pushed and are maintained in factry a string tag cannot be aggregated string measurements return their values in raw queries, and a string tag alongside numeric tags does not affect their results, but an aggregate over a string measurement has no meaningful value deleting a measurement in factry while ignition is writing to it recovers on its own in the normal case factry rejects the next write, the module drops the cached identifier and recreates the measurement under the same name, and storing continues deleting the measurement does not delete its stored data time series data is held per measurement name, and removing it is a separate action in factry, so the recreated measurement reads back the history the old one had what is not restored is everything attached to the old measurement record its asset property links, labels, metadata and any calculations or events that referenced it, because the recreated measurement is a new record if the recreated measurement cannot reach active , most often because the collector has no default time series database, every retry fails and the records end up quarantined instead