Map device "state" to an icon

Being able to change the icon based on state would be a nice feature.

Unless it already exsits and i have not found it yet.

For instance:

If state == on sets icon: mdi: sun
if state == off set icon: mid: cloud

I know I can change the Icon perminently but then I loose the open / close icon feature.

2 Likes

Could have sworn this was a feature request already but searched and couldn’t find it so I’m voting on this one.

I would assume the feature would be implemented in such a way

customize:
    cover.myq_First_Bay:
      icon:
       state_open: mid:door_open
       state_closed: mid:Door_closed
    switch.kitchen:
      icon:
       state_on: mid:toggle-switch-on
       state_off: mid:toggle-switch-off
4 Likes

Well, not customizing but that’s what’s binary sensors do. Two icons for two states.

I’ve modified template sensor to allow adding a template for the icon as well.

https://github.com/tboyce1/home-assistant/commit/a30fd576ef40181ecb38007567f330600fa02ea3

If you want to try it out, just copy that entire file to {hass_dir}/custom_components/sensor/template.py and then you can add icon_template to all your template sensors.

Here is the example I used to test this out:

input_boolean:
  template_icon:
    name: Template Icon
    initial: off

sensor:
  - platform: template
    sensors:
      template_icon:
        value_template: >
          {% if is_state('input_boolean.template_icon', 'on') %}
            Open
          {% else %}
            Closed
          {% endif %}
        
        icon_template: >
          {% if is_state('input_boolean.template_icon', 'on') %}
            mdi:garage-open
          {% else %}
            mdi:garage
          {% endif %}
          
group:
  template_icon:
    name: Template Icon
    entities:
      - input_boolean.template_icon
      - sensor.template_icon

And here is a more useful/interesting example:

sensor:
  - platform: darksky
    api_key: !secret dark_sky_key
    monitored_conditions:
      - summary
      - icon
      
  - platform: template
    sensors:
      dark_sky_template:
        value_template: "{{ states('sensor.dark_sky_summary') }}"
        icon_template: >
          {% if is_state('sensor.dark_sky_icon', 'clear-day') %}
            mdi:weather-sunny
          {% elif is_state('sensor.dark_sky_icon', 'clear-night') %}
            mdi:weather-night
          {% elif is_state('sensor.dark_sky_icon', 'rain') %}
            mdi:weather-rainy
          {% elif is_state('sensor.dark_sky_icon', 'snow') %}
            mdi:weather-snowy
          {% elif is_state('sensor.dark_sky_icon', 'sleet') %}
            mdi:weather-snowy-rainy
          {% elif is_state('sensor.dark_sky_icon', 'wind') %}
            mdi:weather-windy-variant
          {% elif is_state('sensor.dark_sky_icon', 'fog') %}
            mdi:weather-fog
          {% elif is_state('sensor.dark_sky_icon', 'cloudy') %}
            mdi:weather-cloudy
          {% elif is_state('sensor.dark_sky_icon', 'partly-cloudy-day') or is_state('sensor.dark_sky_icon', 'partly-cloudy-night') %}
            mdi:weather-partlycloudy
          {% elif is_state('sensor.dark_sky_icon', 'hail') %}
            mdi:weather-hail
          {% elif is_state('sensor.dark_sky_icon', 'thunderstorm') %}
            mdi:weather-lightning
          {% else %}
            mdi:help-circle
          {% endif %}
14 Likes

This is nice but won’t it get wiped out with each update?

Yes, it will unless it gets merged into the project or you run from source and keep it on your own branch.

Edit: Sorry, I got my posts crossed and thought this was to something else. What @rpitera said below is correct.

For reference, this is the post I accidentally put here, which is actually unrelated to this topic.

1 Like

Actually, if you keep it in custom components, it will remain in place. And it will use that instead of the updated code.

The only problem is if there is a fix or a bug in the version that was modified, that fix will have to be applied to the custom code manually. Also, if they drastically change the template.py code for some reason, you may run into issues running HA. But you can just remove the code from custom_components, comment out your specific references to the template icon and restart.

I hope so, because this remains one of the most requested features in the forums.

I copied your code and diligently made sure the spacing was perfect (it is!) but I get an error when trying to run it

“Invalid config for [sensor.template]: [icon_template] is an invalid option for [sensor.template]. Check: sensor.template->sensors->dark_sky_template->icon_template. (See ?, line ?). Please check the docs at https://home-assistant.io/components/sensor.template/”

I couldn’t find any documentation on the types of templates allowed, but it appears that an icon template isn’t one of them, can you guide my wayward ways?

Did you also copy the template.py file to your custom components directory?

1 Like

…uh. no… no in fact I did not :flushed: (I can read I promise!!)

1 Like

It’s easy to miss when you’re excited about implementing something cool. :wink:

But that’s why; his configuration code requires the custom template changes (at the moment - hopefully this will get merged in the near future).

FYI, the next release should allow custom state cards. I think it should be possible to do this with a custom card, but it’s going to be more involved than using a template in the config.

Here are some examples of custom state cards:

Created a PR for this, but not sure if it will get accepted.

There is a difference between this and the one I posted earlier, which is that in this PR the icon template is only rendered when the template sensor is updated rather than on every call to get the icon. Because of this, you shouldn’t use the state of the template sensor itself for the icon template since the state may not be updated before the icon template is rendered. Just use the state of the other sensor instead, like I did in my Dark Sky example above.

6 Likes

Thank you! I was ready to give up with the icons until I noticed on your post that, it was better to use the original value for the sensor. Now it works! Thanks!

Merged in February, so closing.