Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[netatmo] Switch to Code Granting process #12726

Merged
merged 7 commits into from
May 20, 2022
Merged

Conversation

clinique
Copy link
Contributor

Based on the work done in the spotify binding.
This exposes a second servlet, so I refactor servlet handling in the binding.

Closing issue #12677

Signed-off-by: clinique [email protected]

@clinique clinique added enhancement An enhancement or new feature for an existing add-on (potentially) not backward compatible labels May 12, 2022
@clinique clinique self-assigned this May 12, 2022
@clinique
Copy link
Contributor Author

Current status : authentication flow works.
Reviewing servlet handling between authentication servlet and webhook.
Documentation to be updated (based on the great spotify readme file).

Breaking changes :

  • ApiBridgeHandler configuration parameters have changed.
  • webhook url will change

@lolodomo lolodomo added the work in progress A PR that is not yet ready to be merged label May 12, 2022
@lolodomo
Copy link
Contributor

@clinique : why saving technical data in thing configuration? The user will not be able to set them as they are provided by the API.
Why not keeping them only in memory? Of course, that will mean a new refresh token requested at each binding restart, but is it a problem?

@clinique
Copy link
Contributor Author

clinique commented May 13, 2022

@clinique : why saving technical data in thing configuration? The user will not be able to set them as they are provided by the API. Why not keeping them only in memory? Of course, that will mean a new refresh token requested at each binding restart, but is it a problem?

If you do not save them, then you've got to redo the approval process - not doable.
I'll double check, I think we can get rid of the code and maybe the redirectUri, but the token_refresh has to be stored.
Sure, the user can not set them the first time, but once he's got them, they can be used in things file directly.

@jlaur
Copy link
Contributor

jlaur commented May 13, 2022

@clinique : why saving technical data in thing configuration? The user will not be able to set them as they are provided by the API. Why not keeping them only in memory? Of course, that will mean a new refresh token requested at each binding restart, but is it a problem?

If you do not save them, then you've got to redo the approval process - not doable. I'll double check, I think we can get rid of the code and maybe the redirectUri, but the token_refresh has to be stored. Sure, the user can not set them the first time, but once he's got them, they can be used in things file directly.

Can you link to some documentation describing the authorization flow/API? I would like to understand this. Is this the new approach: https://dev.netatmo.com/apidocumentation/oauth?

@lolodomo
Copy link
Contributor

lolodomo commented May 13, 2022

And did you think about using OAuth2 provided by a package of the core framework?
Tokens are then stored in a dedicated json file. The homeconnect binding is using it. Probably also others bindings.

@clinique
Copy link
Contributor Author

@clinique : why saving technical data in thing configuration? The user will not be able to set them as they are provided by the API. Why not keeping them only in memory? Of course, that will mean a new refresh token requested at each binding restart, but is it a problem?

If you do not save them, then you've got to redo the approval process - not doable. I'll double check, I think we can get rid of the code and maybe the redirectUri, but the token_refresh has to be stored. Sure, the user can not set them the first time, but once he's got them, they can be used in things file directly.

Can you link to some documentation describing the authorization flow/API? I would like to understand this. Is this the new approach: https://dev.netatmo.com/apidocumentation/oauth?

Keeping the refresh token is enough.
The workflow is presented here, but it does not highlight how we should handle the process from one start to the other.

@clinique
Copy link
Contributor Author

clinique commented May 14, 2022

And did you think about using OAuth2 provided by a package of the core framework? Tokens are then stored in a dedicated json file. The homeconnect binding is using it.

It was my original plan but I had an issue with the answer provided by the API (see here). So we arrived here and there . But it still does not work. IIRW the core oauth is not able to reach the deserializer I provide.

@lolodomo
Copy link
Contributor

lolodomo commented May 15, 2022

It was my original plan but I had an issue with the answer provided by the API (see here). So we arrived here and there . But it still does not work. IIRW the core oauth is not able to reach the deserializer I provide.

Maybe we can debug what would be wrong in core?
Do you have a branch with the code relying on OH core OAuth2 client?

@J-N-K
Copy link
Member

J-N-K commented May 15, 2022

I believe that the core bundle must be able to create imports dynamically. This can be achieved by adding DynamicImport-Package: * to the manifest.

@clinique
Copy link
Contributor Author

It was my original plan but I had an issue with the answer provided by the API (see here). So we arrived here and there . But it still does not work. IIRW the core oauth is not able to reach the deserializer I provide.

Maybe we can debug what would be wrong in core? Do you have a branch with the code relying on OH core OAuth2 client?

unfortunately not, It was 2 years ago...

@lolodomo
Copy link
Contributor

We must keep in mind that it should be merged before 3.3 is released (end of June) to avoid a second breaking change for users and to have a working 3.3 binding in September when Netatmo will stop the old authentication method.

@clinique :please submit your last code if ready

@clinique
Copy link
Contributor Author

Not much time available this week, I'll do my best as soon as possible - or else, I leave the webhooks untouched, just to take care of code granting, without optimizing servlets.

