Spezialbehandlung: Nullen von OutputHomePower - surfer1264/Zendure-Stuff GitHub Wiki

Output Home Power (DC-Ausgang des Hubs) wird auch nicht sauber genullt

Im Vergleich zu den beiden Akkusensoren lässt sich hier nicht ganz easy anhand von pack state der Null-Zustand ableiten, denn auch im Standby produzieren die Panels weiter und schieben im Zweifel Energie ins Haus.

Wann kann OutputHomePower NULL werden?

  • Bedingung 1: wenn der Hub im Standby ist oder nur den Akku lädt (also packstate in [0,1])

und

  • Bedingung 2: wenn die Differenz aus solar_input_power und output_pack_power (Akku laden) kleiner ist als der geringste Einspeisewert des Hubs. Beim SF1200 sind das so um die 20W, die ich da sehe. ( gut tastbar, wenn man den Wechselrichter ausschaltet, dann geht
    solar_input_power komplett über in output_pack_power, die Differenz damit gegen Null.)

dann

  • kann es keine Output Home Power geben, also NULL.

Lösungsvariante 1

der Template-Sensor sieht so aus:

  - name: "SF Output Home Power Filtered"
    unique_id: sf_output_home_power_filtered
    unit_of_measurement: "W"
    device_class: power
    state_class: measurement
    state: >-
      {% set pack_state = states('sensor.solarflow_pack_state') | string %}
      {% set output_home = states('sensor.solarflow_output_home_power') | float(default=0)  %}
      {% set output_pack = states('sensor.sf_output_pack_power_filtered') | float(default=0) %}
      {% set solar_input = states('sensor.solarflow_sf_solar_input_power') | float(default=0) %}
      {% set surplus = solar_input - output_pack %}
      {% if pack_state in ['0', '1'] and surplus < 15 %}
        0
      {% else %}
        {{ output_home  }}
      {% endif %}

Achtung: Der Sensor nutzt den bereits abgeleiteten Template-Sensor für output_pack_power (heißt bei mir sensor.sf_output_pack_power_filtered)

Achtung: Achtet auf die Namensgebung Eurer Sensoren (nicht einfach nur kopieren hier!!!)

Die Sensordefinition einfach der template.yaml hinzufügen, wie bereits hier beschrieben.

Das funktioniert schon sehr zuverlässig, aber solar_input power wird viel öfters aktualisiert, als output pack power, sodass der Rechenwert der Differenz schneller kleiner 15W ist als der reale Wert und somit Output Home Power etwas zu oft (und auch nur kurz) versehentlich genullt wird. On top gibt es immer wieder diese Spikes nach unten (Datenlücken?), die den SolarInput kleiner machen als er ist. Auch das wird ggf. fehlinterpretiert. Am Ende sind das Timingprobleme.

Das lässt sich nur bedingt einfach in einem Template-Sensor abbilden. Aber es gibt eine Lösung.

Lösungsvariante 2

Erstens:

einen Template-Sensor Solarflow Surplus Power bauen, der nur die Differenz aus solar_input_power und output_pack_power abbildet, diesen in der template.yaml anlegen.

  - name: "Solarflow Surplus Power"
    unique_id: solarflow_surplus_power
    unit_of_measurement: "W"
    state: >-
      {% set solar_input = states('sensor.solarflow_sf_solar_input_power') | float(default=0) %}
      {% set output_pack = states('sensor.sf_output_pack_power_filtered') | float(default=0) %}
      {{ solar_input - output_pack }}

Hier wird nur die Differenz zwischen solar_input_power und output_pack_power gebildet. (Bedingung 2)

Zweitens:

einen Schalter(Boolean) als Helfer-Sensor anlegen: sf surplus low.

Den Boolean benötigen wir gleich in folgender Automatisierung.

Drittens:

Eine Automatisierung anlegen. Den folgenden Code in die automatisierungs.yaml kopieren.

- alias: "Setze sf_surplus_low, **wenn 70s unter 15W**"
  triggers:
  - trigger: numeric_state
    entity_id: sensor.solarflow_surplus_power
    below: 15
    for:
      hours: 0
      minutes: 1
      seconds: 10
  actions:
    - action: input_boolean.turn_on
      target:
        entity_id: input_boolean.sf_surplus_low
  mode: single
- alias: "Setze sf_surplus_low zurück, wenn über 15W"
  triggers:
  - trigger: numeric_state
    entity_id: sensor.solarflow_surplus_power
    above: 15
  actions:
    - action: input_boolean.turn_off
      target:
        entity_id: input_boolean.sf_surplus_low
  mode: single

Wenn die Differenz (aus Schritt1) über 70 Sekunden unter (hier) 15W liegt, dann wird der Boolean (aus Schritt2) ON (wahr). Wenn die Differenz wieder größer ist als 15, dann wird der Boolean auf OFF (falsch) gesetzt.

Die obige Bedingung 2 wird hier abgesichert. Mit dem Boolean wird die Wahrscheinlichkeit abgebildet, dass Output Home Power tatsächlich NULL ist. Und diesen Zustand nutzen wir nun in unserem Template für unseren neuen Output Home Power Filtered - Sensor im Schritt4.

Viertens:

Wir bauen den neuen abgeleiteten Sensor für Output Home Power. Folgender Code ist in der template.yaml abzulegen. (Achtet auf EURE Sensornamen!!).

Obige Bedingung 1 wird hier mit der nun abgesicherten Bedingung 2 zusammengeführt.

  - name: "SF Output Home Power Filtered"
    unique_id: sf_output_home_power_filtered
    unit_of_measurement: "W"
    device_class: power
    state_class: measurement
    state: >-
      {% set pack_state = states('sensor.solarflow_pack_state') | string %}
      {% set output_home = states('sensor.solarflow_output_home_power') | float(default=0)  %}
      {% set surplus_low = states('input_boolean.sf_surplus_low') == 'on' %}
      {% if surplus_low and pack_state in ['0', '1'] %}
        0
      {% else %}
        {{ output_home }}
      {% endif %}

Diesen neuen Sensor nutzt Ihr nun im HA-Dashboard, und er wird zuverlässig NULL anzeigen, wenn er NULL ist.

Fazit

WENN Hub im Modus Stand-by (0) oder Akku_Laden (1) ist UND sich die Differenz zwischen Solar_Input und Output_Pack (Akku LAden) für mindestens 70 Sekunden unter 15W bewegt, DANN kann Output Home Power Filtered auf NULL gesetzt werden.

Mit den zwei Parametern kann man jetzt etwas spielen:

  • der Differenzgrenze (hier 15 W)
  • der Zeitgrenze (hier 70 Sekunden)

Muss man das alles machen?

Auf keinen Fall. 😀

Dies ist für die Enthusiasten, die unbedingt ein sauberes Dashboard wollen (aber Lösungsvariante 1 ist da schon sehr nah dran.)