Understanding Device Shadows
When you change an edge device's configuration, accepting the request and applying the change are separate outcomes. A Device Shadow helps you distinguish the configuration you requested from the state the device last reported.
What Is a Device Shadow?
A Device Shadow is a persistent, virtual representation of an edge device's state in WEDA Core, the cloud or on-premises management center. WEDA Core retains this representation when the physical device is disconnected.
Your application works with WEDA Core through the relevant feature's APIs, or you use the supported controls in WEDA Console. WEDA Node applies supported configuration on the device and reports the outcome through the Digital Twin Protocol.
Reported state reflects the information the device has reported. Check the result and its timestamp before treating a requested change as the device's current configuration.
Desired and Reported State
The two views answer different questions:
| View | Meaning | What it tells you |
|---|---|---|
| Desired state | The configuration requested through WEDA Core. | What you want the device to use. |
| Reported state | The state last reported by the device. | What the device last confirmed. |
For example, a monitoring application needs a sensor reading every two seconds. For a sensor that supports this setting, you request a reporting interval of 2000 ms while its last reported interval is 1000 ms. The desired value now expresses the new target; the reported value still describes the earlier configuration until a new report arrives.
A difference between the views can mean the change is still being applied, the device is disconnected, or application failed. Use the feature's result information to distinguish these cases.
Each API defines how it exposes these views. For telemetry configuration, Get Device Telemetry Configurations returns the desired settings when they exist. Before a configuration has been submitted, or after a reset, it returns the device's reported settings instead. Reading back the requested interval alone therefore does not establish that the device has applied it.
How State Synchronization Works
WEDA Core maintains the requested configuration, and WEDA Node handles its application on the device. The device reports its state and application result back to WEDA Core, where your application can check the outcome. A failure needs investigation even when the original HTTP request succeeded.
When a device reconnects and reports its local configuration target, WEDA Core compares it with the retained target. If they differ, WEDA Core sends the retained target again for the device to apply.
In the telemetry example, 202 Accepted means the desired configuration was sent. To check what happened next, inspect the returned configuration's status, appliedAt and errorMessage, then verify recent sensor values and timestamps. updatedAt records when the update request was saved; it does not establish when the device applied it.
Check the result: A fresh, successful device-reported outcome confirms application of the requested change, and the observed device behavior matches your intent. The Telemetry Configuration guide provides the discovery, update and verification steps for this example.
Offline Behavior and Limitations
When a device is disconnected, WEDA Core can retain its last reported state, but that state cannot confirm what the physical device is doing now. Keep connectivity and the time of the last report separate from the configuration values you read.
Apply these limits when interpreting the cloud view:
- Configuration application requires device communication. After reconnection, inspect the relevant feature's result and the device's behavior before considering a change complete.
- Offline handling depends on the operation. A desired configuration is different from a one-time command. In WEDA v1.2.0, the Remote Commands guide requires a reachable device: an offline request is rejected with 409, rather than queued for reconnection.
- Device support still matters. The target device and its software must support the requested setting. A cloud-side configuration value does not add a capability to the device.
A saved desired state or an accepted API request is not a successful device application result. Check the operation's documented result and an observable device outcome.