Make it possible to use type "area" for area cards instead of Mushroom template card

[DigiLive]

One of our users made the effort in a PR (#52) as described below.
However, we're not entirely sure about implementing his idea into the strategy and would like our users opinion about it.

Please vote and comment your thoughts...

What

This provides an option to use type: area instead of mushroom-template-card for Areas, by configuring use_type_area: true.
Along with that an option is also added to set common options for all area cards. Example:

strategy:
  type: custom:mushroom-strategy
  options:
    areas:
      _:
        use_type_area: true

Of course it was already possible to override type in mushroom-strategy, but that wouldn't work with the type: area, since it also requires area: <area id>.

Why

• The built in area card in Home Assistant supports pictures, which means that the user of mushroom-strategy now does not have to provide picture URLs for every area.
• The built in area-card shows pictures on the entire card, making it easier to see what is on the image (compared to the mushroom template card which only shows the picture as a round icon).

Example

Example of how it can look:

[DigiLive]

I do like the looks, but I have some objections also...

1. It's called Mushroom Strategy, designed to auto-populate the dashboard with Mushroom cards, whenever useful and possible.
   I'm not sure we should mix all kind of card-styles together, but to keep it at a minimum instead.

2. I.m.o., If adding support for the HA Area Card, the way to go is to add a new class to the package.
   The sole purpose of the current AreaCard class is to create a Mushroom-styled area card.

3. Adding properties to the configuration is allowed, so the following example should work.
   (However, additional properties may be incompatible with Mushroom Strategy.)

    areas:
      biljardrum:
        type: area
        area: biljardrum
        navigation_path: biljardrum

@johanfrick said:

Yeah, you make a fair point that this is a strategy for Mushroom cards. However, this is also the greatest strategy I've seen for Home Assistant and I think the crowd can be made a lot wider if we allow some more customisation. Many people prefer Mushroom cards and nothing else, but not everyone does. That being said, I'll give it another think how I can "hide" the intention of not using Mushroom card for some parts. Probably by moving more to the user's configuration of mushroom-strategy. But let me know if it is not worth the effort, and I'll move forward by only maintaining my own fork.

[punxaphil]

@DigiLive I have now updated the PR and changed the code so that it is not pushing for using another card than mushroom.
Instead, this is simply just about making it possible to set options for all area cards, and an option to dynamically insert area ID in the options using "{{area_id}}".
I hope this solution feels like a better idea 🙏
If you can agree, and unlock the PR, I would change the PR description to the text below:

What

This provides an option to set options for all area cards as well as dynamically get access to the area ID. Examples:

Change layout for all area cards:

strategy:
  type: custom:mushroom-strategy
  options:
    areas:
      _:
        layout: vertical

Use another card for areas:

strategy:
  type: custom:mushroom-strategy
  options:
      _:
        type: area
        area: "{{area_id}}"
        navigation_path: "{{area_id}}"

[DigiLive]

@johanfrick Unlocked #52 to discuss the commits. Please discuss the generic things over here.
@AalianKhan Whats your opinion?

Until now, no votes other than mine.

[AalianKhan]

Yes, this is a better option than limiting the user to area or mushroom-template.
I do foresee that some people will be asking about another option to set up a custom card for a specific domain but that's an issue for another day.

[ankushg]

Definitely a fan of the custom area card with this approach!

Would be nice to extend the _ wildcard pattern to other things like domains, but areas are definitely a good start ;)

[DigiLive]

As I'm reviewing the PR (#52) and tweaking it, I've noticed the following which I'm not keen on:

Note the different heights and the placements of the sensors/buttons.
Seems like the HA Area card isn't very suitable for vertical/horizontal stacks.

[punxaphil]

Maybe always hide "undisclosed" if using Ha Area Card?

[DigiLive]

That would leave the undisclosed area inaccessible by gui.

But for now, it's more the sensors/buttons and the last card that bothers me.

HA area card won't let you configure any of the sensors/buttons and scales the card-height proportionally to the width.

I think we should look for an alternative layout method.
One that would fit all/most card types and screen-sizes.

[punxaphil]

Ok

[DigiLive]

Merged at #52

[maslyankov]

This looks well if the rooms have no temp/humidity sensors. If there are sensors for an area, they show up in the area card and therefore the UI looks too narrow and bad. The easiest solution would be to make them appear in one column.