[RELEASE] Initial Setup for Ecobee3 & 4, Smart-SI, EMS, Smart-02 thermostats - My Ecobee Device

Hi @slagle,@ben,

As I said in the last developer call, there seems to be more connection and timeout issues related to cloud-to-cloud integration than never before,and things are not improving…

  • Before all the changes to the Devconn platform related to HubV2, my (personal) connection with ecobee was very stable, but since the beginning of the year, there are a lot of ups and downs…

I personally have to reconnect to ecobee and re-authorize every month or so (sometimes twice a month).

I did report some connection issues myself quite a long time ago (linked to the security certificate amongs others), and here what ST support responded at that time:

Chris Porter (SmartThings)
Jun 30, 6:02 PM

Hi Yves,

Thanks for letting us know what you are seeing. My developers have been aware of this happening for a little while now also, and have worked on it. I will let them know your thoughts about it being the security timestamp being outdated.

I don’t have an ETA around implementing a revision to the code, but developers do currently know it is not working consistently for users, and are addressing it.

Thanks for the heads up, and the suggestions.

-Chris P.
SmartThings Support

  • Other users (especially with ecobee3’s remote sensors) have more frequent connection issues (every 6-12 hours) like jarettp’s previous post.

So, my question to SmartThings are the following:

(1)- What is being done for stabilizing cloud-to-cloud connections as any related integration is usually more complex and requires more execution time, (and typically hits the rate limiting constraints)?

(2)- Are those issues related to connection pool management, security certificates, or others?

(3)- Do you have any plan to correct the frequent cloud-to-cloud connection issues with devices such as ecobee, TCP Hub, and others?

(4)- For cloud-to-cloud integration, developers need more control over the http timeouts and rate limiting constraints… Is there a plan to let developers have more control over the parameters that can affect their cloud-to-cloud device’s behaviour?

  • Ecobee is very sensitive to the connection issues as it requires to refresh the authorization token every hour: if there is frequent http timeouts (which are set to 10 sec. by default), then, the cloud-to-cloud connection is lost and ecobee requires to re-authorize again.

Similar issues with other devices, refer to

TCP Hub

Stock Ecobee device

Philips Hue

Wemo

Wink Quirky Pivot

Logitech Harmony

Amazon echo

MyQ

P.S. I will personally hold on any new device handlers development that requires cloud-to-cloud integration as long as the connection issues are not solved as this is becoming a support burden for me.

The ST development environment is open (which is good), but this openness is not an asset if it does not provide secure and stable connections/integration with the different solution partners.

Any ST input about those connection issues is welcome at this point!

7 Likes

Hi @jarettp,

I made some changes today to MyEcobee device and ecobee3RemoteSensorInit that would hopefully reduce the number of connection & timeout exceptions

You may want to try the new beta versions at my github:

Let me know how it goes.

P.S. You’d need to copy and paste the code for both the device and the smartapp, save & publish.
Regards.

EDIT. I still think that the ultimate resolution of those connection issues is still on the ST side, but this may alleviate some of the issues till then.

1 Like

Thanks Yves. I installed (AND DONATED to) your device type yesterday. Thanks for your efforts. I’ve been running 2 Ecobee Smart Si t-stats for the last 6 months on the ST device type and its been shoddy at best. Yesterday after installing your code I asked myself “Why didn’t I do this earlier?”.

Anyway, long story short, I received 125 push notifications last night as it kept losing connectivity to the Ecobee site. I refreshed the connection this morning and an hour later it happened again. I’ve been reading the various threads and have a decent handle on the issues and potential fixes.

I’ve just installed your latest revision and I hope that makes a difference.

I also saw a thread that terminated this summer suggesting that by registering two separate ecobee accounts (one for each T-stat) the problem would be solved. Is this correct? Do you know if anyone else with this issue and 2 Smart Si T-stats resolved the connection issue by establishing 2 separate accounts?

I have a one story and a main and master suite T-stat. I have two separate HVAC systems, a traditional gas furnace and central air cond on the main, and a mini-split system responsible for the master suite.

