Ankündigung

Einklappen
Keine Ankündigung bisher.

Unterschiede "sensor" in configuration.yaml und template.yaml?

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    Unterschiede "sensor" in configuration.yaml und template.yaml?

    Hallo zusammen

    jetzt beginne ich damit, mich mit HA zu beschäftigen. Vielen Dank schon einmal an alle - vor allem scw2wi - für die zahlreichen Tipps und Hinweise. Zur Umsetzung der vielen Möglichkeiten fehlt mir aber (noch :-) das notwendige Grundlagenwissen.

    Zum Hintergrund:
    Ich nutze gern, seit langem und intensiv EDOMI. Dabei bin ich jedoch bei ein paar neuen Geräten an Grenzen gestoßen. Zuerst habe ich HA eingesetzt, um einen Deckenventillator mit Tuya über Local Tuya auf den KNX-Bus zu bringen (HA also quasi als Tuya-KNX-Bridge).
    Jetzt habe ich eine PV-Anlage mit DEYE-Wechselrichter, dessen Daten ich auch in HA habe. Der WR liefert für die beiden Strings jeweils die aktuelle Leistung. Ich möchte zusätzlich die Gesamtleistung sehen, also Summe der beiden String-Leistungen. Dazu habe ich zwei Lösungen im Netz gefunden und ausprobiert:


    a) in configuration.yaml​:

    Code:
    sensor:
      - platform: template
        sensors:
          energy_pv_garage_total:
            friendly_name: 'PV-Leistung Garage, gesamt'
            value_template: "{{ (states('sensor.deye_pv1_power')|float + states('sensor.deye_pv2_power')|float)|round(0) }}"
            unit_of_measurement: "W"
    b) in template.yaml:

    Code:
    - sensor:
      - name: "PV-Leistung Garage, gesamt 02"
        device_class: power
        unit_of_measurement: "W"
        state: "{{ (states('sensor.deye_pv1_power')|float + states('sensor.deye_pv2_power')|float)|round(0) }}"

    Beide Berechnungen bringen erwartungsgemäß das gleiche Ergebnis.
    Nun meine Frage(n):
    Welche Vor-/Nachteile haben beide Lösungen bzw. was sollte (und warum) eingesetzt werden?
    Oder ist beides nur eine andere Schreibweise für das gleiche?

    Also es fehlen mir noch die Grundlagen. Trotzdem vielen Dank für Eure Hinweise
    Gruß Marco

    #2
    Code:
    template:
      sensor:
        - wasauchimmer
    ist die aktuelle Art Template sensoren zu erstellen. Es ist auch die Art, die in der aktuellen Doku beschrieben wird.

    Code:
    sensor:
      - platform: template
        sensors:
          - wasauchimmer
    ist die alte Art. Wusste gar nicht, dass die überhaupt noch geht.

    Der einzige Unterschied liegt in der Hierarchie:

    Neu: Platform/Integration -> Entitätstyp -> Einzelne Entität des Typs
    Alt: Entitätstyp -> Platform/Integration -> Einzelne Entität des Typs

    Warum das mal geändert wurde, keine Ahnung. Wahrscheinlich damit alles zu einer Integration an einer Stelle ist statt verstreut.

    Mach am besten das neue, denn da wird man auch in der Doku mehr zu finden.


    Noch ein Tipp zu deinem spezifischem Template: Mach dir Gedanken was passieren soll wenn dein Quellsensor sensor.deye_pv1_power (und deye_pv2_power) mal auf unavailable oder unknown stehen. Denn aktuell würde dein Umwandlung zu float dann einfach fehlschlagen und einen Fehler im Log erzeugen, dass das Template einen Fehler geworfen hat. Siehe dazu auch hier.

    Kommentar


      #3
      Und da du mich explizit so lobend erwähnst, möchte ich dir auch noch ein paar Tipps geben.

      Die Prüfung auf unavailable kannst du entweder selbst entwickeln oder auch von der KI erstellen lassen, z.B. mit folgendem Prompt.

      "prüfe den folgenden template sensor auf robustheit: <code_vom_sensor>"

      Das Ergebnis kann ich meist 1:1 übernehmen.

      Wenn du dir von der KI einen template sensor, template trigger oder sonst was erstellen lässt, dann wird sehr oft die alte Syntax geliefert. Auch das kann man verhindern, wenn man es der KI vorher sagt. Wenn du das mit der KI bis ins Extreme treiben möchtest, hier entsteht gerade eine Anleitung dazu: Using ChatGPT for yaml Generation.

      Es wurde hier zwar mal behauptet, dass man bei copy/paste von KI-Code nichts mehr lernt, bei mir ist jedoch genau das Gegenteil der Fall, da ich jeden von der KI generierten Code mir Zeile für Zeile erklären lasse und dabei sehr viel lerne. Bei komplexen Themen verwende ich auch 2 KIs parallel und merge dann die beiden Ergebnisse (best of both).

      ​Ich hab hier eine Anleitung geschrieben, wie man die configuration.yaml möglichst schlank hält und soviel wie möglich ausgliedert. Die aktuelle Warnung in #2 würde ich ernst nehmen.

      Kommentar


        #4
        Ich danke Euch erst einmal recht herzlich: Schon beim ersten Lesen bin ich schlauer.
        Werde das dann heute Abend dann genauer anschauen und (wenn ich es dann richtig durchschaut habe :-) umsetzen.

        Kommentar

        Lädt...
        X