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.
v1.0.21
v1.0.2110 Nov 2026TimescaleDB Historian module for Ignition 8.3 with a TimescaleDB backend.
- Ignition:
- 8.3.0+
- TimescaleDB:
- 2.17+
Changes
- Fixed: the history of a deleted tag could not be queried. In 1.0.20 this started as soon as the tag was deleted, before that after a Gateway restart. Its history is now returned, also after a restart, including for deleted tags that a browse lists.
- Fixed: two Gateways starting at the same moment on one database, such as both nodes of a redundant pair after a module upgrade, could make one of them fail its schema setup while it showed as running. The schema setup now runs on one Gateway at a time.
- Fixed: on TimescaleDB 2.17, turning retention off left the retention of the 5-minute and hourly rollups in place, so they kept deleting old rollup data, and a changed retention age never reached them.
- Fixed: on TimescaleDB older than 2.17, which the module does not support, 1.0.20 gave a new install a unique key those versions cannot use with compression, so a late value could block store-and-forward. Such an install is now created without the key. One that 1.0.20 already gave the key logs an error at every start with the two ways out: upgrade TimescaleDB, or replace the key as the user manual describes.
- Fixed: the migration script 1.0.20-unique-tag-time.sql failed on TimescaleDB 2.17 with compression off, and the backfill script 1.0.19-timestamptz-backfill.sql did not find the rollup jobs to pause on 2.17. Both now work there.
- When the trial expires, the Gateway log now says that the license is why store-and-forward paused, instead of reporting the database as disconnected. The user manual now says that this buffering only works while Ignition's own license still allows storing tag history.
- The module's database sessions are named Ignition TimescaleDB Historian in pg_stat_activity.
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 on Ignition 8.3.3, and of the previous one on 8.3.10. Count shows 1 for it.
- Aggregates other than LastValue leave out a sample exactly at the end of the query window.
- Aggregates other than Count, PctGood and PctBad include Bad-quality values, and every aggregated value except LastValue is reported with Good quality.
- LastValue skips rows stored without a value: when a tag went Bad without a value at the end of an interval, LastValue shows the sample before it, with that sample's quality.
- NULL values read back from the database come out as 0.0.
- A data type change that cannot keep the old values, such as Float to String, starts a new entry. Queries return the values from the change on; the older values stay in the database but are no longer returned.
- A browse with snapshotTime lists a tag renamed since under its new path, not the path it had then.
- The 72 hours an expired trial keeps collecting start again after a Gateway restart, or after disabling and enabling the historian.
- On TimescaleDB 2.24, each 5-minute rollup refresh takes a few seconds even when there is little new data. TimescaleDB 2.31 does not have this cost.
- A redundant pair upgraded from 1.0.20 one Gateway at a time can still hit the schema setup problem fixed in this version once, while the other Gateway still runs 1.0.20. Restart that Gateway, or save its historian settings.
v1.0.20
v1.0.2010 Nov 2026TimescaleDB Historian module for Ignition 8.3 with a TimescaleDB backend.
- Ignition:
- 8.3.0+
- TimescaleDB:
- 2.17+
Changes
- Upgrading from 1.0.19 or earlier: DurationOn and DurationOff now return seconds, as documented. They returned milliseconds, so a report or script that divided them by 1000 must stop doing so.
- Upgrading from 1.0.19 or earlier: Average, SimpleAverage, Minimum, Maximum, MinMax, Sum and Range were wrong for aggregate intervals longer than 5 minutes, such as 10 minutes or a day. They now return one value per interval, so reports and charts built on them can show different numbers. CountOn and CountOff no longer count the first sample of the window as a transition, and an unknown aggregation name returns Bad quality instead of silently using Average.
- Upgrading from 1.0.19 or earlier: when the trial expires, the module no longer writes to the database. It keeps collecting into store-and-forward for 72 hours and writes that data once the module is activated; after that, new data is lost until activation. Earlier versions kept writing, so a Gateway on an expired trial stops writing as soon as it is upgraded.
- Upgrading from 1.0.19 or earlier: system.historian.browse now returns result quality Error_Exception when it fails, instead of an empty result with Good quality. That includes a database error, a root without a gateway or provider part, and a continuation point from another browse or from 1.0.19: start such a browse again.
- Upgrading from 1.0.19 or earlier: a historian profile on its own schema, in a database whose public schema also holds the module's tables, now runs its own compression, retention and cleanup jobs. On its first start after the upgrade it compresses its older history once and, with retention on, deletes data older than the retention age.
- The database migration scripts are now a download on this page, TimescaleDB-Historian-migrations.zip, and the user manual has a chapter on which ones you need and how to run them.
- A new install has a unique key on tag and timestamp, so a value that store-and-forward delivers twice, for example after a database failover, is stored once. The first value stored for a tag and time is kept, also over a later correction or import at that time. Existing installs can add the key with 1.0.20-unique-tag-time.sql from the migrations download; with compression on it needs TimescaleDB 2.24 or newer. Once a table has the key, only module 1.0.20 or later may write to it; the user manual explains how to remove the key before going back to an older version.
- New setting Index t_stamp_tz for SQL Tools (off by default): with Extra timestamptz Column on as well, external SQL tools that select a tag's values by t_stamp_tz read only an index. The cost is roughly double the disk space for data that is not compressed yet. Chunks that already hold data get the index from 1.0.20-t-stamp-tz-index.sql in the migrations download, which runs while the Gateway keeps recording.
- A historian profile can now use its own schema with just currentSchema=site2 in the JDBC URL. When that schema is missing or the user may not use it, the profile status names the statement that fixes it.
- New store-and-forward engines use a 5 second time threshold instead of 30, so a Gateway that stops during a database outage loses at most about 5 seconds of values from memory. Existing engines keep their setting: change it under Platform → System → Store & Forward.
- The user manual has a new chapter on running the historian on a redundant pair of Gateways. Tag metadata, deletions and renames now use the Gateway's current system name, so a redundant backup that has taken the master's name records under that name.
- Fixed: connected to a read-only standby, the historian showed Running while every write failed. It now holds the data in store-and-forward and resumes by itself after promotion. Tag metadata and deletions made while the database was down are now kept and written when it returns, and forwarding no longer stays paused after an outage until someone opens the historian status page.
- Fixed: a deleted or renamed tag could come back as a live tag when a value collected before the change arrived late through store-and-forward. Such a value is now stored as history of the old tag.
- Fixed: changing a tag's data type kept recording it with the old type. A change that keeps every old value, such as Integer to Float, now applies in place and keeps all history visible; other changes start a new entry, as the SQL Tag Historian does.
- Fixed: a string value with a NUL character, such as a padded PLC string, was refused by the database and blocked its whole store-and-forward batch for good. NUL characters are now removed, and data already stuck in store-and-forward is stored after the upgrade. Tag metadata with a control character or a NaN is now stored too.
- Fixed: LastValue missed a sample exactly at the end of the query window, reported Good for every value and returned nothing for String and DateTime tags.
- Fixed: system.historian.browse now lists every tag in a recursive browse from the root, honours snapshotTime and includeMetadata, and returns paths that Ignition can parse back, each once.
- Fixed: on TimescaleDB 2.24, a new installation's 5-minute and hourly rollups could keep one stale 5-minute bucket, and the 5-minute refresh job failed on every run.
- Faster queries on large installations: looking up 1,000 tag paths among 100,000 tags drops from about 0.8 s to 16 ms, bounding values for a single tag read only that tag's samples, and LastValue over intervals of an hour or more reads the index instead of the whole window.
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 on Ignition 8.3.3, and of the previous one on 8.3.10. Count shows 1 for it.
- Aggregates other than LastValue leave out a sample exactly at the end of the query window.
- Aggregates other than Count, PctGood and PctBad include Bad-quality values, and every aggregated value except LastValue is reported with Good quality.
- LastValue skips rows stored without a value: when a tag went Bad without a value at the end of an interval, LastValue shows the sample before it, with that sample's quality.
- NULL values read back from the database come out as 0.0.
- A data type change that cannot keep the old values, such as Float to String, starts a new entry. Queries return the values from the change on; the older values stay in the database but are no longer returned.
- A browse with snapshotTime lists a tag renamed since under its new path, not the path it had then.
- The 72 hours an expired trial keeps collecting start again after a Gateway restart, or after disabling and enabling the historian.
- On TimescaleDB 2.24, each 5-minute rollup refresh takes a few seconds even when there is little new data. TimescaleDB 2.31 does not have this cost.
- The history of a deleted tag cannot be queried: the query returns no rows although the data is still in the database. A browse with snapshotTime or includeRetired still lists such tags.
- Two Gateways upgrading to 1.0.20 at the same moment on one database, such as a redundant pair restarted together, can make one of them fail its schema setup while its profile still shows as running. Restart that Gateway, or save its historian settings.
- On TimescaleDB older than 2.17, which the module does not support, a new install still gets the unique key on tag and timestamp. A value that arrives late for a compressed chunk is then refused, and its store-and-forward batch is retried without end. Use TimescaleDB 2.17 or newer.
v1.0.19
v1.0.196 Oct 2026TimescaleDB Historian module for Ignition 8.3 with a TimescaleDB backend.
- Ignition:
- 8.3.0+
- TimescaleDB:
- 2.17+
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.
v1.0.18
v1.0.1821 Aug 2026TimescaleDB Historian module for Ignition 8.3 with a TimescaleDB backend.
- Ignition:
- 8.3.0+
- TimescaleDB:
- 2.17+
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.
- Fixed: a historian whose password came from a Referenced secret on another Gateway recorded nothing after a Gateway restart, until someone disabled and re-enabled the profile by hand. The module read the secret while the historian was starting, which happens before the Gateway Network link to the Gateway holding that secret is up. The failed read was treated as an empty password and kept for the life of the profile. This is the usual OT/IT split, secrets on one Gateway and recording on another, so it hit every restart of the recording Gateway. The module now retries the read every 5 seconds and swaps the credential into the live connection pool as soon as it succeeds, so recording resumes on its own within seconds of the Gateway Network coming up. Store-and-forward buffers the data in the meantime and forwards it once the connection is back.
- A password secret that cannot be read now says so. The only symptom used to be Postgres reporting that the password was an empty string, which sends you off checking database credentials that were correct all along. The profile now reports that the secret could not be read and names the secret provider and its Gateway Network connection, and the module no longer opens a connection with a credential it knows it does not have.
Known issues
- Two historian profiles pointing at the same database and schema will fight over compression and retention. Each profile applies its own settings, so the policies 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 the data is intact and only the display is affected.
- NaN and Inf values are stored correctly, but they distort any aggregate calculated over them.
- 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.