@waly_de
Den Pulse greife ich über die API ab. Dafür gibt es direkt eine Integration in Home Assistant.

Die Zuverlässigkeit der API ist nicht perfekt. Da gibt es hier und da regelmäßig mal Aussetzer. Die Integration hängt sich auch gerne mal auf. Ich überwache den Sensor bereits in Home Assistant und starte die Integration neu sobald der Wert sich für fünf Minuten nicht ändert. Wenn die API spinnt hilft das aber auch nicht.
Es gibt auch eine Dokumentation auf GitHub um die Bridge des Pulse zu manipulieren und die Daten zumindest dort lokal abzufragen.

Vorher hatte ich einen Weidmann Lesekopf am Zähler und direkt per USB mit dem Host von Home Assistant verbunden. Absolut zuverlässig. Leider muss ich den Pulse nutzen um den stündlichen Tarif von Tibber nutzen zu können.

Es gäbe Möglichkeiten die Signale des Zählers auf einen weiteren Sendekopf zu spiegeln, aber so kontrolliere ich auch gleich ob alles korrekt auf den Servern von Tibber angekommen ist.

@waly_de
Ich kann das noch nicht genau sagen. Ab ca. 16:00 hat sich die Einspeiseleistung des Powerstream nicht mehr geändert und der Netzbezug ging damit teilweise ins Negative (Einspeisung). Gegen 17:30 habe ich das bemerkt und das Skript neu gestartet.
(Sorry, der erste Pfeil muss etwas weiter nach rechts auf kurz vor 16:00)

Abends schien es dann andauernd auszusetzen. Es kann aber auch sein, dass da andere Probleme mit reingespielt haben. Es gab gestern reichlich Updates bei ecoflow. Vielleicht war der MQTT Server schlicht überlastet, weil alle an den Geräten rumgespielt haben.
Im PV-Forum gibt es reichlich Beschwerden zu Problemen mit der Cloud bzw. dem Powerstream seit den Updates gestern.

Zur Klarstellung: das Skript läuft weiter und die Objekte in ioBroker werden auch aktualisiert. Es scheint irgendwann nur nicht mehr vom Powerstream übernommen zu werden.
Welches Objekt (state) in ioBroker entspricht dem Wert "Leistungsbedarf am AC-Ausgang"? Ich würde beobachten wollen ob dieses dann aktualisiert wird und zur tatsächlichen Einspeiseleistung passt.

Das mit der App ist ein guter Tipp. Ich werde diese schließen, das Skript 1x neu starten und dann einige Stunden die Finger von der App lassen.

Update:
es hängt wieder. Aktuell sieht es so aus:
Das Skript läuft und der Wert RealPower wird auch fleißig aktualisiert. Die Daten des Powerstream scheinen aber weder aktualisiert zu werden, noch überhaupt zu stimmen.
Beispiele:
totalPV steht unverändert auf 5762,88. Das kann nicht sein. Der Wert müsste um die 1000 liegen.
PV1_Power steht auf 3 und PV2_Power steht auf 6000.
PlugPower steht auf 36. Ist das der Wert für die Smart Plugs? Ich habe keine.

Ich vermute aktuell es liegt an der WLAN Verbindung des Powerstream.
Jepp, ich habe den Powerstream wieder auf den richtigen Repeater gezwungen und die Werte werden aktualisiert. Der Powerstream hat auch gleich wieder mit der Einspeisung begonnen. Das Problem liegt also vermutlich in meinem Netzwerk.

@waly_de said in ecoflow-connector-Script zur dynamischen Leistungsanpassung:

definition von protoSource2 vorhanden und vollständig ?

Wie prüfe ich das? Ich habe Protobuf und den MQTT Client mit den Befehlen aus dem Script über die Konsole installiert.
Nachtrag: die Werte der Delta 2 werden mit der aktuellen Version des Scripts aktualisiert. Die Werte des Powerstreams bekommt er anscheinend nicht decodiert.

@waly_de

Das Script läuft bei mir immer noch einwandfrei, trotz dem Umweg über Home Assistant. Super Arbeit. Danke dafür!

