"Object-oriented" template entities

Feature Requests
1

Disclaimer: I’m not looking for a solution, I have one. I just find it cumbersome

Probably due to my dev background, I like to decouple functionality and infrastructure aspects of my devices.
E.g., if I have a random temperature/humidity sensor in my living room, I keep the “infrastructure” naming of the device as-is, then create “sensor.living_room_temperature” / "sensor.living_room_humidity template entities above them, which is constant across my configuration. If the device dies, or I want to use something else, I just change the source of the template sensor and done.

Currently, that involves quite a bit of “boilerplate” code, so I use an external Go template generator which does most of the work, e.g.

## gomplate template
## install:
##   go install github.com/hairyhenderson/gomplate/v4/cmd/gomplate@latest
## docker:
##   docker run -v .:/config hairyhenderson/gomplate:stable -d 'data=file:///config/gomplate/templates_template_occupancy.json' -f /config/gomplate/templates_template_occupancy.tmpl -o /config/platforms/templates/gmp_templates_template_occupancy.yaml
## run: 
##   cat gomplate/templates_template_occupancy.json | gomplate -d 'data=stdin:?type=application/array%2Bjson' -f gomplate/templates_template_occupancy.tmpl -o platforms/templates/gmp_templates_template_occupancy.yaml

- sensor:

{{- range  $c := (ds "data") }}

{{ $slug_name := $c.name | strings.Slug | strings.ReplaceAll "-" "_" }}

  - name: "{{ $c.name }}_temperature"
    unique_id: "{{ $c.uid }}_temperature"
    state: '{{ "{{" }} (states("{{ $c.entity_id }}_temperature")|round(1)) {{ "}}" }}'
    unit_of_measurement: "°C"
    device_class: temperature
    state_class: measurement
    availability: '{{ "{{" }} states("{{ $c.entity_id }}_temperature")|is_number {{ "}}" }}'
  - name: "{{ $c.name }}_humidity"
    unique_id: "{{ $c.uid }}_humidity"
    state: '{{ "{{" }} (states("{{ $c.entity_id }}_humidity")|round(1)) {{ "}}" }}'
    unit_of_measurement: "%"
    device_class: humidity
    state_class: measurement
    availability: '{{ "{{" }} states("{{ $c.entity_id }}_humidity")|is_number {{ "}}" }}'

{{- end }}

It would be more elegant to be able to derive a template entity directly from the parent, infrastructural one, e.g.

template:
  - sensor:
    - name: "living_room_temperature"
      unique_id: "living_room_temperature"
      base_entity_id: "sensor.temperature_humidity_sensor_0cb4_temperature"

which would take all characteristics of the base entity, with the capability to override specific aspects if needed, rather than having to recode a complete template definition.

Surely and advanced need/request, but hey…

2

I am doing same.
But instead of that “Go template generator” using a jinja code which I put into Dev tools → Templates to generate a yaml code which is then may be saved as some package.
A small simplified example is below:

{% set DEST_AND_SOURCE_NAMES = [
  ("x_1","sensor"),
  ("x_2","sensor"),
  ("x_3","sensor"),
  ("x_4","sensor"),
  ("x_5","sensor"),
] %}

{% set PARAMETERS = [
  ("co2",        "co2",        "co2",        "carbon_dioxide",                  "molecule-co2"),
  ("tvoc",       "tvoc",       "tvoc",       "volatile_organic_compounds_parts","cloud-alert"),
  ("temperature","temperature","temperature","temperature",                     "thermometer"),
  ("humidity",   "humidity",   "humidity",   "humidity",                        "water")
] %}

{% set code_parameter_from_attr = '
      - name: {0}_{2}
        unique_id:
        unit_of_measurement: !secret glob__unit_of_measurement__{3}
        device_class: {4}
        icon: mdi:{5}
        state: >-
          {{% set SENSOR = "{1}.{0}" -%}}
          {{{{ state_attr(SENSOR,"{6}") }}}}
' %}

template:
  - sensor:
{%- for device_name,source_domain in DEST_AND_SOURCE_NAMES -%}
  {% for parameter,attribute,unit,dev_class,icon in PARAMETERS -%}
    {{ code_parameter_from_attr.format(
         device_name,
         source_domain,
         parameter,
         unit,
         dev_class,
         icon,
         attribute) }}
  {%- endfor %}
{%- endfor %}

(the example is based on a larger code, some things are omitted, but still it gives the idea)
This approach may be used to generate MANY entities of different platforms (template, input helpers, automations etc).

But for that example:

template:
  - sensor:
    - name: "living_room_temperature"
      unique_id: "living_room_temperature"
      base_entity_id: "sensor.temperature_humidity_sensor_0cb4_temperature"

I would choose using a blueprint for a template sensor where a “source entity” is a variable. According to a few of my tests, the “template blueprint” does work - but only for non-trigger-based template sensors (one, two, also here).

3

I don’t think template blueprints are quite ready for prime.
I’m fighting with a button blueprint, and cannot understand the error

As for a jinja generator, fair enough. Cumbersome for cumbersome, I might find my way cleaner for my taste.