The issue: Periodically, and seemingly randomly, my Inovelli switches get assigned group ID 163. Strangely, it's not all of them, but most of them. And it keep happening.
At first, I thought it might be a bad rule or something, but the two rules I'm using send setLEDEffectAll with the params the switch wants to change the light bar, nothing more.
I don't want to be using Zigbee groups at all
Logs don't seem to tell me anything as to why that may be happening.
Does anybody have any idea as to why these switches are grabbing a group ID? I don't want them as a part of a Zigbee group - when my garage lights turn on, I don't need my basement lights coming on...
I've definitely experienced this - it was REALLY bad when the Blues first released, but I've seen it since too.
My latest theory use that it happens (well, can happen anyway) any time you initiate a zigbee pairing.
I haven't had to do a pairing since the last time this happened (and that's when I came to my conclusion here), so I don't have any additional data points. But I also haven't had any unsolicited bindings since then either.
ETA - the most recent time this happened to me, I know I was on the latest Blue firmware (2.15), but driver was a version or two ago.
Interesting, my inkling was the same - it seems to reliably happen when/around when I add a new Blue switch (what I've been adding recently), though today I added a Zooz RGBW dimmer and it happened.
I just updated my hub today, and update the driver from 2023-06-01(MA) to 2023-10-14(MA) (latest as of today). I've got one more Blue to install, so I'll see if things happen again.
I had this happen again today, and it was due to a power pull (not ZB pairing as I suspected earlier)...
I needed to install a new outlet, so I pulled the corresponding breaker. When I restored power, I had the unsolicited bindings in-place again. It was definitely power related.
The strange thing is that the group # it binds itself to every time is an odd choice -- it's just the Activator device for one of my Room Lights setups, and it's not like that has just the Blues in it or anything like that. And that Activator device isn't normally bound to any Blue or any other zigbee device.
But it was this exact same group last time too, so at least it's consistent
And it's the same 6 (out of 9 total) Blues that bind each time -- they're spread across different circuits, so not all 6 lost power today when I turned off that one circuit.
The 6 Blues don't have any smoking-gun commonality I can see (so far anyway)... They have a spread of different serial#/EIDs and configurations.
It's very strange! But at least now I know to check for that binding whenever I pull power on some circuit. I'll also watch for it next time I have to pair a ZB device too, just in case.
Tagging @ericm for visibility... Eric, I'll keep looking for some kind of commonality, but this is a head-scratcher so far! I'm on latest fw (2.15) and driver (10-14) for all 9 Blues.
Thanks!
It's a headscratcher!... I confirmed it again this past weekend since I had to pull power on that circuit again for an unrelated project.
Whatever it is, I give it points for consistency -- it's always the same 6 (out of 9) Blues, and it's always the same Room Lights group activator that they all bind to.
That RL activator device is not normally bound to anything (Blues or otherwise) and the affected 6 Blues are not normally bound to anything.
I think there was some code added to the driver to automatically bind to a zigbee group that the switch is a part of, but I'm not too sure on the specifics. Might be related to that.
If so, I'd love to have the option to disable that capability... I'm sure its inception was well-intentioned (like Alexa's Hunches feature), but like Alexa's hunches often do, it's taking too many liberties.
Thanks -- looking forward to hear if @mark.amber has any additional thoughts or ideas too. Thanks again to you both!
I have not seen this behavior. Is it always group 163? I’ll have to try a few things and see if I can reproduce it. If you can make it happen, try enabling Trace logging (NOT Debug) and send me the log when it happens
This issue sure sounds like it’s related to that added code to auto-bind groups. That’s definitely where I’ll be looking … if I am ever able to reproduce it
The Hubitat Groups and Scenes app has a switch to enable or disable zigbee group messaging when the group is created. If disabled, there should not be any zigbee groups auto-created
Thanks Mark -- I appreciate the additional insights and dialogue here.
In my case, it's always the same Group Activator Device and same Blues (6 out of 9), but it only happens after a power outage/restore. I just checked, and I am indeed utilizing ZGM in that particular Group.
I guess my question here is -- why are Blues intentionally programmed to "auto-bind" to anything at all?
What is the point of that feature? I'm struggling to see any upside, since the only result I get is unwanted/unsolicited bindings.
ZGM is a very useful feature in bigger zigbee-heavy groups, so having users disable ZGM in such groups is an unpleasant solution to prevent these bindings. The right answer is to disable that auto-bind feature. Any chance of that happening?
I need to pull power on that circuit again this weekend for some other work, so I'll try to remember to capture trace logs for everything.
Thanks again for your time & help - I really do appreciate it, and wish you & yours a great Thanksgiving!
Because when there are multiple Blues in the group, they all turn on/off each other (and other zigbee devices) in the group, even when it's not the Group Activator calling the action.
When this unsolicited binding happens to me, I realize it because when I turn on/off any one of the Blues, all of the other Blues and other zigbee devices in that group then do the same action too.
So, in effect, each one of the corresponding Blues in that group is turning itself into the Group Activator Device -- hopefully you'll agree that is not desired behavior.
ETA -- this is eerily similar to the flagrant unsolicited bindings that plagued the Blues at initial release. In my current case here, it (thankfully!) only manifests after a power outage/restore, but it's still unsettling behavior to deal with.
ETA2: I'm planning to swap out a ZW switch on that circuit tomorrow, so I'll do my best to capture trace logs and other documentation.
ETA3: I have 2 Room Lighting groups that involve ZGM and multiple Blues, and the one Grp Activator Device ID# that keeps getting bound is one of those -- it's the one that has the most Blues in it (6 vs 3).
If you have switches A and B in a 3-way setup, you bind A -> B and B -> A and they mirror each other. Or you can create a group and bi-directionally bind the switches to that group and they all mirror each other.
In the group configuration, if any individual Blue in that group receives a command or is manipulated physically, that device apparently sends a corresponding group command which causes all the others to stay in sync. Same result, different approach. Obviously in a 4-way or higher setup, the number of individual bindings quickly gets out of hand, so the group approach might be preferable.
Here's the scenario that doesn't work at present. Let's say you have a number of switches that you want to control using a single group command. For example, I want to turn a lot of switches on at sunset, but other than that the switches are unrelated to each other, I just want to minimize zigbee traffic.
In HE, you can create a group and add those switches as members of the group. The Groups and Scenes app apparently calls into the driver for each device in the group, commanding it to add (or remove) itself to/from the group. It is NOT telling the device to bidirectionally bind to the group or initiate group messages, just respond to them. Group -> switch ONLY, NOT switch -> group.
But the driver, in response to the (presumed) "add/remove yourself as a group member" call is bi-directionally binding the device to the group. This causes all the switches in the group to control every other switch in the group. This is definitely unwanted behavior, and what I and others are complaining about
I don't have any non-Blue zigbee switches to test, but I would bet that they (or their driver) don't behave that way.
Possibly related but seems like a bug nevertheless: parameter 51. Device Bind Number always shows zero despite the label "counts one group as two devices."
Thank you for your excellent additional details throughout your post above!
The quoted part here is definitely true in my case... P51 always does stay at 0 throughout everything, but the relevant 4-digit Group Activator Device ID # shows up every time in Group Bind #1 for each of my 6 affected Blues (example shown below, since I've cleared that ID since last time).
Perhaps having an option next to each group ID for "respond-only" vs "bidirectional" group binding would solve the problem. Probably would need a firmware update though, I'm guessing.
This may also shed some light on the issue and explain at least some of the current behavior:
@mark.amber and @ericm -- I know this discussion got busy right at Thanksgiving, so timing wasn't great there, but curious to hear if Inovelli is looking a change to the bi-directional vs respond-only binding behavior for the Blues?
I'm not smart enough to know if that would be a driver thing, firmware thing, or both...
I think the code that automatically binds to a group that the device gets added to should be modified. It used to be a manual process, but I think @mark.amber made it automatic to simplify the process.
Thank you @mark.amber and @ericm -- I really appreciate your willingness to reconsider the automatic binding; it'll be a nice win to help protect against unsolicited binds.
-- it's always the same 6 (out of 9) Blues, and it's always the same Room Lights group activator that they all bind to.
