I have two Blue Smart Dimmers VZM31-SN acting as controllers for a Blue Fan Canopy Module VZM36. They are both wired with no load with just the neutral and line wires connected. I have it setup with bindings so the paddles dim the canopy light, and the config buttons control the fan with multi-tap. Controlling both the lights and fan work perfectly. But the LEDs on the dimmers do not work as I would expect.
I setup two groups.
gp_living_room_fan_light:
Canopy module endpoint 1, and endpoint 2 for each dimmer.
gp_living_room_fan:
Canopy module endpoint 2 and endpoint 3 for each dimmer.
Each switch is bound with endpoint 2 to gp_living_room_fan_light and endpoint 3 to gp_living_room_fan.
If I operate the canopy light with the hub, the LEDs on the dimmers do not show the dim level or change in any way.
If I operate the canopy light with one of the dimmers, the LED on that dimmer will show the dim level, but the other dimmer will not. Both dimmers act exactly the same way.
Not a big deal. I don’t need an LED to tell me the dim level of the light in the same room. I can see the light itself! But I like things to work as expected.
Hi Mike. Your situation is actually similar to mine. Off the cuff, I would say that you need to bind the two switches together to get them to sync the dimmer state. I haven’t done any Zigbee bindings, so I don’t know if this is possible or how.
I did a one-way association first, virtual switch → load switch. The virtual switch worked perfectly - everything I did on the virtual was also done on the load switch. But the opposite was not happening - changes made at the load switch were not updated on the virtual. So I added another association, load switch → virtual switch, which fixed that issue. The switches now stay in sync with each other as long as the commands (on/off or dimmer) are performed on either switch. My issue is when the command comes from the hub.
Thank you. I don’t know much about Zigbee bindings either. This is the first time I’ve tried it.
As far as I can tell, these switches don’t support direct binding to another switch. The only cluster available when I select the other switch is “identify,” and I doubt that will help with the LEDs.
Both of my switches are “virtual” since neither is controlling the load.
Have you looked at the help articles in https://help.inovelli.com ? Search “binding”. There are several depending on your hub. The articles discuss group binding, which, according to the MQTT article, is designed to keep switches in sync.
I looked at all of those articles. None of them mention keeping the LED notification bar in sync using groups. In a video they show one switch controlling 13 Hue bulbs, and the LED shows the dim level, but that was only demonstrated from the switch which also works in my situation.
I followed the instructions here (the description incorrectly says using ZHA when the article is actually about Zigbee2MQTT):
As I described when I opened this topic, my groups and switches are bound according to the group binding setup described in that article.
The group does not keep the LED bar in sync. The LED bar only works when the switch is controlling the canopy module endpoint 1. When the other switch or the HUB controls the dimming level of the canopy module, the LED bar does nothing.
The MQTT article does. I don’t have anything bound right now so I can’t help you with specifics. But there are plenty of people here that bind, so someone should have a solution.
What hub are you using. If it’s HA, ZHA or Z2MQTT?
My hub is HomeSeer HS4 using Zigbee2MQTT with their Zigbee Plus plugin.
The Home Assistant with Zigbee2MQTT articles are relevant for HomeSeer systems like mine.
The level of the group is not the problem. The dimming of the bulbs in the bound canopy module work perfectly from either switch or the hub. It’s the LED bars on the switches that do not work when the dimming is controlled by the hub or the other switch.
First it talks about binding a switch to a switch endpoint 2 with the OnOff and LevelCtrl clusters bound. Maybe that’s an old firmware because the only cluster offered when I try to go switch to switch EP2 is Identify.
But it also says if you’re binding 3 or more devices, you should use groups. I’m binding a canopy module and two switches; therefore, I should use groups.
My groups are setup exactly as described in the article.
When you are controlling the canopy module in Z2M or your hub, are you controlling the module directly or controlling the new entity that represents the group?
If you want everything to maintain state, you have to only control the group entity and none of the others directly in your hub.
I missed the part in switch to switch binding that says you need to bind source switch EP2 to destination switch EP1. So I tried it, and it works if controlled from either switch, but not the hub.
I figured I should drop the direct switch to switch binding and add each switch’s EP1 to the lights group. Well, that works the same as the direct switch to switch binding. It works from either switch, but not from the hub.
It’s probably a flaw in the way HomeSeer implemented it, but when I create a device for the group in the hub, there are no features that I can control. I’ll post over in the HomeSeer forum and see if the plugin developer can shed any light.
I’m fairly convinced that this is exactly what the problem is. The way that the groups are configured, when you control a switch, it is bound to the groups so it can xsn trigger them, but there’s no way to do the same from the canopy module.
Each group should create a new entity in the hub and controlling via those entities should keep things in state always. If they can change the hub integration to support that, it should fix the issue.
I bound my canopy module to the groups and now the LEDs sync whether from switches or hub. I never saw an instruction that you needed to bind the canopy to the groups. I guess you just have to bind everything in every direction.
Your last sentence is the key part: Put everything in a group - switches, lights, canopy module, whatever. I use groups even for a single switch and bulb just for simplicity and consistency. The group names become easier to mess with elsewhere in your hub.
Not in HomeSeer. In HomeSeer, the Zigbee2MQTT groups are just useless names that have no features to interact with.
Fortunately, with all the devices grouped, and each device in the group bound to the group, when I control the canopy module in HomeSeer, the group is notified in Zigbee2MQTT, and the right thing happens.
In HomeSeer, I should be controlling the Fan group, but I’m actually controlling the canopy module directly, and the group it’s in notifies the other group members. Not the way it’s supposed to work, but it does work.
