Allow multiple sections

[gjohansson-ST]

Proposed change

Allow us to use multiple sections e.g. the user can add/remove sections from the same configuration.
See frontend PR how it would be displayed for the user.

Example of integrations that could use this (some already in UI)

• bayesian (observations list)
• filter (as filters)
• compensation (data points)
• template (alarm_control_panel/lock define the different arming/lock options).
• scrape (sensors)

Frontend: home-assistant/frontend#22965
Dev docs: home-assistant/developers.home-assistant#2471

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.

To help with the load of incoming pull requests:

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

[home-assistant]

Hey there @home-assistant/core, mind taking a look at this pull request as it has been labeled with an integration (kitchen_sink) you are listed as a code owner for? Thanks!

Code owner commands

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

[MartinHjelmare]

Please provide an overview of use cases and existing integrations that can use the new selector config, besides the compensation integration.

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

[gjohansson-ST]

Please provide an overview of use cases and existing integrations that can use the new selector config, besides the compensation integration.

I have updated the PR description with some integrations that could use this. There are probably also quite a few more than could use it, if it was available when it went into UI.

[MartinHjelmare]

I'd say that of the ones mentioned now, only bayesian, compensation and filter are suitable. Scrape would use sub entries (nuggets), and template alarm control panel I don't see how it would use a multiple section. There's only one action (script) allowed per alarm control panel service action and panel and we use action selectors for that.

[gjohansson-ST]

and template alarm control panel I don't see how it would use a multiple section. There's only one action (script) allowed per alarm control panel service action and panel and we use action selectors for that.

I was more thinking the whole arming definition would go into sections. So instead as currently you need to ask which ones to use and present on a second form. The user could just simply add one after the other and define for which action it is.

So I think that would also be the same for lock, cover etc.

arm_away:
  action: alarm_control_panel.alarm_arm_away
  target:
    entity_id: alarm_control_panel.real_alarm
  data:
    code: !secret alarm_code

[MartinHjelmare]

What's the second form? Is it really intuitive to use sections when there's a limited set of distinct items to configure?

[gjohansson-ST]

I guess that's a border line case to have the sections in the initial form (and the user need to select the arming types) than presenting the fixed set of options on a second form (or multiple forms).
Even though it's a bit hard to present a lot of integrations that can use this, I'm convinced it would be beneficial also for other integrations to use when there is a list with multiple fields inside.

[MartinHjelmare]

There's only one form for template alarm control panel.

[gjohansson-ST]

I don't remember but I guessed two. Anyhow template is not the best example here anyhow.
I guess you'll come back with some final verdict later 😅