@waly_de hm, weiteres Problem mit der Lösung. Gerade steht *writeables.chgPauseFlag auf 1. Auf dem Gerät scheint das aber nicht anzukommen. WIFI ist OK. params.inv.inputWatts meldet manchmal 0, manchmal 60W, laut shelly wird konstant mit um die 90W geladen. Das script hat die Ladegeschwindigkeit auf 0 gesetzt. Sehe grad, das data.params.chgPauseFlag gibt 255 zurück. Da klappt wohl irgendwo noch was nicht ganz mit der übertragung manchmal?
Hab jetzt gerade chgPauseFlag kurz auf 0 gesetzt, dann hat er noch schneller geladen?! (über 255W wahrscheinlich?) Dann nochmal auf 1 gesetzt und jetzt ist Ruhe, wie es sein sollte. Irgendwo rutschen da in der Kommunikation wohl immer noch 255 rein manchmal?
PS: Ja ich seh's gerade, *.params.slowChgWatts steht auf 255 *.writeables.slowChgWatts auf 0 steht.
@waly_de Hm, also ich hab das jetzt gerade nochmal genauer angeschaut - das Problem tritt anscheinend auf, wenn ich die D2M subscribe - dann springen pauseChgFlag und slowChgWatts zufällig auf 255 (als ich gerade getestet habe und jeweils wieder den richtigen Wert setzen lies, war's immer in einem durchgang deines Scripts der richtige Wert, danach wieder 255. . In den writables bleibt’s korrekt, aber an die Station geschickt wird anscheinend der falsche Wert.
Edit: Hat's evtl. was damit zu tun? Mir ist nicht ganz klar was das bedeutet:
{ id: 0, name: 'slowChgWatts', ValueName: 'slowChgWatts', Typ: 'D2M', MT: 3, OT: 'acChgCfg', AddParam: '{"fastChgWatts":255, "slowChgWatts":0,"chgPauseFlag":255}' }, // Objekt angelegt, schreibbar
{ id: 0, name: 'chgPauseFlag', ValueName: 'chgPauseFlag', Typ: 'D2M', MT: 3, OT: 'acChgCfg', AddParam: '{"fastChgWatts":255, "slowChgWatts":255,"chgPauseFlag":0}' }, // TODO: chgPauseFlag testen, ob dann die Ladung pausiert
@sirdir leider hab ich im Augenblick keine Zeit um das genauer zu untersuchen. Kümmere ich mich bald drum. Ich bau Dir dann auch eine Parameter ein "ExcessChargeStopPower" der festlegt ab welcher Überschussleistung abgestellt werden soll, was im Moment fest auf 0W steht.
Noch ein paar Anmerkungen:
@sirdir sagte in ecoflow-connector-Script zur dynamischen Leistungsanpassung:
Hab den Offset auf -70 um nicht dauernd an der Grenze zu sein.
Das führt aber auch dazu das ein negativer Wert an die Delta gesendet wird.
Das ist noch nicht abgefangen. Bau ich in die nächste Version.
Dass mit den 255 ist vermutlich richtig so. 255 heisst nach dem was wir bisher wissen: den vorhandenen Wert nicht ändern. Das wird nur mit dem Set gesendet, auch von der APP. Im eigentlichen Wert (Heartbeat) steht dann der echte wert.
@waly_de Interessantes Thema, habe das gerade gefunden, Tibber Pulse hängt am Zähler und Web-Server ist freigeschaltet. Dein Skript in meinen ioBroker eingetragen, allerdings gibt es bei mir ein Problem mit der Funktion BigInt():
Cannot find name 'BigInt'. Do you need to change your target library? Try changing the 'lib' compiler option to 'es2020' or later.(2583)
Keine Ahnung wo ich die Option für den Compiler anpassen muss - gibt es da eine Lösung oder Hilfestellung?
@waly_de der falsche Wert steht aber IMHO im Heartbeat. Aber irgendwie auch nur gestern, am Tag davor schien es zu klappen. Hab jetzt vorerst alles wieder auf shelly an/aus gestellt, da funktioniert alles soweit. Wenn ich die Grenzen vernünftig setze geht es auch nicht andauernd an und aus. Es ist wirklich schade, dass man die Geräte nicht lokal steuern kann. Manchmal hab ich das Gefühl die Server tun ihr übriges… Dass bei 0 überschuss aus geht (hab die Stelle im Script übrigens schon gefunden) ist ja soweit OK. Was ich eher möchte ist, dass etwas 'Luft' bleibt beim Leistung setzen. (resp. eben dass das Script nicht versucht unrealistisch tiefe Leistungen zu setzen). Ich schau da auch nochmal rein... Hab mir eigentlich mal gesagt ich fummle an deinem script nicht mehr rum, aber…
@etgermany sagte in ecoflow-connector-Script zur dynamischen Leistungsanpassung:
allerdings gibt es bei mir ein Problem mit der Funktion BigInt():
Cannot find name 'BigInt'. Do you need to change your target library? Try changing the 'lib' compiler option to 'es2020' or later.(2583)
Keine Ahnung wo ich die Option für den Compiler anpassen muss - gibt es da eine Lösung oder Hilfestellung?
Ich nehme an, du bekommst diese Meldung nur im Editor und nicht beim Ausführen des Scripts, richtig?
Das hatte ich auch, es geht scheinbar um die javascript Versionen. Man kann das abstellen indem man "es2020" in den in den Instanz-Einstellungen des Javascriptadapters unter "Die Syntaxhilfe für diese npm-Module aktivieren:" einträgt.
Ich habe dort 3 Einträge: JSON,string und es2020.
@waly_de Ich glaube man muss auch bei der Ladeleistung noch nen Offset vorsehen. gerade der inv.inputWatts zeigt vielleicht die DC Leistung an. Der Wert ist tiefer als was man als SlowChgWatts setzt, laut meinem Shelly ist die bezogene Leistung aber höher. (in meinem Fall ca. 20W differenz)
@foxthefox, @Waly_de
So da meine Delta 2 Max nun mal etwas geladen ist und auch heute ein weiteres Update durch Ecoflow bekommen hat,
dachte ich log mal was über die Lap-Funktionen.
Laden über Solar, einmalig, heute 17.12.23 ab 10:00 Uhr:
script.js.Ecoflow_Dynamische_Leistung_V1_2: Unbekannter Delta2Max Set Befehl: {"params":{"min":20,"taskIndex":0,"taskPrior":0,"sec":6,"timeMode":3,"timeScale":[0,0,0,0,0,0,0,240,255,255,255,255,255,255,255,255,255,255],"day":17,"type":1,"timeParam":1036177,"year":2023,"week":1,"isEnable":1,"month":12,"hour":9,"isCfg":1},"from":"iOS","lang":"de-de","id":"232761002","moduleSn":"R351ZEB4HF4Exxxx","moduleType":1,"operateType":"taskCfg","version":"1.0"}
ein verändern jeweils um eine komplette Stunde (10, 11, 12, 13, 14, 15, 16:00 Uhr) ewirkt:
"timeScale":[0,0,0,0,0,0,0,240,255,255,255,255,255,255,255,255,255,255],"day":17,"type":1,
"timeScale":[0,0,0,0,0,0,0, 0,252,255,255,255,255,255,255,255,255,255],"day":17,"type":1,
"timeScale":[0,0,0,0,0,0,0, 0,0 ,255,255,255,255,255,255,255,255,255],"day":17,"type":1,
"timeScale":[0,0,0,0,0,0,0, 0,0 ,192,255,255,255,255,255,255,255,255],"day":17,"type":1,
"timeScale":[0,0,0,0,0,0,0, 0,0 ,0 ,240,255,255,255,255,255,255,255],"day":17,"type":1,
"timeScale":[0,0,0,0,0,0,0, 0,0 ,0 , 0,252,255,255,255,255,255,255],"day":17,"type":1,
"timeScale":[0,0,0,0,0,0,0, 0,0 ,0 ,0 , 0,255,255,255,255,255,255],"day":17,"type":1,
täglich 10:00 Uhr bis 15:00 Uhr
script.js.Ecoflow_Dynamische_Leistung_V1_2: Unbekannter Delta2Max Set Befehl: {"params":{"min":0,"taskIndex":0,"taskPrior":0,"sec":0,"timeMode":0,"timeScale":[0,0,0,0,0,0,0,240,255,255,255,3,0,0,0,0,0,0],"day":17,"type":1,"timeParam":1036177,"year":2023,"week":1,"isEnable":1,"month":12,"hour":0,"isCfg":1},"from":"iOS","lang":"de-de","id":"617597303","moduleSn":"R351ZEB4HF4Exxxx","moduleType":1,"operateType":"taskCfg","version":"1.0"}
täglich von 15:00 Uhr bis 20:00 Uhr
script.js.Ecoflow_Dynamische_Leistung_V1_2: JSON-Nachricht empfangen:/app/1669741428735926273/R351ZEB4HF4Exxxx/thing/property/set:{"params":{"min":0,"taskIndex":0,"taskPrior":0,"sec":0,"timeMode":0,"timeScale":[0,0,0,0,0,0,0,0,0,0,0,252,255,255,255,0,0,0],"day":17,"type":1,"timeParam":1036177,"year":2023,"week":1,"isEnable":1,"month":12,"hour":0,"isCfg":1},"from":"iOS","lang":"de-de","id":"873716234","moduleSn":"R351ZEB4HF4Exxxx","moduleType":1,"operateType":"taskCfg","version":"1.0"}
Könnt ihr hiermit was anfangen?
@aherby
grundsätzlich kann man damit was anfangen, timeScale ist noch etwas interpretationsbedürftig, aber sonst sprechen die Namen schon fast zu einem.
Allerdings würde ich solche Aufgaben nicht über script oder Adapter setzen wollen.
Bzw. diese überhaupt setzen, wenn man Automatisierung über iob macht.
Aus meiner Sicht gehört die Logik zentral an eine Stelle und kein konkurierendes Eigenleben zusätzlich (dezentral im Gerät).
Theoretisch alles machbar, aber einfacher wird es dadurch nicht.
EDIT:
wobei ich glaube, daß die eigentliche Aufgabe im Powerstream zu setzen ist und dann folgt die Powerstation diesem. Kann aber auch sein, daß die Einstellung auch von der Powerstation initiert werden kann.
@foxthefox Moin es ist eine von vier Automatisierung von der Delta 2 Max.
Laden über Solarengergie, Laden über Wechselstrom, Entladen über AC-Port und Entladen über 12V-Dc Port.
Einstellungen täglich, einmalig, wöchentlich.
Natürlich ist es über die App oder so einfacher aber vielleicht für Überschussladen mit entsprechender Ladeleistung
ein Mehrwert. Oder als Rückmeldung ob eins der "Punkte" aktiv ist und daher die Delta 2 Max dies und das nicht macht.
@aherby sagte in ecoflow-connector-Script zur dynamischen Leistungsanpassung:
@foxthefox Genau richtig es waren erstmal 0%, 50% und 100% Helligkeit. Habe glaube nicht alle als Code eingefügt.
Und ja 2500 W sind der Max-Wert und 1750 W war so grob als ein Werte oberhalb der Mitte gedacht.
Kannst du mir in irgendeinerweise beibringen so Sachen / Dinge zu lesen?
Kein Problem.
zum anschauen der HEX-Pakete, gibt man diese auf der Webseite ein
https://protobuf-decoder.netlify.app
Danach wird ohne protobuf-Definition zu kennen etwas ausgegeben.
Beispiel: 
FieldNumber
1 -> die Daten der gemachten Einstellung
8 -> welches Gerät 20=Powerstream, 2=Plug
9 -> cmdId, hier die 137 für die Überlastgrenze
10 -> Datenlänge von FieldNumber 1
Damit kommt man solchen einfachen Kommandos schon gut auf die Spur.
Komplexere wie die Aufgaben, haben dann in 1 noch ihre eigene Struktur (bzw. wenn es um Daten vom Gerät kommend handelt)
Wenn das eine 0% Helligkeit war, dann ist dies wieder auch ein interessanter Fall. Bei binären wurde auch schon eine "0" gar nicht als data übergeben, sondern nur der Rest. Hier scheint es ähnlich zu sein, daß 0% auch nicht übergeben wird.
@foxthefox
0% Helligkeit könnte dies hier sein:
script.js.Ecoflow_Dynamische_Leistung_V1_2: Binäre Nachricht empfangen:/app/166974142873592xxxx/HW52ZDH4SF66xxxx/thing/property/set:0a36102018352001280138034002488201580170f4f9d1c407800113880101ba0103696f73ca0110485735325a4448345346363636353835
@aherby sagte in ecoflow-connector-Script zur dynamischen Leistungsanpassung:
0a36102018352001280138034002488201580170f4f9d1c407800113880101ba0103696f73ca0110485735325a4448345346363636353835
Ja, so wie ich schrieb.
cmdId=130 und keine Daten dabei, 0=> nix an Daten mit FieldNumber=1
Muss dann nur beachtet werden, daß 100% in 1024 umzurechnen ist.
@foxthefox hoffe es hat geholfen
@aherby sagte in ecoflow-connector-Script zur dynamischen Leistungsanpassung:
@foxthefox hoffe es hat geholfen
auf jeden Fall
@foxthefox noch weiter Daten benötigt?
Sobald mal mehr Sonne da ist würde ich dass mit den Smartplugs und mit oder ohne Berücksichtigung ins Hausnetz weiter loggen.
@aherby sagte in ecoflow-connector-Script zur dynamischen Leistungsanpassung:
@foxthefox noch weiter Daten benötigt?
Sobald mal mehr Sonne da ist würde ich dass mit den Smartplugs und mit oder ohne Berücksichtigung ins Hausnetz weiter loggen.
Ja gerne, ich bräuchte auch mal ein HEX String von den normalen update Daten die zyklisch kommen, da müsste eigentlich dieses Bit für "Berücksichtigung im Powerstream"neu drin sein.
@foxthefox Hallo, wir hatten mal im August über das Thema WLAN Verlust bei den Powerstreams gesprochen.
Einige FW - Releases später ist aus meiner Sicht dieses Problem immernoch vorhanden. Powerstream und Delta2Max haben guten WLAN Zugang (D2M ist ohne Probleme die ganze Zeit am WLAN). Die Powerstream fängt morgens gut an, jedoch nach einigen Stunden verabschiedet sich die Steuerung und nimmt nichts mehr. In der App ist dann nur noch Bluetooth aktiv. Die PS nimmt zwar im UI Einstellungsveränderungen an, jedoch setzt sie nach einiger Zeit wieder zurück.
Manchmal hilft Bluetooth an ausschalten am Handy, immer hilft alle Stecker abziehen, manchmal hilft Powerstream neu zu verbinden, gelingt aber auch nicht immer. Jetzt könnte man meinen, dass ist ein reines Ecoflow Problem, jedoch ist eine erfolgreiche Massnahme, das JavaScript "ecoflow-conn...." neu zu starten. Danach funktioniert die Regelung wieder und in der App von Ecoflow ist die Powerstream wieder über WLAN connected. (Ich verwende derzeit 1.1.6.2/iobroker ist in Summe auf neuestem Stand). Habt Ihr neue Einschätzungen zu dem Thema?
Klar, bin mit Ecoflow auch in Kontakt, da hält man sich bedeckt. Daher mal die Frage nach einem Meinungsbild hier in der Community. Bei Ecoflow wollte man davon nichts wissen, bis das letzte Update dann exakt unter dem Titel "Verbesserter Algo...for Batterieladezustand" das Problem behebt. 
@dadue-max
Also ich kann das bei mir so nicht beobachten. Aus meiner Sicht läuft es super stabil. Ich hab einmal node-red was PowerStream und powerstation zuverlässig abholt und meinen Adapter der auch die gleichen Dinge holt. In beiden Implementierungen hab ich einen Zähler drin. Getrennt für beide Geräte und der läuft munter hoch. Ich hab jetzt keine Auswertung ob mal weniger Telegramme kommen, aber gefühlt gibt’s da keine Aussetzer oder Verlangsamung. PowerStream schickt nur Daten die sich auch aus ihrer Sicht geändert haben und es wert sind auf die Reise zu gehen. Die Station schickt immer alles von einem der Teilgeräte (bms, mppt,…) und das quasi im Sekundentakt.
Das einzige was auffällig bei mir ist:
Kann sein das das ein bug in der Version 1.0.0.73 ist. Die Version bekam ich von EF direkt, da ich aus dem Fehler 1 (3 Fehler Stromnetz - warten bis es sich erholt) nicht mehr raus kam.
@dadue-max Meine Powerstream hat auch Schrott WIFI. Manchmal denk ich, wenn viel Strom fliesst (oder hohe Temperatur? Hängt ja auch zusammen) bricht WIFI weg. Merk es aber auch nicht immer, da es, wenn viel Strom rein fliesst meist nichts zu kontrollieren gibt (Einspeisung ist dann 0 weil andere Solaranlagen genug liefern).
