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

[rubberduck67]

hier meine Aktuelle Version, ich habe jetzt auch die "Historischen" Daten für die STREAM Serie mit eingebaut, getestet nur für die MAX.
Damit können jetzt die Werte für beliebige Zeiträume gelesen werden. Wird unter
SolarGeneratedPower, EnergyIndependence, EnvironmentalImpact, TotalSolarEnergySavings, ElectricityConsumption, Grid und BatteryChargingDischargingPower ein Zeitraum im Form von

Dann muss ich wohl doch wieder das "Single read" einbauen. Bei powerstream und Delta machte das entweder keinen Sinn(es gibt keine historischen Daten) oder es wurde übersehen.

Ich guck es mir mal an....

Grüße
Markus

Danke!

[KölnSolar]

wie vermutet handelt es sich um eine "zusätzliche" URL "POST: /iot-open/sign/device/quota/data", die es für die Delta's, powerstream... nicht gibt.

Da werde ich den Code von Denis anschauen und übernehmen...

Edit: verstanden. Du hast Dich an 'JT303_Dashboard_Overview_Summary_Week' angelehnt, was ich mangels Nachvollziehbarkeit eliminiert hatte. Nochmal recherchiert mit Ergebnis, dass das historische Daten zur PowerOcean sind.
Da hatte ich die devicespezifischen gets schon eliminiert, da sie nicht darüber hinausgehen was ein "all data" auch überträgt und somit wenig Sinn machten(zumindest bei Delta, powerstream). Für die historischen Daten ist es aber etwas anderes. Die sind zusätzlich.
@Denis: Ist es bei den Stream Devices auch so, dass, abgesehen von den historischen Daten, sämtliche Daten der "Single gets" auch bei "all data" übertragen werden ? Ich würde dann nämlich die "getcmds" auf POST und einzig die historischen Daten umbauen

[dergolem]

Ja, es ist so, dass sämtliche Daten der "Single gets" auch bei "all data" Übertragen werden.

Gruß Denis

[Cineman]

Hallo! Ich bin neu in diesem Forum und hoffe auf Eure Hilfe, obwohl ich kein FHEM-Nutzer bin (aktuell versuche ich meine Einbindung über n8n und in mein laufendes Openhab-System).
Ich besitze eine Stream Ultra und Stream AC Pro. Bisher ist mir mit den Jinweisen in diesem Forum gelungen die GET-Befehle umzusetzen. Ein herzlichen Dank für diese Infos! Jedoch schaffe ich es keine PUT oder POST Befehle zu senden. Ist das schon jemandem gelungen? Und wenn ja, wie?

[KölnSolar]

https://forum.fhem.de/index.php?topic=140806.msg1358983#msg1358983

[KölnSolar]

Hallo Denis,

anbei meine 1. Version, die bitte nur Du zum Test, insbesondere der historischen Daten, einsetzt.

Es gibt nur noch modellspezifische gets für die historischen Daten. Aktuelle "Allgemeine" Daten außerhalb der zyklischen Abfrage erhält man durch ein get update.

Updates/Timestamps von readings sind deutlich verändert. Dazu schreibe ich ausführlich etwas, wenn der Test erfolgreich war.

Wichtige Änderungen bei den Attributen:
- ecInterval geändert zu interval
- Testmodel geändert in Model

Eine englische commandref gibt es auch. Natürlich nur sichtbar mit dem nächsten FHEM-Update.

Ich hoffe es klappt. Ich kann es ja nicht testen.

Grüße Markus

[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.