Ah cool. Thanks for the additional info.
Not for Z-Wave.. With Z-Wave you run a network repair, which will take an amount of time proportional to the number of devices you have. When the repair is done, the network is rebuilt. (As a rule you should run repair 2-3x) Unlike Zigbee, Z-Wave isn't self-healing/self-routing (technically discovery frames kind of implement this), so when the repair process says it is done, it's done.
Zigbee much more dynamic. There's no repair process that you can run on the hub. It's self-healing/self-routing. How long it takes for a Zigbee mesh to recover following a shutdown of the hub is again fully dependent on the quantity and type of devices on the network, if the Zigbee channel changed, and even how long the hub was offline.
The official guidelines I've seen suggest 24-48 hours.. But the reality is, the network is usually fully functional within the first few minutes bringing the hub back online, but there will be a lot of background traffic as route discovery between nodes takes place. This is the process that can take a day or more to finally settle down.
2 Likes
Correct. Z-Wave repair/heal/optimize (whatever the chosen vendor is calling it) initiates the neighbor discovery and update to rebuild the routing table on the primary controller.
Z-Wave Plus is a self-healing environment that uses explorer frames as a last resort when a node is not in the route table received from the controller. This will slowly rebuilt the routing table if a heal is not performed. Explorer frames are only within Z-Wave Plus and if it's a mixed mesh of non Plus devices this will not work correctly.
It's always best after a remove of a device to run a heal/repair/optimize to rebuild the routes. It's not absolutely necessary after adding a new device and should never be necessary just because of a hub reboot/shutdown as the routes are the same and did not change just because the hub was rebooted/shutdown.
1 Like
But if it's not all done, then the impression will be it's not done, so as you mentioned, that's why the guidelines are 24-48 hours or "a day or more" 
The wisdom in the area that is much greater than mine, suggests that repairs are useful regardless of Z-Wave or Z-Wave Plus.
This kind of info should be shown to all newcomers to Home Automation.
2 Likes
@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.
@mike.maxwell would it be possible for this below to be involved?
A change was made to the event processor in the hub. It was found that some hubs can send so many events that the processor is overloaded and the hub will stop processing events. This processor has been reworked and there is now a limit to the number of events that can be sent to the processor at one time (1024), if the event queue goes over the limit an error message will be thrown and the system will log an error “Limit Exceeded Exception, Event Queue is Full”.
no, unless the OP reported seeing this in his logs:
Limit Exceeded Exception, Event Queue is Full
And AFAIK that wasn't reported...
Imperihome used to connect locally to the Vera, but the last time I tried it, you have to create an Imperihome cloud account, which you then give credentials to so it can log into your Vera via their cloud connection service. I didn't feel comfortable putting my Vera creds in the hands of someone else. Is it still like that?
OFF TOPIC but since you mentioned this !
Finally, a reason to dabble with a few bulbs. Switches for groups of bulbs made sense to me, an array of individual bulbs not so much. ...But... a few key bulbs to be "in my face" when some condition of concern is met, now that's useful (and probably "old hat" for 80% of the folk in the Community) 
What does this mean? Please provide some specifics.
As Mike said, there were no changes at all in 2.1.9 to Groups.
@bravenel if you have questions about the specifics that I wrote in the post I linked under the text you quoted, it would probably make sense to be more specific about what you want to know and post the questions there...
When I started this thread it was intended just to complain in a generally way.
The post this relates to this problem is here. Suddenly Inconsistent and the answer is:
No, I did not report seeing "Limit Exceeded Exception, Even Queue is Full" because I did not know to look for it until @waynespringer79 post. I will tonight (I wonder when the logs rotate...) and follow up on Suddenly Inconsistent.
Ah, so this isn't really something about Group at all.
The Limit Exceeded Exception has to do with certain types of devices that can basically spam a lot of events, so it's probably not related to your problems.
I'm not sure I see what you mean. The root of cause here might be The Limit Exceeded Exception (TBD) but it is interfering with the Group functionality. Wouldn't that make it "about Group?"
Well, no. If you have a device spamming your hub, that would not have anything to do with Group. That would have something to do with the device or its driver.
2 Likes
While I 100% agree with you, there's no sensor that can actively determine when I'm in the bedroom and want the lights to go off so I can go to sleep--or not, because I'm reading or folding clothes or whatever. So dashboards and a fast UI for them become critical.
Or a simple button.
2 Likes
You don't use toasters or microwaves? 
While I get what you're saying, it totally depends on the use case.
1 Like
Sad huh? I need 4 sets of those sensors too. 
I agree that there are cases that don't automate smoothly. For me, Pico is the answer. It's true that I have Echo's everywhere that have a Pico, but none of us here seem to find that faster than a Pico in an an extremely handy spot.
2 Likes
We have a lot of picos, but for some reason every time we put them in the bedroom they disappear/get lost. Just a practical life thing for us. And while we do have voice response in the house we've declined to let people listen in the bedroom 
This does lead to good laughs when we get spam claiming to have video of us we wouldn't want released. If someone were capable of p0wning our cameras, they could only release camera footage of our dogs asleep on their beds
1 Like