Nichts ist so gut, dass es nicht mehr verbessert werden könnte. Daher mal zwei Ideen für die sonnenschwache Jahreszeit:

1. wie wäre es mit einem Pendant zu BattPoz On/Off für niedrigen Ladestand? Derzeit wird bei wenig Solarertrag der Akku permanent geladen und wieder entladen. Damit geht jeglicher Ertrag erst durch den Akku. Das bedeutend Verschleiß und erhebliche Verluste.
   Ich würde hier ab einem gewissen Ladestand die Einspeisung ins Netz auf einen einstellbaren Höchstwert begrenzen, bis der Akku eine bestimmte Ladegrenze wieder erreicht hat.
2. könnte man die Einstellung „Regulation: true/false“ optional abhängig vom State eines Objektes machen? Ich für meinen Fall denke hier an einen Switch in Home Assistant dessen State ich an ioBroker durchreiche. Im Idealfall wird beim Umstellen auf false bei laufenden Script einmalig ein zu definierter Einspeisewert eingestellt.

Nachtrag zu Punkt 2:
Ich habe in Home Assistant ein Auswahlfeld mit true/false angelegt. Dessen Status wird in ioBroker durchgereicht und den state dieses Objektes habe ich im Script in den Nutzerdaten für regulation hinterlegt. Läuft aber irgendwie noch nicht zuverlässig. Es wird weiterhin geregelt, auch wenn ich auf false stelle.

@waly_de
Wow, läuft.
Bisher grundsätzlich getestet:

• LowBatLimit -> ist erfolgreich angesprungen
• RegulationState -> Änderungen aus Home Assistant per Schalter werden per Script übertragen und korrekt übernommen, inkl. Begrenzung der Leistung
• SetPrio -> Umstellung per Auswahlliste in Home Assistant wird per Script übertragen und übernommen

Langzeittest steht aus.

@ponti92 said in ecoflow-connector-Script zur dynamischen Leistungsanpassung:

@dreffi
Ja dieser Modus kommt schon ganz gut hin, jedoch ist der Wert der Einspeisung dann fix auf 150W eingestellt. D.h. bei einer Solarleistung von 50W werden dann trotzdem 100W vom Akku genommen und dieser dann weiter entleert.

Dann muss der Wert noch kleiner gestellt werden. Ich habe den aktuell auf 50W bei 4x 410W Peak am Powerstream.

Meine Idee war, dass man dann den Wert von Solar auf den AC Output spiegelt, sodass Solareingang == AC Output ist.

Problem: die Solarleistung wird durch den eingestellten Wert für die Ausgangsleistung gedrosselt. Die mögliche Solarleistung ist unbekannt. Man könnte sich da nur Schrittweise rantasten. Ich persönlich glaube das wird nichts. Dann lieber auf Prio Akku. Sobald die Ladegrenze erreicht wurde wird dann direkt eingespeist. Leider kann die Ladegrenze nicht auf weniger als 50% gesetzt werden. Zumindest nicht per App.

@waly_de
Was mir grundsätzlich lieb wäre: (optional) statt BattPoz bei vollem Akku, die Priorität umstellen. Also SOC = SOCMax --> umstellen auf Prio Akku. Wenn Mindest- oder Durschnittsbezug >= X für Betrachtungszeitraum --> zurückstellen auf Prio Einspeisung.
Dabei wird die Solarenergie 1:1 durchgeschleift. Also keine Verluste und der Akku wird nicht unnötig verschlissen.

Mein Ansatz ist aktuell: 1 Powerstrem deckt die Grundlast (PV 2) und einer liefert bei Bedarf den Rest dazu (PV 1).

Dazu die Möglichkeit diese Regelungen für vollen und leeren Akku auch auf den zweiten Powerstream anzuwenden. Mehr braucht es gar nicht.

Meine Spielerei mit Home Assistant mache ich nur, weil die Regelungen aus dem Skript für hohen und niedrigen Akkustand sonst für den zweiten Powerstream nicht angewendet werden. Das bilde ich damit nur extern nach.

