Access Token Expired

[Kositch]

Describe the bug
After a few days homebridge-eveatmo plugin stopped updating Netatmo weatherstation values into the HomeKit - in logs errors that Access Token Expired (new authentication method used and worked after setting it up 2 days before). Restarted homebridge and Netatmo values started updating correctly into Homekit. See screenshot.

Version you use

• homebridge version 1.5.1
• node version 18.12.0
• plugin version: 1.0.1

[jeloneal]

Same problem here. Logs states that refresh token is not valid.

Creating now token on netatmo page and even updating the other authentication keys did not help.

[Kositch]

Same problem here. Logs states that refresh token is not valid.

Creating now token on netatmo page and even updating the other authentication keys did not help.

For me what helped temporarily was to restart child bridge in which I am running the plugin. Values are updating now, but I suppose it is only a matter of time until stops and will require Access token renewal again.

[jeloneal]

For me what helped temporarily was to restart child bridge in which I am running the plugin.

I tried that first, but didn’t work for me. Thats why I tried to update the keys and tokens one after another.

[jeloneal]

That what I see in log when updating token in config with a freshly created refresh token. I granted all available scopes to make sure to not miss one.

[jeloneal]

Ok, fiddled around a bit more and found out that netatmo-token.json was not updated automatically. Once I deleted the old existing JSON and restarted the child bridge everything worekd again. The plugin created a new JSON file with the correct tokens.

[mtressl]

Same behaviour here:

• homebridge version 1.6.0
• node version 18.12.1
• plugin version: 1.0.1

homebridge-eveatmo plugin running in a child bridge.

Did a touch netatmo-token.json but this did not help, child bridge did not start.
Only after rm netatmo-token.json the child bridge did restart.

[Kositch]

Yes, it is a definitely bug, let's wait when dev will be have a time to look into that.

[TheRock89]

Same problem here. Meanwhile I have disabled the plugin

[tne7laa]

Same here. Disabled.

[palasinio]

In my case it helped just to restart the Homebridge instance twice. Once to get the new credentials, the second time to get it work. There seems to be an issue with the logical order after retrieving the keys or the keys are written to disk, but the variables are not set. Duno.

[Kositch]

In my case it helped just to restart the Homebridge instance twice. Once to get the new credentials, the second time to get it work. There seems to be an issue with the logical order after retrieving the keys or the keys are written to disk, but the variables are not set. Duno.

Yes, I can confirm that - today it got stuck again with Access Token Expired and I did restart of child homebridge once - it did not started, so I did it for second time and it is running now. Hope it will be fixed soon.

[vincentbls]

In my case after an update of credentials (cliend id, client secret, refresh token read_station) :
[eveatmo platform] WARN - Netatmo: Error: getHealthyHomeCoachData error: Application does not have the good scope rights
[homebridge-eveatmo] This plugin is taking long time to load and preventing Homebridge from starting. See https://homebridge.io/w/JtMGR for more info

[The-Paw]

