Batterieprogramm ohne griffigen Namen bisher
| .idea | ||
| init_db | ||
| src | ||
| .gitignore | ||
| bacon.toml | ||
| Cargo.lock | ||
| Cargo.toml | ||
| compose.yaml | ||
| compose_old.yaml | ||
| Dockerfile | ||
| Dockerfile-alt | ||
| Dockerfile-develop | ||
| Dockerfile-release | ||
| homeassistant_configuration.yaml | ||
| LICENSE | ||
| README.md | ||
Batterie-Programm ohne griffigen Namen bisher
Was macht das Programm
- Es liest die Daten aus dem UART-Port aus und schickt sie als MQTT-Signal in
den Äther. In der aktuellen Version wird gesendet:
- Pack-Spannung
- Zellspannungen (derzeit 8)
- Derzeit fließender Strom in Ampere (etwas ungenau, weil der vom BMS gemessene Strom etwas ungenau ist)
- SOC (siehe unten)
- aktuellen Tibber-Preis
- Es versucht auf Basis des aktuellen Tibber-Preises und dem SOC einen Wechselrichter ein- und auszuschalten. Derzeit wird hierzu ein MQTT-Signal (Ein/Aus) gesendet, das bspw. von einem HomeAssistant mit einer Shelly-Erweiterung ausgewertet und dem Shelly übergeben werden kann.
- Der SOC vom Daly-BMS ist nicht genau, er verschiebt sich, und das um ca. 10% pro Woche. Daher versucht das Programm mit Hilfe einer Datenbank über den Strom zu integrieren (anders ausgedrückt: Bilanzieren), und sich bei drei Punkten auf Basis der Packspannung von selbst zu kalibrieren. Das BMS kalibriert den SOC auf 100% automatisch. Da selbst beim LFP-Akku das Aufladen auf 100% schädlich ist (nicht so sehr wie bei anderen Chemien, aber dennoch), wird der SOC bei 30%, 5% und 0% ebenfalls korrigiert. Das begrenzt die Ungenauigkeit des SOC auf ein Maß, dass Entscheidungen getroffen werden können. Derzeit wird ein Postgres-Skript verwendet.
Voraussetzungen
- Daly-BMS
- Vor Inbetriebnahme des Akkus: An den Uart-Anschluss das Bluetooth-Dongle anschließen und in der "SMART BMA"-App die erforderlichen Abschaltspannungen einstellen.
- Anschließend den Dongle entfernen und den UART-USB-Adapter anschließen und mit dem PI verbinden.
- Es ist möglich, den Raspberry Pi über einen Adapter direkt am Akku zu versorgen. Das ist jedoch nicht zu empfehlen, weil ich den Verdacht habe, dass das BMS den Strom für den PI "nicht bemerkt" und ihn auch dann versorgt, wenn die Batterie eigentlich schon entladen ist. Es könnte eine Tiefentladung auftreten. Den Pi also besser an der Steckdose versorgen.
- Verbindungskabel zwischen Uart und USB (als Zubehör, vorzugsweise galvanisch getrennt). Auf Spannungen des UART-Port achten, die sind beim alten BMS und dem neuen unterschiedlich.
- Akku mit 8 Zellen (das Programm wurde für die EVE 280k entwickelt), andere
Zellenzahlen werden derzeit nicht unterstützt; der Betrieb von Zellen
mit weniger oder mehr als 280Ah sollte gehen, wenn auch nicht getestet (ich hab nur einen Akku) Bei Interesse kommt es aber noch (Hey, ich lad das nicht ausschließlich altroistisch hoch. Wem der Finger juckt...) - Computer mit USB-Anschluss. Beispiele:
- Raspberry Pi 5 (Derzeit bei mir im Einsatz)
- Raspberry Pi 1B (Programm würde laufen, aber das Kompilieren dauert ca. 10 bis 20 Stunden)
- Im Grunde würde vermutlich jede Architektur funktionieren, aber nicht getestet
- Raspberry 4: Eher nicht, weil die USB-Schnittstellen unter Umständen zerstört werden.
- Wechselrichter, der per Homeassistant ein- und ausgeschaltet werden kann oder ersatzweise über einen Shelly (die weiteren Ausführungen beziehen sich auf den Shelly)
- Tibber-Vertrag mit dynamischer Abrechnung (andere Anbieter oder die Abrechnung über die Std-Lastkurve sind derzeit nicht vorgesehen)
- MQTT-Broker im Netz (über HomeAssistant bspw)
- Smart-Home-Lösung, die MQTT abonnieren und eine Shelly-Erweiterung hat, z. B. Homeassistant
- Docker und docker-compose auf dem Raspberry Pi
- Die erforderliche Rust-Umgebung für das Kompilieren wird automatisch im Docker-Container (siehe Dockerfile, wenn Interesse besteht) bereitgestellt, die Installation der Rust-Tools (Compiler, Cargo, ...) auf dem Raspberry Pi ist nicht erforderlich.
Installation
- Repository auf Raspberry Pi klonen
- Im HomeAssistant den Editor holen und in die homeassistant-configuration.yaml den Inhalt aus "homeassistant-configuration.yaml" rauskopieren und einfügen (es könnte auch geeignetere Files geben; ich hab's so gemacht, siehe Dokumentation von homeassistant). Für io-Broker bitte selbst konfigurieren.
- in compose.yaml die Daten eintragen, die dort verlangt werden
- Auf HomeAssistant tauchen die MQTT-Signale (homeassiatant-configuration.yaml) als Sensor auf. Ich muss hier voraussetzen, dass ihr wisst, wie man die Sensoren anzeigt oder konfiguriert.
- Auf HomeAssistant einrichten, dass er auf das MQTT-Topic "batterie/inverter/zustand" lauscht. Der Zustand liefert 0 oder 1.
- Über die Funktion der Automatisierung im HomeAssistant die Regel festlegen, dass bei 1 der Shelly am Wechselrichter eingeschaltet und bei 0 ausgeschaltet wird. Ich persönlich habe dafür >0.9 und <0.1 verwendet, das klappt auf jeden Fall.
- Bei Verwendung von anderen Akkus mit einer anderen Kapazität pro Zelle: In die init.sql die Kapazität lt. Datenblatt in Amperestunde eintragen. Achtung: derzeit gehen nur 8 Zellen, weil ich (derzeit noch) 8 Zellen in der init.sql vorgesehen habe, und die sind (noch) NOT NULL, also die Datenbank verlangt da eine Spannung.
- Auf dem Pi
docker compose build && docker compose up -dausführen - mit
docker compose logs -f nachsehen, ob alles funktioniert. Sieht man was von "panic", ist irgendwas in der compose.yaml falsch. In diesem Fall die compose.yaml korrigieren und docker compose down und docker compose up -d - Bei Fragen oder Anregeungen entweder im Akkudoktor-Forum ne PN oder in dem Repo n Issue aufmachen. Ich versuche mein Bestes.
Ich habe noch viele Funktionen auf der Liste, die ich gerne implementieren würde aber noch nicht getan habe.
Das Programm ist mein erstes Rust-Projekt ever. Überhaupt mein erstes ernstgemeintes Programmierprojekt. Also nicht lachen! :)
Disclaimer
Das ist ein selbstgebautes Programm. Auch wenn ich Rust verwende, kann ich weder für Schäden am Akku noch am BMS noch für Schäden, die kausal mit dem Versagen des Programms zusammenhängen, irgendeine Haftung übernehmen. Wer das Programm herunterlädt und am eigenen (selbstgebauten) Akku verwendet, tut dies auf eigene Gefahr.