Add config flow to NMBS

[silamon]

Breaking change

Removes support for configuration by configuration.yml file.

The "name" and "station_live" options cannot longer be configured. The config flow will setup 2 disabled sensors for the "station_from" and "station_to" provided in the config flow. You can set a custom "name" after setting up the config flow.

Proposed change

Adds a config flow for nmbs integration. The configuration.yml had combined options allowing to specify a connection between 2 stations, additionally one can add a specific configuration option to have a sensor showing the next first departing train in a specific station.

The config flow only supports the "connection" and setups 2 disabled "liveboard" for the "from" and "to" sensors. Here is a overview:

configuration.yaml option	description	config flow type	config flow parameter
station_from (required)	The station where the connection departs.	connection	station_from
station_to (required)	The station where the connection arrives.	connection	station_to
station_live (optional)	Setting this will create another sensor to monitor the liveboard in a station.		--
exclude_vias (optional, default: false)	Setting this will not show connections for which you have to transfer to another station.	connection	exclude_vias
name (optional)	Name to use in the frontend.		--
show_on_map (optional, default: false)	Show the station on the map.	connection	show_on_map

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: Add config flow to NMBS home-assistant.io#35923

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.

To help with the load of incoming pull requests:

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

[home-assistant]

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

Code owner commands

Code owners of nmbs 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 nmbs 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.

[joostlek]

Is the liveboard a current available feature?

[silamon]

Is the liveboard a current available feature?

Yes. By configuring the station live parameter in the configuration yaml you get the next train to depart as additional sensor.

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

Oh I still had some comments from a while back.

I still feel like liveboard shouldn't be its own entry and we can just combine that with the normal entry

[joostlek]

I am missing a test:

• Where we try to setup an already set up entry that already exists, which should abort
• Where do the same but then with importing

[silamon]

Not clear at the moment if we can take updated unique ids right now, or later since now the localized names are used in the unique id.

[jcoetsie]

I did a test of this too.

Having a setup between station A and B and the same between station A and B but now also with vias does not work.

It says Location is already configured. The error is unclear, it must be more To/From combination already exists

This also means one cannot configure two sensors for both direct and indirect trains. Must we not create both OR allow both to be created? Should unique id not contain if it is with vias?

Another one is the functionality of the state of the sensor. Why do we keep duration? Isn't departure time including delays more relevant?

[silamon]

I did a test of this too.

Having a setup between station A and B and the same between station A and B but now also with vias does not work.

It says Location is already configured. The error is unclear, it must be more To/From combination already exists

This also means one cannot configure two sensors for both direct and indirect trains. Must we not create both OR allow both to be created? Should unique id not contain if it is with vias?

Another one is the functionality of the state of the sensor. Why do we keep duration? Isn't departure time including delays more relevant?

True that, that was a problem before as well as both would make the same sensor anyway. I will look into it.
Currently the functionality of the sensor is kept, not to make even more changes into already big pull request.

[joostlek]

Maybe such thing can be solved with config sub entries, which might land soon