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

Thanks for all of your hard work. I’ve had my E3 since launch and got the ST v2 hub at launch. I was frustrated with the long delay with the E3 before away mode is started. I tried IFTTT and Life360 to control the E3 when my family was away vs. home, but it was very unreliable. Now with ST and your Smartapps and Device settings I hope this will finally be the best fit. Time will tell as I just got it set up tonight. Thanks!

This is great and worked flawlessly with my new Ecobee 3. I do have a concern though.

The app itself allows for a lot of customized control over the Ecobee and one can accidentally shift the unit from heat to cool, etc. I actually don’t intend to use SmartThings to really change those settings, although I would like it to pull those current values. Something simple like shifting the temp up or down and then just read-only for everything else in the main app would be great. I would still like the SmartApps like changemode and resumeprog to work of course as well.

Is there a way to make a lite version of this? The Weather forecast, changing of heat/cool modes, is just too much information on screen and too much to mess up by other users. One series of buttons for setting temp would be great as well instead of a separate one for heat and cool.

Just a thought if you have some time.

@stvbll,

When the ST UI will allow HTML dynamic tiles, then it will be possible to customize a lite version…

Till then, I don’t intend to make any more changes to the UI.

And, please support the developer :grinning:
Regards.

I’ve been using your Ecobee3 integration for a few months. Recently, my smartthings app was not able to control the ecobee3 (can’t change temperature or mode), so I went to re-initialize it. It came back with a huge JSON error page after entering my login information. I can’t figure out how to copy and paste it, but looking through it, it appears that the username, full name, and e-mail are not being sent:

java.util.concurrent.ExecutionException: grails.validation.ValdiationException: Validation failed:
- Field error in object 'physicalgraph.auth.LazyCreateUserCommand' on field 'username': rejected value [];....
- Field error in object 'physicalgraph.auth.LazyCreateUserCommand' on field 'fullName': rejected value [null];....
- Field error in object 'physicalgraph.auth.LazyCreateUserCommand' on field 'email': rejected value [null];....

I went through and updated all of my SmartApps (specifically paying attention to myEcobeeInit) from the most current GitHub version, published, ensured OAuth was checked. Then I attempted to re-run the myEcobeeInit from the phone, same problem. I was then going to remove all things Ecobee from the SmartThings app, and when I try to press the big red Remove button, I get ‘deleteObserver onError: %s’ flash across the top of the screen. So, now I have a smart app that won’t work anymore, nor can I remove.

Do you have any idea what is going on?

Thanks!!
Ben

Hi @benmctee,

  1. For your username, fullname, email issues please contact ST support as this is an error related to
    your ST physical graph. Your graph seems corrupted and only ST support can fix it. This is not related to MyEcobee device as I do not use those fields.

  2. If you want to uninstall myEcobeeInit, please see troubleshooting (item no 8) at the ST community wiki

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

In brief, like any other ST devices, you need to remove MyEcobee device from any other smartapps before uninstalling MyEcobeeInit and deleting the device (i.e. uninstalling MyEcobeeInit will delete
the device).

Regards.

I’ve sadly had to uninstall this app. I can’t, for the life of me, keep it logged in for more than a few hours at a time. It’s too unreliable at this point. I fully understand the token issue but I can’t live with the constant notifications to log back in and having to constantly check if the app actually changed my thermostat comfort setting. If you can find a way of getting this issue resolved please post back and I’ll give it another go and absolutely “support the developer”.

Thanks,

Jarett

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