Overview
Start by identifying how your device connects to WEDA Cloud. The connection path determines how you register it, which management operations apply, and how you check its status.
Device Types and Relationships
WEDA Node connects an edge device to WEDA Cloud. SubNode integrates equipment or applications through that Node. Custom Device provides another integration path for external data without installing WEDA Node.
| Device type | Its role | Registration path and guide |
|---|---|---|
| WEDA Node | The software running on your edge device that connects it to WEDA Cloud for management, data reporting and supported application operations. | Register in an Org through Console or REST API, then activate and connect on the edge device with the Activator. Continue with Register WEDA Node in this chapter. |
| SubNode | An edge integration component that represents connected equipment, sensors or an application through a WEDA Node. It has its own device identity in the device list. | Configure and start the SDK application, register with the local WEDA Node, then synchronize to Cloud through that Node. Continue with WEDA SubNode SDK in Developer Resources. |
| Custom Device | A Cloud-side integration for an external device or application to submit data without WEDA Node. | Create the Custom Device, prepare its DataStreams, configure the source, parser and input credentials, then activate and verify data input. Continue with Custom Device Integration in this chapter. |
In the Org device list, the API identifies these records with type: WedaNode, SubNode or CustomDevice. For a SubNode, parentDeviceId identifies its WEDA Node.
Appearing in the same device list does not mean that each type supports the same activation, container deployment, remote commands or telemetry configuration. Follow the task and prerequisites for the device type you are integrating. SubNode development belongs to the Edge integration workflow; Custom Device data input has its own configuration and authentication.
Device Identity and Organization
Each device belongs to one Org at a time. That association determines the organization scope in which you manage the device and its data. Confirm the selected Org and your membership before registering or managing a device.
| Field | How to use it |
|---|---|
deviceId | Identifies the device in API requests. For a WEDA Node registration, copy the Device ID from WEDA Node Activator. Keep the returned or reported identity for SubNode and Custom Device records. |
deviceName | A readable name to help your team identify the device. Use deviceId when an API requests the device identifier. |
hwModel | The hardware model used for WEDA Node registration. Copy it from the Activator. SubNode and Custom Device records do not have their own hardware model. |
orgId | Identifies the Org that owns the device. Access remains subject to the caller's permissions in that Org. |
parentDeviceId | For a SubNode, identifies the WEDA Node it is bound to. This is a device relationship, separate from the parent-child Org hierarchy. |
- Device name (
deviceName): 1-128 characters. Use only English letters, digits, underscores (_) and hyphens (-). Spaces, non-English characters and periods are not accepted. - Name uniqueness: Names must be unique within the same Org, ignoring letter case. WEDA Nodes and Custom Devices share this name scope:
Device_Aanddevice_acount as the same name. - WEDA Node Device ID (
deviceId): Exactly 12 lowercase English letters or digits. Copy the value from WEDA Node Activator. - WEDA Node model (
hwModel): 1-64 characters. Use only uppercase English letters, digits and hyphens (-). Copy the model from the Activator.
The Device ID and model rules above apply to WEDA Node registration. SubNode and Custom Device identities follow their own integration paths.
A SubNode belongs to its WEDA Node's Org. In the Org-list response, its lifecycle status is taken from that Node. This does not mean that the SubNode application has started or stopped. Use parentDeviceId to identify the owning Node.
For WEDA Node registration, use the Device ID and Model supplied by the Activator. Custom Device creation follows a different path: the create request omits deviceId and requires deviceName. Detailed field validation belongs in the registration and Custom Device procedures.
Device Lifecycle and Status
Lifecycle status -> Is the device registered, activated or deactivated?
Connectivity -> What does the latest accepted heartbeat indicate?
Check both when investigating a WEDA Node or SubNode. Activated does not by itself confirm a current connection.
Lifecycle Status
| Status | What it tells you |
|---|---|
Registered | The WEDA Node's Cloud record has been created; complete activation and connection on the edge device. |
Activated | The device is activated. Check connectivity separately to assess its current connection. |
Deactivated | The device has been administratively deactivated. This remains a device record; deactivation and deletion are separate operations. |
The activation procedure depends on the device type. WEDA Node uses the Activator on the physical device; Custom Device uses its integration configuration and lifecycle operations. A SubNode registers with the local WEDA Node through its SDK application, without a separate Activator step.
Registration and later management are different operations. After synchronization to Cloud, supported sensor-discovery and telemetry-configuration APIs accept the SubNode's Device ID. Access is checked against the owning WEDA Node's Org, and configuration changes require that Node to have completed onboarding. This does not make the Node / Custom Device rename or deletion APIs applicable to SubNodes.
Connectivity
The Org device-list API returns connectivity for WEDA Nodes and SubNodes, based on heartbeat information at query time:
connectivity.state:Connected,AbnormalorDisconnected, based on how long ago the latest heartbeat was received. A device readsConnectedwhile that heartbeat is no more than 180 seconds old,Abnormalafter 180 seconds of silence, andDisconnectedafter a further 10 minutes (about 13 minutes in total). These thresholds are fixed and cannot be changed per organization or device. The API can also returnUnknownwhen the status is temporarily unavailable; show it as unknown rather than offline.connectivity.updatedAt: The server receipt time of the latest accepted heartbeat after activation. It isnullwhen no qualifying heartbeat is available.- Separate SubNode checks: A SubNode is judged on its own heartbeat, using its WEDA Node's activation status and time. A connected WEDA Node alone does not prove that its SubNode is connected.
A Registered or Deactivated WEDA Node or SubNode reads as Disconnected, with updatedAt: null. An activated device that has not reported a qualifying heartbeat also has no heartbeat timestamp to confirm a connection.
For a Custom Device, connectivity is null because heartbeat monitoring does not apply. Verify its input by checking the integration and the data received in the intended DataStreams; do not interpret this null value as an offline WEDA Node.
In WEDA Console, the Connectivity label shows Connected when the device has reported DataStream values within the latest-value retention window (60 minutes by default). It is not the heartbeat result, so it can read Connected for a Deactivated device that reported data recently. Use the API's connectivity field for the heartbeat-based state, including Abnormal and Unknown. Per-device thresholds, disconnection reasons and connectivity alerts are not part of v1.2.0. Keep connectivity separate from lifecycle status and data-input verification.
Use List Devices in an Organization to inspect type, parentDeviceId, status and connectivity together.
Device Management Tasks
Choose the task that matches what you want to do:
| Your task | Page | What you will cover |
|---|---|---|
| Connect an edge device running WEDA Node | Register WEDA Node | Prepare its identity, register it in an Org, activate WEDA Node and verify connectivity. |
| Connect equipment or an application through WEDA Node | Developer Resources / WEDA SubNode SDK | Configure the SDK application and its local Node connection, register through the SDK, and verify the synchronized Cloud device. |
| Integrate external data without WEDA Node | Custom Device Integration | Create the device, prepare DataStreams, configure the source and parser, authenticate input and verify received data. |
| Inspect or maintain an existing device | Manage Devices | Find devices, inspect details and connectivity, update information, deactivate, reactivate or delete as supported. |
| Configure data reporting and local recording | Telemetry Configuration | Discover supported sensors, change reporting or recording settings, and verify the applied configuration. |
| Request an action on a supported device | Remote Commands | Reboot, shut down, request manual Data Resync, invoke supported custom commands and inspect results. |
| Add your own asset metadata | Custom Information | Read and maintain key-value information such as a location or asset tag. |
For your first WEDA Node connection, the Getting Started onboarding guide provides the initial walkthrough. The task pages in this chapter expand the rules, supported operations and troubleshooting for ongoing device management.