template Probleme nach Update auf 2025-12-01

[ReinerDaniel]

Vielen Dank für das Angebot.
Ich muss mich jetzt leider um andere Sachen kümmern.
Melde mich morgen wieder.

Gruß Matthias

[scw2wi]

Melde mich morgen wieder.

Alles klar, ich bin morgen erst nachmittags Online.

Wenn du Passwörter sauber in secrets.yaml ausgelagert hast, dann kannst du auch mal deine gesamte configuration.yaml hier hochladen und ich sehe sie mir mit dem Studio Code Server mal an. Der sollte eigentlich sofort anzeigen, wo der Fehler steckt.

Wenn du einen Stand recovert hast, der funktioniert, dann sichere mal die aktuelle configuration.yaml irgendwo als Textfile hin.
Als nächstes mach einen Screenshot von der ersten Repair-Meldung und sichere auch deren Inhalt als Textdatei.

Die Kunst besteht dann darin, den Code aus der Repair-Meldung (ohne die erste Zeile) an die richtige Stelle zu pasten,
und im gleichen Schritt den alten Sensor zu entfernen (löschen oder auskommentieren).

Folgende Fehler könnten dabei passieren.

1. Die erste Zeile im Repair-Vorschlag wird nicht gelöscht.
2. Der Code wird an der falschen Stelle oder mit der falschen Einrückung reinkopiert.
3. Der Code wird nicht mit copy/paste übertragen sondern manuell, dabei können Fehler passieren.
4. Der alte Sensor wird nicht entfernt.
5. Im Template ist irgendwo ein einzelnes einfaches Hochkomma, damit kommt der aktuelle Migrationscode noch nicht klar. Die Lösung dafür wäre, die ganze Zeile unter doppeltes Hochkomma zu setzen.

Der erste Block wird dann am besten direkt nach der einzigen bestehenden template Zeile eingefügt und dann sehen wir uns Block1 (neu) und Block2 (alt) an, warum 2 weiterhin funktioniert und 1 direkt davor nicht.

Da du keine unique_id verwendest, kann es passieren, dass der neue Sensor von HA nicht exakt als Nachfolger des alten Sensors erkannt wird, dann ist die history kaputt und er bekommt möglicherweise ein _2 im Namen.

Falls dir die History wichtig ist, kannst du vor der Migration noch die unique_id einfügen und bekannt machen. Diese darf danach dann nie mehr geändert werden, solange du die History behalten willst.

Wichtig ist die Sicherung der betroffenen Files am Anfang (nicht nur das HA-Backup),
damit man jederzeit rasch wieder zurück kann, wenn irgend etwas nicht funktioniert.

[Tom Bombadil]

Das kann ich so nicht bestätigen. Ich hab mehr als 100 template sensoren und andere templates schrittweise migriert und da ist nie irgendwas falsch geworden.
Da ich überall auch eine unique_id verwendet hab, gab es nachher auch keine _2 sensoren, auch die history daten sind nahtlos weitergelaufen.

Doch. Ist auch logisch. Du hast zB in mehrere includes in einem Projekt ('package') - gekürzte Fassung der configuration.yaml:

homeassistant:
  packages:
    trovis:
      template main:       !include trovis557x/template_sensors.yaml
      template statistics: !include trovis557x/statistics.yaml
      template curves:     !include trovis557x/heating_curves.yaml

Dies fügt HA wie folgt zu einer Datei zusammen (da ist keine Intelligenz dabei - der pappt die einfach hintereinander weg, wie schon immer):

trovis:
  sensor:
    - template_sensors.yaml
    - statistics.yaml
    - heating_curves.yaml

Wenn Du jetzt Änderungen ausschliesslich an Datei #1 vornimmst (Einrückungen, einleitende Schlüssel änderst usw), knallt es natürlich. Denn Datei #2 und #3 werden so wie sind sind hinten dranmontiert und haben die neuen Einrückungen und Schlüssel aus Datei #1 ja noch nicht.

Mal ganz davon abgesehen, dass der oben angegebene Import mit mehreren Template Files jetzt plötzlich von einem auf den anderen Tag nicht mehr unterstützt wird - wenn Du erstmal angefangen hast, musst also mergen oder mit !include_dir arbeiten, um Deine config am Laufen zu halten. Alles Dinge, die mir heute passiert sind. Gruselig und definitiv nicht zu Ende bzw aus Sicht des Anwenders gedacht ...

/tom

[scw2wi]

Packages habe ich mir nie angetan und nachdem, was du erzählst, werde ich das weiterhin meiden.

Die template Migration ist das volle desaster, der Thread dazu hat schon über 700 Posts und es ist noch lange kein Ende in Sicht.

[Tom Bombadil]

