Sync for IoT is currently in Developer Preview, which means access is by invite only. If you'd like to try what you see in these docs, sign up for the developer preview and the team at Twilio will get you onboarded.
With Twilio Sync for IoT, application running on your devices automatically persists its data in Twilio Sync service. Each device can address arbitrary number of Sync objects, including Documents, Lists, Maps and Message Streams. Sync objectsƒ accessed by deployed devices may belong to one of the following groups.
- Common objects: multiple devices in your application publish or subscribe to the same object. If the object state changes, all of them will be notified by the service.
- Dedicated objects: accessed by a single device in your application, reflecting its state fully or partially. Other devices never address these objects in order to isolate their state.
The figure below illustrates an example application where a Toaster device subscribes to the dedicated 'toastConfig' map and publishes to the dedicated 'toastAlert' list. Coffee Machine device subscribes to the dedicated 'brewConfig' map and publishes to the dedicated 'brewProgress' document. Both devices publish reports to the common 'powerConsumption' list.
With Twilio Sync for IoT, the authoritative state is always stored in the cloud, and the logical flow of data in every interaction can be one of the following.
- Device to Cloud (D2C): your devices delivers data to your backend for further processing. Typical examples include data collection and sensor state reporting.
- Cloud to Device (C2D): your backend delivers data to your devices. Typical examples include device configuration and remote control.
- Device to Device (D2D): your devices are exchanging data through the Twilio cloud without your backend transforming it in the middle. Besides human-less devices, this scenario may also involve human-operated Browser, iOS and Android endpoints.
Additionally, there may be hybrid scenarios, e.g. where your backend needs to make sure if (or when) the updated state was received by the target device and got processed successfully. In such scenario, you may want to combine C2D and D2C flows, and enable feedback loop through a separate object, reflecting the actual device state back to your backend. When processing is successful, the device would update a dedicated object to indicate its completion. This way, your backend can make a difference between requested and actual states, and execute business logic driven by the device feeback.
In case device connectivity is impaired and the client goes offline, it may miss updates to its authoritative state stored in the cloud. Sync for IoT addresses this problem by keeping track of Sync objects subscribed by your devices and respective revisions of last known good states received by these subscribers. In case a state update is missed by a QoS 1 subscriber, MQTT gateway replays the data when the subscriber is observed online next time, thus bringing it up to date with latest state.
To simplify application logic that restores correct state after loss of connectivity, we encourage developers to
- Use persistent MQTT sessions (Clean Session flag set to 0). This way, devices will reuse their previous sessions, with all persisted subscriptions and unacknowledged QoS 1 messages.
- Subscribe with QoS 1 level requests. This way, MQTT Gateway will perform replay of missed updates to corresponding subscriptions.
For more information on Twilio Sync, please refer to the following resources.