And the winner is... @waynespringer79. Getting rid of my (unused) dashboards did the trick. Hub is down to ~18% over the last 24 hours with all Sonos devices and all.
Thank you all for the very valuable suggestions.
In earnest I am pretty good at diagnosing issues but the dashboards angle was not even a possibility that crossed my mind.
This group rocks!
A pause is a temp thing used mostly when pausing another rule from another one.
Stop is more permanent or if you're working on a room that is likely to fire. When you're working on it you would want to stop it during that stage.
So... I spoke way too soon. A little over a day after the HE dashboards were removed, the Sonos devices climbed their way to the top overloading the hub yet again. I am now attempting to remove the SharpTools dashboards I have (which are the ones that are actually occasionally used) to see if that resolves the issue.
So... What has changed in 2.2.6 both at the core and at the Sonos integration level that would cause millions and millions of events to generate for each device and bring the hub load to a screeching halt?
There is also something definitely wrong with the math ontop of the device and app utilization statistics. Seems like 1172.3% load is not feasible for any environment to actually report.
The last message that I saw claimed that the HE database had over 80 million events in it and I'd like to be able to purge them all together as I have no use for state or event history for more than a rolling last 10 or so.
Is there a method that allows to schedule purge of events from the database or
Is there a way a reset events performance counters (and actually a reset of device generated events) without rebooting the device?? Seems like we should have more control on things that overload the hub when it comes to how it is behaving behind the scene.
I'll move the performance question / issue to a new post as I think the problem is more generic than just Sonos even if Sonos seems to be the trigger in this case.
From memory there is an option that is displayed from the alert screen on the database size, allowing you to adjust the global settings for events and attribute state history. I think that takes effect next time a database cleanup occurs, which may be during the overnight backup process. In my experience it seemed to take a day or two for it to fully reduce, but that could have been something specific to my setup...
I think there is a hidden page where you can change these settings when there is not an alert on database size, I'll see what I can find...
Here's the links to adjust the settings that appear on the database size alert page:
You can also adjust these per device on the device edit page.
Thanks. I did that but I'm not convinced it purged the 80million historical records vs. limit accumulation of future events. How often that the table prunes itself, how does one ever access all this history to begin with and are 80 million rows a reasonable accumulation for the actual size and performance of the hub altogether? At what point in time, the database or the hub get to a choking point or consume too much cpu attention at the infrastructure layer leaving less and less room for applications and devices above them to adequately perform?
What is the size of your database backup?
Averaged at ~4.2MB and after changing to 5 events / 5 states they dropped down to 2.4MB so definitely something was pruned, thank you.
Any views / comments / insights on the Sonos issue as I cannot really use any dashboard for my >15 devices without severely maxing the hub even at the global setting (validated on the individual devices) of 5 / 5 history.
I realize the devices expose a good amount of attributes and events and that some of the attributes are also long streams of data but they devices are idle 99.9% of the time at which it seems that activity should drop down to almost none - certainly for subscribing entities?
That's a reasonable size for database. As for Sonos, the integration needs some attention. I only have one and it's also a hog, but not to the point that my hub has any problems.
Thank you. Is there a way to open-source it to increase the team's bandwidth? It was never an issue until 2.2.6 so some other change must have impacted it...
I have a C-7 since last December still in the box. This may be the trigger to subscribe and migrate from the C-5, however, throwing more hardware at the problem is not necessarily going to solve the issue and is also bad practice overall.
I just found this thread and I'm having the same issues on a C-7 with sonos killing my hub. A reboot seems to clear it for a little while but it will eventually get totally bogged down in a week or so and throws warnings. I have 12 devices in Sonos so it's not a small system but it isn't what I'd consider huge either.
try disabling trackData in the preferences for all your speakers.
Done. I'll keep an eye on it to see what happens. Thanks for the idea!
Also have you got them reserved in your router? If they move IP that Muller's the hub, so fixing the IP is a good idea.
I have as best I can.
BTW, don't try to tell the people at Sonos that hard-coding IP addresses is important, they'll just ignore you and feed you some BS about how that's not a good thing for some reason. 
That's probably using static IP which can have issues if you don't know how to do it correctly. Address reservation is the better one as the router does the work, you've just saying to it always use this IP.
That seems to have done the trick! One week later and no load warnings. Thanks again!
What is the downside (if any) to doing this? Does it just not poll for track information if this toggle is disabled?
there isn't a down side, unless you're trying to capture a track url for some reason.
Download the Hubitat app