Das da oben hat mit Packages nur bedingt was zu tun (hab das Beispiel nur zur Vereinfachung genommen). Du kannst die dort genannten Definitionen genauso direkt in die configuration.yaml tun, mit gleichem Ergebnis.

/tom

p.s. Packages solltest Du Dir echt mal ansehen. Speziell wenn man die Config in mehrere Dateien aufteilen und dabei eine klare Struktur mit configs in Unterverzeichnissen behalten will, sind sie in grossen Konfigurationen DAS Mittel der Wahl. Zumal Du beliebig viele Packages definieren und die Namen dabei frei vergeben kannst. Gute Alternative bzw. Ergänzung zu !include_dir_xx - jedes definierte Package ist quasi eine 'mini-configuration.yaml' für sich, parallel zur Hauptdatei.

[scw2wi]

Ich hab eine sehr übersichtliche Folder Struktur, in der ich mich gut zurecht finde. Ohne Not baue ich das ungern um.

/templates
..../template_sensors.yaml
..../template_triggers.yaml

Ich verwende auch in jedem File den "fold all" Befehl und sehe damit immer nur den obersten Level. Den Key sensors: verwende ich dann am Anfang jeder Sensorgruppe, damit ist auch diese in einem fold level gruppiert.

[Tom Bombadil]

Naja, ich mag mein HA halt per Gerät konfigurieren, und nicht per 'Entity type', der sich dann sogar noch aus verschiedenen Quellen ergeben kann (sensor, template sensor etc). KWL, Heizung, Müll, Kalender, NAS, Multimedia, Netzwerk - alles separate Config Files in ihren eigenen Verzeichnissen und somit im Fehlerfall schnell zu debuggen. Anders herum müsste ich immer alles durcheinanderschmeissen. Selbst petro denkt so. --> klick

/tom

[starwarsfan]

Hi

ich mag mein HA halt per Gerät konfigurieren, und nicht per 'Entity type'

Wenn ein sog. Package alles mögliche an YAML enthalten kann, also bspw. Sensoren, Templates, etc., dann werden die "Package-YAMLs" schlussendlich nach YAML-Struktur gemerged?

[Tom Bombadil]

Genau. Ich find das Prinzip der Packages mittlerweile genial. Du kannst sogar innerhalb des Packages weitere Aufsplittungen wie !dir_merge_xx machen.

Wann immer ich einen weiteren sensor: Haupteintrag in der configuration.yaml bräuchte (was öfter mal passiert), bau ich mir einfach ein Package: mit meinem Wunschnamen (der nur ein Platzhalter ist, mehr nicht), und kann mein yaml an beliebiger Stelle ablegen. Wenn ich nachher wieder am Rechner bin, kann ich mal ein paar Beispiele posten.

Die Haupteinträge in der configuration.yaml (zB sensor: include sensor.yaml) sind somit nur noch eine Sammlung für Klein- und Grabbelkram, wo sich kein eigenes File lohnt.

/tom

[Tom Bombadil]

starwarsfan Yves, ich will den Thread hier nicht kapern (eigentlich schon zuviel geschrieben) - guckst Du: Click.

/tom

[tsb2001]

Packages habe ich mir nie angetan und nachdem, was du erzählst, werde ich das weiterhin meiden.

Das da oben hat mit Packages nur bedingt was zu tun

Ich verstehe die ganzen Problematiken nicht.
Ich habe mittlerweile das Ganze auf 11 Packages (vom Müllkalender über die PV-Anlag bis hin zu den Wärmemengenzählern) gesplittet und habe die Templates vor geraumer Zeit in der Struktur und der passenden Konventionen angepasst. Heute habe ich von HA Version 2025.11.3 auf 2025.12.1 (die "0" hab ich übersprungen) geupdatete und alles läuft ganz normal weiter.
Ohne Fehler, ohne alles.
Durch das splitten wäre vielleicht eine Datei nicht lesbar gewesen (falls Fehlerbehaftet). Das ist aber definitiv einfacher zu beheben, als sich komplett entlang einer .yaml zu hangeln, wo alles drin liegt.

[ReinerDaniel]

Hier mal ein kurzer Sachstand.
Ich bin mit dem Backup auf den Stand 2025.11.3 zurück gegangen.
Damit funktioniert erst mal wieder alles. Natürlich ist das keine Lösung. Ich würde gerne auf Eure angebotene Hilfe zurückkommen, schaffe es aber heute und die nächsten Abende sicher nicht (muss/darf zu mehreren Weihnachtsfeiern).
Ich würde mich melden, wenn ich einen neuen Anlauf starte.
Ich habe schon länger den Studio Code Server installiert, aber noch nicht als Editor benutzt. Das wäre ich noch vorher implementieren.
Ich würde auch gerne vorher, wie von Tom vorgeschlagen, die getriggerten templates zusammenfassen. Und das vor dem Backup. Frage wäre noch wie,
aber das wird Tom sicher noch schreiben.
Problem nicht gelöst, aber vorerst vertagt.
Euch noch vielen Dank und einen schönen zweiten Advent!
Matthias

