UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[DaDue-max]

@waly_de

Okay, dann wird mir alles klar. Dann wird es ein thermisches Problem sein, da es immer um Mittag passiert. WLAN ist soweit okay, nachdem ich die Batterie/PS ins Haus geholt habe….Lieber nochmal ein Ticket aufmachen bei ECOFlow 😉

[sirdir]

@ponti92 naja, mir ist es aber lieber, ich speis mal 800W für nix ein (und aus dem Akku kommen eh nie mehr als 600W) als dass ich Strom kaufe, den ich nicht kaufen muss. Die Trägheit des Systems regelt das sowieso schon raus. Wenn es wirklich eine Spitze von wenigen Sekunden ist, dreht der Powerstream eh nicht so schnell auf. Aber selbst so, 30 Sekunden ist auch nicht was ich sehe. Ich sehe oft, dass weiterhin derselbe Wert eingespeist wird (also in dem grösseren debug Dialog) obwohl ich weiterhin mehr Leistung anfordere. Ich hab ehrlich gesagt die Geduld nicht ne halbe Stunde davor zu sitzen um nachzuvollziehen was passiert, da mein Script ja soweit gut funktioniert und jetzt im Sommer mit Klimaanlagen etc. die Regelung auch ziemlich wichtig ist.
Müsste mal das Script genau analysieren was da gemacht wird, aber verglichen zu der Version von Anfang Juli ist's jetzt ziemlich kompliziert geworden.

[Waly_de]

@sirdir das ist eben ein anderer Ansatz. Es ist nur eine Zeile im Script umzustellen um das mit dem „Echtzeitwert“ zu regeln. Allerdings ist das System sehr Träge. Selbst ein taktender Herd kann dazu führen das a) die Batterie und der Wechselrichter sehr gefordert werden und b) unnötig Energie ins Netzt geht.
Es rechnet sich meiner Meinung nach, so viel wie möglich sofort zu verbrauchen und den Akku so wenig wie möglich zu belasten, dabei aber möglichst 100% der erzeugbaren Solarenergie irgendwie zu verwerten. 100% deines Bedarfs kannst du mit einem balkonkraftwerk eh eher nicht decken. Das Script verfolgt diesen Ansatz und lässt sich per Parameter an verschiedene Usecases anpassen. Wenn dir eine Minute Betrachtungszeit (+ Intervall Zeit) zu wenig sind, stell es halt um. Der Quellcode ist offen. Guck nach „lowestvalue“ und ersetzte das mit dem aktuellen Messwert. Empfehlen kann ich das aber aus genannten Gründen nicht.

[foxthefox]

@dadue-max @Waly_de

Ich bin mir nicht sicher ob es WLAN instabilität ist, oder ob es nicht doch etwas mit dem Protokoll zu tun hat.
Ich bau grad ein paar node-red Knoten auf um Power Stream und Power Station einzulesen.
Was mir dabei auffällt, ist das sich bei mir wohl nichts von WLAN trennt, sondern das Senden einfach aufhört. Das merkt man recht gut bei der Powerstation, da die viel mehr am plaudern ist.
Obwohl ich auch regelmäßig mal ein "latestQuatas" anfrage, kommt manchmal nach einer gewissen Zeit nichts an. Gehe ich dann mit der App auf das Gerät, gehts wieder los, WLAN ist demzufolge noch an.
Ich vermute eher, daß hier bei Telegrammen, die ein ACK=1 haben, auch ein ACK zu senden ist.
Ich hatte mal probehalber den .../set der powerstation im debug, da kommt eine Unmenge an gleichartigen Telegrammen rein, scheinen die ACK zu sein.

Gruß
Klaus

[sirdir]

@foxthefox naja, ich habe manchmal pingzeiten zur powerstream von 5 sekunden… Währen der AP von einer 'excellenten' Verbindung mit 30 dB spricht. Irgendwas ist da oberfaul.

[Waly_de]

