ich habe einen laufenden Tibber-Vertrag, eine Balkonsolar-Anlage und einen Akku, der solar geladen wird, und einen Balkonakku-Wechselrichter. Anfangs hatte ich nur mit dem BMS und einer Zeitschaltuhr das Einspeisen geregelt. Das war mir zu ähm. Außerdem hat mich die App vom Daly gestört, weil ich nicht weiß, was mit den Daten passiert. Also habe ich angefangen, ein Programm zu schreiben, das sowohl die wichtigsten Infos über den Akku ausliest und im HomeAssistant anzeigt und versucht, in Abhängigkeit vom Ladestand und dem aktuellen Tibber-Preis den Wechselrichter aus- und einschaltet. Dabei bin ich ähm ausgerastet.
Ich habe mir gedacht, ich veröffentlich das mal als git-Repository. Vielleicht kann es außer mir jemand brauchen.
Hoffentlich blamiere ich mich nicht allzusehr. Das ist mein erstes Rust-Projekt.
Wenn ihr Fragen oder Anregungen habt, dann gerne unter diesen Post. Derzeit habe ich das Registrieren und Anmelden in meinem Git-Repo abgeschaltet.
Ich verwende kein github aus politischen Gründen. Wie ihr seht, fahr ich meine eigene Git-Instanz.
Ich habe das Ding für nen Balkonkraftwerkwechselrichter geschrieben. Dafür isses nach wie vor gedacht. Ich hatte schon überlegt, den Wechselrichter zu regeln, aber bisher hab ich zwei Probleme nicht lösen können:
Jeder Wechselrichter scheint irgendwie anders steuerbar zu sein, falls denn überhaupt. Ich hielt für meine Zwecke ein OpenDTU für übertrieben oder ich war zu faul, such dir was aus
Ich bräuchte im Programm die Verbräuche in Echtzeit. Die Tibber-API erlaubt jedoch nur soundsoviele Zugriffe pro Tag. Wie der Pulse lokal adressiert werden kann, hab ich nicht kapiert. Ich könnte den Shelly3EM abfragen, aber er sieht weder die Wärmepumpe noch die Wallbox.
Ich musste n Haufen anderer Probleme lösen, z. B. ne akkurate Abschätzung des SOC (der Daly versagt da).
Mir erschien es daher sinnvoller, an die Heimautomatisierung (HomeAssistant, aber welche ist egal) nur Ein/Aus zu senden (daher mqtt) und es diesem zu überlassen, die Leistung zu regeln. Das DTU oder sonst eine Regelung könnte z.B dort realisiert werden.
Wie gesagt: Das is n Ich-Projekt ohne Netz, doppelten Boden oder fremde Hilfe. Letzteres n Stückweit selbstverschuldet, weil ich nicht gefragt hab. Beispielsweise der Algorithmus für die Arbitrage war und ist nicht ganz einfach und viel Try und Error. Und ich mach(te) beruflich was ganz anderes.
Ja OK. Ich seh halt Nachteile. Das harte abschalten ist nicht gut für die Lebensdauer. Zuschalten muss wenigstens 2 min vor Leistungsanforderung passieren. Hab WR steuern incl marktpreis im shellyzähler und 20€ für den openDTU onbattery spendiert. Kämpfe nur noch mit paar kleinigkeiten: brauche mehr Signale ausm (fremden) script, und Regelstrecke 2-3 sekunden ist recht lahm
nur eine Frage: Warum wird der WR nur geschaltet und nicht geregelt?