Was mir noch dazu einfällt: wie oft lässt du deine Automatisierung laufen? Auch alle 10 Sekunden wie ich, oder öfter?
Genau ich trenne dann den Powerstream von allem, netz, akku und solar. Dann stecke ich ihn wieder an und alles läuft top... Ich hab nen Ubiquiti Mesh am start, aber könnte ja das gleiche sein. Der Wechselrichter wird bei mir eigentlich nie in der App als Offline angezeigt...
Der Wechselrichter wurde recht warm daher liegt er jetzt auf der Plastik kappe, seitdem ist die Temperatur wesentlich besser. Das script führe ich mittlerweile nur alle 15sek aus, war erst bei 5, 10 und jetzt 15. Weil mein tipp auch irgendwie ist das sich die API verschluckt.
Noch ein komisches verhalten was mir gerade wieder einfällt, manchmal kann ich dann per app den verbrauch auf 0 stellen aber ein paar sekunden danach bekommt er wieder 600W vorgeschrieben, als ob wirklich irgendwo das script oder die API hängt, oder halt der Wechselrichter...
Noch ein komisches verhalten was mir gerade wieder einfällt, manchmal kann ich dann per app den verbrauch auf 0 stellen aber ein paar sekunden danach bekommt er wieder 600W vorgeschrieben, als ob wirklich irgendwo das script oder die API hängt, oder halt der Wechselrichter...
Das Verhalten habe ich prinzipbedingt immer, wenn ich einen hohen Verbrauch hatte, aber nicht genügend Solarleistung oder Speicher: dann regelt das Script den Haushaltsbedarf halt immer auf Maximum hoch, kann es aber nicht liefern. Sobald dann genügend Einspeiseleistung zur Verfügung steht, regelt er sich wieder ein auf den tatsächlichen Verbrauch.
Genau ich trenne dann den Powerstream von allem, netz, akku und solar. Dann stecke ich ihn wieder an und alles läuft top... Ich hab nen Ubiquiti Mesh am start, aber könnte ja das gleiche sein. Der Wechselrichter wird bei mir eigentlich nie in der App als Offline angezeigt...
Der Wechselrichter wurde recht warm daher liegt er jetzt auf der Plastik kappe, seitdem ist die Temperatur wesentlich besser. Das script führe ich mittlerweile nur alle 15sek aus, war erst bei 5, 10 und jetzt 15. Weil mein tipp auch irgendwie ist das sich die API verschluckt.
Hm, dann kann ich nur raten es mal eine Weile laufen zu lassen, ob es sich wieder fängt. Weil wenn er in der App nicht als offline angezeigt wird, scheint er ja noch zu laufen.
Was du temporär noch machen kannst, ist das Debug-Logging einzuschalten, so wie am Ende des Readme.md im Github des Scripts erklärt ( allerdings steht da, man soll den Logging- Ausschnitt im automation.yaml einfügen, es muss aber ins configuration.yaml). Nach Neustart des Home Assistant kannst du dann mit dem FileEditor das Logfile anzeigen lassen und prüfen, was das Script rausloggt (der Watt-Wert ist immer x10, d.h. bei 600W wird 6000 gesendet). Da das Script ja auch den eingestellten Wert abfragt, sieht man zumindest indirekt ob die Cloud da ist.
Später nicht vergessen, das Logging wieder abzuschalten (also die Einträge wieder rausmachen), sonst ist irgendwann deine SD-Karte voll, wobei des Logging rollierend eingestellt sein kann, das habe ich nicht überprüfen können. Sicher ist sicher 
Das script führe ich mittlerweile nur alle 15sek aus, war erst bei 5, 10 und jetzt 15. Weil mein tipp auch irgendwie ist das sich die API verschluckt.
Hm, ich hätte gedacht, dass bei zu häufigem Ausführen so eine Art Schutz vor durchdrehenden Apps greift, aber ich führe mein Script jetzt ja permanent alle 10 Sekunden aus ohne dein Verhalten zu beobachten.
Schwierig so etwas zu debuggen …. 
Gute Idee mit dem Loggin und ja ist nicht einfach sowas zu debuggen...
2024-05-03 20:35:30.403 DEBUG (MainThread) [custom_components.pyscript.eval] file.set_ef_powerstream_custom_load_power.set_ef_powerstream_custom_load_power: calling executor(<function put at 0x7fa8110040>, " Link entfernt ", {'headers': {'accessKey': 'xxx', 'nonce': '592355', 'timestamp': '1714761330391', 'sign': 'xxx'}, 'json': {'sn': 'xxx', 'cmdCode': 'WN511_SET_PERMANENT_WATTS_PACK', 'params': {'permanentWatts': 6000}}})
2024-05-03 20:35:30.431 INFO (Thread-5 (_thread_main)) [custom_components.ecoflow_cloud.mqtt.ecoflow_mqtt] Unsupported EcoPacket cmd id 4
2024-05-03 20:35:30.431 INFO (Thread-5 (_thread_main)) [custom_components.ecoflow_cloud.mqtt.ecoflow_mqtt] Found another frame in payload
2024-05-03 20:35:30.432 INFO (Thread-5 (_thread_main)) [custom_components.ecoflow_cloud.mqtt.ecoflow_mqtt] Found 3 fields
2024-05-03 20:35:30.581 DEBUG (MainThread) [custom_components.pyscript.eval] file.set_ef_powerstream_custom_load_power.set_ef_powerstream_custom_load_power: calling json(, {})
2024-05-03 20:35:31.555 INFO (Thread-5 (_thread_main)) [custom_components.ecoflow_cloud.mqtt.ecoflow_mqtt] Unsupported EcoPacket cmd id 32
2024-05-03 20:35:32.476 INFO (Thread-5 (_thread_main)) [custom_components.ecoflow_cloud.mqtt.ecoflow_mqtt] Unsupported EcoPacket cmd id 4
2024-05-03 20:35:32.476 INFO (Thread-5 (_thread_main)) [custom_components.ecoflow_cloud.mqtt.ecoflow_mqtt] Found another frame in payload
2024-05-03 20:35:32.477 INFO (Thread-5 (_thread_main)) [custom_components.ecoflow_cloud.mqtt.ecoflow_mqtt] Found 2 fields
2024-05-03 20:35:34.421 INFO (Thread-5 (_thread_main)) [custom_components.ecoflow_cloud.mqtt.ecoflow_mqtt] Unsupported EcoPacket cmd id 4
2024-05-03 20:35:34.421 INFO (Thread-5 (_thread_main)) [custom_components.ecoflow_cloud.mqtt.ecoflow_mqtt] Found another frame in payload
2024-05-03 20:35:34.422 INFO (Thread-5 (_thread_main)) [custom_components.ecoflow_cloud.mqtt.ecoflow_mqtt] Found 3 fields
2024-05-03 20:35:36.467 INFO (Thread-5 (_thread_main)) [custom_components.ecoflow_cloud.mqtt.ecoflow_mqtt] Unsupported EcoPacket cmd id 4
2024-05-03 20:35:36.467 INFO (Thread-5 (_thread_main)) [custom_components.ecoflow_cloud.mqtt.ecoflow_mqtt] Found another frame in payload
2024-05-03 20:35:36.468 INFO (Thread-5 (_thread_main)) [custom_components.ecoflow_cloud.mqtt.ecoflow_mqtt] Found 2 fields
2024-05-03 20:35:37.183 INFO (MainThread) [aioshelly.rpc_device.wsrpc] Connected to 192.168.1.138
Das kommt dabei raus, bin mir aber gerade unsicher was das bedeutet.
@kefff Ich habe jetzt mal versucht, deinen log-output mit dem Script in Verbindung zu bringen, und da das nicht passt habe ich folgende Vermutung:
1. In der Lösung von Mr.Togi wurde ja noch zusätzlich eine Ecoflow-Integration installiert und benutzt, die man meiner Meinung nach nicht braucht.
2. Genau daher scheinen die Fehlermeldungen zu kommen: hier habe ich - soweit ich mich erinnere - beim Googeln auch schonmal das Problem gelesen, dass sie immer mal wieder neu gestartet werden muss.
3. Bei mir hatte ich die Integration zwar kurz installiert, aber - nachdem ich gemerkt hatte dass ich sie nicht brauche - wieder deaktiviert:
Liege ich mit meiner Vermutung richtig, dass bei dir die Ecoflow-Integration aktiv ist? Wenn ja - und du sie nicht brauchts - deaktiviere sie doch mal und schaue, ob das Problem weiter auftritt.
D.h. verwendest du die Lösung von Mr.Togi, oder hast du meine Lösung gewählt?
Genau bei mir ist die EcoFlow Clodd integration aktiv und ich benutzte sie tatsächlich auch :/
Ich benutzte das pyscript von svenerbe.
@kefff Vielleicht kommen sich die Ecoflow-Cloud Integration und das Script in die Quere, z.B dass die Ecoflow Integration hängt und dadurch auch das Script nicht mehr gut funktioniert, ich kann hier nur Vermutungen anstellen.
Wenn du meine Beschreibung hier ( https://www.akkudoktor.net/forum/postid/204585/) genau durchliest, braucht man meiner Meinung nach mit der aktuellen Version des Scripts die Ecoflow-Integration nicht für die Nulleinspeisung über den periodischen Trigger.
D.h. wir fahren halt leider nicht dasselbe Setup.
Was ich dir sonst noch empfehlen könnte: Google doch mal, ob und wie man eine Integration periodisch alle 10 Stunden neu starten kann: wende dies dann auf die Ecoflow-Integration an, vielleicht hilft das ja auch anstatt dass du den Powerstream neu starten musst.
Mehr fällt mir jetzt dazu nicht ein.
Ich bin trotzdem an einer Problemlösung interessiert, da ich mittelfristig zu einer besseren Regelung weg von periodischer Triggerung mehr durch Sensorwerte-basierter Triggerung hin will. Und da wäre die Ecoflow-Integration natürlich interessant um z. B. den Akkustand miteinzubeziehen. Vielleicht bekommt man das aber auch mit einer abgeänderten Version des Scripts von svenerbe hin. Mal schaun wann ich wieder Zeit habe …..
Was ich jetzt noch gesehen habe (falls es tatsächlich zur Überhitzung kommt), ist folgendes Zubehör:
https://de.ecoflow.com/products/smart-cooling-deck
(oder auch beim großen Fluss: Smart Cooling Deck)
Das Verhalten habe ich prinzipbedingt immer, wenn ich einen hohen Verbrauch hatte, aber nicht genügend Solarleistung oder Speicher: dann regelt das Script den Haushaltsbedarf halt immer auf Maximum hoch, kann es aber nicht liefern. Sobald dann genügend Einspeiseleistung zur Verfügung steht, regelt er sich wieder ein auf den tatsächlichen Verbrauch.
Hierzu ein kleiner Hinweis, ich weiß nicht ob du meine Issues in GitHub gesehen hast. Ich habe das Script entsprechend an zwei stellen angepasst:
https://github.com/svenerbe/ecoflow_dynamic_power_adjustment/issues/9
Hintergrund ist auch die unnötige Regelung wenn z.B. mehr Solar kommt (Battiere voll und dann Einspeisung erfolgt), dass er den Bedarf auf 0 in Schritten regelt und wenn dann ne Wolke kommt und Solar wegfällt er mehrfach in Schritten hoch regelt und nicht direkt den richtigen Wert vorgegeben bekommt.
Ich frag also nicht mehr den aktuellen Permanenten Einspeisewert (Grundbedarf ab) sondern den aktuell eingespeisten tatsächlichen Wert und verrechne hierzu die Differenz vom Zähler.
Aktuell eher im Bereich BKW aktiv. Einrichtung mehrere BKW (Hoymiles / EcoFlow / Nulleinspeisung).
Selbst ein BKW mit 4kWp und 5kW/h Akku im Betrieb und Tibber Kunde.
@ps2aich Ist gibt einen Schutz, meine bei 15 Anfragen die Minute, also unter /10 sollte man nicht gehen, da erst der Wert abgefragt und dann neu gesetzt wird.
Mit zusätzlich Tibber Cloud würde ich dir empfehlen auf alle 15 Sekunden zu gehen. Du musst bedenken, du erhälst einen Wert vom Zähler, dann setzt du die Einspeisung neu, dann muss der WR nachregeln, der Zähler seine Werte ändern und dann noch über die Tibber Cloud der Wert zurück. Ich kann mir vorstellen, dass bei 10 Sekunden es häufiger dazu kommt, dass Anpassungen doppelt erfolgen, weil der neue Zählerwert noch nicht vorliegt und dann ist es auf einmal zu viel.
Aktuell eher im Bereich BKW aktiv. Einrichtung mehrere BKW (Hoymiles / EcoFlow / Nulleinspeisung).
Selbst ein BKW mit 4kWp und 5kW/h Akku im Betrieb und Tibber Kunde.
@ps2aich Ob Ecoflow Cloud (nutzt auch nur die Api) oder Anpassung von Svenerbe Script, beides möglich.
Der Batteriestand ist durchaus relevant für die Planung der Steuerung, gerade bei dynamischen Preisen. So kannst du z.B. wenn Akku nicht voll ist, aber Preise später stark steigen, lieber die Einspeisung auf 0 setzen, damit alles in den Akku geht und dann einspeisen, wenn es teuer ist.
Bzgl. Lüfter, man kann auch günstigere Lüfter mit USB nehmen, wenn es nicht auf die Optik ankommt 😉
Aktuell eher im Bereich BKW aktiv. Einrichtung mehrere BKW (Hoymiles / EcoFlow / Nulleinspeisung).
Selbst ein BKW mit 4kWp und 5kW/h Akku im Betrieb und Tibber Kunde.
PS. Hab noch etwas an dem Script angepasst:
https://github.com/svenerbe/ecoflow_dynamic_power_adjustment/issues/5
So kann ich anstatt nur 0 Watt einen konstanten Wert vorgeben.
Aktuell eher im Bereich BKW aktiv. Einrichtung mehrere BKW (Hoymiles / EcoFlow / Nulleinspeisung).
Selbst ein BKW mit 4kWp und 5kW/h Akku im Betrieb und Tibber Kunde.
Das Verhalten habe ich prinzipbedingt immer, wenn ich einen hohen Verbrauch hatte, aber nicht genügend Solarleistung oder Speicher: dann regelt das Script den Haushaltsbedarf halt immer auf Maximum hoch, kann es aber nicht liefern. Sobald dann genügend Einspeiseleistung zur Verfügung steht, regelt er sich wieder ein auf den tatsächlichen Verbrauch.
Hierzu ein kleiner Hinweis, ich weiß nicht ob du meine Issues in GitHub gesehen hast. Ich habe das Script entsprechend an zwei stellen angepasst:
https://github.com/svenerbe/ecoflow_dynamic_power_adjustment/issues/9
Hintergrund ist auch die unnötige Regelung wenn z.B. mehr Solar kommt (Battiere voll und dann Einspeisung erfolgt), dass er den Bedarf auf 0 in Schritten regelt und wenn dann ne Wolke kommt und Solar wegfällt er mehrfach in Schritten hoch regelt und nicht direkt den richtigen Wert vorgegeben bekommt.
Ich frag also nicht mehr den aktuellen Permanenten Einspeisewert (Grundbedarf ab) sondern den aktuell eingespeisten tatsächlichen Wert und verrechne hierzu die Differenz vom Zähler.
Wenn ich deine Ausführung richtig verstanden habe, hast du die Einspeisekontrolle ausgeschaltet im Powerstream, ich aber habe sie extra wieder aktiviert, damit die Automation nicht verwirrt wird.
Ich schaue mir das mal genauer an, sobald ich wieder Zeit investieren kann.