Home Assistant Bastelbude - Heute: virtueller P1 Sensor

Henry

Hallo zusammen,

Hier mal wieder ein kurzer Beitrag aus meinem Home Assistant Gefrickel.

Ausgangspunkt: 2xSF2400, Steuerung über Zendure Manager aus der Z-HA Integration im Home Assistant

Problem: Mir gefällt die Z-HA Steuerung nicht 100%ig, da sie jede kleine Schwankung am P1 Sensor (bei mir Shelly) sofort regelt. Ist mE nach nicht nötig und belastet die Technik.

Ich habe in der Vergangenheit schon mit eigenen Steuerung experimentiert und bin dabei bei einer eventbasierten Steuerung hängen geblieben, die für mich auch hervorragend funktioniert hat. Ich hatte das Thema zugunsten der Z-HA Steuerung aber wieder verworfen, da ich die sinnvolle Aufteilung auf 2xSF2400 nicht hinbekommen hatte.
Da mir, wie gesagt, die Z-HA Steuerung nicht so ganz gefallen hat, war die Idee die Z-HA Steuerung durch meine eigene auszutauschen, dabei aber die Systematik der Aufteilung auf die Speicher von Z-HA beizubehalten.
Also habe ich im Quellcode der Z-HA Integration rumgepopelt, mit dem Ergebnis, dass die Z-HA Integration natürlich nicht mehr funktioniert hat…😅
Da ich das zum einen nicht in den Griff bekommen habe und ich zum anderen wusste, dass beim nächsten Z-HA Update meine Änderungen sowieso überschrieben werden würden, musste eine andere Lösung her, die den Quellcode von Z-HA so lässt wie er ist.
Ich habe lange überlegt, bis mir eingefallen ist, was wäre eigentlich, wenn ich den P1 Sensor so manipuliere, dass ich Z-HA etwas anderes vorgaukel und so mein Ziel erreiche?
Also hab ich ChatGPT meine alte eventbasierte Steuerung an die Hand gegeben, und ihn daraus einen virtuellen P1 Sensor erstellen lassen. Diesen habe ich dann in der Z-HA Integration als P1 Sensor hinterlegt und was soll ich sagen, es funktioniert sogar…🤗

Was macht meine Steuerung nun anders, als die Z-HA Steuerung?
Z-HA regelt im Prinzip jede Änderung am P1 Sensor auf 0.
Meine Steuerung definiert ein Ziel (bei mir 10W Einspeisung) und legt eine Deathzone um das Ziel (bei mir +-30W). Ausserdem definiere ich Events, nur wenn diese auslösen, wird geregelt. Die Events sind definiert als Differenz Aktueller Shelly Wert - Shelly Wert vom letzten Event, bzw das Verlassen der Deathzone. Erst wenn dieser Fehler größer 30W ist, oder die Desthzone verlassen wird, wird ein Event und damit eine Regelung ausgelöst. Das heißt im Umkehrschluss, solange der Shelly Wert in der Deathzone ist und der Fehler

Surfer1264(2nd)

Henry Z-HA regelt im Prinzip jede Änderung am P1 Sensor auf 0.
Meine Steuerung definiert ein Ziel (bei mir 10W Einspeisung) und legt eine Deathzone um das Ziel (bei mir +-30W). Ausserdem definiere ich Events, nur wenn diese auslösen, wird geregelt. Die Events sind definiert als Differenz Aktueller Shelly Wert - Shelly Wert vom letzten Event, bzw das Verlassen der Deathzone. Erst wenn dieser Fehler größer 30W ist, oder die Desthzone verlassen wird, wird ein Event und damit eine Regelung ausgelöst. Das heißt im Umkehrschluss, solange der Shelly Wert in der Deathzone ist und der Fehler

Willkommen in der ReglerCommunity …sehr stark

Das ist klassische Regelungstechnik,
Sollwert als Parameter
Hysterese als Parameter ( du nennst es Deatzone)
Und der Istwert der Regelstrecke, als Differenz zum letzten Wert…und wenn Diff Null tue nix.

Das ist genau das was ich seit Tag 1 noch vor ZHA gebaut habe.
Dabei sind alle Parameter externalisiert und sowohl über ein Dashboard als auch über andere Automatisierungen erreichbar.

Ontop
Parameter Einspeisbegrenzung ( als Min und als Maxwer)

Und all diese Regelparameter ( Sollwert, Hysterese, Entladegrenze, Eisnpeisebegrenzung) werden von außen durch
pv Forecast und Akkufüllstand ontop noch dynamisch beeinflusst für ein optimales Systemverhalten unter diversen Bedingungen