Even if my connection loss only happened 1-2X a month, that would be acceptable, but 10+X a day obviously won’t work. Hoping for a fix!

Steve

Hi @stvdano, I mainly made the changes for the ecobee3 thermostats as they typically have remote sensors exposed to ST, and they seem to generate more exceptions…

For the Smart-SI, you should try to create 2 instances of MyEcobeeInit, but using the same ecobee account… And, also reduce the polling interval In MyEcobeeInit…

I have a single Smart-02 thermostat at home, and it’s mostly stable although I do poll it quite a lot with my installed smartapps… I have to re-authenticate once or twice a month usually due to the connection and timeout exceptions…

I’m kind of surprised to see that you have some issues with only 2 Smart-SI though.

Please report those connection issues to ST as this may be related to the way ST does its connection pool management… Is the connection pool management done by US region and this could explain why some US regions have more connection issues than others?

I personally don’t have any clue about the ST Devconn platform internals; all I know is that those recurrent connection issues are annoying for everybody!!

Regards.

Thanks for all your effort @yvesracine! Hopefully @slagle and @Ben read this and give an official response on what’s being done to fix this. From everything I can tell you’ve reported this numerous times for months with no resolution. This thermostat isn’t just your average $30 contact sensor that’s not working. It’s a $250 piece of equipment that I invested into because Smartthings told me I could integrate with. This needs to be escalated on their part and I appreciate everything you’re doing to keep pushing for an answer.

We are working on improving our end of Cloud and Lan connected devices. We can only control what we can control.

Aside from that, the only recommendation I can recommend is to reduce polling intervals. This will rule out your connection being limited by the external API. I know MyQ and Ecobee are very specific about their polling intervals. I have read on their forums they recommend not polling more than every 30 seconds (maybe 10 seconds? I found both numbers but 30 second intervals show up more).

I’d find it unlikely that you are hitting this limit, but I have also read on their forums something along the lines of “Our servers ensure that your thermostat is protected from attacks against it.” I wonder if you are hitting that “wall” so to speak.

I say all this not to say it isn’t on our end at all, but it may not be all on our end. Try reducing polling intervals and see if that resolves these timeout connection issues. :smile: I’d be interested to know. Maybe start by doubling your currently polling intervals.

Most of the other threads @yvesracine mentioned (with the exception of MyQ) are not related to this and are either related to a platform outage or DHCP issues. (We have a fix for wemo coming out in a little while that allows us to see and change the IP when the wemo Ip changes locally)

Hi @slagle,

Thnx Tim for your input, I’ve also recommended to lower the polling interval in many threads and also at the ST community wiki under “Known issues”:

http://thingsthataresmart.wiki/index.php?title=My_Ecobee_Device

About the ecobee polling constraints (30 sec. or so), I have already implemented a lot of defensive code to make the device more robust.

In my poll() command for example, I have already implemented the following logic to avoid calling the ecobee servers too often:

def poll_interval=0.25   // set a 15 sec. poll interval to avoid unecessary load on ecobee servers
def time_check_for_poll = (now() - (poll_interval * 60 * 1000))
if ((state?.lastPollTimestamp) && (state?.lastPollTimestamp > time_check_for_poll)) {
    return
}
state.lastPollTimestamp = now()

ecobeeType = determine_ecobee_type_or_location(ecobeeType)
if (!getThermostatRevision(ecobeeType,"")) {

// if there are no changes in the thermostat, runtime or interval revisions, stop the polling as values at ecobee haven't changed since last poll()
    return
}

So the following controls have been implemented for a while:

(1) There is a minimum polling interval of 15sec.
(2) And, the code will not send a getThermostatInfo to the ecobee servers if the thermostat revision has not changed since the last poll according to the ecobee specifications in

https://www.ecobee.com/home/developer/api/documentation/v1/operations/get-thermostat-summary.shtml

My code is actually by far more robust than the ST stock device which doesn’t do any of the above logic.

I doubt also that we’re hitting the 15 (or even the 30 sec.) limit often…

