Data Engine Concepts
WEDA's Data Engine is the layer that turns raw device signals into actionable data. Every downstream feature — Alert Policies and Data Stream Bridge — reads from a single unified entity: DataStream.
The Pipeline
Alert Policies and Data Stream Bridge consume ② DataStream — everything downstream reads from this single layer, whether the DataStream came from device auto-sync or from an Analyzer (as an Output DataStream).
① Device
A device (WEDA Node or WEDA SubNode) reports its sensor capability. WEDA Core auto-syncs each reported sensor into a DataStream — there is no separate, queryable "data source" entity to inspect first; the device's sensor list and its DataStreams are the same lookup.
② DataStream
A DataStream is the single queryable, time-series data unit that every WEDA feature builds on. It replaces both the former Data Source and Data Object concepts.
DataStreams are scoped to a device. Listing the DataStreams under a device returns everything together regardless of origin — a stream auto-synced from the device and a stream produced by an Analyzer both show up in the same list.
Every DataStream is one of two flavors:
- System-managed (
managedBy: System) — auto-synced directly from the device's reported sensor capability. Identity and lineage are fixed by the device; only its display fields can be edited. See System-Managed DataStreams. - User-managed (
managedBy: User) — created directly via the API, typically as the output of an Analyzer. It starts unbound until an Analyzer claims it as its output. See Analyzers.
Whichever flavor, a DataStream carries a read-only dataSource lineage recording where its value
comes from — WedaNode/WedaSubNode for a device-originated stream, or Analyzer for a computed
one. The exact request/response schema for each operation is covered in the API Hub reference;
this page only covers the concept.
③ Analyzer
An Analyzer is an optional, cloud-side computation in WEDA Core. It reads one existing DataStream as input, applies a computation, and produces an Output DataStream — this version of Analyzer is one-to-one, not a fan-in.
WEDA v1.1.1 ships one Analyzer type: TransferFunction — a single arithmetic expression,
producing exactly one output.
Multiple Analyzers can coexist on the same device — and multiple Analyzers can even read the same DataStream as input, each producing its own, independent Output DataStream. An Analyzer is always created in the disabled state and must be enabled with a separate action before it runs. It must be disabled again before it can be updated or deleted.
Example: two Analyzers fanning out from one DataStream
A device reports a 4–20 mA analog input. Two separate Analyzers each read that same DataStream and convert it differently — one to Celsius for alerting, one to Fahrenheit for an external MQTT integration:
Each Analyzer is still one-to-one (one input, one output) — it's the DataStream AI_0 that fans
out to two independent Analyzers, not one Analyzer with two outputs. temperature_c itself also
fans out — one Alert Policy watches it for threshold breaches, while a separate Data Stream Bridge
forwards it (alongside temperature_f, via its own Bridge) to the same Omniverse endpoint.
Next Steps
| Guide | What it covers |
|---|---|
| System-Managed DataStreams | Discover what sensors a device exposes |
| DataStreams | Query telemetry values via the DataStreams API |
| Analyzers | Derive additional DataStreams with custom expressions |
Monitoring and alerting on DataStreams is covered in a separate article: Alert Policies. Forwarding DataStreams to your own MQTT broker is covered in Data Stream Bridge.