Manage Devices

Use this guide after a device has been registered or integrated. First confirm its identity, organization and type, then choose the management operation you need.

The device list contains WEDA Nodes, SubNodes and Custom Devices. The read, rename and lifecycle procedures below distinguish the device types; appearing in the same list does not give them identical management operations.

For API examples, use your user access token and the intended Org's permissions. Replace https://weda.example.com/central/weda with your WEDA base URL and route placeholders with the actual IDs.

Find and View Devices

In WEDA Console:

1. Select the intended organization in the top bar and open Devices.
2. Locate the device by its name and Device ID. Confirm the identity before making changes.
3. Select the device to inspect its details.

Check the result: You have identified the intended device in the correct Org. If it is missing, check the Org selection and your membership before assuming that the device was deleted.

Match the selected Org and Device ID, then select the device name to open its details.

Using the API:

GET https://weda.example.com/central/weda/api/v1/orgs/{orgId}/devices?skipCount=0&maxResultCount=20&sorting=deviceName%20asc
Authorization: Bearer {userAccessToken}

Use List Devices in an Organization for the mixed list. Inspect these fields before selecting a management operation:

Field	What to confirm
deviceId	The identifier of the device you intend to manage.
deviceName	Its readable name. Use the ID when an API requests an identifier.
type	WedaNode, SubNode or CustomDevice.
orgId	The owning Org. A SubNode inherits its WEDA Node's Org.
parentDeviceId	For a SubNode, the ID of its WEDA Node.
hwModel	The WEDA Node's model; null for SubNode and Custom Device records.

For a known ID, add deviceIds={deviceId} to the Org-list query. Repeat the key to request several IDs. IDs outside the Org are omitted from the results.

Keep maxResultCount between 1 and 100. Pagination and totalCount cover the filtered set across the three types, so a page is not necessarily a page of WEDA Nodes alone. Sorting supports deviceId, deviceName, hwModel, orgId, status, createdAt and type; it does not support connectivity. Use createdAt rather than the older CreationTime name.

For the broader application device list, List Devices uses GET /api/v1/devices. Its page size is 1-1000, default 10. Unlike the Org-scoped endpoint above, its sorting uses names such as Name, DeviceId, Type, Status and CreationTime, with CreationTime desc as the default. Do not substitute createdAt into that endpoint's sorting expression. Use the Org-scoped list when you need the type relationships and heartbeat fields described here.

Check the result: The returned Device ID, type and Org match your target. Follow parentDeviceId when you need to relate a SubNode to its WEDA Node.

View Device Details and Connectivity

In WEDA Console: Open the WEDA Node's details and choose the view for your check:

• Overview: Review reported resource values, such as memory, disk and CPU metrics.
• Information: Check the Device ID, Model, lifecycle status and available hardware information. Inspect connectivity separately from lifecycle status.

The Overview tab summarizes resource values reported for this WEDA Node.

The Information tab provides the device identity, status and hardware sections for the selected WEDA Node.

Using the API:

For an Activated or Deactivated WEDA Node, or a Custom Device, use Get a Device in an Organization. A WEDA Node that is still Registered returns 404 from this endpoint; query the Org list with deviceIds={deviceId} instead.

GET https://weda.example.com/central/weda/api/v1/orgs/{orgId}/devices/{deviceId}
Authorization: Bearer {userAccessToken}

Use the Org-list result for SubNode details and relationships. Obtain heartbeat connectivity from that list as well; the single-device endpoint is not a replacement for the list's connectivity fields.

Lifecycle status -> Administrative registration / activation state
Connectivity     -> Heartbeat evidence at the time of the API query

Read Lifecycle Status

Status	How to interpret it
Registered	The record exists. A WEDA Node still needs its activation procedure; a Custom Device needs its input configuration and activation.
Activated	The device is activated. Check current connectivity or received data separately.
Deactivated	The device has been administratively deactivated. Its record remains available for management.

For a SubNode, the Org-list response reports its WEDA Node's lifecycle status. This is not an independent SubNode activation state or an indication that its application has started or stopped.

Read Heartbeat Connectivity

For a WEDA Node or SubNode, inspect connectivity.state and connectivity.updatedAt in the Org-list result:

