Connecting Input Datasources

An input datasource is one logical source of sensor data — an OPC-UA endpoint, an MQTT topic group, a CSV replay file, and so on. Each source is a typed adapter with its own connection settings and tag list. You map its tags to your model’s input channels, then enable it to start inference.

The Data Sources screen — add a source, map its tags, pair a model, enable.

Supported input sources

• OPC-UA — subscribe to tags from any compliant server.
• MQTT — bring-your-own broker, TLS supported.
• CSV — replay recorded data from a file (great for testing).

One input enabled at a time

At most one input datasource can be enabled at any moment. Enabling a new source automatically disables the previous one. This keeps the runtime bound to a single, predictable stream.

Walkthrough: add a source and start inference

1. Open the Datasources page

   In the dashboard, go to Datasources → Input, then click + Create.

2. Pick the adapter type and fill the connection

   Select the source type. The form adapts to the protocol you choose — fill in the endpoint, credentials, and any protocol-specific fields. Secret fields (passwords, tokens) are masked as *** after saving.

   OPC-UA

   Field	Example
   Endpoint	opc.tcp://your-opcua-host:4840/factory/line1
   Security policy	None (or a Basic256Sha256 profile with certificates)
   Authentication	Anonymous (or username/password)

   Tags are referenced by NodeId, e.g. ns=2;i=2 (numeric) or ns=2;s=Temperature (string).

   MQTT

   Field	Example
   Broker URL	mqtt://your-broker-host:1883 (or mqtts:// for TLS)
   Base Topic	factory/line1/# — used for Browse/Test Connection discovery; leave empty to fall back to # (whole broker)
   Client ID	optional (leave blank to auto-generate a unique id)
   Username / password	optional (masked on save)

   Tag names are the full topic path (e.g. factory/line1/temp). Once the datasource is enabled and running, the adapter subscribes only to its mapped tags — not the Base Topic wildcard — so the broker forwards just what you mapped. Use Browse to discover tags from traffic observed on the Base Topic (MQTT has no topic-enumeration API, so the adapter waits briefly for messages); a topic that never publishes during that window needs a hand-typed tag. String payloads (e.g. a RUN/STOP status topic) never become tags.

   CSV

   Field	Example
   File	a recorded dataset to replay
   Columns	the sensor columns to feed as channels

   CSV is replay-only — useful for testing a model without a live plant connection.

3. Map tags to model channels

   List the tags you want to stream and assign each to a numbered input channel (0, 1, 2, …). Each channel feeds one model input. Set the window size — how many consecutive samples the model consumes per prediction — to match the model you will pair.

   Channel mapping must be complete

   Provide exactly one tag per channel, with no gaps. Validation rejects an enable if any channel is unmapped or over-filled. String tags (e.g. a RUN/STOP status) cannot be used as numeric features — skip them when defining channels.

4. Save and pair a model

   Save the datasource. Then pair it with a model you uploaded under Models. The platform runs a compatibility check — window size × feature count must agree on both sides — and rejects the pairing if they differ.

5. Enable, then start

   Toggle Enable on the row. This validates the configuration, loads the paired model, and connects the adapter. The connection handshake (OPC-UA / MQTT) happens here, so a network or credential problem surfaces now and rolls the row back to Disabled with an error message.

   Enabling does not auto-start streaming — click Start to begin inference.

Conditional fields and switches

The config form only shows fields relevant to what you’ve already chosen. On the MQTT tab, TLS fields (CA certificate, client cert/key, allow-untrusted) appear only once TLS is switched on. On the OPC UA tab, client certificate/key fields appear only under Certificate authentication, and username/password only under Username/Password authentication. Every on/off switch in the form shows its state as a check or cross inside the track, not by colour alone.

Security modes: Insecure, TLS, and Secure

Every network protocol can run in three postures. Pick the highest one your endpoint supports — Insecure is for bench and lab work only, never for a plant network.

Certificates referenced below live in the bundle’s certs/ directory, mounted read-only into the backend at /certs (enable with AIBOARD_CERTS_ENABLED=1 in the bundle .env). Config fields accept only paths under /certs — anything outside the jail is rejected. Copy only the CA certificate and the client certificate/key pair to the box; the CA private key and broker/server keys must never leave your PKI host.

OPC-UA

Insecure

Field	Value
Security policy	None
Message security mode	None
Authentication	Anonymous

No encryption, no identity — anyone on the network can read tag values and impersonate the server. Acceptable only against the local demo lab or an air-gapped bench.

TLS (signed)