Genau deshalb benutze ich die Smarte Regelung von ZHA gar nicht, sondern bespiele mit meinem Regelsystem, den manuellen Eingang von ZHa.

ZHA erfüllt für mich nur die Funktion des Monitors, Datenlieferanten und Datenübermittlers, aber nicht als Regelmaschine.

Alles hier hinterlegt und im Detail beschrieben.

https://github.com/surfer1264/Zendure-Stuff/wiki/Regeln-mit-HomeAssistent

TL-F

Henry Hallo Henry, ich finde Deinen Ansatz gut, da er auch unabhängig davon ist, wieviele Geräte man im Einsatz hat. Bei der Variante von Surfer1264, die ich sehr interresant finde, sieht es so aus, als wenn es nur einen Wechselrichter gibt.

Könntest du uns Deine Lösung mal zur Verfügung stellen?

Surfer1264(2nd)

Henry kleine Schwankung am P1 Sensor (bei mir Shelly) sofort regelt. Ist mE nach nicht nötig und belastet die Technik.

Ist das so ?
Die technik ist dafür gebaut, genau dafür.

Aber der Ansatz trotzdem interessant.
Ich fasse das mal in meine Worte.

Du filterst jede Schwankung aus dem eigentlichen P1-Signal raus
Änderungen kleiner 30W werden ignoriert und nicht durchgereicht , oder anders gesagt nur ÄNderungen von größer 30W werden ausgeregelt.
im Bereich von -40 bis +20 findet auch keine Regelaktion statt, also Schwankungen von 60W am echten P1 werden auch weg ignoriert.

Wie gesagt ….interessanter Ansatz, dass über einen abgeleiteten P1 -Sensor zu realisieren.

Zusammengefasst:
Still ruht der See im Bereich -40…+20 und dann gestuft in 30W nach oben oder unten

Gefällt mir irgendwie
(Leider finde ich das Yaml-Geraffel so furchtbar grins )

Surfer1264(2nd)

TL-F sieht es so aus, als wenn es nur einen Wechselrichter gibt.

Korrekt, das ist aber ganz easy aufteilbar.

Ein Regelsignal aufteilbar auf so viele Ausgänge wie man brauchst. Ob ich einen WR ansteuere oder zwei oder drei ….egal

Und vermutlich wäre es sogar so….. wenn ich zwei Hubs in ZHa hätte ……würde das Regelsignal,dass ich ZHa für meinen Hub zur Verfügung stelle sogar von ZHA aufgeteilt werden, wenn beide Hubs zu einer Sicherungsgruppe gehören.

Also NOPE …….
Das Ansprechen von mehreren Geräten ist das kleinste (oder gar kein?) Problem.

Henry

Klar, ich bin nur überhaupt nicht fit mit Github…😅
Hier mal als Notlösung der yaml code (neue Automation > einfügen > speichern).

alias: Zendure Custom P1 (eventbasiert, deadband, ohne Integrator)
mode: restart
trigger:

platform: state
entity_id: sensor.shellypro3em_total_active_power

condition:

condition: state
entity_id: input_boolean.input_boolean_zendure_use_custom_setpoint
state: "on"

action:

variables:
TARGET_W: -10 # gewünschte Einspeisung: -10 W
DEADBAND_W: 30
CHG_TH: "{{ states('input_number.zendure_change_threshold_w') | float(80) }}"

real: "{{ states('sensor.shellypro3em_total_active_power') | float(0) }}"
last_real: "{{ states('input_number.zendure_p1_last_real') | float(real) }}"
d_real: "{{ (real - last_real) | float(0) }}"

u_last: "{{ states('input_number.zendure_p1_last_setpoint') | float(0) }}"
err: "{{ real - TARGET_W }}"
in_db: "{{ (err | abs) = CHG_TH or (not in_db) }}"
choose:
- conditions:
  - condition: template
    value_template: "{{ not is_event }}"
    sequence:
    - action: input_number.set_value
      target:
      entity_id: input_number.zendure_idle_ticks
      data:
      value: "{{ states('input_number.zendure_idle_ticks') | int(0) + 1 }}"
    - stop: "HOLD: kein relevantes Event"
variables:

Deadband-bereinigter Fehler als "virtueller P1"

u_new: >-
{% if in_db %}
{{ u_last | round(0) }}
{% else %}
{% set s = 1 if err > 0 else -1 %}
{{ (s * ((err | abs) - DEADBAND_W)) | round(0) }}
{% endif %}
choose:
- conditions:
  - condition: template
    value_template: "{{ (u_new | int(0)) != (u_last | int(0)) }}"
    sequence:
    - action: input_number.set_value
      target:
      entity_id: input_number.zendure_p1_last_setpoint
      data:
      value: "{{ u_new | int(0) }}"
