I’ve got 8 blue-series switches installed, and am trying to set up an “everything off” behaviour in Home-Assistant. In my experience, this works better as a Zigbee group, due to the multicast nature of the command.
I’ve created a zigbee group through the HA ZHA integration’s group setup UI, and added all the blue-series switches and zigbee bulbs to it.
However, now, activating any of the inovelli switches turns on every light in the group, including all the other switches.
What I want is:
Zigbee group of every zigbee light and switch in the house, to support multicast “turn off” commands
Each inovelli blue switch only turns on its own load, when commanded remotely or manually at the button
Does anyone know if this is possible, and if so where I went wrong?
Huh, this seems like a bug @EricM_Inovelli - I just tested throwing a couple random devices in a ZHA group and turning them on/off doesn’t affect anything else in their group. Add a Blue switch to the group and hitting on/off, etc now controls the other devices in the group.
In the meantime, you may be able to just group non-Blue devices (assuming none of the other devices do this) and then capture the Blue switches in your off automation? Not sure how many devices you’ve got at play here, I do something similar to this in Node-Red but it’s for all of my devices (zwave and zigbee) and it filters to only send the command to ‘on’ devices which has removed any issues I’ve had in terms of latency, etc from sending to everything.
Thanks for the reply Chack. Yea, I can make this work by just ungrouping all the blue-series switches and moving them to a home-assistant group instead. I think the only cost there is the missed messages when there’s a thundering herd scenario of off commands. And also the laser light show effect from all the differing latencies.
It’d be great if we could get some definitive “yes this is how it’s supposed to be”, “we never considered this, maybe we can change it”, or “oh no, that’s not how it’s supposed to be, that’s a bug” feedback.
I’m pretty certain this would count as a bug (or unintended feature? ) that likely should get addressed in a firmware update given it doesn’t appear to match up with other devices default behavior. My first thought was it was going to be something with the random binding issue, but that doesn’t seem to be the case at all and I can really easily replicate what you’re seeing.
This is definitely bad behavior and is not something you would want happening by default. If it isn’t binding I’d wonder if they start communicating to the group instead of the coordinator when added to a group (they shouldn’t but it seems like they are if binding isn’t the case)
@EricM_Inovelli confirmed another FW bug. When they are grouped they send group messages. They should not do this. They should only send data to groups if a user specifically binds them to the group. When they are members they should continue speaking to the coordinator and they should also listen on the group nwk address. They should not send on the group address. Lmk if this doesn’t make sense.
) that likely should get addressed in a firmware update given it doesn’t appear to match up with other devices default behavior. My first thought was it was going to be something with the random binding issue, but that doesn’t seem to be the case at all and I can really easily replicate what you’re seeing.