Back to TimescaleDB Module

Releases

TimescaleDB Module for Ignition 8.3

Every published version of the module, with the Ignition and TimescaleDB versions it has been verified against, plus a direct download for the .modl asset.

  1. v1.0.19

    v1.0.196 Oct 2026

    TimescaleDB Historian module for Ignition 8.3 with a TimescaleDB backend.

    Ignition:
    8.3.0+
    TimescaleDB:
    2.13+

    Changes

    • Upgrading from 1.0.16 or earlier: tag metadata is now kept as a version history in a new table. Metadata recorded before the upgrade stays in the old column, which the module no longer reads, so queries do not return it until it is converted. Contact us for the migration script that converts it. If several Gateways share one historian database, run the script only after all of them are upgraded. Tags whose metadata is sent again, on a configuration change or the next Gateway restart, get a fresh version either way.
    • Upgrading from 1.0.16 or earlier: data retention is now a setting on the historian profile, and it is off by default. While it is off, the module removes any retention policy it finds on its own tables, including one added by hand in SQL. If you set one up yourself, switch retention on in the historian profile, or the database will start growing again.
    • Upgrading from 1.0.16 or earlier: compression never actually ran in those versions. The first compression run after the upgrade works through the whole backlog at once, so expect a period of heavy database activity followed by a large drop in disk usage. No action is needed.
    • New setting Extra timestamptz Column (off by default). It adds a t_stamp_tz column for external SQL tools, such as Grafana or a BI tool, that can only filter on a real timestamp. A query that filters on it reads only the time window you ask for instead of the whole history of a tag (this needs TimescaleDB 2.16 or newer). Turning the setting off never drops the column or its data.
    • Data stored before you turn the timestamptz column on needs a one-time backfill script. It can run while the Gateway keeps recording, but it rewrites the whole table, so plan it on a large database. Contact us for the script.
    • Fixed: a Gateway restart or a historian settings save could stop recording for as long as another session was reading the historian tables, for example a nightly pg_dump. Store-and-forward kept the data, so nothing was lost. The module now gives up on that schema check after 3 seconds and tries again on the next restart or save.
    • Fixed: the LastValue aggregate failed for every tag (in a Power Chart, system.tag.queryTagHistory or system.historian.queryAggregatedPoints) and returned Bad quality. It now returns the last value stored in each interval.
    • Fixed: system.historian.browse ignored its name filters and returned every tag. Filters now work like the SQL Historian's: matched against the tag path, case-insensitive, with * and ?. For example 'PRF*' selects everything under PRF/ and '*/speed' finds a tag in a folder.
    • Fixed: system.historian.browse stopped at maxSize without saying more results existed. It now returns a continuation point to fetch the next page. Results are now sorted, folders first and then by name.
    • The Gateway log now states the retention age whenever retention is on, and warns when it is the default age, because retention deletes data permanently.

    Known issues

    • On Ignition 8.3.3 to 8.3.8, the historian create form shows numeric fields such as Retention (days) empty and Enable Compression unchecked. The profile is still saved with the defaults (compression on, 7 and 365 days), so enter the retention age yourself before turning retention on. Inductive Automation has announced a fix for 8.3.9.
    • Two historian profiles pointing at the same database and schema will fight over compression, retention and the timestamptz column. Each profile applies its own settings, so they flip back and forth. Give each profile its own schema or database.
    • Annotations that were not created by hand do not always render on a chart. They are stored correctly, so only the display is affected.
    • NaN and Inf values are stored correctly, but they distort any aggregate calculated over them.
    • In an aggregated query, an interval without data shows the value of the next interval that has data, and Count shows 1 for it.
    • Aggregates other than Count, PctGood and PctBad include Bad-quality values, and every aggregated value is reported with Good quality.
    • NULL values read back from the database come out as 0.0.
    • A tag's data type cannot be changed in place. Remove the tag and create a new one.