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.
Not sure if this helps at all, but I tried changing the hold hours to 12 and see in the logs that it at least properly records the number at some point, but apparently that value isn't getting passed along?
Update - More information
I changed the hold time to "2 hours" explicitly, rather than the "set number of hours" and got the following in the logs when I tried to activate the switch and routine:
Update again - Went back to rule machine to accomplish the goal. Rather than having it turn on the "dad sleeping" switch to activate the routine via Ecobee suite, I just send the custom command to change program with 1 hour hold parameter and the thermostat takes it.
I'm still down for tweaking code and changing things if this is deemed to be a bug and you need a test dummy.
I don't know if this is relevant for Universal Ecobee Suite (or anything non-homekit), but I thought I'd share this reddit thread I came across just in case. It seems that a recent update to the smart sensor firmware has exposed occupancy status to homekit, where previously it only exposed motion.
On a related note, when I'm looking at a sensor device in hubitat, is the 'motion' status actually checking motion detection, or occupancy? It seems to stay active for quite a long time, so if it is actually motion does the sensor only check for / report back motion infrequently?
Here is a reddit discussion about the timing/delay of the motion trigger and reset time for the ecobee remote sensors:
I dont use the motion reporting on them because it is not fast enough to make use of. The new presence option might have a little more logic in it, but these sensors deliberately do not update frequently to save battery life, and also to ensure there are no fast changes in the hvac system causing it to fast cycle/etc.
I have recently started adding better motion and temp/humidity sensors in rooms that already have the ecobee remote sensors to have more accurate readings for automation and averaging of live temperatures/humidity in vs outside of the house and leave the ecobee sensors to just communicate with the thermostat.
Yes the Ecobee sensors and the polling to get status doesn't make them a candidate for motion, but from a room occupancy perspective they work great for the room being "unoccupied" that is how I use them . I have rules for each room that has a sensor in it and if the room goes unoccupied the rooms scenes automatically reset. The same for Sleep or Away I use the group motion sensors app and created 3 groups, upstairs, downstairs, and whole house. So when downstairs goes unoccupied when it's evening or night outside I set sleep mode. When whole house goes inactive I set away.
As I always said use the strengths of the product and ignore the weaknesses.
I don’t think the API is returning any new information, just now the implementation is reporting the (relatively new) “occupied” attribute. I will look into providing both motion and occupancy, but it won’t be for a few weeks…
