Ignition Historian
Infohub reads Ignition's historian database directly — which database engines are supported, and why the gateway name matters.
Inductive Automation's Ignition stores historical tag data in a relational database rather than in a proprietary store. Infohub's Ignition connector reflects that: it connects to the database Ignition logs into, and understands Ignition's schema and partitioning on top of it.
That design has consequences worth knowing before you configure it.
Connection properties#
| Property | Notes |
|---|---|
| Database Type | Which relational engine holds the Ignition history |
| Server | Database server address |
| Database | The Ignition history database name |
| Port | Database port |
| TimescaleDB | Set when the history is stored in a TimescaleDB-extended PostgreSQL |
| Gateway Name | The Ignition gateway whose data you are reading |
| Username / Password | Database credentials, not Ignition login credentials |
| Timeout (seconds) | Query timeout |
| Maximum Concurrent Connections | Parallel query limit |
These are database credentials. The username and password are for the database engine, not for the Ignition gateway. A perfectly valid Ignition operator account will not authenticate here. You need an account on SQL Server, PostgreSQL, MySQL, or whichever engine Ignition logs into, with read access to the history tables.
Gateway Name#
Ignition history tables record which gateway produced each value. In an installation with more than one gateway logging into the same database — common in larger or redundant deployments — Gateway Name is what separates them.
Get it wrong and you may see no data at all, or, more awkwardly, data from the wrong gateway. If a connection works but the values do not match what the Ignition client shows, check this property.
TimescaleDB#
Where Ignition logs into PostgreSQL with the TimescaleDB extension, set the TimescaleDB flag. The storage layout differs enough that the connector needs to know, and leaving it unset against a Timescale-backed history produces empty or partial results rather than an error.
Per-measure properties#
| Property | Purpose |
|---|---|
| Tag | The tag name |
| Path | The tag's path within its provider |
| Type | Tag data type |
| TagId | Ignition's internal tag identifier |
| Aggregation | Source-side aggregation when retrieving at an interval |
| Rollover | Handle a wrapping counter |
| Deadband | Ignore changes below a threshold |
| State Comparator / State | Define what counts as "in state" |
| Expression | Custom expression evaluated at retrieval |
Path and TagId both appear because Ignition identifies tags in two ways. Browse the namespace and let the connector populate them rather than filling them in by hand — the internal identifier in particular is not something to guess.
A retagged Ignition tag can break an Infohub measure. Because Ignition history rows key off an internal tag identifier, a tag that is deleted and recreated in Ignition — even with the same name — can be a different identity in the history tables. If a measure stops producing values after Ignition configuration work, re-browse and reselect the tag rather than assuming the name is enough.
Database access, and the argument about it#
Infohub reads Ignition's history database directly, which raises a reasonable question: why not just use a plain SQL connector?
Use the Ignition connector. It understands the schema, the partitioning scheme Ignition uses to split history across tables over time, the tag identity mapping, and the quality encoding. A hand-written SQL query has to reimplement all of that and re-verify it after every Ignition upgrade, because the schema is Ignition's to change.
Reach for the plain SQL connector only for data that genuinely is not tag history — production records or custom application tables that happen to live in the same database.
Permissions and the service account#
The account needs read access to the Ignition history tables. Two practical notes.
Read-only is enough, and is what you should ask for. Infohub never writes to the historian.
Partitioned history needs ongoing access. Ignition creates new history tables over time. An account granted rights on the tables that existed at setup will silently stop seeing new data when the next partition appears. Grant rights at the schema or database level so new tables are covered.
That second point is a genuinely awkward failure: everything works for weeks, then retrieval quietly stops returning recent values while historical queries still succeed.
Load on the database#
Infohub's queries land on the same database Ignition is actively logging into. Coordinate with whoever owns it:
- Keep Maximum Concurrent Connections modest to begin with.
- Set a sensible Timeout so a slow query fails rather than holding a connection open.
- Prefer retrieving at Tag interval and aggregating in Infohub over many small interval queries, since fewer, larger queries are usually kinder to the database than many narrow ones.
If the database is under pressure, that is a conversation with its administrator rather than something to tune away in Infohub alone.
Diagnosing#
| Symptom | Check |
|---|---|
| Authentication fails | Database credentials, not Ignition credentials |
| Connection succeeds, no tags listed | Gateway Name, or database read permissions |
| Empty or partial results on PostgreSQL | TimescaleDB flag not set |
| Values do not match the Ignition client | Wrong Gateway Name |
| Measure stopped after Ignition config work | Tag recreated with a new internal identity — re-browse and reselect |
| Recent data missing, history fine | Permissions do not cover newly created partition tables |
| Queries timing out | Raise Timeout, lower concurrency, and check database load |
| Tag not found | Browse rather than typing; Path and TagId must match |