NEWS
ecoflow-connector-Script zur dynamischen Leistungsanpassung
-
@est58 dann mach doch einen Shelly EM (pro) rein in den Sicherungskasten und nutze die Ecoflow dynamische Regelung. Bis jetzt läuft bei mir alles absolut problemlos mit dem Script, PS und DP…
-
@est58 dann mach doch einen Shelly EM (pro) rein in den Sicherungskasten und nutze die Ecoflow dynamische Regelung. Bis jetzt läuft bei mir alles absolut problemlos mit dem Script, PS und DP…
@ralf77 ich beginne gerade mich mit shelly / homeassistant zu beschäftigen und hab auch in der EF-Gruppe an die Nutzer eine Anfrage gestellt. Meiner Erinnerung nach gabs die letzten 2 Wochen auch Ausfälle bei der Datenübermittlung, aber weil ich mir unsicher bin, hab ich die Frage gestartet, ob das eine Alternative sein kann.
-
@est58 Und heute musst ich wieder ständig die App offen halten.
Und meine 8 SmartPlugs 2x über den Tag ziehen und neu stecken bzw. entsprechende Sicherung aus und an.
Das macht keinen Spass mehr mit Ecoflow und ich hab in meine Anlage 16k Euro investiert letztendlich.
Das Skript wäre eine super Idee, aber wenn Ecoflow die Vorgaben ändern, es dann aber niemand gibt, der in der Lage ist, das Skript anzupassen, um es wieder lauffähig zu bekommen, dann ist hier eben Schluss mit der Nutzungsmöglichkeit. Schade ist das.
@est58
Meiner Einschätzung nach ist es egal welche Umgebung du benutzt (Script, Adapter, HA, …). Das basiert alles auf den gleichen Kommunikationsprinzipien. Hat also weniger mit Script weiterentwickeln zu tun. Aus meiner Sicht sollte der Fokus darauf liegen, was die App sonst noch so tut um sich als offiziell zu legitimieren. Allerhöchste Zeit sich den Datenverkehr anzuschauen, ob da noch zusätzliche Topics benutzt werden oder noch woanders hin telefoniert wird. Fürs erste bräuchte es einen lokalen MQTT Server der selbst nur Client bei EF ist, sich aber als der offizielle ausgibt. Sozusagen man in the middle. Das geht aber nicht mit self signed certificates, zumindest verweigert mein Adapter schon die Kommunikation mit einem mqtt-Server mit diesen jenen. Verdacht nach unbekannten topics habe ich schon länger, da darüber evtl. auch die Smart plugs einen Kanal haben.
Oder es gibt ein spezielles Telegramm was noch nicht erkannt wurde, aber einen eventuellen timeout am mqtt Server verhindert.Die einzige Möglichkeit ist die offizielle API, aber zum einen sind dort nicht alle Geräte verfügbar. Und wenn unterstützt, dann ist nur ein Bruchteil der Daten sichtbar.
Für die meisten kann das reichen, aber warum diese Limitierung. -
@est58
Meiner Einschätzung nach ist es egal welche Umgebung du benutzt (Script, Adapter, HA, …). Das basiert alles auf den gleichen Kommunikationsprinzipien. Hat also weniger mit Script weiterentwickeln zu tun. Aus meiner Sicht sollte der Fokus darauf liegen, was die App sonst noch so tut um sich als offiziell zu legitimieren. Allerhöchste Zeit sich den Datenverkehr anzuschauen, ob da noch zusätzliche Topics benutzt werden oder noch woanders hin telefoniert wird. Fürs erste bräuchte es einen lokalen MQTT Server der selbst nur Client bei EF ist, sich aber als der offizielle ausgibt. Sozusagen man in the middle. Das geht aber nicht mit self signed certificates, zumindest verweigert mein Adapter schon die Kommunikation mit einem mqtt-Server mit diesen jenen. Verdacht nach unbekannten topics habe ich schon länger, da darüber evtl. auch die Smart plugs einen Kanal haben.
Oder es gibt ein spezielles Telegramm was noch nicht erkannt wurde, aber einen eventuellen timeout am mqtt Server verhindert.Die einzige Möglichkeit ist die offizielle API, aber zum einen sind dort nicht alle Geräte verfügbar. Und wenn unterstützt, dann ist nur ein Bruchteil der Daten sichtbar.
Für die meisten kann das reichen, aber warum diese Limitierung.Solange es noch keine Bestätigung gibt, dass das script nur beim erst Aufruf sich die mqtt-credentials holt und immer mit der gleichen Androidkennung läuft, würde ich vom häufigen Neustarten des scriptes absehen. Sonst gibt es sehr viele „Geräte“ die mit dem Server in Verbindung stehen/standen. Da muss man als EF nur mitschneiden und zählen.
-
Solange es noch keine Bestätigung gibt, dass das script nur beim erst Aufruf sich die mqtt-credentials holt und immer mit der gleichen Androidkennung läuft, würde ich vom häufigen Neustarten des scriptes absehen. Sonst gibt es sehr viele „Geräte“ die mit dem Server in Verbindung stehen/standen. Da muss man als EF nur mitschneiden und zählen.
@foxthefox Das Skript hat heute Nacht mehrfach gestoppt, kostete 2kWh Landstrom trotz Strom in den Akkus (max 18kWh Speicher)
Im Adapter Energiefluss-erweitert brauche ich einiges an Datenpunkten, die wird mir dankenswerterweise Dein Adapter verschaffen und ich behalte den Überblick, auch wenn das Skript nicht läuft.
Die Regelung muss ich dann wieder den Ecofloweigenen Methoden überlassen, aber die sind zuverlässiger als das Skript. Also Steuerung über die 8 SmartPlugs und manueller Einpegelung der verbleibenden Grundlast.
Hab leider keine Ahnung, wie man Skripte schreibt/programmiert, deswegen bleibt mir nur diese Notlösung. -
@foxthefox Das Skript hat heute Nacht mehrfach gestoppt, kostete 2kWh Landstrom trotz Strom in den Akkus (max 18kWh Speicher)
Im Adapter Energiefluss-erweitert brauche ich einiges an Datenpunkten, die wird mir dankenswerterweise Dein Adapter verschaffen und ich behalte den Überblick, auch wenn das Skript nicht läuft.
Die Regelung muss ich dann wieder den Ecofloweigenen Methoden überlassen, aber die sind zuverlässiger als das Skript. Also Steuerung über die 8 SmartPlugs und manueller Einpegelung der verbleibenden Grundlast.
Hab leider keine Ahnung, wie man Skripte schreibt/programmiert, deswegen bleibt mir nur diese Notlösung.Ich setze das Script nicht ein, kann dazu recht wenig sagen.
Meine Zeit ist etwas begrenzt und das dürfte für viele Entwickler hier zutreffen. Deswegen leidet bei mir zum Beispiel die Oberfläche drunter, wo ich mich der Einfachheit halber über das von mir implementierte Gateway zu Homeassistant beholfen habe.Ich würde gern auch mehr in Richtung lokales Interface machen, aber das dauert halt. Und neue Geräte wollen auch in den Adapter rein.
Wie oben geschrieben, aus meiner Sicht ist der Datenverkehr genauer anzuschauen. Braucht eine gewisse Akribie und auch Willen und Zeit und geht über das einfache Anwenden hinaus.
Wenn also was entdeckt wird, kann ich das auch im Adapter einarbeiten.Das Dinge mal nicht funktionieren passiert, das ein Hersteller dazwischengrätscht und ggf. die Ursache ist, ist doppelt schlimm.
Aus meiner Sicht tendiert man sehr schnell zum verteufeln von Allem und der Frust entlädt sich überall.EF macht tendenziell keine schlechten Produkte und nicht vorhandene Funktionen oder Schwachstellen versucht man über inoffizielle Zugänge und scripte zu lösen. Dabei wäre es angebracht genau die Funktionen und Berichtigung dort einzufordern. Die Shelly Integration ist beta und läuft noch nicht annähernd gut, weil ggf. die cloud zu cloud Lösung das Problem ist oder weil der Algorithmus nicht gut ist. Auch funktioniert bei Akku voll und auch dort vorhandenen Panels die Überschusseinspeisung nicht wirklich.
Reaktion auf die Last von den Smartplugs funktioniert aber recht gut.
Nulleinspeisung ist wünschenswert, aber ich kenne eine Installation wo keine Smartplugs verwendet sind und bei 3 Kühlschranken und überlappenden Zyklen dennoch eine feste Grundlast eingestellt ist. Ja manchmal geht auch was ins Netz zurück (max 50W), aber man ist zufrieden damit.
Just my 2ct.
-
Ich setze das Script nicht ein, kann dazu recht wenig sagen.
Meine Zeit ist etwas begrenzt und das dürfte für viele Entwickler hier zutreffen. Deswegen leidet bei mir zum Beispiel die Oberfläche drunter, wo ich mich der Einfachheit halber über das von mir implementierte Gateway zu Homeassistant beholfen habe.Ich würde gern auch mehr in Richtung lokales Interface machen, aber das dauert halt. Und neue Geräte wollen auch in den Adapter rein.
Wie oben geschrieben, aus meiner Sicht ist der Datenverkehr genauer anzuschauen. Braucht eine gewisse Akribie und auch Willen und Zeit und geht über das einfache Anwenden hinaus.
Wenn also was entdeckt wird, kann ich das auch im Adapter einarbeiten.Das Dinge mal nicht funktionieren passiert, das ein Hersteller dazwischengrätscht und ggf. die Ursache ist, ist doppelt schlimm.
Aus meiner Sicht tendiert man sehr schnell zum verteufeln von Allem und der Frust entlädt sich überall.EF macht tendenziell keine schlechten Produkte und nicht vorhandene Funktionen oder Schwachstellen versucht man über inoffizielle Zugänge und scripte zu lösen. Dabei wäre es angebracht genau die Funktionen und Berichtigung dort einzufordern. Die Shelly Integration ist beta und läuft noch nicht annähernd gut, weil ggf. die cloud zu cloud Lösung das Problem ist oder weil der Algorithmus nicht gut ist. Auch funktioniert bei Akku voll und auch dort vorhandenen Panels die Überschusseinspeisung nicht wirklich.
Reaktion auf die Last von den Smartplugs funktioniert aber recht gut.
Nulleinspeisung ist wünschenswert, aber ich kenne eine Installation wo keine Smartplugs verwendet sind und bei 3 Kühlschranken und überlappenden Zyklen dennoch eine feste Grundlast eingestellt ist. Ja manchmal geht auch was ins Netz zurück (max 50W), aber man ist zufrieden damit.
Just my 2ct.
@foxthefox Alles was bei mir plus-minus 80Watt um Null angezeigt wird, bekommt eine überwiegend grüne Farbgebung, dann sehe ich altersichtiger Gleitsichtbrillenträger mit nur noch 90% Sehfähigkeit schon von weitem, die Regelung ist ok.
Die Plugs regeln im Gegensatz zum Skript, wenn es nur auf den Stromzähler reagiert, sehr schnell hoch und runter und pendeln sich somit viel schneller wieder um die Null herum ein.
Die Grundlast ist halt fix. Kommen größere Verbraucher außerhalb der Plugs dazu, dann geht das zu Lasten des Landstrom es sei denn, man setzt die Grundlast manuell hoch.
Einen taktenden Backofen oder Herdplatte wird man niemals einfangen, denn für die sind die Plugs ungeeignet.
Das hat bisher das Skript über Monate gut geregelt, aber das scheint ja jetzt Geschichte zu sein.Heute werde ich einen neuen Energiefluss-erweitert mit den Datenpunkten aus Deinem Adapter bestücken. Dann werde ich sehen, ob Ecoflow es da auch schafft, die Übertragung zu sabotieren. Gibt es da schon Erfahrungswerte? Sicher weiter vorne zu lesen.
-
@foxthefox Alles was bei mir plus-minus 80Watt um Null angezeigt wird, bekommt eine überwiegend grüne Farbgebung, dann sehe ich altersichtiger Gleitsichtbrillenträger mit nur noch 90% Sehfähigkeit schon von weitem, die Regelung ist ok.
Die Plugs regeln im Gegensatz zum Skript, wenn es nur auf den Stromzähler reagiert, sehr schnell hoch und runter und pendeln sich somit viel schneller wieder um die Null herum ein.
Die Grundlast ist halt fix. Kommen größere Verbraucher außerhalb der Plugs dazu, dann geht das zu Lasten des Landstrom es sei denn, man setzt die Grundlast manuell hoch.
Einen taktenden Backofen oder Herdplatte wird man niemals einfangen, denn für die sind die Plugs ungeeignet.
Das hat bisher das Skript über Monate gut geregelt, aber das scheint ja jetzt Geschichte zu sein.Heute werde ich einen neuen Energiefluss-erweitert mit den Datenpunkten aus Deinem Adapter bestücken. Dann werde ich sehen, ob Ecoflow es da auch schafft, die Übertragung zu sabotieren. Gibt es da schon Erfahrungswerte? Sicher weiter vorne zu lesen.
@est58
Ich hab noch nicht ganz verstanden was du machen willst, aber grundsätzlich ist auch der Datenpunkt für Grundlast im Adapter dabei. Den kann man mit eigenen Script oder node-red auch steuern.Adapterüberblick: Profil Github;
Wenn der Adapter gefällt und nützlich ist, bitte ins Repo gehen und Star setzen. Danke
Ein Aufruf: video
-
@est58
Ich hab noch nicht ganz verstanden was du machen willst, aber grundsätzlich ist auch der Datenpunkt für Grundlast im Adapter dabei. Den kann man mit eigenen Script oder node-red auch steuern.Hallo, bei mir hatte das Skript bzw. dessen Regelung nur an zwei Nächten Aussetzer.
Sonst läuft es bisher einwandfrei obwohl die App nicht immer offen ist...
Ist es noch nicht bei allen Usern umgestellt?
P.S.: Für mich Interessant: Man kann den Tibber Puls als Messgerät in Ecoflow integrieren. Sollte die Steuerung darüber bei mir funktionieren und nicht mehr über das Skript auf meinem Raspberry zu Hause? Bin gerade im Urlaub und habe auf nichts Zugriff :-)
Nächtliche Einspeisung sollte damit ja klappen:
Aber die Laderegelung der Delta Pro mit Shelly eher nicht.
-
Hallo, bei mir hatte das Skript bzw. dessen Regelung nur an zwei Nächten Aussetzer.
Sonst läuft es bisher einwandfrei obwohl die App nicht immer offen ist...
Ist es noch nicht bei allen Usern umgestellt?
P.S.: Für mich Interessant: Man kann den Tibber Puls als Messgerät in Ecoflow integrieren. Sollte die Steuerung darüber bei mir funktionieren und nicht mehr über das Skript auf meinem Raspberry zu Hause? Bin gerade im Urlaub und habe auf nichts Zugriff :-)
Nächtliche Einspeisung sollte damit ja klappen:
Aber die Laderegelung der Delta Pro mit Shelly eher nicht.
@thomas-weller leider hab ich die Aussetzer nahezu jeden Tag.
Aber ich verabschiede mich grad von dem Skript und wechsle auf den Ecoflow MQTT-Adapter.
Dann kann ich im Energiefluss immer meine Daten sehen, egal welche Variante des Skripts bei mir grad gelaufen wäre.
Und die Regelung erfolgt wie vor dem Skript mit 8 SmartPlugs und manueller Anpassung der verbleibenden Grundlast.
Und diese Lösung läuft ganz rund und ist heute noch fertig. -
@thomas-weller leider hab ich die Aussetzer nahezu jeden Tag.
Aber ich verabschiede mich grad von dem Skript und wechsle auf den Ecoflow MQTT-Adapter.
Dann kann ich im Energiefluss immer meine Daten sehen, egal welche Variante des Skripts bei mir grad gelaufen wäre.
Und die Regelung erfolgt wie vor dem Skript mit 8 SmartPlugs und manueller Anpassung der verbleibenden Grundlast.
Und diese Lösung läuft ganz rund und ist heute noch fertig.@est58
Ich möchte keine Plugs mehr verwenden.
Ich greife den Stromverbrauch bzw. Überschuss an meinem SolarEdge Smartmeter ab.
Mit Tibber hat Ecoflow ja für mich jetzt auch alles an Board.
Verbrauch/ Überschuss kommt vom Tibber Pulse und die Steuerung der Ladung über einen Shelly würde auch gehen.Ich bin gespannt was die Zeit bringt.
-
@est58
Ich möchte keine Plugs mehr verwenden.
Ich greife den Stromverbrauch bzw. Überschuss an meinem SolarEdge Smartmeter ab.
Mit Tibber hat Ecoflow ja für mich jetzt auch alles an Board.
Verbrauch/ Überschuss kommt vom Tibber Pulse und die Steuerung der Ladung über einen Shelly würde auch gehen.Ich bin gespannt was die Zeit bringt.
@thomas-weller ja, die Plugs haben den Riesennachteil, dass wenn einer offline geht, sämtliche andere Plugs ihre Regelfunktion nicht mehr wahrnehmen.
Erschwerend kommt dazu, dass man zu Hause sein muss und den Plug ziehen muss und wieder neu einstecken (oder eben die Sicherung).
Also so was im Urlaub und dann weißt Du zum X-ten Mal, dass Du ein Spielzeug von Ecoflow gekauft hast und keine ernstzunehmenden Geräte.Ich hoffe auch auf bessere Lösungen, der Schritt zurück auf Smartplugs kann nur temporär sein.
-
@thomas-weller ja, die Plugs haben den Riesennachteil, dass wenn einer offline geht, sämtliche andere Plugs ihre Regelfunktion nicht mehr wahrnehmen.
Erschwerend kommt dazu, dass man zu Hause sein muss und den Plug ziehen muss und wieder neu einstecken (oder eben die Sicherung).
Also so was im Urlaub und dann weißt Du zum X-ten Mal, dass Du ein Spielzeug von Ecoflow gekauft hast und keine ernstzunehmenden Geräte.Ich hoffe auch auf bessere Lösungen, der Schritt zurück auf Smartplugs kann nur temporär sein.
Hab grad einen interessanten Eintrag bei der HA integration von tolwi gesehen:
"
from FB
client_id limits for MQTT connections
If you are using MQTT to connect to the API be aware that only 10 unique client IDs are allowed per day.
As such, it is suggested that you choose a static client_id for your application or integration to use consistently.
If your code generates a unique client_id (as mine did) for each connection,
you can exceed this limit very quickly when testing or debugging code.
"Keine Ahnung wie offiziell das verkündet wurde, aber immerhin gibt es hier einen Hinweis auf die Begrenzung auf 10 client IDs pro Tag. Bestätigt ein wenig meine oben geäußerten Ideen.
EDIT:
Unten gibt es eine Rückmeldung von @giovanne. Die Beschränkung ist für die public API bestätigt, aber nicht zwingend für die inoffizielle! -
Hab grad einen interessanten Eintrag bei der HA integration von tolwi gesehen:
"
from FB
client_id limits for MQTT connections
If you are using MQTT to connect to the API be aware that only 10 unique client IDs are allowed per day.
As such, it is suggested that you choose a static client_id for your application or integration to use consistently.
If your code generates a unique client_id (as mine did) for each connection,
you can exceed this limit very quickly when testing or debugging code.
"Keine Ahnung wie offiziell das verkündet wurde, aber immerhin gibt es hier einen Hinweis auf die Begrenzung auf 10 client IDs pro Tag. Bestätigt ein wenig meine oben geäußerten Ideen.
EDIT:
Unten gibt es eine Rückmeldung von @giovanne. Die Beschränkung ist für die public API bestätigt, aber nicht zwingend für die inoffizielle!Hallo,
bei mir läuft die Datenübertragung von Ecoflow auch nur noch wenn ich zuvor die offizielle App benutzt habe.
Hat jemand es geschafft, sich mit der neuen offiziellen API einzuloggen?
https://developer-eu.ecoflow.com/us/document/generalInfoVielleicht werden die Daten an diesen Adapter wieder gesendet, wenn man parallel alle paar Minuten diese Verbindung ab abfrägt?
Leider bekomme ich es selbst nicht hin. Hat jemand ein JS-Script, wie ich mich mit meinen eigenen Zugangsdaten in der neuen API einloggen kann und z.B. einen einfachen Wert abfragen kann?
Die Anleitung sieht ja übersichtlich aus, und das vorhandene Beispiel konnte ich sogar korrekt verschlüsseln. Mit meinen eigenen Zugangsdaten kam ich aber leider nicht weiter.
-
Hab grad einen interessanten Eintrag bei der HA integration von tolwi gesehen:
"
from FB
client_id limits for MQTT connections
If you are using MQTT to connect to the API be aware that only 10 unique client IDs are allowed per day.
As such, it is suggested that you choose a static client_id for your application or integration to use consistently.
If your code generates a unique client_id (as mine did) for each connection,
you can exceed this limit very quickly when testing or debugging code.
"Keine Ahnung wie offiziell das verkündet wurde, aber immerhin gibt es hier einen Hinweis auf die Begrenzung auf 10 client IDs pro Tag. Bestätigt ein wenig meine oben geäußerten Ideen.
EDIT:
Unten gibt es eine Rückmeldung von @giovanne. Die Beschränkung ist für die public API bestätigt, aber nicht zwingend für die inoffizielle!@foxthefox ,
zur Info zu dem Thema... ist mir aber bisher nur für die offizielle API (Developer API) bekannt und ich bin beim Testen dort ab und an reingelaufen -
@foxthefox ,
zur Info zu dem Thema... ist mir aber bisher nur für die offizielle API (Developer API) bekannt und ich bin beim Testen dort ab und an reingelaufenIch habe nur eine Delta Pro und den PowerStream im Skript und es läuft immer noch...noch...
-
Bei mir läuft die Regelung auch wieder seit letzter Nacht gut. Die Nacht zuvor hat nicht funktioniert. Jetzt scheint hoffentlich alles wieder wie gewohnt.
@ralf77 Was mir auch noch immer wieder auffällt, ist dass die Regelung durch das Skript, wenn die Smartplug ON sind, also den Hauptteil des Stroms steuern, mehr oder weniger gut funktioniert.
Kann sein, es regelt einige Stunden auf NULL, wenn es aber einmal "entgleist", dann nehm ich die Plugs auf OFF und dann regelt es augenblicklich wieder in den Bereich um NULL herum. -
@ralf77 Was mir auch noch immer wieder auffällt, ist dass die Regelung durch das Skript, wenn die Smartplug ON sind, also den Hauptteil des Stroms steuern, mehr oder weniger gut funktioniert.
Kann sein, es regelt einige Stunden auf NULL, wenn es aber einmal "entgleist", dann nehm ich die Plugs auf OFF und dann regelt es augenblicklich wieder in den Bereich um NULL herum.
Support us
482
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge