Neue Entitäten / Verbrauchszähler durch Berechnungen

Bislang habe ich in der configuration.yaml diverse Berechnungen, durch die aus anderen Entitäten Werte für neue Entitäten entstehen. Da ich mein Ausreißer-Problem beim Neuladen der Config noch weiter in den Griff bekommen will, würde ich - wie schon durch das Anlegen von Verbrauchszählern - gerne weitere Helfer aus der configuration.yaml entfernen.

Jetzt habe ich mir das

mal angeschaut. Allerdings nutzt das allenfalls für manche Berechnungen:

Kombinationssensor

Erstellt einen Sensor, der aus einer Liste von Eingabesensoren deren Minimal-, Maximal-, Mittel-, Median- oder Summenwert berechnet.

Damit lassen sich also nur Additionen realisieren.

Hier mal ein paar Bsp:

  1. Differenzbildung
# PV neu: Eigenverbrauch
  - sensor:
    - name: Eigenverbrauch PV neu (mit Langzeitkorrektur)
      unique_id: eigenverbrauch_pv_neu
      device_class: Energy
      state_class: total_increasing
      unit_of_measurement: "kWh"
      state: >
        {% set neuer_wert = states('sensor.gesamtertrag_pv_neu') | float(0) - states('sensor.verbrauchszaehler_einspeisung_pv_neu_korrigiert') | float(0) %}
        {% set alter_wert = states('sensor.eigenverbrauch_pv_neu') | float(neuer_wert) %}
        {% set differenz = neuer_wert - alter_wert %}
        {% if 0 < differenz <= 0.5 %}
          {{ neuer_wert }}
        {% else %}
          {{ alter_wert }}
        {% endif %}

Die Werte von Gesamtertrag und Einspeisung (brauche ich auch für das EVU) kann ich aus dem Wechselrichter und Stromzähler erfassen, den des Eigenverbrauchs muss ich berechnen.

  1. Multiplikation
# Kosten pro 100 km
  - sensor:
    - name: Kosten pro 100 km
      unique_id: kosten-pro-100-km
      device_class: Monetary
      state_class: total
      unit_of_measurement: "€/100 km"
      state: "{{ states('sensor.evcc_statistik_wallbox_warp3_und_ladesteckdose_preis_kwh_gesamt') | float(0) * states('input_number.durchschnittsverbrauch') | float(0) }}"    

Das kann ich ebenfalls nur berechnen.

  1. Division und Multiplikation
# Berechnung des Wirkungsgrades
  - sensor:
    - name: Wirkungsgrad (Stromspeicher)
      unique_id: wirkungsgrad_stromspeicher
      device_class: battery
      state_class: measurement
      unit_of_measurement: "%"
      state: "{{ (states('sensor.total_battery_discharge') | float(0) / states('sensor.total_battery_charge') | float(0)) * 100 }}"

Auch das kann ich nur berechnen. Das wird vom Wechelrichter / Speicher nicht zur Verfügung gestellt.

Wie ich schon sagte ein Teil deines Problems besteht darin das du Verfügbarkeit nicht prüfst


# Kosten pro 100 km
- sensor:
    - name: "Kosten pro 100 km"
      unique_id: kosten_pro_100_km
      device_class: monetary
      state_class: total
      unit_of_measurement: "€/100 km"
      state: >
        {{ states('sensor.evcc_statistik_wallbox_warp3_und_ladesteckdose_preis_kwh_gesamt') | float(0) * states('input_number.durchschnittsverbrauch') | float(0) }}
      availability: >
        {{ has_value('sensor.evcc_statistik_wallbox_warp3_und_ladesteckdose_preis_kwh_gesamt') and has_value('input_number.durchschnittsverbrauch') }}

Das wäre dann der nächste Schritt für alles, was in der configuration.yaml verbleibt. Aber je weniger da drin steht, desto besser, da auch sonst im Zuge der HA-Updates immer mehr daraus verschwindet bzw. entfernt werden muss, da es in die Einstellungen im UI wandert.

Du kannst den Sensor komplett im GUI umsetzen, erstelle über Helfer einen Template Sensor trage bei State die Berechnung ein
Und bei avaible die Prüfung .
Absolut simpel.

Ich bin ja eher der Typ Konfigurationsdatei statt Blackbox - Linux-Nutzer halt :rofl:
Aber nachdem die Entwicklung bei HA wohl weg von der configuration.yaml etc. geht, wäre es vielleicht sinnvoll, das tatsächlich so zu machen.

Einziger Haken: Ich kann den neuen Sensor nicht mit identischer unique-ID wie die bestehenden Sensoren anlegen und damit auf die vorhandenen Statistiken zugreifen, weil der unique-ID datenbankintern eine numerische ID zugeordnet wird und der neue Sensor da eine neue bekommt. Also muss ich für jeden Sensor wieder die Statistiken übertragen.
Den vorhandenen Sensoren in der configuration.yaml den Check hinzuzufügen würde das ersparen und den Aufwand deutlich reduzieren, zumal ich vor jeder solchen Aktion auch immer noch einen Snapshot mache, um auf den alten Stand zurück zu können, falls was schief geht. Das summiert sich insgesamt zeitlich ganz schön :see_no_evil_monkey:

Das geht , du musst nur die aktuelle Vorgehensweise dafür googeln

Nicht die uniqe ID ist entscheidend, sondern die Entity-id.

Diese leitet sich normalerweise von Namen ab.

Gruß Osorkon