Voice, app, and physical control of one device need real-time state sync

What it is

When voice, app, and the wall switch — three entry points — control the same device (the same lamp, the same socket), every entry must read and write the same state: change it from one side, and the other sides reflect it immediately. This is multi-entry state synchronisation.

The failure looks like this: a family member flips the wall switch, and the app still shows the lamp "on"; the voice assistant, working from stale state, answers "the light is already off". No entry is lying — each holds a state snapshot from a different moment — but the user treats whichever one they are looking at as the truth.

Why it happens

The three entries send commands down paths of different lengths, so arrival order need not match action order: the physical switch changes the device or a local circuit almost instantly; the app's command travels through the network to the cloud and back, hundreds of milliseconds to seconds; voice adds wake confirmation, recognition, and cloud parsing on top — the longest path of all. With three writers each keeping their own copy and no single source of truth, divergence is a matter of time, not luck.

A household is precisely a natural multi-entry concurrent environment: under one roof, the grandparents use the switch, the parents the app, the kids shout at the speaker — the same device can be altered from different entries in different directions at any moment. Any read inside a synchronisation window returns the past.

The physical switch is the biggest source of divergence: changing the device often bypasses hub and cloud (a smart switch acting locally, or a traditional switch cutting power outright), and the system only learns the world changed at the next report. Until then, app and voice are showing history.

Studying it

Multi-entry sync research is mostly deployment observation and log analysis: instrument homes with multi-entry-controllable devices, reconstruct "state displayed per entry vs. actual device state" time series from logs, and measure the distribution of divergence windows; on the user side, pair with experience sampling to capture the moments an inconsistency is noticed and how it is handled (the dominant handling is "walk over and look" — itself a behavioural index of lost trust in displays). Voice entry end-to-end latency can be measured at scale with scripted commands (stated as standard practice).

Typical variables: entry combination, sync latency, reporting period (for polling devices, the report interval directly caps how long divergence can last). One methodological caution: single-entry, single-user lab setups cannot produce concurrent divergence — sync problems only appear when multiple entries are simultaneously active, so evaluation must reproduce the usage structure of a multi-user household.

Where it stops holding

• "Real time" has a physical ceiling. The voice path is inherently an order of magnitude slower than a physical switch; zero divergence is unattainable. The goal is consistency across entries with predictable latency — users tolerate "consistent a moment later", not "each tells a different story".
• Polling devices have structural divergence. Low-power sensors report on a cycle (seconds to minutes); divergence within the cycle is the price of the power design, not a defect. The job is to expose the divergence window, not to pretend it away.
• A traditional switch plus a smart bulb fabricates disconnection. Flip the switch and the bulb loses power entirely; the system sees "device offline", not "light turned off". That is an entry-design problem, not a sync problem — don't fix it with sync.

Applying it

• Bind state display to a single source of truth: device-reported state is authoritative, and all entries read the same copy — no private replicas.
• At wiring and selection time, prefer smart switches (state reported back) over traditional switch + smart bulb; reserve traditional switches for purely manual circuits.
• Offer a "force refresh" action for key devices, and add freshness cues to state displays ("updated 3 s ago").
• Show "processing" on the entry side before committing: after a command fires, the interface enters a pending state rather than optimistically jumping to the target — otherwise a failed command leaves the display lying first.
• How to check: two people, three entries, cross-operating one device; screenshot every second and compare each entry's display against the device's actual state, recording the maximum divergence duration. Track "share of divergences beyond N seconds" as a release metric, not just mean latency.

Related

• Same group: Z4.10.2 Misrecognised voice commands cause unintended state changes · Z4.10.3 The directness of physical switches makes them the reliable fallback in failures · Z4.10.4 Users need to know the response-latency differences between entries
• Nearby: Z4.02 State desynchronisation · Z4.09.4 After recovery, state must be confirmed, not assumed restored
• Search terms: state synchronisation · multi-device control · event ordering · single source of truth