template Probleme nach Update auf 2025-12-01

[scw2wi]

Fast richtig, zwischen Minus und sensor: fehlt noch ein Leerzeichen, und das s gehört auch noch weg.
Frage: Hat dir die Repair Meldung diesen falschen Code generiert, oder hat die KI den halluziniert?

Der Repair-Vorschlag hat den Vorteil, dass er bei der Migration kaum Fehler macht. Er hat aber den Nachteil, dass er die Jinja2-Code Formatierung zerstört. Man kann das Vermeiden indem man den gesamten vorgeschlagenen Block mal kopiert und dann die Jinja2-Blöcke vom Original Code 1:1 reinkopiert, und dabei auf die Einrückung achtet.

unique_id ist schon mal gut, damit kann HA den Sensor eindeutig wiedererkennen.

default_entity_id ist nicht unbedingt notwendig, er sollte auch so denselben Namen wieder bekommen. Wenn dir das aber wichtig ist, dann kannst du diesen Parameter auch noch ergänzen. Die unique_id lautet bei dir zwar gleich, aber das ist HA völlig egal und hat mit dem Namen eigentlich gar nichts zu tun. Das ist nur irgendein unique String, wie z.B. 97d4bc87-42b7-4bde-a596-8ec2553edd74

Wenn du es noch schöner machen möchtest, kannst du auch noch availability ergänzen. Das hat mir schon so manche Fehlermeldung erspart.

default_entity_id: sensor.cover_e3_kueche_status

availability: >
  {{ has_value('cover.kuche_links') and has_value('cover.kuche_rechts') }}​
​

Die Frage ist jetzt, wohin mit diesem Code.

Wie viele template: hast du in all deinen yaml files zur Zeit?

Du hast zwar oben bereits einen Ausschnitt deiner configuration.yaml attached, da fehlt aber leider genau der template Eintrag. Kannst du diese Zeile hier noch posten, z.B.:

template: !include_dir_merge_list templates/

Je nachdem, ob diese Zeile auf ein File oder einen Folder zeigt, geht es dann leicht unterschiedlich weiter.
Wenn es ein Folder ist, dann würden mich noch die Filenamen in diesem Folder interessieren.

Meine Empfehlung wäre, mache das Schema zuerst mal so weiter, wie du aktuell auch die anderen Domänen verwaltet hast, also noch keinen Umstieg auf das neue packages System, sonst hast du 2 Migrationsschritte in einem - das würd ich nicht gleichzeitig machen wollen.

[Sven1973]

Wie viele template: hast du in all deinen yaml files zur Zeit?

derzeit sind es 4 yaml Datein mit einigen Tempalte-Sensoren.

[scw2wi]

Wie sieht die Folderstruktur und die include Einbindung aus?
Hast du nur template sensoren, oder auch template trigger, template cover oder anderes?
Fehlt in allen diesen bestehenden Files der Eintrag template: ?

Meine Idee wäre, den neuen Sensor mal direkt oberhalb von einem bestehenden reinzukopieren, und nicht vergessen, den alten auszukommentieren, dann ein YAML-Reload machen und den Sensor suchen, ob er denselben Namen wieder bekommen hat.

[Sven1973]

Ich bekomme das template nicht geladen!

Ich habe jetzt mal eine yaml-Datei genommen die nur einen template sensor beinhaltet und dieser wird nicht geladen...

template:
  - sensors:

    - name: "Temperatur E08 MasterBad"
      unique_id: temperatur_e08_masterbad_01
      state: "{{ states('sensor.master_bad_e8_tt1_raumtemperatur') }}"
      unit_of_measurement: "°C"
      icon: >-
        {% set icon_current = state_attr('climate.badezimmer', 'hvac_action') %}
        {% if icon_current == 'heating' %}
          mdi:fire
        {% else %}
          {{ state_attr('sensor.master_bad_e8_tt1_raumtemperatur', 'icon')}}
        {% endif %}
      attriebutes:
        hs_color: >-
          {% set hvac_status = state_attr('climate.badezimmer', 'hvac_action') %}
          {% if hvac_status == 'heating' %}
            [0, 100]   # red
          {% else %}
            
          {% endif %}
        device_class: "{{ state_attr('sensor.master_bad_e8_tt1_raumtemperatur', 'device_class') }}"
        state_class: "{{ state_attr('sensor.master_bad_e8_tt1_raumtemperatur', 'state_class') }}"    ​

und in der configuration.yaml

homeassistant:
  packages:   
    temperatur: !include conf/temperatur.yaml    ​

[scw2wi]

Wie sieht die Folderstruktur und die include Einbindung aus?
Fehlt in allen diesen bestehenden Files der Eintrag template: oder ist er vorhanden?

