Timebase Historian

Connection properties#

Per-measure, there is a single property: Tagname.

That simplicity is the point. Where a historian connector needs overlap, scaling, rollover, and filter properties to paper over decades of accumulated variation, Timebase was designed for this job and the connection carries the complexity instead of each measure.

Two endpoints, not one#

Unlike most connectors, this one talks to two services: the historian itself, and an identity provider that issues the credentials to reach it.

That means two host-and-port pairs, two TLS settings, and two things that must be reachable from the Platform hosting the connection. When a connection fails, establish which of the two is the problem before changing anything — an unreachable identity provider and an unreachable historian both present as "cannot connect".

Use Authentication gates the identity provider entirely. Where Timebase is configured without authentication — an isolated evaluation environment, typically — the IdP properties are not needed. For anything beyond evaluation, authentication should be on.

Client credentials#

IdP Client and IdP Client Secret are a client credentials pair issued by the Timebase identity layer, not a user's login. The secret is stored encrypted on the connection.

Practical points:

• Create a dedicated client for Infohub rather than reusing one belonging to a person or another application. It can then be granted exactly the read access it needs and revoked without affecting anything else.
• Grant read-only access. Infohub never writes to Timebase through this connector.
• Record the client identifier somewhere alongside your other integration credentials, so that when it is eventually rotated, whoever does it knows Infohub depends on it.

Datasets#

Timebase organises data into datasets, and the connection targets one.

If you need to read from several datasets, create one connection per dataset. That is the intended shape, and it has the useful side effect of making the model's dependencies explicit: you can see at a glance which parts of the plant model read which dataset.

Getting the dataset wrong produces a connection that succeeds and a namespace that is either empty or contains entirely unexpected tags — a good early signal to check this property rather than the credentials.

TLS#

There are two independent TLS settings, one per endpoint. Enable both for anything that is not a throwaway evaluation.

Because the two are separate, a common misconfiguration is encrypting one leg and not the other. Check both when reviewing a connection, and remember that the certificate trust applies to the machine hosting the connection — the Platform host — not to the workstation where Flow Config runs.

Tag names#

Per-measure configuration is a single Tagname. Browse the namespace to select it rather than typing.

Browsing here is a particularly efficient test, because it exercises the whole chain at once: network path to the identity provider, credentials, token issue, network path to the historian, TLS on both legs, and the dataset selection. If browsing returns tags, the connection is genuinely working.

Retrieval#

Retrieve at the Tag interval and aggregate in Infohub, as with any source. You keep the raw values, and your aggregation rules stay uniform across every source in the model. See Retrieved Measures.

Writing Infohub results back to Timebase#

Asked directly by integrators: can Infohub's calculated measures be written into Timebase, so the historian carries the derived values alongside the raw ones?

The honest answer for 7.2.0: there is no Timebase data consumer — this connector reads only. The alternatives, in order of preference:

• Publish via MQTT/Sparkplug to a broker a Timebase Collector already logs from — Infohub's MQTT consumer out, Timebase's collection in. This is the supported composition today, and it keeps Timebase's ingest on its own front door.
• Let the consuming system read the derived values from Infohub (API or consumer) rather than insisting they live in Timebase.

If the requirement is strategic rather than tactical, raise it as a product request — it is a known and reasonable ask.

Diagnosing#

See also#

• How Infohub Retrieves Data
• Choosing a Data Source
• Connection Property Reference