Yes it does: Aqara ZNQBKG39LM control via MQTT | Zigbee2MQTT
Crap! You are absolutely correct! Sorry about that! I read WAY too fast. 
Anyhow, then, yes, you can set it in ZHA using the manage clusters interface and setting the mode there.
Hi all and more specificaly to @mikaelhertzman 
, I would like to revive this thread once more. Looking into the devices supported by zigbee2mqtt i found these three:
- Ubisys S1 control via MQTT | Zigbee2MQTT
- Ubisys S2 control via MQTT | Zigbee2MQTT
- Ubisys C4 control via MQTT | Zigbee2MQTT
they all three support binding
they all three support decoupled mode
all three are battery less and powered by main.
Aren’t they satisfying all the requirements?
- Use the physical light switch to turn on and off smart bulbs (without toggling the power to the bulb)
- Use the grid/mains to power said device
- Use Zigbee standard for said device
- Not having to rely on bypassing the switch with wiring (edit: added this for clarity)
1 Like
Yes, they should fulfill the requirement and they are mentioned multiple times throughout this thread but good looking out!
I actually own a S1 but haven’t gotten around to testing it yet. Finding the Aqara moved it a whole lot further down on my todo-list but if you or anyone else picks one up and tries it out I will be more than happy to list the result here.
Crap, you are totally right!
I just re-read the thread and you mention them in your very first post… Sorry… I should have read better…
I had the opportunity to test for these devices
- DIM Zigbee Push-button Coupler SR-ZG2833PAC-DIM-S2
- DIM Zigbee Push-button Coupler SR-ZG2833PAC-DIM-G2
from this manufacturer
beside the fact that they are not supported by zigbee2mqtt and that I had to implement their support on my own (trivial but a bump on the road
nonetheless) into zigbee2mqtt
i have bad news for those. I have them working and they WORK as intended but not with Philips Hue.
The reason is due of their firmware nature. They are green power device, so they behave very similarly to the battery less device where they send a message and the home automation system will intercept it and translate to an action.
These device works slightly differently, they assume that the bulb / lamp that they are targeting has the capability to LEARN more remotes to directly control them.
In zigbee2mqtt they appear as devices that have no endpoint nor cluster (only the green power one) and they don’t send any message to the main mesh hold by the coordinator.
The configuration of these device is more “hardware” than software.
You need to set a certain status the device (pairing mode) via a button sequence and the lamp/ bulb in pairing mode, then the device will send a command to a frequency of the mesh. It can cycle over the 16 channel available until it matches the one where the lamp is listening.
If the pairing is successful, the light will react in some how to it (blinking most likely) during pairing.
Proceed to repeat for every lamp/ bulb you want to control with this device.
These device can control as many device that are at reach of the signal that it produces.
More over, these devices can act as router relying messages of the network, they rely messages on the same frequency where the lamp configured to it is.
They can work within a configured mesh network.
In addition my test were executed with this configuration:
- 2 bulbs from 3rd party vendor (something from aliexpress, with pairing mode with multiple remote, i discover it only by chances )
- bulbs initially paired / joined to my main mesh network zigbee and displayed in zigbee2mqtt
- let the button coupler to join the network as well (put it in pairing mode and let it be visualized by zigbee2mqtt)
- put one of the two bulb in pairing mode, then put the the button coupler in pairing mode (my newtork is on channel 11) and then simply waited a couple of second. the bulb blinked.
- repeated for the second
at the end when i was pressing the push button attached to the button coupler it was indeed controlling the two bulbs with dimming.
So the TLDR is:
If the bulb has this capability then you are gold (their bulb / led driver has this). If you have a Philips Hue you are out of the game.
So their binding is different from what we mention in this thread.
I Hope that this would be helpful to some one.
In addition i am in contact with them since some weeks, i explained my struggle with this device and I explained the needs, it seems that they are listening to the request and they could modify the firmware to allow a different firmware to be loaded with a normal binding, but i am waiting for their answer, i wouldn’t hold the breath for this
3 Likes
I just need a 3-gang switch that supports decoupled mode for the US region 
Maybe that doesn’t exist yet.
Thank you for the tip! If you, or anyone else, owns it and can verify that it checks all the requirements of my first post I will add it to the list!
I have two of these modules. While they support decoupled mode, they lack direct Zigbee binding, which is a drawback. One issue I find particularly annoying is the green LED that stays on constantly, visible through the plastic cover of my wall box at night. I’ve already requested that Sonoff consider adding an option to turn off the LED and enable direct binding in future updates—hopefully, they’ll implement this. Overall, these modules are the smallest available on the market, and the relay is both fast and quiet.
1 Like
Draw over it with black marker or cover it with a small piece of black electrical tape. Problem solved
I see better ways of spending electricity. This LED is completely unnecessary. However, covering it does partially solve the issue.
If the measly amount of electricity a tiny smd led uses bothers you, then go nuclear. Grab a pair of tin snips or your nail cutter and chop off the led. Job done.
Hi all, I’m new to the community.
A very interesting thread as I’m looking for the same things in a smart switch relay. Because 8’m new to this, reading the thread leaves me with some questions:
- How can you see that direct binding is supported? If I look at documentation of those switches, I don’t seem to find n exact reference to the term.
- The Ubysis C4 module seems to work very different from the others (even from their own brand like the S2) as it only exposes “action”. Is it something categorically different and why does it exist compared to the other modules that seem to operate very similarly?
Btw, andrazk seems to confirm that the minir2 works, so I suppose it should be added to the list? I’m considering testing one of the Ubysis ones as they seem the most feature complete, but I just need some clarity first on the conceptual difference between the C4 and the others.
minir2 would work. you likely would always want to go to the product page to see the details to be sure.
ZBMINIR2 - SONOFF Official
Note that for the decoupled / detached mode to work, make sure you have a neutral wire to the minir2 also.
And yes information about the binding feature is not consistent. You likely will have to try, or rely on other user’s feedbacks, or reference the documents from the manufacturers, if there is any.
I think (I don’t own either) the difference is that the c4 doesn’t have the possibility to switch the circuit (as in cut the power to it), while the s2 and others do. So you could say it only works in decoupled mode.
I did email ubisys with a question about the switches (possibility to set up double or triple click action, unfortunately not possible) and they were quite responsive, so could always try that if you don’t find an answer here 
1 Like
Decoupled mode works great, but wouldn’t it be even better to have it combined with direct Zigbee binding? Please write to their support to show there’s strong interest in this. They confirmed that my request for direct Zigbee binding is included in their next iteration plan, but due to limited resources, they couldn’t provide an estimated timeline for implementation.
I already wrote them to ask about hold and double click functionality and am awaiting a reply. I will follow up with request for direct binding as well. I couldn’t really make out if they had it (alas my previous post), so that’s why I hadn’t asked.
1 Like
@mikaelhertzman, I’m new to this and don’t have a HA setup yet. As you have been playing around with the T2, I wanted to check something with you regarding the following sentence you wrote: “double and hold actions would make things simpler”.
Does that mean that even without support for those actions, you can work around them with HA scripts/automations to support such things like dimming the light by holding the switch or cycling through scenes if subsequent clicks follow each other fast enough?
Thank you for verifying! I will add it to the list since it meets all requirements from my original post. I agree that the lack of binding support is a drawback but it’s the same for the Aqara T2. When it comes to that option the only hope I think we might have is the Ubisys devices. Thank you again for your contribution!
The best source of information I have found is the device pages on https://zigbee2mqtt.io/devices/. As a alternate option you can also try it out for yourself (using HA, Zigbee2MQTTT and the device in question). There might be a better way to do this, but those have been my two methods of choice.
The only bits of information I can find explaining this is at Ubisys C4 control via MQTT | Zigbee2MQTT and Control unit C4 – ubisys. If none of those sources answer your questions I recommend getting in touch with Ubisys support. They have been really helpful in our previous e-mail conversations.
That is correct. I have created modified scripts from Trigger different actions on a single, double or double click on a binary sensor (if I recall correctly). The reason why I’d prefer if the device had native support for hold and double tap/click actions are:
-
More responsive - the switch sends the correct action to the gateway instantly. This means that any action (turning off lights, turning on your lawn mower etc.) will be carried out as quick as your Zigbee network allows. Say that you, for example, configure a 2 second delay to allow HA to “listen” for a second click. In this case you will not be able to have the single click action occur before you have “waited out” the 2 second window. This means that after every interaction you will have to wait 2 seconds before anything is carried out. I hope that makes sense.
-
More reliable - if you press a button twice or hold it and the subsequential clicks (or releases) are not received by the gateway for any reason, things will get weird. A package lost due to transmission issues, or the timing of your interaction being off, will in my experience result in frustration from the end user. (I know this from personal experience after hearing the sounds of my partner double-clicking switches again and again and again without it having the desired effect.) With finetuning it should/could/might work but your mileage may vary and it is in no way as effective as built-in actions in my experience.