Ok, now I’m seeing them. Not from the sensors, but from the thermostats itself.
Both thermostats I have show the same spikes at the same time.
The down spikes seem to indicate when the thermostat did the recent software update. My last one finally updated yesterday and I got a down spike for it. Not sure on the up spikes.
Has anyone noticed their ecobees dropping offline over the last few days?
I usually notice it when the temperature readings flatline, and that has happened for the third time now over the last two days.
Getting them back online is easy: I just need to disable and then re-enable the Ecobee account thing. The fact that everything resumes to working state tells me that nothing’s wrong with credentials and such.
Still not a viable solution, only a short-term fix.
Yes, I’m seeing it too. Not sure what’s going on, but this seems to happen with them from time to time.
The binding really should deal with the status code 14 by doing a token refresh. There must be an edge condition where the token expires before the refresh occurs.
2024-02-21 11:01:55.372 [DEBUG] [org.openhab.binding.ecobee.internal.api.EcobeeApi ] - API: Ecobee API returned unsuccessful status: code=14, message=Authentication token has expired. Refresh your tokens.
I haven’t looked at the code in quite a while. And, it turns out the code does check for status code 14 (ECOBEE_TOKEN_EXPIRED). And, then it calls isAuthorized() to try to refresh the token. But i must be doing something wrong because it clearly isn’t working the way I thought it would.
In this section of code, I would expect isExpired to return true if the token is expired or within 120 seconds of expiring. But that’s clearly not happening in this situation because I don’t see that DEBUG message in my logs. Maybe I don’t completely understand how isExpired works.
if (localAccessTokenResponse.isExpired(Instant.now(), TOKEN_EXPIRES_IN_BUFFER_SECONDS)) {
logger.debug("API: Token is expiring soon. Refresh it now");
localAccessTokenResponse = oAuthClientService.refreshToken();
}
I just tried to install this version (to get the fix above) of the Ecobee binding on OH 4.1.0 and it wouldn’t leave WAITING. Must be a conflict with 4.1.0 with 4.3.0 with this binding.
org.openhab.binding.ecobee-4.3.0-20240223.053829-62.jar
Best, Jay
I’m not so sure, it might have something to do with Ecobee.
If your binding has issues renewing the token, it would go offline regularly (no idea how long a token is valid). But it hasn’t happened for months and now three times over the past few days.
Yeah, I’m sure Ecobee is the root cause, but the binding should recover by refreshing the token.
I seem to recall the life of a token is 1 hour, hence the 120 seconds of “wiggle room” in the call to isExpired. I just don’t understand why isExpired is not returning true based on how the following should evaluate, where createdOn is the time when the token was last refreshed, expiresIn is 3600, tokenExpiresInBuffer is 120, and givenTime is the current time. I must be missing something.
createdOn.plusSeconds(expiresIn).minusSeconds(tokenExpiresInBuffer).isBefore(givenTime)
Maybe i should just brute force close and recreate the OAuthClientService when I get the code 14. That’s essentially what happens when you disable/enable the account bridge thing.
Ok, I made that change to close and recreate the OAuthClientService upon receipt of an error code 14. Let’s hope I don’t have to wait months for Ecobee to hiccup again. lol
Mark,
sounds good, thank you very much!
I’ll certainly try it out.
Will you push that to the marketplace so it auto-updates? I have to admit I’m not sure how quickly that happens. I’m currently on v4.1.1.
Somehow I thought those Ecobee tokens would have a longer lifetime, like months. No idea why they would want to refresh the token every hour, honestly.
Yes I’ll do that. But first I need to figure out how to do it. 
Probably will get posted sometime tomorrow.
Access token is 1 hour. This is pretty typical for OAuth from what I’ve experienced. Refresh token is a year (I think)
Here it is. I hope I did it right.
1 Like
Thanks!
I’ll watch for if that auto-updates sometime or if I need to manually uninstall the binding and use the jar file.
@Tron I got an error code 14 yesterday, Feb 25, at 9:35 am US EST. Looks like my recent change to close and recreate the OAuthClientService successfully recovered from the error. I don’t see any downside to the change, so I’m going to remove the extra debug, let it run for a while longer, then submit the PR.
When it happens, you will see something in your logs like this.
2024-02-25 09:35:29.821 [DEBUG] [org.openhab.binding.ecobee.internal.api.EcobeeApi ] - API: Perform thermostat summary query
2024-02-25 09:35:30.389 [DEBUG] [org.openhab.binding.ecobee.internal.api.EcobeeApi ] - API: Ecobee API returned unsuccessful status: code=14, message=Authentication token has expired. Refresh your tokens.
2024-02-25 09:35:30.389 [DEBUG] [org.openhab.binding.ecobee.internal.api.EcobeeApi ] - API: Unable to complete API call because token is expired. Try to refresh the token...
2024-02-25 09:35:30.390 [DEBUG] [org.openhab.binding.ecobee.internal.api.EcobeeApi ] - API: CLOSING OAuthClientService
2024-02-25 09:35:30.390 [DEBUG] [org.openhab.binding.ecobee.internal.api.EcobeeApi ] - API: Closing OAuth Client Service for ecobee:account:account
2024-02-25 09:35:30.390 [DEBUG] [org.openhab.binding.ecobee.internal.api.EcobeeApi ] - API: CREATING OAuthClientService
2024-02-25 09:35:30.390 [DEBUG] [org.openhab.binding.ecobee.internal.api.EcobeeApi ] - API: Creating OAuth Client Service for ecobee:account:account
2024-02-25 09:35:30.390 [DEBUG] [org.openhab.binding.ecobee.internal.api.EcobeeApi ] - API: CALLING isAuthorized
2024-02-25 09:35:30.390 [DEBUG] [org.openhab.binding.ecobee.internal.api.EcobeeAuth] - EcobeeAuth: Change state from NEED_PIN to COMPLETE
Looks good, thanks!
By “submitting the PR” you mean the Openhab “Marketplace” repository?
What I meant was that would submit a PR to have the change included in the distribution.
I may just leave the marketplace version there for now since there’s no harm to the extra debug logging.
Understood.
Probably better to update the marketplace version with one without debug information, though.
My logs are big enough as they are…although I’m not sure how “chatty” the binding is in debug mode.
~25 MB every 13-14 days. And this won’t change that much because the error code 14 doesn’t occur that often.
I agree, but the debug mode would apply to the whole binding, not only the error 14 notifications.
I mean, sure, one can always disable it in karaf (or maybe even in the MainUI), but I’d suggest that the default log level should be “WARN”.
I updated the marketplace with the latest version. Barring any other changes, this is what I will submit for inclusion in the distribution.
1 Like