Add template sensors to device page

[kamaradclimber]

Most helpers (integration, derivative, utility meters) are attached to the device of the entity they relate to.

For instance:

The proposal is to do the same for templates.

The use cases are numerous, many people define templates to slightly transform entities exposed by a device: it can be to change unit (convert a price from euros to euro cents for instance), to filter out some values or to combine entities together.

This request is also tracked on here.

There are quite a few challenges to do this:

1. A template can relate to several entities, from different devices. Picking the most relevant device is not obvious.
2. Templates are widely generic and one cannot guess relevant device until template has been rendered
3. Entities used by a template can change over time. For instance, a template could list all entities according to a given criteria, this list change as device are added/removed from HA.

All those challenges can be worked around if users were to choose the device at template creation. However, this requires users to enter additional configuration which is redundant with template definition. It could be a first implementation step though.

I'd like to propose a more interesting implementation:

• Templates depending on entities from a single device are automatically attached to this device. More complex templates are not attached to any device. This solves 1).
• Entities are allowed to update device_info after being added to hass. Templates would do so after first rendering (and possibly after each rendering). See Allow entities to change device #1055

[llucax]

Hi, from the user perspective for me it would be interesting if I could freely/manually choose how to attach templates to devices. This removes the complexity of having to guess for more complex templates and could also serve to "override" any automatic attachment.

It might be even more flexible if they could be attached to more than one device (if that's even possible in the current architecture).

[kamaradclimber]

Thanks for your input. I agree manual override would be interesting, especially for cases not covered by the current proposal (automatically attach if there is only a single possibly device).

Trying to anticipate a bit, what are the uses case we can think of where this strategy would not be relevant?

[llucax]

I don't have a specific use case in mind right now, I guess it just my fear of past experiences with software trying to guess what I want instead of letting me tell what I want explicitly :)

[emontnemery]

@kamaradclimber I don't understand what this means:

Templates depending on entities from a single device are automatically attached to this device. More complex templates are not attached to any device. This solves 1).

I'd suggest to rewrite your proposal to more concretely explain what you suggest, including how users would define devices, both via yaml and via the template integration's config flow.

Also, there's a major obstacle preventing what you suggest in that devices must unconditionally be owned by at least one config entry, and there's no config entry for template entities defined through yaml.

[pethans]

I came across this discussion via the forums, as I'm interested in finding an easier way to know when a device's entities are part of a group without having to painfully check inside each group in the Helpers tab.

Looking at the screenshot example above, I'm surprised to see "Utility Meter" listed where normally only Integrations would be listed. (I have no helpers like this personally, but I have had devices with two Integrations e.g. both MQTT and, say, Shelly, active simultaneously).

I would suggest adding a fourth information box — beneath (or above?) "Automations", "Scenes", and "Scripts" — for "Helpers" that displays links to any UI-defined helpers in which the device or its entities are being used, and a plus "+" to add more as in the associated workflow. As of today, only a few templates can be defined as helpers but if there is a long-term strategy to move full template functionality to the helper workflow, eventually all templates, as well as groups, derivatives, utility meters, etc, could be helpfully listed together on the device page (sidestepping the yaml-defined obstacle mentioned above).