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.
It’s not a single occurance that is an issue, it’s a repeated or long running high load that you need to be concerned about (believe this is what drives HE’s indicator)
HE has 4 cores, so a load of 4 is an indicator that the hub is fully scheduled (running processes + waits); fully scheduled does not equal 100% busy
Understand your pattern - everyone’s app/driver mix is different, so determine your normal good pattern and watch for long running deviation
If everything is running without issue, is it really a problem if the load spikes a few times; i.e. if nothing is broke…..
The load reported is an average over the last 5 minutes, refreshing the stats every 1 to 30 seconds isn’t going to change the number in a positive way, give it a minute or 2 at least (the sweet spot seems to be in the 5-10 minute range for most)
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.
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.)
I 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.
FWIW, there are many more ideas in the documentation - each of the Helpers is designed to provide a simple means to accomplish common automation tasks...
I've hit a snag. I've gotten a couple helpers set up. In short, when I go to sleep, my hub receives a Maker API message, which turns on a "dad sleeping" switch. Ecobee suite sees the switch and changes the thermostat to a custom comfort profile, coincidentally named "dad sleeping," with a hold for 1 hour. "Dad sleeping switch turns back off. But the thermostat wasn't changing. Error in the log is:
I went in to the app code and changed the "isInteger" to "toInteger" and that solved the dad sleeping issue, the hold successfully took for the one hour. But then that messed up my "mode becomes away" to set the away profile. I don't remember the exact error and have already repaired the package, but it involved line 866 of the routines helper and "indefinite is invalid." After repairing the installation, the indefinite away hold when I'm away is working again, but now "Dad Sleeping" is throwing the above error again.
Any suggestions, or is this even related to the app code? If not, then I apologize for wasting time and will head off to do more research. Thank you!
That's definitely something I should have mentioned in the narrative. I had it set to 1 hour and have also tried 2.
I was curious why it showed the value as being what appears to be an invalid character. I've also tried copy/pasting a "1" from my text editor in case there was some stupid formatting being carried over, no change.
Sorry for the delay. I tried to apply your code last night on mobile while I was in bed, but couldn't get the window to stop jumping back up to the top. Just applied it via PC to no avail. Same error, except it specifies the "isNumber" now instead of "isInteger" with the same "[]" as being the value.
There's a clue though... I thought that was single invalid character sign, but that's actually an open and close bracket... I'll do some more playing around in the meantime.
