Home Assistant Bastelbude - Heute: virtueller P1 Sensor

Henry · 2025-12-17T19:06:05+00:00

Hallo zusammen,/n/n Hier mal wieder ein kurzer Beitrag aus meinem Home Assistant Gefrickel./n/nAusgangspunkt: 2xSF2400, Steuerung über Zendure Manager aus de...

TL-F

Super werde ich gleich bei.mir übernehmen.

Surfer1264(2nd)

TL-F

Berichte mal bitte wie sich das bei Dir im täglichen Regelgeschäft auswirkt.

Das ganze ist eine Lösung für genau welches Problem ?

TL-F

Hallo Surfer1264 wie gewünscht eine Zusammenfassung:

Wie Henry richtig schreibt, versucht die Z-HA Steuerung eine sogenannte Nulleinspeisung zu gewährleisten, wenn man im Betriebsmodus die Smarte Leistungsregelung auswählt.
Dafür nimmt er den Wert des Sensors, den man in der Zendure Integrationsoptionen unter P1 Sensor für Smart Matching eingibt.
Dieser Wert kommt in der Regel, vom Zendure eigenen Gerät D0-Zähler oder Zähler 3CT (120A), beziehungsweise Shelly Pro 3EM, Ecotracker IR oder einen anderen Stromleser (Tasmota). Dieser Wert kommt je nach Einstellung sogar im Sekundentackt an.

Da die Z-HA Steuerung nun versucht möglichst auf null zu kommen heißt das, dass entsprechende Steuerbefehle auch im Sekundentackt gesendet werden müssen, obwohl es nur Schwankungen im Bereich von - 10 bis 10 Watt sind, die auf die Stromrechnung so gut wie keinen Einfluss haben.

Hier setzt die Lösung mit dem virtuellen P1-Sensor an, der diese minimalen Schwankungen herausfiltert und im Bereich von -10 bis 10 Watt der Z-HA Steuerung „vorgaukelt“, dass es keine Änderung gegeben hat, da er den Wert 0 übermittelt.

Dafür wird in der HA-Config-Datei das Script von Surfer1264 eingefügt und in der Zeile 3 der eigene Sensor, der bisher als P1-Sensor funktioniert, eingetragen.
In der Zendure Integrationsoptionen unter P1 Sensor für Smart Matching wird jetzt der Sensor „sensor.p1_sensor_virtuell“ eingetragen.

