I just setup a rule to try this today and so far it working. My rule checks for Not idle.
Mine works. It went from idle to heating just fine.
Really? Mine did once yesterday but only once. Every other time the thermostat ran the operating state stayed at "idle".
You may be right. Last night I tried it and it changed. I just tried it again and it sits at idle. So its not consistent.
You may want to report it to support.
I have. No response yet on that or another request I submitted.
It appears to me that it's the same problem that ST had with my Honeywell. If there is some other event that is causing the setpoint to change, it recognizes that change from Idle. But if the t-stat is simply recovering the temp on it's own, that is not picked up. But that is just anecdotal. Haven't had time for a deep dive yet.
Scratch that, today it stays in idle and does not pickup the change to heating.
Okay, so it's not just me. I feel better now. Not that I want anyone else to suffer but it makes me feel better knowing it's not just me.
I've watching this for a day now. It appears that a change to heating set point will trigger an update to operating state, this looks to occur from changes via android app, main EcoBee thermostat or a scheduled change. If the change in operating state is based on just the current temp dropping below heating set point it will not pick up the change. However, even when it does pick up on the change, it only does so during a polling update so can be delayed by 5 minutes.
In all cases the android app picks up the change right away.
So this won't work for my use case. Triggering humidifier as soon as heating starts. Because of the delay of up to 5 minutes before HE can pickup on a drop in humidity I get large swings.
Looks like I'll need to switch to a separate humidity sensor vs. using the EcoBee. Now to find one that reports changes quickly.
You can change polling to 1 minute.
However @bravenel, it does appear there's a recent issue with contacting the Ecobee server. I'm finding this in my past logs daily. I reestablished connection to their cloud a few days ago, and initially it appeared to have helped, but the error comes again the next day.
I do have an issue with my modem that rebooting every two days does not seem to be enough anymore. My ISP is sending another modem, so if this isn't seen by others too, it's also possible it's simply a symptom of my faulty modem.
app:23642018-11-13 09:56:42.257 am infoHttpResponseException groovyx.net.http.HttpResponseException: Internal Server Error, 500 polling ecobee pollAttempt:1, isThermostatPolled:false, isSwitchesPolled:true, [status:[code:14, message:Authentication token has expired. Refresh your tokens. ]]
I get that error every hour, when I asked I was told it is normal and to only be concerned if the "pollAttempt" count starts climbing above 1.
We have identified an error in the display logic for the operatingState for the driver. This results in a default action of idle when certain conditions are happening. This is fixed in the next update.
I am now also seeing this error with the latest 2.0
I was also wondering about a possible update rot the native integration to allow setting the thermostat to a specific comfort profile with a specific hold pattern. In ST, the DTHs I used had the option to send a command to the Ecobee with up to 3 parameters, the specific comfort profile name; one of three hold patterns (indefinite, until Next Transition, or by time; and the number of hours if by time was the hold. The until next transition was very useful because it would allow you to only modify your thermostats program until it's next change kicked it. For example, I'm going to bed early so I want my sleep profile to start early but I want it to pick up again with my day profile at the next transition automatically.
It's something we have a ticket in for. Can't say when but it has been noted.
On the device page for EcoBee change Hold Type to Temporay. then any change to temp is until next transistion
Thanks!!! That will mean I'll finally be able to shut down my ST. I'll try and be patient.
Yes... But it doesn't allow you to change to any comfort profile except away. And away I want to be indefenite.
True but instead of changing comfort profile you could just set heating and cooling set points to be the same as the target profile and then it would resume the normal programming at the next scheduled change
That's true. But I don't always want the setting to be next transition. If I set it to away I want it to be indefinite. Will you please just trust me on this one? The functionality is there.
Something came to me last night and I have to agree with @Ryan780 on this.
On the ecobee the schedule is what triggers what they call comfort settings. If we want to manage the ecobee modes (such as sleep for example) the driver needs a method to set the comfort settings. It can be done through IFTTT if you really need it now but integrated right into the driver would be nice.
The thing about comfort profiles is that is more than just the temperature it is setting. It also works along side remote sensors to manage the temperature. So if I set the night comfort setting, the ecobee only worries about the temperature via my bedroom sensor. Just setting the temperature via the driver does not properly utilize the sensors.
So what would be nice if possible is to have a "setComforProfile [name]" option that we could trigger as needed.