Neuer Adapter ecoflow-mqtt
-
Je nachdem was du mit Erzeugung meinst ist es watth1 (Energie aus dem Powerstream) und watth7+8 für die Erzeugung aus den Solarmodulen.
Kürzlich noch entdeckt habe ich watth16,17, das kommt demnächst als Datenpunkt. Muß man dann mal beobachten was das ist.
Die 100Wh Differenz kann mit dem Update des Datenpunktes zusammenhängen.
Habe letztens beobachtet, daß es keine updates der Energiewerte gab, erst beim Nachschauen in der App.
Eine Ursache dazu ist die zu hohe Temperatur im Powerstrem, da kommt evtl. nur bei Anfrage etwas.
Sofern es einen Befehl zum Anfragen der Energie gibt, werde ich den noch implementieren. -
@foxthefox
Hallo allerseits !
Ich lese schon einige Zeit mit und habe den Adapter erfolgreich am Laufen. Vielen Dank auch von mir für die gute Arbeit!
Ich habe am PowerStream eine DeltaMax mit Zusatzakku (je 2kWh) hängen.
Die DM frage ich für einige Werte separat ab.
Der Wert für bmsSlave1\outputWatts und bmsSlave1\inputWatts ist um Faktor 10 zu klein. (Vermutlich auch bei Slave2)@bentschik
Die Differenz bei allen energy-Werten hat 2 Ursachen:- Die App aktualisiert nur noch stündlich.
- Die Werte in der Cloud werden um 00:00 UTC genullt. Das bedeutet es fehlen derzeit im Adapter die ersten 2 Stunden am Tageswert. In der App wird es auf DE-Zeit umgerechnet.
@foxthefox
Das die Ursache eine zu hohe Temperatur des PS ist kann ich nicht bestätigen. (ist bei mir 25-35°C). Es liegt wohl eher daran, dass das "GetLatestQuotas" nicht auf die Energy-Werte wirkt. Nur bei Aktualisierung durch die App werden alle Abonnenten auch informiert ?!? Auch ein HTTP-Request, wie es die App macht, bringt keinen Erfolg. Zusätzlich wird noch "graph.facebook.com" kontaktiert. Vielleicht liegt hier die Lösung.
Bin noch dran. -
@erzi60
Die Slave Werte muß ich mir dann mal noch anschauen, wundert mich das zwischen Master/Slave unterschieden wird.
Evtl. bräuchte ich dann mal ein JSON incl. der Slave.Die Vermutung mit den getLatestQuotas habe ich auch, werde mal schauen ob es im log noch weitere Telegramme gibt (evtl. unbekannte).
Ich denke es fehlt bzgl der Energiewerte nichts im Adapter, das Nullen kommt halt erst später, aber bis dahin wird weiter erfasst. Die Temperatur möchte ich noch nicht komplett ausschließen, da ich eine Instanz kenne wo die App so gut wie nie geöffnet wird und dort bei gesunkener Temperatur auf einmal ein stetig wachsender Graph zum Vorschein kam. Also da wird Energie irgendwie ausgeblendet. Dort ist noch die vorherige FW drauf, evtl. ist dort zusätzlich noch die Ursache.
Auch bei mir wurde es nach dem Anbau des EF-Lüfters besser.
Aber wie gesagt ein special request auf Energie kann es auch geben. -
OK, danke auch an @Erzi60 für die Erläuterung. Wenn ich das zusammenfasse, dann ist watth1 ein kumulierter Tageswert, der 0:00 UTC wieder zurückgesetzt wird. Das erklärt auch, warum mein watth1 am nächsten Tag plötzlich wieder geringer ist.
Mit Erzeugung bzw. Gesamterzeugung meine ich, wie in der App, die komplette kumulierte Erzeugung des Powerstreams (also nicht nur tageweise). Dafür scheint es dann unter den bereits identifizierten Datenpunkten noch nichts zu geben. D.h. ich addiere mir das einfach selbst zusammen.Vielen Dank Euch!
-
@bentschik
Gesamtzähler aus der App wäre nicht schlecht, ist aber wohl noch nicht dokumentiert. Ist momentan vermutlich nur per API und nicht per MQTT zu erreichen, hab ihn aber auch da noch nicht gefunden.
Das Addieren der Tageswerte funktioniert aber eben auch schlecht, da sie nicht zuverlässig aktualisiert werden. Bedeutet, man muss um 01:59 (23:59 UTC) einmal die App aufrufen um den letzten Wert des Tages zu bekommen....
Alternativ bleibt nur das Abtippen der Werte aus der App. Automatisierung sieht normalerweise anders aus....
Hilft nur dranbleiben und die Entwickler weiter nerven, dass sie die Daten herausgeben. -
@erzi60 Ja, das habe ich eben auch festgestellt, als mein watth1 noch nicht genullt war, aber nach dem Aufrufen der App. Damit wird es in der Tat etwas schwierig...
-
Also im Telegramm werden eigentlich 24 Einzelwerte übertragen, jede Stunde hat einen Wert. Sofern die Stunde noch aktuell ist, ändert dieser sich auch (ggf. Nicht mehr in der aktuellen FW des PS, mindestens aber noch davor). Im Adapter addiere ich diese 24Werte zusammen. Für welche Stunde am Tag der erste Wert steht, hängt von Zeitzone und Sommerzeit ab.
Wenn es eine separaten Aufruf für Energiewerte gibt , dann sollte der hoffentlich auch durch das Abo auf „get“ sichtbar sein. Dies lässt sich dann auch im Adapter benutzen. Falls ein unbekannter MQTT Pfad benutzt wird, dann müssen wir den erst noch ausfindig machen.
-
Endlich ist es soweit, die nächste Version ist auf git und npm verfügbar.
EDIT: die Version läuft zwar, aber es kommen bei mir derzeitig nur die Daten rein nachdem gestartet wurde, oder die App offen ist.
Werde hoffentlich bald die Ursache finden und die 0.0.35 erstellen.EDIT2: War evtl. nur ein Problem in meinem Setup und dem Tagesanfang geschuldet. Die vorherige Version zeigte gleiches Verhalten. Mit der erneut installierten 0.0.34 läuft es wie es soll. Ansich hatte ich auch nichts an der MQTT Anbindung geändert
Power Ocean DC Fit ist mit den ersten Datenpunkten dabei.
Smart Home Panel 2 ist mit den bekannten Datenpunkten komplett dabei.
Für beide sind noch keine Kommandos implementiert, dies muß noch mit euch zusammen ermittelt werden.0.0.34 (npm)
- (foxthefox) first implementation for power ocean kit
- (foxthefox) first implementation for smart home panel 2
- (foxthefox) new values watth16/17/18 for powerstream
- (foxthefox) deltapro max values mmpt.inAmp, mpptTemp
- (foxthefox) fixed updates to info.reconnects
- (foxthefox) fixed #90 cfgAcEnabled on river2max
- (foxthefox) logging enhancements
-
Wenn ich mir die Revisionliste so ansehe dann sollte es ev. eine 0.1.0 werden
Da sind ja offensichtlich (auch) neue Features drinnen .Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes MINOR version when you add functionality in a backward compatible manner PATCH version when you make backward compatible bug fixesUnd damit's nicht falsch rüber kommt: Jedenfalls ein ganz großes DANKE dass du Zeit und Wissen für den Aapetr investierst.
-
So gesehen ist es richtig und ist mir auch bewusst.
Von daher müsste ich schon bei Version 0.20.0 oder höher sein.
Meist fange ich etwas kleines an und dann wird es mehr und dann lässt sich der code nicht mehr trennen.
Naja, wollte schon längst mal eine 1.0 veröffentlichen um ins offizielle repo zu kommen. -
@foxthefox said in Neuer Adapter ecoflow-mqtt:
So gesehen ist es richtig und ist mir auch bewusst.
Von daher müsste ich schon bei Version 0.20.0 oder höher sein.
Meist fange ich etwas kleines an und dann wird es mehr und dann lässt sich der code nicht mehr trennen.
Naja, wollte schon längst mal eine 1.0 veröffentlichen um ins offizielle repo zu kommen.No problem. Wollte es nur anmerken
Manchmal ist der Begriff semver nicht wirklich präsent
Und bei 0.0.x ist es streng genommen auch egal.DANKE jedenfalls dass du hier mitarbeitest.
Und bislang sind mit keine Adapter bekannt bei denen die Version ausgegangen ist. Also 0.20.x wär sicher kein Problem
Mit dem js-controller 6 wird das Versionierungsthema nur etwas wichtiger da es nun automatische Updates gibt. Und damit sollte nach möglichkeit nicht was installiert werden nur weil der Versionssprung zu klein war. Betrifft zwar zu 99% nur major - aber uns devs sollte es nochmehr bewußt sein drauf zu achten.
-
Hallo, @foxthefox. Ich habe auf 0.35 aktualisiert und alle alten DPs gelöscht. Ich erhalte mit der neuen Version im Sekundentakt folgende fehler
State value to set for "ecoflow-mqtt.0.XYZ.bmsMaster.cellVol" has to be type "number" but received type "object"
State value to set for "ecoflow-mqtt.0.XYZ.bmsMaster.cellTemp" has to be type "number" but received type "object"
-
@mikerow
Danke für die Rückmeldung.
In meinen Test lasse ich recht viel laufen, hab aber die Objekte bisher nicht gelöscht. Evtl. zeigt sich der Fehler dann auch in meinem Test, ansonsten bräuchte ich mehr Info.
Um welches Gerät handelt es sich denn? -
@foxthefox es ist eine Delta Pro
-
@mikerow sagte in Neuer Adapter ecoflow-mqtt:
@foxthefox es ist eine Delta Pro
OK, danke.
Habs in der 0.0.36 dann drin.
Wenn du möchtest, kanns du es von git schon installieren. -
@foxthefox Super, danke. Passt wieder alles
-
Die Version 0.0.36 steht auf git und npm zur Verfügung.
Beim Datenabo am MQTT lief alles gut, keine Beobachtung wie bei 0.0.34!
Wesentlich wurde am logging verbessert, nun kann man die Meldungen reduzieren indem man nur beim interessierenden Gerät das debug Häckchen setzt.
Bei den protobuf Werten wurde auch ein Fehler für das Senden an Homeassistant behoben.0.0.36 (npm)
- (foxthefox) correction bmsMaster.cellVol/cellTemp as array for DeltaPro
- (foxthefox) correction for transfer of values derived from protobuf to HA
- (foxthefox) enhanced to device specific logging
-
Was mir übrigens beim Anschauen der logs aufgefallen ist:
- die InverterHeartbeat2 beim powerstream scheint es in der aktuellen FW nicht mehr zu geben
- dafür ist inverter_heartbeat mit fast 100 Werten nun deutlich größer (evtl. wurde da etwas zusammengeführt)
Weiß da jemand was oder gibt es ähnliche Beobachtungen?
-
Die nächste Version ist auf git und npm verfügbar.
0.0.37 (npm)
- (foxthefox) corrections for HA discovery of PowerOcean/SHP2/PowerKit
-
Beim Erstellen der neuen Version hatte ich eine Beobachtung gemacht, die ich noch nicht richtig einordnen kann.
Grundsätzlich kommen die zyklischen Updates von station und stream hinein.
Als ich beim Testen am Live-system aber auf ein Absturz kam, wollte selbst nach Installation der bereinigten Version sich das zyklische updaten nicht wieder einstellen (nur wenn die App lief).
Dann habe ich die 0.0.33 wieder installiert und danach die 0.0.37 und es läuft wie gehabt mit den zyklischen updates. Auch nach Neustart des Adapters.
Muß man mal beobachten.
