Hmmm....that would indeed explain things. I'm pretty sure that cpuPct : 219.25 is an overstatement!
Perhaps @bobbyD can comment as to whether this may be a "false positive", given that indeed Ecobee Suite Manager spends a LOT of time waiting (almost all Ecobee API calls are asynchronous HTTP Gets and Puts).
I am also once again getting the severe load. I put the ESM back on with 1 thermostat less than a week ago and getting this error again. I rebooted my hub and it goes away for several days then comes back.
Unfortunately I cannot replicate these issues on any of my Hubitat setups. Given the collective input, there may likely be more than one issue:
Probably best if each of you submit a problem report to Hubitat Support, so that @BobbyD can track them (he knows how to find me 
)...
So weird because I literally did this on an untouched, brand new hub.
One left-field idea: does Hub Mesh consume a lot of resources? I ask because, to make ESM work, I had to mesh access a bunch of temp sensors, vents, etc.
Both of my homes use ESM running on a separate Hubitat hubs than that which has all my Zwave/zigbee devices and automations. I also use Hub Mesh, though MOST traffic is FROM the secondary server TO the first (ES devices, SONOS speakers, Echo Speaks devices, and more). And like I said, I can’t recreate the issue.
Both my secondary hubs have been running for 8+ days since the last reboot, running multiple ESM Helpers, and the only warning I get is the occasional DB oversized warning.
YMMV, of course…
Can you help me understand this better? If ESM is running a separate hub (just like I do!), then don't you have a bunch of devices coming INTO that hub to support the helpers? Sounds like you're saying more of the Mesh flow is the other way.
I'm currently running very simple ES Helper automations. I USED to run a lot of vents and stuff, but in my new home this isn't part of the setup. Most of my Ecobee Suite automations are for changing programs when location mode changes (or the cleaners/home watch providers arrival/departure), and changing thermostat modes based on outdoor weather.
FWIW, I have also found that you can Mesh the thermostat(s) and sensor(s) to another hub, and then run most Rule Machine automations against that instance - the Mesh magically replicates the command calls (for the most part) over to the secondary hub. I haven't fully tested Ecobee Suite, but SONOS devices and Echo Speaks devices work fine on the "primary" hub, with the native support running on a secondary hub (I basically run ALL my cloud-interaction services on my secondary hub).
I also Mesh devices from my secondary hub over to the primary, so that the primary can reflect those devices to the Amazon Echo Skill, expose them to IFTTT and various other cloud services that limit you to connecting to only 1 hub...
Can anyone recommend a cpuPct threshold (or other metric available from the Hub Information Device) that I can use to tell if my hub is experiencing performance problems? I'm envisioning writing a simple notification rule: If [hub-perf-problem], then notify me. Just not sure what criteria and threshold to use for hub-perf-problem.
Figure if the "Severe Hub Load Detected" is a rough indicator, I wonder if one can use Hub Info metrics as a better indicator? Maybe I should be posting this over there....
Not sure where HE has their threshold at, but a few general thoughts that may help you determine where you set your warning.
Think I’m going to copy this to the Hub Info driver thread
FWIW, I look at the Live Logging for ES Manager whenever I'm concerned about the performance of a hub. The log entry at the end of each cycle tell you how long it took to complete the cycle:
2021-06-13 09:58:17.386 am [trace] Updates sent (231 / 4066ms)In this entry, it took 231ms to transfer the updates to each of the changed devices, and 4066ms for the complete polling cycle (including asynchronous waits for responses from the Ecobee servers).
For 3 thermostats and 12 sensors, my cycles usually run 2.5-5.0 seconds. when running 1 minute polling frequency. If the cycles exceed 5 seconds (5000ms) consistently, then I know that ES is competing for CPU resources and something might be wrong.
YMMV, based on the hub version you are on, your polling frequency, your chosen display precision for temps (etc.), the number of thermostats and sensors you have, etc.
FWIW, I have optimized this cycle time over the past 2 years since moving to Hubitat (I didn't worry too much on SmartThings, because CPU was "virtually unlimited" on their cloud platform). When I started optimizing, cycle times would rarely be less than 9-15 seconds (peaking at over a minute - that's why the code checks to see that the prior poll was completed). This high CPU load caused havoc on my Hubitat hubs - I actually was running 5 HubConnected hubs for a while there just to ensure things like ES Manager didn't slow down (or break) my Z-Wave and Zigbee devices and rules.
So, if your ES Manager cycle times get way out of your normal range, then somethings is probably wrong. And if not, things are OK, and/or ES Manager probably isn't causing any problems you might see.
Oh, and I guess 219.5% CPU load isn't out of line for a 4-core processor (the max should be 400%).
I'm having the same issue, the Ecobee suite is taking up a lot of my C5's time. seems to lock it up from time to time also. Any idea or update?
I think for now i am going to uninstall and watch and see what happens, i don't run all that many automations, just want it to show on the dashboard...
I do have a general recommendation that may help some people: for each ES Device (thermostats and sensors), make the following change in the Device Page:
Event history size, per event type (1-2000): 30 (default: 100)
State history size, per attribute (1-2000): 10 (default 30)
You might also want to do this for any other large-data devices you may have (e.g., Echo Speaks, weather stations, SONOS, BOND, iAquaLink, Ring, etc.). Reducing the memory/persistent storage demand does seem to make things run a bit more smoothly.
Also, if you are running any automations against Ecobee Suite devices (Helpers, Rule Machine, or WebCoRe), I strongly suggest setting your cycle frequency to 1 minute. Counter intuitive maybe, but this spreads out data change handling over time, instead of having to deal with 15 minutes worth or changes all at once.
And as mentioned above, if your cycle times (as seen in Live Logging) are running less than (say) 5-10,000ms, then your problems are quite possibly elsewhere, as the cycle time is directly related to the amount of CPU processing available to Ecobee Manager.
Barry, this was super helpful guidance, thank you. I watched my cycle times over the past couple weeks and they (the complete polling cycles) are routinely in the 6-11 second range for 3 thermostats and 3 sensors @ 1 minute polling frequency, and precision of decimal display set to 0. I submitted a formal support request to @bobbyD and got one of those standard "it's been referred to engineering" responses and that all further emails will be ignored. So, guess there's nothing I can do.
Weird, cause I'm running nothing else on this hub other than ESM (except hub mesh).
You may want to change the bottom one to 11. As I recall there was a thread where it was explained that anything 10 or below was essentially ignoring the hourly database clean up and trigger cleanup immediately to trim old records. This was causing sone folks extream impact.
I can't find that thread - can you point me to it?
It's been in several in responses to individual questions within several threads. General recommendation is not to use a value less than 11 because, as @mavrrick58 noted, it causes an immediate cleanup each time an event is added. (Also read where this is slated to change when 2.2.8.x comes out.)
OK, indeed it is recommended to set these both to 11. This can be done globally, for all devices on your hub, using the following commands:
http://<hub-IP>/hub/advanced/event/limit/11
http://<hub-ip>/hub/advanced/deviceStateHistorySize/11I have a pretty basic question. I've installed the Ecobee Suite 1.8.01. Everything is setup.
I'd like to see an example using RM to have the AC turn itself OFF when a certain sliding door is open for more than 5 minutes, and to resume the normal schedule when the door is closed again for more than 5 minutes for example.
Thank you.
Is there a reason you don't want to use the helper app for contact sensors that would do that exactly.
Was looking for some idea of where to start. Thanks for that.
Download the Hubitat app
