The problem
When a wall switch is set to decoupled mode, the relay is locked closed and the button only emits a Zigbee event that the hub converts into an automation. If the hub is unavailable — hardware failure, reboot, or a firmware update — the button does nothing, and the light is stuck in whatever state it was in. The only way to recover manual control is the circuit breaker.
In control_relay mode the button drives the relay locally, so manual control survives a hub outage. Decoupled mode trades that away, and there is currently no middle ground.
Why there is no workaround today
The switch firmware exposes operation_mode as a strict two-value enum:
operation_mode: ["control_relay", "decoupled"]
There is no third state, and no attribute anywhere in the switch firmware that is aware of hub reachability. So this cannot be solved by an automation, a hub-side setting, or a third-party integration — it has to live in the switch itself.
(power_outage_memory exists, but that governs behaviour after a mains outage, which is a different failure mode.)
The request
A third mode, or a sub-option of decoupled mode:
“Fall back to relay control when the hub is unreachable for N seconds”
Proposed behaviour:
- Normal — relay stays closed, button sends scene/automation events (current decoupled behaviour, unchanged)
-
- After N seconds with no hub — button reverts to directly toggling the relay
-
- On hub recovery — automatically return to decoupled
N configurable, with a sane default (30–60s) so a brief hub reboot does not cause a visible mode flip.
- On hub recovery — automatically return to decoupled
Why it matters
This matters most for smart ceiling lights, which must stay powered to remain controllable. For those fixtures decoupling is the architecturally correct wiring — cutting mains to a smart fixture is exactly what causes the “I can turn it off by voice but not back on” problem in the first place. But adopting the correct wiring currently costs the household its last manual fallback.
The people most affected are the ones who did not build the system: family members, guests, an elderly parent, a helper. During a hub outage they have no way to turn on a light, and “go find the breaker panel” is not a reasonable answer in the dark.
Prior discussion
The same question was asked in February 2026 for the H2 EU and never received an official answer:
Related to, but not solved by, the Matter binding requests
There is an existing cluster of requests asking for Matter Binding Cluster (0x001E) support, which would let a switch drive a light directly with no hub in the path:
- ** Feature Request ** Matter Bindings and Decouple Relay (Sept 2025)
-
- Binding Clusters – Feature Request & Roadmap Question — where the official answer was that binding cluster support cannot be confirmed as planned
Bindings are the better long-term answer, and I support those requests. But they do not help the large installed base of Zigbee switches sitting behind a hub, which is most of what people already own. Matter bindings only apply to Matter/Thread devices.
- Binding Clusters – Feature Request & Roadmap Question — where the official answer was that binding cluster support cannot be confirmed as planned
That is the practical argument for this request: a hub-unreachable relay fallback can ship as a firmware update to switches people already have on their walls. Binding support cannot. The two are complementary, not alternatives.
My own setup is 3× Hub M2 bridging ~44 Zigbee accessories into Apple Home, including AK037/AK038 wall switches paired with AL186/AL018/AL185 ceiling lights — exactly the configuration where decoupling is correct and the missing fallback bites.