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:
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.
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.
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?
@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.
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 …..
Hierzu ein kleiner Hinweis, ich weiß nicht ob du meine Issues in GitHub gesehen hast. Ich habe das Script entsprechend an zwei stellen angepasst:
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.
@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.
@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
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.
Bevor ich die Fehlerlogs bei Kefff gesehen habe, bin ich auch davon ausgegangen, das Integration und Script gleichzeitig laufen können sollten, hier kann ich aber aus meinem Kenntnis-Stand nur raten, ich habe mir die Integration im Detail nicht angeschaut.
Und ja, so eine Vorrausschauende Planung mit Akkustand und Strompreisen ist eine Optimierung, die auch die MachineLearning-gestützte Lösung von Andreas - wenn ich das Video richtig verstanden habe - nutzt.
Da mein Speicher aber seeehr klein ist (1kwH) habe ich da Grenzen {green}
Das mit dem Ecoflow-Lüfter fand ich erst überraschend, aber Marc hat es sogar in einem der letzten Videos erwähnt, dass es da u. U. Überhitzungen gibt beim Powerstream.
da hast Du dir ja richtig Mühe gemacht! Ich kenne das Skript schon einige Zeit und habe damit "rumgespielt" es ist ein guter Start und geht in die richtige Richtung. Für einen Ersten Aufschlag und auch für Anfänger / Neulinge bei HAS und HACS leicht umzusetzen.
Allerdings hat es m.E einige Nachteile, die das ioBroker Skript nicht hat. Zum Beispiel die Kontrolle über die Deltas, feinere Regelung, mehr Möglichkeiten wie der Akku angesprochen werden soll, die Einbindung von SmartPlugs,... die Reglung läuft auch weicher.
Wer einen HAS laufen hat, der kann einfach einen ioBroker auf einem 2. Gerät laufen lassen und HAS hinzufügen und das ioBroker Skript nutzen (für alle die mehr Flexibilität und mehr Kontrolle haben möchten)
Viel Erfolg und Danke für deine Anleitung, das hilft sicherlich vielen weiter!
Ein wichtiger HINWEIS:
Grundsätzlich gilt, wer via Dev-Account oder per Skript die Cloud anspricht, sollte es vermeiden die Eco-Flow App zu häufig zu nutzen. Die requests gehen teilweise in 3000 (!!) das kann zum Hängen oder Absturz des PS oder HAS führen.
Wie sieht es eigentlich mit nem Android Tablet aus, der im Smart Home integriert ist. Kann man da was zusammenbasteln anstatt Raspberry Pie? Python kann auch Android, oder eben irgendwie über Java mit ne APK?
Und was passiert eigentlich wenn die PV Anlage mehr Strom liefert, als der Script einspeisen möchte - angenommen der Speicher ist voll, Einspeisung ist auf 100W gesetzt wegen zu wenig Last und dann will die Anlage aber 500Watt über den Powerstream schieben, schmiert mir die Powerstream ab?
Ich beantworte mir selbst die Frage - die Leistung bleibt im Panel und er beginnt im Infrarot Bereich zu leuchten.
Daher muss hier auch ein IF eingebaut werden, dass wenn die Ausgangsleistung > als die Einspeisung ist (eventuell auch Batteriespeicher über 100% wenn man das auslesen kann?), dann die Ausgangsleistung trotzdem eingespeist wird, egal was der Skritp sagt und was im Haus verbraucht wird.
Ja, das habe ich inzwischen auch erkannt, das fehlt komplett in meiner Minimallösung, mal schaun ob ich dazukomme, das zu erweitern bevor es so richtig heiß wird draußen.
Super, vielleicht kannst du deinen Script teilen, wenn soweit ist. Mein Speicher wird sich verspäten. Hast du auch Zugriff auf den Batterie Zustand über den Ecoflow Automat ?
Und übrigens, was passiert eigentlich wenn die Leistung mehr als die Einspeisung ist aber die Batterie nicht voll ist - wird alles in die Batterie geschoben, automatisch, oder muss man hier in der Ecoflow App was einstellen?
Ja, wenn man zusätzlich die inoffizielle Ecoflow-Integration installiert. Vielleicht geht es auch durch selbsterweitern des Python-Scripts, wenn man mehr Arbeit reinsteckt.
Du kannst dich gerne dran versuchen, oder dir mal die Erweiterungen vom Forumskollegen @mhltheone weiter oben anschauen
Kommt drauf an, was du in der App eingestellt hast (Speicher oder Stromversorgung priorisieren),.
Bei ,Stromversorgung priorisieren' wird überschüssige Leistung in den Akku geschoben. So betreibe ich das auch, die andere Priorisierung habe ich nie getestet gegen meine Minimallösung: dürfte nicht gut funktionieren.
Sobald der Akku voll ist, kommt es darauf an, ob die Einspeise-Kontrolle aktiv ist.
Meine Minimallösung funktioniert nur gut wenn sie aktiv ist, dann wird -wie schon erwähnt- die überschüssige Energie nicht abgenommen und in den Pannels in Wärmeenergie umgesetzt.
Wenn Sie nicht aktiv ist, wird überschüssige Energie einfach eingespeist, auch über den Haushaltsstromverbrauch hinaus.
Was genau bewirkt sie? Ich verstehe nicht so ganz was da gesagt wird, vielleicht Übersetzungsfehler?
So wie da steht, müsste bei "Einspeisekontrolle" auf "An" bei voller Batterie die komplette PV Leistungs ins Netz geleitet werden, auch wenn sie über den voreingestellten Strombedarf liegt. Wie wird aber damit verhindert, dass überschüssigen Strom ins Netz eingespeist wird, wenn genau das passiert?
Ich glaube da wird etwas nicht richtig kommuniziert was "An" und was "Aus" bedeutet.
@balkonsolarundspeicher Das funktioniert genau so wie beschrieben. Nur das Wort 'Einspeisekontrolle' fand ich anfangs irritierend und hatte genau die gleichen Probleme wie du, den Satz dazu korrekt zu verstehen.
In deinem Screenshot ist die Einspeisekontrolle desaktiviert: d.h. die Einspeisung erfolgt ohne Kontrolle, d.h. der maximal erzielbare Solarertrag wird eingespeist.
Wenn aktiviert, wird die Einspeisung 'kontrolliert', d.h. nur soviel eingespeist wie eingestellt.
Die Frage ist tatsächlich wie ein anderes einzelnes deutsches Wort dies besser ausgedrückt hätte.
Tatsächlich müsste das dann auf AN stehen, wenn man nicht zu viel einspeisen würde. Wieso will @mhltheone die Einstellung auf aus haben, damit er die Problematik mit den heißen Panellen vermeidet?
Im Prinzip macht er was doppelt, wenn ich das richtig verstehe - er baut ein Automat, der genau das macht, was diese Einstellung auf AN bewirkt? Stellt sie aber auf Aus und macht dasselbe über den Script? Oder verstehe ich seinen Einsatz hier nicht?
Verstehe nicht so ganz was er da geändert hat und wo der Unterschied invOutputWatts zu permanentWatts besteht. permanentWatts ist wahrscheinlich der eingestellte Wert in der App für den Haushaltsbedarf?
