Zigbee light switch with decoupled mode?

[ciberkids]

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:

1. Ubisys S1 control via MQTT | Zigbee2MQTT
2. Ubisys S2 control via MQTT | Zigbee2MQTT
3. 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?

1. Use the physical light switch to turn on and off smart bulbs (without toggling the power to the bulb)
2. Use the grid/mains to power said device
3. Use Zigbee standard for said device
4. Not having to rely on bypassing the switch with wiring (edit: added this for clarity)

[mikaelhertzman]

@ciberkids

Aren’t they satisfying all the requirements?

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.

[ciberkids]

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…

[ciberkids]

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

Zigbee Push-button Coupler

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

[diegz (diego)]

Now there is the SONOFF ZBMINIR2 control via MQTT | Zigbee2MQTT
It does support detached mode

[luqqas66]

I just need a 3-gang switch that supports decoupled mode for the US region
Maybe that doesn’t exist yet.

[mikaelhertzman]

@diegz

Now there is the SONOFF ZBMINIR2 control via MQTT | Zigbee2MQTT

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!

[andrazk (Andraz)]

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.

[ShadowFist]

@andrazk

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.

Draw over it with black marker or cover it with a small piece of black electrical tape. Problem solved

[andrazk (Andraz)]

I see better ways of spending electricity. This LED is completely unnecessary. However, covering it does partially solve the issue.

[ShadowFist]

@andrazk

I see better ways of spending electricity

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.

[manoswerts]

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.

[k8gg]

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.

[TRiSS]

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

[andrazk (Andraz)]

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.

[manoswerts]

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.

[manoswerts]

@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?

[mikaelhertzman]

@andrazk

I have two of these modules. While they support decoupled mode, they lack direct Zigbee binding, which is a drawback.

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!

@manoswerts

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 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.

@manoswerts

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?

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.

@manoswerts

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?

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:

1. 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.

2. 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.

[svalheimk (Kristian Svalheim)]

@mikaelhertzman

Decoupled mode is great, but what would be even greater is if it was possible to change between decoupled and control_relay for example by pressing the switches for a certain time, or pressing the reset button etc. The reasoning for this is that the decoupled mode is used to a great extent to control smart bulbs. If, however, the Zigbee or MQTT network becomes unavailable you often want to have a way to temporarily fall back to the control_relay mode without having to reset all relays. Think of it as a way to create redundancy.

Thanks for this thread @mikaelhertzman - looking for the same features, and it seems the Aqara T2 is the best option currently.

I am wondering though - while we cross our fingers that Aqara will implement these improvements - how can one revert to control_relay from decoupled as it stands now?
Is the only option to send a mqtt message (not necessarily easily available if system has crashed), and even the reset button (which is inconvenient), or killing the power (slightly less inconvenient) will not change it?

[mikaelhertzman]

I apologize for a looong answer. You raise a valid concern and I wanted to give it my best. I have included a short version at the bottom.

@svalheimk

Is the only option to send a mqtt message (not necessarily easily available if system has crashed), and even the reset button (which is inconvenient), or killing the power (slightly less inconvenient) will not change it?

To be honest I haven’t tried using MQTT to manually set operation modes yet. I’ve simply used the Zigbee2MQTT GUI (see image below) to change the operation mode of my compliant switches.

Secondly, I would like to raise the following thoughts on the general topic of availability/service continuity:
How can we ensure the operations of our home automation setup, and how do we recover from a faulty state? Issues can be prohibited or partly mitigated with redundancies or failsafes but in a worst-case scenario I think it’s wise to have a plan for recovering your system.

I bet there are many people on this forum who could tell you more on how to configure Home Assistant and your hardware in a secure and reliable manner, and I would be more than happy to share my experience too. If you can’t find a topic that raises these questions I would recommend creating one!

Thirdly, with that being said I would unfortunately have to give you the answer “it depends”. If your Zigbee coordinator is one of the components that goes down, will you still be able to send MQTT commands to Zigbee devices? I don’t have the answer myself, I just want to add some perspective to your question. Assuming enough components are available to allow you to send MQTT commands I see no reason as to why your device would not be able to receive and interpret commands, but it might need to be verified (preferably not in a live environment ).

When it comes to resetting the device to factory defaults it’s not as simple as just “killing the power”. Most, if not all, devices will store their configuration and resume their previous operation when possible. Most Zigbee devices that I have come in contact with require certain steps to be reset. If we take bulbs as an example, it usually entails flipping the light switch (toggling the power) on and off a couple of times with a certain time delay in between.

The only official instructions I have found for the T2 is to hold the reset button on the device for 5 seconds and that is not very convenient as you mentioned. I have also seen some discussions on Reddit that seem to suggest that it might be possible to reset the device by toggling the switch connected to the relay (or perhaps the circuit breaker), but this would also require verification.

I realize my answer might raise some new questions but I also hope it answered a few. Thank you for your kind words and for contributing!

TL;DR: Changing operation mode in case of a disaster without human intervention probably requires the supplier to make firmware/software changes. Depending on your hardware there isn’t always a straight-forward way of changing or resetting the operation mode manually.