Home Automation That Distinguishes Commands From Reality
Abstract
Home automation often treats a delivered command as evidence that a device reached the requested state. That assumption breaks when messages are delayed, acknowledgments are ambiguous, or a resident uses a physical control. This paper proposes a Slot3 control model with separate desired state, observed state, command identity, and override policy. A synthetic lighting sequence illustrates how an older command can conflict with a newer human action. The analysis distinguishes message-delivery guarantees from physical outcomes, compares toggles with explicit state commands, and defines tests for reconnects and stale observations. It is a reference architecture for household control, not a validated safety case or an account of a deployed installation.
Intended audience Home-automation developers and engineers designing device orchestration.
1. Delivery is not completion
A controller sends a command, a messaging system acknowledges it, and the interface shows success. Yet several outcomes are possible: the device has not received the command, it received but rejected it, it acted but has not reported back, or the physical state changed again afterward.
The design question for Slot3 is how to represent those outcomes without making the household depend on an optimistic interface. The proposed answer is to keep desired state, observed state, and command progress separate. A command is an attempt to change reality; an observation is evidence about reality at a particular time.
This paper develops that distinction for ordinary household automation and uses lighting as a synthetic example. It does not establish the suitability of any software for hazardous equipment, access control, or life-safety functions. No particular installation or device implementation has been verified for this edition.
2. A command needs an identity and a deadline
A command record should identify its target, requested state, creation time, expiry condition, and applicable control policy. Its progress can be requested, dispatched, acknowledged, confirmed by observation, rejected, expired, or uncertain. The supported states depend on what the device protocol actually exposes.
The MQTT specification defines delivery quality-of-service levels for protocol messages. These mechanisms do not constitute a report that a physical actuator reached a requested state. [1] A device integration must state what an acknowledgment means instead of borrowing a stronger interpretation from the message transport.
- 1. RequestIdentify desired state and expiry.
- 2. DispatchApply policy and send the command.
- 3. ObserveReceive fresh device evidence.
- 4. ReconcileConfirm, disagree, or remain uncertain.
An observation also needs identity and time. An old report arriving after a reconnect should not overwrite a more recent physical state merely because it was received last. If a device cannot supply trustworthy sequencing or timestamps, the controller must acknowledge the resulting uncertainty and use a conservative reconciliation policy.
3. Worked example: an older automation conflicts with a resident
Consider a synthetic lighting rule that requests a lamp to turn off after a period without detected activity. The request is delayed. Before it arrives, a resident turns the lamp on using a physical control.
A controller that blindly retries the older request can turn the lamp off again, overriding the resident's newer action. A controller that only tracks desired state may continue showing “off” while the room is lit. Neither behavior reflects the ordering of intent and observation.
The proposed design gives the automation request a limited validity window and records a manual override when the integration can identify it. Within that override period, automatic changes that conflict with the resident's action are suspended. If the source cannot distinguish manual control from device drift, the interface should expose the discrepancy rather than inventing a cause.
| Event | Evidence available | Response |
|---|---|---|
| Automation requests off | Pending command | Show requested state separately |
| Resident turns lamp on | Fresh state report; manual cause if supported | Update observation and apply override policy |
| Older request becomes eligible for retry | Expired or superseded intent | Do not issue it as a current action |
| Device becomes unreachable | No fresh confirmation | Show uncertainty and preserve physical control |
A controller cannot necessarily recall a command already delivered into a device queue. Preventing the conflict completely may require device-side expiry or sequence checks. This is an important limit: a good controller state model can explain and reduce a race without claiming that every integration can eliminate it.
4. Prefer explicit state to ambiguous toggles
“Turn on” and “toggle” have different retry semantics. Repeating an explicit on command often leaves the intended state unchanged. Repeating a toggle can reverse the effect of the first request. Whether either operation is safe to repeat depends on the actual device behavior, not its friendly name.
The proposed integration contract therefore declares replay behavior per command. A duplicate request identity should return the existing local command record where possible. If a device supports sequence numbers or operation identifiers, the adapter can extend duplicate protection toward the actuator. If it does not, the controller should avoid treating uncertain delivery as permission to repeat a non-idempotent operation.
Retained messaging also needs careful use. A retained state observation can help a reconnecting client discover the last reported state, provided its age remains visible. A retained action can be hazardous if a reconnect causes an obsolete instruction to execute. The transport configuration must be chosen according to whether a message represents state or a request for a new effect.
5. Human override is part of the control policy
An override needs a scope and an end condition. It may apply to one device, a room, or a specific automation, and may end after a period or an explicit resident action. An indefinite hidden override makes future automation appear broken; an invisible short override makes the system seem to ignore the resident.
The user-facing explanation should identify what is currently controlling the device and how to resume normal automation. It need not expose message topics, internal services, or raw event records. Those details belong in diagnostic tools when they help resolve a problem.
Presence signals deserve particular care because they can reveal household routines. The proposed design keeps only the state and history needed for the chosen behavior, with a defined retention policy. Local processing reduces some disclosure paths but does not make every local log appropriate to retain indefinitely.
6. Alternatives and verification
A stateless rule engine is straightforward: receive an event, send an action. It works best when actions are low consequence, repeatable, and easy for residents to correct. Its limitation is reasoning about delayed messages, competing rules, and earlier intent.
A desired-state controller continuously reconciles a target with observations. It can recover from drift, but may fight physical controls unless manual changes are represented in policy. The proposed model adds command history and override semantics so reconciliation can distinguish a persistent target from a superseded request.
Validation should interrupt the system before dispatch, after dispatch, and before confirmation. Reconnect a device with delayed observations and queued messages. Exercise duplicate commands, expired commands, conflicting automations, and physical control during uncertainty. Verify what the interface reports as well as what the device does.
A useful acceptance criterion for the lighting example is that the controller never reports confirmed off merely because dispatch succeeded. Another is that an expired automatic request is not issued as fresh work. Physical outcome guarantees require device-specific tests and cannot be inferred from messaging tests alone.
7. Conclusion
Household automation becomes more understandable when the interface separates what was requested, what was observed, and what currently has authority to change the device. That model supports explicit uncertainty, bounded retries, and human override without pretending that transport acknowledgments describe physical reality.
For Slot3, the next meaningful proof would be a small set of device integrations tested through the delayed-command and manual-control sequence above. Their documented limitations would define which promises the controller can make and where it must preserve uncertainty.
References
- OASIS. MQTT Version 5.0, 2019. Protocol delivery and retained-message semantics informing Sections 2 and 4.