ecoflow-connector-Script zur dynamischen Leistungsanpassung

[sirdir]

@Waly_de Ich hab jetzt die für mich wichtigsten Dinge implementiert (ohne Feed-Prio, weil das wohl nicht geht) und es klappt so weit. Eine Frage, ist es normal, dass die Verbindung in unregelmässigen Abständen (wenige Sekunden) geschlossen und wieder aufgebaut wird?

[Odi77]

@sirdir Ich hatte seit ich die gleiche "clientId" wie Waly_de im Test-Skript verwendet hatte ("Ecoflow_1") den selben Effekt.
Ich habe nun einen komplett kryptischen jedoch konstanten Wert gewählt. - Nun scheint dieses Problem behoben zu sein.

[sirdir]

@odi77 Versuch ich mal - also auch fix, nicht generiert pro neustart oder so? Lustig ist auch, dass es nicht immer auftrat. Jetzt, nach ändern der ClientID seh ich’s auch nicht, aber eben, war auch vorher nicht immer so.

[Accu]

@ralf77 gestern lief mein Skript plötzlich wieder. Ab heute Morgen 5 uhr wieder das gleich wie am Tag zu vor. Es speist nicht mehr ein.
Hast du irgendeinenen Tipp?

[sirdir]

@accu Hast du dasselbe Problem wie ich vielleicht? Zusatzakku geht schlafen oder so? (battErrorCode: 8 ) und PS speist deswegen nichts ein. Hab jetzt mein Script so angepasst, dass in dem Fall der andere PS das Doppelte Einspeist, bis die Batterie irgendwann aufwacht…
Weiss auch nicht warum das mit der Batterie jetzt passiert und ob das auch irgendwie von Ecoflow gesteuert wird…

[Ralf77]

@accu gestern war bei mir auch wieder alles ok. Keine Ahnung warum…

Hast Du mal geschaut, ob Du irgendwo eine geplante Aufgabe noch aktiv hast oder eine Automatisierung aktiv ist?

Ich hatte es bisher noch nie, dass die Einspeisung komplett gestoppt wurde. Das kommt eigentlich bei mir nur vor, wenn ich z.B gesetzte Limits erreicht habe oder ich ein Abschalten durch Wechsel in den Speicher-Prio Modus aktiviert hatte .

Oder hast Du im Script eventuell den BattPrio Modus mit gewissen Zuständen verknüpft?

[sirdir]

@ralf77 Bei mir definitiv keine geplaneten Aufgaben etc. Steuerte alles über das Script. Irgendwas passiert manchmal bei manchen Leuten. Hab auch schon von welchen gehört die sagten, sie kriegen nur noch daten geliefert wenn sie die App aufmachen. Ich hab gesehen, dass das Script 0 einspeisen wollte, obwohl bedarf da war. Jemand, dem ich beim Setup geholfen habe hatte das auch schon mehrmals… Bei mir kam noch mehr dazu, warhscheinlich eben wegen der Batterie die sich schlafen legt oder vielleicht auch Serverprobleme, jedenfalls hatte ich plötzlich 2x0% SOC und sowas. Ich hab jetzt alles auf die offizielle API umgestellt. Nicht so sophisticated wie Waly’s Script, aber für mich tut’s jetzt seit ner Weile perfekt.

[gooflo]

@sirdir cool, dass Du es auf die offizielle API umgestellt hast. Teilst Du Deinen Code mit uns?

[sirdir]

@gooflo Kann ich schon machen aber es ist nicht das Script von Waly angepasst sondern einfach sein public-api sample benutzt um das nötigste für mich zu machen… hab an einigen Stellen schon versucht es etwas ‘generell’ zu schreiben aber am Ende ist es genau auf meinen Anwendungsfall mit 2 PS die einspeisen angepasst, speist den aktuellen Bedarf ein, nix historie etc. Weiss nicht ob das jemandem wirklich so viel nützt.

[Accu]