[scw2wi]

Kein Stress, du hast für die Migration 6 Monate Zeit und kannst sogar problemlos neue HA-Updates installieren. Musst halt dann die Repair Messages vorübergehend ignorieren. Danach können wir anhand von den Schritten aus Post #17 vorgehen, dann kann nichts passieren.

[scw2wi]

Das hier könnte eine super Lösung sein, um alle alten templates auf einmal zu migrieren.

Legacy Template Migration Helper

[Sven1973]

nachdem ich, zumindest hoffe ich das, meine Ordnerstruktur 2025.12.x confirm aufgeräumt habe, komme ich nun zu dem schwierigen Thema Tempates. Ich habe mir den von Tom Bombadil verlinkten Tread durgelesen und kann sagen, ich bin verwirrter als vorher.

Bsp.:
alte Formatierung:

  - platform: template
  
    sensors:

      cover_e3_kueche_status:
        friendly_name: Cover E3 Kueche Status
        unique_id: cover_e3_kueche_status
        value_template: |
          {% set b1_cover_current = state_attr('cover.kuche_links', 'current_position') | int %}
          {% set b2_cover_current = state_attr('cover.kuche_rechts', 'current_position') | int %}
          {% if b1_cover_current == b2_cover_current %}
            {{ b1_cover_current }}
          {% elif b1_cover_current > b2_cover_current %}
            {{ b1_cover_current }}
          {% else %}
            {{ b2_cover_current }}
          {% endif %}
        icon_template: |
          {% set cover_list = [state_attr('cover.kuche_links', 'current_position') | int,
                              state_attr('cover.kuche_rechts', 'current_position') | int] %}
          {% set behang_status = cover_list | min %}  
          {% if behang_status == 100 %} kuf:fts_window_2w
          {% elif behang_status < 100 and behang_status >= 90 %} kuf:fts_shutter_10
          {% elif behang_status < 90 and behang_status >= 80 %} kuf:fts_shutter_20
          {% elif behang_status < 80 and behang_status >= 70 %} kuf:fts_shutter_30
          {% elif behang_status < 70 and behang_status >= 60 %} kuf:fts_shutter_40
          {% elif behang_status < 60 and behang_status >= 50 %} kuf:fts_shutter_50
          {% elif behang_status < 50 and behang_status >= 40 %} kuf:fts_shutter_60
          {% elif behang_status < 40 and behang_status >= 30 %} kuf:fts_shutter_70
          {% elif behang_status < 30 and behang_status >= 20 %} kuf:fts_shutter_80
          {% elif behang_status < 20 and behang_status >= 10 %} kuf:fts_shutter_90
          {% else %} kuf:fts_shutter_100
          {% endif %}​

nach den Vorschlägen von Home Assistant, müsste die neue Formartirung wie folgt lauten

  template:
  
    -sensors:

      - name: Cover E3 Kueche Status
        unique_id: cover_e3_kueche_status
        state: |
          {% set b1_cover_current = state_attr('cover.kuche_links', 'current_position') | int %}
          {% set b2_cover_current = state_attr('cover.kuche_rechts', 'current_position') | int %}
          {% if b1_cover_current == b2_cover_current %}
            {{ b1_cover_current }}
          {% elif b1_cover_current > b2_cover_current %}
            {{ b1_cover_current }}
          {% else %}
            {{ b2_cover_current }}
          {% endif %}
        icon: |
          {% set cover_list = [state_attr('cover.kuche_links', 'current_position') | int,
                              state_attr('cover.kuche_rechts', 'current_position') | int] %}
          {% set behang_status = cover_list | min %}  
          {% if behang_status == 100 %} kuf:fts_window_2w
          {% elif behang_status < 100 and behang_status >= 90 %} kuf:fts_shutter_10
          {% elif behang_status < 90 and behang_status >= 80 %} kuf:fts_shutter_20
          {% elif behang_status < 80 and behang_status >= 70 %} kuf:fts_shutter_30
          {% elif behang_status < 70 and behang_status >= 60 %} kuf:fts_shutter_40
          {% elif behang_status < 60 and behang_status >= 50 %} kuf:fts_shutter_50
          {% elif behang_status < 50 and behang_status >= 40 %} kuf:fts_shutter_60
          {% elif behang_status < 40 and behang_status >= 30 %} kuf:fts_shutter_70
          {% elif behang_status < 30 and behang_status >= 20 %} kuf:fts_shutter_80
          {% elif behang_status < 20 and behang_status >= 10 %} kuf:fts_shutter_90
          {% else %} kuf:fts_shutter_100
          {% endif %}​

habe ich das richtig verstanden?