Canary Historian
Two connectors for two API generations — choosing between them, and configuring the one you need.
Canary Labs' historian is well represented in Infohub deployments. Infohub provides two connectors, split by API generation, and picking the wrong one produces failures that look like credentials problems.
Which connector#
| Connector | Use for |
|---|---|
| Canary Historian V24 | Canary V24 and later |
| Canary Historian | Earlier Canary versions |
The APIs differ enough that a single connector could not serve both cleanly. Check the Canary server version before configuring, rather than trying one and then the other — a mismatch tends to fail at authentication or during namespace browsing, which sends people looking in the wrong place.
Connection properties#
| Property | Notes |
|---|---|
| Server | Canary server name or address |
| Historian Type | Which Canary service to address |
| Port | Canary listens on its own ports — confirm against the server configuration |
| Username / Password | Canary credentials |
| Maximum Concurrent Connections | How many parallel requests Infohub will make |
The Port property is worth attention. Canary uses specific ports per service, and these are frequently changed from the defaults during installation, particularly where several Canary services run on one host. Get the value from whoever administers the historian rather than assuming.
Historian Type selects which part of the Canary stack you are talking to. If namespace browsing returns nothing but the connection itself succeeds, this is the property to revisit.
Per-measure properties#
| Property | Purpose |
|---|---|
| Tag | The Canary tag path |
| Aggregation | Source-side aggregation when retrieving at an interval |
| Forward Overlap / Backward Overlap | Extend the query window beyond the period |
| Detect SF | Detect the scaling factor automatically |
| Scaling Factor | Apply a fixed multiplier |
| Rollover | Handle a wrapping counter |
| Deadband | Ignore changes below a threshold |
| State Comparator / State | Define what counts as "in state" |
| Filter Tag / Filter Comparator / Filter Value / Filter Default Result | Conditional retrieval |
| Expression | Custom expression evaluated at retrieval |
Detect SF#
Detect SF is specific to this connector family and asks it to determine the scaling factor from the historian rather than having one supplied.
Use it when Canary holds scaled values and you want the connector to resolve the scaling itself. Set an explicit Scaling Factor when you know the multiplier and want it fixed and visible.
Do not set both and hope. Enabling automatic detection and an explicit scaling factor invites confusion about which is in force. Decide which approach the site uses, apply it consistently, and verify a handful of retrieved values against the Canary client before modelling on top of them.
Overlap on slow tags#
Canary logs on change. For a tag that moves rarely — a tank level, a setpoint, a machine state — a period bounded strictly by its own start and end frequently contains no logged value at all.
Backward Overlap is the fix: it lets the connector reach back to the last known value so the period gets the value that was actually in force. Set it generously on slow tags, in hours rather than seconds. See How Infohub Retrieves Data.
Tag paths#
Canary organises tags into a hierarchical namespace. Browse it rather than typing paths — the hierarchy is usually deeper than expected and the separators are easy to get wrong.
Browsing also confirms the connection, the credentials, the port, and the Historian Type are all correct in one action, which makes it the fastest first test after configuring.
Migrating between the two connectors#
When a site upgrades Canary to V24, the measures need to move to the V24 connector. The model itself does not change — only the connection they read through.
A workable sequence:
- Create a new connection using the V24 connector, alongside the existing one.
- Test it and browse its namespace. Confirm the tag paths are what you expect; verify rather than assume they are unchanged.
- Repoint a small number of measures at the new connection and deploy.
- Compare their values against the old connection and against the Canary client.
- Repoint the remainder.
- Leave the old connection undeployed rather than deleting it, until you are confident.
Doing this in one sweep across a large model is possible but leaves you with nothing to compare against if values look wrong.
Keep the old connection for a while. Undeploying rather than deleting costs nothing and gives you a way back. Delete it once a full reporting period has passed on the new connector without surprises.
Aggregation#
Like other historian connectors, the Canary connector offers source-side aggregations including some with no measure-level equivalent. Retrieving at Tag interval and aggregating in Infohub remains the better default — you keep the raw values and your aggregation rules stay uniform across every source in the model.
Retrieve at an interval when the tag is fast enough that raw volume is genuinely a problem, or when you specifically need an aggregation only the source can provide.
Diagnosing#
| Symptom | Check |
|---|---|
| Authentication fails | Wrong connector for the Canary version; credentials; Historian Type |
| Connection succeeds, namespace empty | Historian Type, or the account has no rights to browse |
| Cannot connect at all | Port — confirm against the Canary server configuration, do not assume a default |
| Tag not found | Browse and compare the full path exactly |
| No values on slow-moving tags | Increase Backward Overlap |
| Values consistently out by a factor | Scaling — check Detect SF against an explicit Scaling Factor |
| Retrieval slow | Lower Maximum Concurrent Connections and check the historian's own load |
| Worked before an upgrade, fails after | The site moved to V24 and needs the V24 connector |