ecoflow-connector-Script zur dynamischen Leistungsanpassung
-
@sirdir , aktiv abfragen kannst wenn es per mqtt nicht geht, mit http. Auch setzen geht (alternativ) per http.
Ich nutze mqtt auch mehr fürs monitoring, man subscribed /abonniert ja topic die einen interessieren und dementsprechend finde ich es korrekt das nur Änderungen mitgeteilt werden.
Aktiv schalten und co dann per http...Aber gibt sicherlich verschiedene Wege nach Rom
Edit: ich glaube Einspeisekontrolle fehlt tatsächlich (vermutlich) noch, war zumindest damals so. Die kam ja erst in späterer Firmware und müsste von Ecoflow in die API aufgenommen werden (wenn nicht vorhanden).
Ich nutze die nicht deshalb habe ich die nicht weiter verfolgt. -
@giovanne OK, ich brauch das mit der Einspeisekontrolle…
So oder so, ist doch ne ganz schöne Arbeit das Originalscript anzupassen, zumal ich das erst mal richtg analysieren müsste.
Ich fühl mich so doof, hab jetzt nochmal den http Weg versuchen wollen und mit der Funktion von Wally zu signieren versucht, aber der Wert den ich raus krieg wenn ich die Parameter aus dem Beispiel von Ecoflow übergebe stimmt nicht überein…Edit: Man sollte Funktionen, die man benutzt vielleicht auch mal anschauen
er sortiert das ja um.. ohne das stimmt der Wert. -
jetzt hats mich auch erwischt und das Script speist nicht mehr ein. Muss irgendwann letzte Nacht um 5 Uhr morgens passiert sein. Seltsamerweise lief es jetzt all die Zeit problemlos, bis ich gestern an der Anlage rumgespielt hatte und den Powerstream AC-seitig vom Strom getrennt hatte. Was ein Mist. Der Realpower -Wert wird in den Objekten noch angezeigt. Woran sieht man eigentlich, dass von EF MQTT nichts mehr zuürck kommt in den Objekten?
Gibt es irgendwelche Alternativen was man jetzt machen kann? wie habt ihr das alle jetzt gelöst. Vorallem dass ich die Überschussladung jetzt nicht mehr nutzen kann nervt ohne Ende.
Im Skript schein er bestimmte Werte vom PS nicht mehr zu lesen.
-
@accu das ist normal soweit ich weiß und and dauert immer kurze Zeit nach eine, Neustart, bis wieder entsprechend historische Werte angelegt sind. Das sollte alles schon wieder funktionieren. Di3se Meldung bekomme ich auch, wenn ich neu starte… nach ein paar Minuten geht es dann wieder normal weiter.
Generell habe ich aber auch ein Problem… Immer gegen 2 Uhr in der Nacht verdoppelt der ioBroker die Einspeisung. Keine Ahnung, was das ist… wir schlafen da alle und es ist auch genügend Energie im Speicher. Das ist so jetzt schon die 2 Nacht. Jemand eine Ahnung, was das sein kann?
-
@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?
-
@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. -
@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.
-
@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? -
@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… -
@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?
-
@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.
-
@sirdir cool, dass Du es auf die offizielle API umgestellt hast. Teilst Du Deinen Code mit uns?
-
@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.
-
@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.
-
@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).
-
@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 -
@sirdir cool, danke
-
@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
-
@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…
-
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?