State	What it means for your next check
Connected	A recent accepted heartbeat supports a connected result. Check telemetry separately for the data you expect.
Abnormal	Heartbeats have become late. Check the device service, network and reporting behavior, then query again.
Disconnected	There is no qualifying heartbeat or the silence window has expired. Check lifecycle status before diagnosing a network outage.
Unknown	The API could not obtain heartbeat status. Treat it as unavailable information and retry; do not display it as a confirmed device disconnection.

updatedAt is the server receipt time of the latest accepted heartbeat after activation, not the time when the device disconnected. With a successful heartbeat lookup, Registered or Deactivated devices read as Disconnected with a null timestamp. An Activated device without a qualifying post-activation heartbeat also has no timestamp to confirm a connection.

WEDA Nodes and SubNodes are judged on their own heartbeats. A connected parent Node does not prove that its SubNode is connected. SubNode monitoring eligibility follows the parent's activation status and time.

For a Custom Device, connectivity is null because heartbeat monitoring does not apply. Verify its activation, input response and received DataStream values instead.

Note: Heartbeat availability and Console indicators

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. The device list can still return 200 OK with Unknown connectivity and a null timestamp when heartbeat status is unavailable. The Activator's local Connection indicator is a separate check on the device. Per-device thresholds, disconnection reasons and connectivity alerts are not part of v1.2.0.

Check the result: You can distinguish an administrative state, a heartbeat result and evidence that expected data is arriving. A missing heartbeat timestamp by itself does not identify the cause.

Update Device Information

The organization-scoped update changes the name of a WEDA Node or Custom Device. Confirm its current Org and ID before submitting the new name.

In WEDA Console, for the WEDA Node shown here:

1. Open the device's details and select Edit.
2. Change Device name. Device ID and Model are read-only in this form.

Edit the device name while retaining the existing device identity. This screenshot shows the form before a change is submitted.

3. Select Submit, then select Save in Save Changes.

Confirm the name change with Save.

4. Read the device again and confirm the new name and unchanged Device ID.

The name is now ARK-2252-Test; the Device ID remains cc827fdd1713.

Using the API:

PATCH https://weda.example.com/central/weda/api/v1/orgs/{orgId}/devices/{deviceId}
Authorization: Bearer {userAccessToken}
Content-Type: application/json

{
  "deviceName": "ARK-2252-Test"
}

Check the result: The API returns 200 OK. Read the device again and confirm the new name while checking that its Device ID and Org remain the same.

Note: Name rules and immutable fields

• Name format: 1-128 English letters, digits, hyphens or underscores. Spaces, non-English characters and periods are not accepted.
• Name uniqueness: Names are unique within the Org, ignoring letter case. WEDA Nodes and Custom Devices share that name scope.
• Immutable fields: Do not include deviceId, hwModel or orgId in the PATCH body, even with their current values. Supplying any of them returns 400. PATCH cannot move the device to another Org.

See Rename a Device in an Organization. The existing flat Rename a Device route, PATCH /api/v1/devices/{deviceId}, has the same name-format and immutable-field restrictions.

Note: SubNode names

The rename APIs above do not support SubNodes. A registration request that reuses an existing SubNode Device ID with a different name is rejected with code 409; changing the name in that request is not a rename operation. Contact your WEDA support team for the applicable procedure before changing an existing SubNode's identity.

Deactivate or Reactivate a Device

Use deactivation when the device should remain in the inventory but should no longer have active Cloud input or connectivity. Confirm the type and expected effect first:

Device type	Management scope
WEDA Node	Deactivation stops all running container Stacks on that WEDA Node and disconnects it from WEDA Cloud.
SubNode	Its status in the Org-list response follows its WEDA Node. Review the parent Node's Stack, connection and reporting impact before deactivating it.
Custom Device	Deactivation pauses its input. HTTP ingestion requires Activated status and is rejected while inactive.

In WEDA Console, for a WEDA Node:

1. Find the intended device in Devices, select Deactivate and review the confirmation.

Review the target device name and the effect on running Stacks before selecting Deactivate.

2. Confirm the action, then refresh the list and check Device status: Deactivated.

Confirm Deactivated in the Device status column before choosing the next operation.

3. To reconnect the device, select Activate, then confirm Activate Device.

Select Activate to begin reactivation of the intended WEDA Node.

