@michael.l.nelson you are right. updates break things! this sucks!
1 Like
FYI, Sengled bulbs are not repeaters, so adding more of these (unlike most directly or indirectly mains-powered devices--not that I'd generally recommend bulbs for this purpose anyway) won't help strengthen the mesh. In fact, because the hub has a limit of 32 directly-connected "end devices" (i.e., non repeaters), if you have a lot of Sengleds (or Zigbee end devices in general), it's actually quite important to have repeaters to extend the network's total device capacity, regardless of range (though if that's the issue, that will undoubtedly help here, too).
...so given the above, these outlets are indeed a good idea. 
I'm not sure how you determined how far away you could place them; if you're going with theoretical Zigbee range, I'd at least look at RSSI or LQI from Zigbee logs (or possibly a repeater driver if any you're using expose these as commands or respond to them) rather than relying on that. Especially Zigbee, more repeaters can rarely hurt (and regarding the 32-device thing above, keep in mind that each repeater also has its own limit, often far less--I think I've seen people say around 4-6 for some devices, though I've seen ones like the SmartThings 2018 outlet with a few more and special-purpose devices like the Xbee with even more).
Unfortunately, because you changed two variables at the same time, it's hard to say exactly what may have caused this. Zigbee bulbs directly connected to Hubitat have always been a bit difficult in my experience if you have a large number of them and send commands to lots of them around the same time without using group messaging (an option for Groups in Groups and Scenes)--one reason I went back to a Hue Bridge after a brief experiment. Clicking "Done" in the each group app shouldn't be necessary but certainly can't hurt for troubleshooting. Moving now-problematic bulbs back to their old locations (and waiting a bit for them to find good repeaters--something you might also want to do in their current/new location if you attempted to control them right away) also couldn't, but since you really do want them there, finding the real issue--mesh or otherwise--would obviously be better.
Good luck!
1 Like
I determined how far I could place them by using only 1, placing it far away, and seeing if it worked.
Sorry, nothing special.
Well I'm experiencing this as well all of a sudden. I'm also using Sengled Color Bulbs in my Group and on 2.1.9.114 as well.
In my case all I have connected to the hub and powered on atm is 3 RGBW lights(2 Sengled Bulbs and their light strip). Hub is setup about 5 feet from the devices as well.
Using groups is very much inconstant. It's anyone guess as what the lights will do.
Never mind I think I fixed it.
Had my bedroom lamp group(bulb 1, bulb 2) sub nested into the Bedroom group ex: (bedroom lamp, led strip) which I don't think hubitat likes. Grouped all the individual Sengled devices into the new Bedroom group as(bulb 1, bulb 2, ledstrip).
@srwhite HE documentation says, "24 hours." But we are only a few hours away from 48 so I can easily see if the problem has fixed itself by tonight.
You may have overlooked...
Now that you know, how long do you think it would take to heal a mesh with a depth less then 2?
Furthermore the reconfiguration I did was to move 2 bulbs from the edge to near line of sight with the hub and add 2 bulbs within line of sight with the hub. Then the problems I experienced involved EVERY SINGLE group, including those that would be on an entirely different side of the building and thus hopefully not effected by changes. Pretty sub par if a change like this can take down the entire network...
These problem occurred after the update (yes and adds & moves), continued after the reboot "for optimal routing", continued after the 10 hour shutdown, and now only those groups I have rebuilt are working....
Would you like me to let you know tonight if this was clearly a mesh issue? Do you suggest I wait an additional 48 hours after the last time I turned the hub on before we can eliminate the mesh as the source of this problem?
We should probably pursue this in that thread though... re-posting there.
Huh... I am also using nested groups... IE
{{{overhead1}{overhead2}overheads}{desk1}bedroomLights}
The groups and subgroups worked before the update...
Let me ask you a more basic set of questions..
-
If you control the devices individually, do they respond consistently each time?
-
Are you using Zigbee group messaging in the Groups app?
If the answer to both is yes, then you have a mesh issue.
Zigbee group messaging is essentially a multicast. The hub sends out a message addressed to a specific group ID.. Each device that receives the message, processes the message, and if it's a routing device, forwards the message to all of the neighbors in its route table. The process repeats itself until the message propagates throughout the mesh.
There are no communication re-tries if a device fails to receive and/or act on the message. The device either gets the message or it doesn't. So device responsiveness/control issues arising from the use of Zigbee multicast are almost always an indicator of a weak/poorly performing mesh.
I see you are using nested subgroups.. If I am reading your post correctly, you have 5 nested levels of groups. If you have all of them enable for Zigbee group messaging, then you're creating a broadcast storm on your mesh, since all of those groups can potentially each cause a multicast message to be sent.
2 Likes
Actually it turned out to be zigbee group messaging with both nested groups. Removing the one subnested group took care of that. As @srwhite mentions it created a broadcast storm which can overload the devices with messages. I have a feeling Sengled devices are prone to this anyways.
1 Like
Hmmm... I may have group messaging turned on for one group or subgroup but certainly not all...
I hadn't experienced anything I would name "popcorn" so I had it on for a test group to try to see what this feature did. The documentation was a bit... brief. Groups and Scenes - Hubitat Documentation
Not 5 level nested...
There are 2 bulbs in a group called Overhead Lights.
Overhead lights is a member of Bedroom LIghts.
Bedroom Lights is member of House Lights.
zigbee group messaging...
In order for this to work, the short zigbee address is required...
The group app knows which devices from the selected group members are zigbee...
Each group instance creates a unique group id.
When the app is saved the zigbee devices that were unselected have that group deleted, new and existing devices have the group set.
When the group receives a command the zigbee group version of the command is sent, all other devices execute the given schema command (on/off/setlevel whatevs...)
So, if the same zigbee device is included within multiple groups that are then nested, the same command will be broadcast multiple times...
That’s what I was hinting at. He’s creating a broadcast storm. And since bulbs are generally regarded as lousy repeaters my money in on this.
2 Likes
Let me try to pull this together in one place.
@waynespringer79 @bravenel @mike.maxwell have been chatting this up in my general complaint thread. There is a suggestion to look for "Limit Exceeded Exception, Event Queue is Full" logs
@srwhite seems convinced my bulbs are acting as repeaters although everything I read says they dont. But @mike.maxwell seems to think recursive broadcasting through subgroups is a problem. I suppose this is the same-ish as the LEEEQF problem?
So first things first. Since it has been well over 48 hours for the mesh to heal, when I get home I'll see if things work. I don't expect them too.
Then I'll look for "Limit Exceeded Exception, Event Queue is Full" and if I see them we can start to address that.
If I don't then I am going to start to rebuild my groups (with nesting) but without Group Messaging.
If that doesn't work I'll try not nesting groups.
Am I missing anything?
I assume by "patching" you mean a new platform update? As a general rule, we aren't "patching" things. And also, as a general rule, updates don't break things. That's not to say that from time to time a bug can't be introduced, but this is the exception, not the rule. There is a common phenomenon that some users tend to blame an update for breaking things that have nothing to do with the update. It's usually pretty easy to tell, just roll back to the prior build. If something is broken in a new build, and not in a prior build after a roll back, we will certainly dig into the cause post haste. I haven't seen anywhere that you rolled back to confirm that your problems stem from the platform update. That would be super useful information, as opposed to unsupported presumptions that the cause of your problems is an update that didn't touch the system elements that you have issues with.
It seems to me that Limit Exceeds Exception is a total red herring for your described problems.
2 Likes
I don't think the diagnosis is unwarranted in this case. As I've said. I added 2 bulbs to the system (of a type I'd used before.) Moved 2 bulbs a trivial distance. And applied a platform update.
It's not a crazy assumption to make, especially after my elsewhere mentioned experience with HE putting into production a pretty buggy subpar dashboard.
Another common phenomenon is that developers think all issues are first PEBAC and hardly every on their side.
Anyway, I'll look into rolling it back and applying my backup configuration files. Lets see what happens =)
What's wrong with the dashboards? I've been using 10 different Dashboards for over 10 months now and haven't had a single issue with any of them aside from still not having battery % displayed on the Lock tile after repeated requests.
2 Likes
Except it's not a diagnosis at all. Roll back to 2.1.8 and see if everything works that doesn't now work. That would be a diagnosis. If that is the case, as I said, we would dive in to find out what could have caused that.
What bugs in Dashboard are you referring to? I didn't see where you had reported any, or referred to any reported bugs. There are a couple of recently reported bugs in Dashboard that we're looking at, but there are thousands upon thousands of dashboards running with no reported problems.
If you look into the history of Hubitat, you will find that we are quick to admit when there are problems or bugs, and generally quick to fix them. We welcome genuine bug reports.
11 Likes
Listen,
I don't enjoy getting caught up in the nuances of word choice patching/updating or how specifically you judge my diagnostic effort.
I have not outlined the dashboard problems explicitly yet, and it feels more and more like a thankless task. Feel free to look through the Underwhelmed thread though if you want a general sense of my problems and some that other people express.
I am not sure how to look into the HE other then these forums. Is there a github style issues? I can look at my history and it does not feel great to me.
I just rolled back, it fixed my issues a lot of witch are the same as you and several others described.
Now when i have time i will do more digging as to why i had issues and how to trouble shoot and narrow down the culprit.
