Feature request — automatic relay fallback when the hub is unreachable (decoupled mode)

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:

  1. Normal — relay stays closed, button sends scene/automation events (current decoupled behaviour, unchanged)
    1. After N seconds with no hub — button reverts to directly toggling the relay
    1. 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.

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:

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.

5 Likes

We’ll share your feedback with our product team for further evaluation and take it into consideration for future improvements. We really appreciate your detailed suggestions and support for Aqara!

2 Likes

Hi @Caroline_Zzz,

Any updates on this issue?
I believe this is a huge missing part of the device, which seems to be a minor firmware feature, yet the non existence of it makes the device a really bad position when choosing a switch, despite having great features otherwise.

I just bought one of these to test it out and it seems like the above feature is indeed missing. Me and a lot of people are designing their smart homes to be reliable even if the hub/server (like HomeAssistant) goes offline, which requires failsafe features like this to exist. While I’m running with HA, and shutting off my server completely resulted in the switch not doing anything about the loss of the Zigbee network, I believe, since MARS requires a hub to be running, would be the same if someone bought themselves in fully to the Aqara ecosystem. The hub can be at a different phase which can have a power outage independently of other phases and would leave people without control over their lights with these switches, having the only option to switch the light switches back to standard ones in case of a power outage.

I have a friend who has H1 switches and he told me that he has this working with them, while Sonoff Orb and other switches (even with no neutral support) implement this simple failsafe in their device firmwares.

Please, let us know about a timeline when you are planning to fix this in the firmware.

thats a great suggestion! Fingers crossed this will be added in the future

For anyone wandering here, spent some time figuring out a workaround for the miss of the failsafe behaviour. I came up with the following solution, though, this comes with some inconveniences:

You can factory reset this device by pressing on each button 10 times. This will reset ALL the settings of the device, including the relay mode. So this can give you a quick method of getting your lights working if your coordinator or hub fails. However, this implies that everyone in the household has to be prepared for this scenario, meaning you should let them know to press a button 10 times to make the switch work, if it seems to be not working. The lucky part is that “pressing the button several times” sounds like one would do if the button does not do its job, so maybe they would put the device in reset anyway.

The second inconvenience is that as far as I can test it out, the switch not always goes into pairing mode and since it leaves your Zigbee network, you need to re-pair again, meaning you should allow the join on your zigbee network and go around your house, doing the re-pair procedure on all of your switches (push a button two times, but keep holding the second press for 5 seconds). It can be a bit tedious if you have a lot of switches.

The third inconvenience is that while the device ID won’t change, your automations will keep working, but, the device will forget every setting. You have to make sure to have an automation set up that checks any setting, like the decoupled mode or the multi-click mode to be in the setting that you want it to be in. For me, I put it in as a step in the “turn on light” action, since I already have a check there for the relay state, since I put my switch in OFF mode for power loss and my lights in ON mode for power loss, or else my lights would flash in my face at the middle of the night in case of a power outage and bulbs won’t work in relay mode. Whenever I toggle back the relay from a power outage (which means if it was OFF for some reason) I re-apply the settings I want for the switch, so it’ll flip in decoupled mode and have all the other settings I need.

So, there are workarounds to overcome this missing feature, but it’s just unbelievable that a failsafe feature is missing from these switches given it’s overall quality and that even older Aqara switches had this.

If your switch is connected to an Aqara smart light load, we recommend using the Smart Load feature under Mars Tech to link the switch with the smart light. Even if the hub or light goes offline, you can still toggle the relay by double-clicking the switch to control the light, ensuring you can successfully control it whether a network connection is available or not.

1 Like

Thanks @Aqara_Devin — but I don’t think Smart Load / MARS Tech can apply to my hardware, and I’d like to confirm that with you before this is treated as addressed.

MARS Tech requires a neutral wire. The Light Switch H2 product page states the condition explicitly:

*With-neutral wiring, Zigbee mode and Aqara smart lights are required for this function.

My switches are no-neutral. Read directly from HomeKit:

Device Model Firmware
睡房燈開關 / 廁所燈 AK037 (single rocker) 32.0
飯廳燈開關 客廳燈開關 AK038 (double rocker) 32.0

All bridged by Hub M2 (ZHWG19LM, firmware 4.5.60). The house wiring is single-live — there is no neutral at the switch box.

Why this looks structural rather than a settings problem. A no-neutral switch powers itself by drawing a trickle through the load while the relay is open. Decoupled mode requires the relay to stay permanently closed — at which point there is no voltage across the switch left to harvest from. That is presumably the exact reason MARS Tech is documented as with-neutral only.

So for a no-neutral installation both suggested paths appear closed:

  • MARS Tech / Smart Load — requires neutral
    • Decoupled mode — unreliable or unavailable, for the same electrical reason
      Questions:
  1. Is there any supported path for no-neutral switches (AK037 / AK038, or the wider no-neutral line) to keep an Aqara smart light controllable while retaining local wall control?
  2. If there is not, does that make the original request in this thread — a hub-unreachable relay fallback — more relevant for no-neutral users rather than less? They cannot use MARS Tech at all, so the relay is the only local control path they have.
  3. Can you confirm whether MARS Tech is hardware-exclusive to the H2 series, or whether it could reach older with-neutral switches by firmware?

@szbotms — you mentioned older H1 switches already have this failsafe. Do you know whether that was the with-neutral or the no-neutral H1, and roughly which firmware? If a no-neutral H1 does it, that would contradict the reasoning above and I would very much like to know.

Hey @Aqara_Devin,

I understand that MARS is recommended because it is part of your ecosystem and I don’t mind that binding would work that way, but I’m seeing no point of not providing such a simple failsafe mechanism for users outside of your ecosystem, given that you are providing control over the decoupled mode. I’m not using Aqara lights, so I would need to change the lights themselves too, along with an Aqara HUB, which is a way more expensive solution than just replacing the switches. Please, consider adding this feature, especially because this is available on your other switches.

For your question @sem_lal, my friend is using the H1 switches without a Neutral, but he is also using it without MARS - the simple failsafe is available for him, when the switch loses connection to the zigbee network, the button presses operate the relay in the switch instead of staying in decoupled mode.

I do not think that this is a hardware limitation. I’m pretty sure the switch’s firmware is aware of the current connectivity state and since the switch can already control its own relay, it seems to me this should be a pretty simple logic to implement. This would give a huge positive outlook on the device and Aqara itself as it would prove they are listening to their customers by fixing this issue.

1 Like

Hey @Caroline_Zzz, @Aqara_Devin,

Any updates on this one? Will this be implemented?