Neuer Adapter ecoflow-mqtt
-
Ich habe das gleiche Problem. Die Werte werden nur aktualisiert wenn die App auf dem Handy geöffnet ist.
-
@vmi sagte in Neuer Adapter ecoflow-mqtt:
@foxthefox wollte mal nachfragen ob Du schon weiter gekommen bist?
An ein paar kleinen Stellen ja, ansonsten fehlte grad die Zeit.
Werde aber demnächst eine neue Version einstellen. -
Die Energie Werte werden nicht mit den zyklischen Updates geschickt, allerdings macht der Adapter alle 5min ein "get" Anfrage und da kommen die Daten dann mit. In der App werden diese Daten nur zur vollen Stunde erneuert.
Es wurde schon öfter berichtet, daß Daten nur bei geöffneter App kommen.
Angeblich versucht EF hier die "fake"-Apps (wie diesen Adapter) weniger mit Daten zu versorgen.
Erkennungsmechanismen kenne ich nicht, habe da die Anzahl der "Apps" in Verdacht (jedes Holen und Benutzen von Credentials mit neuer APP-ID kann da ein Problem werden). Der Adapter benutzt aber nur einmalig den Mechanismus und speichert dies ab, so daß hier nichts passiert. Aber scripte und andere Instanzen (auch Homeassistant) kann hier zur Vermehrung der Anzahl beitragen. Eine ältere Version von HA-Integration hat für jedes Gerät ein eigenes Login :-(. -
Es gibt eine neue Version zum neuen Jahr.
- neu ist die vorläufige Implementierung für Batterieladegerät
- nicht unterstützte Geräte (Delta Serie3) können definiert werden und erzeugen log Einträge für weitere Auswertung
1.1.0 (npm)
- (foxthefox) added a preliminary version of alternator (no cmd, non final state names)
- (foxthefox) added a config possibility for unsupported devices for capturing the transmitted telegrams
- (foxthefox) #168 changed SHP2 masterIncreInfo.gridSta '0': 'Grid volt. not detected', '1': 'Grid OK'
- (foxthefox) #173 DPU added additional battery selection
- (foxthefox) #174 SHP2 added in ProtoTime the wattInfoChWatt, wattInfoAllHallWatt
- (foxthefox) #174 SHP2 added channel values of power and current in loadPower/loadCurrent including the sum of the values
- (foxthefox) #167 DELTA2/2Max pd.dsgPowerAC and pd.dsgPowerDC (type from 'power' to 'energy')
-
Zur Vollständigkeit hier nochmal die Info zu den neuen Versionen.
Hauptsächlich interne Dinge und SHP2.Aber auch der Alternator ist nach den ersten Erkenntnissen etwas verbessert.
1.1.3 (npm)
- (foxthefox) enhancements to alternator values
- (foxthefox) refactoring of protobuf handling/structure/component data
1.1.2 (npm)
- (bh1cqx) handle HA restart #PR193
- (foxthefox) initial state population of BPInfo2/3 to HA
- (foxthefox) jsonConfig enhancements
1.1.1 (npm)
- (foxthefox) changed code structure
- (foxthefox) initial state creation of BPInfo2/3 to HA
-
Es gibt eine neue Version:
- mehr Datenpunkte in pstream und beim plug
- massiv mehr Datenpunkte für powerocean
bitte Berichten, wenn es Auffälligkeiten gibt (Faktoren etc.)
1.2.0 (npm)
- (foxthefox) new values powerocean
- (foxthefox) new values powerstream
- (foxthefox) new values plug
- (foxthefox) enhancements on values for SHP2,DPU,alternator
-
@foxthefox Moin, ich erhalte seit kurzem diesen Fehler für meine DP.
State value to set for "ecoflow-mqtt.0.XXXXXXX.inverter_heartbeat.bmsReqChgVol" has value "5341.1" greater than max "65"
State value to set for "ecoflow-mqtt.0.XXXXXXXXXXXXX.inverter_heartbeat.geneWatt" has to be type "boolean" but received type "number"
tate value to set for "ecoflow-mqtt.0.XXXXXXXXXX.inverter_heartbeat.bmsReqChgVol" has to be type "boolean" but received type "number"
State value to set for "ecoflow-mqtt.0.XXXXXXXXXXXXXX.inverter_heartbeat.espTempsensor" has to be type "boolean" but received type "number"
Kannst du den Wert für kommende Versionen anpassen. Danke und Gruß Mike
-
@foxthefox für das SHP hat sich niochts geändert oder?
-
@mikerow
Mach ich, kommt mit 1.2.1 -
@vmi
Ist schon für 1.2.1 in Arbeit.
Ich musste erstmal großflächig etwas umstrukturieren, damit der Alternator richtig ausgewertet wird. -
neue Version 1.2.1 auf npm und git verfügbar
Die neuen Datenpunkte des PS sollten nun keine Fehler mer zeigen.
1.2.1 (npm)
- (foxthefox) corrections for pstream objects, some changed from string to number
- (foxthefox) new SHP time task config values
@vmi
War ne Menge an Arbeit, aber nun sollten die timeTasks sichtbar sein -
@foxthefox Vielen Dank. Für die kommende Version
State value to set for "ecoflow-mqtt.0.XXXXX.inverter_heartbeat.geneWatt" has to be type "boolean" but received type "number"
State value to set for "ecoflow-mqtt.0.XXXX.inverter_heartbeat.bmsReqChgVol" has to be type "boolean" but received type "number"
-
@mikerow
Bitte mal den Adapter stoppen und diese Datenpunkte löschen. Danach Adapter starten, dann werden sie neu angelegt. Die sollten schon behoben sein. -
@foxthefox Jupp, sorry hatte ich ganz vergessen. Passt wieder
-
@foxthefox dank Dir. Sieht gut aus.
Hier mein Beispiel für die Ladesteuerung ... per APP manuell angelegt
Leider sind die Datenpunkte schreibgeschützt.
Wenn ich diese per Skript ändere, werden die Daten dann an die API von ecoflow übertragen?
-
@vmi
Ja, die Datenpunkte sind schreibgeschützt, weil ja nur das ankommende Telegramm sichtbar gemacht wird. Verändern setzt demzufolge auch kein Kommando ab. -
@foxthefox wäre super wenn die Telegramme auch gesendet werden könnten.
Dann kann ich meine Ladesteuerung wieder per Skript nutzen. Die Datenpunkte sind ja jetzt alle da ...
Ist das umsetzbar? -
@vmi
Aus meiner Sicht braucht es zum Absetzen alle relevanten Datenpunkte einer Aufgabe, das ist nicht ganz so einfach mit dem derzeitigen Mechanismus vereinbar.
Grundsätzlich funktioniert ioBroker durch Reagieren auf Änderungen an den Datenpunkten und dann wird die Änderung verarbeitet (z.B. Kommando abgesetzt). Nachdem ja quasi nur ein Datenpunkt chChargeWatt interessant ist, darf man nicht auf die anderen Reagieren und zeitgleich muss aber das Beiwerk aktuell und verwendbar sein.
Man könnte nur auf chChargeWatt reagieren und müsste die anderen Datenpunkte, die auf schreibbar zu bringen sind, vom Reagieren ausschließen. Machbar aber Sonderlocke.
Und das Problem der Aktualität des Beiwerks ist dennoch da.Evtl. hast du ja eine Idee.
-
Aktuell steuere ich die Netzzusatzladung über das SHP so:
Ich berechne den Überschuß, welche ich einspeise, sobald der Durchschnitt größer als 1500 W ist schalte die Netzladung am Port 2 ein.
Den Überschuß ermittel ich aus dem aktuellen Bezug bzw. Einspeisung über meinen Stromzähler per USB Lesekopf.
Das funktioniert auch so wunderbar, nur leider geht halt jeder PV Überschuß unter 1500 Watt "verloren"
Meine Idee, ist per App den Task fürs Laden einmal anzulegen, mein Beispiel z.B. Task 3 (siehe letzter Post)
Der Deaktivierte Block kommt noch aus der Vergangenheit, wo die Steuerung über die Delta Pro möglich war. Den würde ich dann entsprechend anpassen auf den Wert von Task 3
Dann hätte ich alle Datenpunkte und alle Werte und könnte nur noch das Datum, Ein- bzw. Ausschalten und den ChChargeWatt Wert per Skript anpassen.
Es wären alle Datenpunkte mit den entsprechenden Werte aktuell und könnten an die API übermittelt werden.
Ich denke so könnte es funktionieren.
Was meinst Du?
Generell wäre mir eine native API am liebsten, so dass die ecoflow cloud nicht gebraucht wird. Ging ganz am Anfang mal bei den Delta Pros bis die Ports mit einem Firmwareupdate gesperrt wurden.
-
@vmi Ich mache das ähnlich aber in feineren Stufen damit nichts verloren geht.
Ich berechne den Einspeisedurchschnitt (ESPD) der letzten 10 Minuten.
Wenn ESPD >300 dann schalte ich auf Beladung mit 200W. Alle 3 Minuten schaue ich wieder nach >300 und erhöhe die Beladung um 100W.
Und genauso geht es wieder runter. alle 30 Sekunden wenn ESPD <100 dann geht es um 100 W runter bis ich ggf abschalte.
