Mein Balkonkraftwerk mit Speicher in Home Assistant: Aufbau, Dashboard und die Sensor-Fallen

Nulleinspeisung, ~5 kWh Akku, zwei getrennte PV-Stränge – und vier Stellen, an denen die Zahlen im Dashboard erst falsch waren.

TL;DR

Ein Balkonkraftwerk mit MaxxiCharge-CCU regelt die Wechselrichter-Ausgabe auf den Hausverbrauch und schiebt den Überschuss in einen ~5-kWh-Akku – Ziel: nichts einspeisen. Im laufenden Jahr: 1.324 kWh erzeugt, davon 1.301 kWh selbst verbraucht (98 %), nur 23 kWh ins Netz. Das Dashboard dazu ist schnell gebaut; die Arbeit steckt in vier Sensor-Details, die die Autarkie-Anzeige sonst auf 0 % kleben lassen.

Die Anlage

• MaxxiCharge CCU (maxxisun) als Regler. Sie liest über einen Tasmota-Lesekopf am Stromzähler die aktuelle Netz-Wirkleistung und moduliert die Wechselrichter-Ausgabe so, dass der Netzbezug nahe null bleibt. Überschuss lädt den Akku, abends entlädt er wieder.
• Akku rund 5 kWh (aus 322 Wh bei 6 % Restladung hochgerechnet).
• Zweiter PV-Strang „Solar Keller" – ein kleines Modul mit eigenem Tasmota-Messpunkt, das die CCU nicht kennt. Muss in der Gesamtrechnung von Hand mitgeführt werden.
• Betrieb aktuell im Sommermodus (switch.balkonkraftwerk_winterbetrieb = off).

Die Regel-Parameter der CCU, direkt aus Home Assistant steuerbar:

(Die eingestellte Leistungsobergrenze lasse ich hier bewusst weg – jeder betreibt seine Anlage im Rahmen der für ihn geltenden Vorgaben.)

Das Dashboard

Eine sections-View mit sechs Blöcken:

