IoT solutions are expected to interact with devices to perform and track device state changes. There are two ways this challenge manifests. First, even when experiencing intermittent network connectivity the solution needs the device to perform an action that changes the state of a device, and second the device needs the solution to reflect a state change which has occurred on the device.
Verifying state changes is a pivotal capability necessary for all command and control scenarios.
IoT solutions that leverage the Device State Replica pattern are able to manage device-related state changes in a reliable, scalable, and straightforward fashion.
The Device State Replica pattern describes how to replicate a device’s current state, desired future state, and the difference between current and desired states. The Device State Replica pattern is similar to Command in that both use messages as triggers for actions and acknowledgement messages when actions are complete. However, the Device State Replica pattern goes farther than the Command pattern, by taking a prescriptive approach to both the management of device-related state and how the state and changes are communicated. Using the Device State Replica pattern allows solutions to know and verify device states and state changes.
An IoT solution should leverage the following pattern when a component of the IoT solution is the source of the desired state change and that change should be replicated in a device.
state/deviceID/update
topic.state/deviceID/update
topic and records the device state in a persistent data store.state/deviceID/update/delta
upon which device-related state change messages will arrive.state/deviceID/update
and the Device State Replica tracking this device records the desired device state in a persistent data store.state/deviceID/update/delta
and the server sends the message to the device.state/deviceID/update
and the Device State Replica tracking this device records the new state in a persistent data store.state/deviceID/update/accepted
topic.An IoT solution should leverage the following pattern when the device is the source of the state change that should be communicated to components of the IoT solution.
state/deviceID/update
.state/deviceID/update/delta
upon which device-related state change messages will arrive.state/deviceID/update
.state/deviceID/update/delta
and the server sends the message to the subscribed component.When implementing this pattern, consider the following questions:
Using a pub/sub style of interaction a component can listen to the state/deviceID/get/accepted
and state/deviceID/get/rejected
topics and then post a message to the state/deviceID/get
topic. The Device State Replica would then respond with the state on the state/deviceID/get/accepted
topic. If the Device State Replica exposes a REST API, a component can execute a GET against the state/deviceID/get
topic and expect a direct response.
The first action a device should take when connecting or re-establishing a connection is to obtain the current desired state and compare that to it’s last known state. Ideally the server tracking the Device State Replica can calculate the delta automatically and so a connecting Device would subscribe to state/deviceID/update/delta
and can then act on any changes that occurred while in an offline state.
<tbd written scenario>