Ecobee binding v2

[Tron (Michael Frotscher)]

@mhilbush

But i must be doing something wrong because it clearly isn’t working the way I thought it would.

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.

[mhilbush (Mark)]

@Tron

I’m not so sure, it might have something to do with Ecobee.

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.

[mhilbush (Mark)]

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

[Tron (Michael Frotscher)]

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.

[mhilbush (Mark)]

@Tron

Will you push that to the marketplace so it auto-updates?

Yes I’ll do that. But first I need to figure out how to do it. Probably will get posted sometime tomorrow.

@Tron

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.

Access token is 1 hour. This is pretty typical for OAuth from what I’ve experienced. Refresh token is a year (I think)

[mhilbush (Mark)]

Here it is. I hope I did it right.

Ecobee Binding (beta)

[Ecobee_logo] Supports Ecobee’s line of smart thermostats. This is an experimental version that attempts to better handle the case where the Ecobee API unexcepectedly returns an error code 14 (Access Token Expired). Instead of trying to refresh the token, which doesn’t seem to work, the binding closes and recreates the OAuthClientService upon receipt of the error code 14. Changelog Version 0.1 includes potential for for error code 14 includes extra debug info Resources Binding jar Source C…

[Tron (Michael Frotscher)]

Thanks!
I’ll watch for if that auto-updates sometime or if I need to manually uninstall the binding and use the jar file.

[mhilbush (Mark)]

@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

[Tron (Michael Frotscher)]

Looks good, thanks!
By “submitting the PR” you mean the Openhab “Marketplace” repository?

[mhilbush (Mark)]

@Tron

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.

[Tron (Michael Frotscher)]

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.

[mhilbush (Mark)]

@Tron

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.

[Tron (Michael Frotscher)]

@mhilbush

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”.

[mhilbush (Mark)]

I updated the marketplace with the latest version. Barring any other changes, this is what I will submit for inclusion in the distribution.

[jwiseman (Mr. Wiseman (OH 4.2 Snapshot on Pi4))]

@mhilbush

I updated the marketplace with the latest version.

I can’t get your 4.2.x version to install on OH 4.1.0. It sits in Waiting state at the Karaf level. This was the same result as trying 4.3.x a week ago.

There must be something fundamental different with the core from 4.1 to 4.2 for the Ecobee binding.

Oh well, Jay

[Tron (Michael Frotscher)]

I’ll try tonight and give feedback. I’m also on 4.1.0 stable.

[mhilbush (Mark)]

@jwiseman

There must be something fundamental different with the core from 4.1 to 4.2 for the Ecobee binding.

Do you see anything in the console if you try to restart the binding? There must be a version change for one of the dependencies between 4.1 and 4.2.

[jwiseman (Mr. Wiseman (OH 4.2 Snapshot on Pi4))]

@mhilbush

There must be a version change for one of the dependencies between 4.1 and 4.2

I’m backing my entire system up and upgrading to 4.2.x and will provide feedback later on.

Best, Jay

[Tron (Michael Frotscher)]

Ok, so who wants to know, I uninstalled the old binding via Marketplace and placed the new .jar into /usr/share/openhab/addons. This is the result:

openhab> bundle:list | grep Ecobee                                                                                                                                       
310 │ Active │  80 │ 4.2.0.202402261643     │ openHAB Add-ons :: Bundles :: Ecobee Binding

I’m on OH 4.1.1, btw.

[jwiseman (Mr. Wiseman (OH 4.2 Snapshot on Pi4))]

@Tron

new .jar

Can you post the direct link for it vs. me grabbing it from marketplace?

I’d like to do the same as you.

Best, Jay