Hallo Jens, ich bin gerade vor der Arbeit am Rechner (ca. Min 14) und muss zwei Anmerkungen loswerden. Erstens: Du must deinen Strompreis für die Akkuladung zeitlich dynamisieren. Sonst kannst du in eine Situation kommen, wo du nicht mehr entlädst, da du mal relativ teuer geladen hast. Diesen Deadlock gilt es zu vermeiden. Z.B dadurch, dass du den Strom im Akku jeden Tag um einen gewissen Prozentsatz preiswerter kalkulierst. Irgendwann entlädt er dann wieder. Zweitens: Wenn der Akku groß genug ist, einfach nicht voll laden. Die Reserve sollte als Puffer reichen, wenn doch mal mehr vom Dach kommt als erwartet. Du brauchst nicht die gesamte Akkukapazität, wenn du nicht ständig entlädst. Eine Denksportaufgabe habe ich noch: Was ist wichtiger beim Entladen? Hoher Preis und geringer Verbrauch oder Durchschnittspreis und hoher Verbrauch. Ich weiß auch noch nicht wie ich das berücksichtigen soll. Bin mir aber ziemlich sicher, dass man den Verbrauch nicht unberücksichtigt lassen kann.
Danke dir, guter Input! zu 1. Ja, kommt - jetzt wo die Möglichkeit da ist :). Aber erstmal die Reihe mit dem aktuellen Stand zuende machen. zu 2. Jup, es sei denn, der Preis ist supidupigünstig - Teil 2 ist grad abgedreht, da gibts vielleicht ein wenig Aufklärung, und genau den Einwand hab ich da auch gebracht (weil ich da wirkich bis 100% voll mache). Da braucht es ggf. doch noch nen PV-Prognosen-Override. Zur Denksportaufgabe: das wäre ja der "Peak Shaving" Ansatz und Lastverschiebung. In den NL defintiv lohnenswert. Und mit kommenden dynamischen Netzentgelten vielleicht auch zukünftige Herausforderung. Aber lohnt sich halt nur, wenn der Preisunterschied groß genug ist (Thema Verluste). Da sind wir dann teils wieder bei 1./2. und auch einer möglichen Verbrauchsprognose. Vor dem Hintergrund, dass man Lasten direkt ansteuern kann (Wärmepumpe, BEV laden) - Peak Shifting - ohne dem Umweg über den Speicher zu gehen: jaaa, das muss man holistisch sehen (ganzheitlich - extra holistisch genommen, ich mag Douglas Adams "Dirk Gently" - Lesetip).
Da gehts ja weiter 😀 . Ich freue mich ! Zur Zeit lasse ich das DESS von Victron laufen und versuche die Logik zuverstehen. Jetzt zum Beispiel: Tibberstrom kostet 26cent, Akku 55% voll und der MP2 versorgt das Haus mit Netzstrom. Heute Mittag soll der Strom irgendwann 32 cent kosten. Da wird er bestimmt wieder vom Akku lutschen. Für mich ist das alles ein wenig undurchsichtig. Und deswegen freu ich mich auf dein fertigen Flow 🙂. Zu 22:30 : Nein du machst das genau richtig. Das Normalos wie ich das auch gebacken kriegen 😉 Bewerb dich mal bei Victron . Ich glaub die brauchen so Leute wie dich 😉
Merci - 2. Teil ist grad auch im Kasten... Puuh. Victron hat schon die richtigen Leute - das Thema ist aber echt sehr komplex und imo individuell. Wenn es einfach wäre, wäre Victron längst fertig :).
@@fldutch Da hast du Recht ! Ich habe heute mal angefangen und den Flow importiert. Einige Nodes , wie den Battery Monitor musste ich rauslöschen, neu einfügen und mit meinem Seplos BMS konfigurieren. Auch den Teilflow von deinem Phönix kann ich doch ohne Probleme da rauslöschen, oder?
Man muss halt auch die Ladeverluste im Auge behalten. Wenn ich den Akku 6 Stunden mit 21A lade und dann wieder entlade hat man 2 mal Umwandlungsverluste. Somit muss der Preis unterschied schon sehr hoch sein damit man dies ausgleicht und günstiger kommt.
Bin gespannt wie´s weitergeht. Hab das auch mit NodeRed gelöst, aber bspw. bisher keine PV-Vorhersage drin. Hab einfach 3 Preisbereiche definiert: Billig = die 6 billigsten h eines Tages, Günstig = alles unter Mittelpreis des Tages, Teuer = alles über Mittelpreis des Tages. Und für jeden Preisbereich einen Schieberegler für den SOC: also wann laden / wann entladen. Aktuell jetzt im Winter fahre ich mit 100%/65%/45%, alles drunter ist noch Reserve. Will das nun 1 Jahr laufen lassen & mit den Reglern spielen, dann kann ich evtl. die Schieberegler ersetzen durch die gewonnenen Erfahrungswerte. Neulich am Wochenende waren mal tagsüber die billigsten h (eher selten) - also wurde der Speicher vollgeknallt, das eingehende Solar mußte dann verkauft werden - nicht optimal, aber das sind seltene Zustände wie ich meine. Da wäre an diesem Tag wohl SOC 80% statt der 100% für die Billig-Zeit besser gewesen. Man kann sich hier zu Tode optimieren oder einfach eine 80/20 Regel versuchen...andererseits macht das Ganze ja auch Spaß...kann also gut sein, daß ich Deinen PV-Vorhersageansatz auch einbauen werde. Ach ja: 13,3kWp Nord 22Grad plus 2,25kWp Süd senkrecht, 50kWh Speicher, Deye Hybrid 12kW, Tibber dynamisch
Für mich klappt es am besten damit, einmal pro Tag 2 Werte einzugeben, Lade-Preis und Entlade-Preis. Dies per AI, Regeln oder sonstwie zu lösen ist zu aufwendig. Und, diese 5 Minuten pro Tag um mich mit den 2 Werten zu beschäftigen, habe ich.
Gut erklärt. Vermutlich werden die Leute nur nicht mehr die alte InfluxDB im Einsatz haben sondern die 2.x. Mich würde mal dein Grafanaboard interessieren kannst du das auch zur Verfügung stellen. Den Flow in Node Red haben ich angepasst auf die InfuxDB 2.x Daten kommen rein. Sehr gut.
Alter SQL Hase halt - da war Influx 1.8 halt naheliegend. Mal sehen, ob ich da nochmal auf 2.x oder höher umsteige. 2.x hat halt neben der neuen Query Language auch den Vorteil, dass Monate bekannt sind. Grafana Dashboard soll es auch weitergehen. Erstmal die Node Red Reihe nu fertig machen.
@@fldutch Sollte bei Tibber Preise Abholen und in die DB schreiben in der DB nicht Werte zu sehen sein ? Wenn ich den Trigger starte werden zwar werte geholt das sehe ich im Debug aber in DB unter Testing_only ist nichts drin zumindest nicht im Influx Data Explorer.
@karstenm6042 Es könnte sein, dass du das anders aufbereiten musst? Bei InfluxDB 2.0 bin ich leider aktuell raus, hätte auch keine Testinstanz am Start. Ggf ist nicht nur das measurement abzufragen sondern auch nach dem konkreten „Feldnanamen“ zu suchen? Fehlermeldung vom Influx Node bekommst du nicht?
Verfolge das Thema schon länger, habe deine "Tibber macht den Akku voll" im kleinen bei mir laufen ;-) Und verfolge nun auch diese Variante... freue mich auf die nächsten Teile. Stellst du vielleicht auch die Grafana Dashboards zur Verfügung? Danke dir!
Benutz solcast API für pv Forecast, dann lass die letzten 5-15 Tage forecast solcast / wirklich produziert den Ration ausrechne. Dann der KPI generiert über zb ein Exponential Moving Average rechnen lassen und dann hast du den faktor fur den neuen berechneten Forecast. Liege simlich genau, im winter sieht man auch in den EMA wie der faktor den neue Forcast Richtung null (Schnee zb) geht (automatisch) Forecast neu = EMA(Array(FC Solcast/Real Produktion))*Forecast Solcast
Spannender Ansatz. Solcast hab ich hier teils auch drin (kommt in Teil 3 ggf.) - vor allem als Vergleich. Victron basiert mittlerweile auch auf Solcast Prognose mit "Machine Learning" drübergebügelt. In welcher Region in Deutschland befindest du dich? Wenn weiter im Süden: euer Wetter ist imo ein wenig stabiler als hier im Nordwesten. Da liegt auch Victron fix mal massiv daneben, wenn sich die Wolken oder Hochnebel schneller/anders/langsamer vorschieben als gedacht.
@@fldutch München. Muss sagen ich treffe Recht gut das estimated Wert. Bei mir pendelt der Faktor von 0.55-0.65, bedeutet Solcast sagt zb 20kwh und KPI sagt 0.5 sollte ich ca 10kwh produzieren können und liege hier ca +/- 1 kWh von 10kwh Abweichung, ich würde sagen max 20%. Dazu wiegsagt nutze ich nicht nur den reinen Verhältniszahl aber lasse es über den Indikator einmal durchjagen so dass Vergangenheit eine Rolle spielt. Ich nutze aber 2 Weschelrichter, einmal der Haupweachlerrichter (SunGrow mit 16 kWh Speicher) dazu ein DEYE Sun 12 Niederigvolt mit 4*5,12 kwh. Hier wird es etwas komplizierter da ich ja aufpassen muss dass beide gleichzeitig Laden sonst ist es Ping pong von laden. Ich Steuer dass alles über Modbus. Alles per HA und NR
@@europer67 Für München sollte das Modell so sicherlich passen :). Ich glaub ich muss da wirklich mal diverse Modelle laufen lassen und dann Treffgenauigkeit rechnen - das ist schon im Hinterkopf.
@@fldutch Solcast hat 10 pull per day aber ich habe Ost und West Ausrichtung und Teile mein Dach in 2, hab dann nur 5 Pulls (2*5) und gibt bessere Ergebnisse als sollte ich alles über eine Fläche zb gewichtet gerechnet von kwp, Neigung, Ausrichtung. Nur als Hinweis
@@europer67 Merci - ja, ist bekannt. Für zuhause wird das nicht funzen, da es im Endausbau viele Flächen geben wird. Da wird Victrons System die einfachste Lösung werden.
Ich mache das über Home Assistent, allerdings mehr händisch als über Automationen. Da das ganze Recht selten passiert kann ich das halbautomatisch besser händeln. Ich habe natürlich auch eine PV Prognose in HA aber so richtig begeistert bin ich damit nicht. Ebenfalls habe ich natürlich alle Daten zum Speicher auch im System (HA) und somit wäre eine komplette Automation auch realisierbar.
Moin, ich bin gerade dabei mir die ganze sache mal anzunehmen und frage mich, muß ich grafana mit installieren und geht das dann auch auf dem Cerbo gx noch mit drauf?
Für das ein oder andere bräuchte es ggf. leider doch Influx-DB. Könnte man aber bestimmt umschreiben um ohne auszukommen. Influx und Grafana würd ich aufm Cerbo GX eher nicht machen.
@@fldutch habe gerade meinen raspy vom victron entfernt und wollte da home assistant drauf testen. Wäre da vielleicht die Möglichkeit noch für die Datenbank? Aber da sehe ich die Frage, wie die Daten hin und herwandern.
@roywobser5036 Daten übers Netzwerk sollte ja kein Problem sein ;). Ob man parallel zu HA noch zumindest ne InfluxDB (1.x) installieren kann gute Frage. Kurze Suche: www.home-assistant.io/integrations/influxdb/ - sollte gehen? Wichtig: nicht 2.x installieren sondern 1.x - sind unterschiedliche Abfragesprachen 🫣. 1.x mit FluxQL ist eher SQL Style, Fluxx aus 2.0 total anders und nicht kompatibel. Für 3.0 gehts dann zurück zu FluxQL 🤷🏻.
@@fldutch ich glaube ich gehe dann doch lieber jeden tag und programmiere die Zeiten zum laden von Hand. Nein War ein Spaß. Aber es muß erst verstanden werden, bevor man da etwas auf seine Bedürfnisse umändern kann.
@@roywobser5036 Jup :). Andreas (Akkudoktor) ist übrigens auch dran, dito Victron mit Dynamic ESS. Ich wollt halt net so lang warten - es muss auch nicht zu 100% passen bzw. optimal günstig sein - die Unwägbarkeiten bei Prognosen machen dir eh nen Strich durch die Rechnung ;).
ohne verbrauchsprognose ist das doch alles halbgar. finde node-red auch viel zu umständlich, auch wenn ich den reiz, code zu visualisieren, nachvollziehen kann. ich hab mir das klassisch zusammenprogrammiert und erst mit verbrauchs- und solarprognose brauchbare ergebnisse erzielt. vermutlich weil der verbraucher "wärmepumpe" ziemlich dynamisch ist (außentemperatur). die grundlast abbilden kann man natürlich auch mit einer konstanten verbrauchsprognose. richtig interessant wird es, wenn man stunden überbrücken kann die weder von pv noch akku abgefangen werden können. z.b. strom zum günstigsten zeitpunkt ist X und reicht um die 3 teuersten stunden Y1,2,3 zu überbrücken und speicher ist groß genug um das abzufedern. dann gibt es aber noch die "wendepunkte" die zu teuer sind, im vergleich zur zwangsladung + verlusten, aber auch nicht günstig, sodass man gerne trotzdem so wenig wie möglich verbrauchen möchte (=aus dem netz beziehen) und somit die wärmepumpe 1-2h auf idle schickt. geht natürlich nur, wenn man sowieso wärmekapazitätspuffer bei der wärmepumpe hat. entweder weil sie sowieso taktet und die wärme über 24h nicht abgeben kann oder warmwasserpuffer mit vorheizen oder einfach 1-2 kühle stunden aushalten möchte.
Ja, da liegst du schon richtig :). Das klassisch zu programmieren ist natürlich am sinnvollsten, braucht aber noch mehr Zeit und KnowHow - Node Red war der Weg des geringsten Widerstandes - dann auch im Hinblick auf Videos und Nachvollziehbarkeit. Je mehr Faktoren da eine Rolle spielen, desto komplexer es wird, desto schwieriger wird es, das abzubilden. Wie schon geschrieben: es ist aktueller Status. So weit wie du bin ich da leider noch nicht. Aber das wird ne spannenden Reise, sobald nicht nur hier im Büro sondern dann im Laufe des Jahres auch die PV, Speicher, Brauchwasserwärmepumpe und BEV zuhause einziehen. Was die Verbrauchsprognosen angeht: wie rechnest du die? So ne grobe Idee wäre spannend.
Kommt noch… Erstmal den aktuellen Stand aufarbeiten ;). Ausserdem geht das nur mit nem Victron System. Mit Forecast.Solar oder Solcast ist es ein wenig universeller. Victron läuft hier im Monitoring aber schon mit. Trefferquote ist gefühlt definitiv besser, gibt aber natürlich auch noch wetterbedingte „Ausrutscher“.
@@fldutch ich nutze aktuell folgende Node zur Strategie-Berechnung: node-red-contrib-genetic-charging-strategy2. Der Author hat mir seinen Flow zur Verfügung gestellt, allerdings muss man ziemlich viel selbst anpassen auf seine eigenen Geräte, Batteriegrößen, Erzeugerpreise usw. Läuft bei mir mit Tibber, kleiner PV (mit Verschattung), 2x OpenWB, 3x Splitklima und MP2 + 2xPylontech US5000. Analog zu Victron Dynamic ESS hat er auch eine Html-Übersichtsseite gebaut, wo man das Ganze als Webseite beobachten kann.
@@flea-l4t Ja, da will ich auch noch „ran“ - hatte leider noch nicht die Zeit gefunden mir das anzuschauen. Ist mittlerweile auch auf GitHub und als Node über die Node Red Pallette installierbar. Die persönliche Anpassung ist halt immer ein wenig die Krux an der Geschichte - deswegen wird sich Victron mit Dynamic ESS auch so schwer tun.
Viel zu teoretisch und unnötig weil die meisten haben eh zu kleine Akkus. Also kannst du nur für max one day haed planen. Man kauft strom wenn es am günstigsten ist, dann kann man dann es so planen dass der Ladevorgang maximal lang geht weil das Haus nutz gleichz den günstigen Strom dazu der Akku voll laden. Wichtig ist nur dass ich nie den akku voll mache wenn evt der PV etwas hergibt aber wir reden ja nur uber spat Herbst, Winter und früh Frühling
Naja - es ist ja auch nicht allgemeingültig sondern erstmal nur mein Weg - auch wenn da nu HowTo davorsteht. Daran, dass Victron mit dem Dynamic ESS noch nicht fertig ist sieht man ganz gut, dass es verdammt schwer ist, da allgemeingültige Lösungen zu finden. Wenn ich die hätte, würde ich das nicht bei YT machen sondern würde es als Patent anmelden :P. Nur Day Ahead zu planen ist etwas zu kurz finde ich. Aber längere Betrachtung macht es wieder massiv komplex. Nur mal so als "mein" Fernziel für Zuhause (grad in der Planungsphase): maximale Autarkie mit 2-stufigem Speichersystem mit mehr PV als bei mir im Büro möglich ist, dazu noch mit BEV und Warmwasser-WP. Das wird spannend für mich - und dafür ist der ganze Kram hier am Ende nur Vorgeplänkel.
Hallo Jens, ich bin gerade vor der Arbeit am Rechner (ca. Min 14) und muss zwei Anmerkungen loswerden.
Erstens: Du must deinen Strompreis für die Akkuladung zeitlich dynamisieren. Sonst kannst du in eine Situation kommen, wo du nicht mehr entlädst, da du mal relativ teuer geladen hast. Diesen Deadlock gilt es zu vermeiden. Z.B dadurch, dass du den Strom im Akku jeden Tag um einen gewissen Prozentsatz preiswerter kalkulierst. Irgendwann entlädt er dann wieder.
Zweitens: Wenn der Akku groß genug ist, einfach nicht voll laden. Die Reserve sollte als Puffer reichen, wenn doch mal mehr vom Dach kommt als erwartet. Du brauchst nicht die gesamte Akkukapazität, wenn du nicht ständig entlädst.
Eine Denksportaufgabe habe ich noch: Was ist wichtiger beim Entladen? Hoher Preis und geringer Verbrauch oder Durchschnittspreis und hoher Verbrauch. Ich weiß auch noch nicht wie ich das berücksichtigen soll. Bin mir aber ziemlich sicher, dass man den Verbrauch nicht unberücksichtigt lassen kann.
Danke dir, guter Input!
zu 1. Ja, kommt - jetzt wo die Möglichkeit da ist :). Aber erstmal die Reihe mit dem aktuellen Stand zuende machen.
zu 2. Jup, es sei denn, der Preis ist supidupigünstig - Teil 2 ist grad abgedreht, da gibts vielleicht ein wenig Aufklärung, und genau den Einwand hab ich da auch gebracht (weil ich da wirkich bis 100% voll mache). Da braucht es ggf. doch noch nen PV-Prognosen-Override.
Zur Denksportaufgabe: das wäre ja der "Peak Shaving" Ansatz und Lastverschiebung. In den NL defintiv lohnenswert. Und mit kommenden dynamischen Netzentgelten vielleicht auch zukünftige Herausforderung. Aber lohnt sich halt nur, wenn der Preisunterschied groß genug ist (Thema Verluste). Da sind wir dann teils wieder bei 1./2. und auch einer möglichen Verbrauchsprognose. Vor dem Hintergrund, dass man Lasten direkt ansteuern kann (Wärmepumpe, BEV laden) - Peak Shifting - ohne dem Umweg über den Speicher zu gehen: jaaa, das muss man holistisch sehen (ganzheitlich - extra holistisch genommen, ich mag Douglas Adams "Dirk Gently" - Lesetip).
Da gehts ja weiter 😀 . Ich freue mich !
Zur Zeit lasse ich das DESS von Victron laufen und versuche die Logik zuverstehen. Jetzt zum Beispiel: Tibberstrom kostet 26cent, Akku 55% voll und der MP2 versorgt das Haus mit Netzstrom. Heute Mittag soll der Strom irgendwann 32 cent kosten. Da wird er bestimmt wieder vom Akku lutschen. Für mich ist das alles ein wenig undurchsichtig.
Und deswegen freu ich mich auf dein fertigen Flow 🙂.
Zu 22:30 : Nein du machst das genau richtig. Das Normalos wie ich das auch gebacken kriegen 😉
Bewerb dich mal bei Victron . Ich glaub die brauchen so Leute wie dich 😉
Merci - 2. Teil ist grad auch im Kasten... Puuh.
Victron hat schon die richtigen Leute - das Thema ist aber echt sehr komplex und imo individuell. Wenn es einfach wäre, wäre Victron längst fertig :).
@@fldutch Da hast du Recht !
Ich habe heute mal angefangen und den Flow importiert. Einige Nodes , wie den Battery Monitor musste ich rauslöschen, neu einfügen und mit meinem Seplos BMS konfigurieren.
Auch den Teilflow von deinem Phönix kann ich doch ohne Probleme da rauslöschen, oder?
@andi692 Ja, der kann wech :)
Man muss halt auch die Ladeverluste im Auge behalten. Wenn ich den Akku 6 Stunden mit 21A lade und dann wieder entlade hat man 2 mal Umwandlungsverluste. Somit muss der Preis unterschied schon sehr hoch sein damit man dies ausgleicht und günstiger kommt.
Korrekt, kommt in Teil 3.
Bin gespannt wie´s weitergeht. Hab das auch mit NodeRed gelöst, aber bspw. bisher keine PV-Vorhersage drin. Hab einfach 3 Preisbereiche definiert: Billig = die 6 billigsten h eines Tages, Günstig = alles unter Mittelpreis des Tages, Teuer = alles über Mittelpreis des Tages. Und für jeden Preisbereich einen Schieberegler für den SOC: also wann laden / wann entladen. Aktuell jetzt im Winter fahre ich mit 100%/65%/45%, alles drunter ist noch Reserve. Will das nun 1 Jahr laufen lassen & mit den Reglern spielen, dann kann ich evtl. die Schieberegler ersetzen durch die gewonnenen Erfahrungswerte. Neulich am Wochenende waren mal tagsüber die billigsten h (eher selten) - also wurde der Speicher vollgeknallt, das eingehende Solar mußte dann verkauft werden - nicht optimal, aber das sind seltene Zustände wie ich meine. Da wäre an diesem Tag wohl SOC 80% statt der 100% für die Billig-Zeit besser gewesen.
Man kann sich hier zu Tode optimieren oder einfach eine 80/20 Regel versuchen...andererseits macht das Ganze ja auch Spaß...kann also gut sein, daß ich Deinen PV-Vorhersageansatz auch einbauen werde.
Ach ja: 13,3kWp Nord 22Grad plus 2,25kWp Süd senkrecht, 50kWh Speicher, Deye Hybrid 12kW, Tibber dynamisch
Für mich klappt es am besten damit, einmal pro Tag 2 Werte einzugeben, Lade-Preis und Entlade-Preis. Dies per AI, Regeln oder sonstwie zu lösen ist zu aufwendig. Und, diese 5 Minuten pro Tag um mich mit den 2 Werten zu beschäftigen, habe ich.
Wenn das so für dich passt: perfekt.
Gut erklärt. Vermutlich werden die Leute nur nicht mehr die alte InfluxDB im Einsatz haben sondern die 2.x. Mich würde mal dein Grafanaboard interessieren kannst du das auch zur Verfügung stellen. Den Flow in Node Red haben ich angepasst auf die InfuxDB 2.x Daten kommen rein. Sehr gut.
Alter SQL Hase halt - da war Influx 1.8 halt naheliegend. Mal sehen, ob ich da nochmal auf 2.x oder höher umsteige. 2.x hat halt neben der neuen Query Language auch den Vorteil, dass Monate bekannt sind.
Grafana Dashboard soll es auch weitergehen. Erstmal die Node Red Reihe nu fertig machen.
@@fldutch Sollte bei Tibber Preise Abholen und in die DB schreiben in der DB nicht Werte zu sehen sein ? Wenn ich den Trigger starte werden zwar werte geholt das sehe ich im Debug aber in DB unter Testing_only ist nichts drin zumindest nicht im Influx Data Explorer.
@karstenm6042 Es könnte sein, dass du das anders aufbereiten musst? Bei InfluxDB 2.0 bin ich leider aktuell raus, hätte auch keine Testinstanz am Start. Ggf ist nicht nur das measurement abzufragen sondern auch nach dem konkreten „Feldnanamen“ zu suchen? Fehlermeldung vom Influx Node bekommst du nicht?
@@fldutch Nee leider nicht nur das Debug
7.2.2024, 14:30:01node: Ausgabe Debug in DB
msg.msg.payload : Object
{ time: 1707429600000, total: 0.2372 }
@@karstenm6042 Hmm, msg.msg.payload? ggf ein msg zuviel? Da würde der nachfolgende Node das nicht übernehmen können?
Verfolge das Thema schon länger, habe deine "Tibber macht den Akku voll" im kleinen bei mir laufen ;-) Und verfolge nun auch diese Variante... freue mich auf die nächsten Teile. Stellst du vielleicht auch die Grafana Dashboards zur Verfügung? Danke dir!
Ja, ist geplant. Ggf. „As is“ - da ist viel gewachsenes Zeug dabei.
Benutz solcast API für pv Forecast, dann lass die letzten 5-15 Tage forecast solcast / wirklich produziert den Ration ausrechne. Dann der KPI generiert über zb ein Exponential Moving Average rechnen lassen und dann hast du den faktor fur den neuen berechneten Forecast. Liege simlich genau, im winter sieht man auch in den EMA wie der faktor den neue Forcast Richtung null (Schnee zb) geht (automatisch) Forecast neu = EMA(Array(FC Solcast/Real Produktion))*Forecast Solcast
Spannender Ansatz. Solcast hab ich hier teils auch drin (kommt in Teil 3 ggf.) - vor allem als Vergleich. Victron basiert mittlerweile auch auf Solcast Prognose mit "Machine Learning" drübergebügelt.
In welcher Region in Deutschland befindest du dich? Wenn weiter im Süden: euer Wetter ist imo ein wenig stabiler als hier im Nordwesten. Da liegt auch Victron fix mal massiv daneben, wenn sich die Wolken oder Hochnebel schneller/anders/langsamer vorschieben als gedacht.
@@fldutch München. Muss sagen ich treffe Recht gut das estimated Wert. Bei mir pendelt der Faktor von 0.55-0.65, bedeutet Solcast sagt zb 20kwh und KPI sagt 0.5 sollte ich ca 10kwh produzieren können und liege hier ca +/- 1 kWh von 10kwh Abweichung, ich würde sagen max 20%. Dazu wiegsagt nutze ich nicht nur den reinen Verhältniszahl aber lasse es über den Indikator einmal durchjagen so dass Vergangenheit eine Rolle spielt. Ich nutze aber 2 Weschelrichter, einmal der Haupweachlerrichter (SunGrow mit 16 kWh Speicher) dazu ein DEYE Sun 12 Niederigvolt mit 4*5,12 kwh. Hier wird es etwas komplizierter da ich ja aufpassen muss dass beide gleichzeitig Laden sonst ist es Ping pong von laden. Ich Steuer dass alles über Modbus. Alles per HA und NR
@@europer67 Für München sollte das Modell so sicherlich passen :).
Ich glaub ich muss da wirklich mal diverse Modelle laufen lassen und dann Treffgenauigkeit rechnen - das ist schon im Hinterkopf.
@@fldutch Solcast hat 10 pull per day aber ich habe Ost und West Ausrichtung und Teile mein Dach in 2, hab dann nur 5 Pulls (2*5) und gibt bessere Ergebnisse als sollte ich alles über eine Fläche zb gewichtet gerechnet von kwp, Neigung, Ausrichtung. Nur als Hinweis
@@europer67 Merci - ja, ist bekannt. Für zuhause wird das nicht funzen, da es im Endausbau viele Flächen geben wird. Da wird Victrons System die einfachste Lösung werden.
Suuuuper Video
Ich mache das über Home Assistent, allerdings mehr händisch als über Automationen. Da das ganze Recht selten passiert kann ich das halbautomatisch besser händeln. Ich habe natürlich auch eine PV Prognose in HA aber so richtig begeistert bin ich damit nicht.
Ebenfalls habe ich natürlich alle Daten zum Speicher auch im System (HA) und somit wäre eine komplette Automation auch realisierbar.
Moin, ich bin gerade dabei mir die ganze sache mal anzunehmen und frage mich, muß ich grafana mit installieren und geht das dann auch auf dem Cerbo gx noch mit drauf?
Für das ein oder andere bräuchte es ggf. leider doch Influx-DB. Könnte man aber bestimmt umschreiben um ohne auszukommen.
Influx und Grafana würd ich aufm Cerbo GX eher nicht machen.
@@fldutch habe gerade meinen raspy vom victron entfernt und wollte da home assistant drauf testen. Wäre da vielleicht die Möglichkeit noch für die Datenbank? Aber da sehe ich die Frage, wie die Daten hin und herwandern.
@roywobser5036 Daten übers Netzwerk sollte ja kein Problem sein ;).
Ob man parallel zu HA noch zumindest ne InfluxDB (1.x) installieren kann gute Frage.
Kurze Suche: www.home-assistant.io/integrations/influxdb/ - sollte gehen? Wichtig: nicht 2.x installieren sondern 1.x - sind unterschiedliche Abfragesprachen 🫣. 1.x mit FluxQL ist eher SQL Style, Fluxx aus 2.0 total anders und nicht kompatibel. Für 3.0 gehts dann zurück zu FluxQL 🤷🏻.
@@fldutch ich glaube ich gehe dann doch lieber jeden tag und programmiere die Zeiten zum laden von Hand. Nein War ein Spaß. Aber es muß erst verstanden werden, bevor man da etwas auf seine Bedürfnisse umändern kann.
@@roywobser5036 Jup :). Andreas (Akkudoktor) ist übrigens auch dran, dito Victron mit Dynamic ESS.
Ich wollt halt net so lang warten - es muss auch nicht zu 100% passen bzw. optimal günstig sein - die Unwägbarkeiten bei Prognosen machen dir eh nen Strich durch die Rechnung ;).
ohne verbrauchsprognose ist das doch alles halbgar. finde node-red auch viel zu umständlich, auch wenn ich den reiz, code zu visualisieren, nachvollziehen kann. ich hab mir das klassisch zusammenprogrammiert und erst mit verbrauchs- und solarprognose brauchbare ergebnisse erzielt. vermutlich weil der verbraucher "wärmepumpe" ziemlich dynamisch ist (außentemperatur). die grundlast abbilden kann man natürlich auch mit einer konstanten verbrauchsprognose.
richtig interessant wird es, wenn man stunden überbrücken kann die weder von pv noch akku abgefangen werden können. z.b. strom zum günstigsten zeitpunkt ist X und reicht um die 3 teuersten stunden Y1,2,3 zu überbrücken und speicher ist groß genug um das abzufedern. dann gibt es aber noch die "wendepunkte" die zu teuer sind, im vergleich zur zwangsladung + verlusten, aber auch nicht günstig, sodass man gerne trotzdem so wenig wie möglich verbrauchen möchte (=aus dem netz beziehen) und somit die wärmepumpe 1-2h auf idle schickt. geht natürlich nur, wenn man sowieso wärmekapazitätspuffer bei der wärmepumpe hat. entweder weil sie sowieso taktet und die wärme über 24h nicht abgeben kann oder warmwasserpuffer mit vorheizen oder einfach 1-2 kühle stunden aushalten möchte.
Ja, da liegst du schon richtig :). Das klassisch zu programmieren ist natürlich am sinnvollsten, braucht aber noch mehr Zeit und KnowHow - Node Red war der Weg des geringsten Widerstandes - dann auch im Hinblick auf Videos und Nachvollziehbarkeit.
Je mehr Faktoren da eine Rolle spielen, desto komplexer es wird, desto schwieriger wird es, das abzubilden. Wie schon geschrieben: es ist aktueller Status. So weit wie du bin ich da leider noch nicht. Aber das wird ne spannenden Reise, sobald nicht nur hier im Büro sondern dann im Laufe des Jahres auch die PV, Speicher, Brauchwasserwärmepumpe und BEV zuhause einziehen.
Was die Verbrauchsprognosen angeht: wie rechnest du die? So ne grobe Idee wäre spannend.
Warum nimmst du nicht die Victron eigenen PV Forecast Daten?
Kommt noch… Erstmal den aktuellen Stand aufarbeiten ;). Ausserdem geht das nur mit nem Victron System. Mit Forecast.Solar oder Solcast ist es ein wenig universeller.
Victron läuft hier im Monitoring aber schon mit. Trefferquote ist gefühlt definitiv besser, gibt aber natürlich auch noch wetterbedingte „Ausrutscher“.
Dass würde mich am meisten interessieren, da ich unter Bäumen wohne und ein allgemeiner forcast einfach völlig ungeeignet ist.
@@_macrosky Danke fürs Feedback. Schreib mir das auf die Agenda.
@@fldutch ich nutze aktuell folgende Node zur Strategie-Berechnung: node-red-contrib-genetic-charging-strategy2. Der Author hat mir seinen Flow zur Verfügung gestellt, allerdings muss man ziemlich viel selbst anpassen auf seine eigenen Geräte, Batteriegrößen, Erzeugerpreise usw.
Läuft bei mir mit Tibber, kleiner PV (mit Verschattung), 2x OpenWB, 3x Splitklima und MP2 + 2xPylontech US5000. Analog zu Victron Dynamic ESS hat er auch eine Html-Übersichtsseite gebaut, wo man das Ganze als Webseite beobachten kann.
@@flea-l4t Ja, da will ich auch noch „ran“ - hatte leider noch nicht die Zeit gefunden mir das anzuschauen. Ist mittlerweile auch auf GitHub und als Node über die Node Red Pallette installierbar.
Die persönliche Anpassung ist halt immer ein wenig die Krux an der Geschichte - deswegen wird sich Victron mit Dynamic ESS auch so schwer tun.
Viel zu teoretisch und unnötig weil die meisten haben eh zu kleine Akkus. Also kannst du nur für max one day haed planen. Man kauft strom wenn es am günstigsten ist, dann kann man dann es so planen dass der Ladevorgang maximal lang geht weil das Haus nutz gleichz den günstigen Strom dazu der Akku voll laden. Wichtig ist nur dass ich nie den akku voll mache wenn evt der PV etwas hergibt aber wir reden ja nur uber spat Herbst, Winter und früh Frühling
Naja - es ist ja auch nicht allgemeingültig sondern erstmal nur mein Weg - auch wenn da nu HowTo davorsteht.
Daran, dass Victron mit dem Dynamic ESS noch nicht fertig ist sieht man ganz gut, dass es verdammt schwer ist, da allgemeingültige Lösungen zu finden.
Wenn ich die hätte, würde ich das nicht bei YT machen sondern würde es als Patent anmelden :P.
Nur Day Ahead zu planen ist etwas zu kurz finde ich. Aber längere Betrachtung macht es wieder massiv komplex.
Nur mal so als "mein" Fernziel für Zuhause (grad in der Planungsphase): maximale Autarkie mit 2-stufigem Speichersystem mit mehr PV als bei mir im Büro möglich ist, dazu noch mit BEV und Warmwasser-WP. Das wird spannend für mich - und dafür ist der ganze Kram hier am Ende nur Vorgeplänkel.
Wenn dich die Theorie nicht interessiert, dann schau das Video nicht