Device shadow (digital twin) in IOT Protocols - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is a device shadow (digital twin) in IoT?

A device shadow is a virtual copy of a physical device that stores its last reported state and desired future state. It helps applications interact with devices even when they are offline.

beginner

How does a device shadow help when a device is offline?

It keeps the device's last known state and desired state so applications can read or update the device's status. When the device reconnects, it syncs with the shadow to update its actual state.

intermediate

What are the main parts of a device shadow document?

The main parts are:
1. Desired state - what the device should be.
2. Reported state - what the device actually is.
3. Metadata - info about timestamps.
4. Version - tracks updates.

beginner

Which protocol commonly uses device shadows for IoT devices?

MQTT (Message Queuing Telemetry Transport) is commonly used with device shadows to send and receive state updates efficiently.

beginner

Why is a device shadow also called a digital twin?

Because it acts like a digital copy of a physical device, mirroring its state and behavior in software to enable remote monitoring and control.

What does the 'desired state' in a device shadow represent?

A The state the device should have

B The last reported state from the device

C The device's hardware specifications

D The network status of the device

The desired state is what the device should be set to, as requested by applications or users.

How does a device shadow help when the physical device is offline?

A It turns off the device remotely

B It deletes the device data

C It stores the device's state so apps can still read and update it

D It disables network communication

The device shadow keeps the last known and desired states so apps can interact with the device virtually.

Which protocol is most commonly used with device shadows?

A MQTT

B FTP

C HTTP

D SMTP

MQTT is a lightweight messaging protocol ideal for IoT and device shadow communication.

What happens when a device reconnects after being offline?

A It ignores the device shadow

B It syncs its actual state with the device shadow

C It resets to factory settings

D It deletes the device shadow

The device updates the shadow with its current state and applies any desired state changes.

What is the main benefit of using a device shadow?

A Blocks unauthorized access

B Increases device battery life

C Improves device hardware speed

D Allows remote control and monitoring even if the device is offline

Device shadows enable apps to interact with devices virtually, improving reliability and control.

Explain what a device shadow is and how it helps in managing IoT devices.

Think of it as a mirror of your device in the cloud.

Describe the main components of a device shadow document and their roles.

Consider what information is needed to track device status and changes.

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