Meine Idee wäre, den neuen Sensor mal direkt oberhalb von einem bestehenden reinzukopieren, also in eine bereits bestehende Datei.

Du hast oben einen anderen Sensor gepostet als jetzt, um welchen Sensor geht es aktuell?
Im aktuellen Sensor sind so viele Tippfehler, da wundert es mich nicht, wenn der nicht geladen wird.
Beim oberen Sensor hab ich nur 2 Tippfehler gefunden, die kannst du recht einfach korrigieren.

Der Repair-Vorschlag hat den Vorteil, dass er bei der Migration kaum Fehler macht. Er hat aber den Nachteil, dass er die Jinja2-Code Formatierung zerstört. Man kann das Vermeiden indem man den gesamten vorgeschlagenen Block mal kopiert und dann die Jinja2-Blöcke vom Original Code 1:1 reinkopiert, und dabei auf die Einrückung achtet.

[Sven1973]

versuchen wir es mit dem letzten Template-Sensor.

ich versuche es erst einmal mit der kleinsten yaml die ich habe. Ich bin noch auf 11.3, geht das erst ab 12.x
mein Problem ist, ich musste jetzt schon 3x rücksichern

welxhe Tippfehler meinst du im letzten sensor?

[scw2wi]

Rücksichern musst du nur dann, wenn du deinen Code nicht irgendwo gesondert abspeicherst, das würde ich mit jedem Sensor machen, bevor du ihn migrierst.
Copy/Paste in eine TXT und speichern.

Im Post #29 hab ich einen Migration Helper verlinkt, der würde die Sache extrem vereinfachen, da er einfach sämtliche zu migrierende Sensoren in eine neue Datei reinschreibt, und man diese nur mehr einbinden muss.

Was ich so auf die Schnelle sehe:

sensors: >= sensor:

attriebutes: => attributes:

Warum hast du device_class und state_class unter attributes, dort bringen sie doch nichts? Das würde ich jetzt aber noch nicht ändern, nur mal als Anmerkung für eine weitere Aufräumaktion.

Die default_entity_id ist zwar nicht unbedingt notwendig, er sollte auch so denselben Namen wieder bekommen. Wenn dir das aber wichtig ist, dann kannst du diesen Parameter auch noch ergänzen. Die unique_id verwendet HA nicht als Default-Wert für die entity_id. Das ist nur irgendein unique String, wie z.B. 97d4bc87-42b7-4bde-a596-8ec2553edd74.

[Sven1973]

okay, jetzt bin ich etwas verwirrt. Ich möchte das sensor immer den namen temperatur_e08_masterbad bekommt.
wo muss der dann rein?

[scw2wi]

unique_id: temperatur_e08_masterbad_01
default_entity_id: sensor.temperatur_e08_masterbad_01

unique_id ist komplett beliebig und muss nur unique sein, bei mir sehen die unique_id immer so aus, wie der Studio Code Server sie automatisch befüllt, ohne dass ich irgendwas tippen muss, also so: d9a24e89-dd6d-4640-b390-4a276b132e47
Diese ID ist nur intern zur Verwaltung und wird im UI nicht angezeigt.

default_entity_id wird als Vorschlag genommen, wie der Name (die entity_id) des Sensors sein soll. Wenn der noch frei ist, dann bekommt er diesen Namen, wenn nicht, dann nicht. (dann kommt ein _2 hinten dran)

Umbenennen kannst du einen Sensor nach der Erstellung nur über das UI, und auch nur, wenn er eine unique_id hat.

default_entity_id musst du danach nicht anpassen, kannst sie aber ändern, damit sie wieder mit dem neuen Namen übereinstimmt.

unique_id darfst du nicht ändern, niemals ändern! Sobald du die unique_id änderst, ist das für HA ein neuer Sensor und du verlierst die gesamte History, selbst wenn der Sensor den gleichen Namen bekommt.

Viele Leute verwechseln diese beiden Einträge. Es ist auch nicht sehr verständlich dokumentiert, da die best Practices dort wieder mal fehlen.

Wenn du die default_entity_id weglässt, dann überlässt du HA die Entscheidung, wie die entity_id sein soll, und dann wird der Name nach einem Algorithmus verarbeitet. Alles in Kleinbuchstaben, Leerzeichen zu Underline, Umlaute entfernt, ... ev. noch ein _2 hinten dran, um die entity_id eindeutig zu machen.

Verwirrend finde ich auch, dass der Name eines Sensors die entity_id ist, und das was als Name angegeben wird, ist eigentlich der friendly name.

Ich bin übrigens morgen nicht online und erst ab Fr wieder hier unterwegs.

[Sven1973]

ahhh... okay, jetzt klappt es mit dem template.
dann hab ich ja nur ca. 50 vor mir.