In general, all basic entities so so simple/limited (feature-wise), to the extent that often they require to copy them into corresponding template sensors.
Examples:
changing an icon based on the state or attributes
ignoring unavailable/unknown state
setting icon at all (not sure it’s still the case, in the past there were integrations making it impossible to set icon when defining entity)
rounding values (taken from another WTH)
In short, why template abilities are not provided to any entity (in OOP world it could be its parent)
I can. But this is a similar point to my OP. I don’t want to configure things in several places. Why it cannot be provided as a feature of any sensor/entity?
It wouldn’t be a case if every sensor has derived from template sensor features.
In general, your answers reflect the current state. I can imagine it got created in incremental manner. But today I see no reason why not “compile” templates into all other entities for-sake simplifying things and reducing redundancy.
Can be done via customize via device class like tom said. It can also be changed in the UI via display as. The only missing functionality here is customized icons based on states, which is already a WTH making point 1 a duplicate. We don’t want duplicates, we would like all voting in 1 place. Please use the search before creating WTHs.
Breakout into it’s own WTH. This would be an update to the filter entity, where you can filter undesired states. It’ll still make a new entity, that’s how home assistant works.
They are derived, that’s why you get unknown and unavailable. All entities can have these states.
Icons are set via the UI (with unique_id), yaml if the integration supports an icon key, or yaml in customize if the integration doesn’t support that key.
This is already a WTH. See point 1 about duplicates.