Der Vorteil beim virtuellen Sensor ist auch, dass man einen eigenen Nullbereich festlegen kann.
Derzeit ist -10 bis +10 eingestellt. {% set null_hyst = 10 %} {# ±10 W Totzone #}
Manche wollen, dass grundsätzlich 50 Watt bezogen werden, um die Einspeisung zu minimieren und andere wollen garantiert 50 Watt einspeisen, um so wenig wie möglich zu beziehen.

Meine Erfahrungen bisher sind, dass die Z-HA Steuerung nicht jede Wattanpassung im einstelligen Bereich sofort über den Wechselrichterausgang (‚sensor.hyper_2000_output_home_power‘) regelt, aber ist trotzdem bemüht, dass der Wert des P1-Sensors auf null steht.
Im Vergleich mit dem virtuellen Sensor regelt die Z-HA Steuerung über den originären Sensor (D0, Shelly, Ecotracker usw.) spätestens ab 5 Watt Unterschied (manchmal auch bei nur 1 Watt Unterschied) den Wechselrichteraugang.

Der virtuelle Sensor nimmt die Werte von -10 bis +10 und setzt sie auf 0, sodass der keine Regelung erfolgt. „Still ruht der See“

Beim zuschalten von Lasten gibt es kein Unterschied und beide regeln gleich schnell hoch oder runter.

Surfer1264(2nd)

TL-F Der virtuelle Sensor nimmt die Werte von -10 bis +10 und setzt sie auf 0, sodass der keine Regelung erfolgt. „Still ruht der See“

Super Danke @TL-F

Toll das der Sensor so funktioniert, wie von Dir gewünscht. Sehr einfacher Hebel und schön, dass ich noch ein paar Impulse setzen konnte. Ich lerne dabei selbst.

Die Funktion von ZHA ist mir klar, setzte ich seit Tag1 (April?) ein.
Und das ZHa versucht die Null zu erreichen liegt ja in der Natur der Sache.
Das Ausregeln von ein paar Watt finde ich perse nicht schlimm, die Hw und Sw ist dafür gemacht. Ich glaube nicht, dass man da extra Rücksicht nehmen muss.

Interessanter bei so einem virtuellem Sensor finde ich allerdings das Glätten des Signals, es gibt genug Verbraucher, die hin und her Flippern in kürzester Zeit. Diese Signale können nicht ernsthaft verarbeitet/ ausgeregelt werden, da macht das Glätten, insbesondere die zeitliche Entkopplung sehr viel Sinn.

Ich habe gerade die Tage überlegt, diesen virtuelle. Sensor auch zu nutzen, passt aber nicht in meine eigene Reglungsarchitektur, da ich das defacto am Reglerausgng schon mache und die zeitliche Entkopplung am Eingang auch schon da ist. Doppelt hilft eben nicht.

Die dynamische Sollwert Verschiebung (statt statischer Festlegung) basierend auf dem PV Forecast und Akkufüllstand ist auch am Start, so dass das ganze System Wettergeführt als Vollautomat läuft.

Mich interessieren aber all diese Ansätze und Konzepte und man sieht wie flexible und einfach man in HA Dinge verändern/ anpassen kann,

Danke für das Feedback und Melden. Schöne Feiertage und Beste Grüße

Henry

Und es hat auch noch den Vorteil, dass man in den virtuellen P1 Sensor zusätzlich beliebige Features integrieren kann, ohne die mE grundsätzlich gute Regelung von Z-HA verändern zu müssen.
Aus in Github veröffentlichten Versuchsreihen zum Thema Wirkungsgrad geht hervor, dass der SF2400 seinen maximalen Wirkungsgrad bereits ab ca 1100W erreicht. Da aktuell die PV Produktion ohnehin nicht ausreicht, um den kompletten Tagesbedarf zu decken, habe ich zb den virtuellen P1 Sensor inzwischen so angepasst, dass er, wenn ich Winterbetrieb aktiv habe, nur Leistungen >1100w bedient, einfach um das bisschen PV Strom aktuell möglichst effizient zu nutzen.
Und da lässt sich so ein virtueller P1 Sensor beliebig auf die eigenen Bedürfnisse abstimmen.

Surfer1264(2nd)

@TL-F

Hier noch die Ergänzung um einen (externen) Sollwert.
Mit einer Helfer-Entität: input_number.regler_sollwert (in HA vorher anlegen)

Mit diesem Sensor denkt die Z-HA Regelung , dass sie auf 0W regelt , tatsächlich wird jedoch auf einen beliebigen Sollwert optimiert, der von außen vorgegeben werden kann. Nette Übung

- trigger:
	- platform: state
	  entity_id: sensor.shellypro3em_power_actual_total
	  for:
		seconds: 3

  sensor:
	- name: "P1-Sensor Virtuell"
	  unique_id: shellypro3em_p1_virtual_power
	  unit_of_measurement: "W"
	  device_class: power
	  state_class: measurement
	  state: >
		{# --- Sollwert --- #}
		{% set soll = states('input_number.regler_sollwert') | float(0) %}

		{% if trigger.from_state is none or trigger.to_state is none %}
		  0
		
		{% else %}
		  {# --- Parameter --- #}
		  {% set null_hyst = 10 %}       {# ±10 W Totzone #}
		  {% set sprung = 30 %}          {# Sprungschwelle #}
		  {% set alpha = 0.2 %}          {# Glättung #}

		  {# --- Werte --- #}
		  {% set ist = trigger.to_state.state | float(0) %}
		  {% set neu = ist - soll %}
		  {% set alt = this.state | float(0) %}
		  {% set diff = neu - alt %}

		  {# --- Logik --- #}
		  {% if -null_hyst < neu < null_hyst %}
			0
			
		  {% elif diff | abs >= sprung %}
			{{ neu | round(1) }}

		  {% else %}
			{{ (alt + alpha * diff) | round(1) }}

		  {% endif %}
		{% endif %}

TL-F

Surfer1264(2nd) Hallo Surfer, Danke Dir nocheinmal für die Überarbeitung.

Das mit dem hinterher schleichen hat mir nich ganz so gut gefallen, deshalb habe ich das geändert und noch eine If -Else - Bedingung eingefügt und jetzt ist das Ergebnis so wie ich es mir vorgestellt habe.

Jetzt gehe ich das nächste Projekt an und schaue mir mal Deine Steuerung an.

Hier meine Lösung:

Virtueller Sensor P1 Zendure

trigger:
- platform: state
  entity_id: sensor.stromleser_lk13be_power
  
  sensor:
  - name: "P1-Sensor Virtuell"
    unique_id: P1-Sensor_Virtuell
    unit_of_measurement: "W"
    device_class: power
    state_class: measurement
    state: >
    {# --- Sollwert --- #}
    {% set soll = states('input_number.regler_sollwert_null') | float(0) %}
    {% if trigger.from_state is none or trigger.to_state is none %}
    0
    
    {% else %}
    {# --- Parameter --- #}
    {% set null_hyst = 15 %} {# ±10 W Totzone #}
    {% set sprung = 20 %} {# Sprungschwelle #}
    
    {# --- Werte --- #}
    {% set alt = this.state | float(0) %}
    {% set ist = trigger.to_state.state | float(0) %}
    {% set Bestand = states('input_number.p1_bestand') | float(0) %}
    {% set neu = ist - soll %}
    {% set diff = neu - alt %}
    {% set diff2 = neu - Bestand%}
    
    {# --- Logik --- #}
    {% if -null_hyst < neu < null_hyst %}
    0
    {% elif diff | abs >= sprung %}
    {{ neu | round(1) }}
```
{% else %}
  {% if diff2 | abs < sprung %}
    {{ Bestand | round(1) }}
  {% else %}
    {{ neu | round(1) }}
    actions:
      - action: input_number.set_value
      target:
        entity_id: input_number.p1_bestand
      data:
        value: "{{ neu | float(2) }}"
  {% endif %}
{% endif %}
```

{% endif %}

Henry

Ich hab mir heute mal die Mühe gemacht, einen kleinen Template Sensor zu schreiben, der die Anzahl der Regelvorgänge mitzählt, um mal einen Vergleich von reiner Z-HA Steuerung zu virtuellem P1 Sensor zu haben. Das Ergebnis war schon recht erstaunlich.
Jetzt Abends wenn der Stromverbrauch relativ konstant ist, macht die Z-HA Regelung ca 300 Regelungen pro Stunde, mit virtuellem P1 Sensor nur 30 Regelungen pro Stunde. Schon ein erheblicher Unterschied. Da hoffe ich doch mal schon, dass das die Lebensdauer der Komponenten im WR erheblich schont…😅

Surfer1264(2nd)

Henry macht die Z-HA Regelung ca 300 Regelungen

yupp, das überrascht in der Tat nicht...
die Hysterese macht viel aus....
Meine Standard-Hysterese ist sogar schon immer (plus/minus) 15W und begrenzt die Regelaktionen am Tag auf 1200 (im 24h Betrieb), der Reglertakt liegt bei 5 Sekunden (auch das glätte viel weg) ......schnell genug, gut genug.

Ich sehe das eher aus einer zeitlichen Entkopplungsperspektive. Die HW ist nicht so schnell wie das Auslesen des Smartmeters und Regelaktion berechnen. Regelungen übersteuern da schnell. So ein Filter bremst sie halt smart aus, für die Z-HA Smarte Regelung ist das ne smarte Sache.

Ob dadurch die HW länger hält???
Die rein technischen Komponenten sehe ich da als unkritisch an, die können das....ob sie 200W konstant liefern oder hin und her pendeln .....

Henry

Ich hab tatsächlich durch die Eventsteuerung gar keinen festen Regeltakt. Die Automation, die hinter dem virtuellen Sensor arbeitet, regiert auf jede Änderung am Shelly und bewertet dann, ob die Änderung eine derBedingungen für ein Event erfüllt. Erst wenn eine Bedingung erfüllt ist, gibt sie das delta target aktueller Shelly Wert an den virtuellen Sensor weiter, dh erst dann wird eine Regelung ausgelöst. Da vergehen vor allem Abends manchmal Minuten, bis neu geregelt wird. Quasi ein bedarfsgesteuerter Regeltakt.
Im Github gibt es sehr wohl Berichte, dass elektronische Bauteile im WR (kann mich nur nicht mehr an die genaue Bezeichnung erinnern) durch den Einsatz übereifriger HA Eigenbauregelungen gelitten haben.

Surfer1264(2nd)

Henry

Henry dass elektronische Bauteile im WR

Bei Wechselrichterherstellern gibts die Warnungen auch, weil dort EEPROMS verbaut sind, die nur ein paar 10 tausend Schreibzyklen aushalten.. Ich kenne das von den Hoymiles.
Ich habe eine APSystemEZ1, der vom Hersteller ab einer bestimmten Seriennummer freigegeben ist.

Bei den Solarflows gehe ich davon aus, dass das perse kein Problem ist.
Dort werden nicht nur die paar Regelaktionen verarbeitet, sondern Unmengen mehr von Daten(aktualisierungen), damit unsere HA Dashboards nett aussehen. Ich hoffe sehr, dass das in diesen Produkten anders gelöst ist.

Henry Die Automation, die hinter dem virtuellen Sensor arbeitet, regiert auf jede Änderung am Shelly und bewertet dann, ob die Änderung eine der Bedingungen für ein Event erfüllt.

I know this, so funktionieren alle Sensoren im HA, man legt sich auf den Eventbus und lauscht und greift ab oder triggert was man braucht. Andere Regelarchitektur....

Ich lege den Filter über das Ausgangssignal ......und da der SF1200 ein ziemlich gemächliches Regelverhalten hat, ist ein Takt gerade gut genug, nicht jedes Event ist relevant. Allein das glättet schon massiv.

Am Ende zählt ein ausgewogenes Regelverhalten, nicht wahr? die vielen Wege, die nach Rom führen.

Surfer1264(2nd)

ja cool, DANKEEE
@TL-F

anbei die passende Visualisierung, was war das Problem des "Schleichens?" zu viele Regelaktionen?

Surfer1264(2nd)

Den Code einmal um einen Tab einrücken und dann hier einfügen, ergibt folgendes Bild, ohne die Umbrüche (only your Code!!!)

sieht jetzt nach einer Automation aus...kein Template Sensor mehr..... Korrekt? Ja cool

trigger:
  - platform: state
	entity_id: sensor.stromleser_lk13be_power

sensor:
  - name: "P1-Sensor Virtuell"
	unique_id: p1_sensor_virtuell
	unit_of_measurement: "W"
	device_class: power
	state_class: measurement
	state: >
	  {# --- Sollwert --- #}
	  {% set soll = states('input_number.regler_sollwert_null') | float(0) %}

	  {% if trigger.from_state is none or trigger.to_state is none %}
		0
	  {% else %}

		{# --- Parameter --- #}
		{% set null_hyst = 15 %}   {# ±15 W Totzone #}
		{% set sprung = 20 %}      {# Sprungschwelle #}

		{# --- Werte --- #}
		{% set alt = this.state | float(0) %}
		{% set ist = trigger.to_state.state | float(0) %}
		{% set bestand = states('input_number.p1_bestand') | float(0) %}
		{% set neu = ist - soll %}
		{% set diff = neu - alt %}
		{% set diff2 = neu - bestand %}

		{# --- Logik --- #}
		{% if -null_hyst < neu < null_hyst %}
		  0
		{% elif diff | abs >= sprung %}
		  {{ neu | round(1) }}
		{% else %}
		  {% if diff2 | abs < sprung %}
			{{ bestand | round(1) }}
		  {% else %}
			{{ neu | round(1) }}
			actions:
			  - action: input_number.set_value
				target:
				  entity_id: input_number.p1_bestand
				data:
				  value: "{{ neu | float(2) }}"
		  {% endif %}
		{% endif %}
	  {% endif %}

TL-F

Surfer1264(2nd) Jupp.

Da ja immer der alte Wert genommen wurde, der nur minimal angehoben wurde, der dann aber im nächsten Schritt vom neuen Wert überschrieben wurde, waren die Sprünge so gut wie gleich, nur um ein Stepp verschoben.
Deshalb habe ich noch den einen Helfer eingefügt, um den Wert stabil zu halten, bis wirklicher ein Sprung um 30 Watt erfolgt.

Den Vorteil gegenüber der Automation von Henry ist für mich, dass diese Version einfacher zu lesen ist und so besser angepasst werden kann.

Aber wie Du schon in anderen Beiträgen geschrieben hast, haben wir hier keinen Wettkampf, sondern wollen unsere Erfahrungen und Anrgeungen teilen und jeder kann für scih rausziehen was er gebrauchen kann.

Vielen Dank hier noch einmal für Deine Mühe.

ZenUser486D4A5

Surfer1264(2nd) Mit dem neusten Update von HA funktioniert dieser viertuelle Sensor anscheind nicht mehr.

ZenUser5gWdF82

N'abend. Ich bin auf diesen Threat durch einen anderen gestoßen und würde meiner Z-HA gern einen geglätteten Leistungswert anbieten, der bei kleinen Änderungen stabil bleibt aber schnell springt wenn die Änderung groß genug ist. Ich habe deshalb einen Template-Sensor nach dem letzten Post von Surfer angelegt. Dabei sind mir ein paar Sachen aufgefallen:

Der YAML-Code kann keine Automation sein so wie hier steht. Das ist immer noch ein Template Sensor
P1_Bestand hatte ich als Helfer angelegt. Der Wert hat sich aber bei mir nie geändert. Ist ja auch klar, denn ein Template Sensor ist immer nur lesend und kann keinen anderen Wert beschreiben. Demnach müsste es doch als Automation angelegt werden.
Aaaaber: Man braucht doch P1 Bestand gar nicht, sondern nimmt als gespeicherten Wert einfach den Wert vom Template Sensor, oder? Ich habe das mal was angelegt, jetzt auch mit Kommentaren zur vereinfachten Lesbarkeit:

template:
    trigger:
      - platform: state
        entity_id: sensor.tm_smartmeter_sm_16_7_0
    
    sensor:
      - name: "Leistung für Zendure"
        unique_id: leistungfuerzendure
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement
        state: >
          {# --- Konfiguration --- #}
          {% set sollwert_null = 0 %}     {# Für eine Nullverschieben, um immer eher zu Beziehen und Einspeisen zu vermeiden #}
          {% set sprung_schwelle = 30 %}  {# Erst ab 30W Differenz wird angepasst #}
          {% set null_zone = 15 %}        {# Werte zwischen -15 und +15 werden zu 0 #}

          {# --- Werte ermitteln --- #}
          {% set aktueller_verbrauch = trigger.to_state.state | float(0) %}
          {% set alter_wert = this.state | float(0) %}
          
          {# --- Berechnung --- #}
          {% set ziel_neu = aktueller_verbrauch - sollwert_null %}
          
          {# Differenz zwischen dem neuen Ziel und dem, was wir aktuell senden #}
          {% set differenz = (ziel_neu - alter_wert) | abs %}

          {% if ziel_neu | abs < null_zone %}
            {# Fall 1: Wir sind nahe 0, also schalten wir auf 0 #}
            0
          {% elif differenz >= sprung_schwelle %}
            {# Fall 2: Die Änderung ist groß genug (Sprung), wir übernehmen den neuen Wert #}
            {{ ziel_neu | round(0) }}
          {% else %}
            {# Fall 3: Die Änderung ist zu klein, wir bleiben beim alten Wert #}
            {{ alter_wert | round(0) }}
          {% endif %}

Ich habe auch mal den sollwert_null Helfer rausgenommen. Ich bin Fan von static variablen. Das ist aber in Home Assistant unglücklich gelöst, denn das geht da nicht. Wer mag, kann es aber gern wieder reinpacken und diese Zeile verwenden:

{% set sollwert_null = states('input_number.regler_sollwert_null') | float(0) %}

Surfer1264(2nd)

ZenUser5gWdF82 Ich habe auch mal den sollwert_null Helfer rausgenommen. Ich bin Fan von static variablen. Das ist aber in Home Assistant unglücklich gelöst, denn das geht da nicht. Wer mag, kann es aber gern wieder reinpacken und diese Zeile verwenden:

Was meinst Du eigentlich damit,
Klar geht das …..
Die Idee ist den Sollwert von außen setzen zu können,
Im Sommer mit viel Überschuss ins Negative
Im Winter mit kaum Überschuss ins Positive.

Der virtuelle P1 wird so gegenüber dem echte. P1 verschoben um den Sollwert…..
In Verbindung mit der smarten ZHa Steuerung, die immer hart auf Null geht ist das ein sehr smarter Trick, der auf den Autoren dieses Post zurückgeht.

Ich nutze den Sensor selbst nicht, habe aber in meiner NodeRed Regelung genau dieses Modell vor einem Jahr auch schon etabliert……”gleitender Sollwert”, der beeinflusst durch diverse Parameter ( wie Wetter, Akkustand….) sich selbst verschiebt.

Surfer1264(2nd)

hey Danke 🙏

Im Prinzip bist du wieder beim Ausgangspunkt des Posts gelandet ! Man kommt halt immer wieder zu ähnlichen Lösungen 😎👌

Ich bin hier bei diesem Stand hängen geblieben, ein klassischer Template Sensor, mit der Möglichkeit der Sollwert Verschiebung, den Sensor nutze ich selber aber gar nicht, läuft nur mit im HA…..Ich bin Jäger und Sammler, bereite auf, professionalisiere, dokumentiere und teile Wissen im GitHub als Vorlage und ausführlichst dokumentiert, sogar grafisch.

https://github.com/surfer1264/Zendure-Stuff/wiki/Virtueller-P1%E2%80%90Sensor

Allerdings schleicht dieser Template Sensor bei kleinen Änderungen außerhalb der Hysterese …..langsam dem Istwert hinterher ( gedacht für die Nacht, mit wenig Änderungen…..da soll er nicht ewig ….30 W neben der Spur liegen, aber auch nicht jeder Änderung in Gänze hinterher hüpfen.)

Die Frage ist …was man will
A) Genauigkeit
B) wenig Regelaktionen
Es geht immer nur ein Kompromiss

Mit Automatisierungen selbst habe ich gar nichts am Hut….mir zu kompliziert und unübersichtlich am Ende ……bin gleich in die NodeRed Welt und Java Script eingestiegen.

Beste Grüße

ZenUser5gWdF82

Wenn ich persönlich im Idle-Mode bin rattert mein Gehirn an irgendwelchen technischen Größen. Als ich gestern lang im Auto unterwegs war ging mir die Sache mit dem Template Sensor durch den Kopf😉 Auf Home Assistant bin ich jetzt schon seit einem Jahr unterwegs aber war davor habe ich bestimmt schon 12 Jahre auf FHEM genutzt.

Aus regelungstechnischer Sicht ist dein Template Sensor Premium👌Der verhält sich ähnlich wie ein PI Regler. Also schneller Sprung auf neuen Zielwert aber langsamer Angleich an den Zielwert. Finde ich persönlich auch am besten und behalte ich mir mal im Hinterkopf.

Mein aktueller Usecase ist vor allem, das System zu beruhigen so dass nicht alle fünf Sekunden ein neues Limit im SF geschrieben und dass aber schnell reagiert wird, wenn die Leistung stark springt. 5s sind lang. Im Worstcase liegt man dann 5s daneben und speist die gute Batterieenergie ins Netz oder bezieht unnötig. Ich werde aber mal beobachten und ggf. dann doch auf deinen Template Sensor umschalten.

Surfer1264(2nd)

ZenUser5gWdF82 5s sind lang. Im Worstcase liegt man dann 5s daneben und speist die gute Batterieenergie ins Netz oder bezieht unnötig

800 W 5 sec sind 1,11 Wh also auch kein Drama.

Ich arbeite auch mit dem 5 Sek Takt. Auch das führt zu einer Glättung. Schneller istvdie gesamte Regelstrecke eh kaum ( also meine auf keinen Fall)

ZenUser5gWdF82

Ja stimmt. Genauso wenn man über längere Zeit ein paar Watt daneben liegt. Irgendwie hat man den Drang, ne schön flache Linie nahe der Null zu sehen. Aber vielleicht ist das auch vergebene Mühe bei den paar Cent, die man dabei spart. Letztenlich fließt ja die meiste Energie aus dem Speicher in die richtige Richtung, um den Großteil der Grundlast zu decken oder zu Unterstützen wenn z.B. mal die Waschmaschine läuft.

Henry

[unknown]Du kannst dir, wenn du Lust hast, auch mal meinen originalen virtuellen P1 Sensor, auf dem der Thread basiert, anschauen. Der ist inzwischen noch durch zusätzliche Features ergänzt worden. Aktuell (Winterbetrieb) hab ich noch einen Schwellwert eingebaut, unter dem der SF2400 nicht entläd, um ihn ausschließlich in einem Bereich optimalen Wirkungsgrades arbeiten zu lassen. Ausserdem wird der minSoC automatisch auf 50% erhöht, wenn die Geräte im Standby sind, um die Standbyeinspeisung abzuwürgen; wird Leistung über Schwellwert angefordert setzt er min SoC vorübergehend auf 10%. alias: Zendure P1 Virtual stabil (Target+Deadband+Hold) v1.2.0 description: > Virtueller P1 für Z-HA: virt = real - target. Target/Deadband per Helper. Im Deadband -> 0W. Hold per Change-Threshold. Winterbetrieb (nur Entladen): bedient nur 400..1700W (clamp), darunter stoppt Entladung (outputlimits=0). triggers: - entity_id: sensor.shellypro3em_total_active_power trigger: state - entity_id: input_boolean.input_boolean_zendure_use_custom_setpoint trigger: state - entity_id: input_boolean.zendure_winterbetrieb trigger: state conditions: [] actions: - variables: REAL: "{{ states('sensor.shellypro3em_total_active_power') | float(0) }}" TARGET_W: "{{ states('input_number.p1_sensor_target') | float(0) }}" DEADBAND_W: "{{ states('input_number.p1_sensor_deathband') | float(0) }}" CHANGE_TH_W: "{{ states('input_number.zendure_change_threshold_w') | float(80) }}" ENABLED: >- {{ is_state('input_boolean.input_boolean_zendure_use_custom_setpoint', 'on') }} WINTER: "{{ is_state('input_boolean.zendure_winterbetrieb', 'on') }}" LAST: "{{ states('input_number.zendure_p1_last_setpoint') | float(0) }}" VIRT_RAW: "{{ (REAL - TARGET_W) | float(0) }}" IS_DISCHARGE_REQ: "{{ VIRT_RAW > 0 }}" IN_DB: "{{ (VIRT_RAW | abs) 1700 %} 1700 {% else %} {{ VIRT_RAW }} {% endif %} {% endif %} IN_DB2: "{{ (VIRT_WINTER_CLAMPED | abs)

ZenUser5gWdF82

Surfer1264(2nd) Was meinst Du eigentlich damit,
Klar geht das …..
Die Idee ist den Sollwert von außen setzen zu können,
Im Sommer mit viel Überschuss ins Negative
Im Winter mit kaum Überschuss ins Positive.

Das mit static war auf den Helfer P1_Bestand bezogen. In HA ist es nicht möglich, funktionseigene Variablen zu definieren, die nach dem Ausführen auch noch erhalten bleiben (also das was eine static Variable in C macht). Da muss man einen Helfer anlegen, der dann wie eine globale Variable ist. Ist sehr unschön, denn so kann ich von außerhalb Werte ändern, die eigentlich nur von der Funktion selbst geändert werden sollten. Bei Sollwert_null macht das aber absolut Sinn. Das ist ja sozusagen ein Steuerparameter von außerhalb.

Generell mag ich HA und habe auch schon viel Automationen am Laufen. Aber was ich nicht so toll finde ist der YAML Kram zusammen mit Jinja. YAML ist schon unglücklich. Normalerweise sollte es dem Parser egal sein, wieviel Leerzeichen irgendwo drinstehen. Das gab es mal ganz früher in den 70ern. Aber bei Java, HTML, JSON oder was auch immer ist es total egal wie was eingerückt ist, nur nicht bei YAML. Jinja dazu macht es auch nicht besser mit den ganzen geschweiften Klammern am Beginn und Ende jeder Zeile... Puh, aber genug offtopic gelästern.

« Previous Page Next Page »