SimtoLink: Devices are marked offline after 30 minutes of silence
On mobile networks, devices are often only intermittently online. If a business application pushes configuration directly to a device, the command may be lost or arrive out of order while the device is asleep.
What the shadow solves
A device shadow keeps a JSON state document in the cloud and separates the configuration or properties the application expects (desired) from the state the device actually reports (reported). The application talks only to the shadow, and the platform pushes the difference when the device comes online, which removes the race in this pattern. The SimtoLink device-management platform treats the shadow as a first-class object and shares the same state source with configuration delivery and the rules engine. The shadow also covers the application’s desired state, the device’s reported state, version conflict detection, and cached replay of offline commands on a weak network.
The JSON structure includes metadata, desired, reported, and delta fragments. Each update increments the version number and rejects stale writes. After the application patches desired, the platform computes the diff and generates a delta. When the device comes online it pulls and applies the delta, then reports the reported state, converging step by step. A version vector detects concurrent write conflicts and rejects stale operations. Rollback to a historical version is supported, and highly sensitive parameters can require a second approval. The sync sequence is: the application writes desired, the platform computes the delta, the device pulls and executes it, and then reports the reported state.
Platform capabilities and document structure
The platform separates desired from reported: the application writes only the desired state, the device reports only the actual state, and the platform computes the difference and pushes it. Versioning and conflict detection increment the version on every update and reject stale writes, so several parties changing configuration at once do not overwrite one another. While the device is asleep, commands are held in the shadow and the difference is pushed automatically when it comes online. On a weak network, confirmation can be done in batches. Write permission on desired fields is limited by role, and highly sensitive parameters can require a second approval or a two-person review. The console shows the live difference between desired and reported, and fields that have not converged raise a linked alarm.
A typical document contains metadata (version and timestamp), desired, reported, and a delta fragment. The platform increments the version on every update and rejects stale writes, so two operators changing configuration at the same time do not overwrite each other. For large fields, such as a full page of rule sets, a shard key or an object-storage URL can be used so the shadow stays a manageable size. After the application patches desired, the platform computes the diff against reported and generates a delta message. The device pulls or subscribes to the delta when it comes online and, after a successful apply, reports the reported state. If some fields cannot take effect immediately, the device should report a pending reason. The shadow keeps a not-yet-converged mark and raises an alarm. On a weak network, this can be combined with connection-resilience policy so the device confirms in batches.
Permissions, boundaries, and acceptance
The shadow is oriented to runtime state sync. A digital twin can add simulation and historical tracks on top of it. In some projects, SimtoLink customers use the shadow as the real-time layer of a twin and write aggregated results into time-series storage. Who may change desired should be constrained by RBAC: support staff may change only display parameters, while engineering may change the sampling period. Every change is written to an audit log, and rollback to a historical version is supported. Highly sensitive parameters, such as an unlock command, can require a second approval or a two-person review.
The shadow should not be used as a general message queue for high-frequency writes. High-frequency telemetry should still go through the telemetry pipeline. Sensitive credentials in plaintext should not be stored in the shadow; a reference token should be used instead. The desired and reported field sets should follow the same schema, or delta calculation produces a lot of noise. Shadow document size and update frequency should have an upper limit, because an oversized JSON raises the cost of diff calculation and storage. For configuration changes across many devices, prefer configuration templates and batched jobs rather than writing a huge desired state to a million devices at once. Integration tests should include out-of-order reports, partial field failure, and replay after a disconnect, to check that version numbers and pending marks behave as expected. The acceptance checklist covers rejection of conflicting writes, rollback, and completeness of audit fields. A device shadow lets cloud intent and field truth still converge gradually in a weak-network world. The SimtoLink device-management platform provides a versioned shadow API, a visual diff, linked alarms, and quota governance, so application teams can reduce the complexity of a homegrown state machine.
Source: https://www.simtolink.com/product/dmp/device-shadow-state.html