Volume entities (sound): dynamic icon update

[dougiteixeira]

I would like to propose this change, as it interferes with the core, I preferred to open a discussion before creating a PR (I created the PR home-assistant/core#64803 later).

The suggestion consists of create icon_for_volume_level() so that the volume entities icon is dynamically updated from the entity value. It also considers a possible mute or do not disturb entity that may exist for the device.

The initial idea came from the objective of defining the icon of entities of similar volume with the battery level (entities number when there is volume control on the device and sensor entity when there is only volume feedback), but there is no class of devices for this (in sensor entities it doesn't exist and number entities are not yet supported). I realized that defining the icon is possible even without a class directly in the core, defining it in each integration, but the ideal of this icon_for_volume_level class is to be in the core.

Changes:

Additions to the homeassistant/helpers/icon.py file:

def icon_for_volume_level(
    volume_level: int | None = None, volume_mute: bool = False
) -> str:
    """Return a volume icon valid identifier."""
    icon = "mdi:volume"
    if volume_level is None:
        icon += "-variant-off"
    elif volume_mute:
        icon += "-mute"
    elif volume_level == 0:
        icon += "-off"
    elif volume_level <= 35:
        icon += "-low"
    elif volume_level <= 70:
        icon += "-medium"
    elif volume_level > 70:
        icon += "-high"
    return icon

Screenshots of the various conditions:

Volume level 71-100% and not muted:

Volume level 36-70% and not muted:

Volume level 1-35% and not muted:

Volume level 0% and not muted:

Volume level 0-100% and muted:

[dougiteixeira]

@frenck, do you think i can implement this?

Thanks!

[frenck]

Not sure why you tag me specifically, especially since I rarely do frontend development.

Anyways, I'm not sure if you are capable of implementing it. That is more a question you can answer yourself the best 😉

[dougiteixeira]

The changes will be in the core, sorry if I bothered you.

I already implemented it locally, but I don't know the rules for changes in the core, so I preferred to open a discussion before. I opened the discussion on the frontend as I understand that new features are discussed here. I'll create the PR to be evaluated in the core then.

[frenck]

The changes will be in the core

Than this discussion is in the wrong place 😬

sorry if I bothered you.

Don't worry. I meant it in a more funny way. I'm not bothered.

[spacegaier]

We do something similar for battery icons already, but I am not sure right now if that is driven by the backend or the frontend. If frontend then probably based on the device_class. Do we have a device class for audio volumes?

[dougiteixeira]

It's performed on the backend, I'll treat it in the core with a PR. Thanks for the feedback.

[spacegaier]

But is that the best approach? I checked for batteries the frontend handles that for those. What would be the benefit for doing it in the backend instead now for audio volumes?

Did you check if there is a device class for audio volumes (which would be a requirement for the frontend to apply a dedicated icon logic)?

[dougiteixeira]

I updated the description to explain better.