So, I hope that SmartThings will fix their DevConn issues ASAP for the benefits of all the ST community.

All I know is that some stability and reliability would make my life easier (and others!).

Regards.

2 Likes

Hi @slagle,

FYI, My Ecobee Device’s service manager will warn me (by sending notifications) if there are any exceptions/errors with the ST-ecobee connection.

And, today, I woke up with the notifications below.

My polling to myEcobee Device is usually about every
3-5 minutes which is more than reasonable given all the rate limiting on both parties (ST and ecobee).

So, again, something needs to be done. As soon as I re-authenticated again, the connection was fine.

Could it be related to some connection pool management that is done by ST at night (EST)?

Regards.

Push (OK)
59ad8038-9812-11e5-9be6-22000b029046 2015-12-01 5:00:28.604 AM EST - 2 hours ago APP MonitorEcobeeHumidity>monitoring every 30 minute(s)
Push (OK)
58e88118-9812-11e5-b60c-22000b3d02e5 2015-12-01 5:00:27.313 AM EST - 2 hours ago APP MonitorEcobeeHumidity>monitoring every 30 minute(s)
Push (OK)
4ef98423-9812-11e5-8576-22000b4a846d 2015-12-01 5:00:10.647 AM EST - 2 hours ago APP ecobeeSetZoneWithSchedule> too many exceptions/errors or unauthorized exception, doRequest>exception groovyx.net.http.HttpResponseException: Internal Server Error for null (90 errors), need to re-authenticate at ecobee…
Push (OK)
f0ae0dd2-9811-11e5-88a6-22000b248da3 2015-12-01 4:57:32.447 AM EST - 2 hours ago APP ecobeeSetZoneWithSchedule> too many exceptions/errors or unauthorized exception, doRequest>exception groovyx.net.http.HttpResponseException: Internal Server Error for null (89 errors), need to re-authenticate at ecobee…
Push (OK)
9799fa01-9811-11e5-b60c-22000b3d02e5 2015-12-01 4:55:02.998 AM EST - 2 hours ago APP ecobeeSetZoneWithSchedule> too many exceptions/errors or unauthorized exception, doRequest>exception groovyx.net.http.HttpResponseException: Internal Server Error for null (88 errors), need to re-authenticate at ecobee…
Push (OK)
3df28b45-9811-11e5-88a6-22000b248da3 2015-12-01 4:52:32.583 AM EST - 2 hours ago APP ecobeeSetZoneWithSchedule> too many exceptions/errors or unauthorized exception, doRequest>exception groovyx.net.http.HttpResponseException: Internal Server Error for null (87 errors), need to re-authenticate at ecobee…
Push (OK)
f07b1778-9810-11e5-8576-22000b4a846d 2015-12-01 4:50:22.616 AM EST - 2 hours ago APP ecobeeSetZoneWithSchedule> too many exceptions/errors or unauthorized exception, doRequest>exception groovyx.net.http.HttpResponseException: Internal Server Error for null (86 errors), need to re-authenticate at ecobee…
Push (OK)
8af55aa5-9810-11e5-88a6-22000b248da3 2015-12-01 4:47:32.290 AM EST - 2 hours ago APP ecobeeSetZoneWithSchedule> too many exceptions/errors or unauthorized exception, doRequest>exception groovyx.net.http.HttpResponseException: Internal Server Error for null (85 errors), need to re-authenticate at ecobee…
Push (OK)
38e8e1dd-9810-11e5-9be6-22000b029046 2015-12-01 4:45:14.635 AM EST - 2 hours ago APP ecobeeSetZoneWithSchedule> too many exceptions/errors or unauthorized exception, doRequest>exception groovyx.net.http.HttpResponseException: Internal Server Error for null (84 errors), need to re-authenticate at ecobee…
Push (OK)
more…

2 Likes

Yves,

Tried those things (polling interval to 5) and separate instances on the Myecobeeinit app. No luck. Made it through most of the day yesterday, but then in the evening it disconnected many many times. I awoke to similar messages that you did…

