Subscribe to Ecobee 3 events (events not firing)

Does anyone know if you can subscribe to the events for an Ecobee 3?

I’m trying to subscribe to a thermostat mode change. Specifically I want to know if it is cooling, heating, or if only the fan is on. I have a bypass damper that needed a little help. So I have created an automated version of the damper that I want activated depending upon which zones are calling. I can schedule it via cron with the limitations being 1) that I have to issue a refresh on the thermostats before evaluating the status of the thermostats (for the Ecobee 3’s the refresh can push the 20 second app limit) and 2) the damper doesn’t respond until the cron job runs which causes the whole thing to wait to relieve the pressure for a small zone.

I have tried subscribing to thermostat.thermostatMode (among other things), but the events never fire.

Does the Ecobee 3 generate events? ST can control the thermostats, but many times the thermostats need to be refreshed to display accurate/current information. Is this normal? Any ideas or suggestions?

You want to subscribe to the capability thermostatOperatingState:

subscribe(thermostat, "thermostatOperatingState", tHandler)

Valid states are idle, heating, cooling, fan only

NOTE! Not all Smart Device Handlers for thermostats implement this (although they all SHOULD implement it). Unfortunately, the (current) SmartThings Device Handler DOES NOT implement this (nor do most all of the Nest Handlers, by the way).

Yves Racine’s “My ecobee Device” DOES implement this, but unfortunately the latest returns the OperatingState from the prior poll, so you’ll usually be 40 minutes behind. If you’re interested in getting it to work better, I guess you might contact Yves and see if he can help you…

1 Like

Thanks for your help. I have tried that one (and others), but because of your post I tried it again and it kind of did something. After about 20 minutes one of two events fired. I’ll admit, I never waited 20 minutes before (maybe one of the other 5 subscribe statements worked too). I tried another test as well, and after 40 minutes I received nothing.

Buggy! Should it take 20-40 minutes and still miss virtually all of the events? I rarely miss an event, with my other devices, but with the Ecobee, I rarely receive them (prior to receiving the one event mentioned above, I would have said I never receive an event). The cloud-to-cloud integration doesn’t work very well. Hopefully ST and Ecobee can address some of the limitations that you mentioned at some point.

I have successfully sent the Ecobee commands from ST (and it works for the most part). I have been UNSUCCESSFUL at receiving commands from Ecobee (whether triggered by the Ecobee app or even if the thermostat triggered the event). The cloud-to-cloud integration seems to work mostly one way (ST->Ecobee).

The ST ecobee device only gets updates when it is polled, so if you want to see things in “near real time” you will need to poll it frequently - but Yves suggests no more than every 15 minutes. My version supports polling down to 3 minutes (The ecobee API minimum), but Yves has asked me not to share my code with anyone.

Oh well…I suggest you discuss your needs with Yves. Good luck!

Hello @bago, if you use my Ecobee device, then all you need to do is a regular polling on the device in your smartapp -like any other devices that support poll().

If you need to do it every 2 minutes no problem, there is nothing in my code that prevents it. Refer to
my version 2.0.8 at github:

Since ST did some cloud optimization (and introduced rate limiting), many devices now need to be polled in order to get the latest values.

A good example of this is the weather station, see this thread below for more info. As you can see in the last posts of this thread, even stock ST devices now need to be polled in order to get the latest values, and it’s not as reliable as it used to be.

P.S. I can assure you that My ecobee device is as reliable as any other implementation out there (either the stock ST device or any custom ones based on my code). There are some reliability issues related to the ST platform as a whole, but that’s a totally different concern and not related to my code.


Thank you @yvesracine. I adjusted the polling a few hours ago. It did help. I think my app works as well as it can considering the limitations of everything involved (since app relies upon app and so on - our own little House of Cards).

As for the stability, I believe that your code is solid. I do NOT BELIEVE that the ST and Ecobee sides are (that’s why I said “hopefully ST and Ecobee can address some of the limitations that [@storageanarchy] mentioned”. Solid or not, their limitations affect your code and that is unfortunate for everyone. Thanks for all you have done. I look forward to a platform where all of this just works a bit more reliably.

BTW, I had noticed some things were not updating (i.e. weather tile), but I did not notice how pervasive the problem had become until you mentioned it (“even stock ST devices now need to be polled in order to get the latest values”). Interesting in light of the comments surrounding Pollster (@geko) not getting approved. Without having a reliable state to depend upon, it’s difficult to write an app to respond appropriately (more likely impossible). I truly hope they get this fixed.

Lastly, rate limiting seems to be catching things that are not running a muck (things that are efficiently written) which adds to the aforementioned problems. Unfortunately there is no way to tell the difference (between good apps, slow internet, etc.).

1 Like

Hello @Bago, apparently some ST users are having even more issues with the stock ST ecobee device under the SmartThings labs.

See this thread:


@yvesracine Started yesterday evening, but I’m having a similar problem with My Ecobee Device.

Again, I think the issue is ST or Ecobee. I’ve been watching and trying to find a pattern and I noticed that the execution time for the Ecobee increases significantly around sunrise/sunset (no surprise) and stays higher in the evening (I guess because people are home, tinkering, etc.). I think this is the culprit, not your code (so chill, I meant no disrespect). I think there are lots of things at play here (rate limiting, schedules failing, unresponsive websites, etc.). Things won’t stabilize until those endpoints are fixed/stable. Until then, we have a House of Cards.