Since updating Z2M to 2.0 my groups inside the add-on have not been working like before.
Right now I have a 6 device group, 4 Hue bubs and 2 Inovelli switches with 3 way wiring. Then I have each switch bound to the group as suggest in one of the Inovelli guides.
The problem I am having is the lights will turn on and off the lights but the “group” status stays on in Home Assistant. I believe that since the group status is not going off with all the lights it is causing my lights to randomly turn on like an hour later. The only fix I have right now is togging the group off in HA before going to bed so I don’t wake up with them on for serval hours.
Anyone know what could be causing this? I have no issues or changes before this update so I think it’s Z2M. I also believe it could be the switches as well because if I take the switches out of the group then it works great. This isn’t desired as I want the LED bars to match On/Off on each side of the 3 way locating or when app controlled.
hi Gbo, I’d like to try to help if I could, please see this GitHub which addresses the new Z2M 2.x version.
there is one part in here that also talks about click sensors, not sure how long you’ve had those Inovelli switches paired in Z2M but they maybe using legacy actions.
I don’t believe that’s the issue. I also had this break my system and I had no legacy attributes on. It didn’t use those triggers either, it only used direct zigbee bindings.
I have the inovelli switch bound to the group on/off. I can toggle on the light switch and everything turns on. When I toggle off the light switch, the lights turn off. However, the light group device remains on. This causes issues since adaptive lighting will turn the lights on again to adjust the color temp.
Basically the current way of handle binding/groups should not be used. Apparently actor device/receiving devices shouldn’t be in the same group, even if they are separate end points.
The correct way to handle it is to have both endpoints bound to the group, but neither be in the group. That seemed to handle it correctly in my testing and the led bar showed the correct % lit corresponding to the brightness of the group.
This documentation linked above should be updated and possibly firmware changed to handle it better
I closed the issue I had on github as this does not seem to be a zigbee2mqtt issue but on the Inovelli side.
I will give this a try and see how it goes but can confirm that I am also using adaptive lighting. Never put that together but that explains why it randomly comes on for me.
Similar problem here with the canopy fan controller, with the light and fan in separate groups controlled by the fan wall switch. The light seems to work as set up, but the LED bar does not sync with the light status as it did in pre-2.0 Z2M.
Edit: It works when controlling the fan light using the switch itself, but the LED does not update from any automations that change the light brightness or on/off setting. I do not use adaptive lighting
Not sure how to best adjust this since the wall switch isn’t in the group–just the canopy endpoint is.
Came over from the GH issue you opened. I just tried removing the switch from the group and updated the switch bindings to the group to include both Endpoints 1 & 2 w/ LevelCtl and OnOff (and then disabled the workaround automation I suggested on the GH issue). Worked great for my test switch; I’m about to roll this out to the rest of them.
Thanks for doing the legwork to figure this out and reporting back a fix
I will say here that there is an alternative fix I got from the Z2M discord.
If you set the Z2M group to optimistic and off_state to ‘last_member_state’, it should also work. I didn’t try this as I want to have the possibility of turning off some of the lights but the group to still report as on.
Pic of group settings from the discord chat (thread link):
It’s a bummer that this doesn’t work as it did before. I hope the firm ware can be updated to improve it.
For the same reasons you stated I wanted to keep the switches in the group because it simplifies the led bar status.
Having to separate them was working for me but I will probably still leave it as is just handle the group status to off in an automation with click down. That way my dashboard controls can control the group and led status will update accordingly, then I can have the switches toggle the group off.
Thanks for putting in the work to figure this out!
I’m a few weeks away from setting up a renovated house with a few dozen Inovelli switches controlling Hue lights, so I’m glad the Z2M 2.0 transition is being worked out now by other people.
Question about your solution: You have just the lights in the group, and endpoints 1 and 2 of the switch bound to the group, right? From my understanding, endpoint 1 is the control point for the LED bar and endpoint 2 is the controller point for the dimmer. So if I’m understanding the original issue correctly (controllers shouldn’t be put into the groups they control), wouldn’t it still make sense to have all EP1s inside the groups, and just bind the groups to EP2s?
I’d test myself, but for the next few weeks my HA server is in a house with no Inovellis, and my Inovellis are in a house without HA.
Basic question. Once the dimmers are removed from the group, what’s the preferred method to control all of the lights and [previously] dimmers in the group via a command? Sending, say, an off command to the group (which is now only the bulbs) would now turn the bulbs off, but not the dimmer(s), correct?
@clintm You did an outstanding job explaining the situation in that Discord chat.
I have a gut feeling that the person you were talking to was a little quick to dismiss and say “it doesn’t matter” when it comes to the send/receive endpoints in the dimmer. But I’m prepared to be wrong about that. I am far from an expert.
I’ve downgraded to Z2M 1.42 and everything is back to sweet perfection for me. Hopefully a fully functional solution can be worked out between Z2M and these devices in a future update.
I’ll add my thanks to you all for working toward that.
I’ve actually started having the same problem with ZHA since earlier this month (corresponded to the 2025.1 release), which makes me think something changed in the zigpy). With ZHA though it looks like the down press is still be received by HA, but it apparently isn’t doing anything with it. My fix (which I’m going to try some time this week when I have a bit) will be to update the automation that reapplies adaptive lighting when turned on to also explicitly turn the lights off.
Not having the switches in the groups (and thus losing the sync on the LED bar) would definitely defeat the major use of the bar.
Quick follow up. After more testing (slow because I’m currently remote and have to get someone to do the button pressing) it isn’t affecting all of the groups, only one of them. So probably not the library itself and more likely something about the particular group in my case.
I’m experiencing this same behavior after upgrading to Z2M 2.0.0. I have four groups targeted by HA Adaptive Lighting which contain Hue bulbs and Blue 2-1 switches. I was experiencing a symptom where turning off all individual lights / switches in my group was not triggering the group “OFF” state, and so AL would eventually turn those lights back on again on the next adapt cycle.
I found that the suggested fix in this thread doesn’t entirely resolve the issue. After binding switch endpoints 1 and 2 to my Zigbee group of bulbs, I do see that turning off the bulbs individually will change the group state to “off” (as intended). This resolves the Adaptive Lighting problem I described. However, turning the individual bulbs off in that way does not appear to be changing the switch state to off, or the level. Now we end up with the incorrect LED bar state on the wall.
The only way I see the switch state properly reflecting the group is if I explicitly set the zigbee group entity to off. When setting all bulbs individually within that group to off, the switch state still shows ON. See my video of 3x pendants in a group below:
Any suggestion on how to resolve this? My WA could be to just expose the Zigbee group in HomeKit rather than the individual bulbs I guess, but I would prefer not to do that.
