Modul für Ecoflow-Komponenten (über HTTP-REST)

[dergolem]

Hallo Markus,

so habe mich gerade mal hingesetzt und getestet. Hat alles funktioniert.

Gruß Denis

[KölnSolar]

Prima, danke. Dann kann es jetzt jeder einsetzen.

Und nun noch die versprochene Dokumentation meiner Änderungen.

Erst einmal vielen Dank für das sicherlich seeeeeehr aufwändige Entwickeln des Moduls für die Ecoflow-Produkte auf Basis der von Ecoflow bereitgestellten API an Neolux.

Nun kurz zu meinen Beweggründen das Modul anzupassen:
Meine Delta2 weist/wies einen Defekt auf. Um diesen nachzuweisen ist das Verständnis und dann die Aufzeichnung der Notwendigen aus der der schier unendlichen Zahl der Readings nötig.
In der ursprünglichen Fassung war dies nicht möglich, weil:
- beim Abruf von Daten der timestamp für JEDES Datum, welches in der Cloud vorliegt, verändert wurde. Tatsächlich aber nur wenige Daten verändert werden
- Selbst ausgesetzter tatsächlicher Betrieb des physischen devices oder Störungen der Übertragung an die Ecoflow-Cloud konnten nicht erkannt werden, weil das Modul immer die in der Cloud vorhandenen Daten nach FHEM übertrug
- ein set änderte das betroffene Reading, obwohl das set vielleicht gar nicht erfolgreich war(kann u.U. vorkommen, wenn z.B. das device gar nicht mit der Cloud verbunden ist)

Das Modul nutzt nun
- konsequent update-if-changed, so dass nur veränderte readings ein event auslösen.
- das von mir selbst geforderte Attribut  "no_data_20_134", was ebenfalls zu mehr Übersichtlichkeit führen sollte, habe ich entfernt, da nun mit dem Standard-Attribut suppressreadings der vergleichbare Effekt erreicht wird
- eine für mich nicht nachvollziehbare Anpassung zu den Standard-Attributen "event-on-change" habe ich entfernt.
  Die Standard event-on-.... Attribute liefern nun wieder zu erwartende Ergebnisse
 
Die Umsetzung jedes einzelnen MÖGLICHEN device-spezifischen Datums durch get, führte zu einer sehr unübersichtlichen Anzahl von gets, obwohl diese Daten auch mit einem get "all" geliefert werden.
Folglich macht deren Berücksichtigung wenig Sinn. Ich habe diese vollständig entfernt und durch einen einzelnen Abruf "get update" ersetzt, sofern jemand Bedarf an der Aktualisierung der Daten außerhalb des zyklischen automatischen Abrufs haben sollte.
device spezifische gets sind somit nur noch für Daten realisiert, die nicht mit get update abrufbar sind. Nach aktuellen Erkenntnissen betrifft dies nur historische Daten bei PowerOcean und Stream xyz Modellen.

Im Ergebnis ist nun viel leichter ersichtlich, welche Daten sich tatsächlich im Betrieb verändern, Loggingdaten sind deutlich reduziert.

Ebenfalls für Intransparenz sorgte die Darstellung von Bildschirmausgaben nach set/get.
Tatsächlich ist es so, dass das Modul richtigerweise Non-Blocking-Get einsetzt.
Das bedeutet im wesentlichen, dass das Modul nicht blockiert, nur weil Antwortzeiten deren Server unbefriedigend sind.
Es bedeutet nun einmal aber auch, dass eine erfolgreiche Verarbeitung der set/get Befehle nicht im Augenblick des Senden ersichtlich ist, sondern erst sobald auch tatsächlich eine Antwort aus der Cloud erfolgt ist.
In der vorherigen Fassung des Moduls wurden also lediglich "alte" Informationen angezeigt. Die "Wahrheit" war erst nach einem Empfang von Daten in den readings ersichtlich, die sich u.U. flip-/flop-mäßig änderten.
Ich habe daher entweder auf Anzeigen verzichtet oder weise in den Bildschirmmeldungen zumindest darauf hin, dass "veraltete" Daten angezeigt werden.