4. Refresh the list. The device first returns to Registered; allow time for WEDA Node to activate again, then check for Activated.

Registered is the intermediate lifecycle status during this WEDA Node reactivation.

Note: Reactivation has an intermediate status

After reactivating a WEDA Node, wait for Registered to become Activated before continuing with operations that require activation. Check the device's connection and received data separately. The Console's Connectivity label and the Device status column describe different checks.

Using the API:

1. Read the WEDA Node or Custom Device in the intended Org and confirm its identity and current status.

2. Send the appropriate action using the lower-case route value:

   POST https://weda.example.com/central/weda/api/v1/devices/{deviceId}:deactivate
   Authorization: Bearer {userAccessToken}

   To reactivate:

   POST https://weda.example.com/central/weda/api/v1/devices/{deviceId}:activate
   Authorization: Bearer {userAccessToken}

3. After 200 OK, query the Org list with deviceIds={deviceId} again (the single-device endpoint returns 404 while a WEDA Node is Registered). For deactivation, confirm Deactivated. For WEDA Node reactivation, allow the Registered → Activated transition to finish; for a Custom Device, confirm the intended activation status.

4. After reactivation, verify the WEDA Node's connection and fresh heartbeat, or send and read back a Custom Device test value.

For a Custom Device that has not yet been accessed through the organization-scoped API, read it through GET /api/v1/orgs/{orgId}/devices/{deviceId} before using these flat action routes. This confirms its Org context and helps avoid a missing-record response.

Check the result: The administrative status changed, and the subsequent connection or input check supports the intended operating state. An Activated response alone does not prove that the device has reconnected or resumed sending the expected data.

See Deactivate or Reactivate a Device. Check any pending deployment or command results separately after reactivation; this operation is not a workload execution result.

Delete a Device

Confirm that you intend to remove the device record rather than pause it. Use the Device ID for the deletion target and review the requirements for that type:

Device type	Before deletion
WEDA Node	It must be Deactivated, and the caller must be an Admin of its Org. A Registered device must also go through deactivation first.
Custom Device	The current API permits deletion from any lifecycle status. Stop the external sender and confirm the device in its Org first.
SubNode	The DELETE request below does not apply. Confirm the removal procedure with your WEDA support team.

For a SubNode, resetting SDK registration information clears only the SDK's saved registration. It does not unregister the SubNode from its WEDA Node or delete its Cloud record. Absence from the Org device list alone does not establish that its Cloud record or historical data has been deleted.

Note: DataStreams after device deletion

The data-cleanup scope is currently limited to associated DataStreams, which are cleaned up asynchronously. After re-creating a device, discover its current DataStreams again instead of assuming that previous DataStream IDs remain valid. This cleanup is separate from resetting telemetry configuration.

Caution: Review the device and its data before deletion

Treat device deletion as permanent removal of the device record. Confirm the Device ID, Org, type and any configuration or data you need to retain before proceeding. Do not assume that re-registering the same Device ID restores earlier configuration or data.

In WEDA Console, for a WEDA Node:

1. Confirm that Device status is Deactivated and that you are an Admin of its Org. The Delete action is unavailable while the WEDA Node is Activated or Registered.
2. Select Delete for the intended device.
3. In Delete Device, re-enter its current device name, such as ARK-2252-Test, then select Delete.

Re-enter the current device name to enable Delete. Review the device and data-handling notes above before confirming.

4. Refresh the device list and confirm that the same Device ID is no longer listed.

Using the API:

1. Read the target device in its Org and verify its identity and type.

2. For a WEDA Node, deactivate it and confirm Deactivated before proceeding.

3. Send the delete request:

   DELETE https://weda.example.com/central/weda/api/v1/devices/{deviceId}
   Authorization: Bearer {userAccessToken}

4. After 204 No Content, query the Org device list again and confirm the record is no longer returned.

Check the result: The device is absent from the inventory you query. Cleanup of its associated DataStreams runs asynchronously.

See Delete a Device. For WEDA Node deletion, 403 can mean the device is not Deactivated or the caller lacks the required Org Admin role. 404 can mean that the record does not exist or is outside the caller's accessible Orgs.

For a Custom Device, its MQTT and NATS device credentials are revoked. Review Client Credentials and the integrations that use them separately. Do not assume this device action revokes every issued M2M token.