Update stookwijzer api to atlas leefomgeving and add extra sensors

[fwestenberg]

Breaking change

Stookwijzer states are updated. New possible states are: code_yellow, code_orange and code_red.

Proposed change

The API has changed, also the different advices are added (source https://iplo.nl/thema/lucht/houtstook-de-stookwijzer-en-het-stookalert/)

fwestenberg/stookwijzer@v1.3.0...v1.4.10

To fix the issue mentioned in #104705, the pyreproj dependency is removed.

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 Changed site home-assistant.io#29679
• This PR is related to issue:
• Link to documentation pull request: Update Stookwijzer markdown with extra sensors home-assistant.io#30092

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.

[fwestenberg]

@joostlek Does this PR look familiar to you? Would you mind reviewing this one as well?

[joostlek]

Yes this PR does look familiar, but in its current form it's doing way too much. Can you split out stuff like the dependency bump, coordinator, new sensors?

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

[fwestenberg]

Splitting will be a problem. Because of the dependency so many had to change. And I even added a lot of new tests. We can probably take more time for this review and keep it as is?

[joostlek]

Yes but a dependency change does not have to change the way we fetch data or the amount of sensors. Like if it was only 1 new entity, sure. But in this case this PR does too much

[frenck]

@joostlek Honestly, that review is kinda waste of time. You've seen a few pushes from me + it is draft for a reason. Most of the code will look different.

[frenck]

I think this is rather complete now. Now I've mostly refactored it, I do agree with the other comments that this needs to be split out into multiple PRs.

So, what we first can do here, is make a PR that bump the dependency in the existing integrations and does the bare minimum to get there.

That would mean a PR with a Dependency bump, config entry migration + issue, config flow adjustments, config flow test adjustments, and probably the init tests (which test the migration of the entry + issue raised in case of failure) + diagnostics adjustments.

As follow-up PRs could be:

• Add coordinator
• Add entity description support (+ entity entry migration) for the existing sensor + sensor tests
• Add new sensors
• Add strict typing
• Add quality scale files

With this PR in place, that shouldn't be too much of a task to split out.

After that, I think there are quite a few improvements that can be made upstream in the client library as well. Mostly in terms of error handling. Right now, it just silences all the errors and returns None for those cases. While easy to use, it does cause problem as we won't be able to react on it. For example, how would we know the difference between an connection error or data just not being available? Each of these cases is handled differently in Home Assistant, but we don't have that information.

../Frenck

[frenck]

Extracted part 1, the bump: #131567

[frenck]

Coordinator added in #131574

[frenck]

Entity descriptions support: #131585

[frenck]

New sensors: #131587

[frenck]

Extend tests for Stookwijzer init: #131589

[frenck]

Enable strict typing for Stookwijzer: #131590

[frenck]

Add data description for Stookwijzer config flow: #131591

[frenck]

And the last one:

Record current IQS state for Stookwijzer: #131592

[frenck]

Closing this PR, as everything in here is done in the splitter-out PRs listed above.

../Frenck