Batterie-Programm ohne griffigen Namen bisher

Lizenz

AGPL v. 3.0

Einleitendes

Abgesehen von dem Auslesen des UART-Ports kann alles, was ich hier gemacht habe, auch in HomeAssistant automatisiert werden statt mit diesem Programm. Ich habe dennoch versucht, es hier in Rust zu implementieren. Bitte seht es mir nach, ich programmiere nicht hauptberuflich; das hier ist ursprünglich ein Lern-Projekt für mich gewesen, und die App vom Daly fand ich mehr so meh. Daher ist der Code auch ähm teilweise naiv geschrieben, und er enthält noch Fehler (siehe unten).

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.

• In Abhängigkeit vom Tibber-Preis (derzeit ohne den Ladestand des Akkus auszuwerten, viellecht kommt das noch) schickt das Programm MQTT-Signale für
  • Wallbox
  • Wärmepumpe-Warmwasseraufbereiter
  • Kühlschränke Die MQTT-Signale können über HomeAssistant (oder jedem Automatisierungs-Tool, das MQTT-Broker abbonnieren kann) ausgewertet und die Aktoren entsprechend geschaltet werden.
• 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 ca. 5% ebenfalls korrigiert. Das begrenzt die Ungenauigkeit des SOC auf ein Maß, dass Entscheidungen getroffen werden können. Derzeit wird ein Postgres-Skript verwendet. Ferner wird einmal im Monat (erster Freitag pro Monat) der Akku auf ca. 3 Volt pro Zelle entladen und der SOC auf 0 festgelegt.

Voraussetzungen

• Daly-BMS (alte Version)
• Vor Inbetriebnahme des Akkus: An den Uart-Anschluss das Bluetooth-Dongle anschließen und in der "SMART BMA"-App die erforderlichen Abschaltspannungen einstellen. Das Programm schaltet den Inverter zwar bei ca. 3 Volt pro Zelle ab, aber sicher ist sicher.
• 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.
  • Jeder UART-USB-Adapter hat einen Device-Bezeichner, der als Device im /dev/- Verzeichnis auftritt. Für das Zubehörteil von Daly (alte Version von 2021!) ist der Device-Name voreingestellt.
  • Fremde USB-Uart-Adapter in irgendeinen Rechner stecken (Daly-BMS muss dazu nicht angeschlossen sein). Solle er erkannt werden, taucht im Verzeichnis /dev/serial/by_id eine Datei auf. Dessen Name in der compose.yaml an den beiden Stellen. An dem Eintrag mit dem Kürzel kann ein beliebiger Teil des Dateinamens eingetragen werden.
• 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.
  • Vorzugsweise also Raspberry Pi 5 oder 3B (bei zweiterem kann das Kompilieren doch ein bisschen dauern...)
• 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
• Bei Verwendung von anderen Akkus mit einer anderen Kapazität pro Zelle (als die 280 Ah 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.
• in compose.yaml die Daten eintragen, die dort verlangt werden
• Auf dem Pi docker compose build && docker compose up -d ausführen. Auf dem Raspi 5 dauert der erste Start ungefähr drei Minuten, weil Rust nicht für schnelle Kompilierzeiten bekannt ist. Beim Bauen des Docker-Containers muss alles von vorne kompiliert werden, was sonst nicht notwendig ist. Bei jedem Neustart ist docker compose build nicht erforderlich und geht daher erheblich schneller.
• mit docker compose logs -f nachsehen, ob alles funktioniert. Sieht man was von "panic", gibt es zwei Möglichkeiten: - Entweder ist irgendwas in der compose.yaml falsch. In diesem Fall die compose.yaml korrigieren und docker compose down und docker compose up -d - Oder es hat irgendwas mit Tibber nicht geklappt. In diesem Fall einfach docker compose down und erneut docker compose up -d. In der Regel klappt es dann.
• Mit einem MQTT-Explorer (ich verwende den MQTT5-Explorer) auf den Broker conneten und lauschen, ob MQTT-Signale kommen. Kommen die Signale, läuft das Programm.

Das Folgende ist noch nicht fertig, daher mit etwas Salz:

• 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.
• 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 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.

Wie gesagt: Das Programm ist mein erstes Rust-Projekt ever. Überhaupt mein erstes ernstgemeintes Programmierprojekt. Also nicht lachen! :)

Bekannte Probleme

• Wenn das BMS einen Fehler wirft, dann funktioniert das Programm nicht mehr. In diesem Fall muss das Programm neu gestartet werden. Das liegt daran, dass
  • das BMS den Fehlercode nicht löscht, selbst dann, wenn der Fehler behoben ist
  • und ich das (versehentlich) so programmiert habe, dass im Fehlerfall der Batterie- Zustand nicht mehr ausgelesen wird. Das wird in der nächsten Version korrigiert.

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.