Nur ein Szenario habe ich derzeit nicht abgedeckt: PV 1 ist voll geladen und geht auf Prio Akku (aktuell würde die Einspeisung durch BattPoz greifen). In dem Fall würde PV 2 weiter die eingestellte Grundlast einspeisen. Praktisch ist in dem Fall immer Sonne im Überfluss vorhanden. Eleganter wäre in dem speziellen Fall (PV 1 Akku voll) PV 2 zu drosseln. Luxusproblem. Da würde ich mir im Moment gar keine Gedanken machen.
So lange beide Akkus über Nacht leer werden, reguliert sich das immer wieder selbst ein. Falls die Akkus nicht leer werden, sind wir wieder beim Luxus. Sonne im Überfluss.

Das passt natürlich erstmal nur für insgesamt zwei Powerstreams.
Hätte ich drei Powerstreams, würde ich die Grundlast fest auf zwei aufteilen und wieder nur den dritten nach Bezug regeln lassen. Noch mehr Powerstreams sind dann doch eher unwahrscheinlich und fernab jeglicher Zulässigkeit.

Grundsätzlich würde ich versuchen das nicht zu komplex zu machen. Keep it simple!
Es ist nur eine Frage der Zeit bis Ecoflow wieder was an den Daten oder der Regelung ändert. Dann sollte das Skript einfach und robust sein.
Beispiel: ich hoffe noch, dass die Überschusseinspeisung bei vollem Akku irgendwann auch für den Modus Prio Einspeisung kommt. Dann würde ein Problem schonmal wegfallen. Vielleicht schafft es Ecoflow irgendwann auch das Verhalten bei fast leerem Akku zu optimieren. Dann wäre unterm Strich wieder nur die Regelung eines einzigen Powersteams nach Bezug erforderlich.

@waly_de
Zwischenbericht:
an und für sich läuft die Steuerung von zwei Powerstreams in meiner jetzigen Konfiguration einwandfrei.
Alles was mir noch fehlt:

• Umstellung auf Prio Akku bei Erreichen von BatLimitHigh.
• Steuerung der weiteren Powerstreams bei vollem/leeren Akku wie auch den ersten (Leistungsbegrenzung und Umstellen der Priorisierung)

Einfach volle Pulle einzuspeisen bei vollem Akku missfällt mir. Das geht unnötig auf den Akku. Verschenken des Potentials wäre aber auch schade.

Nachtrag:
Heute scheint die Sonne reichlich. Ich nutze das um die Trigger zum Umstellen der Priorisierung zu optimieren.
Ladegrenze erreicht (SOC = BatLimitHigh) --> stelle auf Prio Akku
Tatsächliche Einspeiseleistung fällt einige Zeit deutlich unter Bedarf --> stelle zurück auf Prio Einspeisung. Das sollte sowohl mit fest eingestellter Grundlast als auch mit einem durch das Script gesetzten Bedarf funktionieren. Ich warte hier ab bis der Wert für durchgehend 5 Minuten mindestens 20 W unter den eingestellten Bedarf fällt.

Wenn beide Powerstreams dank vollem Akku auf Prio Akku stehen, wird aus dem gesamten System wieder ein normales Balkonkraftwerk, inkl Bezug bei Wolken. Hier muss man entscheiden ob das so wirklich sinnvoll ist. Ich weiß aber nicht ob die aktuelle Regelung (BattPozON/Off) besser funktioniert. Als Kompromiss sehe ich erstmal nur meinen Powerstream für die Grundlast auf Prio Akku zu stellen und den zweiten per Script nach Bedarf regeln zu lassen. Da wird eventuell weiteres PV-Potential verschenkt, aber es erfolgt möglichst kein Bezug.

Aktuelles Problem: nachdem zurück auf Einspeisung gestellt wurde, wird der Trigger zum erneuten Umstellen auf Prio Akku (SOC) erstmal nicht mehr erreicht werden. Das funktioniert so nur einmalig. Also wohl doch entweder die aktuelle Regelung beibehalten oder auf Überschusseinspeisung verzichten.

So richtig perfekt ist das alles nicht. Ideal wäre wenn Ecoflow einfach im normalen Modus Stromversorgung priorisieren auch den Überschuss mit einspeist. Das extern durch Regelung zu korrigieren ist doof.

