Device shadow (digital twin) in IOT Protocols - Step-by-Step Execution

Process Flow - Device shadow (digital twin)

Device Shadow Service

↓

Receive Desired State Update

↓

Update Shadow Document

↓

Notify Device of Desired State

↓

Device Applies Changes

↓

Device Reports Reported State

↓

Update Shadow Document with Reported State

↓

Clients Read Updated Shadow

The device shadow service keeps a virtual copy of device state. It updates when clients or devices change state, syncing desired and reported states.

Execution Sample

IOT Protocols

1. Client updates desired state: {"light": "on"}
2. Shadow service updates shadow document
3. Device receives desired state
4. Device turns light on
5. Device reports reported state: {"light": "on"}
6. Shadow service updates shadow document

Shows how a client changes desired state, device applies it, and reports back, updating the shadow.

Process Table

Step	Action	Shadow Document Desired State	Shadow Document Reported State	Device State	Output/Result
1	Client sets desired state to {"light": "on"}	{"light": "on"}	{}	off	Shadow document desired state updated
2	Shadow service notifies device of desired state	{"light": "on"}	{}	off	Device receives desired state {"light": "on"}
3	Device applies desired state	{"light": "on"}	{}	on	Device turns light on
4	Device reports reported state {"light": "on"}	{"light": "on"}	{"light": "on"}	on	Shadow document reported state updated
5	Clients read updated shadow	{"light": "on"}	{"light": "on"}	on	Clients see device is on
6	No further changes	{"light": "on"}	{"light": "on"}	on	Execution ends

💡 No more updates; desired and reported states are synchronized.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
Desired State	{}	{"light": "on"}	{"light": "on"}	{"light": "on"}	{"light": "on"}	{"light": "on"}
Reported State	{}	{}	{}	{}	{"light": "on"}	{"light": "on"}
Device State	off	off	off	on	on	on

Key Moments - 2 Insights

Why does the shadow document have separate desired and reported states?

Because the desired state shows what clients want the device to do, while the reported state shows what the device has actually done. This separation helps track if the device is in sync with client requests, as seen in steps 1 and 4 of the execution table.

What happens if the device cannot apply the desired state?

The device will not update the reported state to match the desired state, so the shadow document shows a difference between desired and reported states. This difference signals clients that the device is not yet in the desired state, as would be visible if step 4 did not update reported state.

Visual Quiz - 3 Questions

Look at the execution table, what is the device state after step 3?

A unknown

B on

C off

D {}

💡 Hint

Check the 'Device State' column at step 3 in the execution table.

At which step does the shadow document's reported state get updated?

A Step 4

B Step 1

C Step 3

D Step 5

💡 Hint

Look for when the 'Reported State' column changes from empty to {"light": "on"}.

If the device never reports its state, what will the shadow document show?

A Device state will automatically update

B Desired and reported states will be the same

C Reported state will remain empty while desired state updates

D Shadow document will delete desired state

💡 Hint

Refer to variable_tracker rows for 'Reported State' and 'Desired State' changes.

Concept Snapshot

Device Shadow (Digital Twin):
- A virtual copy of device state stored in the cloud.
- Has separate 'desired' and 'reported' states.
- Clients update desired state to request changes.
- Device reads desired state, applies changes, reports back.
- Shadow syncs states to reflect real device condition.

Full Transcript

Device shadow is a cloud service that keeps a virtual copy of a device's state. It stores two parts: desired state, which clients want the device to have, and reported state, which shows what the device actually has. When a client updates the desired state, the shadow service notifies the device. The device then applies the changes and reports its new state back. The shadow updates the reported state accordingly. This process helps keep clients and devices in sync, even if the device is offline temporarily. The execution table shows each step: client sets desired state, device receives it, applies it, reports back, and clients read the updated shadow. Variables track how desired state, reported state, and device state change over time. Key points include understanding why desired and reported states are separate and what happens if the device cannot apply changes. The visual quiz tests understanding of device state changes and shadow updates.