Zum Inhalt

/7 Energie 5 Minuten Lesezeit

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

Von Michael Mackedanz, gelernter Elektroinstallateur. Alles in diesem Artikel ist in meinem eigenen Homelab passiert.

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

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 kamen so bis zum 27.10.2026 1.520 kWh Erzeugung zusammen, davon 1.494 kWh selbst verbraucht, macht 98 % Eigenverbrauch, nur 25 kWh gingen ins Netz. Das Dashboard dazu ist schnell gebaut, die eigentliche Arbeit steckt in vier Sensor-Details, die die Autarkie-Anzeige sonst auf 0 % kleben lassen.

Home-Assistant-Dashboard des Balkonkraftwerks: solar-card mit Erzeugung, Verbrauch und Tageswerten, darunter ein Energiefluss-Sankey von Batterie/Netz/PV über die Etagen bis zu einzelnen Geräten, dazu Verlaufsgraphen, Gauges für Akku-Leistung und Ladestand, die Live-Verteilung mit Autarkie- und Anteil-Balken sowie die Jahreswerte.

Die komplette Solar-View: oben die solar-card mit Energiefluss-Sankey und Top-Verbrauchern, darunter Verläufe, Momentanwerte, Live-Verteilung und Jahreswerte.

Die Anlage

Regler ist eine MaxxiCharge CCU (maxxisun). Sie holt sich den aktuellen Hausbedarf von einem Shelly 3EM und moduliert die Wechselrichter-Ausgabe so, dass der Netzbezug nahe null bleibt. Überschuss lädt den Akku, abends entlädt er wieder. Der Akku selbst hat rund 5 kWh, hochgerechnet aus 269 Wh bei 5 % Restladung (das ergibt 5,4 kWh).

Zusätzlich hängt ein Tasmota-Lesekopf am Stromzähler. Er gehört nicht zur Regelung, die CCU braucht dafür nur den Shelly 3EM. Der Lesekopf liefert die Zählerstände für Netzbezug und Einspeisung, die im Dashboard auftauchen.

Dazu kommt ein zweiter PV-Strang „Solar Keller", ein kleines Modul mit eigenem Tasmota-Messpunkt, das die CCU nicht kennt und das deshalb von Hand in die Gesamtrechnung muss. Betrieb Stand 27.10.2026 weiterhin im Sommermodus (switch.balkonkraftwerk_winterbetrieb = off).

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

ParameterWertBedeutung
Reaktionstoleranz50 WTotband auf die Zähler-Messung, darunter wird nicht nachgeregelt
Ausgabe korrigierenkleiner Korrektur-Offsetgleicht Messabweichungen am Zähler aus
Offline-AusgangsleistungFallback-Festwertgreift, wenn die Zähler-Verbindung abreißt
Minimale Entladung5 %Akku wird nicht tiefer entladen
Maximale Akkuladung100 %im Sommer voll laden erlaubt

(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 für Autarkie und Anteil. Achtung: die Autarkie hier ist ein Momentanwert (im Screenshot 79 %), nicht zu verwechseln mit der Jahres-Autarkie im Block „Jahreswerte" (Stand 27.10.2026 rund 34 %).
  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, Stand 27.10.2026:

KennzahlWert
Erzeugung im Jahr1.520 kWh
davon selbst verbraucht1.494 kWh (98 %)
ins Netz eingespeist25 kWh
„Verlust" durch Einspeisung (eingespeiste kWh zum Strompreis von 0,40 €/kWh bewertet)10,12 €
Ersparnis durch Eigenverbrauch (zu Arbeitspreis)598 €
Autarkie (Eigenverbrauch / Gesamtverbrauch)~34 %
Erzeugung seit 2023 gesamt4.127 kWh

Pro Monat kam die kombinierte Anlage 2026 so weit (Differenz der Monatsendstände des Jahreszählers sensor.solar_im_jahr_watt):

MonatErzeugung
Januar22 kWh
Februar37 kWh
März139 kWh
April202 kWh
Mai200 kWh
Juni257 kWh
Juli234 kWh
August202 kWh
September145 kWh
Oktober (bis 27.10.)81 kWh

Die Monate Mai bis August liegen bei 200 bis 257 kWh, das sind rund 6,5 bis 8,5 kWh am Tag. Die Nulleinspeisungs-Strategie mit Akku geht auf: 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. Das gab Warnungen im Energie-Dashboard („Einheit hat sich geändert") und ließ die Autarkie-Bar der power-distribution-card stur auf 0 % stehen. Die Karte rechnet den Autarkie-Anteil nur, wenn Producer- und Consumer-Entitäten konsistent energy/kWh sind, bei einem Mismatch zeigt sie kommentarlos 0, keinen Fehler.

Nach der Umstellung auf unit_of_measurement: "kWh" und device_class: energy an den betroffenen Template-Sensoren stand die Autarkie sofort bei ~35 %. Wenn eine Ratio- oder Prozent-Kachel auf 0 hängt, lohnt sich als Erstes ein Blick auf Einheiten und device_class der zugrunde liegenden Entitäten.

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, weil der Sprung nach unten von Home Assistant als Zählertausch interpretiert wird. Der Offset-Ansatz ist unhübscher, aber stabil. Beim Umstellen der device_class in Falle 1 sollte diese state_class unangetastet bleiben.

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 sollte man 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 halten (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 legen, dann muss man für eine Anpassung nicht in die Hersteller-App

Wie die „im Jahr"-Template-Sensoren aufgebaut sind und der komplette Umbau von W auf kWh folgen als eigener Artikel.