edited: Never mind, I don't really want to get into an argument.
I'm glad they are working on it, and trying to improve it.
4 Likes
If you aren't going to spend every waking minute on your hub UI watching for new release notifications we're going to have to take your hub(s) away from you. The lack of commitment is just not tolerable. 
I've turned the setting off on all of my hubs. I rely heavily on hub mesh, with something like 70 to 80 devices on a C7 shared to a C8-Pro via hub mesh, and a smaller number of devices shared from the C8-Pro to C7. I haven't seen any issues w/any of my automations since turning the setting off yesterday. Things are "just working," and I wouldn't know that the setting had been changed if I hadn't done it myself. So my initial feeling is "Don't worry, be happy." 
2 Likes
Please! PLEase!!! PLEEEAAASSSEEE!!! Don't take my toys away. 
That's my motto in life. It drives my wife nuts.
2 Likes
SAME!! I just can't worry enough about everything to make her happy.
2 Likes
That’s almost exactly how my wife phrases it! Quite uncanny.
2 Likes
There's gotta be a class they all sneak off together to take.
4 Likes
Just want to summarize things for my understanding:
- This issue has turned out to negatively affect much more than originally thought (not just ESP micro controller being unable to handle this)
- The root cause hasn't been identified, but the mDNS restart is related
- Turning off the mDNS restart will keep it from happening, but may cause issues with HomeKit
Is that accurate?
Whats the difference between starting (I assume) the hub's mDNS service versus a restart? Hopefully the dev team is close to root causing.
The mDNS restart was the root cause for the large traffic spikes.
Case closed.
How else can this be explained? Its a system service, normally it starts on boot and runs. As a band-aid possible fix for HomeKit it was setup to restart every 20 minutes at some point in time (kill the service and re-launch it). We now have an option to disable the band-aid fix so that it just starts once at hub boot and then runs constantly, as system services are usually designed to work.
As for a real fix for HK without blasting the LAN with mDNS every 20 minutes, not sure. A few people have already reported no issues even with the mDNS restart turned off. So that restart may have been fix for a very small number of people that impacted everyone else negatively.
4 Likes
I guess I interpret things differently.
The restart shouldn't have acted that way. If the mDNS service was restarting properly, it would dump all its DNS entries and reinitialize the same way it does on initial boot up. The packet storms wouldn't occur if there weren't multiple cached entries from the restarts.
Agreed that restarting it was/is a bandaid for HomeKit. Its good that there's a way to make it stop. Hopefully I don't start having issues with my HomeKit integration, which has been working without a problem.
1 Like
Maybe there IS a packet storm upon initial start of the service? Anyone checked? If one time during hub startup, it might just be overlooked.
Just tested it, pretty insignificant. I started the capture before clicking reboot, the largest spike should be around when it booted back up.
I also have no idea what the mDNS "restart" actually does, if they are just simply restarting the service or some other procedure doing more than that. Whatever it is doing though, IMO is broken. Good riddance to turn that off finally.
Obviously restarting the mDNS via a hub reboot does not have the same effect as the Bonjour 20 minute restarts.
2 Likes
Tested on three HE hubs with HomeKit integrations enabled - no any issues since I switched the mDNS restarts off. 
5 Likes
Interesting new info that the mDNS start-up at reboot isn't "stormy," while the mDNS restart while running creates such a mess. In my feeble mind I would have expected them to have similar results.
4 Likes