@clinique clinique changed the title [netatmo][wip] Switch to Code Granting process [netatmo] Switch to Code Granting process May 18, 2022
@clinique clinique removed the work in progress A PR that is not yet ready to be merged label May 18, 2022
@clinique clinique added this to the 3.3 milestone May 18, 2022
@jlaur jlaur removed this from the 3.3 milestone May 18, 2022
Copy link
Contributor

@lolodomo lolodomo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review part 1 of 2

bundles/org.openhab.binding.netatmo/README.md Outdated Show resolved Hide resolved
bundles/org.openhab.binding.netatmo/README.md Outdated Show resolved Hide resolved
bundles/org.openhab.binding.netatmo/README.md Show resolved Hide resolved
@@ -330,8 +330,7 @@ thing-type.netatmo.wind.description = Wind sensor reporting wind angle and stren

conf-error-no-client-id = Cannot connect to Netatmo bridge as no client id is available in the configuration
conf-error-no-client-secret = Cannot connect to Netatmo bridge as no client secret is available in the configuration
conf-error-no-username = Cannot connect to Netatmo bridge as no username is available in the configuration
conf-error-no-password = Cannot connect to Netatmo bridge as no password is available in the configuration
conf-error-grant-needed = Configuration incomplete, please grant the binding to Netatmo Connect.
Copy link
Contributor

@lolodomo lolodomo May 18, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please run the i18n tool as there should be other changes (parameter refreshToken, username, password).

Copy link
Contributor Author

@clinique clinique May 18, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did it - that's weird.

Copy link
Contributor

@lolodomo lolodomo May 20, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I think I understand, this is not something new in this PR but something we missed when reviewing your PR for the new binding.
As you have no static things declared (in XML) linked to these configs, the i18n tool does produce nothing.
So you have no label/description for these configurations available in the translation file.
The solution would be to use @text in the config.xml file and add the corresponding entries in the default translation properties file.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be fixed in a next PR if we want to merge the current PR very soon.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...or by extending the translation tool to take this case in account ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tool can do nothing as it will know what key to produce. That is typically the case where you need to use @text/myparameterlabel and in this case, the tool will add the entry myparameterlabel in the properties file.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am going to create a PR for that.

Signed-off-by: clinique <[email protected]>
Copy link
Contributor

@robnielsen robnielsen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't forget to update the things/netatmo.things example.

Copy link
Contributor

@lolodomo lolodomo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review part 2 o f2

@lolodomo
Copy link
Contributor

As soon as you push an update with the resolved comments, I will test it.

Signed-off-by: clinique <[email protected]>
@robnielsen
Copy link
Contributor

@clinique, I built you latest code and was able to get it up and running. The only problem I ran into is the refresh token isn't optional for file based configurations.

@lolodomo
Copy link
Contributor

lolodomo commented May 20, 2022

@clinique, I built you latest code and was able to get it up and running.

Same for me, it is working.

Will see tomorrow if renewing is working.

@lolodomo
Copy link
Contributor

Can we elaborate how much it will be a breaking change for users that already moved to the new binding ?
For users using configuration files to setup things, as usual, this is not really a difficulty.
For users using UI to setup things, what does it mean ? They have to delete everything ? Only the account thing ? Maybe nothing ?

@clinique
Copy link
Contributor Author

For users using UI, deleting and recreating the Account thing should be enough.

@lolodomo
Copy link
Contributor

For users using UI, deleting and recreating the Account thing should be enough.

This can be done without removing all child things ?
All child things should then be reattached to the new bridge.
This would be a good news.

@lolodomo
Copy link
Contributor

@clinique: please answer to the last 2 open comments and then I will commit.
Regarding the missing translations, it could then be fixed in a separate PR.

Signed-off-by: clinique <[email protected]>
Copy link
Contributor

@lolodomo lolodomo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thank you

@lolodomo lolodomo merged commit 9632a0a into openhab:main May 20, 2022
@lolodomo lolodomo added this to the 3.3 milestone May 20, 2022
@lolodomo
Copy link
Contributor

The breaking change is already mentioned in 3.3 so there is nothing more to add for users that will upgrade from 3.2 to 3.3 in July.

For users upgrading from 3.3M5 to next 3.3M6 at end of month, the account thing will certainly be offline. I think we should mention in the forum topic that the account bridge thing has to be removed and created again, child things have to be attached again to the new bridge.

@clinique clinique deleted the netatmo_12677 branch May 20, 2022 11:38
@jlaur
Copy link
Contributor

jlaur commented May 20, 2022

@clinique - thank you! Authorization process went smooth (file-based configuration).

@openhab-bot
Copy link
Collaborator

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/netatmo-recreate-things/136451/2

andan67 pushed a commit to andan67/openhab-addons that referenced this pull request Nov 6, 2022
andrasU pushed a commit to andrasU/openhab-addons that referenced this pull request Nov 12, 2022
psmedley pushed a commit to psmedley/openhab-addons that referenced this pull request Feb 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement An enhancement or new feature for an existing add-on (potentially) not backward compatible
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants