Map card: add prefix & suffix for "label_mode: attribute"

[ildar170975]

Breaking change

Proposed change

Added prefix & suffix for label_mode: attribute on Map card.

type: map
entities:
  - entity: device_tracker.demo_home_boy
    label_mode: attribute
    attribute: source_type
  - entity: device_tracker.demo_home_boy
    label_mode: attribute
    attribute: gps_accuracy
    prefix: "~"
    suffix: m
  - entity: device_tracker.demo_home_boy
    label_mode: attribute
    attribute: battery
    suffix: "%"
theme_mode: auto

Also, introduced 2 new CSS theme vars --ha-marker-prefix-margin, --ha-marker-suffix-margin to manage margins between a prefix, suffix & attribute's value.

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: Map card: add "prefix" & "suffix" options home-assistant.io#38535

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

[piitaya]

We don't need to add an option for that. We can render attribute with the right unit.

Attribute units can be added to this file :

frontend/src/data/entity_attributes.ts

Line 41 in 1bba103

export const DOMAIN_ATTRIBUTES_UNITS = {

For example we can add this to have unit for latitude, longitude, battery and gps_accuracy :

  person: {
    gps_accuracy: "m",
    battery: "%",
    latitude: "°",
    longitude: "°",
  },
  device_tracker: {
    gps_accuracy: "m",
    battery: "%",
    latitude: "°",
    longitude: "°",
  }

For prefix, I don't see other use-cases so I would not put it as an option for only this case.
Also margin are not needed as the space between the unit will be automatically calculated according to the language and the unit.

[ildar170975]

We can render attribute with the right unit.

But what if the entity is a template sensor?
What if it is some geo event sensor with different attributes?

For prefix, I don't see other use-cases so I would not put it as an option for only this case.

We have prefix/suffix in Entities card, so I wanted to make similar.
An ability to define ANY labels (other than some hardcoded ones) will may it more flexible.
Also, perhaps in some cases a user may want to NOT show a hardcoded unit.

[piitaya]

The template sensor can provide its own unit of measurement so it can be displayed here.

The unit for entity card was introduced 5 years ago when we didn't have unit translations and unit provided by the backend.
Newest card doesn't have this option.

Also, we are trying to avoid using too many attribute for entity to be more device centric. For example, the battery level attribute for vacuum has been moved to its own entity.

[ildar170975]

The template sensor can provide its own unit of measurement so it can be displayed here.

For a state, not for an attribute.

Also, we are trying to avoid using too many attribute

But still many integrations have attributes.
Geo events is a good example.
And a set of attributes can be different.

[piitaya]

Can you provide examples provided by HA integration? It may be solved by automatically by adding unit for the attribute.
I'm not in favor of adding option to let user fixing the problem themselves if we can fix it automatically. I prefer to have the best default and then provide option if it's not enough.

[ildar170975]

Can you provide examples provided by HA integration?

GDACS, transport schedule integrations, many of them.

I'm not in favor of adding option to let user fixing the problem themselves if we can fix it automatically

Good, but you cannot provide ways for template sensors.

[piitaya]

Which attribute GDACS provide that require a suffix or prefix?

[ildar170975]

Which attribute GDACS provide that require a suffix or prefix?

Sensors of HACS have a variable set of attributes - perhaps dependently on a particular event, could be smth like "water height", "population loss" etc. For these attributes a user may want to have a unit (in general - prefix/suffix).

Also, there are PLENTY of integrations, not sure that frontend should oblige all of them to have hardcoded units.

I wonder if it is possible to combine methods: allow showing hardcoded uoms (if they are provided; also - NOT use it if not needed) OR use own suffixes.

[MindFreeze]

We are generally skeptical of new options and css variables because we will likely be stuck with them forever.
The margin vars don't seem that necessary. Nor does the prefix.
Suffix seems useful but we should not encourage putting important measurement data in attributes. It should have it own entity. I often create template entities to get values out of attributes and it's a pain but it's the integration's fault.
For GDACS attributes seem unavoidable but I think we can handle them with DOMAIN_ATTRIBUTES_UNITS

[ildar170975]

So far attributes are supported in entities, so why not letting users to add them on cards.
As for DOMAIN_ATTRIBUTES_UNITS - as I said, it may not cover all possible cases, not to mention template sensors with attributes.
Banning adding new features for users who prefer using attributes - not a good idea imho.

As for "we will likely be stuck with them forever" - recent changes in the world should encourage people to stop thinking that everything can last for ages. Everything may change.

Anyway, I am not insisting on this PR. There are alternative custom map cards which can be used for such scenarios.
Let me know if I should close this PR.

[MindFreeze]

I hear you. My point was not disallowing attributes. Just that we shouldn't support them as much as entity state. We allow using attributes everywhere but if you want the full experience, you have to move the data to an entity.
We just have to draw the line somewhere, otherwise everything will be shoved in attributes. Many integrations already do this and we don't want that.
Anyway, the more important point is that we have to try to handle as many cases with defaults first. Then if there are still real cases require options, we add them. Just want to see how far we can get without new options first, so we know for sure that we need them

[ildar170975]

we have to try to handle as many cases with defaults first

Agreed definitely!

1. If an attribute already has some uom - it should be shown by default. Ideally, a user may have an ability to NOT show uom, but not crucial (anyway, it is also not available for states, they are shown with uoms always). Suffix MAY be added by a user - but it is useless.
2. If an attribute does not have uom - suffix could be a good way (it should be shown with some margin, hardcoded or managed with css var).
3. As for prefix - OK, less critical, can exclude it.

So, I may do:

1. Show an attribute value with uom if it is available.
2. Suffix will be still added with a hardcoded margin.
3. Exclude prefix.

[ildar170975]

Converting to draft. Will continue in a week when hopefully be home again.

[MindFreeze]

we have to try to handle as many cases with defaults first

Agreed definitely!

1. If an attribute already has some uom - it should be shown by default. Ideally, a user may have an ability to NOT show uom, but not crucial (anyway, it is also not available for states, they are shown with uoms always). Suffix MAY be added by a user - but it is useless.
2. If an attribute does not have uom - suffix could be a good way (it should be shown with some margin, hardcoded or managed with css var).
3. As for prefix - OK, less critical, can exclude it.

So, I may do:

1. Show an attribute value with uom if it is available.
2. Suffix will be still added with a hardcoded margin.
3. Exclude prefix.

One more thing. Instead of suffix, name it unit so it is consistent with the entity card

[ildar170975]

Agree, will use a “unit” ! Will continue in a week I hope.