I have 3 “mode Change” apps for my main T-stat (Home, Away, Sleep), and 1 Mode Change for my Master Bedroom T-stat (Sleep), Plus one Away and one Resume App for the master bedroom working off of 2 motion sensors for a total of 3 apps for that one and 5 total across the 2 ecobees.

Might I have too many Interactions going?

Another interesting thing I noticed is that my Master Bedroom and Main T-Stats are going “Offline” intermittently, one at a time on the Ecobee app. To me, it seems that somehow the Oauth token being repeatedly used to log in to ecobee is forcing out the other t-stat?

I’m STRONGLY considering trying the multiple ecobee account route, although I know I’m going to lose my historical energy data on the ecobee website. For me, the whole point to switching to the Smart Si’s from the dumb thermostats was to bring motion sensor / mode functionality into the mix, so barring a solution to these issues, I’m considering buying 2 Ecobee 3’s and just isolating it from ST. Im sure that’s what Ecobee wants, but 500$ is a lot to drop after having dropped 300$ earlier this year. (Wish ecobee 3’s existed when I bought these)

Also despite all this frustration, I still like the idea of your code and stand by donating to your paypal… I think you did strong work here and its really unfortunate that it’s muddled by inherent issues with the API for the device.

1 Like

Similar scenario for me. Worked most of yesterday and cut out in the evening. It wouldn’t even let me log back in so I have hidden the notifications for now.

Seems like this may be an existing/known issue based on the thread but wanted to see if my issue are in-line with others.

Within the last few weeks I have started to get quite a few error notifications "MyEcobeeInit> too many exceptions/erros or unauthorized exception, doRequest>…

For a while I was able to re-login/authenticate and the issue was temporarily resolved. It would work okay after re-login/authenticate for varying amounts of time, sometimes a few days other times just over 24hrs.

Within last week the problem has gotten worse and I am receiving continuous error notifications, sometimes in excess of a dozen and hour. Even now when I re-login/authenticate the issue comes back within hours or even minuets. I have always left polling at default (which is 10min) and lately been using 30min polling (not sure why people need polling for Thermostats in seconds or anything <5min to be honest).

Would love to continue using the device type/ smatapp but I cannot if I continue to receive so many notifications. Case and point… here are all the errors I just received writing this!

@yvesracine Any help as to why I am getting all of these errors and how to resolve?

I am having the same issue. Today has been especially bad. So far this morning I’ve received not less than 50 of those messages.

I’ve been going through yvesracine codes and updating to see if it will help.

I’ll be watching this thread.

1 Like

Here are some earlier logs incase that helps. I will admit upfront I am not very tech savvy, so not entirely sure what the logs are saying, but always willing to roll my sleeves up and try something. Again would appreciate any help

4597a3a7-d698-481f-8e37-f4946d93d4fa ‎9‎:‎18‎:‎06‎ ‎AM: error groovyx.net.http.HttpResponseException: Internal Server Error @ line 1277

4597a3a7-d698-481f-8e37-f4946d93d4fa ‎9‎:‎18‎:‎06‎ ‎AM: debug doRequest>exception groovyx.net.http.HttpResponseException: Internal Server Error for %7B%22functions%22%3A%5B%7B%22type%22%3A%22setHold%22%2C%22params%22%3A%7B%22coolHoldTemp%22%3A810%2C%22heatHoldTemp%22%3A510%7D%7D%5D%2C%22selection%22%3A%7B%22selectionType%22%3A%22thermostats%22%2C%22selectionMatch%22%3A%22265227224905%22%7D%7D

970086f0-4e35-4217-a469-c929b3df373d ‎9‎:‎18‎:‎06‎ ‎AM: error groovyx.net.http.HttpResponseException: Internal Server Error @ line 1277

970086f0-4e35-4217-a469-c929b3df373d ‎9‎:‎18‎:‎06‎ ‎AM: debug doRequest>exception groovyx.net.http.HttpResponseException: Internal Server Error for %7B%22functions%22%3A%5B%7B%22type%22%3A%22setHold%22%2C%22params%22%3A%7B%22coolHoldTemp%22%3A810%2C%22heatHoldTemp%22%3A510%7D%7D%5D%2C%22selection%22%3A%7B%22selectionType%22%3A%22thermostats%22%2C%22selectionMatch%22%3A%22210250995779%22%7D%7D

