Du kannst sonst das Debug Log auch in eine Datei schreiben lassen. Aktiviere das einfach rechtzeitig und hol dir dann irgendwann die Datei raus. Die wird nur wahrscheinlich recht groß 
Wie schon geschrieben, der Fehler ist die Einheit der Leistung. Daher ging es schief. Es fehlen meiner Meinung nach ein paar Infos im Dialog. Unter anderem an dieser Variablen steht nicht dran welche Einheit sie haben soll.
Der Strom wird korrekt gesetzt. Nur wird die Phase nicht umgestellt. Hat er einmal einphasig begonnen springt er nicht von selbst zur dritten Phase.
Hab jetzt ein Log erzeugt.
debug_19164.txt (666,1 KB)
Gegen 19:30 Uhr war die PV-Leistung so gering, dass eigentlich die Ladeleistung gegen 9 gehen müsste. Sie bleibt aber irgendwann bei 38% stehen.
Gegen 19:42 Uhr ist die PV-Leistung 0W und die Einspeiseleistung beginnt. Da jedoch die Ladeleistung noch auf 28% steht, geht der Energiespeicher in den Modus „aktiv“ und speist dann nicht mehr ein. Kurz darauf habe ich ihn wieder auf „automatisch“ gestellt, dann ging es ein paar Minuten auch, obwohl die Ladeleistung immernoch auf 38% stand.
19:48 Uhr wieder „aktiv“ (oder „inaktiv“?) und Ladeleistung stand weiterhin auf 38%.
19:52 Uhr habe ich die Ladeleistung manuell auf 0% gestellt und den Energiespeicher auf „automatisch“. Dann lief es…
Das ist genau der Zustand am Abend, der problematisch ist. Ich hoffe, @Dr.Niels du kannst mit dem Log und der Beschreibung nachvollziehen, was ich meine?
Okay, ich habs entdeckt. Prinzipiell meldet der Energiespeicher recht durchgehend einen Verbrauch von 0, egal was bei der Ladeleistung anliegt. Da auch keine Energie im Haushalt fehlt, die negativen Werte bleiben in der Hysterese von 19:30 bis 19:34, wird auch nichts umgeschaltet. Es ist ja genügend Energie da. Eher wird bei verfügbarer Energie die Ladeleistung mal erhöht, was aber keinen realen Effekt hat. Der gemessene Verbrauch bleibt bei 0. Der Speicher nimmt die Energie also nicht an.
Um 19:34 kommt dann ein Sprung nach unten, es fehlen 959 Watt. Auch wenn der Energiespeicher keinen Verbrauch meldet (gemessener Verbrauch weiterhin 0 Watt), wird der Sollwert auf 0 geschaltet. Das klappt aber leider nicht, der Speicher bleibt bei einem Sollwert zum Laden von 640 Watt.
Die Frage ist also, warum lässt sich der Energiespeicher hier nicht abschalten? Klappt es per Visualisierung, dass du einfach nur den Sollwert runterschalten kannst und dieser dann auf 0 geht? Oder musst du einen separaten Schalter nutzen oder dergleichen, den der Energie Manager nicht kennt?
Der Speicher war zu der Zeit voll, deshalb war trotz 100% Ladeleistung keine Energieaufnahme. Aber wie gesagt, irgendwann war die Energie PV weniger und der Speicher hätte entladen müssen. Das hat er auch getan, aber durch die fest stehende Ladeleistung hat es dann den Lade-/Entladeregler fest gemacht.
Meine Schaltung ist ja so, dass der Energiemanager jeweils eine Integer-Variable für die Ladeleistung und Entladeleistung in % schaltet. Diese beiden Variablen setzen per Aktionsskript eine Variable des Victron Lade-/Entladereglers (Modbus). Im Normalmodus funktioniert das auch.
Die Frage ist, warum die Variable Ladeleistung vom Energiemanager nicht herunter geregelt wird? Heute Nacht gab es dann noch den Fall, dass durch einen größeren Verbraucher neben einer erhöhten Entladeleistung plötzlich auch die Ladeleistung auf einen Wert angesprungen und stetig geblieben ist. Damit kam es dann wieder in den instabilen Zustand und der Energiemanager hat auf „aktiv“ geschalten. Eine Entladung kam dann aber auch wieder nicht zustande.
Ich sehe hier zweierlei Themen, die noch angegangen werden müssten:
- Zum einen hat wie gesagt deine Ladevariable sich nicht runterregeln lassen. Vielleicht solltest du also nochmal dein Aktionsskript prüfen, ob der Wert immer durchgeht, oder ob es hier ungewünschte Konstellationen gibt, in denen das nicht passiert
- Auf der anderen Seite muss ich nochmal bei der Entladung ran. Diese passiert aktuell nicht, falls die Ladevariable noch gesetzt ist. Das passe ich aber noch an.
Das Aktionsskript setzt die durch den EM gesetzte Variable auf den Victron (Modbus) um:
<?php
SetValue($_IPS['VARIABLE'], $_IPS['VALUE']);
//Faktor ist die Umrechnung von 100% auf die Ladeleistung (100%*20=2000W) + 0.55W (USV-Verbraucher)
$Faktor=GetValueFloat(35552) + 55;
<?php
//Freigabe ist eine Variable, ob überhaupt geladen werden darf
$Freigabe=GetValueBoolean(13957);
$Victron=$Faktor/100 * $_IPS['VALUE'] * $Freigabe;
SetValueFloat(41792, $Victron);
RequestAction(37546, $Victron);
Durch die Variable Freigabe kommt es vor, dass die Ladevariable durchaus 100% vorgibt, aber in der Mulitplikation mit 0 trotzdem nicht geladen wird. Ich denke aber nicht, dass es an der Stelle problematisch ist. Die Modbus-Variable im Victron ist auf alle Fälle 0, es wird tatsächlich nicht geladen.
In meinem Fall passiert die Entladung eine kurze Zeit schon trotz gesetzter Ladevariable. Aber eben nicht sehr lange, bis „das Gerät reagiert nicht“ kommt und der Energiemanager den Speicher von „automatisch“ auf „aktiv“ stellt. Dieses Verhalten kann ich irgendwie nicht nachvollziehen.
Beim Aktionsskript ist ja aber die Frage, warum die Schaltvariable selbst nicht auf 0 geht. Und mit dem SetValue in der ersten Zeile sollte der Schaltwert ja immer durchgereicht werden, egal was du dann an Logik mit dem Wert weiter machst… Schaltet noch irgend etwas anderes die Variable und setzt es vielleicht zurück?
Die erste Zeile ist erstmal dazu da, dass es eine anpassbare Variable ist. Und der Wert wird durch den Energiemanager vorgegeben. Oder ich setze ihn manuell, was ich z.B. im Fehlerfall mache. Eine andere Beeinflussung außer durch den EM gibt es nicht.
Darf man das so machen, einen Float mit einem Boolean multiplizieren?
Laut Log wird diese Variable halt immer wieder auf 0 geschaltet. Aber beim nächsten Durchlauf ist sie nicht mehr (oder war nie) auf 0. Damit ist halt die Frage, was da los ist. Und vom aktuellen Eindruck her, scheint es halt als wenn dein System da irgendwas komisches macht. Denn aktuell fällt mir kein Szenario ein, in dem der Energie Manager mit diesem Log die Variable nicht auf 0 schaltet. Magst du vielleicht ein IPS_LogMessage im Aktionsskript einbauen? Dann könnte man vielleicht besser debuggen, was da wirklich passiert.
PS: Ich vermute das doppelte <?php in deinem Aktionsskript ist einfach ein Fehler beim Copy & Paste und nicht Teil des tatsächlichen Skriptes? Denn in der aktuellen Form wäre das Skript ungültige Syntax. Aber dann würde die Variable nie schalten.
Wie und wo soll ich das im Skript einbauen?
Das doppelte <?php ist wirklich nur durch das Kopieren hier in den Thread passiert.
Hallo,
ich habe 3 Marstek PV Speicher angebunden. 2 Speicher werden jede Nacht relativ gleichmäßig entladen. Der dritte jedoch wird erst genutzt, wenn die anderen beiden leer sind. Dies hat den Nachteil, dass dieser länger auf 100% bleibt und die anderen beiden schneller die untere Ladegrenze erreicht haben. Ein gleichmäßiges Entladen würde aus meiner Sicht die Lebensdauer der Batterien verlängern. Kann ich das irgendwo einstellen?
Ich hatte den dritten Speicher schon auf Priorität 1 gesetzt. Das Verhalten bleibt das gleiche.
In dieser Grafik kann man das Verhalten gut erkennen:
@Dr.Niels es wäre toll wenn du die Mindestlaufzeit nochmals angehen würdest. Nach wie vor wird diese beim Phasenwechsel nicht immer aktiviert bzw. nicht berücksichtigt. Ich habe dort 300sec (5min) konfiguriert.
Die Wallbox (in meinem Fall die openWB2) braucht ungefähr eine Minute, um den Phasenwechsel zu vollziehen. Dafür hat mein Modul eine Sperrzeit, welche konfiguriert werden kann (in meinem Fall 2min). Der Grund ist, dass das EV nicht die Ladung blockiert, weil wegen der unmittelbar aufeinanderfolgenden Phasenwechsel ein Fehler abgelegt wird.
Durch die nicht aktivierte Mindestlaufzeit kann es nun passieren, dass der Energiemanager gegen die Sperrzeit des Moduls hämmert und dann irgendwann die Wallbox deaktiviert, weil diese nicht reagiert.
Zur Veranschaulichung die Variable für die Phasenumschaltung, wo du siehst, dass häufig nur die 2min Sperrzeit meines Moduls wirksam sind, nicht die 5min Mindestlaufzeit, welche ich im Energiemanager für die Wallbox konfiguriert habe.
Einfach ganz am Anfang sowas wie
IPS_LogMessage('Aktionsskript - Speicher', 'Variable: ' . $_IPS['VARIABLE'] . ' Neuer Wert: ' . $_IPS['VALUE'] . ' Alter Wert: ' . GetValue($_IPS['VARIABLE']));
Das wäre sicherlich eine hilfreiche Erweiterung, aktuell ist das aber nicht möglich. Der Energie Manager nimmt sich einfach irgend einen Energiespeicher und nutzt den. Ich notiere mir das aber mal.
Ja, da passen einige Wechsel nicht zur Mindestlaufzeit… Hast du das Debug Log dazu? Da steht nochmal einiges mehr, da schaue ich dann gerne mal genauer.
ja klasse. Vielen Dank. Aus Sicht Nutzungsdauer wäre es hilfreich, wenn alle Speicher zuerst bis 80% entladen werden.
Vielleicht wäre es auch eine Idee, dass zuerst die Kapazität verwendet wird, die über “weiterladen” in den Akku geladen wurde), also die über dem vorgegebenen Ladewert aufgeladen wurde.
So könnte mit den vorhandenen Parametern jeder selber einstellen wie viel Ladung zuerst entnommen werden sollte.
Fände ich auch eine gute Idee. Einen zweiten Schalter ‘Als freie Kapazität nutzen’ oder so ähnlich….
Ich habe mir dafür einen Ablaufplan für die Wallbox gebaut, welchen ich jeden Abend brauche wenn ich nach dem Feierabend nach Hause komme, um die überschüssige Energie noch zu verstauen.
Wenn das vom Energiemanger direkt unterstüzt würde, wäre das perfekt….
1 „Gefällt mir“
Ich hab IPS-LogMessage jetzt in das Aktionsskript eingefügt. Da sollte ich jetzt in nächster Zeit im Log dazu etwas finden, richtig?
Zwischendurch habe ich jetzt auch noch etwas anderes gemacht. Da es ja so war, dass die Ladeleistung aus irgendwelchen Gründen auf einen Wert gesetzt wurde und dort verharrt ist, obwohl eigentlich Einspeisung wäre, habe ich mit einem ausgelösten Ereignis die Ladeleistung auf 0 heruntergedrückt. Das hat auch schon geholfen. Allerdings kam dann doch das Phänomen, dass trotzdem der Energiemanager den Energiespeicher auf „inaktiv“ gesetzt hat. Ich dachte bisher, das hängt immer mit dem inkonsistenten Zustand von Ladeleistung und gleichzeitig Einspeiseleistung zusammen, aber scheinbar gibt es da noch einen anderen Einflussfaktor? Sehr komisch.
Hier konnte ich eine Aufzeichnung machen, wo die Mindestlaufzeit bei ca. 12.38 Uhr beim Wechsel von 3 → 1 Phase nicht aktiviert wurde. Leider hatte das dann aber keine Konsequenzen, da dann eh nicht mehr Leistung von der PV kam und der Energiemanager auch nicht wieder den Phasenwechsel vollziehen wollte. Aber zu oben erwähntem Zeitpunkt wurde die Mindestlaufzeit definitiv nicht aktiviert, was dann zu den erwähnten Problemen führen kann. Vielleicht siehst du im Dump den Grund dafür…
dump.txt (378,3 KB)
Hier nun habe ich den Energiemanager dazu gebracht, durch zuschalten von Verbrauchern die Wallbox auf 1 Phase zu wechseln. Die Mindestlaufzeit von 5min wurde nicht aktiviert. Danach versucht der Energiemanager während zwei Minuten (Sperrzeit des openWB2 Moduls) die Leistung wieder zu erhöhen, bis das dann nach 2 Minuten geklappt hat. Also hier ganz eindeutig nachvollziehbar. Meine Subjektive Wahrnehmung ist, dass die immer nur beim Wechsel von 3 zu 1 Phase passiert.
Umschalten auf 1 Phase ca 15.28
Umschalten auf 3 Phasen ca 15.30
dump.txt (315,1 KB)
Ich habe es jetzt bei mir so gelöst :
Schaltverzögerung runter auf 20s. Dadurch wird der Strom gut und schnell genug geregelt, mit der aktuellen Phasezahl.
Dann habe ich eine weitere bool Variable, die im EM als Gerät hinterlegt ist, abgelegt. Diese steht unterhalb des Autos und hat als Bedingung “1 phasig laden aktiv” und einen fiktiven Verbrauch von 800W. Wird diese true, wird alle 10s ein script ausgeführt, dass für die nächsten 10min prüft ob diese bool variable true bleibt.
Damit wird sichergestellt, dass mindestens 800W für 10min zusätzlich verfügbar sind.
Dann wird das Auto im EM deaktiviert, laden beendet und ein 120min timer gestartet. (Timeout der go e mach Landen beenden) Nach 120s geht das Auto im EM wieder auf automatisch. Jetzt startet dann der EM direkt mit 3 Phasen, da genug Strom da ist.
Nicht schön, scheint aber die einzig mögliche Lösung zu sein.