Has the detached relay mode been fixed in Z2MQTT yet?
I’m not entirely sure how it’s supposed to work, but shouldn’t it show 2 on/off entities at least in detached mode in order to read the switch state independently of the relay state? I see only one on/off state here:
Is this still a bug or “by design”? And does the switch show up as an independent sensor in ZHA?
No. The switch itself has no state. Only the relay does.
This applies to all devices with or without detached mode. If you look at something like a wireless switch, it won’t even have a state since there’s no relay
Sorry for the noob question, but how would I be able to set up an automation based on the switch independently of the relay (detached mode) if it has no state? Maybe I don’t get what the detached mode actually does… If the “state” is the relay state, it won’t change when the switch is pressed in detached mode, right? Then how is a switch change (not relay change) communicated to HA?
Same issue here.
Part of the apparently missing “switch state” issue may be due to the fact that the device supports both rocker switches and momentary push switches. A rocker switch obviously has a state, mechanically/electrically. But because this device also works with momentary push “switches” those don’t have state in the same way.
This really sucks, but seems it is the nature of the device I apparently wasted my money on.
I want one set of behaviours when the rocker switch is Off and another when it is On, I expected the rocker state to be presented as a sensor, but instead all I can do is trigger a toggle and not actually report switch state. I could work around this by storing a variable in HA that holds the current state of the rocker switch and turn it on or off accordingly on a toggle event (not fool proof, it could well go out of sync) but I’m struggling even to do that.
I mapped the toggle action to toggling the switch on and off, and doing that the damned relay seems to emit the same event as the switch so if you ask it to toggle in response to a toggle it keeps on toggling and now the relay is stuck on regardless of what state the HA dashboard thinks it’s in.
Disappointing to say the least. This should be really really simple but I’ve wasted not only money buying 5 of these useless switches but 3 hours of my life trying to turn a light on in response to a switch (!)
Edit: I should also note I’ve tried ZHA and Z2M and I’m having an equally bad time with both.
Edit 2: I have now finally got this working the way I want. It’s using Z2M now. What I had to do:
1: Force remove the devices from my zigbee network.
2: Delete all previous attempts at automation
3: Create an inputboolean helper to track the status of the physical switch (I can soft-flip it if it gets desynced)
4: Create an automation on the action: toggle event of the switch with a ‘choice’ as the action. If input boolean is true, set input boolean false and set switch relay OFF and the reverse choice for turning on.
4a: It is critical that you don’t just toggle the relay on a toggle action, as toggling the relay will send the toggle switch action as well as respond to it, which gets the device stuck in a loop.
5: create a second automation for the motion sensor with input_boolean = off as a condition. Again, critical that you use switch ON and switch OFF and not toggle to avoid getting stuck in a loop.
Now my motion sensor controls the light when the switch is ‘off’, and the light is overridden to ON when the switch is ON.
Like I said, any occasional desyncs caused by reboots can be corrected by soft flipping the input boolean in ha
In your specific case, (you are posting about Z2M properties in a ZHA topic), you need to listen to events. You can use the legacy action entity or the new experimental event or the recommended MQTT device trigger. It’s all explained here.
There’s a few posts here on how you can adapt to the new (non-legacy) requirements, so I’ll let you search for them in the hopes of teaching you how to fish, so to speak.
Yes, I get that the single toggle event sucks, but other devices have the same issue with single_press , and that hasn’t stopped users from adjusting to them.
I moved from ZHA to Z2M and I can do the detached with the capability to automatically revert to attached if the zigbee network is down. I have done partial testing, but it looks good.
In detached mode, the physical switch seems to only generate the event “toggle” to trigger an automation. It is also a bit slow since it miss to generate a second event if the physical switch is toggled in less than 2 seconds.
Anyone found something different?
How did you manage to do this? More importantly, how did you test this?
The only way this could ever work is if you could code the automation directly on the device, like ESPHome does. There used to be an external extension which let you create Z2M automations, but that’s been removed and even then, it wasn’t a direct on-device thing. You still needed Z2M to be running to have it working.
I am not aware of something which works like you mention, so consider me genuinely curious.
I have the same use case and I switched today to Z2M only for this feature. Woud you liek to share the script for the automation ? Thank you!
For everyone following this topic, in HA 2025.8.2 this issue has finally been fixed for the ZHA integration.
You can now use detached mode without any issues.
Recently, I bought four ZBMINIR2 to replace dumb relays and switches, and to my surprise, they seem to be working just fine with ZHA under the most recent version of HA.
I don’t need detached mode at the moment, but it seems to be working just fine.
I’m using a RPi 4 Model B running Home Assistant OS 16.1, Core 2025.8.3
The coordinator is a ConBee II with latest firmware.
All relays have firmware 0x00001004, I don’t have older ZBMINIR2.
I replaced two standard relays, so the Sonoffs receive a 230v pulse on S2 when I push the buttons (Pulse Trigger mode), while the other two replace normal switches (Edge Trigger mode) with the interrupted phase sent to S2 (so it’s either 0v or 230v depending on the state of the switch).
I have no Sonoff that uses a closed loop between S1/S2 as trigger, so I can’t say anything about that configuration.
All four Sonoffs have Detached relay disabled and PreviousValue for power on state.
With detached mode disabled everything works as expected, I only get this warning from time to time, probably due to low signal strength:
Unexpected transmit confirm for request id 250, Status: TXStatus.SUCCESS
Apart from that, I can control the lights both from HA and the physical switch directly, so they still work even if the RPi somehow dies.
If I turn on Detached relay, the physical buttons and switches will not affect the state of the relay, but they trigger the 7 events when I use them:
Physical Button:
Physical switch ON:
Physical switch OFF:
Opening is independent from the state of the switch/button, it just toggles.
If Detached relay is off, Opening will keep the last state until I turn Detached relay back on.
Example:
onClosed → OpenoffOpenonOpen → ClosedFrom what I can see, if I turn on Detached relay, a Toggle event is always fired (among others) every time I change the state of the S2 input, which can be easily implemented into automations. The Opening entity doesn’t really do anything useful apart from toggling itself twice, so I will probably ignore/disable that entity.
The LED of the SONOFF is always still, it never blinks.
Hi @Muiss, you beat me on time!
I was diving into GitHub in search of this issue, and this is the PR in zigpy that implemented the fix.
This version of zigpy (0.81.0) was included from Home Assistant 2025.8.0b1 so if you update to the latest version, the ZBMINIR2 will work natively on ZHA (probably you will have to Reconfigure the relays).
Hi,
one thing I do not get is why in case of essentially using ZBMINIR2 only as digital input, bother with detach mode. If you are able to install ZBMINIR2 with all the wiring availabe (full power L - N, outgoing L wire toward the light, switch), why just not leave the output of ZBMINIR2 unconnected and wire the L in and L out together. This way light bulb always has power and switch state is detected. Annoying thing might be the relay clicking, but that is a minor issue.
There is also the factor of local regulations / code compliance.
This obviously depends on where you are, how much risk you wish to take, and how thorough you wish to be compliant.
But sure technically it can be done - one can certainly wire L to L.
And then, there are also people simply want to have options / want to make changes sometime down the road.
If/when my smart bulb gets faulty, or I need the smart bulb somewhere else, I could have just swap in a dumb bulb, change the config of the smart relay in ZHA, and still get smart lights in the room. And I can move on.
This is now all working with ZHA. In detached mode on and switch turned on; when you flick your physical switch, you’ll see the Opening sensor Open (on) or Closed (off). Use this attribute to automate your lights on and off.
Has anyone been able to bind bulbs to the ZBMINIR2 combined with the detached mode? The detached mode works just fine with an automation to turn the bulbs on or off based on the Opening sensor state, but if I directly bind the bulbs (and disable the automation), separately or as a Zigbee group, to OnOff, they just stay on and flicking the switch doesn’t appear to have any effect on the bulbs. Am I forgetting something or is it just a limitation of this device?
It works fine with the automation, I’d just like to make it even more foolproof.
Did you flash the open source firmware from GitHub that would enable binding? If not, the firmware from Sonoff does not support binding. I have checked with Sonoff’s tech support.
Aha, do you know by any chance if similar firmware exists for the ZBMINIL2? I tried binding that to a Ikea Vallhorn PIR sensor but though it’s listed in the ‘bindable devices’ nothing happens.
Don’t know about L2, but if you find something (or if you build your firmware) please share back here.