970086f0-4e35-4217-a469-c929b3df373d ‎9‎:‎18‎:‎05‎ ‎AM: error groovyx.net.http.HttpResponseException: Internal Server Error @ line 1277

970086f0-4e35-4217-a469-c929b3df373d ‎9‎:‎18‎:‎05‎ ‎AM: debug doRequest>exception groovyx.net.http.HttpResponseException: Internal Server Error for %7B%22functions%22%3A%5B%7B%22type%22%3A%22setHold%22%2C%22params%22%3A%7B%22coolHoldTemp%22%3A810%2C%22heatHoldTemp%22%3A510%7D%7D%5D%2C%22selection%22%3A%7B%22selectionType%22%3A%22thermostats%22%2C%22selectionMatch%22%3A%22210250995779%22%7D%7D

Install his beta device type and smart app that he listed a few posts up. It hasn’t gotten rid of the issue but it’s helped. Otherwise, this is an issue for ST and Ecobee to fix it seems. Seems like there should be some direct communication between the two seeing as how they both advertise each other’s compatibility.

1 Like

Thanks @jarettp will give the beta device type a try now.

Hi @slagle, @jotto, @jarettp, @dvanzuiden,@stvdano,@benmctee

FYI, after some testing on my end, I have observed the following facts:

(1) Before the peak of connection issues that we’re all experiencing with my custom Ecobee Device now, I had been able to correct any connection issues by re-authenticating with ecobee, and this action would “reset” the connection and any connection issues would disappear after.

(2) Now, even if I try to “reset” the connection by re-authenticating with ecobee, the connection issues stick. The only way is to uninstall the Service Manager and delete the device to create another one.

Also, since yesterday, somebody has pointed out to me that the ecobee’s access token expiration time is now expressed in seconds (not in minutes like before)…

This is a recent change that was implemented just yesterday:

https://www.ecobee.com/home/developer/api/documentation/v1/change-log.shtml

The change does not explain all the connection issues in the last week, but it explains the fact that I can no longer ‘reset’ the connection with ecobee since yesterday.

There may be also more rate limiting done either on the ST or the ecobee side that I’m not aware of.

I implemented more defensive coding into My Ecobee Device, MyEcobeeInit and ecobee3RemoteSensorInit to avoid connection issues in the future.

MyEcobee device at home has been now stable for a while, and hopefully it will work also for anybody
who uses it.

Please let me know of any issues, especially with ecobee3RemoteSensorInit as I cannot test
it at home (I do not have any ecobee3’s remote sensors).

So, in order to correct their current connection issues, ST users need to

(1) Remove My Ecobee device and any ecobee3’s remote sensors from all smartapps

(2) Uninstall MyEcobeeInit, ecobee3RemoteSensorInit

(3) Get the latest MyEcobeeDevice, MyEcobeeInit and ecobee3RemoteSensorInit code at my main branch:

(4) Re-execute MyEcobeeInit and ecobee3RemoteSensorInit

Regards.

Thanks Yves. Trying now.

I was just about to uninstall it all for now and buy Ecobee 3s to replace my Si’s and remove it from ST all together. Lets see how this one goes.

Probably 250 error messages today. Wife wasn’t happy; I’m sure many of you can relate

@stvdano, in all my smartapps, you can disable notifications by saying ‘no’ to the following question at the last page:

	section("Notifications") {
		input "sendPushMessage", "enum", title: "Send a push notification?", metadata: [values: ["Yes", "No"]], required:
			false

Regards.

Yeah, I know… It’s not that i don’t want to know, its that I want it to work :slight_smile:

1 Like

Thanks for the update. Mine has been working with the beta I installed since yesterday. For now I’ll leave everything alone until that changes. Unless you’re saying that eventually this “seconds instead of minutes” thing is going to cause some issues.