Die device- u. readingspezifischen "adjustments", halte ich für eine sehr sinnvolle Idee von Neolux. Ich habe dazu kleinere Anpassungen vorgenommen:
- device-spezifische Anpassung der einzelnen readings-Werte, sofern modulintern zum device konfiguriert(war bereits so implementiert)
- Zeitangaben sind scheinbar immer in Sekunden. Enthält der reading-Name das Literal "time" wird automatisch in hh:mm umgerechnet
- Internal HardwareVersion entfernt; nun lesbar über die 6 hwVersion_x readings

Weitere Kleingkeiten, die ich geändert habe:
 - kein set für AccessKey, da fehleranfällig; bei Änderung des AccessKey besser defmod ausführen
 - set "SerialNo", "deleteReadings" entfernt
 - einiges im Code zur Verbesserung der Lesbarkeit geändert, reduziert

Hier noch meine Beispiele für den sinnvollen Einsatz der Standard-Attribute.

Für eine Delta2:

Code Auswählen Erweitern

attr Delta2_AC event-on-change-reading .*
attr Delta2_AC event-min-interval data_pd.inputW.*:160,data_pd.out.*W.*:160,data_pd.usb.W.*:160,data_pd.watts.*:160
attr Delta2_AC timestamp-on-change-reading .*bewirkt, dass nur für Daten, die wirklich aktualisiert wurden ein event erzeugt wird. Der readings-timestamp ändert sich auch nur bei Änderung. Nach einiger Laufzeit erkennt man die wenigen wirklich genutzten readings.
Ich habe sogar manuell die timestamps der readings OHNE update in meinem FHEM so angepasst, dass ich leicht an den timestamps erkennen kann, ob und wann sich deren Wert tatsächlich geändert hat.(2025-12-31 23:59:59)
Für durchgängige Plots die Ausnahme mit event-min-interval, dass auch ohne Änderung ein update erfolgt

Für einen Powerstream:

Code Auswählen Erweitern

attr Powerstream_AC event-on-change-reading .*
attr Powerstream_AC suppressReading data_20_134.*
attr Powerstream_AC timestamp-on-change-reading .*Vergleichbar den Attributen zur Delta2. Zusätzlich die Unterdrückung der unsäglichen time-schedule-Readings.

Sicherlich habe ich noch etwas vergessen, aber so ist das leider bei umfangreichen Änderungen.

Bedenkt, dass Ihr nach Einspielen in Euer FHEM ein "reload 98_Ecoflow" machen müsst und mindestens das Attribut ecInterval löschen und ggfs. das Attribut interval anlegen müsst.
Wenn das nicht klappt, müsst Ihr das device neu anlegen. Vorsicht: Holt Euch vorher den SecretKey, da dieser beim Löschen des devices auch aus der Datei gelöscht und wieder neu eingegeben werden muss.

Und nun bin ich auf Euer Feedback gespannt.

Sicherlich werden noch die ein oder andere Anpassung am Modul notwendig, aber in absehbarer Zeit würde ich es dann offiziell mit automatischer Verteilung machen.

Have fun
Markus

[Damian]

Ich habe einen API-Zugang zum Ecoflow (Stream ac pro) beantragt. Dazu habe ich eine Frage zum aktuellen Modul. Erfolgt die Kommunikation über das Modul mit dem Ecoflow über das lokal Netz oder geht die Kommunikation über's Internet wie bei der App?

[dergolem]

Hallo,

die Kommunikation erfolgt über das Internet wie Bei der App. Eine locale Verbindung ist leider noch nicht möglich.

[KölnSolar]

Das Modul baut auf der API von Ecoflow mit Zugriff auf deren Cloud auf.

Der MQTT-Zugriff funktioniert(bin mir gerade nicht zu 100% sicher) ohne Cloud. Allerdings stellt das device das Senden "irgendwann"(muss noch detaillierter analysiert werden) wieder ein und ein Anstoß über die Äpp ist notwendig.

[Damian]

Das Modul baut auf der API von Ecoflow mit Zugriff auf deren Cloud auf.

Der MQTT-Zugriff funktioniert(bin mir gerade nicht zu 100% sicher) ohne Cloud. Allerdings stellt das device das Senden "irgendwann"(muss noch detaillierter analysiert werden) wieder ein und ein Anstoß über die Äpp ist notwendig.