action: input_number.set_value
target:
entity_id: input_number.zendure_p1_last_real
data:
value: "{{ real | round(1) }}"
action: input_number.set_value
target:
entity_id: input_number.zendure_idle_ticks
data:
value: 0

Ob das mit dem Einfügen funktioniert, weiß ich nicht. Yaml ist empfindlich, wenns um Formatierung geht…😅
Der input.bolean als trigger ist nicht notwendig, hab ich den bloß drin, damit ich das ganze per Schalter an und aus machen kann.
Ansonsten muss man noch 3-4 Helfer anlegen, damit das funktioniert. Wer den code lesen kann, weiß was zu tun ist…😉

andi2802

Hallo Henry und Surfer.......ich habe mich, u.a. durch Euch insperieren lassen und mit HA in den letzten 6 Wochen als Super-Anfänger irgendwie durchgebissen und einige Lernkurven dann positiv durchlaufen.....bin jedoch gerade etwas verunsichert durch den jetzigen Post...ich mag Regelungstechnik nicht besonders....

Mein Setup in Summe, eine 9KWp-Anlage in 3 Himmelsrichtungen verteilt mit 4 Balkonkraftwerken auf Garage und am Zaun in Richtung Süd und einer etwas größeren OST/West Dachanlage im String.

In der nächsten Stufe wollte ich jetzt eigentlich meine beiden Systeme SF2400 Systeme mit je 2 Akku-Packs AB3000x lokal über Z-HA einbinden und mit der smarten Leistungsregelung betreiben, allerdings ohne weiteren Schnörkel.
Meine aktuelle Zielstellung war: Mehr Effizenz und nicht rd 400-600Wh täglich ins Netz schieben und zweitens eine schnellere Leistungsangleichung. Ist eine zusätzliche Regelung (zur Schonung der Technik, schätze ihr meint das Umschaltrelais) aus Eurer Sicht unabdingbar ? Bei meiner PV-Analge gibts meistens nur 2 Zustände, entweder es brummt oder oder es kommt nichts, lediglich in den Morgenstunden, Abendstunden und ggf. Lastwechsel durch Sonne Wolken-Mix und oder den unkoordinierten Stromverbrauch meiner Frau sind Lastwechsel von Laden zum Entladen vorprogrammiert. Sicher macht das Sinn was ich da bei Euch lese, allerdings ist das wieder eine nächste Hürde sich mit Regelungstechnik in HA zu beschäftigen um eine Sicherheitszone von -20 W bis 20W einzurichten. Da habe ich nicht wirklich viel verstanden von dem was ihr hier aktuell redet :-) Ich finde die ganzen Anregungen und Anleitungen von Dir Surfer wirklich Super, aber erkläre mal ein Schachspieler das er morgen Leistungsturner werden soll.....das brauch seine Zeit...

Surfer1264(2nd)

andi2802 Ist eine zusätzliche Regelung (zur Schonung der Technik, schätze ihr meint das Umschaltrelais) aus Eurer Sicht unabdingbar ?

Bist du zufrieden oder nicht.

Wenn ja: dont touch this !!!!
Wenn nein: was ist das Problem…..und dafür gibts dann Lösungen…… HA ist eine .

So lass dich also von uns nicht irgendwo reinziehen ….wo du nicht sein willst.

Ich komme aus der SF1200 Welt…….
Schlechte Regelung von Zendure, man verschenkt immer Energie
Unzuverlässige Services von Zendure. Geht eben auch mal nicht …und keiner merkst
Schlechtes Akku BMS
Unzuverlässige Statistik, Lücken, oder gar nicht…..
Zendure App ….naja benutzerfreundlich ist anders.
Kein einfaches Bedieninterface
Usw. Usf.

Also mal eben selber gemacht.
Und jetzt wird der Hub täglich vom PV Forecast gesteuert (ich glaube um Längen besser als ZENKI) Zendure App deinstalliert, brauch ich nicht mehr. Konfiguriert und steuert sich selbst als Vollautomat… und brauche keine Angst haben dass der Akku morgen stirbt.

Was ich hier anbiete sind Impulse. Niemand muss das nachmachen oder sollte sich verführen lassen.

TL-F

andi2802 Hallo Andi2802, wie Surfer1264 richtig schreibt, kannst du mit HA soweit eintauchen wie Du für Dich richtig findest. Ich bin auch erst seit 4 Monaten dabei und merke, wie sich meine Grenze, was HA angeht, sich immer weiter verschiebt.

