Ecobee temperature settings forcing to HOLD and sensors no longer work in automations

Starting a new thread from an older one on the topic to hopefully get more attention.

Automations that change the temperature on the ecobee integration now seems to force a HOLD (Hold until changed, ignoring ecobees built-in comfort setting changes).

Previously the integration, by default, set temperatures “until the next change”, which worked well for me and allowed a union of comfort settings and ST temp changes that worked well for my automations.

A comment on the original thread pointed to setting holdType in Preferences via the ST IDE is set to “Temporary”, but that doesn’t seem to be honored at all.

Things had been working nicely for me for years, but I recently had to delete and re-add ecobee to ST and now when ST changes the temp, it’s “holding” and is not able to be changed except manually or via another ST temp change.

I wonder what changed recently here? I suspect others won’t see this either unless they need to add a new thermostat or delete/re-add themselves.

Is anyone else experiencing this new difference in the ST/ecobee integration?

I observed the same issue going through Google, which implies this could be an Ecobee change, not ST. And yes, it is annoying because you don’t realize that it goes to indefinate hold until you later realize it. I now use the Ecobee app or actual thermostat to make the temp changes. On and Off usually are ok via google or ST.

I am having the same issue. It just started in the last few days. Ecobee disconnected from ST. When I reconnected, it started forcing the HOLD.

I have an Awair air monitor and am using an ST routine to set the fan mode of my Ecobee3 to ON when the particulate or TVOC reading is too high. When the air quality is good again I set the fan mode back to AUTO.

It works great EXCEPT, in addition to changing the fan mode it puts a indefinite hold on the temperature.

Changing the fan mode using the ST Ecobee3 device controls also puts the thermostat in an indefinite temperature hold.

Not a very good 1st impression of ST which I just installed and started using a few days ago.

When I removed/replaced the ecobee integration, it of course deleted all of my sensors too, which I had forgotten about how used they were in other automations, namely:

  • “When things quiet down, good night” and
  • “When things start happening, good morning”

These are probably two of the most critical automations in my toolbox that I rely on and had taken for granted with them working over the years, including through the Samsung app transition.

But now, after re-adding ecobee, those automations are no longer firing, although the history shows presence indicated by the sensors which should make them fire.

Now I’m cooking at night when I forget to turn down the temp after activity stops and freezing in the morning when I forget to turn the temp up and fire my good morning routine from activity.

I wonder who’s at fault here? ST or ecobee? Does anyone know of a custom device handler we could try to see if that works better? The built-in one now seems broken.

I reached out to Ecobee support who have been very responsive! This was the answer I received today.

I heard back from the team today and I have decent news here I think. The team managed to look into this and identified the issue. I was told there should be a fix deployed by the end of they day next Monday. Given this information, I’d recommend testing things out again on Tuesday/Wednesday and seeing how things are functioning then. All indications so far are that it should be getting fixed

3 Likes

Woohoo! Great news! Thanks for being proactive about this and not just bitching and moaning on the groups here like I did.

That’s great news and a surprisingly fast response.

Please check my custom ecobee integration with custom capabilities. The custom integration brings much more features, and the live history is working with all events pertaining to your automations.

You can set the temporary hold (nextTransition) if needed in the preferences section (amongst others).

@yvesracine are there plans to update this to Edge when Groovy ends?

1 Like

Hi, this would be a total rewrite of the code, and for sure it would be a different product.

I don’t have such plan at the moment.
BTW, there are very few developers who are writing with the new platform for cloud-to-cloud integration such as ecobee. There is practically no examples of such a rewrite. And Edge is for devices paired to the hub with protocols such as zwave and zigbee, not for C2C integration. I don’t see how SmartThings will eliminate totally the Groovy platform for C2C.

All the developers I know are now migrated to Hubitat, and my code has been ported and optimized on this platform as well. Hubitat is not dependent per se on the cloud such as SmartThings, but the integration with ecobee requires a C2C connection.

Regards

This appears to be fixed…for me at least.