Ok. Also ganz cloudfrei geht es wohl erst mal nicht. Die Nulleinspeisung von ecoflow funktioniert eigentlich recht gut. Allerdings frage ich mich, wer die Regelung überhaupt übernimmt, ich hoffe nicht komplett die Cloud. Alleine die Tatsache, dass der Zähler bei mir über den Tibber-Puls mit einem Tibber-Account bei ecoflow zum Regeln benutzt wird, macht mir Bauchschmerzen.

[KölnSolar]

Kannst es ja mal mit MQTT probieren https://forum.fhem.de/index.php?topic=133322.msg1343585#msg1343585

[MasterRay]

Das Modul baut auf der API von Ecoflow mit Zugriff auf deren Cloud auf.

Der MQTT-Zugriff funktioniert(bin mir gerade nicht zu 100% sicher) ohne Cloud. Allerdings stellt das device das Senden "irgendwann"(muss noch detaillierter analysiert werden) wieder ein und ein Anstoß über die Äpp ist notwendig.

... nun, die URL, mit der man am MQTT-Server abonniert lautet ja 'mqtt.ecoflow.com'. Das sieht mir nicht "lokal" aus. Zudem müssten die Geräte, wenn es ohne Cloud gehen sollte, über MQTT-Server verfügen. Sie haben aber nach meiner Erfahrung MQTT-Clients.

Grüße aus dem (gerade) sonnigen SüdWesten

[Damian]

Vermutlich werde ich, sobald der API-key kommt, nur die aktuelle Kapazität und die aktuelle Einspeisung/Bezug auslesen, um es in FHEM anzuzeigen. Ein Shelly 3EM, den man statt eines Tibber-Puls angeben kann, würde vermutlich im Gegensatz zum Tibber-Puls lokal ausgelesen werden, aber den müsste ich erstmal anschaffen.

[KölnSolar]

nun, die URL, mit der man am MQTT-Server abonniert lautet ja 'mqtt.ecoflow.com'. Das sieht mir nicht "lokal" aus.

Du hast ja sows von recht. 

[phantom]

für Anwender von STREAM ULTRA & STREAM ACPRO habe ich 2 kleine Korrekturen zur Ansteuerung der Relais der Ausgänge:

- beim STREAM UP muss die Zeile für das 2. Relais so lauten:
    "cfgRelay3Onoff" => { "cmdId" => 17, "cmdFunc" => 254, "dirDest" => 1, "dirSrc" => 1, "needAck" => "true", "dest" => 2, "params.cfgRelay3Onoff" => "a[2]"},

- beim STREAM AC gibts auch 2 Relais, daher sollte die gleichen Sets und SetCmdCodes drin sein:

