Add configuration to default dashboard

[piitaya]

Proposed change

Strategy editor

Adds UI editor for strategies. The user can switch between UI and yaml to edit the strategy configuration. If the strategy doesn't provide editor, it will be yaml only.

Default dashboard improvements

Add 3 options to default dashboard :

• hidden_areas : List of areas that must not be displayed
• hide_entities_without_area: Entities without area will not be listed
• hide_energy: Hide the energy card

Demo

CleanShot.2023-11-15.at.15.53.07.mp4

Type of change

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

Example configuration

Additional information

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

Checklist

• The code change is tested and works locally.
• There is no commented out code in this PR.
• 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

[balloob]

Instead of hidden areas, could we have a single area selector component that allows:

• enable/disable area (current hide functionality)
• re-order area

I am sure that this will become useful for many other strategies too.

[piitaya]

Yep definitely! We already discussed about a better UX for areas during frontend meeting 🙂
If we use an included list, new areas will not be automatically added.

I think we need two lists to store it:

areas:
  hidden: 
    - kitchen 
    - bedroom
  ordered:
    - living_room
    - bathroom

So if the user create a new area. It will add it at the end of the visible areas list.

But the selector will only display an ordered visible list so it's easier for the user.

[balloob]

Yeah that sounds about right, and I guess that means that we can also add that in a future PR. Should we then already adopt the YAML format in your comment (top level areas with 2 sub-keys) to avoid having to reuse hidden_areas key in the future? (assuming selectors only work on 1 key)