Did you find out why your station went offline?
Yes, I have a tempest weather station and I updated a few things on my NAS and one of the docker containers I run that makes the connection between the station and hubitat wasn’t working right. Had to restart it.
Going back to the performance question. I just upgraded to a C8 Pro. Since I installed it has been reporting an elevated state. I have three Ecobee's, two sensors, no helpers (although I do plan to start exploring these). Polling is set to 1 minute. Running 1.9.00. I am not experiencing any issues with performance or responsiveness, so this error message could be a red herring?
1 Like
Same here, elevated and severe, and Ecobee Suite Manager is on top by all three params.
Gosh, I wish the built-in app knew how to sync comfort settings with modes, I really don't need anything else from this monstrosity...
1 Like
Ummm...not for nothing, but have you considered that maybe there's something not quite right with the new C8 Pro platform? It's supposed to have a more powerful processor, so why would ANY application use MORE CPU time than on an older platform? Especially one that has been running FOR YEARS, and hasn't been changed since the release of the C8 Pro (it shouldn't need to be changed, BTW).
I run Ecobee Suite on a C7 supporting 1 thermostat and 9 sensors and 5 helpers, and it doesn't report "heavy load" EVER. Another instance is on a C5 with 3 thermostats, 5 Helpers, and 11 sensors - again, no heavy load reports. This alone would point to the problem being in the C8 Pro hardware and/or software...
Perhaps you should report your issue to the Hubitat folks - they may still have some tuning to do for the C8 Pro that will stop the heavy load reports.
And FWIW, the total load "Local Apps" load of 7.4% might indicate that you wasted your money on the C8 Pro. What was the load on your prior system?
Also, you really should make sure that you are:
- running the latest version of Ecobee Suite (the latest version is NOT "1.9.00")
- running the latest Hubitat software - especially when running on a new platform (your alerts are telling you there is an available update)
I am pretty sure that the Hubitat folks are still tweaking the code for the new platform behind the scenes; this "problem" may already be fixed.
Finally - there is a built-in fix for Ecobee Suite: in Ecobee Suite Manager preferences, scroll down to the bottom of the page and select Remove Ecobee Suite Manager.
2 Likes
Sorry - I should have been clearer on my original post. Since Hubitat doesn't actually tell you what is contributing to the elevated load I have no way of knowing if Ecobee Suite Manager is the cause of it.
All I know is when I went into the app stats the Ecobee Suite Manager is consuming 40% of the busy time. However the busy time as I read it is only 7.4% of hub uptime - so should I even care?
Also, ecobee suite manager is consuming the same percentage overall as it did on the C5 that I upgraded from. So far I am not seeing any issues with the C8-Pro other than the UI is quicker - which one assumes it should be with the faster processor and more memory.
Since my diagnosis tools are limited, my real question is whether I should be concerned about the Ecobee Suite Manager consuming 40% of app time or not. There are plenty of other things that could be leading to elevated load which I continue to investigate. So not pointing fingers at Ecobee Suite Manager - just trying to figure this all out. Thanks
1 Like
Oh, that's a surprise. According to HPM, it is 1.9.00 (except for the Thermostat driver and Smart Mode app). According to the GitHub page, is it also 1.9.00? What do I miss?
I don't think any application uses more CPU. "Elevated" and "Severe" loads were a constant on C7 and C8 as well, that's why I always upgrade as soon as new hardware is available, hoping more powerful hardware will solve the problem. So far, no luck.
According to support, my number of devices and apps should be any problem for the hardware.
And I second @simon4's sentiment, regardless of how much total processing time my total 156 apps are consuming, a quarter of them (in my case) is Ecobee Suite Manager.
Consider: 40% of 7% is 2.8%! This leaves 97.2% of the available CPU time to OTHER APPLICATIONS AND DRIVERS!
Ecobee Suite Manager collects updates on over 300 attributes every 60 seconds, from a server that sends close to 15K worth of data (for a full update request) in 8-10 "packets" (without marking which specific attributes have changed within each packet). It has to maintain 2 full copies of the full data set (last and current), do compares to determine what changed, then format the data appropriately. It's a LOT of work, but even then it generally completes an entire poll cycle in LESS THAN 5 SECONDS.
This means it is running about 7% of wall clock time - and apparently that uses less than 2.8% of CPU time!!!. So a little more than 4% of the elapsed time is WAITING FOR SOMETHING OUTSIDE OF THE CODE'S CONTROL!!!
Look guys:
- it is what it is
- over the past 7+ years, I have optimized this code tremendously, while providing access to read AND MODIFY practically every single attribute of the thermostat
- I'm pretty sure it runs a little faster on the C8 Pro, but not significantly so since so much of the task is moving data around in memory and across the network
- If you don't like it, stop using it
Or, you could always write your own...
3 Likes
My bad - you are correct...
Please update your hub to the latest Hubitat code....
Gladly (and thank you for all the work, seriously)! What are the latest versions?
Is HPM not on the latest?
That's what both HPM and the GitHub page show:
The thermostat driver is 1.9.05, and the smart mode app is 1.9.01.
I am sorry that this is upsetting you.
I am not sure you read my post correctly. I was not complaining about the app. And I also made the point that it was only consuming 40% of the 7%. I was merely asking if the level of activity is to be expected.
I am trying to diagnose a repeated warning from my hub about increased levels, which I might add is not impacting anything as far as I can tell. Since it doesn't tell me what app is causing it I am going through the tools at my disposal to see if I can isolate a specific app or rule etc. The error message is not really much good - it would be more helpful if it took a snapshot of running apps and let me know so I could narrow it down. For all I know the Ecobee Suite could be idle at the time this is happening.
1 Like
The "heavy load" setting in the Hubitat firmware is somewhat arbitrary - the default has been (somewhat arbitrarily) set at 33% by the Hubitat team.
I suspect that this is tunable so as to eliminate the nagging when your hub is otherwise running Just Fine.
Again, contact Hubitat support for assistance, or perhaps ask to be put on the Beta program...
And, just to close out this round of this discussion:
- Yes, this load is normal, and expected, given the amount of work that Ecobee Suite has to do./ The code has bee exhaustively optimized to both minimize the overhead and impact on your Hubitat hub, on the network, and on the Ecobee servers.
TTFN!
1 Like
@storageanarchy thanks for such a great app! The best ecobee app out here for hubitat! Wish you were still developing it for the new models but understand your position. No need to reply, just wanted to say Thanks!
3 Likes
For the contacts and switches helper, would it be possible to add a number of contacts threshold?
Right now, ANY contact triggers HVAC shutoff and resume only happens when all are closed. What I would like to do is be able to set a threshold of 3, for example. If 3 or more contacts are open, disable HVAC. If 2 or less are open resume schedule.
1 Like
Allow me to suggest an alternative solution:
- Create a new "Virtual Contact" device
- Assign that to the Contacts & Switches Helper
- Write a Rule (or two) that does what you want:
- Open the Virtual Contact when any 3+ windows are open
- Close the Virtual Contact when 2 or fewer windows are open
You may need to create/use a global variable to count how many windows are open/closed. Create the rule with the Trigger "Any Contact Changes", then first step of the rule is to check if the action was open (add 1) or close (subtract 1), then if (global-var > 2, virtual contact open, else if global-var < 3, virtual contact close).
2 Likes
Thanks. That a good idea.
What would be the best way to "to check if the action was open (add 1) or close (subtract 1)"?
I'm not seeing an easy way of doing other than using a variable, resetting to 0, and then counting each open window and adding 1 to the variable through a If, then statements in rule machine.
Is there a simpler way of checking if the trigger was open or close?
Rule Machine will put the triggering action into the variable %value% - so you can do:
IF (%value% is "opened") ...
IF (%value% is "closed") ...First of all, thanks for the great app! I've been using it for a while now and love all the helpers in particular.
I've recently wired up my humidifier to my thermostat and am running into an error when I try to add a "Smart Humidity Helper" in the Ecobee Suite Manager. Just wondering if anyone else is experiencing this and if there's anything I can do to troubleshoot further and hopefully resolve the issue? I live in Calgary, so the lack of humidity is real here...lol.
Screenshot of the error I get after selecting my thermostat in the Smart Humidity Helper page:
Screenshot of error in the logs:
That's an odd bug - Groovy is supposed to cast the temp value to a BigDecimal when doing the math.
Try replacing the following code in ecobee suite smart humidity, starting at line 638 through 664 (inclusive):
// Calculate a close approximation of Dewpoint based on Temperature & Relative Humidity
// TD: =243.04*(LN(RH/100)+((17.625*T)/(243.04+T)))/(17.625-LN(RH/100)-((17.625*T)/(243.04+T)))
def calculateDewpoint( BigDecimal temp, rh, units) {
def t = ((units == 'C') ? temp : fToC(temp)) as BigDecimal
def dpC = 243.04*(Math.log(rh/100.0)+((17.625*t)/(243.04+t)))/(17.625-Math.log(rh/100.0)-((17.625*t)/(243.04+t)))
return (units == 'C') ? roundIt(dpC, 2) : roundIt(cToF(dpC), 1)
}
// Calculate a close approximation of Relative Humidity based on Temperature and Dewpoint
// RH: =100*(EXP((17.625*TD)/(243.04+TD))/EXP((17.625*T)/(243.04+T)))
def calculateRelHumidity( BigDecimal temp, dp, units) {
def t = ((units == 'C') ? temp : fToC(temp)) as BigDecimal
def td = ((units == 'C') ? dp : fToC(dp)) as BigDecimal
def rh = 100*((Math.exp((17.625*td)/(243.04+td)))/(Math.exp((17.625*t)/(243.04+t))))
return roundIt(rh, 0)
}
def roundIt( value, decimals=0 ) {
return (value == null) ? null : value.toBigDecimal().setScale(decimals, BigDecimal.ROUND_HALF_DOWN)
}
def roundIt( BigDecimal value, decimals=0) {
return (value == null) ? null : value.setScale(decimals, BigDecimal.ROUND_HALF_DOWN)
}
def cToF(BigDecimal temp) {
return (temp != null) ? ((temp * 1.8) + 32) : null
}
def fToC(BigDecimal temp) {
return (temp != null) ? ((temp - 32) / 1.8) : null
}Let me know if that works, and I'll update the master code...
EDIT: I was able to resolve the issue, please see the EDIT notes at the bottom for final TL/DR updates. I've also created a PR here with the changes made (please note the comment on line 635 stating my assumption but inability to verify/test). Thanks again for the help @storageanarchy!
Thanks for the quick reply...I ran into an initial error and realized that it was simply because the fToC function was removed. I updated it the same way the cToF function had been updated, so the full set of code I updated from line 638 through 664 inclusive was below:
EDIT: Literally just realized you had this there all along, didn't realize the code window was scrollable, lol...my bad.
// Calculate a close approximation of Dewpoint based on Temperature & Relative Humidity
// TD: =243.04*(LN(RH/100)+((17.625*T)/(243.04+T)))/(17.625-LN(RH/100)-((17.625*T)/(243.04+T)))
def calculateDewpoint( BigDecimal temp, rh, units) {
def t = ((units == 'C') ? temp : fToC(temp)) as BigDecimal
def dpC = 243.04*(Math.log(rh/100.0)+((17.625*t)/(243.04+t)))/(17.625-Math.log(rh/100.0)-((17.625*t)/(243.04+t)))
return (units == 'C') ? roundIt(dpC, 2) : roundIt(cToF(dpC), 1)
}
// Calculate a close approximation of Relative Humidity based on Temperature and Dewpoint
// RH: =100*(EXP((17.625*TD)/(243.04+TD))/EXP((17.625*T)/(243.04+T)))
def calculateRelHumidity( BigDecimal temp, dp, units) {
def t = ((units == 'C') ? temp : fToC(temp)) as BigDecimal
def td = ((units == 'C') ? dp : fToC(dp)) as BigDecimal
def rh = 100*((Math.exp((17.625*td)/(243.04+td)))/(Math.exp((17.625*t)/(243.04+t))))
return roundIt(rh, 0)
}
def roundIt( value, decimals=0 ) {
return (value == null) ? null : value.toBigDecimal().setScale(decimals, BigDecimal.ROUND_HALF_DOWN)
}
def roundIt( BigDecimal value, decimals=0) {
return (value == null) ? null : value.setScale(decimals, BigDecimal.ROUND_HALF_DOWN)
}
def cToF(BigDecimal temp) {
return (temp != null) ? ((temp * 1.8) + 32) : null
}
def fToC(BigDecimal temp) {
return (temp != null) ? ((temp - 32) / 1.8) : null
}
I'm now getting the following error (guessing this is suggesting that elsewhere in the code is still expecting the value as a string now that we've updated it to BigDecimal?):
EDIT: Deleted my subsequent post and copy/pasting the info here instead.
I was able to correct the issue by updating line 635 as follows (showing lines 617 through 639):
def myConvertTemperatureIfNeeded(scaledSensorValue, cmdScale, precision) {
if (scaledSensorValue == null) {
LOG("Illegal sensorValue (null)", 1, null, "error")
return null
}
if ( (cmdScale != 'F') && (cmdScale != 'C') ) {
if (cmdScale == 'dF') {
cmdScale = 'F' // Normalize
} else if (cmdScale == 'dC') {
cmdScale = 'C' // Normalize
} else {
LOG("Invalid temp scale used: ${cmdScale}", 1, null, "error")
return roundIt(scaledSensorValue, precision)
}
}
if (cmdScale == temperatureScale) {
return roundIt(scaledSensorValue, precision)
} else if (cmdScale == 'F') {
return roundIt(fToC(scaledSensorValue.toBigDecimal()), precision)
} else {
return roundIt(cToF(scaledSensorValue), precision)
}
}
I'm assuming line 637 needs to be updated the same way, but not positive and also not quite sure how to test, so I'm leaving it alone for now. Let me know if there's anything else I can do on this end to help troubleshoot/resolve the issue, but the above seems to have resolved the issue I was having at least as I'm now able to set up the Smart Humidity Helper.
