mal eine ganz blöde Frage: Wieso sollte ich einen Flow über Node-Red benutzen anstatt einfach gleich das DESS von Victron?
Ich hatte vorher meinen eigenen Flow über Node-Red und ja klar, ich konnte die Werte so einstellen wie ich es wollte.
Aber jetzt probiere ich seit 2 Wochen DESS von Victron aus und ganz ehrlich: Mein Node-Red Flow bleibt deaktiviert und ich lasse das laufen.
Man merkt einfach wie das DESS perfekt auf die Victron-Sachen ausgelegt ist und diese demnach so steuert.
Aber ich lasse mich gerne davon überzeugen wieso den Umweg über Node-Red mit eigenen Flows..
Der Flow war quasi vor dem DESS da. Wir schalten die Multiplus automatisch bei Nichtverwendung ab und bei Bedarf wieder an um Energie zu sparen. Sind 100W in einem 3-Phasen System. Heute z.B. hat das 2,4 kWh gespart.
achso, lol, habe nur gesehen das der Beitrag neu oben hängt und garnicht gesehen wie alt der Ursprung ist .
Ja das mit dem Abschalten habe ich mit meinem Flow vorher auch gemacht. Ich wollte mich mal damit beschäftigen ob das nicht auf parallel zum DESS möglich wäre das zusätzlich anzusteuern, denn ja mir ist auch aufgefallen das die Multiplus ordentlich Energie im Standby fressen und bei mir sind am Ende auch mindestens 3 geplant.
Danke Codeworkx für die vielen Erläuterungen,
schlußendlich lag es genau an dem Löschen des Victron Laderegler-Flows und den nicht mit 14 sondern nur 13 Werten erwarteten Join vor der "ESS control logic" Funktion.
Echt cooler Flow, habe es auf Anhieb auch zum laufen gebracht. Habe aber auch ein MPPT zusätzlich am Laufen. Aktuell habe ich noch zwei Fragen.
Wenn ich es richtig verstanden habe, wird das Charge Fenster immer erst nach 17:00 Uhr bestimmt, charge_after. Wieso ist das so?
Was ist wenn, der Akku in der Nacht vollgemacht wird und morgens der MPPT den Akku nicht mehr laden kann, weil Discharge erst auf 16:00 Uhr gesetzt ist. Außerdem mache ich gegen 10 Uhr immer einmal ordentlich Wasser warm, was auch ein Peak verursacht. Das wird nicht in den Flows berücksichtigt, sprich nur der gesamte Konsum und daher auch keine Peaks, geschweige denn eine Autoladung.
Die Zeiten sind in den global Settings konfigurierbar.
Wenn der Akku voll ist würde der MPPT abregeln, der Flow würde dies erkennen und daraufhin die Entladung starten.
Der Flow versucht generell teure Stunden mit Strom aus günstigen Stunden zu ersetzen. Wenn der Strom morgens um 10 Uhr nicht wesentlich teurer ist als der Preis zu dem du geladen hast, macht es keinen Sinn zu entladen. Der Preis muss höher sein als der Preis im Akku x Unwandlungsverluste.
Wie kann ich denn die Forecast-Betrachtung des Verbrauchs bei der Verwendung einer Wallbox wieder "herausrechnen"? Ladevorgang des Autos geschieht mittels Tibber immer in den günstigsten Zeiten (meisten nachts) und soll natürlich nicht über das (teure) Akku abgedeckt werden, nur der Haushaltsstrom.
Zweite Frage geht auch um die Forecast-Beeinflussung: wir haben die Wärmepumpe mit Messkonzept 8 (Kaskadierung von WP und HS Zähler), was außer im Winter natürlich die Nutzung der WP über PV-Strom optimiert und aktuell trotz Zählergebühr noch günstiger ist, als alles über einen Zähler laufen zu lassen. Aktuell läuft hier über Nodered ein Flow, der prüft, ob über den HS-Zähler Strom ins WP-Netz eingespeist wird und setzt den max_discharge dann entsprechend rauf/runter (je nach Solar Forecast/ SOC), damit die WP den Akku nicht leerlutscht.
Also kurzum, hier geht es auch um die Beeinflussung des Forecasts, da der WP-Stromverbrauch hier natürlich auch berücksichtigt wird.
Jemand eine Idee oder schon eine (erfolgreiche) Umsetzung dazu im Umlauf gesehen/nachgebaut? Dann lasst es mich wissen
.