Why Device shadow (digital twin) in IOT Protocols? - Purpose & Use Cases

The Big Idea

What if you could control your devices perfectly even when they disappear offline?

The Scenario

Imagine you have many smart devices at home, like lights and thermostats, but you can only check or control them when they are online and connected.

What if some devices go offline? You can't see their current state or send commands until they come back online.

The Problem

Manually tracking device states is slow and unreliable.

You might send commands that get lost if the device is offline.

It's hard to keep your app and devices in sync, causing confusion and errors.

The Solution

Device shadow acts like a digital twin that stores the last known state of each device in the cloud.

This lets you read and update device states anytime, even if the device is offline.

When the device reconnects, it syncs with its shadow automatically, keeping everything up to date.

Before vs After

✗ Before

sendCommandToDevice('light1', 'turnOn')  # fails if offline

✓ After

updateDeviceShadow('light1', {"state": {"desired": "on"}})  # works anytime

What It Enables

You can build apps that always know and control device states reliably, no matter if devices are online or offline.

Real Life Example

Smart home apps use device shadows to show if lights are on or off instantly, even if the lights lost internet connection.

Key Takeaways

Manual device control fails when devices go offline.

Device shadow stores device state in the cloud as a digital twin.

This keeps apps and devices synced smoothly and reliably.

Practice

1. What is the main purpose of a device shadow in IoT?

easy

A. To keep a virtual copy of a device's state for synchronization

B. To physically store device hardware components

C. To replace the device's firmware remotely

D. To encrypt device communication data

Solution

1. Step 1: Understand device shadow concept

   A device shadow is a virtual representation of a device's state, not a physical component or firmware.

2. Step 2: Identify its main use

   It stores desired and reported states to keep device and cloud synchronized, especially when devices are offline.

3. Final Answer:

   To keep a virtual copy of a device's state for synchronization -> Option A

4. Quick Check:

   Device shadow = virtual state copy [OK]

Hint: Device shadow = virtual device state copy [OK]

Common Mistakes:

• Confusing device shadow with physical device hardware
• Thinking device shadow replaces device firmware
• Assuming device shadow encrypts data

2. Which JSON field in a device shadow document holds the desired state of the device?

easy

A. "reported"

B. "desired"

C. "metadata"

D. "version"

Solution

1. Step 1: Recall device shadow JSON structure

   The device shadow JSON has fields like "desired" and "reported" to represent states.

2. Step 2: Identify desired state field

   The "desired" field contains the state the cloud wants the device to have.

3. Final Answer:

   "desired" -> Option B

4. Quick Check:

   Desired state = "desired" field [OK]

Hint: "desired" field stores target device state [OK]

Common Mistakes:

• Mixing up "reported" and "desired" fields
• Confusing "metadata" with state data
• Thinking "version" holds state info

3. Given this device shadow snippet:

{"state": {"desired": {"power": "on"}, "reported": {"power": "off"}}}

What will the device shadow report after the device updates its state to match the desired power?

medium

A. {"state": {"desired": {"power": "off"}, "reported": {"power": "off"}}}

B. {"state": {"desired": {"power": "on"}, "reported": {"power": "off"}}}

C. {"state": {"desired": {"power": "on"}, "reported": {"power": "on"}}}

D. {"state": {"desired": {}, "reported": {"power": "on"}}}

Solution

1. Step 1: Understand initial shadow states

   The desired state requests power "on"; the reported state shows power "off" initially.

2. Step 2: Update reported state after device changes

   When the device matches the desired state, the reported state updates to "power": "on".

3. Final Answer:

   {"state": {"desired": {"power": "on"}, "reported": {"power": "on"}}} -> Option C

4. Quick Check:

   Reported state matches desired after update [OK]

Hint: Reported state updates to match desired after device sync [OK]

Common Mistakes:

• Assuming desired state changes after device update
• Leaving reported state unchanged
• Removing desired state incorrectly

4. You receive this device shadow update error:

{"error": "Invalid JSON format"}

Which of these shadow update requests is causing the error?

medium

A. {"state": {"desired": {"temperature": 22}}}

B. {"state": {"desired": {"temperature": 22}, "reported": {"temperature": 22}}}

C. {"version": 1, "state": {"desired": {"temperature": 22}, "reported": {"temperature": 22}}}

D. {"state": {"desired": {"temperature": 22}, "reported": {"temperature": 22}"}}

Solution

1. Step 1: Check JSON syntax of each option

   {"state": {"desired": {"temperature": 22}, "reported": {"temperature": 22}"}} has an extra double quote after the reported object closing brace, breaking JSON format.

2. Step 2: Identify invalid JSON causing error

   Invalid JSON causes the "Invalid JSON format" error in device shadow update.

3. Final Answer:

   {"state": {"desired": {"temperature": 22}, "reported": {"temperature": 22}"}} -> Option D

4. Quick Check:

   Invalid JSON syntax = error [OK]

Hint: Look for extra or missing quotes/braces in JSON [OK]

Common Mistakes:

• Overlooking extra quotes or commas
• Confusing valid JSON with similar invalid syntax
• Assuming error is from device, not JSON format

5. You want to ensure a device shadow only updates the reported state if the device is online. Which approach best achieves this?

hard

A. Use a device shadow update callback to confirm device state before updating reported state

B. Delete the device shadow when device is offline

C. Update reported state immediately on cloud request without device confirmation

D. Set desired state to null when device is offline

Solution

1. Step 1: Understand device shadow update flow

   Reported state should reflect actual device state, so cloud must confirm device is online and updated.

2. Step 2: Choose method to confirm device state

   Using a callback or acknowledgment from the device before updating reported state ensures accuracy.

3. Final Answer:

   Use a device shadow update callback to confirm device state before updating reported state -> Option A

4. Quick Check:

   Confirm device state before reported update [OK]

Hint: Confirm device state via callback before updating reported [OK]

Common Mistakes:

• Updating reported state without device confirmation
• Deleting shadow causing loss of state info
• Setting desired state to null instead of managing reported