Just as a heads up, on line 750, I believe it should be a “+” not a “-” for the new coolingSetPoint i.e.
temp_diff = (temp_diff <0-max_temp_diff)? (-max_temp_diff):(temp_diff >max_temp_diff)?max_temp_diff:temp_diff // determine the temp_diff based on max_temp_diff
targetTstatTemp = (programCoolTemp + temp_diff).round(1)
It is.
Yves may have a broader survey (more end users)… but everyone I know with a Smart thermostat uses Auto, as it’s one of the primary reasons lots of people buy smart thermostats.
Hi,
For comfort reason (and easier setup), I can see why somebody would use the auto mode (as the thermostat will then try to reach the median setpoint - between your heating/cooling setpoints). However, this means that the thermostat will cycle in both heat and cool modes to reach it…
If you’re not careful about your range, this could mean that your thermostat will call heat and cool more much often.
For more efficiency, however it’s recommended to set up your ecobee scheduling and define your heating/cooling setpoints for the following periods of the day: Sleep, Home, Away.
You can save 10-20% by doing a temperature setback or setforward of 7 degrees Farenheit at Nights and when you’re away [This comfort and saving tip will be given to you if you use the “ecobeeGetTips” smartapp. You can use the 3 ecobee generate Stats smartapps (available at my github) to get more targeted energy saving tips].
Also, in my house, my heating setpoint is way lower than my cooling setpoint as don’t have the same temperature requirement in the winter vs. the summer.
BTW, the ‘auto’ mode is now a pretty common feature on some cheap z-wave thermostats like goControl & CT-100, so I don’t consider this feature as being the main component of a “smart thermostat”
The features that are really smart for the ecobee are the following:
- smart recovery
- smart away & follow me
- IQ data
Please refer to the following insight for more details:
Regards.
That’s actually not how ‘auto’ mode works on the ecobee. It doesn’t try to reach the midpoint and ending up calling both heating and cooling too much. Rather, the thermostat will only cool if the temperature is above the cooling setpoint and heat if below the heating setpoint. If the temperature is in between, the thermostat neither heats nor cools (just allow the temperature drift).
As an example, if you set Auto to 72F (heating SP) - 77F (cooling SP), and the temperature in the apartment is 78F, the ecobee will cool to try to get to 77F. Once it reaches 77F, it does nothing and maintains that temperature. For it to start heating again, the temperature will need to drop all the way to 71F. That’s how the overload doesn’t happen and that’s why ‘auto’ mode is actually very efficient. On the ecobee, the minimum range in ‘auto’ between heating and cooling setpoints is 3F.
Essentially, ‘auto’ mode is probably more efficient than just ‘heat’ or ‘cool’ modes.
BTW, you should update your code with my suggestion above as the new code as-is will mess up people’s ‘cool’ modes. Also, my ‘follow me’ features now works very well and as expected. Thanks!
If you carefully read what I wrote above, that’s basically what I’m saying. Therefore, the auto mode is not recommended for most parts of the US and Canada as you should have distinct heating /cooling setpoints & distinct climates/programs (Away, Home, Sleep) for more efficiency.
Auto mode should be used only in some parts of the US where there are wide outdoor temperature discrepancies during the same day.
For the rest of the US and most of Canada, I recommend the following configuration steps:
http://thingsthataresmart.wiki/index.php?title=My_Ecobee_Device#Configuration
Regards
For more details on auto mode, please refer to
It explains here that the target temperature is the median (midpoint) between your lower heating setpoint and your upper cooling setpoint. The lower and upper setpoints are the trigger for the ecobee mode change.
Regards.
I don’t think we’re saying the say thing and that’s not what the article says. It says:
“Your ecobee will then use this temperature as the midpoint between your heat and cool set points (based on what you’ve set your minimum heat / cool temperature delta to).”.
Having used this for quite some time, I’m pretty positive on how it works. It doesn’t try to reach a median setpoint. Rather, it tries to reach one of the end values of the range. In fact, the whole reason why the default difference between the heat and cool setpoints is 5F is to prevent what you’re saying as this article explains (https://support.ecobee.com/hc/en-us/articles/115006210668-How-do-I-use-Siri-and-HomeKit-scenes-to-control-my-ecobee-when-in-Auto-Mode-)
We chose 5 degrees so your system doesn’t constantly switch between heating and cooling, helping you save money on your energy bill.
I’m pretty sure there was some documentation out there that explains this also but can’t seem to find it. I think it’s a link that no longer works on their website. (https://www.ecobee.com/faq/how-do-i-increasedecrease-the-temperature-difference-between-my-heatcool-setpoints/)
Also, if it really targets the median, then what exactly is the point of the heat/cool setpoints? They should really just be the same number (the median) then and 72F - 77F vs 60F - 89F would mean the same thing.
Also, with ‘auto’ mode, you can have distinct setpoints so not sure what you meant when talking about distinct setpoints earlier. When I’m home, auto mode is between 71F - 76F. When asleep, it’s between 70F - 77F and when away, it’s between 64F - 82F. I guess I really don’t see the benefit of just using ‘cool’ or ‘heat’ when you can have the best of both.
1 Like
Hi, we can argue about its behavior, but the fact of the matter is the following:
-
Auto mode is not the optimal mode for efficiency, it should be used for comfort purposes, not efficiency.
-
It’s not recommended for most parts of the US and Canada where you have distinct seasons. It’s recommended for climates where there are wide swings of temperature during the day.
Refer to my previous post for the setpoints explanation.
If you want to use ‘auto’ mode for your home, it’s up to you. Some people prefer comfort over energy savings.
That closes this ‘little’ argument on my side. Enjoy your ecobee.
. I don’t think it’s fact that it isn’t optimal or recommended for certain locations (ecobee doesn’t say so) and whether it’s fact or not is based on how it works (which we disagree on). But I hear you, to each his own. Thanks for the smartapps!
So this morning, my ecobee for some reason decided to ignore my indefinite hold and changed my climate (and the corresponding setpoints) from sleep to away based on my schedule. I typically don’t use my schedule as I use your smartapp to adjust my climate based on the ST hub’s mode and that has always worked well. This morning is the first time I’m seeing that the hold was ignored.
Not sure why that happened but just wanted to give you a heads up on that. I think the problem is most likely from ecobee as the logs don’t show setclimate being run and yet, the program/climate changed. Also, I confirmed on the ecobee that the hold type was still (‘until I change it’) so that wasn’t the issue. Weird that that occurred though
Hi yvesracine,
Bought your device handler to get the most out of my Ecobee3 and facing a couple of issues.
- I am seeing this error messages in Live Logging on the Ecobee. Any idea what went wrong?
Removed
- Also, I wanted to purchase the ecobeeSetZoneWithSchedule SmartApp and checked on the Motion activity of the three remote sensors. Per the mobile app, motion is detected sporadically. One of my master bedroom sensors showed last motion activity as of day before yesterday.
@mainak, those error messages don’t come from My Ecobee device as they are not formatted according to my standards.
They probably come from the stock ST device or else.
Sorry, I cannot help you for those error messages.
Regards.
I’d suggest to remove the ST stock device to avoid any confusion.
Also, I believe that you have the same issues with the remote sensors. You’re probably looking at the wrong sensors in your mobile app.
To install and configure My Ecobee device, please refer to the ST community wiki:
http://thingsthataresmart.wiki/index.php?title=My_Ecobee_Device#Configuration
If you need further assistance, please contribute to one of my support packages, and I can install My ecobee device for you.
Regards.
P.S. Please remove your logs from the ST community forum as sensitive info about your location and settings can be embedded.
You were correct about the stock ST device for the remote sensors.
I am pretty sure I am checking on your sensors in the app. My ecobee is called Home and the name of the sensor is Home:Basement etc… I removed all of the stock ST sensors and will monitor throughout the day and the next day and update.
1 Like
Please remove your logs from the ST community forum as sensitive info about your location and settings can be embedded.
I removed the logs, thanks!
Hi again,
The ecobee’s proprietary remote sensors have some API limitations regarding the motion capability as documented here:
http://thingsthataresmart.wiki/index.php?title=Ecobee3RemoteSensorInit#Known_issues
Also, please follow the troubleshooting section here for any issues:
EDIT: BTW, ecobeeSetZoneWithSchedule can use any ST connected temp/motion/contact sensors, so I’d recommend to use other motion sensors than the ecobee’s proprietary ones for real-time HA scenarios.
Regards.
So I finally switched from Stringify (after hearing comcast news) to webcore and I really do like the flexibility of it.
However, when I call upon Ecobee to set a temperature or away mode within webcore, I dont see any parameter to set it to indefinite time within webcore. Within smartthings app, my holdHours is 1. I only set this so when I set a temp using smartthings/.actiontiles it only holds it for 1 hour. However, I want the option to set it to a certain temp or away mode indefinitely in webcore during certain pistons (like when everyone is away).
Anyway to do this? Stringify let me select between the following when setting a temp or mode: Permanent or Only until next transition.
Here is an example webcore piston script that involves ecobee. I have selected away(); but it is only following my holdHour:1 rule. I added setHold(); to see if that did anything, it does not:
With webcore, here are the following actions for ecobee and your script.
If theres no current way as it follows the holdHour setting, can you add a action like awayIndefinite(); ?
Hi,
It’s all expained here. Refer to setClimate & setHoldExtraParams with the holdType parameter (under examples of smartapp calls). For your use case, you just need to call setClimate with the right parameters.
However, as explained earlier to @farlicimo, you’d need to convince the webCoRE’s author to support map as input parameter. If you’re many users to request it, you have a better chance to make it call the DTH with the right parameters (as the DTH already supports any kinds of holds with a map).
Regards.
thanks for the response and explanation.
Do you have any ideas on how to get around this? I was thinking about doing setAway, wait 1 hour, and do another setAway. By then , once it resumes, it should already be in away mode due to no movement. However, I can see an issue with this if someone comes home within 2 hours