System-Managed DataStreams
Device → DataStream (managedBy: System) → Analyzer (optional) → DataStream (managedBy: User) → Alert Policy / Bridge
Overview
When a device connects, WEDA Node reports its sensor capability and WEDA Core automatically syncs
each reported sensor into a DataStream with managedBy: System. There is no separate
"Data Source" entity or endpoint to query first — the device's sensor list and its DataStreams
are the same lookup: GET .../data-streams.
A System-managed DataStream is:
- Read-only for identity/lineage —
dataStreamName,dataType, anddataSourcecome from the device and cannot be changed via the API - Editable for display —
displayName,description,unitDisplay, andrecordToDataLakecan be updated (PATCH) - Traceable to its origin —
dataSource.typeisWedaNodeorWedaSubNode;dataSource.sourceEntityIdis the underlying sensor resource ID reported by the device
Discover a Device's DataStreams
| Operation | API | Description |
|---|---|---|
| List DataStreams | GET /api/v1/orgs/{orgId}/devices/{deviceId}/data-streams | All DataStreams for a device, including their dataSource lineage |
| Get DataStream | GET /api/v1/orgs/{orgId}/devices/{deviceId}/data-streams/{dataStreamId} | One DataStream by ID |
Filter the list by managedBy=System to see only device-originated streams, or managedBy=User
to see streams created directly (e.g. Analyzer outputs).
System Agent Metric Types
For a device running WEDA Node, the built-in System Agent reports hardware and system metrics.
WEDA Core then auto-syncs the corresponding DataStreams. The following names are examples; call
GET /api/v1/orgs/{orgId}/devices/{deviceId}/data-streams to discover the DataStreams exposed by a
specific device and configuration.
System Resources (all platforms)
| MetricType | Example DataStreams | Unit |
|---|---|---|
cpu | cpu_usage, cpu_load1, cpu_load5, cpu_load15, cpu_context_switches | %, count |
memory | memory_total, memory_available, memory_used, memory_usage_percent | bytes, % |
disk | disk_usage_percent, disk_total, disk_available, disk_reads_completed | %, bytes, count |
network | network_bytes_sent, network_bytes_received, network_errors_in | bytes, count |
system | system_time, system_boot_time, system_procs_running | Unix ms, count |
gpu | gpu_utilization | % |
disk requires a MountPoint parameter (e.g. / or C:\). network requires an Interface parameter (e.g. eth0).
Hardware Sensors (Advantech industrial PCs)
Requires the Advantech SUSI driver. Available on Advantech industrial computers by default.
| MetricType | What it reports |
|---|---|
hwinfo | Motherboard name, BIOS revision, driver version, EC revision |
temperature | All temperature sensors as a dictionary (key = sensor name e.g. CPU, value = °C) |
voltage | All voltage rails as a dictionary (key = rail name e.g. +3.3V, value = V) |
fanspeed | All fan speeds as a dictionary (key = fan name e.g. CPU_Fan, value = RPM) |
Hardware Functionality (Advantech industrial PCs)
| MetricType | What it reports |
|---|---|
gpio | GPIO pin states |
watchdog | Timer IDs, capability, and current configuration |
thermalprotection | Protection zones, source sensor, event type, and shutdown temperature |
If the SUSI driver is not installed, hardware-specific metrics are silently skipped — system resource metrics continue collecting normally.
SubNode devices expose different DataStreams based on their device definition. The metric types
above apply only to WEDA Node's built-in System Agent.
Call GET /api/v1/orgs/{orgId}/devices/{deviceId}/data-streams to discover the actual DataStreams a specific device exposes.
Constraints
- System-managed DataStreams cannot be deleted, and only
displayName/description/unitDisplay/recordToDataLakecan be updated — attempting to changedataStreamNameordataTypereturns409 - A System-managed DataStream becomes available only after WEDA Node reports and syncs the device's capability with WEDA Core
- A System-managed DataStream's identity is tied to
dataSource.sourceEntityId— the sensor's resource ID, assigned by the system and not settable by clients. If the same resource ID is reported again after the device was deleted and re-registered in the same Org, it resolves to the existing DataStream instead of creating a new one, so the stream's history continues. DataStreams are Org-scoped, so this does not carry across Orgs - The sensors exposed by a SubNode depend on its device definition
Related
- How DataStreams fit into the overall pipeline: Data Engine Concepts
- Derive additional values: Analyzers
- Query DataStream values: DataStreams