Add config flow to Entur

[SanderBlom]

Breaking change

N.A

Proposed change

This change will let users configure the entur integration using the GUI instead of having to configure it in the configuration.yaml

• Added config flow to configure the integration using the GUI
• Added options flow to allow changing settings after setup
• Added DataUpdateCoordinator for efficient data polling
• Added support for importing existing YAML configurations to prevent breaking existing installs, with deprecation notice for removal in 2027.1.0. Should we keep this or make it shorter or longer?
• Added validation when adding lines to the whitelist preventing users from adding invalid lines
• Added tests for the integration
• Added quality_scale.yaml to use the new quality scale system, upgrading the integration from legacy to bronze This will be added later in a separate PR as requested

Notes

• I also wanted to add strict typing but this is not possible before the enturclient lib releases as new version with a py.typed marker file.
• Regarding the checklist for the following the perfect PR guidelines about doing as little changes as possible and split things into multiple PRs I think not doing this is valid for this PR as it adds support UI configuration, which requires several interdependent changes (config flow, coordinator, options flow, tests). These changes are bundled together as they can't function independently as the config flow depends on the coordinator, and tests are required to validate the config flow. I can split out the quality_scale.yaml into a separate PR if preferred?
• I also create a PR to update the documentation better explaining how to configure the integration and that the yaml config is deprecated.
• I tried to add a validation when adding lines to the whitelist but this will currently not work as there is no way to list all lines on a stop reliably. If you whitelist a line that only run once a week and you add it a different day then when the line runs, the validation will fail because it can not find that line in the real time data. To add this I think we have to update the enturclient lib.

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:
• Link to developer documentation pull request:
• Link to frontend pull request:

Checklist

• I understand the code I am submitting and can explain how it works.
• 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.
• Any generated code has been carefully reviewed for correctness and compliance with project standards.

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.

To help with the load of incoming pull requests:

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

[home-assistant]

Hey there @hfurubotten, mind taking a look at this pull request as it has been labeled with an integration (entur_public_transport) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of entur_public_transport can trigger bot actions by commenting:

• @home-assistant close Closes the pull request.
• @home-assistant rename Awesome new title Renames the pull request.
• @home-assistant reopen Reopen the pull request.
• @home-assistant unassign entur_public_transport Removes the current integration label and assignees on the pull request, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the pull request.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the pull request.

[Copilot]

Pull request overview

This PR adds GUI configuration support to the Entur public transport integration, enabling users to set up and configure the integration through the Home Assistant UI instead of requiring YAML configuration. The integration is also upgraded from legacy to bronze quality scale.

Key changes:

• Added config flow with validation and error handling for GUI-based setup
• Added options flow to allow users to modify settings after initial setup
• Implemented DataUpdateCoordinator for efficient, centralized data polling
• Added YAML import support with deprecation notices (scheduled for removal in 2027.1.0)
• Comprehensive test coverage for all new functionality

Reviewed changes

Copilot reviewed 15 out of 15 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
homeassistant/components/entur_public_transport/__init__.py	Added config entry setup/unload functions and options update listener
homeassistant/components/entur_public_transport/config_flow.py	New config flow implementation with user flow, import flow, and options flow
homeassistant/components/entur_public_transport/const.py	Centralized constants for configuration keys, icons, and attributes
homeassistant/components/entur_public_transport/coordinator.py	New DataUpdateCoordinator for efficient API polling and data management
homeassistant/components/entur_public_transport/sensor.py	Refactored to use config entries and coordinator pattern, added YAML import trigger
homeassistant/components/entur_public_transport/strings.json	Translation strings for config flow, options flow, and repair issues
homeassistant/components/entur_public_transport/manifest.json	Updated to enable config_flow, set quality_scale to bronze, added integration_type
homeassistant/components/entur_public_transport/quality_scale.yaml	Quality scale rule tracking for bronze certification
tests/components/entur_public_transport/__init__.py	Test module initialization
tests/components/entur_public_transport/conftest.py	Test fixtures for config entries, mock clients, and integration setup
tests/components/entur_public_transport/test_config_flow.py	Comprehensive config flow tests covering all flows and error cases
tests/components/entur_public_transport/test_init.py	Integration setup, unload, reload, and options update tests
tests/components/entur_public_transport/test_sensor.py	Sensor entity tests for states, attributes, and edge cases
script/hassfest/quality_scale.py	Removed entur_public_transport from legacy exemption lists
CODEOWNERS	Added test directory to codeowners (missing new codeowner in this PR)

[Copilot]

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated 4 comments.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Copilot]

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated 1 comment.

[SanderBlom]

I now tested this locally and it works fine. It successfully imported my old yaml config

[epenet]

You are making quite a lot of changes - some of which can be done in preliminary PRs (eg. codeowner or integration type) and some of which can be done in follow-up PRs (eg. coordinator)

This makes the PR bigger than it needs to be, and much harder to review.

Can you please explain why adding the coordinator now is compulsory?

[SanderBlom]

You are making quite a lot of changes - some of which can be done in preliminary PRs (eg. codeowner or integration type) and some of which can be done in follow-up PRs (eg. coordinator)

This makes the PR bigger than it needs to be, and much harder to review.

Can you please explain why adding the coordinator now is compulsory?

Thanks for the feedback @epenet

I thought DataUpdateCoordinator was the recommended replacement for that pattern when using config entries. I was just thinking that when we allreqady refactor a big part for the integration we may as well do this refactor as well. But I'm happy to revert to the proxy approach if we prefer to keep changes minimal.

I can then implement the DataUpdateCoordinator and upgrade the integration scale in a separate PR later

[epenet]

You are making quite a lot of changes - some of which can be done in preliminary PRs (eg. codeowner or integration type) and some of which can be done in follow-up PRs (eg. coordinator)
This makes the PR bigger than it needs to be, and much harder to review.
Can you please explain why adding the coordinator now is compulsory?

Thanks for the feedback @epenet

I thought DataUpdateCoordinator was the recommended replacement for that pattern when using config entries. I was just thinking that when we allreqady refactor a big part for the integration we may as well do this refactor as well. But I'm happy to revert to the proxy approach if we prefer to keep changes minimal.

I can then implement the DataUpdateCoordinator and upgrade the integration scale in a separate PR later

Yes please.

Config flow PRs are some of the hardest to review - so the smaller we can make them the better.