1. Solar Übersicht – die custom:solar-card. Sie bringt Erzeugung/Verbrauch, die Tages- und Jahres-Kacheln, den Energiefluss als Sankey (Batterie/Netz/PV → Home → Etagen → Räume → einzelne Geräte, inklusive „Nicht erfasster Verbrauch") und eine Reihe Top-Verbraucher als Badges mit.
2. Verläufe – sechs mini-graph-Kacheln über 24 h: PV-Leistung, Stromzähler, Batterie-Ladestand, Netzbezug, Netzeinspeisung, PV-Produktion heute, CCU-Leistung.
3. Live-Verteilung – custom:power-distribution-card mit Hausbedarf, Solar-Erzeugung, Netzbezug, Akku und „Ins Netz", dazu zwei Balken: Autarkie und Anteil. Achtung: die Autarkie hier ist ein Momentanwert (im Screenshot 79 %) – nicht zu verwechseln mit der Jahres-Autarkie im Block „Jahreswerte" (~35 %).
4. Momentanwerte – drei Gauges: Leistung aus dem Akku, Akku-Ladestand, Zähler-Wirkleistung.
5. Jahreswerte – zweite power-distribution-card, aber mit den Jahres-Summen in kWh statt Live-Watt, plus zwei Euro-Kacheln (Einspeise-Verlust rot, Eigenverbrauchs-Ersparnis grün) – und der Jahres-Autarkie als Balken.
6. Balkonkraftwerk Einstellungen – die number-Entitäten der CCU zum direkten Nachjustieren.

Die Zahlen, die zählen

Aus den eigenen „im Jahr"-Template-Sensoren:

Ein typischer Sommermonat liefert für die kombinierte Anlage rund 240–270 kWh, also grob 8 kWh am Tag. Die Aussage des Dashboards ist eindeutig: Die Nulleinspeisungs-Strategie mit Akku funktioniert – es geht fast nichts verloren, und der Eigenverbrauch spart real dreistellig.

Die vier Sensor-Fallen

1. W vs. kWh, und die Autarkie-Bar, die auf 0 % klebt

Die selbstgebauten „im Jahr"-Sensoren (sensor.solar_im_jahr_watt, sensor.stromverbrauch_jahrlich_watt, sensor.solar_eigenverbrauch_im_jahr …) zählen Kilowattstunden, waren aber als device_class: power / unit_of_measurement: "W" deklariert – vermutlich, weil im Namen „Watt" steht. Folgen:

• Warnungen im Energie-Dashboard („Einheit hat sich geändert").
• Die Autarkie-Bar der power-distribution-card blieb stur auf 0 %. Die Karte rechnet den Autarkie-Anteil nur, wenn Producer- und Consumer-Entitäten konsistent energy/kWh sind – bei Mismatch zeigt sie kommentarlos 0, keinen Fehler.

Fix: unit_of_measurement: "kWh" und device_class: energy an den betroffenen Template-Sensoren. Danach stand die Autarkie sofort bei ~35 %. Merksatz: Eine Ratio-/Prozent-Kachel, die auf 0 hängt, zuerst auf Einheiten- und device_class-Konsistenz der zugrunde liegenden Entitäten prüfen.

2. Baseline-Offset-Zähler statt total_increasing

Die „im Jahr"-Sensoren sind bewusst state_class: measurement mit einem Jahres-Offset, nicht total_increasing. Ein total_increasing mit hart gesetztem Jahres-Startwert zerschießt beim Jahreswechsel die Langzeitstatistik (Sprung nach unten → HA interpretiert einen Zählertausch). Der Offset-Ansatz ist unhübscher, aber stabil. Beim Umstellen der device_class in Falle 1 diese state_class nicht mitändern.

3. Tote Sensoren nach einem Integrationswechsel

sensor.produktion_der_600w_anlage steht auf unavailable – er ist ein Template-Sensor, der aus sensor.solarman_total_ac_output_power_active rechnet, und diese Entität existiert nicht mehr, seit die Solarman-Integration entfernt wurde. Ein Template-Sensor wird beim Entfernen seiner Quell-Integration nicht mit aufgeräumt; er bleibt als unavailable-Leiche im System und in jeder Karte, die ihn referenziert. Solche Reste nach jedem Integrations-Umbau aktiv suchen (Entwicklerwerkzeuge → Zustände, nach unavailable filtern) und den Template-Sensor löschen oder umschreiben.

4. Zweite Erzeugung, die der Regler nicht sieht

Die CCU bilanziert nur ihren eigenen Strang. Der „Solar Keller"-Strang läuft über einen separaten Tasmota-Messpunkt (sensor.tasmota_energy_power_2 / _today_2). Wer die gesamte Erzeugung will, muss beide Quellen im Template addieren – sonst fehlen im Jahr mehrere Prozent, und die Autarkie wird zu niedrig ausgewiesen.

Checkliste

• Nach jedem Integrations-Umbau: Zustände nach unavailable filtern, tote Template-Sensoren aufräumen
• Energie-Template-Sensoren: unit_of_measurement und device_class konsistent (kWh / energy) – sonst schweigt die Autarkie-Karte
• „Seit X"-/„im Jahr"-Zähler als measurement mit Offset führen, nicht als total_increasing
• Jede PV-Quelle, die der Hauptregler nicht kennt, explizit in die Gesamtsumme rechnen
• CCU-Parameter (Totband, Offset, Min-Entladung) als number-Entitäten aufs Dashboard – dann muss man für eine Anpassung nicht in die Hersteller-App

Verwandte Notiz: Recorder-DB im Griff behalten. — Wie die „im Jahr"-Template-Sensoren aufgebaut sind und der komplette W→kWh-Umbau folgen als eigener Artikel.