quite remarkable really that the example uses the entity_id for updating the binary_sensor template. It doesn’t need it at all, since the entity to update is quite clear in the value_template…
This confuses readers of that documentation, thinking every template sensor would need those added entity_id’s.
On that same page is described when in fact we need to use the added entity_id.
btw note this is an example of an icon_template referencing itself in the template
I read the page given what you said (to align perspectives)
And though I agree that the entity id is not required (sun.sun is a tracked entity and obvious to the interpreter from the template) it positions the concept of entities that ‘may’ be referenced to update the template, so it’s not ‘wrong’
The self referencing in the icon template is also valid and I’ve done this myself, typically when the value template is ‘complex’. Why repeat a long template (possibly with a mistake in it) to evaluate when you can just reference it’s result ?
This also means you can copy a sensor and just change a minimal amount
of course you are right, I merely think it would have been a better educational insight to show the entity_id on a sensor that truly needs it. Most useful might have been a template using now(), which is done on most HA installations I would think.
As an example that wouldn’t need it, this would be the case…
Yes, I see…
But that is a special case where you are iterating over a group???
I think by the time a beginner gets there, he may have the skills to do some more digging ???
Having said that, you had issues (as I would have done) so putting another example in the entity update would be sensible (with an explanation as to why)
And a caution note about the self referencing in the case of groups, would be of value.
You argue well, and your English, syntax and grammar is amazing.
Sumbit a pull request to update the docs as you suggest, I’m sure it will be approved
I would also like to change state of icon in front of Shutter.
Where do I have to place the if loop?
Should this be done at the Configuration.yaml of the cover or in the Lovelace UI entities?
Unfortunately the icon is not shown for first items, only placing fix icon e.g. for second item works!
You have to put your template under icon_template: in an item that will accept icon_template:
(ie. not sure where you are putting that and I’m not sure that cover. will accept it (I don’t have covers))
Sometimes you have to create a sensor (template) to display the desired value AND the desired icon.
Also your template makes no sense. That is not permissible python.
you’d need something like : -
icon_template: "{{ 'mdi:television' if is_state('binary_sensor.tvfr', 'on') else 'mdi:television-off' }}"
From what you’ve said, I would say you need advice from someone who a) has covers b) uses mqtt to talk to them
I also would suspect that your cover is returning an ‘unexpected’ value of 9. I have no idea what this means, you will have to read the documentation that comes with your device.
after you do this, you probably won’t need an icon template because it will handle the icon for you.
@Mutt Icon_templates are only available on specific integrations and that list is extremely limited. Personally, I don’t offer this as a solution anymore because of those reasons.
I was also looking into changing the icon for a few of my door/window sensors. I really thought I understood how this works by reading this topic through, plus the “Template Binary Sensor” page and partly the big “Templating” page.
I started with just overwriting one sensors icon based in it’s state, but I keep getting a new entity with the name of my template binary sensor. And this new entity works and changes its icon based on the actual sensors state… But I can’t get it to work, that the actual sensor gets its icon changed in the frontend:
binary_sensor:
- platform: template
sensors:
living_room_door_on_off_icon:
entity_id:
- binary_sensor.living_room_door_on_off
# Note that 'value_template' is required. I have to add it, but I only want to change the icon...
value_template: "{{ is_state('binary_sensor.living_room_door_on_off','on') }}"
icon_template: >-
{% if is_state("binary_sensor.living_room_door_on_off", "on") %}
mdi:door-open
{% else %}
mdi:door-closed
{% endif %}
I’ve also tried to name the template binary sensor exactly like the actual sensor, but that gives me the same result, just that it’s named living_room_door_on_off_2…
Did I still understood that wrong? Will this never change the actual sensors icon in the frontend by itself, but just gives me another entity that I could use if I would do custom dashboards or something?
Or doesn’t it work, because my sensor is actually not added through the “binary_sensor” integration, but ZHA!?
You already have a binary sensor with on/off states. Delete your binary_sensor template you have there, and instead use the customize config to change the device class to door… like this in your configuration.yaml:
customize:
binary_sensor.living_room_door_on_off:
device_class: door
Much simpler… now restart HA and should be done. The door class will make use of those neat opened and closed door mdi’s (note not all lovelace cards display icon changes… verify the icons are working right using glances or dev/states). Here’s more binary_sensor classes that you may want to be familiar with:
On a side note to help clear some confusion… yes it is likely the ZHA integration went ahead and added in all the necessary entities for you when you set it up. Hence why you magically had the binary_sensor in your dashboard. It does that by default (see the zha integration switch for “adding newly discovered entities”… it’s on by default). So with the above customize: config, you are just telling HA that it should refer to that sensor as a door rather than a generic binary_sensor with an ugly/boring square.
Thank you so much! That’s the solution for my problem I didn’t understand yet, that the device class is “just” used for representation in the frontend. I thought it has some more, deeper usage and I didn’t want to play around with the device class of an entity, not wanting to risk to break something
But still, just so I know / understand the templating thing I did there:
Is the outcome of what I did there (the 2nd binary sensor) the expected outcome? Or is that just here in my setup where the entity I tried to change is not actually a raw binary sensor entity?
Interesting… To be fair, according to what the config looks like, it totally makes sense, as it configures a binary sensor with the platform “template”… Still interesting concept, that you can’t affect the sensor itself but need to use this template sensor instead if you want your icona… So really only helpful if you have custom UI/dashboards, I guess. Tbf, probably 90% of all HA users have tbem, but I am not even two weeks into HA, so I still stick with the default UI and dashboard