Same problem here :-((

[skrollme]

Hello everyone,
I'm currently now sure how and/or why this happens and - us usual - it does not happen in my setup. So it is hard to reproduce for debugging.

Could be a problem with permissions (to write) the file, which stores the tokens. But then it also shouldn't have worked on the first run as well. But it could be a test to chmod 777 the file. Yes, I know, this is bad, but it could help sorting this possibility out. This could explain what @jeloneal wrote:

Ok, fiddled around a bit more and found out that netatmo-token.json was not updated automatically. Once I deleted the old existing JSON and restarted the child bridge everything worekd again. The plugin created a new JSON file with the correct tokens.

Since I do not use child-bridges or other fancy stuff I'm not sure if these have any side-effects here.

I'm in general not very happy with the netatmo-token.json file which stores the refresh- and access-token but it was the easiest way in the remaining time before netatmo switched their auth mechanism.

And about what @vincentbls wrote:

In my case after an update of credentials (cliend id, client secret, refresh token read_station)

On my first tests I had problems when I used the minimal set of permission-scopes (only read_station). Since then I created a new app and granted all(!) permissions. Should not be the problem here, but I just wanted to let you know.

[skrollme]

One addition to the "authentication switch" topic:
The old mechanism (password grant) is still alive in the Netatmo API. I'm already thinking about bringing it back to the homebridge-eveatmo plugin and make it accessible via a config-value.

Although the Netatmo API was never really stable or reliable, at least the old auth mechanism worked and did not need to store new tokens every now and then.

[accolon]

I had the "Access token expired" problem twice during the last weeks on my Homebridge. I'm not using fancy stuff either (just a plain HB installation running on Ubuntu LTS on a small x64 server).

I already granted all permissions for the token on dev.netatmo.com during the initial setup.

The file owner/group for netatmo-token.json is set to homebridge:homebridge, which is the user used by HB on my server. Looking at the file's timestamp, I can see that it was updated just today, so it seems to be writable just fine.

When I got the "token expired" error a few days ago, I could see that netatmo-token.json had remained untouched for a few days. Simply deleting the file and restarting HB fixed the problem.

As far as I can see, it does not seem like a permissions problem. It seems like the token update simply stops after some time. I'll keep an eye on it.

[julien94800]

Hello, keep in mind than Netatmo servers had lot of issues these past two weeks! Several break down and so lost of access. That could explain things. From my side I had issues too during these breakdown, but then it's ok as soon as their servers are working

[skrollme]

Hello, keep in mind than Netatmo servers had lot of issues these past two weeks! Several break down and so lost of access. That could explain things. From my side I had issues too during these breakdown, but then it's ok as soon as their servers are working

Good point. If the API is down when the plugin tries to fetch a new token, there is a problem because the existing tokens have expired and it may be not possible to fetch a new token.

I'm already preparing a new version (currently beta) and will also adapt when the token will be refreshed (doing it earlier to have more time, when it fails).

[jostrasser]

I'm already preparing a new version (currently beta) and will also adapt when the token will be refreshed (doing it earlier to have more time, when it fails).

Hi @skrollme
I saw that you released v1.1.0-beta1:

Readded the password grant type and lets you choose which one you want to use.

How it it possible to configure the grant type? Are users which are already migrated to the new auth (using a token) impacted after upgrading to 1.1.0?

[skrollme]

How it it possible to configure the grant type?

Please see the already updated Readme in the beta tag's branch, @jostrasser : https://github.com/skrollme/homebridge-eveatmo/tree/v1.1.0-beta1#readme

Are users which are already migrated to the new auth (using a token) impacted after upgrading to 1.1.0?

If you already upgrade to the refresh_token grant, you should not be affected, since refresh_token will be the new default grant_type in 1.1.0

[jostrasser]

Please see the already updated Readme in the beta tag's branch, @jostrasser : https://github.com/skrollme/homebridge-eveatmo/tree/v1.1.0-beta1#readme

If you already upgrade to the refresh_token grant, you should not be affected, since refresh_token will be the new default grant_type in 1.1.0

Perfect... thanks @skrollme !

[palasinio]

How will it survive update?Shouldn‘t it detect itself what auth. is used depending on username or token is set in configuration?Am 17.12.2022 um 14:43 schrieb Sebastian K ***@***.***>: How it it possible to configure the grant type? Are users which are already migrated to the new auth (using a token) impacted after upgrading to 1.1.0? Please see the already updated Readme in the beta tag's branch: https://github.com/skrollme/homebridge-eveatmo/tree/v1.1.0-beta1#readme —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[jostrasser]

@palasinio

How will it survive update?Shouldn‘t it detect itself what auth. is used depending on username or token is set in configuration?

I updated from 1.0.0 to 1.1.0-b1 and didn't saw any impact after updating.

However, I added "grant_type": "refresh_token" to the config.json to be on the safe side.

[skrollme]

How will it survive update?Shouldn‘t it detect itself what auth. is used depending on username or token is set in configuration?

"grant_type": "refresh_token" is the new default, so it is assumed if you do not set a grant_type at all in your config.

And there is no auto-detection. If you want to use password-grant you have to set username, password AND grant_type.

[Tralcan]

Hi everyone... I was the same problem with 1.0.1 version and always I back to 0.6.5 version (this use login y password), but today reading this blog... I tried desinstall homebridge-eveatmo and install again with version 1.0.1 and it worked perfect...

[jostrasser]

Hi @skrollme
Official update from Netatmo today.

You are well prepared ;)

Authentication update

Dear Netatmo developer,
As of today, when you refresh an Access Token using the associated endpoint https://api.netatmo.com/oauth2/token, Netatmo servers respond with a couple of tokens : an Access Token and a Refresh Token.

If the previous Access Token is still valid, the newly returned access token is identical but its expiration time is extended for 3 hours.

In any case, the refresh token is not renewed.

Starting from the 17/04/2023, this behavior will change to to be compliant with the recommendations of the RFC of the OAuth2 Authorization Framework (section 10.4) and improving the security of the data of our users.

When refreshing tokens, Access Token and Refresh Token will be automatically renewed and former tokens invalidated.

What does it means for me ?

If you were already updating the tokens provided when refreshing your tokens, this change will not impact you.

If you do not update the refresh token when refreshing your Access Token, your users will be disconnected after 3 hours as the former tokens will become invalidated.

To fix it, you need to update the tokens as soon as you get the newly generated ones.

Sincerely,

Legrand - Netatmo - Bticino

[mrmaximas]

@jostrasser what are we gonna do with the deadline on 29 May?

[jostrasser]

@jostrasser what are we gonna do with the deadline on 29 May?

I think the latest implementation can maybe handle the upcoming change of Netatmo. @skrollme can you confirm this? Thanks!

Related to:
#77 (comment)

[skrollme]

I think the latest implementation can maybe handle the upcoming change of Netatmo. @skrollme can you confirm this? Thanks!

Both access_token and refresh_token are stored every time they are fetched, so yes - the plugin should be ready for the changes.

[jostrasser]

I think the latest implementation can maybe handle the upcoming change of Netatmo. @skrollme can you confirm this? Thanks!

Both access_token and refresh_token are stored every time they are fetched, so yes - the plugin should be ready for the changes.

Thanks for the confirmation! :)