Store access token in entry for Fyta

[dontinelli]

Proposed change

Save the access_token and its expiration received from the API in ConfigEntry an load it in async_setup_entry to reduce unnecessary login-calls to the API.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Deprecation (breaking change to happen in the future)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• I have followed the perfect PR recommendations
• The code has been formatted using Ruff (ruff format homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

- [ ] Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

- [ ] The manifest file has all fields filled out correctly.
Updated and included derived files by running: python3 -m script.hassfest.
- [ ] New or updated dependencies have been added to requirements_all.txt.
Updated by running python3 -m script.gen_requirements_all.
- [ ] For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
- [ ] Untested files have been added to .coveragerc.

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[joostlek]

You can use a minor version config entry migration for this. This way you create a central place where you update the config entry.

[dontinelli]

You can use a minor version config entry migration for this. This way you create a central place where you update the config entry.

Thank you for the hint, done. Is it then save to remove the following code (respectively change it to expiration = entry.data["expiration"] or should I leave it to catch possible errors?

    expiration: datetime | None = (
        datetime.fromisoformat(entry.data.get("expiration", "")).astimezone(
            ZoneInfo(tz)
        )
        if "expiration" in entry.data
        else None
    )

[joostlek]

Minor version, not a major version. Minor versions keep working after a restore of a version before this. Major versions don't, and this change doesn't affect the working on old versions

[joostlek]

I think you can always expect an expiration after this migration

[dontinelli]

I think you can always expect an expiration after this migration

Yes, sure. But this was not my question. Expiration is catched in coordinator. Question was, if I can assume correct expiration value in config entry or if I should leave the saveguard there.

[joostlek]

What safeguard are you exactly talking about? In the code of your previous comment I see 2 about expiration not being in entry data, maybe I'm missing it

[dontinelli]

What safeguard are you exactly talking about? In the code of your previous comment I see 2 about expiration not being in entry data, maybe I'm missing it
I'm asking, if this is still needed:

    expiration: datetime | None = (
        datetime.fromisoformat(entry.data.get("expiration", "")).astimezone(
            ZoneInfo(tz)
        )
        if "expiration" in entry.data
        else None
    )

Or if I should just use expiration = entry.data["expiration"]

[joostlek]

But that's what I meant, after the migration is run, you can expect expiration to be there in entry.data

[joostlek]

I'm wondering 2 things. What's the value of expiration? The Epoch? Isn't that always UTC?

How long is a token valid? Can we get a new one without username/password?

[dontinelli]

I'm wondering 2 things. What's the value of expiration? The Epoch? Isn't that always UTC?

The API returns a validity in seconds (cf. below), which is then added to the current time in fyta_cli: datetime.now() + timedelta(seconds=int(json_response["expires_in"]))
According to my understanding, now() returns local time and not UTC.

How long is a token valid? Can we get a new one without username/password?

Token is valid 5184000 seconds, i.e. 60 days. According to my understanding the renewal requires username and password.

[joostlek]

Ah, in that case I agree that this is a good change.

[home-assistant]

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍

Learn more about our pull request process.

[joostlek]

I think it would make sense to include this in 2024.5 because it will prevent doing a request every time HA boots/the integration reloads. I only see benefit in pulling this into the beta, to avoid unnecessary calls.

[MartinHjelmare]

Please address the comments in a new PR. Thanks!

[dontinelli]

Please address the comments in a new PR. Thanks!

Just opened a respective PR #116433.