Ich habe, wie Du schon bemerkt hast auch nicht nur ein Gerät am Start und alles läuft derzeit über die Z-HA Integration im Smartmodus. Wenn Solarcast mir sagt, dass die Prognose für den Tag nicht mal meine Grundlast (Hausbedarf) deckt, dann schaltet ich in der Z-HA auf manuelle Steuerung mit fester Wattzahl um und decke nur den Hausbedarf.
Hintergrund ist, dass im Smartmodus so bis zu ein 500 W eingespeist wird. Das kann man nicht verhindern, weil die Anlage ja zwischen den verschiedenen Strombedarfen (Kaffeemaschine 1400 W für 10 sec. und dann wieder weg usw.) schalten (Reaktionszeit) muss.

Deshalb finde ich den Ansatz von Henry gut, bevor ich mich an die Variante von Surfer1264 wage.

Also alles ist machbar, aber man muss nicht alles machen. HA ist jedenfalls in der Standardversion 100-mal besser als die Zendure-App mit der Cloud.

Henry

Also was ich hier an Projekten poste, ist für einen normalen Betrieb nicht notwendig. Ich versuche (einfach weils mir Spaß macht) wirklich die letzten Prozentpunkte noch rauszukitzeln und zu optimieren.
Du kannst aber ganz beruhigt und sorglos die Z-HA Integration für dein Setup nutzen. Die ist wirklich super, auch ohne „customizing“…

Surfer1264(2nd)

TL-F seit 4 Monaten dabei und merke, wie sich meine Grenze, was HA angeht, sich immer weiter verschiebt.

Jetzt geht’s ab 😎
War bei mir exakt nach 4 Monaten so.

TL-F

Hallo Henry,

wie ich bereits geschrieben habe, finde ich Deinen Ansatz toll, aber leider steige ich so ganz bei Deiner Formel nicht durch. Ich muss wohl mich einfach noch ein wenig damit beschäftigen.

Ich habe versucht das gleiche über einen anderen Weg zu erreichen, kann es leider aber im Moment nicht ausgiebig testen, da einfach zu wenig Sonne für die Smarte Regelung vorhanden ist. Bei einem kurzen Test scheint es geklappt zu haben. Vielleicht kannst Du es ja mal bei Dir testen und mir ein Feedback geben.

Einfach in die Config einfügen:

template:

trigger:
- platform: state
  entity_id:
  - sensor.shellypro3em_xxxxxxxxxxxxxx_total_active_power
  sensor:
  - name: P1-Sensor Virtuell
    state: |
    {% set alt = trigger.from_state.state | float(0) %}
    {% set neu = trigger.to_state.state | float(0) %}
    {% set Differenz = neu - alt | float(0) %}
    {{ iif( neu > -10 and neu < 10, 0 , iif(Differenz < -30 or Differenz > 30, neu, 0))}}
    unit_of_measurement: "W"
    device_class: energy
    state_class: total
    unique_id: ac345373-0dc0-4801-864b-e2b44061e9e4

Vielen Dank

Surfer1264(2nd)

TL-F Einfach in die Config einfügen:

Sollte funktionieren, mit ein paar Anpassungen
A)
device_class: power
state_class: measurement

B)
{% set Differenz = neu - alt | float(0) %}
wird interpretiert als
neu - (alt | float(0))
fehleranfällig

C)
iif() verschachtelt → schwer lesbar und Magic numbers 10, 30, -30

D)
trigger.from_state == None wird nicht abgefangen....das kracht

Versuch mal das hier:

