Control Seat V0.1.6
V0.1.6 is a depth release. The headline change is bring-your-own historian — Control Seat can now write tag history to an existing TimescaleDB or another supported store you already operate, instead of, or alongside, the built-in historian. We also added configurable retention and fixed several scale-related rough edges around MQTT, Sparkplug, large tag systems, and PI performance.
What's in V0.1.6
Bring your own historian
A new Historian Providers page lives at Gateway → Network → Historian Providers. Add a TimescaleDB instance (or any supported store) with a connection URL, name it, and Control Seat treats it as a first-class destination for tag history. Per-tag history policies can target any provider — keep the local high-rate stuff in Control Seat's built-in historian, push long-retention data to your TimescaleDB, or run everything through your existing TSDB. Migrating a tag between providers is a one-field change in the tag form; values keep flowing while the policy switches.
Why bring-your-own:
- You already have a TSDB. If you're running TimescaleDB, InfluxDB, or another time-series store for the rest of the plant, point Control Seat at it instead of running parallel infrastructure.
- Long-retention separation. Keep 30 days hot in the local historian, 5 years cold in your warehouse — without giving up the single tag namespace inside Control Seat.
- One pane of glass. Trends Workbench, dashboards, alarms, scripts, and the API all read from the same tag path no matter which provider owns the bytes underneath.
The internal historian still ships and is still the default. You can run with zero external providers and nothing changes for you.
Configurable historian retention
Each historian (the built-in one and every connected external provider) now exposes a retention field on the Historian Providers page. Set it to a fixed window — 30d, 1y, whatever your operations and storage policies require — or pick Forever to drop the TTL entirely and keep data as long as the underlying store allows.
How retention works:
- Cloud deployments. Retention changes apply automatically with no downtime.
- Self-hosted deployments. Retention changes are applied during normal operation.
- External historians. Control Seat uses the retention controls supported by the connected provider.
If you were already running v0.1.5, your tenants stay on the existing 30-day default — open the Historians page and bump it up only if you want longer retention.
MQTT — disconnects propagate as bad quality
When an MQTT broker or subscription drops out, every tag bound to it is now marked bad quality with the disconnect reason — instead of leaving values frozen at whatever last came through. Same behavior as V0.1.5's Sparkplug DEATH cascade, applied generally:
- Broker offline. All tags bound to that broker flip to bad quality. Charts and bindings see the change immediately; scripts can branch on
value.quality. - Subscription unsubscribed / deleted. Only the affected tags drop quality, not the whole broker tree.
The status survives across reconnects — values stay flagged bad until a real republish replaces them, so a transient blip doesn't quietly leave half a dashboard reading stale numbers.
Sparkplug DDATA without DBIRTH
When a device sends a DDATA payload before any DBIRTH (because the broker missed the birth message, or because the device restarted before Control Seat reconnected), the previous behavior was to drop the message — there was no alias table to resolve against. V0.1.6 accepts DDATA payloads that arrive with metric names instead of alias IDs and routes them correctly while we wait for the next DBIRTH to rebuild aliases. No more silent gaps when a device cycles independently of the broker.
Bulk historian configuration during MQTT import
When you import a Sparkplug or topic-wildcard subtree (which can pull in thousands of tags), the import dialog now lets you set the historian policy + provider for the whole batch in one step. Pick a retention window, pick a provider, hit import — every newly-created tag inherits the policy. No more clicking through 2,000 tag forms after a bulk import.
Tag browser + tree, optimized for 100k+ systems
We made a round of performance improvements focused on customers running 80k-150k tags:
- Lower memory pressure on the gateway.
- Smaller browse payloads.
- Faster initial editor load.
If you saw the gateway peg a core during heavy editor browsing, V0.1.6 will feel different.
AVEVA PI — efficiency upgrades
Customers with thousands of PI-bound tags were saturating CPU on the gateway side because the PI driver was over-issuing requests during reconnect storms and re-importing more metadata than needed. V0.1.6 reshapes the PI poll batches and metadata reads:
- More efficient bulk lookup. Imports and reconnects make fewer PI API calls.
- Adaptive poll intervals. Tags that do not change are checked less aggressively, while fast-moving tags keep their configured rate.
- Better transient-error handling. A flaky PI server now backs off cleanly and surfaces the reason in the tag form.
Net result: a fully-bound PI deployment that used to keep a vCPU busy at idle now sits near zero load.
AI tools for the new historian page
The Gateway AI assistant can now help with historian-provider setup, including listing configured providers, proposing per-tag policy changes, and explaining what happens when you switch providers.
Smaller things worth knowing
- AI cleanup. Internal work to support the new historian-provider features more cleanly.
- Automatic upgrade support. The new historian-provider data model is applied automatically during upgrade, and rollback to V0.1.5 remains supported.
Self-hosted? Re-download from controlseat.com/download — installers update in place and your data carries over. New to on-prem? The on-prem deployment guide walks through it. Already on cloud? You've been auto-updated. Want to wire up TimescaleDB as your historian destination? Get in touch — happy to help you scope retention + provider topology.