@Ralf77 habe keine Automatisierungen laufen. Nur das Skript. Glaube auch nicht dass es am ZA liegt. Denke es hat mit der EF API zu tun. Gestern habe ich mal den Fehler: authorized gesehen. Zudem habe ich das Gefühl ich muss regelmäßig die EF App aufmachen. Fühlt sich so an, als werden die Nutzer nach 1h Inaktivität rausgeworfen.

[gooflo]

@sirdir habe zufälligerweise auch zwei PS und außerdem noch zwei Shelly Pro und muss mir, wenn alles nicht mehr funktioniert, auch was Eigenes basteln, außerdem fände ich ein funktionierendes Beispiel für Regelung mit der neuen API auch super interessant ... Du siehst, ich zumindest hätte Interesse daran, dass Du es teilst (gerne auch direkt per Chat, falls Dir das lieber wäre).

[sirdir]

@gooflo OK, aber don’t judge me, es ist wirklich schnell zusammengehackt, ohne viel Fehlerprüfung etc.
Funktioniert so wohl nur mit D2M perfekt (wobei für die Grundfunktion sollte es keine Rolle spielen).

Hier das file:
https://www.sirdir.ch:8080/api/public/dl/7iPBEDLM/pspublicapi.js

[gooflo]

@sirdir cool, danke

[matz75]

@sirdir Super. So muss das sein. Werde mich mal gleich als Tester bereitstellen :-). Hab es mal implementiert und lasse nun regeln. Bisher sieht das sehr gut aus. Hab gleich mal um die Schwellwerte erweitert. Sprich: Akkustand kleiner xxx nur noch mit xxx max einspeisen. Die Überschussladung etc. steuere ich eh von extern. Da hab ich nicht so die Not. Wichtig ist, wieder eine stabile Regulierung am laufen zu haben. Und das sieht schon sehr gut aus. Danke

Reduzierung funktioniert

[sirdir]

@matz75 Ja überschussladung steuere ich auch extern. das mit der Reduzierung brauch ich nicht, ausser halt dass der andere PS übernimmt wenn der 1. leer ist. Da bin ich aber nicht sicher ob das zuverlässig klappt, weil zumindest der private MQTT Server da oft noch 1% und sogar aktive Einspeisung gemeldet hat, wenn nix mehr ging… aber ich hab das mit bei 0% speist der andere alles ein eher gemacht weil mein Zusatzakku eben manchmal nicht aufwacht und dann gemeldet wird er habe 0% und der PS speist nix ein… Was ich ja auch noch implementiert habe ist, dass wenn der eine Akku leerer ist als der andere, speist der vollere mehr ein.

PS: Vielleicht wäre ‘der andere speist nix ein’ auch besser als Kriterium um allein einzuspeisen als ‘akku ist auf 0%’. Allerdings… Gerade jetzt ist der eine PS offline, wahrscheinlich ha sich der Akku wieder abgeschaltet.. und laut daten fliessen 3 WAatt aus der Batterie und es gibt auch nen Akkustand. Einspeistung ist auf 0, aber wohl auch nur weil die auf 0 war als der Akku aus ging… Wirklich zuverlässig weiss ich fast nicht wie ich sowas feststellen kann…

Edit: Hab noch was versucht um das mit der leeren Batterie festzustellen und dabei auch gleich noch ein Limit integriert wie du es wohl brauchst. Kann’s jetzt nicht mehr sinnvoll testen weil der Akku leer ist…

[vanessa88]

Hi, also bei mir läuft das Script noch. Was mich stört, ist nach wie vor die quere Regelung. Ich habe drei Powerstream. Wenn richtig Sonne anliegt und ich nicht so viele Verbraucher habe, gerade unter der Woche, muss ich einen oder zwei abschalten. Sonst gehen da locker 800W ins Netz für nix. Solange der Akku geladen wird, passt das alles halbwegs - pendelt sich so bei 30 Watt ein, die ich entweder ins Netz abgeben oder beziehe. Schwankungen halt. Ist der Akku voll, regelt da nix mehr mehr und ich schalte 2 PS ab, damit nicht zuviel abgegeben wird. Im Vergleich zur ecoflow-eigenen Regelung über Shelly Pro 3EM ist das aber immer noch besser, obgleich die besser die Powerstreams runterregeln und zumindest in der Nacht eine Nulleinspeisung erreichen. Tagsüber ist deren Lösung nicht fungibel.