template:
  - trigger:
	  - platform: state
		entity_id: sensor.shellypro3em_xxxxxxxxxxxxxx_total_active_power

	sensor:
	  - name: "P1-Sensor Virtuell"
		unique_id: ac345373-0dc0-4801-864b-e2b44061e9e4
		unit_of_measurement: "W"
		device_class: power
		state_class: measurement

		state: >
		  {# --- Schutz bei Neustart --- #}
		  {% if trigger.from_state is none or trigger.to_state is none %}
			0
		  {% else %}

			{# --- Parameter --- #}
			{% set nullbereich = 10 %}
			{% set sprungschwelle = 30 %}

			{# --- Werte --- #}
			{% set alt = trigger.from_state.state | float(0) %}
			{% set neu = trigger.to_state.state | float(0) %}
			{% set differenz = neu - alt %}

			{# --- Logik --- #}
			{% if -nullbereich < neu < nullbereich %}
			  0
			{% elif differenz | abs > sprungschwelle %}
			  {{ neu }}
			{% else %}
			  0
			{% endif %}

		  {% endif %}

Henry

Das was ich hier rein gestellt hatte, ist ein fertiger Yaml Code für eine HA Automation. Du musst in HA eine neue Automation erstellen > in Yaml bearbeiten > den code rein kopieren > speichern.
Dann mal durch den Code schauen und alles was „input_number“ Entitäten sind mal rausschreiben, bei dir Helfer anlegen und die genauso benennen. Achtung: beim anlegen der Helfer darauf achten, dass die auch negative Werte annehmen können, am besten gleich +-10.000 anlegen.
Einer davon heißt sensor.p1_sensor_eventgesteuert, den hinterlegst du dann bei der Z-HA Integration.

Surfer1264(2nd)

Man könnte noch ergänzen

Nur reagieren, wenn der Wert z. B. 3 s stabil ist als zeitbasierte Entprellung:

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

👉 Dein virtueller Sensor:

ignoriert:

kleine Schwankungen
Rauschen
minimale Änderungen
reagiert nur auf:
echte Leistungssprünge

unterdrückt:

Werte nahe 0 W

📈 Ergebnis: geglätteter Leistungssensor

In Summe sehr schlanke Variante ohne viel DrumRum

TL-F

Vielen Dank.

Für Deine Überarbeitung. Ich hatte gestern versucht es ähnlich aufzubauen, habe aber immer einen Fehler in der Log-Datei gehabt. Deshalb hatte ich es verschachtelt, weil so hat er es genommen.

Ich habe Deine Anregungen übernommen und es funktioniert.

Surfer1264(2nd)

Ich habe den Sensor mal getestet

Original-Sensor
Virtueller Sensor

man sieht schön die Glättung !!!! und er läuft nur mit wenn der Original Sensor sich um mehr als 30W ändert.
und schnelle Änderungen (klein / Groß) innerhalb von 3 Sekunden werden ignoriert

Es steckte allerdings noch ein Fehler in Deinem Sensor @TL-F

Der virtuelle Sensor ging IMMER auf NULL, wenn die DIFF zw. ALT und NEU <30W war.......und das ist nicht im Sinne des Erfinders, Der virtuelle Sensor muss dann den "aktuellen" Wert des Sensors beibehalten (und nicht auf NULL gehen.)

Hier der komplette neue, richtige Sensor, der braucht keine Helfer, Variablen etc. funktioniert "AS IS"
anpassbar
die zeitliche Entkopplung (3sec)
die Hysterese um den Nullbereich (10)
die Sprung-/Reaktionsschwelle (30)

- 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: >
		{% if trigger.from_state is none or trigger.to_state is none %}
		  0
		{% else %}
		  {% set nullbereich = 10 %}
		  {% set sprungschwelle = 30 %}

		  {% set alt = trigger.from_state.state | float(0) %}
		  {% set neu = trigger.to_state.state | float(0) %}
		  {% set diff = neu - alt %}
		  {% set aktuell = this.state | float(0) %}

		  {# --- Logik --- #}
		  {% if -nullbereich < neu < nullbereich %}
			0
		  {% elif diff | abs > sprungschwelle %}
			{{ neu }}
		  {% else %}
			{{ aktuell }}
		  {% endif %}
		{% endif %}

Surfer1264(2nd)

Ziemlich schlanke und einfache Lösung für die HA-Enthusiasten
Bringt Ruhe in die Regelung

Surfer1264(2nd)

Heue morgen nochmal reingeschaut, der virtuelle Sensor läuft gut mit
@TL-F @Henry

hier mit 2 Sekunden Entprellung

Wirklich easy, wer seinen P1-Sensor etwas beruhigen will...
kleiner Nachteil.....das läuft alles durch die HA-Integrationsschichten mehrfach...
Für Z-HA als Input aber nicht anders machbar, wenn man die P1-Sensormimik nutzt

Ich lese den Shelly per HTTP-Request direkt aus, das ist defacto Echtzeit....und übergebe den Wert an Z-HA zur Hubsteuerung

Surfer1264(2nd)

anbei der virtuelle Sensor mit ganz zarter Glättungsfunktion wenn die Änderung (Diff) kleiner 30W ist.
Der virtuelle Sensor schleicht sich langsam an den IST-Wert ran.
Wie man an obiger Kurve sieht, bleibt der virtuelle Sensor lange über dem IST-Wert. Mit Glättung läuft er ganz langsam hinterher.

- 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: >
		{% 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 neu = trigger.to_state.state | float(0) %}
		  {% 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 %}