Ecobee 3 Remote Sensors into ST

Devices & Integrations Connected Things
184

@gwithers105, @swamplynx and others,

The loss of ecobee authorization (and the need to re-authenticate) that you’ve been experiencing in the past weeks seems to be linked to 2 probable causes:

(1) ecobee servers seem to be less reliable by intermittence

I submitted a question to ecobee support about this issue. For the moment, they are saying that
there is no issue on their end. But, there is another ecobee developer who is
experiencing something similar to us (premature loss of authorization).

http://developer.ecobee.com/api/topics/ecobee-servers-outage

(2) There seems to be some scheduling issues on the ST side

Before last week, my Ecobee Device was pretty stable, but since some time last week, it looks
like there are some scheduling issues related to the refresh_tokens() method.

I’ve opened a SmartThing support ticket about it. In my logs, I see the same events sometimes
firing once, and other times, firing twice. As it’s related to the refresh_tokens() calls, ecobee
is seeing two close calls to refresh_tokens with few milliseconds apart, which causes some exceptions.

Here is a trace for Today in my IDE:

015-05-19 4:00:02.956 PM UTC
4 hours ago DEVICE verboseTrace refresh_tokens>expire in 59 m…
My ecobee Kitchen verbose
trace is refresh_tokens>expire in 59 minutes true
2015-05-19 4:00:02.898 PM UTC
4 hours ago COMMAND refreshChildTokens 2015-05-19 4:00:02.448 PM UTC
4 hours ago APP_COMMAND refreshChildTokens My ecobee Init sent refreshChildTokens command to My ecobee Kitchen true
2015-05-19 4:00:02.052 PM UTC