@foxthefox damit schlage ich mich auch schon seit Beginn rum. Es kann sicher reproduziert werden. Wenn du dich mit der App verbindest und dann die App schließt (task beenden) hört der MQTT sofort auf zu feuern. Mein Script macht dann ein reconnect und sendet ein paar dieser leeren Telegramme. Danach gehts dann weiter. Vielleicht registriert der Mqtt einfach ein disconnect und hört dann auf, auch wenn noch weitere Clients verbunden sind?
Ich hoffe immer darauf, das jemand mal den Traffic der App diesbezüglich genauer untersucht. Vielleicht läuft da ja noch mehr, was der Mqtt nicht spiegelt.

dadue-max sagt ja selbst, es geht das WLAN verloren und in der App ist das Gerät nur per Bluetooth zu erreichen. Das ist ein anderes Problem.

[Waly_de]

@sirdir da ich grade nicht schlafen kann ;-) :

function getLowestValue(id, minuten = 120) {
    if (minuten === 0) {
        const value = Math.floor(Number(getState(id).val));
        setStateNE(ConfigData.statesPrefix + ".lowestValue", value);
        return Promise.resolve(value);
    }
...  Rest unverändert 

das baue ich auch in die nächste Version ein. So kann der Wert für "MinValueMin" auf 0 gestellt werden um direkt auf RealPower zuzugreifen.

[DaDue-max]

@foxthefox @Waly_de
Da mag ich nicht widersprechen....und es kann parallel zu dem Hitzeproblem ein Thema sein.
Zum Hitzeproblem hier noch ein Test von heute:
Ich tracke für die Powerstreamtemp "....data InverterHeartbeat llcTemp". Irgendwann heute ist mal wieder ab mittag das WLAN ausgefallen von der PS. Bei der Ilc Temp sind 45 Grad dokumentiert. (Heute morgen waren es ca 25-30 grad ohne Last). Ich habe einen alten PC Lüfter mit Heatpipe und allem Schnickschnack mal auf dem glatten PS Deckel montiert und angeschaltet und siehe da, Ilc Temp auf 42 abgesackt und WLAN funktioniert wieder....:face_with_rolling_eyes:

[Dreffi]

@dadue-max
Ich glaube nicht, dass es an der Temperatur liegt.

Ich habe zwei Powerstreams. Beide werden aktiv gekühlt.
Der, der immer etwas wärmer läuft, macht so gut wie nie Probleme mit dem WLAN.
Der Andere, der trotz höherer Last kälter bleibt, macht leider recht oft Probleme.

Die Effektivste Lösung für mich war bisher bei Problemen den WLAN Kanal am Router zu verstellen. Manchmal will ein Powerstream einfach nur auf einem bestimmten Kanal arbeiten. Nach ein paar Tagen kann das auch wieder ein anderer Kanal sein.

Es gibt zwar ein paar fremde WLAN in der Nähe, aber die sind vom Signal deutlich schwächer als meins. Auch ein gut platzierter Repeater konnte nicht helfen. Die Powerstreams neigen auch dazu sich auf einen ungünstigen, also weit entfernten, AP zu verbinden und dort zu verbleiben.

[Milchbeck]

Erst einmal Super arbeit mit dem Script, nur ich hab ein problem
bekomme ein error
SetState more than 1000 times per minute
und dann hält das script an

27.8.2023, 12:58:40.938 [info ]: javascript.0 (5490) Start javascript script.js.EcoFlow
27.8.2023, 12:58:40.961 [info ]: javascript.0 (5490) script.js.EcoFlow: registered 0 subscriptions, 0 schedules, 0 messages, 0 logs and 0 file subscriptions
27.8.2023, 12:58:41.437 [info ]: javascript.0 (5490) script.js.EcoFlow: Verbunden mit dem Ecoflow MQTT-Broker
27.8.2023, 13:00:35.459 [error]: javascript.0 (5490) Script script.js.EcoFlow is calling setState more than 1000 times per minute! Stopping Script now! Please check your script!
27.8.2023, 13:00:35.462 [info ]: javascript.0 (5490) Stop script script.js.EcoFlow
27.8.2023, 13:00:35.465 [info ]: javascript.0 (5490) script.js.EcoFlow: Ecoflow MQTT-Client beendet
27.8.2023, 13:00:59.397 [info ]: javascript.0 (5490) Stop script script.js.EcoFlow

[anteater321]

Hi, sorry ich bin Anfänger in Sachen iobroker (habe es hauptsächlich installiert, weil ich dieses Skript verwenden möchte) und ich bekomme es nicht richtig zum Laufen. Für Hilfe, woran es liegt, wäre ich sehr dankbar.

Das Skript habe ich eingefügt und die jeweiligen Daten eingegeben:

.

Auf der Skript-Seite scheint mir auch alles in Ordnung:

Das Log zeigt auf der Einstellung "silly" laufend viele Einträge an, aber das Skript nimmt keinerlei Einfluss auf die ausgegebene Leistung; die bleibt immer bei dem was in der App händisch eingestellt wurde. Weiß jemand, was ich falsch mache oder was ich hier einblenden muss, damit man es nachvollziehen kann?

[Dreffi]

@anteater321
Hast du das richtige Objekt mit dem State deines Stromzählers im Script angegeben?

[anteater321]

@dreffi danke für die Antwort. Ich habe aktuell nur einen Smartplug von Ecoflow eingebunden und sonst keine Daten. Aus der Erklärung des skripts erschien mir das optional. Wo muss ich denn den State im Script angeben? Hatte es jetzt mal mit dem folgenden Eintrag versucht, aber das funktioniert nicht:

SmartmeterID: "0_userdata.0.ecoflow.app_device_property_*******.data.plug_heartbeat_pack.watts", 

Im Debug-Modus erscheinen in regelmäßigen Abständen die folgenden Meldungen:

Ich möchte eigentlich erreiche, dass sich der vom Wechselrichter ausgegebene Strom im Wesentlichen nach dem von den Panelen eingehenden Strom richtet, aber ich vermute jetzt, dass das so nicht funktioniert? Ich wäre aber auch schon froh, wenn ich den SmartPlug integriert bekäme, um das Prinzip zu verstehen

[aherby]

@anteater321 Hi der Smartplug kann eigentlich nur ein- und ausgeschaltet werden und liefert Messwerte vom angeschlossenen Gerät also aktuelle Netzspannung, Strom, Leistung, etc.
Wenn du nicht den Powerstream als Gerät mit Seriennummer angibst kann das Script auch nichts steuern.
Weiter muss das Script doch einen Wert vom aktuellen Verbrauch bekommen damit es dynamisch regeln kann.
Sonst kann es villeicht die Prio "Strom" oder "Akku" umschalten wenn die Batteriegrenzen über oder unterschritten sind.

Was möchtest du genau erreichen und welche Geräte hast du verbaut?

[Waly_de]

@anteater321 sagte in ecoflow-connector-Script zur dynamischen Leistungsanpassung:

Ich möchte eigentlich erreiche, dass sich der vom Wechselrichter ausgegebene Strom im Wesentlichen nach dem von den Panelen eingehenden Strom richtet, aber ich vermute jetzt, dass das so nicht funktioniert? Ich wäre aber auch schon froh, wenn ich den SmartPlug integriert bekäme, um das Prinzip zu verstehen

Ich verstehe noch nicht ganz, was Du versuchst mit dem Skript zu machen. Wenn du mit SmartPlugs arbeitest, benötigst du das Skript eigentlich nicht. Wenn du möchtest, dass die eingespeiste Energie sich nach dem zur Verfügung stehenden Sonnenlicht richtet, benötigst du das Skript auch nicht.
Für eine "Null-Einspeisung" ist ein Smartmeter Grundvoraussetzung, dass dem Gesamtverbrauch Deiner Wohneinheit misst.
Zwar könntest du theoretisch auch die Ausgabe der Smart Plug als Smartmeter ID konfigurieren. Aber da die Smart Plug nur sehr selten Werte liefert und auch nur dann, wenn ein Gerät angeschlossen ist, und dieses seine Leistungsaufnahme ändert. Bekommst du die No Data Fehlermeldung. Da arbeitet die Smart Plug ganz ohne Skript, direkt mit dem PowerStream sicherlich viel besser.

[Waly_de]

@milchbeck guck mal im Beitrag. Das wurde schon einige Male angesprochen. Du kannst den Wert in den Einstellungen der Javascript-Instanz hoch setzten. Je mehr Geräte Du hast, um so höher muss der Wert konfiguriert werden. Vor allem die Deltas liefern Unmengen an Updates.
Wenn Du diese Daten nicht unbedingt brauchst, stelle in den Einstellungen für deinen Delta "subscribe" auf false.

[anteater321]

@waly_de @aherby vielen Dank für Eure Antworten:

Ich habe einen Powerstream, ne Delta 2 Max und einen Smart Plug von ecoflow. Ist bei mir im Skript alles mit Seriennummern und Zugangsdaten eingegeben. Habe hier nur Sterne als Platzhalter für den Screenshot eingesetzt.

Ich würde zunächst gerne das Prinzip verstehen und scheitere aktuell schon daran, den Smartplug zu integrieren. Ich weiß, dass der SmartPlug ohnehin automatisch in der Ecoflow-App berücksichtigt wird, mir geht es ums Grundverständnis (ich hoffe das lässt sich dann auf andere Smartplugs/ein Smartmeter übertragen).

Meine Frage zum Einstieg wäre, welchen Wert (Enum?) ich beim Eintrag SmartMeterID angeben muss, damit sich der Output des Powerstream nach dem SmartPlug richtet. Ich vermute es ist "0_userdata.0.ecoflow.app_device_property_****.data.plug_heartbeat_pack.watts", aber dann schaukelt sich der Output innerhalb von ein paar Minuten auf 500W hoch, obwohl am Smartplug ein Verbrauch von 30W ausgegeben wird.

[Waly_de]

"0_userdata.0.ecoflow.app_device_property_****.data.plug_heartbeat_pack.watts" liefert W * 10

10 Watt sind also ein Wert vom 100 in dem State.
Daher das Verhalten.

[Nils_1985]

Vielen Dank für den äußerst nützlichen Script. Ganz tolle Arbeit.....

Der Script läuft bei mir fast ohne Probleme.

Ich möchte gerne, dass bei 95% Akkustand automatisch in den Batterie-Prioritätsmodus gewechselt wird, sofern dieser nicht manuell in der Ecoflow schon eingestellt ist. Ich habe dazu den Wert 95 bei battPozOn eingetragen und battOnSwitchPrio auf true geändert. Nun ist mein Akku bei 99% und der Script schaltet in den Strommodus. Was dann leider dazu führen kann, dass der Akku leergesaugt wird. Da ich Tibber und daher einen dynamischen Strompreis habe, möchte ich den Akkustrom dann nutzen wenn der Preis hoch ist, vorher macht es keinen Sinn für mich.

Habe ich einen Denkfehler, sollte der Script nicht in dem Akkumodus bleiben? Anbei die Meldung aus dem Protokoll.

Und wann wird die Zusatzpower (tolle Funktion) ein- und ausgeschaltet? Bei dem Wert von battPozOff?

Hier würde ich mir wünschen, dass bei über 600 Watt Solarleistung 600 Watt in den Akku gehen und der Rest ins Netz, dass funktioniert aber leider nur im Strommodus. Gibt es eine Möglichkeit, dass dann bei einer Leistung von unter 600 Watt nur der Akku gespeist wird dann die Leistungsabgabe ins Netz auf 0 geregelt wird?

Viele Grüße

Nils

[anteater321]

@waly_de Danke für den Hinweis, hatte ich auch schon irgendwo im dem langen Thread gelesen, aber wieder vergessen.

Hab nochmal drauf geachtet, der Verbrauch kennt aber nur die Richtung nach oben (also deutlich mehr als Faktor 10). Auch wenn der Verbrauch bspw. auf 15 W absinkt, geht der Output nicht runter sondern hoch. Aber ich scheine der einzige mit dem Problem zu sein, muss also irgendwie an meinem Setup liegen.