Für die „alte“ Schreibweise von template Sensoren muss die Zeile Batteriestand raus und der Rest 1 zurückgerückt werden.
Kann es sein, dass Du darüber noch irgendwo
template:
stehen hast?
@anon90710413 "template:"steht im ersten Sensor Zeile 97
Was soll ich damit machen? Ich habe jetzt den zweiten “template” herausgenommen. Sieht schon wieder etwas besser aus
Bau den Zweiten genauso um, wie die Ersten sind.
EDITH: value_template wird zu state, friendly_name raus.
Wie oben mit
- name:
anfangen und
sensors:
und
battery_alert:
raus.
Und entsprechend zurechtrücken. Geht in fast jeden Editor mit Block markieren, TAB->vor, SHIFT-TAB->zurück.
1 „Gefällt mir“
Aus ‘attribute_templates’ muss ‘attributes’ werden.
Was passiert wenn du die löschst?
Nice! Dann ist erstmal Ruhe in Schiff. Nach der schweren Geburt werde ich jetzt mal sehen, was auf dem Dashboard so ankommt. Danke!
Nachtrag:
Hallo @guezli,
ich habe jetzt dank der zusätzlichen Unterstützung aus der Community alles so weit modifiziert, dass keine Fehlermeldungen mehr erscheinen.
Da aber nicht alle Batterien, die aktuelle wenig Leistung haben angezeigt werden, habe ich mal versucht mich in deinen Code hineinzudenken.
Nachdem ich, wie ich vermute, ein wenig davon verstanden habe, hoffe ich die Ursache gefunden zu haben.
Ich benutze Tado Heizkörperthermostate, die für die Batterie folgende Entität herausgeben “binary_sensor.va3541174528_battery_state” . Diese Entität gibt nur “Normal” oder “Niedrig” als Wert aus.
Ich vermute, dass dieser Fall von deiner Sensorauswertung noch nicht abgedeckt ist. Wenn ich richtig liege, könntest du so nett sein und deinen Code ein wenig erweiter? 
by HarryP: Zusammenführung Doppelpost.
*@mickysoft *
Bitte für Nachträge/Korrekturen die “bearbeiten” Funktion verwenden.Danke!
Darüber kannst Du mit “@”+User auch mehrere(n) andere(n) User(n) ansprechen/antworten (s.o.)
Ja, Tado ist in diesem Fall ein Sonderfall und braucht eine separate Lösung. Also ich habe noch keinen Code. Man könnte aber mit einem zusätzlichen Templatesensor arbeiten, der auf den Tado-Binärsensor zugreift.
1 „Gefällt mir“
Versuch das mal so für Tado:
- sensor:
- name: "Tado Batterie Status"
unique_id: "tado_battery"
unit_of_measurement: "%"
device_class: battery
state: >
{% if states('binary_sensor.va3541174528_battery_state') == 'off' %}100{% else %}25{% endif %}
Dann sollte(n) der / die mit berücksichtigt werden.
2 „Gefällt mir“
Danke @anon90710413 und @Macello. Ich habe gerade gesehen, dass ich einige Sensoren habe, die mit der alten Methode erstellt wurden. Ich kann sie nicht programmieren, sondern leite sie aus anderen Modellen durch Try and Error ab. Ich würde mich freuen, wenn jemand, der sich damit auskennt, hier im Forum eine Anleitung zur Migration von der alten auf die neue Methode schreiben könnte. Anderen Nutzenden wird es sicher ähnlich/gleich gehen.
Wenn es um die ‘template’ Sensoren geht, dann gibt es weiter oben in diesem Beitrag schon einen Link.
1 „Gefällt mir“
Den hatte ich übersehen. Danke für den Link.
1 „Gefällt mir“
Da es hier um das Thema Templates und Template Sensoren geht. Und sich ja viele mit dem YAML Code so schwer tun.
Warum kommt hier der Helfer Template Sensor nicht zu Sprache?
Jeden Template Sensor / Binary Sensor, außer trigger based Template Sensoren, kann man ohne eine einzige YAML Datei anzufassen zu müssen, direkt in der GUI erstellen.
Einstellungen-> Geräte & Dienste → Helfer → Template
Template eingeben, Maßeinheit, Geräteklasse, Zustandsklasse definieren falls erwünscht oder notwendig. Fertig! 
Man bekommt sogar eine Vorschau des Template Sensors. Und mit den Klick auf Absenden wird automatisch der Template Sensor erstellt und die template Konfiguration automatisch neu geladen. Und der Template Sensor steht sofort zur Verfügung.
BTW: Hier mal ein Template, welches die Anzahl der Dead Nodes (Z-Wave) ermittelt. Verwende ich als Auslöser um das betroffene Node anzupingen. Leider ist der lästige Bug mit der Firware 7.21.0 wieder zurück!! 
{{ integration_entities('zwave_js') | select('match', 'sensor\..*node_status')| select('is_state', 'dead') | list | count }}
Gruß
Osorkon
Punkt 1
Weil das was in der GUI möglich ist wenn man am positivsten beschreiben möchte halt nach wie vor nur ne Untermenge dessen ist was tatsächlich möglich ist.
Punkt2
Du kannst das was du da in der GUI gemacht hast mit viel Aufwand in den Tiefen von HA als YAML wieder finden solltest du mal etwas ändern müssen was sich über die GUI nicht ändern lässt weil es dort schlicht noch nicht implementiert ist.
Punkt3
Versuch mal Dinge die du in der GUI machst mit Kommentaren zu versehen was etwas genau macht und warum und was du dir dabei gedacht hat. Selbst wenn du an den Stellen an denen eine Umschaltung erlaubt ist zwischen Code und GUI werden beim Speichern sämtliche Kommentarzeilen verworfen.
Ja die GUI wird immer besser, gar keine Frage, aber selbst die Entwickler geben zu das der Punkt an dem die GUI 100% erlauben wird nicht erreichbar ist. Und man ist dann am Ende doch gut beraten sich das YAML anzutun, und nein ich mag es auch immer noch nicht.
Was ich vorbildlich gelöst finde sind die Automationen weil man dort ähnlich wie im lovelace dashboard immer zwischen YAML Code und GUI umschalten kann. Das ist genaugenommen die bestmögliche Variante sich YAML zu nähern weil man dort schnell sieht wie etwas gemacht werden muss.
Am Ende ist das mit YAML ähnlich gelagert wie die Frage ob ein HA ohne HACS das gelbe vom Ei ist. Und nein, ist’s natürlich nicht, ohne HACS ist’s nahezu wertlos. Gleiches gilt am Ende wenn man sich eingehender mit HA beschäftigt hat was das Thema YAML angeht. Denn das mit GUI Mitteln realisierbar ist, ist dann wie vorher bei HA ohne vs. mit HACS halt ne ganz andere Nummer.
Zum Helfer Templatehelfer hab ich ohnehin ein gespaltenes Verhältnis.
Alles was jeder sich an 3 Fingern abzählen kann also Maßeinheit, Geräteklasse und Zustandsklasse kann ich über die GUI eingeben. Wahnsinn, an den 3 Zeilen YAML scheitern vermutlich 0 Personen.
Aber das Template selbst, für das man dann doch YAML Kenntnisse braucht, das bietet schlicht keinen Vorteil. Hätte dieser Helfer n Template Editor direkt integriert würde ich sagen, ok zumindest ein minimaler Mehrwert ist gegeben weil man testen kann bevor man den Helfer speichert.
Der Hauptvorteil aktuell ist dann wohl wirklich der das man in der Hektik in nem Editor beim YAML code gerne die Geräte- und Zustandsklasse vergisst. In der GUI fällt es dann direkt auf das dort noch Felder sind die man vielleicht doch besseer füllen sollte. Ist ja speziell bei den Energie Templates immer ein üblicher Fehler warum solche Sensoren an gewissen Stellen dann nicht akzeptiert werden.
1 „Gefällt mir“
Normalerweise würde ich Deine Antwort nicht weiter kommentieren.
Jeder hat seine Meinung und seinen Vorlieben und das ist auch gut so.
Jedoch kann ich die Falschaussagen so nicht stehen lassen. Die so wie ich denke, nur aus Unwissenheit zustande kommen.
Alles was Du mit einen Template Sensor oder einem Template Binary Sensor anstellen kannst, kannst Du auch mit den Helfer Template anstellen.
Aufnahme, Trigger-Based Template Sensoren, die lassen sich nur über YAML erstellen.
Der Sinn und Zweck der Helfer in der GUI ist doch genau das Gegenteil. Man muss keine yaml anfassen. Nicht um ihn zu erstellen oder nachträglich zu ändern. Geschweige den in irgendwelchen Untiefen! Selbstverständlich lässt sich jeder in der GUI erstellter Helfer, auch der Template Helfer im nachhinein ändern und anpassen und zwar über die GUI.
Im Falle eines Template Helfers.
Template Entität Auswählen → 3 Punkte oben rechts → Zusatzinformationen → Template Helfer auswählen.
Wir sprechen hier von Template Sensoren und nicht von Automatisierungen, richtig?
Das Template welches Du verwenden tust um einen Template Helfer in der GUI zu erstellen, kannst Du genau so gut mit Kommentaren versehen, wie es in der YAML auch der Fall ist.
{## Das ist ein Kommentar ##}
{{ integration_entities('zwave_js') | select('match', 'sensor\..*node_status')| select('is_state', 'dead') | list | count }}
{## Dieses Template ermittelt die Anzahl an Dead Nodes ##}
Ich will ja keinen dazu bekehren. Der eine schwört auf YAML und der andere verflucht es!
Es war ein freundlicher Hinweis, dass man sich nicht zwingend mit YAML rumschlagen muss, wenn man einen Template Sensor erstellen will. 
Gruß
Osorkon
Du hattest die Frage stellt warum der Helfer nicht zur Sprache kommt obwohl er deiner Meinung ja Dinge vereinfacht.
Sorry aber wenn jemand nicht in der Lage ein Template, was nun mal YAML Code ist, zu erstellen dann nutzt ihm die schönste GUI Variante nix, denn das was in deinem Bildchen dann unter Zustandstemplate einzugeben ist, ist ja die Hürde und nicht das Tippen auf der Tastatur.
Aber ja du hast Recht so hat jeder sein eigene Sichtweise auf die Dinge.
Du hast Recht und ich meine Ruhe.
Und der Rest macht sich selbst ein Bild davon.
Gruß
Osorkon