Status light shows an old task after reconnecting

Status Light is a physical indicator whose meaning depends on the software feeding it updates. After a disconnect, the visible colour or the integration's cached value may describe an earlier task. Reconnection should trigger a deliberate resynchronisation process. Do not assume that restoring a cable or bridge automatically establishes what is happening now.

What state was retained during the gap?

Check what your integration stored before the connection failed: the selected task, desired display state and last successful update. Distinguish a confirmed hardware action from an attempted one. A cache that records success before delivery can make the software believe the lamp is current when it is not.

Inspect the actual device behaviour on reconnect using its documented controls. Whether a unit retains, clears or changes its display is a hardware-specific fact to verify. Build the recovery process around observed or documented behaviour rather than assuming a universal power-on state.

Which task should the display represent now?

Resolve the current task selection from the source or your explicit configuration. If the user switched projects during the outage, replaying the old task's final state can be misleading even when that state was once correct. Store the selection separately from the last colour command.

Fetch the current authoritative status when the source provides a suitable interface. If it cannot be reached, preserve that uncertainty instead of inventing an idle or successful result. A supporting text view can explain which task was last known and when it was checked.

Should queued events be replayed?

Decide whether historical transitions have value for this display. A desk indicator often needs the current state more than a rapid sequence of every transition that happened offline. Validate queued events against task identity and ordering before allowing them to replace the newly fetched state.

Do not discard history needed by other consumers merely to simplify the lamp. Keep display recovery separate from the event log or audit trail. The integration can retain records while choosing a current, relevant state for the physical indicator.

How do you test reconnection properly?

Exercise a controlled disconnect while a test task changes state, then reconnect and compare the final display with the source. Include a case where task selection changes during the gap. Inspect logs for the resynchronisation decision and the actual device update result.

Check the Status Light hardware details before choosing the control method. Reconnection correctness comes from current-state retrieval, task selection and a verified write, rather than from the presence of a connection alone.