For context, I do have a very large home (>6,000 sq ft), but I should have a strong zigbee mesh with many repeaters located within and outside the house. For the last couple years, I have had good performance from my mesh, and it has declined pretty badly over the last couple months. I did find that some of the repeaters were unplugged, which I thought explained the performance drop (and probably did to some extent). However, after plugging the repeaters back in and allowing the mesh to rebuild, I have serious problems.
My front porch lights (31 in total), which have three outdoor repeaters in close proximity, and six indoor repeaters in close proximity do not function properly. They do not all turn on or off as commanded any longer. They also often report incorrect status (reporting off, when they are actually on)
First symptom speaks to mesh strengh -- which is that not all lights turn on or off when operating as a group (I do have group messaging enabled)
Second symptom speaks to something that does not seem to be mesh. I can turn most of the lights on / off individually. However, when I turn one of the lights off individually, almost all of the remaining outdoor lights (inexplicably) turn on. I do not have an automation that is triggered by turning off this individual light.
Any advice on what I can to resolve this? It used to work perfectly. I even added more repeaters (innovelli switches) close to these lights, and I am still getting horrible results. Attaching my mesh graph.
If so, they had an issue with unsolicited bindings getting set up with other zigbee devices when power was pulled/restored. That issue was supposedly addressed in the latest 2-1 driver version (2023-12-22), but I haven't pulled power on any of my circuits since then to verify. But that unsolicited-binding bug definitely bit me previously.
Check the parameters for each Blue to see if you have any unsolicited bindings -- if so, remove them and then make sure all Blues are on the 2023-12-22 driver so they don't come back.
Am at office, so no ability to capture screenshot.
Parameter 51 is a read-only value that may indicate if any bindings are set up -- but for me, that was hit-or-miss -- in some cases, 51 read "0" when I had unsolicited bindings, in other cases, it was some positive integer.
On a Blue's Device page, there are 3 entries for Group Bindings toward to bottom of the Preferences -- those should all be blank unless you have an intentional binding in-place.
For all of my unsolicited bindings, there was an entry (e.g. 5116) in at least one of those fields. Just remove it, and save -- that should take care of it.
I think the issue may be with Zigbee group messaging. My mesh is strong, and I can control each device individually. However, when I was turning off lights individually, I would have this one problem -- I finally turn off the last remaining light, and when I do so, a number of other lights turn on. There is no automation to turn these lights on. When I repeat the process of turning lights off individually, this cycle repeats.
So I deleted the group with all of my driveway lights, and turned them off individually and I was able to do that (not what I want to do of course, but seems to be evidence the issue is with Zigbee Group Messaging).
Additionally, I am observing issues with Zigbee devices providing the correct status back to Hubitat. For example, there are lights that never seem turn on or off as a group. When I check them individually in Hubitat, they show a status of being 'off' for example, but they are really on. When I try to turn them off, they won't because Hubitat believes they are already off. What I have to do, is turn them on, then I need to hit 'refresh' and only then can I turn them off.
Hope this additional context might help us better troubleshoot. As always, I appreciate the help. As a long-time user, I have dealt with Zigbee issues, but none quite like this. My lights used to work perfectly. @support_team@mike.maxwell
When you operate each of the group members individually via the commands on the device details page, does the status of each of them update correctly?
And when operated physically, is the status in Hubitat correct?
No. As an example, each light fixture has four lights. One of these light fixtures as two lights that are on. When I check status in Hubitat, it shows that all the lights are off. I can turn the light off, but here is the procedure I need to take -- I need to turn it on (again), and when I do, I can see the light bulb getting the instruction (as it kind of pulses when doing so), and then I can turn it off, usually. Sometimes it doesn't turn off, and I look at the status, and it isn't updated -- in these cases, simply hitting 'refresh' does the trick.
In the above example procedure, I cannot begin the process by hitting 'refresh'. I I do so, the status doesn't update as it should. I need to turn the bulb on, and then I can either turn it off or I need to hit refresh before turning it off.
Providing a link two videos which show the issue -- one showing the device details pages for two bulbs in a light fixture (I was able to replicate both examples described above -- one where I turn the device on again and then off, and another example where I turned on again, had to hit 'refresh' and then turn off) and another video showing the lights, how they are 'on' despite showing a status of 'off', and how they pulse when Hubitat seemingly reconnects when selecting 'On' from the device details page.
I also have 1-2 lights that like to do that also ..
Turn them on from the dash and it will turn on / off the light .. but will not show status as on / off
I also have to do a refresh or try a few times to get the dash and the light to sync.
here is the one that does it the most.
So just a note .. I was able to "fix" a few of my problem devices by re-adding them to the hub.
Since readding them they seem to work faster and better.
And now the dash board sync's with the device on/off commands.
Not sure why this works .. but did in my case.
