Saves your settings, same as most other buttons with "update" in the name, some of which have been modified to make it clearer exactly what you're updating. (I'm looking at you, Z-Wave radio firmware--or more often not, as the case was).
Ok thanks. Still curious as to what it actually does (at a high level) to accomplish that. I have that issue (failure to pair devices) with non-migrated C-8 (haven't tried yet with .109).
Evidently 'Rebuild Network' option doesn't fix (or maybe isn't intended to?) scenario of trying to rejoin a device that has been previously joined.
Just tried this with a sucessfully joined GE Zigbee dimmer after updating C-8 with .109 and got the same reset/join failures I've described elsewhere for C-8 and C-7 on .105 releases.
After pushing the 'Rebuild Network' button; device still doesn't work (and sniffer still shows the recycled device ID hasn't changed). The plug and hub are both broadcasting, appear to be occasionally exchanging data but device cannot be controlled. Haven't tried with .109 but I assume 'Remove Device' would allow it to join and work normally.
I was headed out of town as those options were added to the beta, and I was curious if anyone was going to ask how they worked there (but no one did AFAIK) so I'm grateful you and kahn asked here!
I too would love to eventually get more details on what those options actually do (routine maintenance or more of an emergency-use-only kinda thing), and general thoughts on plus/minuses of using the "Rebuild on every boot" option.
But I know the HE crew is still chin-deep diagnosing other zigbee stuff too, so I can wait -- this all appears to be a step forward in that overall solution, so that's welcome progress.
Don't know, but pressing rebuild only caused both of my Hue Outdoor Motion Sensors to stop reporting anything at all. Frozen on "Active". Re-pairing didn't fix it, but haven't played with them beyond that.
I noticed if I hit Configure on the frozen motion sensors they show up briefly in the route table and then quickly disappear again, but all values in Current States remain frozen in time. Pretty sure I will need to remove and re-add them. Re-setting them and re-pairing (letting Hubitat find a previously paired device) doesn't jog it.
My Child Data section is back to blank -- it has historically always been blank like this, but after the C8 migration and up until v109, I had 1 or 2 odd-ball entries in there that made no sense (but I don't have a screenshot), so maybe this is good ¯_(ツ)_/¯
Haven't had feedback on what I've posted from folks that would know, but I started a thread where I posted at least one effect: 'Rebuild network' purges the neighbor hub's neighbor table, which otherwise would continue to show neighbors that aren't even powered on anymore. Doesn't solve the problems I still see with reset/rejoined devices however.
My C8 has that problem. I have messages with support. All of the migrated C8 don’t play well with Zigbee pairing. It’s an attempt to try and rebuild/resuscitate Zigbee.
Ok but nothing has come from support and even your description is not clear.. ie is it existing originally migrated devices that wont re-pair or wont reset and re-pair or new/ never migrated devices that wont pair? Or both etc and what is the option in every boot for? If its to fix up an existing zigbee network why do we need to do it on every boot? Maybe the routes are rebuilding wrong after every boot? If so why cannot that just be fixed and that appears to have nothing to do with pairing?
My hypothesis on what is going on in relation to these new options and what ive read is that the new zigbee radio is stronger so you get many more direct to hub routes but when these routes don't work the re-route is failing due to incorrect or null ids being used in the new route and this is why we are seeing devices drop off the net. Ie the new route is wrong/not working . This is also why we see it more with the c8 i e most routes are initially direct with the new stronger antenna/ radio but subsequently need to be in reality redone.
And these new options therefore are meant to rebuild the zigbee routing table. And maybe the zigbee routes are rebuilt on every reboot?
As for people unable to re-pair existing devices it appears from what I've read it is only devices that were previously paired ... if so my only hypothesis is that it is still remembering this bad route and trying to use that when doing the re-pair. Otherwise i have no idea.
That would also jive with what I've read that totally resetting the device and remove the device/driver as a workaround. Which should remove the routes or you use this new rebuild option to force remove them.