AV Feedback State Machine: Separate Desired, Pending and Observed State

An AV feedback state machine should track what the operator requested, what the device last reported and whether a transition is still pending. Do not overwrite observed state with desired state when a button is pressed. Keep unknown, stale and fault conditions visible so the interface does not claim success without evidence.

This model applies across transports. A socket send, an HTTP response and a projector status query provide different kinds of information. The control panel must interpret each at the appropriate layer.

Keep three separate records

Store desired state with the request time and source of the request. Store observed state with the device identity and observation time. Store transaction state with confirmation, rejection or uncertainty. Those records can agree, disagree or be unavailable independently.

The labels are a proposed interface model, not a declaration of an existing product implementation.

Derive completion from the device contract

TCP's specification provides transport delivery semantics, not physical completion. HTTP semantics define response categories, while the device API supplies the actual application meaning. Neither should be reduced to a universal boolean success flag.

For a concrete projector example, the Epson EB-PU PJLink table distinguishes standby, on, cooling and warm-up. A panel that keeps only on and off loses transitions that matter to sequencing and operator decisions.

Define the completion condition for each action. Power-on might require a reported on state; a presentation-ready workflow may also require selected input and valid signal. Keep those as distinct conditions so a failed source does not masquerade as failed power.

Reconcile competing events

An operator can request Close while a startup is pending, and a technician can use a local remote at any time. Decide whether a new request replaces, queues behind or rejects an existing transition. Make that policy explicit rather than allowing independent timers to race.

Accept valid unsolicited feedback when the protocol supports it, but distinguish events from replies to a command. Associate transaction responses with the relevant request and session. A delayed observation from a retired connection must not overwrite a newer state.

Keep a freshness deadline for observations and a separate transition deadline. A device can remain connected but stuck in a transition, or be physically on while its last observation becomes stale. Those are different conditions requiring different messages.

Recover from uncertainty deliberately

After reconnecting, obtain a current snapshot before replaying commands. For a desired-state operation, reconcile actual state with the latest approved target. For a toggle or trigger, follow a duplicate-sensitive recovery policy and involve the operator when necessary.

Controller startup should not assume every device is off. Query the installed equipment and rebuild observations. Persist only the information required by the project, and do not confuse saved historical state with a new observation.

Test the event sequence

Use a simulator or controlled bench to deliver delayed replies, lost replies, explicit rejection and local state changes. Verify every displayed label and downstream action. Test a newer operator request arriving before an older response, then restart the controller mid-transition.

Record which request became the current target, which observation completed it and which timeout created uncertainty. Keep timestamps consistent across events. This makes a report that a button turned green too early traceable to a completion rule rather than a debate about whether the network felt slow. Preserve the input event sequence in a reproducible simulator case so a later driver or UI change can be checked against the same operator-visible expectation.

A passing state machine preserves what is known and what remains uncertain throughout those events. Apply the AV commissioning checklist to the complete system, and discuss required feedback capabilities with an integration partner before promising closed-loop operation for every device.