Manually changed state must be written back to the system

What it is

Users change device state around the smart layer all the time: pressing the button on the device itself, pulling the plug, twisting the thermostat dial, pushing the curtain by hand, throwing the breaker. After any such bypass operation (manual override), the system's record and the physical fact have forked. The write-back requirement: the physical fact at the device must continuously feed the system's state model. Not "users should use the app" — rather "the system must accept that they won't".

The physical world is always reachable: you can uninstall an app, not the hand that pulls the plug. Treating bypass operation as the norm rather than misuse is the premise any smart-home state model has to start from.

Why it happens

The system's recorded state is a belief, not a fact. The model can only approximate reality through two kinds of input: event reports (the device says it changed) and sensing (inferring state from physical quantities). A bypass operation belonging to neither is invisible to the model.

The two inputs differ in power. Devices with sensing can infer from physical quantities — a thermostat reads actual temperature, a smart plug reads current and knows whether the lamp drawing power is on; such devices are naturally immune to bypass. Pure actuators (plugs and relays without sensing) can only trust reports: if the on-device button acts locally without reporting, the system never knows. Mechanical actions have neither — a dial turned to 20 degrees does not exist in the system without an encoder.

Timing adds a window: between the bypass and the arriving report, the system holds a stale belief; any automation deciding inside that window acts against the physical world — the heating was switched off by hand, the system still believes it is on, concludes "target met" and stops, and the house goes cold two hours later.

Studying it

• Operation logging: record a week of physical versus app operations in deployed households. In-the-wild studies of deployed smart homes (including ethnographic work with households living with home automation) find mixing to be the norm rather than the exception — older relatives, guests, and rushed everyday actions go physical in volume; that ratio sets the scale of the write-back problem.
• Awareness comparisons: have users describe their devices' current states and compare with device logs; then sample on-site physical state and compare with system records — the two gaps measure how far "the user believes" and "the system believes" sit from the fact.
• Failure retrospectives: collect "the automation misbehaved" incidents and trace how many root back to an unreported bypass; attribution analysis decomposes vague unreliability into a locatable cause structure.

One methodological caution: behavioural data on bypassing must come from multi-user households — the more heterogeneous the operators, the more bypassing; single-occupant flats undercount badly.

Where it stops holding

• Complete write-back is unattainable. Non-networked physical acts (pulling plugs, throwing breakers, turning mechanical valves) are outside the model by nature; the system's duty of honesty includes admitting "I don't know" instead of pretending.
• Write-back has a delay window. While the report is in flight, concurrent decisions may already have fired; for consequential devices (heating, security) the window needs a safety margin rather than a hope of zero latency.
• Sensing is privacy-constrained. Inferring from current draw is uncontroversial; confirming "everyone left, lights off" with a camera crosses a collection boundary — inference methods need privacy review; not every physical quantity may serve as a sensor.

Applying it

• On-device buttons must report as well as act locally; list "does the on-device operation report upstream" as a product acceptance item.
• Give actuator devices inference capability via power or current sensing, cross-checking the reports.
• Present thermostat-class devices in dual channels: measured temperature next to setpoint, keeping "actual" and "intended" separately readable.
• For actions that cannot be inferred, keep an "unknown" expression at system level instead of carrying the old value forward — the model must not read "no message received" as "nothing changed"; display-level honesty is a separate card's boundary.
• How to check: sample random moments and score agreement between device-log state and on-site measured state; then perform a batch of bypass operations (pull plugs, twist dials) and time how long the system takes to reflect them — or never does. Anything never reflected is a write-back gap.

Related

• Same group: Z4.02.2 Desynchronisation shows up as unresponsive control · Z4.02.3 Stale state must be explicitly marked
• Nearby: Z4.01.3 Physical and digital state must stay in sync · Z4.10 Voice, app and physical switches coexisting
• Search terms: manual override · state reconciliation · smart home field study · event reporting