Ich hätte auch noch einen Wunsch:

RegulationMultiPsMode: 2 = invers
Ziel soll sein die Last in umgekehrter Reihenfolge auf die Powerstreams zu verteilen als sonst bei seriell.

@accu
Nach dem was ich gelesen habe aktiv im Vordergrund laufend.

https://github.com/tolwi/hassio-ecoflow-cloud/issues/283

Milli42 created this issue in tolwi/hassio-ecoflow-cloud

open Delta Pro Only Populates Data When Connected To App #283

@accu
Viele Nutzer haben im Moment das Peoblem, dass über die API nur Daten aktualisiert werden, wenn parallel die App auf dem Smartphone oder Tablet geöffnet ist.

Das scheint viele, aber nicht jeden zu betreffen. Bei mir läuft alles reibungslos.

@accu
TotalPV wird glaube ich vom Script aus den beiden PV Eingängen des Powerstreams berechnet.
(pv1InputWatts + pv2InputWatts) / 10 = TotalPV

Werden die aktualisiert?

@accu
Zu der Fehlermeldung: ignorieren.
Mangels laufender Kommunikation steht der State des Objekts auf 0. Die werden nur bei Änderungen aktualisiert.

Wenn es dich stört, setz den State manuell auf den richtigen Wert (Ladestand).

Nur für die Statistik:
Bei mir scheint es auch heute weiterhin zu funktionieren. Die Powerstreams sind gerade erwacht und speisen wie gewünscht ein.

@lordminorin
Du meinst du hast das Problem seit einem App Update? iOS oder Android?

Bei mir läuft noch alles. Sowohl in Home Assistant als auch in ioBroker. Ich öffne vorsichtshalber die App nicht mehr. Für die iOS App wird mir derzeit ein Update auf 5.5.1 angeboten.

Die Home Assistant Integration für Ecoflow bekommt aktuell bei vielen Nutzern Probleme. Dort lassen sich die Werte nur noch aktualisieren wenn gleichzeitig die Ecoflow App geöffnet ist.
https://github.com/tolwi/hassio-ecoflow-cloud/issues/283

Hat schon jemand mit diesem Script etwas ähnliches festgestellt?
Bei mir läuft es derzeit sowohl mit Home Assistant als auch mit diesem Script noch ohne Probleme.

Milli42 created this issue in tolwi/hassio-ecoflow-cloud

open Delta Pro Only Populates Data When Connected To App #283

Bei meinen beiden Powerstreams werden seit dem 20.05. die Objekte für die Temperatur nicht mehr aktualisiert.
0_userdata.0.ecoflow.app_device_property_xxx.data.InverterHeartbeat.llcTemp
0_userdata.0.ecoflow.app_device_property_xxx.data.InverterHeartbeat.pv1Temp
0_userdata.0.ecoflow.app_device_property_xxx.data.InverterHeartbeat.pv2Temp

Die Temperatur des Akkus wird weiterhin aktualisiert.
Hat noch jemand das Problem bzw. kann mal in den Objekten auf den Zeitstempel gucken?
Ich habe beide Powerstreams am 20.05. auf die WLAN Version 1.1.4.31 aktualisiert. Ich weiß nicht ob es damit zusammenhängt.

Ich habe aktuell ein kleineres Problem. Ich habe für LowBatLimit externe States angelegt. Wenn diese geändert werden wird das auch vom Script protokolliert, aber die Regelung wird nicht immer daran angepasst. Es wird weiter mit dem bisherigen Wert gearbeitet.
Der aktuelle wird z.B. berücksichtigt wenn ich das Script über RegulationState = false/true neu starte oder der jeweilige Akku neu unter LowBatLimitPozOn fällt.

Hintergrund: ich wollte damit morgens bei ausreichender Sonnenenergie die Leistung kontrolliert schon früher freigeben.

@waly_de said in ecoflow-connector-Script zur Leistungsanpassung:

• SerialReverse: Wenn true, werden im Serial Mode (RegulationMultiPsMode: 1) die Power Sources in umgekehrter Reihenfolge durchlaufen.

Perfekt! Wird heute noch getestet.
Danke!