Die hier beschriebenen Authentifizierungsprobleme oder Ausstiege habe ich nicht. Ich arbeite allerdings noch mit der Hassio ecoflow cloud v0.13.4 und nicht mit der Aktuellen. Was hat es mit dem neuen Zugang auf sich?

[sirdir]

@vanessa88 Ich hab das so gelöst dass ich die Ecoflows mit Akku dran auf ‚überschuss nicht einspeisen‘ setze per script sobald überschuss zu gross wird. Der 3. der keinen Akku dran hat regelt Einspeisung entsprechend runter. Klappt noch nicht perfekt, aber immerhin.

[gooflo]

@sirdir und ich habe es folgendermaßen gelöst:

1. zwei globale Variablen bei den erweiterten Einstellungen definiert

intelligentBattPozOnMaxPower: true,                 // im Balance mode intelligent battPozOnMaxPower regeln ( (Target-Wert + Realpower)/Anzahl PSs)
intelligentBattPozOnMaxPowerTarget: 700,            // W für intelligente Regelung
 

2. im Balance Mode zählt man dann erst mal, wie viel nicht regulierte PSs man hat, d.h. bei wie vielen die Batterie voll ist:

let nNichtReguliertePSs = 0
...
  if (!GlobalObj[asn].regulieren)
    nNichtReguliertePSs++

3. und baut dann noch folgenden else-if im Balance mode ein:

else if (ConfigData.seriennummern[i].typ == "PS" && ConfigData.seriennummern[i].seriennummer != "XXXXXXXXXXXXX") {
  if (ConfigData.intelligentBattPozOnMaxPower) {
    if (nNichtReguliertePSs > 0) {
      let v = (ConfigData.intelligentBattPozOnMaxPowerTarget + lowestValue)/nNichtReguliertePSs
      setAC(asn, Math.floor(v * 10))
      mlog("unregulierter PS " + GlobalObj[asn].PsName + " (von insgesamt " + nNichtReguliertePSs + ")" + " set power = " + v.toFixed(0))
      GlobalObj[asn].OldNewValue = v                      
    }
  }
}

Der lowestValue Wert entspricht dem Bedarf, der dann auf die nicht regulierten PSs aufgeteilt wird, wobei man mit intelligentBattPozOnMaxPowerTarget einstellen kann, wie viel zusätzlich zum Bedarf eingespeist werden soll. Also wenn Bedarf 400 und ich habe zwei nicht mehr regulierte (= Batterie voll) PowerStreams und intelligentBattPozOnMaxPowerTarget = 600, dann wird je PowerStream 500W eingespeist. Ist nur einer von beiden nicht reguliert, dann versucht dieser die vollen 1000W einzuspeisen, was natürlich nicht klappt, den Rest übernimmt der andere über die normale Regelung.

[sirdir]

@gooflo Das klappt aber nicht wenn zu viele PS voll sind, oder? Was unschön ist, mein ‚überschuss nicht einspeisen‘ ist nun das letzte, wofür ich das ursprüngliche Script mit der private api noch brauche. Aber das kann man über die public api noch nicht steuern, soweit ich weiss.

[gooflo]

@sirdir weiß nicht genau was Du meinst, das ist unabhängig von der Anzahl der vollen PSs (hab's allerdings nur mit 2 getestet bisher ;-)): man legt über die Variable halt fest, wie viel eingespeist werden kann. Sagen wir bei 3 PSs, jeder bekommt 700W PV, wären also max. 2.100W Einspeisung möglich. Wenn nun die Speicher aller 3 voll sind, dann kann man über die Variable festlegen, dass statt 2.100 eben nur 700 oder was man halt will ins Stromnetz gehen soll.