4 hours ago DEVICE verboseTrace doRequest>about to get with u… My ecobee Kitchen verbose trace is doRequest>about to get with uri https://api.ecobee.com/1/thermostat?format=json&body={"… true
2015-05-19 4:00:02.025 PM UTC
4 hours ago DEVICE verboseTrace api> about to call doRequest … My ecobee Kitchen verbose trace is api> about to call doRequest with (unencoded) args = {“selection”:{“selectionType”:"thermos… true

2015-05-19 4:00:01.973 PM UTC 4 hours ago DEVICE verboseTrace refresh_tokens>expire in 59 m... My ecobee Kitchen verbose trace is refresh_tokens>expire in 59 minutes true

2015-05-19 4:00:01.912 PM UTC
4 hours ago COMMAND refreshChildTokens

2015-05-19 4:00:01.760 PM UTC
4 hours ago APP_COMMAND refreshChildTokens My ecobee Init sent refreshChildTokens command to My ecobee Kitchen
true

And, sometimes, just once such as today at 3:00 pm UTC:

2015-05-19 3:00:05.451 PM UTC
5 hours ago DEVICE verboseTrace refresh_tokens>expire in 59 m… My ecobee Kitchen verbose trace is refresh_tokens>expire in 59 minutes true
2015-05-19 3:00:05.438 PM UTC

5 hours ago COMMAND refreshChildTokens 2015-05-19 3:00:05.225 PM UTC
5 hours ago APP_COMMAND refreshChildTokens My ecobee Init sent refreshChildTokens command to My ecobee Kitchen

There is a related ST thread about it:

I'll you let you know of any development on both fronts.

P.S. If you’re still experiencing connection loss with events firing twice in your events list (under the ST IDE), please contact SmartThings about it to increase this issue visibility. You’d need to set
the trace input parameter for My Ecobee Device to true temporarily to see the related events in your events list.

 Regards.
185

OK, the token refresh issue is causing all sorts of issues again. The logs are littered with this kind of error many times a day. It appears to be the dreaded “refresh_tokens>exception…Unauthorized…” issue. Even when I reauthorized the thermostats via the Init app, it died out with the refresh token error mere minutes later. Unfortunately it is making the Ecobee integration unusable. If the answer is to wait for ST to fix the double execution issue, I fear that is not likely to happen any time soon. There is a long list of items promised and not followed through on that are more than a year old. Presuming that is the case, are we simply dead in the water? The issue is out of my abilities to figure out. I can open a ST ticket but I doubt anything will come of it as I can’t really describe what is going on.

186

Hi @gwithers105,

You’re right that ST may take a while before correcting the double execution issue.

FYI, in the meantime, I just implemented a workaround that should (hopefully) avoid the unauthorized exception.

Please update the device type based on the same procedure below, and let me know how it goes.

(1)Grab the latest version of MyEcobee Device at github:

Save and Publish.

(2) Clear your cache as the old Device may be cached

On Android, you’d need to go to settings/apps/smartthings and clear cache.

On iOS, you’d need to uninstall the smartThings app and reinstall it.

Regards.

P.S. On my side, I don’t see the double execution issue in my logs since yesterday (after I opened a ST ticket). So,
you may want to open a support ticket with SmartThings as they are converting users to a new scheduler (and this may cause this very issue).

1 Like
187

@yvesracine I did uncomment that code and indeed the humidity is appearing in the tile for the thermostat.

Thanks!

1 Like
188

I will give the new device type a try. I also submitted an email to support at ST to see if they can do some magic on the back end to help out as well.

189

@gwithers105, just fyi, even if you have unauthorized exceptions in the logs, it does not mean that you have to re-authorize with ecobee.

I had the same issue yesterday, my logs were full of unauthorized exceptions, but My Ecobee Device was still able to recover from them, and get the data from the ecobee servers…

Hopefully, the workaround that I’ve implemented will make the code even more robust and avoid these exceptions.

On my side, My ecobee Device now works flawlessly as the double execution (events firing twice) of refresh_tokens() is now over. It may or not be related to my open ST support ticket, but I would
recommend to open one if you still have this issue.

1 Like
191

Hi Yves,

That is true but it did becoming “broken” today where ST didn’t get updated info from Ecobee. I assume due to the token issue. I did get a response on my support ticket and they mentioned that they have not done anything on the backend to have fixed the double execution as they see that it fixed itself prior to them doing anything. So I don’t think it was a change on the back end that we can point to as the fix. As long as it works…

192

Quick Update.

It appears the “refresh_tokens>exception” issue has not been solved and a new one is showing up as well. The new one is a “doRequest>exception groovyx.net.http.HttpResonseException: Internal Server Error, Internal Server Error for null”. The errors can show dozens of times in an hour and then none for several hours. Either way, communication between ST and Ecobee was lost overnight with a ton of these errors. Reauth in Init app has fixed the connectivity issue (temporarily) but it seems to break every night after working during the day.

193

Hello @gwithers105, just make sure that your My Ecobee device type is saved and published in the IDE (under https://graph.api.smartthings.com/ide/devices).

Also, did you clear your cache following the latest code update?

The new code should avoid ST calling refresh_tokens() twice.

If it’s still the case, please PM me the logs.

If you are on iOS, this means uninstalling the SmartThings app and resinstalling it as there is now way to
clear the cache like Android.

P.S. And, also please do a follow up on your ST about the double execution ticket when you can.

194

Hi Yves,

Yes I cleared the cache after I updated the device type (published as well of course) and I am on Android. Perhaps I will just remove all the ecobee stuff (it is a pain because of how many I have and how I have them integrated into all sorts of things) and start fresh as things still seem to be odd. I can get the logs to you as well but I need to look into it with more detail.

195

Hello @gwithers105, before restarting from scratch, please PM me the logs as I don’t quite understand why
you are still having the double execution of refresh_tokens().

Regards.

196

The issues occurred at 5:00 AM, 5:17 AM, 5:20 AM, 5:30 AM EDT and again at 7:40 AM EDT on most of my thermostats with the same sequence of errors. Poll command (remote sensor Init issued), refresh_tokens error, doRequest>exception. The refresh_tokens error followed by the doRequest>exception would then repeat two or so times. All these activities/errors would occur within a 1 second or so. The times are not all the same for all thermostats but there is a good amount of overlap.

I am not sure this is the double execution thing.

I am also seeing an app execution timeout error @line 391 occasionally as well.

197

@gwithers105, you can PM me the events list or your logs for that timeframe and I will have a look at them.

Did you try to clear your cache again? Sometimes, the cached device is persistent.
Bye.

198

I have cleared the cache again as well.

These errors did just happen moments ago right after the remoteInit for this thermostat sent a poll command (one every 20 minutes currently)

 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 12:00:09 PM: debug doRequest>exception 
groovyx.net.http.HttpResponseException: Internal Server Error, Internal Server Error for null
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 12:00:09 PM: debug doRequest>exception    
groovyx.net.http.HttpResponseException: Internal Server Error, Internal Server Error for null
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 12:00:08 PM: debug doRequest>exception  
groovyx.net.http.HttpResponseException: Internal Server Error, Internal Server Error for null
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 12:00:07 PM: debug doRequest>exception   
groovyx.net.http.HttpResponseException: Internal Server Error, Internal Server Error for null
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 12:00:06 PM: debug doRequest>exception   
groovyx.net.http.HttpResponseException: Internal Server Error, Internal Server Error for null
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 12:00:06 PM: debug doRequest>exception    
groovyx.net.http.HttpResponseException: Internal Server Error, Internal Server Error for null

I can also add I am getting the same errors for the single smartSi thermostat I have and I am getting these errors without any remoteInit program calling a poll command (as this thermostat does not have the capability for remote sensors).

199

@yvesracine

After update I see the Ecobee remote sensor (built in) unit reporting humidity but not the remote sensors.

200

@Drewbert34,

Just to be sure that you have the latest release, please do the following (the usual procedure):

(1)Grab the latest version of MyEcobee Device at github:

Save and Publish.

(2) Clear your cache as the old Device may be cached

Kill your smartThings app if running.

On Android, you’d need to go to settings/apps/smartthings and clear cache.

On iOS, you’d need to uninstall the smartThings app and reinstall it.

(3) Update the ecobee3RemoteSensorInit smartapp

Grab the latest code at

Save and publish.

P.S. If it still does not work, please PM me the logs of the ecobee3RemoteSensorInit in the IDE
(https://graph.api.smartthings.com/ide/logs)

Thnx for your patience.

201

So I totally missed that the device type had to be updated as well…my apologies! :smile:

202

@Drewbert34, normally, just updating the smartapp is enough, but I just want to make sure that we have a good baseline from the start.

And, PM me the logs if you don’t have any humidity values. According to @storageanarchy’s testing, it should work now (unless you have a different firmware version between the 2).

Regards.

203

I can add that the humidity is working for the remoteInit generated temps sensors for the Ecobee3 but only for the temp sensor created for the main unit itself. The remote sensor temp devices created by the remoteInit still does not populate humidty. It is “–”. I think there has been a miscommunication as to what is working and is not for humidity. Temp device for the thermostat itself is working, temp device for any remote sensors is not.

1 Like
204

I believe I’m not seeing the values update because while away from home those sensors in question I’ve chosen not to be inputs of the “Away” comfort schedule.

If my assumption is correct, once home those sensors should then report humidity.