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