ecoflow-connector-Script zur dynamischen Leistungsanpassung
-
@est58 sagte in ecoflow-connector-Script zur dynamischen Leistungsanpassung:
Heute morgen die Antwort via EcoFlow Offizieller Club - Deutsch (Facebook)
Our tech team told me that we made a restrictions for the port to disable the backstage data
https://developer-eu.ecoflow.com/us/ please use our official platform for the API purpose
Was immer das nun bedeutet, bei mir läuft das Skript seit 14 Stunden wie vor dem Urlaub. Also seit ca. 16 Uhr gestern, davor gab es immer wieder Hänger, für die ich die App öffnen musste.
Und mit der Webadress kann ich Null anfangen, bin kein Programmier, kein Developer. War nur ein Skript-User und wenn das Problem wieder kommt, steh ich genauso blöd da wie diese Woche mit Skriptproblemen.Kannst du den FB Beitrag mal verlinken
@mikerow Außerdem hab ich das im Skript von Markus nun gelesen:
Und da es nun seit ca. 16 Uhr gestern normal läuft wie auch vor meinem Urlaub, könnte das doch ein anderes temporäres Problem gewesen sein !? (Hoffentlich)
Denn wäre dies von EF Technik vorgeschobene Restriktion permanent, würde ja nix mehr laufen.
Vielleicht beschrieben sie auch nur das, was schon immer war und deswegen im Skript mit Verbindungsneuaufbau nach spätestens 5 Minuten "behoben" wird.Bin nur Skript-Laie
-
@bernd_65 Bei mir hat das Skript bis vor ca. 7-9 Tagen 3PS, 2DP/ZA und einen ZA/mit PS) gut verwaltet.
Nun läuft es wie schon gesagt, nicht mehr korrekt und auch heute werden die Datenpunkte nur aktualisiert wenn die APP offen und aktiv ist.
So bleibt für mich sowohl Skript als auch Energiefluss-erweitert komplett unbrauchbar und die Gesamtinvestition in Raspberry, Lesekopf und die Zeit für alles ist für die Katz.
Und es scheint keinen weiteres zu stören, auch in der Ecoflow-Gruppe gibt es einige, die das betrifft, doch es scheint, ich bin der einzige, der das an den EF-Support weitergeleitet hat.
Das wird dann dort sicher so aufgefasst, dass sie da erst mal nichts machen müssen, wenn es nur einen stört.
Zum glück hab ich alle 8 Smartplugs behalten und lasse das Skript eben ausgeschaltet und kann dann mit manueller Grundlast einigermassen selbst regeln.
Aber das war ja nicht Sinn der Sache.
Leider kann ich nicht selbst Skript usw. und die Tipps weiter oben mit alternativen Anmeldung am Mqtt-Broker funktioniert einer nicht, weil die Zugangsdaten nur zu einer Fehlermeldung führen.@est58 hi Mister Ed - bei mir läuft das Skript auch wieder normal (ohne app). Scheinbar ist das regional ein Thema oder nach Komplexität des Setups. Ich hatte tatsächlich 1 Tag ein Problem, jetzt ist wieder alles auf normal zurück gekehrt. Ich vermute du hast schon die Hardware mal aus- und wieder angesteckt und einen Reset versucht? Hast du als Alternative mal den EF MQTT Adapter probiert, auf den weiter oben hingewiesen wurde?
-
@est58 hi Mister Ed - bei mir läuft das Skript auch wieder normal (ohne app). Scheinbar ist das regional ein Thema oder nach Komplexität des Setups. Ich hatte tatsächlich 1 Tag ein Problem, jetzt ist wieder alles auf normal zurück gekehrt. Ich vermute du hast schon die Hardware mal aus- und wieder angesteckt und einen Reset versucht? Hast du als Alternative mal den EF MQTT Adapter probiert, auf den weiter oben hingewiesen wurde?
@accu Ja, nach dem Urlaub hab ich das komplette Haus OFF und ON gestellt.
Aber erst seit gestern 16h gings dann (von alleine).Weiß nicht, ob es das war was Du meinst, ich hab ein Skript versucht, das zum EF MQTT Broker verbinden soll, aber das hat nicht funktioniert. Weiß auch nicht, ob es an der Syntax der Eingabe von Email und PW lag.
Und das über die Website - keinen Plan, was ich dann mit den kreierten MQTT machen könnte, wie gesagt, ich kann kein Skript programmieren nur anpassen und nutzen
mit website https://energychain.github.io/site_ecoflow_mqtt_credentials/
ecoflow Zugangsdaten eingeben und dann den Button "create login data" drücken. Danach werden die 4 Datenfelder für MQTT befüllt. -
@accu Ja, nach dem Urlaub hab ich das komplette Haus OFF und ON gestellt.
Aber erst seit gestern 16h gings dann (von alleine).Weiß nicht, ob es das war was Du meinst, ich hab ein Skript versucht, das zum EF MQTT Broker verbinden soll, aber das hat nicht funktioniert. Weiß auch nicht, ob es an der Syntax der Eingabe von Email und PW lag.
Und das über die Website - keinen Plan, was ich dann mit den kreierten MQTT machen könnte, wie gesagt, ich kann kein Skript programmieren nur anpassen und nutzen
mit website https://energychain.github.io/site_ecoflow_mqtt_credentials/
ecoflow Zugangsdaten eingeben und dann den Button "create login data" drücken. Danach werden die 4 Datenfelder für MQTT befüllt.@est58
javascript.0 18:25:06.495 info script.js.common.Ecoflow_Shelly: Verbunden mit dem Ecoflow MQTT-Broker
javascript.0 18:26:06.553 info script.js.common.Ecoflow_Shelly: Verbunden mit dem Ecoflow MQTT-Broker
javascript.0 18:27:06.840 info script.js.common.Ecoflow_Shelly: Verbunden mit dem Ecoflow MQTT-Broker
javascript.0 18:28:06.688 info script.js.common.Ecoflow_Shelly: Verbunden mit dem Ecoflow MQTT-BrokerIch habe auch Probleme mit dem Script. Seit ein paar Tagen trennt sich im Minutentakt die Verbindung zu Ecoflow. Ich teste täglich, ob das Skript wieder funktioniert, leider erfolglos. Ich nutze Aktuell die Einspeisung direkt über Ecoflos / Shelly mit den bekannten Nachteilen...
-
Von der Facebook Gruppe
Für diejenigen, die keinen offiziellen AccessKey und SecretKey erhalten haben: Wenn Ihre Integration auf Code aus Quellen basiert, die keine offiziellen Zugangsdaten erfordern, wie zum Beispiel GitHub, seien Sie sich der erheblichen Risiken bewusst. Da unsere Nutzerbasis weiter wächst, könnte die zusätzliche Belastung unserer Server weitere Maßnahmen gegen unautorisierte Clients erforderlich machen. Wir erkennen an, dass dies Unannehmlichkeiten verursachen kann, und entschuldigen uns im Voraus für etwaige Störungen, die dadurch entstehen können. Ab Anfang August wurden Verbindungen von unautorisierten Clients eingeschränkt. Insbesondere werden MQTT-Clients, die das Verhalten von Apps nachahmen, nicht mehr als gültige App-Clients anerkannt. Dadurch werden Datenaktualisierungen nicht mehr stattfinden, wenn die EcoFlow-App nicht aktiv läuft. Wir empfehlen dringend, sich als offizieller Entwickler zu registrieren und einen AccessKey und SecretKey zu beantragen. Die EcoFlow API unterstützt derzeit Geräte wie DELTA 2, DELTA 2 Max, DELTA Pro, SHP, PowerOcean und PowerStream. Bitte konsultieren Sie unsere Dokumentation für die aktuellste Liste der unterstützten Geräte, da wir unser Angebot kontinuierlich erweitern.
-
Von der Facebook Gruppe
Für diejenigen, die keinen offiziellen AccessKey und SecretKey erhalten haben: Wenn Ihre Integration auf Code aus Quellen basiert, die keine offiziellen Zugangsdaten erfordern, wie zum Beispiel GitHub, seien Sie sich der erheblichen Risiken bewusst. Da unsere Nutzerbasis weiter wächst, könnte die zusätzliche Belastung unserer Server weitere Maßnahmen gegen unautorisierte Clients erforderlich machen. Wir erkennen an, dass dies Unannehmlichkeiten verursachen kann, und entschuldigen uns im Voraus für etwaige Störungen, die dadurch entstehen können. Ab Anfang August wurden Verbindungen von unautorisierten Clients eingeschränkt. Insbesondere werden MQTT-Clients, die das Verhalten von Apps nachahmen, nicht mehr als gültige App-Clients anerkannt. Dadurch werden Datenaktualisierungen nicht mehr stattfinden, wenn die EcoFlow-App nicht aktiv läuft. Wir empfehlen dringend, sich als offizieller Entwickler zu registrieren und einen AccessKey und SecretKey zu beantragen. Die EcoFlow API unterstützt derzeit Geräte wie DELTA 2, DELTA 2 Max, DELTA Pro, SHP, PowerOcean und PowerStream. Bitte konsultieren Sie unsere Dokumentation für die aktuellste Liste der unterstützten Geräte, da wir unser Angebot kontinuierlich erweitern.
@milchbeck hast du mal einen Link zu dem Beitrag?
-
Von der Facebook Gruppe
Für diejenigen, die keinen offiziellen AccessKey und SecretKey erhalten haben: Wenn Ihre Integration auf Code aus Quellen basiert, die keine offiziellen Zugangsdaten erfordern, wie zum Beispiel GitHub, seien Sie sich der erheblichen Risiken bewusst. Da unsere Nutzerbasis weiter wächst, könnte die zusätzliche Belastung unserer Server weitere Maßnahmen gegen unautorisierte Clients erforderlich machen. Wir erkennen an, dass dies Unannehmlichkeiten verursachen kann, und entschuldigen uns im Voraus für etwaige Störungen, die dadurch entstehen können. Ab Anfang August wurden Verbindungen von unautorisierten Clients eingeschränkt. Insbesondere werden MQTT-Clients, die das Verhalten von Apps nachahmen, nicht mehr als gültige App-Clients anerkannt. Dadurch werden Datenaktualisierungen nicht mehr stattfinden, wenn die EcoFlow-App nicht aktiv läuft. Wir empfehlen dringend, sich als offizieller Entwickler zu registrieren und einen AccessKey und SecretKey zu beantragen. Die EcoFlow API unterstützt derzeit Geräte wie DELTA 2, DELTA 2 Max, DELTA Pro, SHP, PowerOcean und PowerStream. Bitte konsultieren Sie unsere Dokumentation für die aktuellste Liste der unterstützten Geräte, da wir unser Angebot kontinuierlich erweitern.
@milchbeck
Man sollte also nicht zu viel Anfragen an den Server schicken, was die App eventuell nicht macht. Auch mehrere Parallelinstanzen bzw. für jedes Gerät eine eigene dürfte nicht im Sinne sein. Ansonsten dürfte sich EF aber nicht beschweren, das man MQTT abonniert wie es auch eine App tut. Deren Server hätten direkt weniger Stress wenn es eine lokale API gäbe 😉 -
@milchbeck
Man sollte also nicht zu viel Anfragen an den Server schicken, was die App eventuell nicht macht. Auch mehrere Parallelinstanzen bzw. für jedes Gerät eine eigene dürfte nicht im Sinne sein. Ansonsten dürfte sich EF aber nicht beschweren, das man MQTT abonniert wie es auch eine App tut. Deren Server hätten direkt weniger Stress wenn es eine lokale API gäbe 😉 -
bei mir geht nichts mehr! kejne verbindung zu den geräten möglich, alles offline!
hat das noch jemand?
-
Von der Facebook Gruppe
Für diejenigen, die keinen offiziellen AccessKey und SecretKey erhalten haben: Wenn Ihre Integration auf Code aus Quellen basiert, die keine offiziellen Zugangsdaten erfordern, wie zum Beispiel GitHub, seien Sie sich der erheblichen Risiken bewusst. Da unsere Nutzerbasis weiter wächst, könnte die zusätzliche Belastung unserer Server weitere Maßnahmen gegen unautorisierte Clients erforderlich machen. Wir erkennen an, dass dies Unannehmlichkeiten verursachen kann, und entschuldigen uns im Voraus für etwaige Störungen, die dadurch entstehen können. Ab Anfang August wurden Verbindungen von unautorisierten Clients eingeschränkt. Insbesondere werden MQTT-Clients, die das Verhalten von Apps nachahmen, nicht mehr als gültige App-Clients anerkannt. Dadurch werden Datenaktualisierungen nicht mehr stattfinden, wenn die EcoFlow-App nicht aktiv läuft. Wir empfehlen dringend, sich als offizieller Entwickler zu registrieren und einen AccessKey und SecretKey zu beantragen. Die EcoFlow API unterstützt derzeit Geräte wie DELTA 2, DELTA 2 Max, DELTA Pro, SHP, PowerOcean und PowerStream. Bitte konsultieren Sie unsere Dokumentation für die aktuellste Liste der unterstützten Geräte, da wir unser Angebot kontinuierlich erweitern.
Hab nochmal über die Erkennung von unautorisierten App-clients nachgedacht. Aus meiner Sicht ist es nicht ganz so einfach zu differenzieren, ob es um eine echte APP geht oder ein selbstgeschriebener Client ist.
Was allerdings nachvollziehbar ist, sind die "angemeldeten" Geräte.
Zum einen wieviele Geräte parallel aktiv sind und zum anderen wieviele access credentials unter dem gleichen EF login geholt oder in Benutzung sind.
Zum ersteren ist eventuell eine Einschränkung von einem selbst notwendig (mehrere Geräte + script + iob.adapter + ...)
Zum letzteren ist darauf zu achten wann und unter welchen Umständen neue access creditials geholt werden.
Im Fall vom adapter werden die einmal geholten credentials abgespeichert und erst bei Neuinstallation wäre man in der Not (auch gibt es die Möglichkeit einmal vorhandene credentials händisch einzugeben, ohne den Automatismus zu benutzen).
Im Fall vom script bin ich mir nicht sicher ob es persistant gespeichert ist, oder ob jeder Neustart des scriptes auch neue credentials holt.
Das könnte mal überprüft werden um zumindest eine virtuelle Vermehrung von Andriod und IOS Geräten zu vermeiden. -
Hab nochmal über die Erkennung von unautorisierten App-clients nachgedacht. Aus meiner Sicht ist es nicht ganz so einfach zu differenzieren, ob es um eine echte APP geht oder ein selbstgeschriebener Client ist.
Was allerdings nachvollziehbar ist, sind die "angemeldeten" Geräte.
Zum einen wieviele Geräte parallel aktiv sind und zum anderen wieviele access credentials unter dem gleichen EF login geholt oder in Benutzung sind.
Zum ersteren ist eventuell eine Einschränkung von einem selbst notwendig (mehrere Geräte + script + iob.adapter + ...)
Zum letzteren ist darauf zu achten wann und unter welchen Umständen neue access creditials geholt werden.
Im Fall vom adapter werden die einmal geholten credentials abgespeichert und erst bei Neuinstallation wäre man in der Not (auch gibt es die Möglichkeit einmal vorhandene credentials händisch einzugeben, ohne den Automatismus zu benutzen).
Im Fall vom script bin ich mir nicht sicher ob es persistant gespeichert ist, oder ob jeder Neustart des scriptes auch neue credentials holt.
Das könnte mal überprüft werden um zumindest eine virtuelle Vermehrung von Andriod und IOS Geräten zu vermeiden.Zur Info für Euch, bei mir läuft das script seit Vorgestern auch nicht mehr. Es kommen keine Daten mehr von D2M beim iobroker an. Habe zwei PS wobei eine an einer D2M mit Zusatzspeicher (4KWh) dran hängen. Habe auch ein shelly device mit dem ich bisher über iobroker geregelt und daten aufgenommen habe, funktionierte auch über die App. Für mich macht es keinen Sinn mehr EcoFlow weiter zu betreiben oder zu empfehlen wenn die App Änderung bzw die Freischaltung der internen Variablen nicht wieder korrigiert werden. Ich werde dann komplett auf ein anderes System umstellen und dies auch allen meinen Bekannten raten. Schade EF fing einmal so gut an.
-
Zur Info für Euch, bei mir läuft das script seit Vorgestern auch nicht mehr. Es kommen keine Daten mehr von D2M beim iobroker an. Habe zwei PS wobei eine an einer D2M mit Zusatzspeicher (4KWh) dran hängen. Habe auch ein shelly device mit dem ich bisher über iobroker geregelt und daten aufgenommen habe, funktionierte auch über die App. Für mich macht es keinen Sinn mehr EcoFlow weiter zu betreiben oder zu empfehlen wenn die App Änderung bzw die Freischaltung der internen Variablen nicht wieder korrigiert werden. Ich werde dann komplett auf ein anderes System umstellen und dies auch allen meinen Bekannten raten. Schade EF fing einmal so gut an.
@andy-3 Starte mal die App. Bei mir bekommt das Skript immer direkt nach dem EF App öffnen wieder Daten (für kurze Zeit). Das ist natürlich ein inakzeptabler Zustand seitens EF.
-
@andy-3 Starte mal die App. Bei mir bekommt das Skript immer direkt nach dem EF App öffnen wieder Daten (für kurze Zeit). Das ist natürlich ein inakzeptabler Zustand seitens EF.
keine Ahnung, ob die Einschränkungen für Daten regional sind. Oder regional gewechselt werden. Denn bei mir war es ja vor Tagen auch einige Tage lang am nerven.
Bei mir läuft es zur Zeit rund, aber vielleicht liegt es daran, dass ich wenn ich am PC sitze auf dem rechten Monitor immer eine Instanz in einem Android Simulator offen habe. Aber auch die letzten Nächte ist es durchgelaufen und da war sicher keine APP offen.
Doch auch in der App in der Sim muss ich hin- und wieder aktualisieren, aber das schon immer. Seit ich die App nutzeAchja, ich lass die 8 Smartplugs wieder aktiv mitlaufen, falls das Skript gemobbt wird von EF, dann übernehmen die wenigstens den zu regelnden Part und die Grundlast bleibt auf dem letzten Wert stehen, der oft passt. bin ich wach, kann ich den ja aktiv regeln.
-
keine Ahnung, ob die Einschränkungen für Daten regional sind. Oder regional gewechselt werden. Denn bei mir war es ja vor Tagen auch einige Tage lang am nerven.
Bei mir läuft es zur Zeit rund, aber vielleicht liegt es daran, dass ich wenn ich am PC sitze auf dem rechten Monitor immer eine Instanz in einem Android Simulator offen habe. Aber auch die letzten Nächte ist es durchgelaufen und da war sicher keine APP offen.
Doch auch in der App in der Sim muss ich hin- und wieder aktualisieren, aber das schon immer. Seit ich die App nutzeAchja, ich lass die 8 Smartplugs wieder aktiv mitlaufen, falls das Skript gemobbt wird von EF, dann übernehmen die wenigstens den zu regelnden Part und die Grundlast bleibt auf dem letzten Wert stehen, der oft passt. bin ich wach, kann ich den ja aktiv regeln.
@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 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 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.
Support us
534
Online32.7k
Users82.4k
Topics1.3m
Posts