Code Auswählen Erweitern

        "STREAM AC" => {
                "Adjustments" => {},
                "Gets" => {
                        "SolarGeneratedPower" => "",
                        "EnergyIndependence" => "",
                        "EnvironmentalImpact" => "",
                        "TotalSolarEnergySavings" => "",
                        "ElectricityConsumption" => "",
                        "Grid" => "",
                        "BatteryChargingDischargingPower" => ""
                },
                "Sets" => {
                        "cfgRelay2Onoff" => ":true,false",
                        "cfgRelay3Onoff" => ":true,false",
                        "cfgBackupReverseSoc"=> ":slider,3,1,95",
                        "cfgEnergyStrategyOperateMode.operateSelfPoweredOpen" => ":true",
                        "cfgEnergyStrategyOperateMode.operateIntelligentScheduleModeOpen" => ":true",
                        "cfgFeedGridMode" => ":1,2"
                },
                "GetCmdCodes" => {
                        "SolarGeneratedPower" =>                { "params.beginTime" => "a[1] a[2]" , "params.endTime" => "a[3] a[4]", "params.code" => "BK621-App-HOME-SOLAR-ENERGY-FLOW-solor-line-NOTDISTINGUISH-MASTER_DATA" },
                        "EnergyIndependence"  =>                { "params.beginTime" => "a[1] a[2]" , "params.endTime" => "a[3] a[4]", "params.code" => "BK621-App-HOME-INDEPENDENCE-PERCENT-FLOW-indep-progress_bar-NOTDISTINGUISH-MASTER_DATA" },
                        "EnvironmentalImpact" =>                { "params.beginTime" => "a[1] a[2]" , "params.endTime" => "a[3] a[4]", "params.code" => "BK621-App-HOME-CO2-WEIGHT-FLOW-impact-progress_arc-NOTDISTINGUISH-MASTER_DATA" },
                        "TotalSolarEnergySavings" =>            { "params.beginTime" => "a[1] a[2]" , "params.endTime" => "a[3] a[4]", "params.code" => "BK621-App-HOME-SAVING-CURRENCY-FLOW-earnings-progress_arc-NOTDISTINGUISH-MASTER_DATA" },
                        "ElectricityConsumption" =>             { "params.beginTime" => "a[1] a[2]" , "params.endTime" => "a[3] a[4]", "params.code" => "BK621-App-HOME-LOAD-ENERGY-FLOW-consumption-prop_arc-NOTDISTINGUISH-MASTER_DATA" },
                        "Grid" =>                               { "params.beginTime" => "a[1] a[2]" , "params.endTime" => "a[3] a[4]", "params.code" => "BK621-App-HOME-GRID-ENERGY-FLOW-grid_prop_bar-NOTDISTINGUISH-MASTER_DATA"},
                        "BatteryChargingDischargingPower" =>    { "params.beginTime" => "a[1] a[2]" , "params.endTime" => "a[3] a[4]", "params.code" => "BK621-App-HOME-SOC-ENERGY-FLOW-battery-prop_bar-NOTDISTINGUISH-MASTER_DATA"},
                },
                "SetCmdCodes" => {
                        "cfgRelay2Onoff" => { "cmdId" => 17, "cmdFunc" => 254, "dirDest" => 1, "dirSrc" => 1, "needAck" => "true", "dest" => 2, "params.cfgRelay2Onoff" => "a[2]"},
                        "cfgRelay3Onoff" => { "cmdId" => 17, "cmdFunc" => 254, "dirDest" => 1, "dirSrc" => 1, "needAck" => "true", "dest" => 2, "params.cfgRelay3Onoff" => "a[2]"},
                        "cfgBackupReverseSoc" => { "cmdId" => 17, "cmdFunc" => 254, "dirDest" => 1, "dirSrc" => 1, "dest" => 2, "needAck" => "true", "params.cfgBackupReverseSoc" => "a[2]" },
                        "cfgEnergyStrategyOperateMode.operateSelfPoweredOpen" => { "cmdId" => 17, "cmdFunc" => 254, "dirDest" => 1, "dirSrc" => 1, "dest" => 2, "needAck" => "true", "params.cfgEnergyStrategyOperateMode.operateSelfPoweredOpen" => "a[2]"},
                        "cfgEnergyStrategyOperateMode.operateIntelligentScheduleModeOpen" => { "cmdId" => 17, "cmdFunc" => 254, "dirDest" => 1, "dirSrc" => 1, "dest" => 2, "needAck" => "true", "params.cfgEnergyStrategyOperateMode.operateIntelligentScheduleModeOpen" => "a[2]"},
                        "cfgFeedGridMode" => { "cmdId" => 17, "cmdFunc" => 254, "dirDest" => 1, "dirSrc" => 1, "dest" => 2, "needAck" => "true", "params.cfgFeedGridMode" => "a[2]"}
                }
 

[KölnSolar]

da fehlte noch die abschließende Geschweifte. 

Ich habe es eingebaut. Bitte testen.

[KölnSolar]

Guten Morgen,
scheinbar gibt es seit kurz nach 6:00 Probleme bei ecoflow. Die domain ist per ping erreichbar, es werden aber keine Daten übertragen.

Die mqtt-domain mqtt-e.ecoflow.com lässt sich nicht anpingen und die Äpp liefert jüngere und "live"-Daten.

Nur bei mir so oder allgemeines ecoflow-Problem ?

Grüße Markus

[Damian]

Guten Morgen,
scheinbar gibt es seit kurz nach 6:00 Probleme bei ecoflow. Die domain ist per ping erreichbar, es werden aber keine Daten übertragen.

Die mqtt-domain mqtt-e.ecoflow.com lässt sich nicht anpingen und die Äpp liefert jüngere und "live"-Daten.

Nur bei mir so oder allgemeines ecoflow-Problem ?

Grüße Markus

Ich habe keine Probleme mit der Kommunikation über die App.

[rubberduck67]

Seit 7:20Uhr kommen Daten aus der API , aber ich überwache das nicht. In der App auch früher

Gruß Sven