Thanks. It does seem a bit odd that changing the frequency higher led to lower total load though. It makes sense the work is more when the frequency is higher but the load calculation is quite perplexing. Maybe it's just a Hubitat accounting thing.
Where can I get more information in order to understand how to setup smart circulation? I admit I am not understanding why I would set to circulate when hotter vs cooler and how to properly setup based on humidity levels.
Here’s what I’m looking for with these helpers.
-
Turn on / off hvac when a window / door is left open or closed for x minutes (This is setup already successfully).
-
circulate the fan at least once every 20 minutes and off when doors / windows open. Circulation Exception: if doors / windows open and it’s below a certain temp outside and humidity outside is below 55% relative humidity and doors/windows are open (don’t circulate and pull hot air from outside in and/or pull higher humidity indoors).
-
I programmed a summer and a winter program on the thermostat. Goal is to keep the house at 70 degrees all year long regardless of season. I setup a helper to switch between summer and winter program based on whether the outside temp is above or below 65 degrees outside (this is subject to change). Right now I have the helper to set thermostat to cool if above 65 and heat if below. My question is should this be set to auto or should I turn the switch on that says to set to auto if temp is i between the program set points? Trying to understand when I should use auto and when I should set to heat or cool directly.
I may have more questions on setup but I appreciate any feedback. Would like to finally get this setup as a set and forget as part of my hubitat configuration.
One other request as it relates to notification with the helper.
Would it be possible to change the notification to only notify when the mode changes from heat to cool or from cool to heat? It appears it’s notifying on the temp change which is a lot.
The code already checks and only notifies if the desired Mode isn't the same as the Current Mode.
Please check Live Logging for the Smart Mode Helper, the Thermostat Device, and for Ecobee Suite Manager. If the debug log entries for Smart Mode say that it is changing the Mode (as opposed to saying that the thermostat is already in the desired mode), then one of two things is happening:
- The prior change didn't take, or was overridden by something else
- The cycle time is too long - this helper really needs you to set the cycle time to 1 minute so that the changes it makes are reported as quickly as possible after they actually happen.
Thanks!
Where is the cycle mode time set at?
Here is my smart mode helper settings.
Curious if you also saw my other reply regarding setting up my helpers?
Good to know. Mine was set at 5. No idea why I set it that way, but guessing it's been that way for years. 
You probably want to set Heat mode when temp is below 65, and Cool mode when temp is above 75, and Auto in between. The gap is because a house will retain heat/cool even as the outside temps change.
In Ecobee Suite Manager / Preferences. If you are actively using Helpers, it should always be set to cycle every 1 minute.
With those logs, verify that the Mode is actually getting changed at the Thermostat. Also - look at the Ecobee Suite Thermostat logs to see if any errors.
or just turn all 3 on, if you are sure that you have more than 5 degrees between heat and cool setpoints (in my experience it makes more sense to use the internal temps rather than external to change modes, but YMMV).
I’m Using the external to keep from having to switch the programming in the spring and fall. I’d ideally like to have this app do that for me. But at the same time I’m trying to keep the house the same temp all year long when the doors and windows are closed and minimize my electric bill with not having the system for running long periods of time like it has been when my wife opens the doors and windows to let fresh air in and then the AC runs for hours on end trying to keep up.
Or, if your security system sensors are integrated with Hubitat, then just do like many do here and have Hubitat turn off your HVAC if a perimeter door or window has been left open for, say, 5 minutes, then have it turn back on when all the doors/windows are closed again. With energy prices being what they are, I have decreased my therm usage a fair amount once I did this (although my actual cost has not gone down much due to increases in cost/therms used, LOL).
Also, unless you are actually using external temp sensors, due to microclimate variations, the local outside temp reported by my Ecobee can be several degrees off from the actual temp.
Thanks for the insight. We installed solar panels on our home to help offset the costs. Between my 400 gallon salt water aquarium and our 2700 gallon swim spa that’s 50% of our electric costs. Just trying to minimize where I can.
I also use a Tempest weather station on my roof that I point to for external temps.
Hi @storageanarchy,
I've noticed some strange behavior with the currentProgram* family of attributes not updating properly while the thermostat is turned off. I'm not sure if this is a suite bug or a limitation of the Ecobee API, but here's an example of what I've seen:
Assume the following setup:
a. Thermostat has four climate settings: Morning, Work, Evening, and Sleep.
b. Morning is scheduled for 7:00 AM.
c. Sleep is scheduled for 11:00 PM.
d. Work and Evening are scheduled between those times (the exact times are not relevant).
e. The current time is 6:30 AM and the thermostat is in Heat mode.
Now, the following events happen:
- 7:00 AM - Thermostat's program changes to Morning.
a.currentProgramreports "Morning"; this is correct. - 7:30 AM - Thermostat is turned off and remains off for the entire day.
- 11:30 PM - Thermostat is turned on to Heat mode.
a. The thermostat device'scurrentProgramis still set to "Morning". This is wrong: it should be set to "Sleep". Furthermore, the fact that it is still "Morning" indicates that it hasn't been updated all day.
b. The physical thermostat is running the correct program (Sleep).
I used currentProgram as an example, but it affects all of the current-program-related attributes.
I have a bunch of automations that behave differently depending on whether or not the thermostat's program is Sleep, and this problem is causing lots of issues with those automations.
Can you take a look and fix it if it isn't an Ecobee limitation?
Hmmm...
First, some questions:
- Have you checked with the Ecobee Web App and the Ecobee Phone App to see what they show during the time that the thermostat is "off"?
- Does the Ecobee Suite Thermostat device update the program attributes after you turn it back on? If so, how long does it take?
- Relevant to #2, what is your Cycle Time in ES Manager / Preferences
I am pretty sure that my code doesn't do anything differently when the thermostat is "off" vs. when it is set to some other mode (Auto / Heat / Cool), but I'll check...
- I haven't, mainly because it's been happening while I'm asleep, and I notice it when I wake up because the heat suddenly kicks on at 2AM. The web app and phone app don't show any information about the current program even when the thermostat is on, so I'm not sure where I would check this anyway.
- No. That's exactly the problem. The attributes don't update until the next scheduled program change.
- By Cycle Time, do you mean Polling Interval? That's 1 minute.
Ok, then - can you check this for me: While the thermostat is off:
- Verify that the
currentProgramis wrong as per your schedule in the ES Thermostat device - Check whether
scheduledProgramis correct as per your schedule - Open ES Manager, and then click Done - this will force a total update to the thermostat device
- check whether the
currentProgramand/orscheduledProgramchanges to the correct program
I suspect that currentProgram isn't being updated by Ecobee when the thermostatMode is 'off', but scheduledProgram should be. If my theory is correct, you'll have to used scheduledProgram for your logic when the thermostatMode is 'off'.
I still have to figure out why currentProgram is wrong after you turn the thermostat back on...
Based on the event history, I can verify that this is what happened last night. I'll get back to you on the other two after the next schedule change.
The problem is that I also use currentProgram to detect if there is currently a hold in place. Is there a better way to do that?
thermostatHold tells you if the thermostat has a "hold", or is in "vacation" mode - will be "null" or "" if not...
If you can, I'd still like to know if currentProgram changes to the correct value if you do a force update (you can also try pushing the Force Refresh button on the ES Thermostat device page).
