Understanding Device Shadows
Overview
In edge-to-cloud deployments, physical edge devices face real-world operational challenges: intermittent network connectivity, power failures, and out-of-sync software configurations. If a cloud server needs to update a model on a device that is currently offline, a naive system might stall or fail.
WEDA addresses these challenges through the Device Shadow concept — a foundational digital twin framework. This article explains what a Device Shadow is, how it works in the WEDA ecosystem, and why it matters for scaling Edge AI applications.
What Is a Device Shadow?
A Device Shadow (sometimes called a digital twin) is a persistent, virtual representation of a physical edge device stored in WEDA Core — the cloud (or on-premise) management center.
Even if the physical device (WEDA Node) goes offline, WEDA Core retains this virtual record. Applications and user interfaces can query or write configurations to the shadow at any time. When the physical device reconnects, WEDA automatically synchronizes any pending state changes.
The Core States: Desired vs. Reported
WEDA uses open, RESTful APIs with JSON payloads to maintain state and configuration. Every Device Shadow document is split into two primary components:
Desired State (desired) — the configuration target defined by WEDA Core (manually via the
WEDA Desk UI or programmatically via APIs). It represents what you want the device to be doing or
running.
Reported State (reported) — the actual state of the physical WEDA Node at the edge, actively
pushed back to WEDA Core. It represents what the device is currently doing.
If the Node detects a difference between the desired state and the reported state, this mismatch triggers an automatic synchronization event.
How Synchronization Works (The Reconciliation Loop)
WEDA resolves differences between desired and reported states using a continuous reconciliation loop:
- State Update — You deploy a retrained AI model or change a configuration parameter on WEDA Core. WEDA Core writes this target directly to the shadow's desired state.
- Delta Detection — The WEDA Node Data Agent on the edge device compares its local configuration with the shadow's desired state via the Digital Twin Framework Protocol.
- Execution — The local WEDA Node pulls down the necessary containers or parameters (e.g., triggering a container stack deployment or applying an OTA model update) to match the desired configuration.
- Report Back — Once the update is successfully applied locally, WEDA Node updates its local state and sends a status report back to the cloud. WEDA Core updates the shadow's reported state to match the desired state.
Key Benefits
Offline Resilience — If an edge device loses its internet connection, it continues to run locally with its last known stable configuration. Cloud applications can still query WEDA Core for the device's last reported telemetry or schedule updates. Scheduled updates are automatically queued and pushed the moment connectivity is restored.
Fleet Scalability and Mass Configuration — Instead of establishing direct SSH/VNC terminal connections to thousands of edge devices to apply configurations, you update their shadow. WEDA handles the orchestration, distribution, and validation asynchronously.
Related
- Explore the full API surface: API Hub
- Register a new edge device: Register Your Device