Field	Value
Security policy	Basic256Sha256
Message security mode	Sign or SignAndEncrypt
Authentication	Username/Password
Server CA certificate	/certs/ca/ca.crt

The channel is signed/encrypted and the server proves its identity against the CA you provide. Leave Accept untrusted certificates off — switching it on silently disables the server identity check.

Secure (best practice)

Field	Value
Security policy	Basic256Sha256 (or Aes256_Sha256_RsaPss if the server supports it)
Message security mode	SignAndEncrypt
Authentication	Certificate
Server CA certificate	/certs/ca/ca.crt
Client certificate / key	/certs/clients/opcua-user.crt · /certs/clients/opcua-user.key

Mutual authentication: the box proves its identity with a client certificate and the server is verified against your CA. Register/trust the client certificate on the OPC-UA server first, or the handshake is rejected there.

MQTT

Insecure

Field	Value
Broker URL	mqtt://broker-host:1883
TLS	off
Username / password	empty (anonymous)

Plaintext and anonymous — readable and spoofable by anyone on the segment. Lab use only.

TLS (server auth)

Field	Value
Broker URL	mqtts://broker-host:8884
TLS	on
CA certificate	/certs/ca/ca.crt
Username / password	broker account (masked after save)

The broker proves its identity via TLS; the box authenticates with credentials. Leave Allow untrusted certificates off in production — it exists only to unblock bench setups with self-signed brokers.

Secure / mTLS (best practice)

Field	Value
Broker URL	mqtts://broker-host:8883
TLS	on
CA certificate	/certs/ca/ca.crt
Client certificate / key	/certs/clients/mqtt-client.crt · /certs/clients/mqtt-client.key

Mutual TLS: both sides present certificates. Combine with a broker ACL that limits this client to exactly the topics it needs — the box subscribes only to mapped tags, so a tight ACL costs nothing.

CSV

CSV is file-based — there is no network channel to secure. The protections are filesystem-level and already enforced:

• File paths are jailed under the CSV root (/data/csv in the container, AIBOARD_CSV_ROOT); path-traversal attempts are rejected.
• Mount replay datasets read-only, and keep the CSV volume on the box — exporting it off-box is a data-governance decision, not a datasource setting.

Best-practice ladder

Lab → Insecure to get the pipeline flowing; staging → TLS to validate certificates and credentials; production → Secure/mTLS with least-privilege accounts and ACLs. The demo lab ships all three postures (ports 1883 / 8884 / 8883) so you can rehearse the full ladder before touching plant equipment — see Docker Lab Walkthrough.

Test the connection first

Before enabling, use Test Connection on the source. It verifies the live form values reach the endpoint, so you catch a wrong host or credential before wiring tags.

MQTT: staleness window, reconnect, and non-finite rejection

MQTT pushes readings; inference pulls one sample per tick. A cached tag value expires after clamp(50 / SamplingHz, 5s, 60s) — at the default 10 Hz that’s 5 seconds. Past that window a stale tag raises a read failure and halts inference, the same as if the sensor had gone quiet.

Breaking change: slow topics can halt inference

If a mapped topic publishes less often than the stale window, inference now stops instead of quietly serving a frozen reading. Check every mapped topic’s publish interval before enabling — lower Sampling Hz to widen the tolerance (1 Hz → 50s).

On broker loss, the adapter reconnects with exponential backoff and re-subscribes to its mapped topics on every attempt, until the datasource is disabled.

NaN and Infinity payloads (including numeric overflow, e.g. 1e400) are rejected at the parser and never reach the model. A topic that publishes NaN as a no-measurement sentinel will halt inference by design — the same contract as a sensor that goes quiet.

Rate limiting and buffering

Each datasource has independent rate limits and a bounded buffer. When a source produces faster than the runtime consumes, backpressure is reported to the dashboard so you can spot saturation.

If something goes wrong

Symptom	Likely cause
Enable fails with model_not_paired	Pair a model with the datasource first.
Enable rolls back on connect	Endpoint unreachable, wrong credentials, or firewall — verify with Test Connection.
Row says Enabled but no predictions	By design — press Start to begin streaming.
Pairing rejected	window size × feature count mismatch between model and datasource.
Tag mapping fails with a tag_outside_subscription_* message	The tag’s topic falls outside the datasource’s Base Topic — widen Base Topic or fix the tag path. Tag-mapping errors render as a sentence, not a raw code.
Inference halts after running fine for a while	A mapped MQTT topic aged past the stale window (slow publisher) — see staleness above.

See the Troubleshooting runbook for more.

Next steps

Send results out Write predictions back to a PLC, broker, or file.

Deploy a model Upload, pair, and activate models.