Changelog

Alle wichtigen Änderungen an diesem Projekt werden in dieser Datei dokumentiert.

Das Format basiert auf Keep a Changelog, und dieses Projekt folgt Semantic Versioning.

[4.1.7] - 2026-10-13 — 62 Korrekturen an Preis, Prognose, Import und Jahresbericht; neu: V2H im Tag, Netzladung im laufenden Monat, „HA-Spiegel jetzt abgleichen”

Added

Cockpit → Tag zählt die V2H-Rückspeisung als Tagesgröße. Speist ein V2H-fähiges E-Auto Strom ins Haus zurück und ist sein Zähler „V2H Entladung” zugeordnet, stand im E-Mobilität-Block des Tages „—”, und Eigenverbrauch, Gesamtverbrauch und Autarkie ließen die Rückspeisung weg — Monat und Jahr zählten sie seit v4.1.2. Jetzt liest der Tag den Zähler (Home Assistant und MQTT) und zählt die Rückspeisung wie der Monat als eigenen Summanden: im Beispiel PV 20, Einspeisung 6, Netzbezug 4, Speicher 3/2 und V2H 2 kWh ⇒ Eigenverbrauch 15 statt 13 kWh, Gesamtverbrauch 19 statt 17 kWh, Autarkie 78,9 statt 76,5 %; der Rechenweg nennt „+ V2H-Rückspeisung”, der E-Mobilität-Block die Zeile „V2H-Rückspeisung”. Stundenwerte und Stunden-Verlauf zeigen sie nicht (Tagesgröße), der laufende Monat zählt sie weiter erst mit dem Abschluss. Ein per MQTT geliefertes …/v2h_entladung_kwh wird jetzt eingelesen (bisher verworfen) und im Monatsabschluss vorgeschlagen; mit Home Assistant schlug der Abschluss den Wert schon vor (Wunsch aus #110).
Reparatur-Werkbank: „HA-Spiegel jetzt abgleichen”. Nach einer Korrektur in Home Assistant (Entwicklerwerkzeuge → Statistik → „Wert anpassen”) zeigten die Tages-Kennzahlen in Cockpit → Tag bis zum nächtlichen Abgleich um 02:45 noch den alten Stand — eine Reparatur über „Tag neu aggregieren” änderte daran nichts, weil sie Stundenwerte und Tageszeile neu baut, nicht den HA-Spiegel. Der neue Werkbank-Eintrag startet denselben Abgleich sofort für die Anlage und sagt, was er getan hat (geprüfte Abschnitte, neu gespiegelt ab welcher Stunde); ohne HA-Spiegel sagt er das. Der Daten-Checker-Befund „Zählerstände – Sprung in Home Assistant” führt mit „Beheben” jetzt dorthin (MartyBr, simon42 #429).

Fixed

Cockpit → Monat: die Netzladung deines Speichers erscheint im laufenden Monat schon vor dem Abschluss. Bisher fehlten im laufenden Monat die Kachel „Batterieladung Netz” und die Zeile „davon aus dem Netz (Arbitrage)”, obwohl Cockpit → Tag die Netzladung jeden Tag nannte; die Wandlungsverluste des Speichers rechneten dadurch den ganzen Verlust zum Einspeisepreis (im Beispiel 10/8 kWh Ladung/Entladung, 3 kWh aus dem Netz, 8/32 ct: −0,16 statt −0,30 €). Jetzt nennt der laufende Monat die Summe der abgelaufenen Tage — dieselben Zahlen wie Cockpit → Tag, im Beispiel drei Tage mit je 1,0 kWh ⇒ 3,0 kWh, mit dem Ladepreis aus deinen Stundenpreisen (25 ct ⇒ 0,75 €) —, und Kachel und Zeile sagen „Menge aus Tageswerten”. Mit dem Monatsabschluss gilt der gespeicherte Wert; ein vergangener Monat ohne Abschluss bleibt wie bisher leer (#427 rapahl).
Daten-Checker → MQTT-Topic-Abdeckung: neben einer Wallbox mit Ladezähler erwartet der Check keine Lade- und Verbrauchs-Topics am E-Auto mehr. Misst eine Wallbox die Ladung, zählt sie — so rechnen Tag und Stunde, und die Energieprofil-Abdeckung überspringt das Auto schon lange. Der MQTT-Check meldete die Felder des Autos trotzdem als „erwartet, nie empfangen”, seit v4.0.51 auch „Heim: gesamt” (ladung_kwh), das in keinem Bestand eine gespeicherte Quellenwahl hat und deshalb nicht abstellbar war. Kilometer, Ladestand und V2H-Entladung bleiben erwartet (#425 gruaGit).
Daten-Checker → MQTT-Topic-Abdeckung: erwartet werden nur noch Topics für Größen, die es an deinem Gerät gibt. Bisher meldete der Check jede Größe, die eedc für den Gerätetyp kennt — auch solche, die dein Gerät laut seinen Angaben gar nicht hat. Ein E-Auto ohne „V2H-fähig“ trug dauerhaft „…/v2h_entladung_kwh“ als „erwartet, nie empfangen“, ebenso ein Speicher ohne „Lädt aus dem Netz“ „…/ladung_netz_kwh“ und eine Wärmepumpe ohne getrennte Strommessung „…/strom_heizen_kwh“ und „…/strom_warmwasser_kwh“ (eine Split-Klimaanlage zusätzlich „…/warmwasser_kwh“) — Topics, auf die niemand publizieren soll. Jetzt stellt der Check dieselbe Frage wie die Monatsdaten-Prüfung: Gibt es die Größe an diesem Gerät? Untypische, aber mögliche Größen (z. B. die Betriebsart-Felder an einer Luft-Wasser-Wärmepumpe) bleiben erwartet. Die Meldung nennt außerdem den Handgriff für ein Feld, das du bewusst nicht über MQTT lieferst: unter Einstellungen → Datenquellen auf „Keine“ stellen (N-746).
Cockpit → Live: hast du Netz-Zähler (Einspeisung/Netzbezug in kWh) und einen Kombi-Netzsensor (±) zugeordnet, kommen die Tageswerte jetzt aus den Zählern. Bisher rechnete eedc Einspeisung, Netzbezug, Eigen- und Gesamtverbrauch für heute und gestern aus der Leistung des Kombi-Sensors (im Beispiel 2,0 statt 4,1 kWh Einspeisung), während Cockpit → Tag die Zähler las; jetzt zeigen beide Sichten dieselbe Zahl. Der Kombi-Sensor liefert weiter die Momentanleistung und die Kurve im Tagesverlauf.
Cockpit → Live, Energiefluss: ein sonstiges Gerät mit kWh-Zähler zeigt im Tooltip die gezählte Tagesmenge. Bisher stand dort die aus der Leistung hochgerechnete Menge — bei kurzen Lastspitzen (Heizstab) deutlich zu viel, im Beispiel 6,8 statt 3,0 kWh —, und bei einem Gerät mit Kategorie „Abgabe” ging sie so auch in den Eigenverbrauch heute ein. Jetzt liest eedc den Zähler, wie schon bei Wallbox und Wärmepumpe und im Tagesverlauf darunter.
Cockpit → Live, Energiefluss: das „Solar Soll ~x kW” über dem Haus erscheint jetzt. Die Anzeige mit der PV-Leistung, die die Prognose für die laufende Stunde erwartet, blieb bisher immer aus, weil eedc die Stundenangabe der Prognose nicht lesen konnte; jetzt steht dort der Wert der laufenden Stunde (Solar Forecast ML vor der eedc-Prognose, sofern eine Prognose vorliegt).
Cockpit → Live, Solar-Aussicht: wer Solcast oder Solar Forecast ML als Prognosequelle gewählt hat, sieht für Morgen und Übermorgen jetzt die Zahlen dieser Quelle. Seit v4.0.36 kamen die Tageswerte der Quelle nicht bei der Kachel an — unter der Überschrift „Solar-Aussicht (SFML)“ bzw. „(Solcast)“ standen für Morgen, Übermorgen und die Vormittag/Nachmittag-Werte die eedc-Zahlen, ohne den „eedc“-Vermerk, der genau diesen Fall kennzeichnen soll. Jetzt stehen dort die Tageszahlen der gewählten Quelle und, wo sie einen Stundenverlauf liefert, auch ihre Vormittag/Nachmittag-Werte; wo sie einen Tag oder seine Aufteilung nicht abdeckt, steht wie versprochen „eedc“ dabei.
Cockpit → Live: fällt beim Wetterabruf eine von mehreren PV-Teilanlagen (Dachflächen) aus, sagt die Anzeige es jetzt. Bisher konnte die PV-Tagesprognose dann um den Anteil der fehlenden Dachfläche zu niedrig stehen (z. B. die Hälfte bei zwei gleich großen Flächen), als wäre es eine normale Prognose — und blieb so bis zu einer Stunde stehen. Jetzt steht ein Hinweis „Der Wetterabruf war unvollständig …“ unter dem Wetter und in der Solar-Aussicht, und der nächste Abruf versucht es neu, statt das unvollständige Ergebnis eine Stunde zu halten. Dieselbe Lücke hatte die Einstrahlung im Energieprofil: fiel eine Dachfläche aus, wurde die Einstrahlung des Tages um ihren Anteil zu klein gespeichert und die Performance Ratio (Cockpit → Tag, Auswertungen → Tabelle) entsprechend zu hoch (im Beispiel 1,39 statt 0,69 — genug, um im Daten-Checker einen Doppelerfassungs-Verdacht auszulösen). Jetzt bleibt die Einstrahlung auf die Modulfläche für diesen Abruf leer und damit auch die Performance Ratio, statt einer falschen Zahl (der nächste Lauf des Tages füllt sie wieder); der nächtliche Archiv-Nachzug schreibt einen solchen Abruf gar nicht und versucht es in der nächsten Nacht erneut.
Cockpit → Live, Solar-Aussicht: bei Solcast steht „eedc“ an Vormittag/Nachmittag von Morgen und Übermorgen. Solcast liefert für die Folgetage nur die Tagesmenge; die Aufteilung kommt dort aus der eedc-Prognose und addiert sich deshalb nicht zur Solcast-Tageszahl (im Beispiel 9,7 kWh über 13,0 + 15,0). Bisher stand das ohne Vermerk da, jetzt sagt es der Vermerk an den beiden Werten. Dasselbe gilt für Solar Forecast ML ohne Stundenverlauf.
Cockpit → Live: liefert Solcast für heute keine Daten, steht die eedc-Prognose nicht mehr unter der Überschrift „Solcast“. Bisher zeigte die Solar-Aussicht dann die eedc-Zahl als Solcast-Wert, ohne Hinweis. Jetzt schaltet eedc wie bei Solar Forecast ML sichtbar auf die eedc-Prognose um und sagt es: „Solcast liefert aktuell keine Daten, eedc-Prognose aktiv.“
Cockpit → Tag und Auswertungen → Tabelle: ein Tag, an dem der nächtliche Wetter-Nachzug ausfiel, bekommt seine Einstrahlung und Performance Ratio nachgetragen. Fiel beim Nachzug aus dem Wetter-Archiv der Abruf (für eine Dachfläche) aus, blieb der Tag dauerhaft ohne Einstrahlung auf die Modulfläche und ohne Performance Ratio. Jetzt holt eedc ihn in derselben Nacht nach und, falls es dann noch nicht klappt, in einer der folgenden Nächte (bis zu einer Woche).
Cockpit → Live: nach einem unvollständigen Wetterabruf rechnet die PV-Prognose nicht mehr still mit der Globalstrahlung. Bei mehreren Dachflächen konnte nach einem Teil-Ausfall bis zu einer Stunde eine Tagesprognose aus der horizontalen Strahlung statt der Strahlung auf die Module stehen (im Beispiel 31,0 statt 38,8 kWh), ohne Hinweis. Jetzt holt eedc die Dachflächen neu und zeigt den Hinweis zum unvollständigen Abruf, bis alle wieder liefern.
Cockpit → Live: die Sonnenstunden fehlen nicht mehr zeitweise. Bei Anlagen mit einer Dachausrichtung blieben die Sonnenstunden (die Zeile „☀ … bisher · … erwartet“ über dem Sonnenverlauf und „Xh Ym Sonne“ im Wetter) bis zu einer Stunde leer, wenn eedc das Wetter vorab im Hintergrund geholt hatte — dieser Vorababruf fragte die Sonnenscheindauer nicht mit an. Jetzt holt er dieselben Wetterdaten wie die Anzeige selbst.
HA-Sensoren „Ersparnis vs Benzin” (E-Auto) und „WP Ersparnis”: Monate vor deinem ersten Stromtarif rechnen wie das Cockpit. Liegen Monatswerte vor dem ersten eingetragenen Tarif, rechnete der HA-Export diese Monate mit einem anderen Preis als Cockpit und Auswertungen — über MQTT mit dem jüngsten Tarif-Eintrag, auch einem Wärmepumpen-, Wallbox- oder künftigen Tarif, über die REST-Schnittstelle mit dem heutigen Tarif; im Rechenweg kostete derselbe Monat für Netz- und PV-Ladung zwei verschiedene Preise. Im Beispiel (zwei Monate vor dem ersten Tarif, Tarif 35 ct, Wärmepumpen-Tarif 22 ct) zeigte HA fürs E-Auto 689,40 € (MQTT) bzw. 666,00 € (REST) statt 675,00 €, für die Wärmepumpe 421,67 bzw. 343,67 statt 373,67 €. Jetzt rechnen beide Wege mit der Vorbelegung 30 ct, die auch das Cockpit nimmt und der Daten-Checker für diese Monate nennt (einmaliger Sprung in der HA-Langzeitstatistik der beiden Sensoren; ohne Monate vor dem ersten Tarif ändert sich nichts). Dazu nennt der Kopf des Jahresberichts den Allgemeintarif, mit dem die Monate des Berichts gerechnet sind: bisher stand dort der jüngste Tarif-Eintrag — auch ein Wärmepumpen-Tarif oder im Bericht 2024 ein Tarif ab 2025; wechselt der Tarif im Berichtszeitraum, stehen jetzt beide Abschnitte da. Die Infothek-Vorbelegung „Stromvertrag”/„Einspeisevertrag” nimmt den heute gültigen Allgemeintarif statt eines schon angelegten künftigen.
Komponenten-Hubs, Aussichten und HA-Sensoren rechnen die Ersparnis mit dem Monatspreis des Cockpits — auch vor deinem ersten Stromtarif und bei gepflegtem Ø-Strompreis. Monate vor dem ersten eingetragenen Tarif bewerteten E-Auto-, Wärmepumpen-, Speicher-, Wallbox- und Sonstiges-Hub, der ROI-Fortschritt in den Aussichten und die HA-Sensoren für Jahresersparnis, ROI und Amortisation mit dem heutigen Tarif statt mit der Vorbelegung 30 ct, mit der Cockpit und Daten-Checker rechnen (im Beispiel E-Auto-Hub 666,00 statt 675,00 €, Wärmepumpe im Hub 421,67 und in HA 343,67 statt 373,67 €, Speicher-Hub 194,40 statt 185,40 €). Und wer im Monatsabschluss einen Ø-Strompreis pflegt, aber keinen eigenen Wärmepumpen-Tarif hat, sah die Wärmepumpe dort und im HA-Sensor „WP Ersparnis” mit dem Tarif-Arbeitspreis statt mit dem Ø gerechnet (im Beispiel 346,67 statt 490,67 €). Jetzt lesen alle diese Sichten den Monatspreis, mit dem auch das Cockpit rechnet. In HA springen „WP Ersparnis”, Jahresersparnis, ROI und Amortisation einmalig in der Langzeitstatistik — nur bei Anlagen mit Monaten vor dem ersten Tarif oder mit gepflegtem Ø-Strompreis ohne eigenen Wärmepumpen-Tarif.
Cockpit → Monat und Jahr: Monate vor deinem ersten Stromtarif zeigen jetzt ihre Geldposten. Bisher fehlten dort Einspeise-Erlös, Eigenverbrauchs-Ersparnis, Stromrechnung sowie Wärmepumpen- und E-Auto-Ersparnis (das Monatsergebnis nannte „Stromrechnung” als fehlend), und die Jahreszahlen lagen um diese Monate unter Cockpit → Übersicht (im Beispiel E-Auto 495,00 statt 675,00 €). Jetzt rechnen sie mit der Vorbelegung (30 ct/kWh Bezug, 8,2 ct/kWh Einspeisung) wie die übrigen Sichten, und unter dem Ø-Preis steht „Kein Strompreis-Tarif für diesen Zeitraum hinterlegt — gerechnet mit der Vorbelegung”. Ebenso nimmt Cockpit → Monat einen gepflegten Ø-Strompreis jetzt auch für die Wärmepumpe ohne eigenen Tarif und für die Netzladung des E-Autos, wie Cockpit → Übersicht (im Beispiel 61,33 statt 43,33 € bzw. 99,00 statt 93,60 € im Monat; mit eigenem Wallbox-Tarif 99,00 statt 98,10 €). Der Daten-Checker meldet Monate ohne Tarif weiter als Fehler; der Handgriff bleibt, beim ältesten Tarif das „Gültig ab” auf den Beginn der Daten zu setzen.
HA-Sensoren „Verbrauch (Monat)” eines sonstigen Verbrauchers und „Überschuss-Prognose heute”: keine doppelte Rundung mehr. Beide Werte wurden erst auf eine Nachkommastelle und dann für HA auf ganze kWh gerundet — 3,46 kWh standen dadurch als 4 statt 3 kWh in HA, in rund jedem zwanzigsten Wert um genau 1 kWh daneben. Jetzt rundet eedc einmal, wie bei allen anderen Sensoren (beim Update kann ein solcher Wert einmalig um 1 kWh zurückgehen; in der Langzeitstatistik ist das ein kleiner Sprung).
Jahresbericht (PDF): Betriebskosten, Netto nach Betriebskosten, Rendite und Amortisations-Fortschritt rechnen wie Cockpit und Auswertungen. Bisher legte der Bericht die Betriebskosten aller Komponenten auf jeden Monat des Berichts um — auch vor der Anschaffung und nach der Stilllegung (im Beispiel zwei erfasste Monate: 120 statt 20 €; Speicher ab Juli: 240 statt 120 €), und „Rendite” und „Amortisations-Fortschritt” waren dieselbe Zahl ohne Wärmepumpen- und E-Auto-Ersparnis (mit E-Auto im Gesamtzeitraum 13,4 statt 27,8 %). Jetzt zählt jede Komponente nur über ihre aktiven Monate wie in Cockpit → Jahr, die Rendite ist die von Cockpit → Übersicht und der Fortschritt der von Auswertungen → ROI — im Jahresbericht eines einzelnen Jahres der Stand zum 31.12. dieses Jahres (gerechnet nur mit den bis dahin angeschafften Komponenten; im Beispiel 6,4 statt 4,0 %); an beiden Zeilen steht, worauf sie sich beziehen. Cockpit → Jahr summiert die Betriebskosten dabei ungerundet (100 €/Jahr ergeben 100,00 statt 99,96 €).
Jahresbericht (PDF): kein Speicher-Wirkungsgrad über 100 % mehr. Passen Lade- und Entlademenge nicht zusammen (häufigste Ursache: die Ladung enthält nur die PV-Ladung), druckte der Bericht z. B. „110,0 %”, während das Cockpit „nicht ermittelbar” sagt. Jetzt steht im Bericht ein Strich; die Ursache nennt der Daten-Checker. Unter 100 % ändert sich nichts.
Import → Eigene Datei: eine Geräte-Spalte, die du zusätzlich im Dropdown ihrem Gerät zugeordnet hast, zählt nur noch einmal. Bisher stand die PV des Monats dann doppelt in der Monatszeile (im Beispiel 600 statt 300 kWh — so auch im Cockpit, sobald ein anderes Modul im Monat keinen eigenen Wert hatte), und die Ladung einer Wallbox oder eines E-Autos landete als Speicher-Ladung in der Monatszeile (Hinweis „Legacy-Daten …” in der Monatsliste, ohne dass es einen Speicher gab). Jetzt zählt jede Gerätegröße so ins Monats-Aggregat, wie es ihr Feld vorsieht — wie bei den automatisch erkannten Spalten.
Import → Eigene Datei: Wallbox-Ladung und Wallbox-PV-Ladung kommen an. Die Zuordnung bot beide Felder an, der Import schrieb sie aber nicht und meldete trotzdem Erfolg. Jetzt landen sie wie beim Portal-Import auf der Wallbox (Netzanteil = Gesamt − PV); gibt es keine Wallbox, meldet der Import den Monat als Fehler, statt die Werte still zu verwerfen.
Import → Eigene Datei: ein sonstiges Gerät (z. B. Pool, Heizstab, BHKW) lässt sich einzeln zuordnen. Bisher brach die Vorschau dann mit „Internal Server Error” ab. Außerdem schreibt der Import jetzt jeden Monat ganz oder gar nicht — scheitert ein Monat, bleibt von ihm kein halber Stand (Gerätewert ohne Monatszeile) zurück.
Import → Eigene Datei: eine gespeicherte Vorlage schreibt nicht mehr in eine andere Anlage. Ordnete eine Vorlage eine Spalte einer Komponente zu, die zu einer anderen Anlage gehört oder inzwischen gelöscht ist, schrieb der Import in die fremde Anlage bzw. brach mit einem Serverfehler ab. Jetzt nimmt der Assistent diese Zuordnung beim Laden der Vorlage heraus und sagt es, und der Import ignoriert sie mit einem Hinweis.
Import → Eigene Datei: die Vorschau zeigt, was der Import schreibt. Mit der Einheit Wh zeigte die Vorschau für erkannte Geräte-Spalten (z. B. Sueddach_kWh, Smart_1_km) ein Tausendstel, geschrieben wurde der Wert der Datei (im Beispiel Vorschau 300, Cockpit 500 000 kWh). Jetzt gilt in beiden: die Einheit im Spaltennamen gilt, umgerechnet werden nur Spalten ohne Einheit im Namen. Mehrere Zeilen desselben Monats (z. B. Tageswerte) werden zum Monat summiert wie beim Portal-Import — bisher galt der erste bzw. letzte Tag als Monatswert; ein Zählerstand in mehreren Zeilen eines Monats ist ein Fehler. Zeilen mit Jahr 0 bietet die Vorschau nicht mehr an.
Import (eigene Datei und Portal-Import): eine PV-Erzeugung von 0 wird als 0 gespeichert. Bisher blieb der Monat leer, der Daten-Checker meldete „PV-Erzeugung fehlt” und das Cockpit zeigte „—”. Eine leere Zelle bleibt weiterhin leer.
Portal- und Cloud-Import mit zugeordnetem Wechselrichter: meldet die Quelle für einen Monat 0 kWh PV, bekommen seine PV-Module 0. Bisher bekamen sie gar keinen Wert; der Monat galt als unvollständig, und der Daten-Checker meldete „PV-Erzeugung unvollständig in 1 Monat(en)” — die Summe der Anlage stimmte. Ein fehlender Wert bleibt weiterhin leer.
Import (CSV und eigene Datei): trägt eine Datei für ein Balkonkraftwerk den heutigen und den alten Spaltennamen, zählt der Wert einmal. Stand neben <Name>_Erzeugung_kWh auch die Spalte <Name>_kWh der Vorlagen bis v4.0.23 (etwa aus einer alten und einer neuen Vorlage zusammenkopiert), ging der Wert der ersten Spalte ins Balkonkraftwerk, die Monatssumme bekam aber beide — im Beispiel 220 statt 100 kWh, so auch im Cockpit, sobald ein anderes PV-Modul im Monat keinen eigenen Wert hatte; stand die alte Spalte zuerst, bekam das Balkonkraftwerk sogar ihren Wert. Jetzt gilt die Spalte mit dem heutigen Namen, die alte zählt nur in Zeilen, in denen die heutige leer ist, und die Vorschau des eigenen Formats zeigt genau diesen Wert.
Import → Eigene Datei: ein negativer Wert in einer einzeln zugeordneten Geräte-Spalte ist ein Fehler des Monats, wie schon bei den automatisch erkannten Spalten. Bisher ging er in die Summe ein (im Beispiel PV 123 bei −77 + 200 kWh). Eine Spalte, die ihre Werte negativ führt, importierst du weiter mit „Vorzeichen umkehren”.
Import → Eigene Datei: eine Batterie-Entladung ohne Ladungs-Spalte wird auf die Speicher verteilt wie beim Portal-Import. Bisher stand sie nur in der Monatszeile, die Speicher zeigten „—”.
Komponenten-Hubs Speicher, E-Auto (V2H) und Sonstiges: die Einspeisevergütung je Monat ist die des Cockpits. Vor deinem ersten Stromtarif rechneten diese Hubs mit der heutigen Vergütung statt mit der Vorbelegung 8,2 ct, und V2H-Rückspeisung sowie Speicher und Erzeuger unter Sonstiges übergingen eine monatlich gepflegte Vergütung („Einspeisevergütung wechselt monatlich”) — im Beispiel Speicher-Hub 192,00 statt 187,60 € (die Summe des T-Kontos), V2H 88,00 statt 108,00 €, Erlös eines sonstigen Erzeugers 25,60 statt 9,60 €. Jetzt lesen sie dieselbe Vergütung wie Cockpit → Monat; HA-Sensoren sind nicht betroffen.
E-Auto-Ersparnis mit eigenem Wallbox-Tarif: die HT/NT-Zeitfenster des Standard-Tarifs gelten nicht mehr für die Wallbox. Trug der Standard-Tarif Zeitfenster und gab es Stundenwerte, ersetzte eedc den Wallbox-Tarif durch den Zeitfenster-Ø des Standard-Tarifs — im Beispiel (Standard 30 ct, 22–6 Uhr 20 ct, Wallbox 25 ct) 760,00 statt 772,00 € in Cockpit, Komponenten-Hubs, Aussichten und den HA-Anlagensensoren für Jahresersparnis, ROI und Amortisation, während der HA-Sensor „Ersparnis vs Benzin” schon 772,00 € zeigte. Jetzt rechnen alle mit dem Wallbox-Tarif (bzw. dessen eigenen Zeitfenstern); in HA springen die drei Anlagensensoren einmalig — nur bei genau dieser Kombination.
Portal-Import aus einer SMA-Sunny-Portal-, Fronius-Solarweb- oder evcc-Datei: eine 0 in der Datei ist ein Wert. Bisher machten die Datei-Leser aus einer Monatssumme 0 „keine Daten” — ein Monat ohne PV-Ertrag stand schon in der Vorschau leer, und nach dem Import meldete der Daten-Checker „PV-Erzeugung fehlt”; jetzt steht dort 0, eine leere Zelle oder „-” bleibt eine Lücke.
Portal- und Cloud-Import: eine Speicher-Ladung oder -Entladung von 0 wird als 0 gespeichert. Bisher bekam der Speicher dann keinen Wert, und der Daten-Checker meldete „Speicher-Ladung fehlt” bzw. „Batterie-Ladung nicht erfasst” für einen echten Null-Monat; die Summen stimmten. Ein fehlender Wert bleibt leer — mit und ohne zugeordneten Wechselrichter.
Auswertungen → ROI, Kachel „Amortisations-Fortschritt”: der Tooltip rechnet wie die Kachel. Mit gepflegten sonstigen Ausgaben oder Erträgen zeigte er „Bisherige Erträge ÷ Relevante Kosten” mit anderen Zahlen als denen der Quote (im Beispiel „1.276 € ÷ 10.000 €” neben „= 16,9 %”); jetzt steht dort „1.776 € ÷ 10.500 €” — die Erträge ohne die sonstigen Positionen und der Kapitaleinsatz. Kachelzahl und „noch … €” waren richtig und bleiben.
Jahresbericht (PDF) eines einzelnen Jahres: die Rendite teilt nur noch durch die bis zum 31.12. angeschafften Komponenten. Bisher standen auch später gekaufte im Nenner (im Beispiel PV ab 2024, E-Auto ab 2025: Rendite 2024 6,7 % auf 15.000 € statt 10,1 % auf 10.000 €), zwei Zeilen neben dem Amortisations-Fortschritt, der schon nur die bis dahin angeschafften zählte. Der Gesamtzeitraum ist unverändert.
Daten-Checker „Monate vor dem ersten Tarif”: der Hinweis nennt beide Preise der Vorbelegung — 30 ct/kWh für den Netzbezug und 8,2 ct/kWh für die Einspeisung, jeweils sofern kein Monats-Ø bzw. Monatssatz gepflegt ist; bisher stand dort nur die 30 ct.
Aussichten → Finanzen und Auswertungen → ROI: eine PVGIS-Prognose mit leerem Monatswert bricht die Finanz-Prognose nicht mehr ab. Ein leerer Monatswert entsteht nur in einer von Hand bearbeiteten Export-Datei; bisher antwortete die Sicht mit einem Fehler und die Fortschritt-Kachel fehlte.
Import → Eigene Datei: tragen zwei Spalten dasselbe Geräte-Feld (zwei Schreibweisen desselben Gerätenamens), zeigt die Vorschau nur die Spalte, die der Import schreibt — die erste; bisher zeigte sie beide Werte.
Auswertungen → ROI, Zeile PV-System: der Eigenverbrauch kommt aus derselben Rechnung wie im Cockpit (ohne den Anteil des Balkonkraftwerks, das seine eigene Zeile hat) — bisher rechnete die Zeile „PV-Module minus Einspeisung der ganzen Anlage”: mit einem BHKW unter Sonstiges 1 560 statt 2 640 €, mit Abgabe an Dritte 1 824 statt 1 464 € (dieselbe Kilowattstunde stand zusätzlich als Erlös der Abgabe), und mit Speicher zählten seine Verluste als Eigenverbrauch (im Beispiel 36 € zu viel); Einsparung, ROI, Amortisation und CO₂ der Zeile ändern sich entsprechend.
Cockpit → Tag: fällt die HA-Summe eines String-Zählers (z. B. nach „Wert anpassen” nach unten), schiebt eedc die Differenz nicht mehr einem anderen Gerät zu — der String bekommt an diesem Tag seinen Anteil am Anlagenzähler nach kWp (wie in der gespeicherten Tageszeile), statt zu fehlen, während das Balkonkraftwerk den Rest erhielt (im Beispiel 53 statt 1,76 kWh); den Rückgang selbst nennt weiter der Daten-Checker.
Cockpit → Monat, T-Konto „Balkon”: das Balkonkraftwerk trägt dort dieselbe Ersparnis wie in Komponenten → Balkonkraftwerk — gleiche Menge, gleicher Preis (der der Eigenverbrauchs-Ersparnis des Monats) —, und die Kopfzahlen des Hubs sind die Summe seiner Monate — bisher setzte das T-Konto die ganze Erzeugung als Eigenverbrauch an (im Beispiel 27,00 statt 18,82 €, auch bei einem Balkonkraftwerk, dessen Module die Erzeugung schon selbst tragen), und der Hub zählte Monate ohne Zählerdaten als Einspeisung mit (im Beispiel Einspeisung 75,1 statt 15,1 kWh, Eigenverbrauchsquote 28,5 statt 66,5 %).
Komponenten → E-Auto: die externe Ladung im Kopf ist die Summe des Verlaufs, und eine externe Ladung ohne Kosten zählt — eedc wählt sie jetzt je Monat wie Cockpit und HA-Sensoren (das Paar mit den höheren Kosten aus Auto und Wallbox, bei gleichen Kosten die größere Menge), und Verlauf, Tabelle und Jahresvergleich zeigen genau diese Werte; bisher stand eine an der Wallbox erfasste externe Ladung (40 kWh) nur im Kopf, und eine am Auto ohne Kosten erfasste (80 kWh) fehlte im Kopf und in Cockpit → Monat.
Cockpit → Tag und Auswertungen → Tabelle: der nächtliche Wetter-Nachzug rechnet die Einstrahlung mit den Dachflächen, die an dem Tag in Betrieb waren — bisher zählte eine später zugebaute Fläche mit anderer Ausrichtung auch an den Tagen davor mit, und die Performance Ratio stand zu hoch (im Beispiel 1,00 statt 0,80).
Jahresbericht (PDF): die Zeile „Investition Mehrkosten” nennt die Zahl, durch die die Rendite darunter teilt, und sagt, welche Investitionen sie zählt (bis 31.12. des Jahres angeschafft, auch vorher stillgelegte) — bisher standen bei einer Stilllegung vor dem Berichtsjahr zwei verschiedene Mehrkosten auf der Seite (im Beispiel 10 000 und 15 000 €).
Cockpit → Monat und Jahr, Monatsbericht (PDF): „PV-Erzeugung aus” nennt auch das Balkonkraftwerk, dessen Erzeugung in der Zahl daneben steckt; und im PV-Hub steht am spezifischen Ertrag „hochgerechnet aufs Jahr”, weil er ein Jahreswert ist und kein Quotient der daneben gezeigten Erzeugung.
Monatsabschluss: misst Home Assistant oder MQTT für einen Monat 0 kWh — etwa Einspeisung, Speicher-Ladung/-Entladung oder Wärmemenge der Wärmepumpe —, schlägt eedc die 0 vor („0 — kein Zuwachs”). Bisher belegte das Formular das Feld mit dem Vormonat und dem Abzeichen „geschätzt” vor (im Beispiel Einspeisung 55, Entladung 40, Heizenergie 900 kWh); wer speicherte, hatte eine erfundene Zahl im Monat. Auf dem MQTT-Weg kam auch die 0 einer Wallbox ohne Ladung bisher nicht an. Bei der PV-Erzeugung und dem PV-Anteil einer Ladung bleibt es wie bisher: dort kann eine 0 auch eine stehengebliebene Integration sein.
Import → Eigene Datei und CSV-Import mit den Spalten Batterie_Ladung_kWh/Batterie_Entladung_kWh: eine Speicher-Ladung oder -Entladung von 0 kommt am Speicher an — wie beim Portal-Import. Bisher bekam der Speicher dann keinen Wert, der Daten-Checker meldete z. B. „Akku: Entladung nicht erfasst (Ladung 50,0 kWh vorhanden)”, und der Speicher-Hub zeigte „—”; die Summen stimmten. Eine leere Zelle bleibt leer.
Cockpit → Monat und Jahr: der Hinweis „PV-Erzeugung ist eine Teilsumme” fehlt nicht mehr, wenn im Monat eine Wallbox-Zeile ohne PV-Anteil steht. Fehlte einem PV-Modul der Monatswert (und gab es keinen Gesamtwert), verschwand der Hinweis in diesem Fall, und der Daten-Checker prüfte gegen die Teilsumme; die PV-Zahl selbst bleibt dieselbe.
Cockpit → Monat (laufender Monat): trägt der Netzbezugs- oder Einspeisezähler nur einen Teil der Tage, sagt der Monat es. Liefert Home Assistant für einen zugeordneten Zähler keine Werte mehr (etwa nach dem Umbenennen der Entity), rechnete der Monat mit den wenigen vorhandenen Stunden weiter — im Beispiel Netzbezug 0,4 kWh und Autarkie 99,1 % statt 21,6 kWh und 67,6 % — ohne Hinweis. Jetzt steht „Der Netzbezug ist eine Teilsumme …” dabei; die Zahl bleibt, bis der Zähler wieder Werte liefert.
HA-Sensoren „Strom Heizbetrieb” / „Strom Warmwasserbetrieb” / „Strom Kühlbetrieb” einer Wärmepumpe: dieselben Werte wie Cockpit → Übersicht. Bei einer Wärmepumpe mit Gesamtstromzähler und Betriebsart-Sensor, aber ohne Leistungssensor, meldeten sie nach einem HA-Statistik-Import 0 und sonst den laufenden Monat nicht mit (im Beispiel 0 / 0 bzw. 198 / 18 statt 217,8 / 19,8 kWh). ⚠ Die Sensoren springen nach dem Update einmalig auf den richtigen Wert — in der HA-Langzeitstatistik steht dieser Sprung als Zuwachs am Update-Tag.
Cockpit → Live, Tagesverlauf: der Hinweis „Nicht dargestellt (kein HA-Leistungssensor): …“ erscheint jetzt. Ein Gerät ohne zugeordneten Leistungssensor fehlt im Tagesverlauf — seine Last steckt im Restverbrauch —, und seit v3.10.3 (#109) sollte der Satz darüber sagen, welches. Die Liste kam aber nie beim Chart an; der Hinweis blieb immer aus. Jetzt nennt er die Geräte. Es ändert sich keine Zahl.
Cockpit → Monat: ein Monat, dessen Monatszeile keine Netzwerte geliefert bekam, zeigt nicht mehr Einspeisung 0, Netzbezug 0 und Autarkie 100 %. Legte ein Import die Zeile ohne Netzbezug bzw. Einspeisung an (z. B. ein Portal-Import nur mit Wallbox-Daten, ein eigenes Format ohne Netzspalte, ein HA-Statistik-Import mit abgewähltem Netzfeld), stand dort eine 0, die niemand gemessen hatte — sie galt als gespeicherter Wert und sperrte HA-Statistik und Tageswerte (im Beispiel 0 / 0 / 100 % statt Netzbezug 250, Einspeisung 700, Autarkie 66,7 %; Eigenverbrauch 1200 statt 500 kWh). Jetzt zählt eine 0 nur, wenn sie geliefert wurde (eingetragen oder importiert); sonst nimmt das Cockpit den Wert aus der HA-Statistik bzw. im laufenden Monat aus den Tageswerten, und ohne Quelle bleibt das Feld leer. Der Daten-Checker meldet einen solchen Monat jetzt mit „Netzbezug nicht erfasst” bzw. „Einspeisung nicht erfasst” (die Meldung konnte bisher nie erscheinen) und nennt den Handgriff: zuerst den HA-Statistik-Import, sonst im Monatsabschluss den gemessenen Wert eintragen (N-734, N-739).
Übersicht, Jahresbericht, HA-Sensoren, Community-Upload, Auswertungen → Tabelle und Aussichten → Finanzen: ein Monat ohne erfassten Netzbezug bzw. Einspeisung zählt dort nicht mehr mit Autarkie 100 %. Legte ein Import die Monatszeile ohne Netzwerte an (z. B. nur mit Wallbox-Daten), rechneten diese Sichten mit der 0, die dort stand: Eigenverbrauch = ganze PV-Erzeugung, Autarkie 100 %, Ersparnis und CO₂ auf die ganze PV (im Beispiel Eigenverbrauch 1200 statt 500 kWh, Ersparnis 360 statt 150 €, CO₂ 456 statt 190 kg; der HA-Sensor und der Community-Benchmark bekamen Autarkie 100 %) — während Cockpit → Monat den Monat seit dem vorigen Punkt richtig zeigt. Jetzt fehlt ein solcher Monat dort bei Eigenverbrauch, Autarkie, Ersparnis, USt und CO₂, bis Netzbezug und Einspeisung erfasst sind (wie ein Monat ohne Monatsabschluss); seine PV-Erzeugung zählt weiter, Auswertungen → Tabelle und der Jahresbericht zeigen bei ihm „–”, der Community-Upload teilt ihn nicht. Tragen die Tageswerte des Monats das fehlende Feld, nimmt eedc es wo möglich von dort. Eine eingetragene oder importierte 0 bleibt eine 0 (Balkonkraftwerk ohne Einspeisung). Der Daten-Checker nennt den Monat mit „Netzbezug nicht erfasst” bzw. „Einspeisung nicht erfasst” (N-736).
Monatsabschluss: ein neu angelegter Monat merkt sich wieder, dass seine Werte von dir eingetragen sind. Seit Mai 2026 ging beim ersten Speichern eines neuen Monats die Herkunftsangabe „im Formular eingetragen” verloren (beim späteren Bearbeiten nicht). Dadurch galt der Schutz „von Hand gepflegt schlägt Import und HA-Statistik” für neu angelegte Monate nicht, und eine eingetragene 0 war von einem leeren Feld nicht zu unterscheiden. Jetzt steht die Herkunft gleich beim Anlegen fest (N-735), und die seit Mai 2026 so angelegten Monate bekommen sie beim ersten Start nach dem Update für Einspeisung und Netzbezug nachgetragen — eine eingetragene 0 zählt dort wieder als 0, und der HA-Statistik-Import mit „Überschreiben” ersetzt die Handwerte nicht mehr (im Beispiel 180 / 250 statt 999 / 888 kWh); Monate aus dem alten Monatsabschluss-Assistenten (Mai bis Juli 2026) werden nicht nachgetragen, weil er ein leer gelassenes Feld nicht lieferte — der Daten-Checker nennt sie (N-738).
Cloud-Import (EcoFlow PowerStream und PowerOcean, Viessmann Gridbox, Growatt, Hoymiles S-Miles): eine gelieferte 0 ist ein Wert. Diese Importer machten aus einer Monatssumme 0 „keine Daten” — etwa die Einspeisung 0 eines Balkonkraftwerks ohne Einspeisung oder eine Speicher-Ladung 0. Mit der Regel „eine 0 zählt nur, wenn sie geliefert wurde” (Zeile oben) hätte Cockpit → Monat Einspeisung, Eigenverbrauch und Autarkie solcher Monate leer gezeigt und der Daten-Checker „Einspeisung nicht erfasst” gemeldet (im Beispiel statt Netzbezug 1 500, Einspeisung 0, Eigenverbrauch 480 kWh, Autarkie 24,2 %). Jetzt kommt die 0 als Wert an; ein Feld, das die Quelle nicht liefert, bleibt leer, und ein Monat nur aus Nullen erscheint weiter nicht (N-737).
HA-Statistik-Import und CSV-Backup-Restore: ein Netzfeld ohne Wert gilt nicht mehr als geliefert. Legte der HA-Statistik-Import einen Monat an, für dessen Einspeisung oder Netzbezug kein Sensorwert vorlag, oder enthielt eine CSV-Zeile eine leere Zelle, stand das Feld mit 0 als „geliefert” da — der Daten-Checker „… nicht erfasst” schwieg. Jetzt meldet er den Monat; eine gelieferte 0 bleibt eine 0. Beim CSV-Restore in einen vorhandenen Monat überschreibt eine leere Zelle den gespeicherten Wert nicht mehr mit 0 (N-740).
Daten-Checker → Monatsdaten: der „Beheben”-Link öffnet den Monat. Die Meldungen zu einem einzelnen Monat („MM/JJJJ fehlt”, „… nicht erfasst”, „Einspeisung > PV-Erzeugung”, „beide 0” usw.) führten nur auf die Seite Einstellungen → Daten, der Monat öffnete sich nicht; jetzt öffnet der Link seine Erfassung. Ein Monat ohne erfassten Netzbezug bzw. ohne erfasste Einspeisung zeigt das Feld im Monatsabschluss leer statt mit 0 — wer ungeprüft speicherte, trug die 0 bisher als gemessen ein; liegt ein Vorschlag (etwa aus der HA-Statistik) vor, steht er im Feld (N-739).
Jahresbericht (PDF): die Zeile „Investition gesamt” sagt, welche Investitionen sie zählt — im Einzeljahr die Vollkosten der im Jahr aktiven, im Gesamtzeitraum aller Investitionen. Die Zahl bleibt.
Cockpit → Live: fehlt der Tagesverlauf, sagt die Seite warum. Die Kurve braucht eine Leistungs-Zuordnung unter Datenquellen (Home Assistant); mit MQTT-Inbound oder ohne Zuordnung fehlte der Block bisher wortlos.
Community → Übersicht, Performance-Profil (Radar): Autarkie und Eigenverbrauch stehen gegen den Community-Durchschnitt desselben Monats. Bisher stand auf diesen beiden Achsen unter „Community“ eine feste Zahl (65 % bzw. 45 %), keine Community-Zahl, und dein Wert war der neueste Monat, auch der laufende — 90 % im Juni wie 18 % im Januar standen gegen dieselben 65. Jetzt vergleicht der Radar deinen letzten abgeschlossenen Monat mit dem Community-Durchschnitt dieses Monats und nennt ihn unter dem Diagramm („Vergleich: September 2026“). Liefert der Community-Server für den Monat keinen Durchschnitt, fällt die Achse weg; eine Autarkie von 0 % wird gezeigt (N-742).
Community → Komponenten → Wärmepumpe: „JAZ nach Bauart“ erscheint jetzt wirklich. Die seit v4.0.41 angekündigte Sicht blieb für jede Anlage aus, weil eedc die Anfrage nicht an den Community-Server weiterreichte; jetzt steht der Bauart-Vergleich über dem Regionalbalken. Ein neuer Test hält alle Community-Anfragen der Oberfläche gegen die Weiterleitungen von eedc (N-743).
Community → Komponenten, Speicher nach Kapazitätsklasse: eine Klasse ohne Community-Wert zeigt „—“ statt 0. Für eine Klasse mit weniger als drei Werten liefert der Community-Server bewusst keinen Wert; die Tabelle zeigte dort „0“ Zyklen und „0,0 %“ Wirkungsgrad (im Oktober 2026 die Klasse bis 5 kWh mit 11 Anlagen). Dasselbe gilt für die E-Auto-Tabelle nach Nutzungsintensität. Ein Speicher unter 5 kWh bekommt in seiner Klasse jetzt auch sein „(Du)“ (N-745).

Changed

Cockpit → Tag: kWh-Werte mit einer Nachkommastelle. Kacheln samt Vortag-Zeile, Energie-Bilanz-Tabelle (IST, Vortag, Ø Wochentag) und die Rechenwege in den Tooltips zeigen Tagesmengen jetzt wie Cockpit → Live mit einer Nachkommastelle — ganzzahlig stand an kleinen Tagen „0 kWh” Netzbezug neben einer Autarkie unter 100 %. Prozent und Euro, Monat und Jahr bleiben, wie sie sind (#426 rapahl).
Doku: Werkbank, Kappung und Hintergrund-Abläufe so beschrieben, wie eedc rechnet. Das Handbuch Energieprofil sagte, eedc kappe unmöglich hohe Werte — der Deckel gilt nur für PV und Einspeisung in den Stundenwerten, die Tages- und Monats-Kennzahlen aus dem HA-Spiegel übernehmen HAs Statistik wie das Energie-Dashboard. Werkbank und Daten-Checker sagen jetzt, dass „Tag neu aggregieren” Stundenwerte und Tageszeile baut, die Tages-Kennzahlen aber der HA-Abgleich. Einstellungen §9 beschrieb eine :55-Live-Vorschau für HA-Zähler, die es seit v3.25.18 nicht mehr gibt, und Lücken-Interpolation für alle Pfade (MartyBr, simon42 #429).
Doku: E-Auto-Heimladung neben einer Wallbox in Daten-Checker-Handbuch, Sensor-Referenz und MQTT-Inbound auf den Stand von v4.0.51 gebracht (die Felder werden angeboten, eine Messung am Auto ist freiwillig; „Heim: gesamt” als MQTT-Topic ergänzt) (#425 gruaGit).
Doku: CO₂ eines Erzeugers unter Sonstiges (BHKW, Windrad, Wasserkraft) so beschrieben, wie eedc rechnet. Berechnungen und Sensor-Referenz sagten, ein solcher Erzeuger bekomme „bewusst keine CO₂-Gutschrift” — eedc rechnet seinen selbst verbrauchten Strom aber wie beim Geldwert als vermiedenen Netzstrom (0,38 kg/kWh) und kann den Eigenverbrauch am Hauszähler nicht in PV- und BHKW-Anteil trennen; die Emission des Erzeugers selbst (z. B. Gas eines BHKW) zieht es nicht ab, weil es sie nicht kennt. Keine Zahl ändert sich.
Intern: der Feld-Wächter zählt nur noch Code, und die Liste „ausgewertet in“ nennt die wirklichen Leser. test_jedes_feld_hat_eine_auswertung sucht den Feldnamen jetzt im ausführbaren Quelltext des genannten Symbols — Docstring, Kommentar und Funktionsname zählen nicht mehr als Lesen (N-686). Acht Einträge waren nur dadurch grün; sie zeigen jetzt auf die Stelle, die das Feld wirklich liest (Ø-Temperatur, Ø-Netzbezugspreis, Kraftstoff- und Gaspreis, WP-Strom, BKW-Erzeugung, Betriebsmodus, PV-Gesamtzähler — dessen alter Leser wurde seit dem 26.09. nur noch von Tests gerufen). Der Eintrag „Wechselrichter-Leistung → Cockpit → Live“ entfällt: kein Live-Pfad liest sie, und die Datenquellen-Fläche zeigt den Wechselrichter gar nicht (N-685); das Feld steht jetzt mit Begründung in der Ausnahmeliste. Für Anwender ändert sich keine Anzeige.
Doku: Community-Funktionen so beschrieben, wie sie sind. Die Funktionsübersicht der Website nannte einen Radar mit sechs Achsen und Detailvergleiche für alle Komponenten, das Handbuch Achievements, die es nicht gibt, und Kennzahlen, die die Komponenten-Seite nicht zeigt. Jetzt stehen dort bis zu fünf Radar-Achsen, die sieben Achievements aus der App und je Komponente die Kennzahlen der App — mit dem Hinweis, dass der Speicher keinen Community-Vergleich hat.

[4.1.6] - 2026-10-11 — Konsolidierung: 31 Korrekturen an Anzeige, Daten-Checker, Import und Hubs; eedc im Wartungsmodus

Added

Daten-Checker: neue Prüfung „PV – Zähler steht”. Friert der PV-Gesamtzähler der Anlage ein — der Sensor meldet weiter, aber sein Stand bewegt sich nicht —, rechnet eedc für diese Tage „keine Erzeugung”, und Cockpit → Tag oder Monat zeigen z. B. eine negative Autarkie. eedc lässt die Zahlen so, wie sie gemessen sind; der Daten-Checker nennt jetzt die Ursache: den Zähler, der seit mindestens drei Tagen steht, obwohl die Einspeisung oder die String-Zähler weiter wachsen. Eine Nulleinspeisung, autarke Tage, Schnee, Teilbeschattung oder ein Speicher, der ins Netz entlädt, lösen die Meldung nicht aus.

Fixed

Abhängigkeit gedeckelt: pymodbus<3.16. Die am 11.10.2026 erschienene 3.16.0 (transitiv über pysma-plus) bricht beim Import ohne das Extra serial mit NameError: pyserial; ein frisch gebautes Image wäre nicht gestartet. Gefangen vom Prod-Paritäts-Check des Release-Scripts, Obergrenze bis upstream repariert ist.
Komponenten → Sonstiges: der Verlauf eines Zählers (Gas, Wasser …) trägt die richtigen Monatsnamen. Jeder Monat stand einen Monat zu früh beschriftet — der Juni-Verbrauch hieß „Mai”, der Januar hatte keinen Namen. Die Werte selbst waren richtig.
Cockpit → Jahr → Verlauf: die Zeile über dem Diagramm behauptet keine Gleichung mehr. Sie lautete „Eigenverbrauch + Einspeisung = PV-Erzeugung”. Das geht schon mit jedem Speicher nicht auf (Wandlungsverluste), mit BHKW oder V2H ebenfalls nicht. Jetzt nennt sie die beiden gestapelten Größen und sagt, dass die Summe dann von der PV-Erzeugung abweicht; die Balken sind unverändert.
Cockpit → Monat (Monatsleiste) und Jahresbericht-PDF: ein Monat ohne Werte zeigt einen Strich statt „0 kWh”. Ein nicht erfasster Monat sah aus wie ein Monat mit 0 kWh, im PDF zusätzlich mit „0,0 %” Autarkie und „0,00 €” Ertrag. Jetzt steht dort der Strich, und die Leiste zeichnet für ihn keinen Balken. Eine gemessene 0 bleibt eine 0; die Summen ändern sich nicht.
Komponenten → PV-Anlage: sind nur einige Strings gemessen, sagt der Hinweis das. Bisher stand dort auch dann „Werte je Modul sind nicht gemessen”, wenn ein Teil der Strings eigene Zähler hat. Jetzt heißt es im Mischfall, dass nicht alle Module gemessene Werte haben und ein Teil nach kWp verteilt ist. Einen besten oder schwächsten String nennt eedc weiterhin erst, wenn alle Strings gemessen sind.
Monatsdaten „Aus HA laden”: die Zeile unter „PV-Erzeugung (berechnet)” nennt alle Erzeuger, die in der Summe stecken. Sie sagte „Aus PV-Modulen”, auch wenn das Balkonkraftwerk oder ein sonstiger Erzeuger (BHKW) mitgezählt war. Jetzt nennt sie jede beteiligte Gruppe; die Zahl ist dieselbe.
Cockpit → Jahr mit Zeittarif (HT/NT): der Tooltip am Ø-Preis nennt die richtige Herkunft. Er sagte „Arbeitspreis aus dem Strompreis-Tarif”, obwohl der Ø über die HT/NT-Zeitfenster gewichtet ist; ein im Monatsabschluss gepflegter Ø hieß dort „dynamischer Tarif”. Jetzt steht im Jahr dieselbe Herkunft wie im Monat, und stammen die Monate aus verschiedenen Quellen, sagt der Tooltip das. Der Preis selbst ändert sich nicht.
Hilfe: keine „Jahres-Rendite” im Cockpit mehr. Berechnungen, Bedienungs-Handbuch und Architektur beschrieben eine Rendite-Anzeige im Cockpit, die es nicht gibt. Die Rendite deiner Anlage steht unter Auswertungen → ROI.
Daten-Checker: kein „Balkonkraftwerk: PV-Erzeugung fehlt” mehr, wenn der Anlagenzähler den Monat trägt. Ein Balkonkraftwerk ohne eigenen Zähler bekommt seinen Anteil aus dem PV-Gesamtzähler der Anlage — es fehlt nichts. Die Warnung stand trotzdem da, direkt neben der OK-Meldung der PV-Prüfung. Jetzt kommt sie nur noch für Monate, in denen weder ein eigener Wert noch ein Gesamtwert gespeichert ist.
HA-Statistik-Import: Wandlungsverluste sind kein Konflikt mehr. Misst dein PV-Gesamtzähler nach dem Wechselrichter und haben alle Strings eigene Zähler, liegt der Gesamtzähler um die Wechselrichterverluste darunter. Die Vorschau zeigte das nach jedem Import als „Konflikt — PV Erzeugung Gesamt 36,0”. Jetzt nennt sie die Differenz als „Wandlungsverluste 36,0 kWh” und bewertet den Monat wie die übrigen Felder. Zählt der Gesamtzähler dagegen mehr als die Strings, oder ist die Differenz für Wandlungsverluste zu groß, bleibt es ein Konflikt.
Klimageräte mit Innengeräten: die Zähler je Innengerät kommen im Statistik-Import und im Monatsabschluss an. Ein Zähler, der einem einzelnen Innengerät zugeordnet ist (z. B. „Wohnzimmer: Strom Kühlen”), fehlte in der Import-Vorschau, wurde vom Sammelimport nicht gespeichert und im Monatsabschluss nicht vorgeschlagen — nur „Aus HA laden” kannte ihn. Jetzt gilt er auf allen vier Wegen.
Eine gelöschte Komponente nimmt ihre Messreihen mit. Beim Löschen blieben ihre stündlichen Zählerstände und Kanäle stehen. Legtest du danach eine neue Komponente an, bekam sie oft dieselbe interne Nummer — und übernahm damit die Messwerte der gelöschten. Jetzt räumt das Löschen sie mit weg, und das Aktivitätsprotokoll nennt, wie viele es waren.
Stündliche Zählerstände: ein Fehler bei einer Anlage kostet die anderen ihre Stunde nicht mehr. Scheiterte beim stündlichen Mitschreiben das Speichern für eine Anlage (etwa weil die Datenbank gerade belegt war), fehlte die Stunde für alle Anlagen — auch für die schon geschriebenen. Mit Home Assistant holte eedc sie später aus der Statistik nach, per MQTT gemessene Stunden blieben verloren. Jetzt bleibt der Fehler bei der einen Anlage und steht im Aktivitätsprotokoll; dasselbe gilt für das Nachholen der Stunden nach einem Neustart.
Wärmepumpe mit flexiblem Tarif: die Ersparnis rechnet mit deinem Monatsdurchschnitt. Hast du im Monatsabschluss einen Ø-Preis gepflegt (oder schreibt eedc die Stundenpreise mit) und hat die Wärmepumpe keinen eigenen Tarif, rechnete ihre Zeile trotzdem mit dem Arbeitspreis des Tarifs — z. B. 30 statt 24 ct. Netzbezug und Wallbox nahmen schon den Durchschnitt. Jetzt gilt er auch für die Wärmepumpe — in ihrer Ersparnis (Cockpit, Auswertungen → Komponenten) und in ihren Kosten je Wärmefunktion. Mit eigenem Wärmepumpen-Tarif ändert sich nichts.
Sonstiger Erzeuger (z. B. BHKW), dessen Wert im Ersatzfeld steht: der abgeschlossene Monat zeigt ihn. Trug die Monatszeile eines Erzeugers ihren Wert nur im Ersatzfeld „Verbrauch” statt in „Erzeugung”, stand der abgeschlossene Monat bei 0, während der laufende Monat den Wert zeigte. Jetzt liest der Monat das Feld wie der Tag — auch Komponenten → Sonstiges —, und die Erzeugung zählt in Eigenverbrauch und Autarkie.
PV-Strings und Jahresbericht: das SOLL eines Strings ist sein Anteil an der Prognose — in allen Sichten dieselbe Zahl. Ohne eigene Prognose je String verteilt eedc die Anlagen-Prognose nach kWp. Geteilt wurde dabei durch die kWp aller je angelegten Strings (Komponenten → PV-Anlage, Auswertungen → Prognose) bzw. der im Berichtsjahr aktiven (Jahresbericht): Nach einer Stilllegung stand das SOLL der übrigen Strings zu niedrig, nach einem Zubau stand es im Jahresbericht der Vorjahre zu hoch (Beispiel 6-kWp-String: 3 408 bzw. 7 668 statt 5 112 kWh). Jetzt teilt eedc durch die kWp, für die die Prognose gerechnet ist, und alle drei Sichten nennen 5 112 kWh. Mit einer Prognose je String ändert sich nichts.
HA-Sensoren und Komponenten → PV-Anlage: ein Monat ohne Einspeise- und Bezugswerte zählt nicht mehr ganz als Eigenverbrauch. Eigenverbrauch, Autarkie und Eigenverbrauchsquote nahmen die PV-Erzeugung aller Monate, Einspeisung und Netzbezug aber nur aus den Monaten mit Zählerwerten — ein Monat mit Erzeugung, aber ohne Monatsabschluss, ging damit vollständig als Eigenverbrauch in die Bilanz ein, die Ersparnis rechnete ihn dagegen nicht (Beispiel: 800 statt 200 kWh Eigenverbrauch, 80 statt 50 % Autarkie). Im HA-Export zogen Ersparnis und CO₂ dadurch auch verschieden viele Wandlungsverluste ab. Jetzt rechnen die HA-Sensoren (Eigenverbrauch, Autarkie, Eigenverbrauchsquote, Ersparnis, CO₂), die Kennzahlen unter Komponenten → PV-Anlage und die CO₂-Einsparung des PV-Stroms in Auswertungen → CO₂ und im CO₂-Block von Cockpit → Jahr über dieselben Monate (Beispiel: 76 statt 304 kg); die PV-Erzeugung zeigt weiterhin jeden Monat. Liegen Einspeise- und Bezugswerte vor, bevor dein erster Erzeuger angeschafft ist, zählen sie in den HA-Sensoren „Einspeisung” und „Netzbezug” nicht mehr mit.
Komponenten → Balkonkraftwerk ohne eigenen Zähler: Kennzahlen und Verlauf zeigen seinen Anteil am PV-Gesamtzähler. Hat dein Balkonkraftwerk keinen eigenen Erzeugungs-Sensor, standen dort 0 kWh und „Keine Verlaufsdaten erfasst”, während Cockpit → Monat ihm seinen Anteil am PV-Gesamtzähler der Anlage (nach kWp) zuschreibt. Jetzt zeigt der Reiter dieselbe Erzeugung wie das Cockpit, samt Eigenverbrauch, Einspeisung, Ersparnis und CO₂, und kennzeichnet sie als „geschätzt (kWp-Anteil)” — wie die PV-Module ohne eigenen Zähler. Mit eigenem Zähler ändert sich nichts.
Wärmepumpe im Standby-Monat: alle Sichten nennen dieselbe Ersparnis. Verbraucht die Wärmepumpe in einem Monat Strom, gibt aber keine Wärme ab (Sommer, nur Bereitschaft), zog der HA-Sensor „Ersparnis” der Wärmepumpe und die Aussichten (bisherige Erträge, ROI-Fortschritt) diesen Strom von der Ersparnis ab, Cockpit und Komponenten-Hub nicht — und Cockpit → Monat führte die WP-Ersparnis des Monats als „fehlt”. Jetzt trägt der Monat eine Zeile mit 0 € und dem Etikett „Standby”; der Strom bleibt als Verbrauch und Kosten sichtbar, wird aber nirgends gegen die ersetzte Heizung gerechnet.
Wärmepumpe mit nur einem Wärmezähler für alles: Heizung und Warmwasser heißen überall „keine Angabe”. Misst ein Zähler die ganze Wärme, weiß eedc nicht, wie viel davon Heizung und wie viel Warmwasser war. Einige Sichten zeigten trotzdem „0 kWh” — u. a. Auswertungen → Tabelle (Spalten „WP Wärme Heizen/WW” und die daraus gebildete „WP Wärme”) —, andere einen Strich. Dasselbe gilt in der Monatstabelle unter Komponenten → Wärmepumpe für einzelne Monate ohne Heiz- oder Warmwasser-Wert. Jetzt steht überall der Strich; die Wärme gesamt gilt unverändert. Umgekehrt zeigen Cockpit → Monat und der Jahresbericht eine gemessene 0 (Heizzähler im Sommer) jetzt als 0 statt als Strich.
Zeittarif (HT/NT): die Eigenverbrauchs-Ersparnis des Monats ist die Summe seiner Tage. Mit Zeitfenstern im Tarif bewerteten Cockpit → Monat, Cockpit → Jahr, die Übersicht und Auswertungen → Tabelle deinen Eigenverbrauch mit dem Durchschnittspreis deines Netzbezugs — der fällt aber zu anderen Stunden an (abends, nachts) als der Eigenverbrauch (mittags). Cockpit → Tag nahm schon den Preis der jeweiligen Stunde, und die Tage ergaben zusammen eine andere Ersparnis als der Monat (Beispiel mit günstigem Mittagsfenster: 96,00 € im Monat gegen 90,00 € über die Tage). Jetzt bewertet auch der Monat jede Kilowattstunde mit dem Preis der Stunde, in der sie den Bezug vermieden hat. Ohne Stundenwerte (handgetragene Monate) bleibt es beim Durchschnittspreis.
Komponenten → Balkonkraftwerk mit Modul-Kindern: keine doppelte Erzeugung mehr. Hängen PV-Module an deinem Balkonkraftwerk, steht seine Erzeugung bei diesen Modulen — das Cockpit zählt sie dort. Der Reiter zeigte sie trotzdem noch einmal am Balkonkraftwerk (z. B. 90 kWh und 19,29 € Ersparnis). Jetzt nennt er dort 0 und sagt, dass die Erzeugung bei den Modul-Kindern steht.
Die E-Auto-Ersparnis zählte Solarstrom doppelt. Was dein E-Auto aus der PV-Anlage lädt, schreibt eedc bereits als Eigenverbrauch gut — die E-Auto-Ersparnis gegenüber dem Verbrenner setzte denselben Strom zusätzlich als kostenlos an. In einer Beispielanlage (200 kWh PV-Ladung im Jahr, 30 ct) stand die Gesamtersparnis so 60 € zu hoch (399,50 statt 339,50 €). Jetzt zieht die E-Auto-Ersparnis den Strom der ganzen Ladung ab: die Netzladung zu ihrem Preis (Wallbox-Tarif, wenn du einen hast), die PV-Ladung zu dem Preis, mit dem eedc sie als Eigenverbrauch gutschreibt. Das gilt in Auswertungen → ROI, Cockpit → Monat und Jahr, den Aussichten, Komponenten → E-Auto und den HA-Sensoren (einmaliger Sprung in der HA-Langzeitstatistik von „Ersparnis vs Benzin”, „Jahres-Ersparnis”, „ROI” und „Amortisation”); die CO₂-Einsparung des E-Autos rechnet ebenso mit der ganzen Ladung — in Auswertungen → ROI, Auswertungen → CO₂, im CO₂-Block von Cockpit → Jahr, im Jahresbericht und im HA-Sensor „CO₂ Einsparung” (einmaliger Sprung in dessen Langzeitstatistik; Beispielanlage 431,5 statt 507,5 kg). Der PV-Anteil der Ladung bleibt als Menge und Prozent sichtbar. Die Energiebilanz ändert sich nicht.
Cockpit → Jahr mit dynamischem Tarif: der Ø-Preis passt zu den Kosten darunter. Für einen Monat ohne Monatsabschluss, in dem eedc die Stundenpreise mitschreibt, nahm der Jahres-Ø den Tarifpreis statt des gemessenen Monatspreises — die Kachel zeigte z. B. „200 kWh · 50,00 €” unter 30,0 ct statt 25,0 ct, während der Monat selbst den gemessenen Preis nannte. Jetzt geht jeder Monat mit dem Preis in den Jahres-Ø ein, mit dem er seine Kosten rechnet; die Kosten waren schon richtig.
Komponenten → Wärmepumpe: kein Balken „Warmwasser 100 %” mehr bei einem Gesamt-Wärmezähler. Hast du Wärme gesamt und daneben nur einen Warmwasser-Zähler, ist die Heizwärme nicht gemessen — der Balken Wärme nach Zweck zeigte trotzdem „Heizung 0 kWh · Warmwasser 100 %” unter z. B. 300 kWh erzeugter Wärme. Jetzt entfällt er in diesem Fall; die Wärmemenge steht wie bisher in der Kachel.
Komponenten → PV-Anlage und Auswertungen → Prognose: kein Hinweis „PVGIS-Prognose passt nicht” nach einer Stilllegung. Der Hinweis verglich die Prognose mit allen je angelegten Strings und nannte z. B. „die Anlage hat aktuell 15,0 kWp”, obwohl nach der Stilllegung eines Strings nur noch 10 kWp laufen und die Prognose genau dafür gerechnet ist. Jetzt vergleicht er mit den heute aktiven Strings; nach einem Zubau ohne neuen Abruf erscheint er weiterhin.
Komponenten → PV-Anlage, Gesamtlaufzeit: der „typische Monat” eines Strings stimmt auch nach einer Stilllegung. Das SOLL des saisonalen Mittels verteilte die Prognose über alle je angelegten Strings, auch stillgelegte — ein 6-kWp-String stand im Juni bei 282,7 statt 424,0 kWh, während seine Jahreswerte daneben stimmten. Jetzt zählt je String nur, wann er aktiv war, und die Anlagen-Zeile summiert je Monat die Strings, die dann liefen.

Changed

Hilfe präzisiert: Zeitraum bei spät angelegtem HA-Sensor, vergangene Monate ohne Abschluss im Standalone-Betrieb, Wärme gesamt neben einem Warmwasser-Zähler und was erst mit dem Monatsabschluss zählt (die Netzladung des Speichers, ohne Home Assistant auch Monate vor der vollständigen MQTT-Mitschrift).

[4.1.5] - 2026-10-10 — Wandlungsverluste zählen nicht mehr als Ersparnis und CO₂, Zählerstand-Meldung klarer, ROI-CO₂ wie das Cockpit

Fixed

Auswertungen → ROI nennt dieselbe CO₂-Einsparung wie das Cockpit. Die PV-Zeile der ROI-Seite rechnete die CO₂-Einsparung als Erzeugung × 0,38 — auch für den eingespeisten Strom, den Cockpit, HA-Sensor und Jahresbericht nicht als CO₂-Einsparung der Anlage zählen (sie rechnen auf dem Eigenverbrauch). Bei 40 % Einspeisung lag die Zahl damit um zwei Drittel über dem Cockpit, dem HA-Sensor und dem Jahresbericht. Jetzt rechnet sie wie diese auf dem Eigenverbrauch (ohne Wandlungsverluste, wo eedc sie kennt), hochgerechnet auf ein Jahr wie die Ersparnis daneben. Dasselbe gilt für den CO₂-Wert in den Monatskennzahlen einer einzelnen Monatszeile. Die Geldwerte der ROI-Seite ändern sich dadurch nicht.
Wandlungsverluste werden nicht mehr als Ersparnis und CO₂-Einsparung bewertet. Bei Anlagen mit String-Zählern und einem Anlagenzähler hinter dem Wechselrichter rechneten Ersparnis, Netto-Ertrag, ROI, die Umsatzsteuer auf den Eigenverbrauch und CO₂ mit dem Eigenverbrauch inklusive der im Wechselrichter verlorenen Energie — Strom, den niemand gekauft hätte (beim Volleinspeiser am Tag Cent-Beträge ohne jeden Eigenverbrauch). Jetzt bewerten alle Sichten (Cockpit Tag/Monat/Jahr/Übersicht, Auswertungen → Tabelle und ROI, Jahresbericht, HA-Export, Community-CO₂, Balkonkraftwerk-Hub) den Eigenverbrauch ohne diese Verluste, wenn eedc sie sicher kennt; die Bilanz (Eigenverbrauch, Autarkie, Eigenverbrauchsquote) trägt sie weiter. Kein Abzug bei DC-gekoppeltem Speicher (auch angenommen, wenn die Kopplung nicht eingetragen ist und der Speicher am Wechselrichter hängt), bei mehr als 10 % Differenz und wenn der Anlagenzähler das Balkonkraftwerk offenbar nicht misst — der neue Daten-Checker „PV – Messpunkt” nennt den Grund und den Handgriff, für Volleinspeiser ohne Anlagenzähler den AC-Ertragszähler des Wechselrichters als „PV gesamt”. Ohne Anlagenzähler ändert sich keine Zahl (#421, Raia-Jicin). Dazu nimmt GET /api/monatsdaten/{id} die PV-Erzeugung jetzt aus dem aufbereiteten Monat (wie Cockpit → Monat) statt aus der rohen Monatszeile — ein Monat, dessen Modulwerte nur eine Teilsumme ergaben, zeigte dort Eigenverbrauch, Autarkie und CO₂ als 0; diese Route liest kein Teil der Oberfläche, sie ist eine Schnittstelle.
Daten-Checker „Zählerstände – Rückgang in Home Assistant”: die Überschrift nennt den gefallenen Zählerstand, nicht mehr eine „negative Menge”. Ein Anwender las „Tag und Monat zeigen dort eine negative Menge” als Vorzeichen und hielt das Entladen seines Akkus für den gemeldeten Fehler. Die Warnung meinte den Zählerstand: Seine zwei Akku-Zähler waren in der HA-Statistik gefallen, weil die Integration sie nach jedem Neustart bei 0 begann und bis August 2026 mit der Zustandsklasse total meldete. Überschrift und Text sagen jetzt, dass ein Lade-, Entlade- oder Einspeisezähler nur nach oben läuft und ein Rückgang kein Entladen ist (#423, kingcap1).

[4.1.4] - 2026-10-09 — Verläufe rechnen wie die Kacheln, ein Rückgang der HA-Statistik wird benannt

Added

Daten-Checker „Zählerstände – Rückgang in Home Assistant”. Fällt die Summe eines Sensors in der Langzeitstatistik von Home Assistant, statt zu steigen — meist nach einer Anpassung in Home Assistant nach unten —, steht die Stunde in eedc wie im Energie-Dashboard als negative Menge in Tag, Monat und Jahr, und „Aus HA laden” schlägt für den Monat einen negativen Wert vor. Bisher sagte das niemand. Jetzt nennt der Daten-Checker Sensor, Tag, Menge und Stunde (Beispiel: sensor.netzbezug am 05.06.2025: −540,0 kWh) mit dem Weg zur Korrektur in Home Assistant, und zwar über die ganze Statistik, nicht nur die letzten 30 Tage. eedc gleicht die korrigierte Statistik nachts von selbst ab; einen schon gespeicherten Monat übernimmst du danach im Monatsabschluss neu. Lädst du einen solchen Monat mit „Aus HA laden”, nennt auch der Vergleichsdialog die Felder mit negativem Wert und den Weg.

Fixed

Komponenten → Speicher: die Vollzyklen im Verlauf rechnen wie die Kachel darüber. Das Diagramm „Vollzyklen pro Monat” und die Monatstabelle teilten die Ladung durch die Kapazität, die Kachel Vollzyklen und alle anderen Sichten die entladene Energie. Bei einem Speicher mit 10 kWh, 90 kWh Ladung und 60 kWh Entladung im Monat stand im Verlauf 9,0, in der Kachel 6,0. Jetzt zeigt der Verlauf je Monat dieselbe Rechnung, und die Monate ergeben zusammen die Kachel.
Komponenten → Speicher: die Netzladung steht im Vergleich und im Verlauf. Die Jahresbilanz (Vergleich) und der Netz-Anteil im Ladungs-Diagramm suchten die Netzladung unter einem alten Feldnamen, den eedc seit Version 3.25 nicht mehr schreibt. Sie stand deshalb als 0 da, und die ganze Ladung zählte als PV-Ladung — im Beispiel 120 kWh PV-Ladung statt 90 kWh aus PV und 30 kWh aus dem Netz. Jetzt kommt die Netzladung aus demselben Wert wie die Arbitrage-Kennzahl; ältere Monate mit dem alten Feldnamen zählen weiter mit.
Komponenten → Wärmepumpe: Verlauf und Monatstabelle zeigen die Wärme, die die Kacheln zählen. Beide lasen nur den Wärmemengenzähler der Heizung. Wer die Wärme über einen gemeinsamen Zähler für Heizung und Warmwasser erfasst, sah im Verlauf 0 kWh neben 648 kWh Wärme in der Kachel; ein Klimagerät, das seine Heizwärme über die Betriebsart-Zähler meldet, 0 statt 54 kWh. Jetzt kommen Strom, Heizung, Warmwasser und Wärme je Monat aus derselben Rechnung wie die Kacheln. Ohne eigene Warmwasser-Messung heißt die Fläche weiterhin „Wärme” und trägt die ganze Wärme des Geräts.
Cockpit → Aussicht: die erwartete Heizsaison der Wärmepumpe rechnet mit dem Strom und der Wärme der Kacheln. Die Zeile „Erwartete kommende Heizsaison” las dieselben Rohfelder wie der Wärmepumpen-Verlauf: bei getrennter Strommessung für Heizen und Warmwasser 0 kWh Strom (statt 216 kWh im Monat), bei einem gemeinsamen Wärmezähler 0 kWh Wärme (statt 648 kWh). Jetzt nimmt sie je Heizmonat die Werte, mit denen auch Komponenten → Wärmepumpe rechnet.
Komponenten → Sonstiges: ein Verbraucher zeigt im Vergleich und im Verlauf seinen Verbrauch. Der Jahresvergleich summierte den Verbrauch unter einem alten Feldnamen: Wer nur das aktuelle Feld pflegt, sah 0 kWh (im Beispiel statt 24 kWh), wer beide hat, den alten Wert (108 statt 72 kWh). Und ein Verbraucher ohne eigene Messung von PV- und Netzbezug hatte im Verlauf gar keinen Balken, obwohl die Kachel seinen Verbrauch nannte. Jetzt zählt der Vergleich wie die Kachel, und was sich nicht nach PV und Netz aufteilen lässt, steht im Verlauf als eigener Balken „nicht aufgeteilt”.
Balkonkraftwerk ohne eigenen Zähler zählt in der Monatsleiste nicht mehr doppelt. Hatten die PV-Module eines abgeschlossenen Monats gespeicherte Werte und der Monat keinen Gesamtwert, setzte die Monatsleiste in Cockpit → Monat und Cockpit → Jahr den Tagesanteil des Balkonkraftwerks noch obendrauf — im Beispiel 215,2 kWh in der Leiste gegen 161,4 kWh in Kennzahl und Tabelle, obwohl der Gesamtzähler 161,4 kWh gezählt hat. Dieser Anteil ist ein Teil des Gesamtzählers, keine zweite Messung: Das Balkonkraftwerk bekommt jetzt nur, was der Gesamtzähler über die gespeicherten Modulwerte hinaus gezählt hat, und alle Sichten nennen dieselbe Zahl; der Daten-Checker prüft solche Monate wieder. Ein Balkonkraftwerk mit eigenem Zähler behält seinen Tageswert wie bisher.

[4.1.3] - 2026-10-07 — eedc rechnet Summen wie das HA-Energie-Dashboard

Added

Wandlungsverluste werden angezeigt — nicht bewertet. Misst deine Anlage ihre Strings mit eigenen Zählern und hat sie dazu einen Anlagenzähler hinter dem Wechselrichter, zeigt eedc, wie viel die Strings zusammen mehr gezählt haben: in Cockpit → Monat und Cockpit → Jahr als Unterzeile unter „PV-Erzeugung” in der Vergleichstabelle, unter Komponenten → PV-Anlage als Zeile im Block „Verlauf” über die gesamte Historie. Beispiel: Strings 360 + 180 kWh und Balkonkraftwerk 90 kWh = 630 kWh, Anlagenzähler 594 kWh ⇒ „Wandlungsverluste 36,0 kWh (5,7 %)”, die Prozentzahl bezogen auf die Summe der String-Zähler. Ersparnis, CO₂ und Eigenverbrauch rechnen weiter mit der Summe der Strings. Ohne Anlagenzähler, bei 0 oder in Monaten, die eedc nicht aus den Zählerständen kennt, erscheint keine Zeile.

Changed

eedc nimmt je Sensor seine Messung wie das HA-Energie-Dashboard; der Anlagenzähler füllt nur Lücken; ein Zählersprung aus HA steht in Tag und Monat und wird im Daten-Checker benannt. Mit Home Assistant rechnet eedc Tag, Monat und Jahr jetzt aus den Zählerständen der HA-Langzeitstatistik über den ganzen Zeitraum, für Netz, PV, Balkonkraftwerk, Speicher und Erzeuger hinter dem Zähler. Ein String mit eigenem Zähler behält seinen Wert auch dann, wenn ihm einzelne Stunden fehlen; bisher fiel der ganze Tag dann auf den Anlagenzähler zurück und der String bekam einen kWp-Anteil. Beispiel: Anlagenzähler 21 kWh, Süd misst 12, West 6, das Balkonkraftwerk hat keinen Zähler — Süd 12, West 6, Balkonkraftwerk 3 (geschätzt). Module, die unter einem Balkonkraftwerk hängen, teilen sich dessen Messung jetzt auch am Tag nach kWp, nicht erst im Monat. Eine Obergrenze je Stunde gibt es für die Home-Assistant-Daten nicht mehr: meldet ein Sensor kurz 0 und kehrt dann zurück, bucht Home Assistant den ganzen Zählerstand als Zuwachs — eedc zeigt diesen Sprung jetzt wie das Energie-Dashboard in Tag und Monat, und der Daten-Checker nennt Sensor, Stunde und Menge mit dem Weg zur Korrektur in Home Assistant („Zählerstände – Sprung in Home Assistant”). Fehlen einem Zähler mehr als 24 Stunden, trägt der erste Tag danach die ganze Menge. Zwischen 00:05 und etwa 01:10 nennt der laufende Monat eine Stunde mehr als die Summe seiner Tage (die erste Stunde des neuen Tages). Ohne Home Assistant und für Tage, die die Statistik nicht ganz abdeckt, rechnet eedc wie bisher.
Speichern eines Monats rechnet nur noch fehlende Tage nach. Nach dem Speichern eines Monats rechnete eedc bisher jeden Tag des Monats neu — auch Tage, die Home Assistant nicht mehr im Verlauf hatte (Recorder-Aufbewahrung, Standard 10 Tage); seit 4.1.1 blieben dabei nur Tage mit Gerätewerten stehen. Jetzt rechnet eedc nur noch Tage, für die es keine Tageswerte hat, und nur solange Home Assistant sie im Verlauf hat. Ein Tag, den eedc schon hat, wird nie neu gerechnet; ein fehlender Tag außerhalb der Aufbewahrung wird nicht aus den Zählern angelegt. Der einmalige Auto-Vollbackfill beim ersten Abschluss nach einem Update entfällt — die Summen kommen aus den Zählerständen, Lücken der Tageswerte füllt Einstellungen → Daten → Energieprofil-Pflege („Lücken aus HA-LTS nachfüllen”) auf Knopfdruck. MQTT-Veröffentlichung, Community-Teilen und Aktivitätsprotokoll beim Speichern sind unverändert.
„Aus HA laden”, Statistik-Import und Monatsabschluss-Vorschläge nehmen auch für Wallbox, E-Auto und sonstige Geräte die Zählerstände. Deckt die Langzeitstatistik den Kalendermonat für alle Zähler der E-Mobilität (samt dem Sonnenanteil der Ladung) bzw. der sonstigen Geräte ab, kommen ihre Werte als Differenz der Zählerstände — wie für Netz, PV und Speicher und wie in Cockpit → Monat; sonst wie bisher aus der Statistik. Ohne Zählersprung sind es dieselben Zahlen. Einen gespeicherten Wert ersetzt der Import weiter nur mit „Vorhandene überschreiben”.
Schneller mit Home Assistant: jede Seite liest jeden Zählerstand nur einmal; ein HT/NT-Tarif in einer Abfrage. Eine Seite, die mehrere Monate abfragt, liest die Zählerstände jetzt einmal und reicht sie an alle Teile weiter (Netz und PV, E-Mobilität, Wärmepumpe, Preis). Ein Tarif mit Zeitfenstern (HT/NT) holt den Netzbezug aller Monate einer Seite, je Wochentag und Uhrstunde zusammengefasst, in einer Abfrage statt je Monat und Tarif. An einer Prüfanlage mit zwölf Jahren Statistik: Cockpit → Jahr 0,99 → 0,90 s; mit HT/NT-Tarif Cockpit → Übersicht 1,13 → 0,61 s und Cockpit → Jahr 2,53 → 1,05 s (bei v4.1.2 2,1 bzw. 3,3 s). Die Zahlen bleiben dieselben.
Dynamischer Stromtarif: der Monatspreis entsteht wie im HA-Energie-Dashboard. Hast du einen Preissensor (Tibber, aWATTar, EPEX-Endpreis), für den Home Assistant eine Langzeitstatistik führt, summiert eedc jetzt stündlich die Kosten deines Netzbezugs und den Wert des Stroms, den deine Anlage dir erspart hat — wie die Kostensensoren des Energie-Dashboards. Der gemessene Ø-Preis eines Monats ist Kosten ÷ bewertete Kilowattstunden (im Beispiel 25,00 ct bezugsgewichtet neben 29,17 ct im einfachen Mittel). Die Zahlen bleiben dieselben wie bisher aus den Stundenwerten; eedc liest je Monat nur noch zwei Stände statt aller Stunden. Das gilt ab dem Monat des Updates; frühere Monate rechnet eedc wie bisher aus den Stundenwerten. Ein abgerechneter Ø, den du im Monatsabschluss einträgst, gilt weiter vor der Messung.

Fixed

Datenquellen: der Anlagenzähler ist nicht „wirkungslos”, wenn jede PV-Quelle einen eigenen Zähler hat. Bis 4.1.2 stand an „PV-Erzeugung Zählerstand” dann „Wirkungslos … auf „keine” setzen” mit Knopf — wer ihm folgte, verlor die neue Zeile „Wandlungsverluste” und den Füller für Zeiträume, in denen ein String-Zähler keine Werte hat. Jetzt steht dort ein blauer Hinweis ohne Knopf: Der Anlagenzähler dient dem Vergleich mit den String-Zählern und füllt nur noch Lücken. Im Handbuch (Einstellungen → Datenquellen, §7.3) steht, welche Zuordnung die Wandlungsverluste sichtbar macht.
Daten-Checker „Zählerstände – Sprung in Home Assistant”: kein „Beheben”-Knopf mehr. Er führte zu den eedc-Datenquellen, dort gibt es aber nichts zu ändern — die Korrektur liegt in Home Assistant (Entwicklerwerkzeuge → Statistik). Der Weg steht im Text der Meldung.
Dienstwagen im Monat ohne Abschluss: Cockpit → Monat zieht die dienstlichen Ladekosten ab. Im laufenden Monat zog der Jahresverlauf die Kosten für den Strom des Dienstwagens schon ab, Cockpit → Monat noch nicht — im Beispiel 12,24 € gegen 10,44 € Netto-Ertrag. Jetzt nennt Cockpit → Monat den Posten „Dienstliche Ladekosten” auch vor dem Abschluss (3,0 kWh PV × 30 ct + 3,0 kWh Netz × 30 ct = 1,80 €) und denselben Netto-Ertrag wie der Jahresverlauf.
Wallbox-Ladung ohne Monatsabschluss: der Sonnenanteil stimmt. Mit Home Assistant stand im laufenden Monat und in einem vergangenen Monat ohne Abschluss die ganze Ladung der Wallbox als Netzstrom da (im Beispiel 9,0 kWh Netz, 0 kWh Sonne), obwohl das Auto mittags ohne Netzbezug lud — nach dem Abschluss stand dieselbe Ladung zu 100 % als Sonne. eedc rechnet den Sonnenanteil jetzt Stunde für Stunde mit (wie viel der Ladung nicht aus dem Netz kam) und nennt ihn vor und nach dem Abschluss gleich — in Cockpit → Monat, Cockpit → Jahr und im Jahresverlauf, und für abgeschlossene Monate in allen Sichten mit derselben Zahl. Der Anteil gilt ab dem Monat des Updates; frühere Monate bleiben bei der bisherigen Rechnung.
Wärmepumpe im Monat ohne Abschluss: Heizwärme, Strom je Betriebsart und Kälte stehen da. Mit Home Assistant fehlten im laufenden Monat und in einem vergangenen Monat ohne Abschluss Strom und Wärme der Wärmepumpe im Jahresverlauf und in den Monatswerten, und Cockpit → Monat zeigte bei einem Klimagerät mit eigenen Zählern je Betriebsart zu wenig Heizwärme und weder den Strom je Betriebsart noch die Kälte (im Beispiel nach drei Tagen 54,0 statt 59,4 kWh Heizwärme; Heizstrom 1,8 und Kühlstrom 3,6 kWh, Kälte 10,8 kWh fehlten; im Juni vor dem Abschluss fehlten alle Funktionswerte). Jetzt kommen diese Werte aus den Zählerständen und sind dieselben wie nach dem Abschluss (Juni: Heizwärme 594, Warmwasser-Wärme 108, Heizstrom 180, Warmwasserstrom 36, Strom je Betriebsart 18 und 36, Kälte 108 kWh). Mit zugeordnetem Betriebsmodus teilt eedc den Strom Stunde für Stunde nach der Betriebsart auf — so lange, wie das Gerät in der Stunde geheizt, Warmwasser bereitet oder gekühlt hat; die Wärme teilt der Betriebsmodus nicht. Der Monatsabschluss speichert dieselbe Aufteilung, nach dem Abschluss stehen dieselben Zahlen da wie vorher. Das gilt ab dem Monat des Updates, frühestens ab dem Zeitpunkt, ab dem eedc den Betriebsmodus mitschreibt; frühere Monate rechnet eedc nicht neu. Ohne Home Assistant und für Monate, die die Statistik nicht ganz abdeckt, ändert sich nichts.
Wärmepumpe ohne Betrieb: 0 statt „kein Stromverbrauch erfasst”. Zeigten Strom- und Wärmezähler einer Wärmepumpe im Monat beide 0, nannten Cockpit → Monat, Cockpit → Jahr, Cockpit → Tag, die Community-Meldung und der Jahresbericht keinen Wert, die Arbeitszahl stand mit „kein Stromverbrauch erfasst” da und die Ergebnis-Leiter führte die WP-Ersparnis als fehlend. Jetzt steht 0 kWh da, die Arbeitszahl zeigt „—” mit „kein Heizbetrieb in diesem Zeitraum” (eine Brauchwasser-Wärmepumpe: „keine Warmwasserbereitung in diesem Zeitraum”), die Ersparnis ist 0,00 € und fehlt nicht mehr. Ist der Stromzähler nicht zugeordnet oder liefert er nichts, bleibt es bei „kein Stromverbrauch erfasst”; zeigt der Stromzähler 0 und fehlt der Wärmemengenzähler, steht dort „kein Wärmemengenzähler zugeordnet”. Misst ein gemeinsamer Wärmemengenzähler Heizung und Warmwasser und zeigt der getrennt gemessene Heizstrom im Monat 0 (Sommer), steht bei der Arbeitszahl Heizen in Cockpit → Monat und → Jahr ebenso „kein Heizbetrieb in diesem Zeitraum“ — nicht „Wärme nicht je Funktion gemessen“ und nicht „kein Stromverbrauch erfasst“.
E-Mobilität und Sonstiges im Monat ohne Abschluss. Mit Home Assistant fehlten im laufenden Monat und in einem vergangenen Monat ohne Abschluss die Ladung von Wallbox und E-Auto, die dienstliche Ladung, die sonstigen Verbraucher und der Strom eines Erzeugers wie BHKW im Jahresverlauf und in den Monatswerten; Cockpit → Monat zeigte Sonstiges gar nicht, und Eigenverbrauch und Autarkie rechneten ohne das BHKW (im Beispiel 43,2 statt 61,2 kWh Eigenverbrauch nach drei Tagen). Jetzt kommen diese Werte aus den Zählerständen und sind dieselben wie nach dem Abschluss; Wallbox-Regel, Aufteilung auf mehrere Autos und Dienstwagen gelten wie dort. Ohne Home Assistant und für Monate, die die Statistik nicht ganz abdeckt, ändert sich nichts.
Statistik-Import: der PV-Gesamtzähler wird gespeichert wie mit „Aus HA laden”. Der Import aus der Home-Assistant-Statistik schreibt den Gesamtzähler deiner Anlage jetzt als Gesamtwert in den Monat; verteilt wird erst beim Lesen, und dabei bekommt auch ein Balkonkraftwerk ohne eigenen Zähler seinen Anteil. Bisher verteilte der Import den Zähler selbst, nur auf die Module: im Beispiel Gesamtzähler 630 kWh, Süd 360 kWh gemessen, West und Balkonkraftwerk ohne Zähler bekam West 270 kWh und das Balkonkraftwerk 0 — jetzt West 225, Balkonkraftwerk 45 kWh. Der Daten-Checker führt solche Monate wieder, und die Import-Vorschau meldet danach „stimmt überein”. Früher importierte Monate korrigiert ein erneuter Import mit „Vorhandene überschreiben”: eedc entfernt dabei die Modulwerte, die der Import damals verteilt hat; eigene Messwerte und Handeingaben bleiben. Hat ein Monat noch keine Zählerzeile und importierst du weder Einspeisung noch Netzbezug, speichert eedc den Gesamtzähler nicht und nennt den Monat in der Meldung nach dem Import.
Community: ein Monat ohne Netzbezug oder ohne Einspeisung wird als 0 kWh geteilt. Bisher ging eine gemessene 0 als „kein Wert” an den Community-Server, während dieselbe Meldung die Autarkie von 100 % aus genau dieser 0 nannte. Jetzt steht die 0 in der Meldung, und der Monatsvergleich der Community zählt die Anlage mit. Die Änderung wirkt beim nächsten Teilen.
Komponenten → E-Auto: die Monatstabelle eines Dienstwagens nennt die Lademenge. Die Kachel darüber zeigte sie schon, in der Tabelle fehlte sie. Jetzt steht in beiden dieselbe Zahl; eine aus dem Fahrverbrauch geschätzte Menge ist gekennzeichnet. Die Ersparnis bleibt bei einem Dienstwagen 0.
Eigenverbrauch mit Speicher: der Tag rechnet wie der Monat. Cockpit → Tag zählte bisher alles, was nicht eingespeist wurde, als Eigenverbrauch — auch die Speicherladung, die erst später verbraucht wird. An einem Ladetag lag der Eigenverbrauch so über dem Verbrauch des Hauses (im Beispiel 12,0 kWh bei 11,0 kWh Gesamtverbrauch), und die Tage passten nicht zum Monat (36 gegen 33 kWh). Jetzt gilt überall dieselbe Rechnung wie im Monat, im Jahr, in Live und im Energie-Dashboard von Home Assistant: direkt verbrauchter PV-Strom plus das, was der Speicher ins Haus abgibt (11,0 kWh, drei Tage zusammen 33 kWh). Die Kachel heißt wieder „Eigenverbrauch” statt „PV-Eigenverbrauch · inkl. Speicherladung”, und der Verlauf in Cockpit → Monat stapelt die Erzeugung als Direktverbrauch, Speicherladung und Einspeisung. Mit dem Eigenverbrauch des Tages ändern sich EV-Quote, CO₂-Einsparung und Eigenverbrauchs-Ersparnis des Tages, der Monat ohne Abschluss sowie der Eigenverbrauch der Tagesprognose. Ohne Speicher ändert sich nichts. Eine kleine Abweichung bleibt an Tagen, an denen der Speicher aus dem Netz lädt: Die Summe der Tage kann dann über dem Monat liegen, weil der Monat die Netzladung mit dem Sonnenüberschuss anderer Tage verrechnet.
Dienstwagen: der Netto-Ertrag ist überall derselbe. Was ein Dienstwagen zu Hause lädt, kostet die Anlage etwas: den Netzstrom zum Wallbox-Tarif und den Sonnenstrom zum Netzbezugspreis. Cockpit → Übersicht, der HA-Sensor und die Aussichten zogen diese Kosten schon ab, Cockpit → Monat, Cockpit → Jahr, Auswertungen → Tabelle und der Jahresbericht nicht. Dieselbe Anlage hatte so im selben Monat zwei Netto-Erträge (im Beispiel 104,40 € und 122,40 €, Monatsergebnis 30,60 € statt 48,60 €). Jetzt nennen alle Sichten die niedrigere Zahl, und die Kosten stehen als eigene Zeile „Dienstliche Ladekosten” im T-Konto, in der Finanztabelle der Komponenten und im Monats- und Jahresbericht. Die Erstattung deines Arbeitgebers pflegst du wie bisher als sonstigen Ertrag. Ohne Dienstwagen ändert sich nichts.
Einstellungen: die Suche findet den Monatsbericht. Wer in Einstellungen nach „Monatsbericht“ suchte, bekam keinen Treffer, obwohl die Kachel Berichte & Dokumente ihn anbietet. Jetzt findet die Suche die Kachel über jedes ihrer Dokumente — Jahresbericht, Monatsbericht, Finanzbericht, Anlagendokumentation und Infothek-Dossier —, und die Kachel nennt den Monatsbericht in ihrer Liste mit.
Balkonkraftwerk: der Eigenverbrauch im Monatsabschluss heißt „optional, wird abgeleitet”. Der Hinweis am Feld riet „typisch 30–40 % der Erzeugung” bzw. „bei Nulleinspeisung meist die Erzeugung” einzutragen. eedc nimmt einen eingetragenen Eigenverbrauch aber nur in einem Monat ohne Erzeugung — sonst leitet es ihn aus der Bilanz am Hauszähler ab. Wer dem Rat folgte und dieselbe Entity auf Erzeugung und Eigenverbrauch legte, bekam in den Datenquellen eine Doppelzuordnungs-Warnung für ein Feld, das eedc gar nicht liest. Jetzt sagen Formular, Datenquellen-Hinweis und Hilfe: leer lassen, eedc leitet ihn ab; nur eintragen, wenn für den Monat keine Erzeugung vorliegt. An den Zahlen ändert sich nichts.
Komponenten → Balkonkraftwerk: Verlauf und Vergleich zeigen dieselben Zahlen wie die Kennzahlen darüber. Die Spalte „Erzeugung” im Verlauf stand immer auf 0, und Eigenverbrauch und Einspeisung kamen nur aus Werten, die du selbst eingetragen hattest — wer nur die Erzeugung zuordnet, sah ein leeres Diagramm, wer „Eigenverbrauch = Erzeugung” pflegte, sah 100 % Eigenverbrauch neben einer niedrigeren Quote in den Kacheln. Jetzt rechnen Diagramm, Monatstabelle und Jahresvergleich je Monat wie die Kacheln: Erzeugung gemessen, Eigenverbrauch als Anteil des Balkonkraftwerks an der Bilanz am Hauszähler, Einspeisung als Rest. Zusammen ergeben die Monate die Kennzahlen oben. Ein Monat ohne Einspeise- und Bezugszähler steht als „—” statt als 0.

[4.1.2] - 2026-10-05 — Eine Rechnung für Netto-Ertrag und Ergebnis, PV mit Balkonkraftwerk und Gesamtzähler zählt überall gleich, „Hausverbrauch” wird Gesamt- und Restverbrauch

Fixed

Netto-Ertrag in Cockpit → Monat und → Jahr zieht bei Regelbesteuerung die Umsatzsteuer auf den Eigenverbrauch ab — wie Cockpit → Übersicht, Jahresbericht und HA-Sensor schon immer. Bisher standen für denselben Monat zwei Netto-Erträge nebeneinander (im Beispiel 212,00 € im Monat gegen 206,30 € in der Übersicht). Der Netto-Ertrag enthält jetzt überall dieselben Posten: Einspeisung, Eigenverbrauch, den Rest des Balkonkraftwerks, den Erlös eines Geräts mit eigenem Vergütungssatz und die sonstigen Erträge und Ausgaben.
Der Umsatzsteuersatz auf den Eigenverbrauch kommt aus einer einzigen Rechnung. Sieben Stellen bildeten ihn bisher je für sich; sie zählten deaktivierte oder stillgelegte Komponenten mit Betriebskosten unterschiedlich mit und nahmen bei sonstigen Erzeugern verschiedene Eigenverbrauchsmengen. Betroffen sind nur regelbesteuerte Anlagen; dort kann sich der Wert in Übersicht, Monatsreihe, Jahresbericht und im HA-Sensor einmalig verschieben (in der HA-Langzeitstatistik als Sprung sichtbar). Bei Anlagen mit Regelbesteuerung und einem sonstigen Erzeuger (z. B. BHKW) kann sich der Netto-Ertrag der Übersicht ebenfalls einmalig ändern: der Umsatzsteuer-Anteil rechnet jetzt mit dem Eigenverbrauch der Monatsabschlüsse, wie alle anderen Sichten. Ein Jahr ohne Abschluss nimmt den Satz des Vorjahres; gibt es keinen, nennt eedc den Grund, statt 0 einzusetzen.
Autarkie und Eigenverbrauchsquote eines Jahres über 100 %. Hatte ein Monat Eigenverbrauch, aber keinen Netzbezugswert, teilte Cockpit → Jahr den Eigenverbrauch aller Monate durch den Gesamtverbrauch der übrigen — bis zu 198 % Autarkie (#421). Quoten eines Jahres werden jetzt über die Monate gebildet, die beide Werte haben, und nennen ihr Fenster („aus 8 von 9 Monaten”); dasselbe gilt für Vorjahr und „Ø Jahr”.
Ein Jahresergebnis ohne Stromrechnung steht nicht mehr als Zahl da. Fehlt in einem Monat der Netzbezug, zeigt das Jahr kein Ergebnis und nennt den Monat („Stromrechnung (Sep 2025) fehlt”), statt die Stromkosten still als 0 zu zählen. Fehlt ein optionaler Posten, zählt er 0 und steht im Hinweis.
Auswertungen → Tabelle und → Finanzen zeigen denselben Netto-Ertrag wie das Cockpit. In der Werte-Tabelle fehlten im Netto-Ertrag (und damit in der Netto-Bilanz) die Sonstigen Erträge und Ausgaben; Auswertungen → Finanzen rechnete sie in Kachel, Diagrammen und CSV selbst dazu. Jetzt trägt die Monatsreihe sie wie jede andere Sicht, und Finanzen zeigt sie nur noch als Bestandteil an. Die CSV von Finanzen hat dadurch eine Spalte weniger („Netto nach Sonderkosten” war dieselbe Zahl wie „Netto-Ertrag”); „Sonderkosten” heißt dort „davon Sonderkosten”.
Betriebskosten einer Komponente zählen erst ab ihrer Anschaffung und nicht mehr nach ihrer Stilllegung — in der Monatsergebnis-Kachel standen sie bisher auch in Monaten davor bzw. danach.
Der Vorjahresvergleich im Monat rechnet mit den Stromkosten des Vorjahres, auch wenn der Netzbezug damals 0 kWh war (der Grundpreis fehlte), und mit dem Umsatzsteuersatz seines eigenen Jahres.
Die Zeile „Abgabe an Dritte” stand im Jahres-Bilanzblock doppelt.
T-Konto und Komponenten-Finanztabelle mit Balkonkraftwerk führen auf das Monatsergebnis. In einem Monat, in dem mehr eingespeist als erzeugt wurde, buchten beide eine Balkonkraftwerk-Ersparnis, obwohl die Anlage keinen Eigenverbrauch hatte; in einem Monat ohne Erzeugungswert des Balkonkraftwerks schnitten sie dessen Ersparnis aus der Eigenverbrauchs-Ersparnis heraus, in der sie gar nicht steckte. Die Balkonkraftwerk-Zeile trägt jetzt nur den Anteil, der im Eigenverbrauch steckt; ein Monat ohne Erzeugungswert hat eine eigene Zeile.
Cockpit → Monat bewertet den Eigenverbrauch bei dynamischem Tarif mit dem Preis der Stunden, in denen er Bezug ersetzt hat — wie Übersicht, Monatsreihe und Jahresbericht schon seit September. Bisher nahm die Monatskachel den Ø des tatsächlichen Bezugs (meist der teurere Abend) und nannte dadurch eine zu hohe Ersparnis (im Beispiel 160 € statt 40 €); das gilt jetzt auch für den Vorjahresmonat und die Balkonkraftwerk-Zeile im T-Konto, und die Herleitung nennt den Preis. Der Vorjahresmonat rechnet außerdem seine Stromrechnung mit demselben Preis wie der Monat selbst — bei gemessenen Stundenpreisen fehlte ihm diese Stufe, und der Vergleich zum Vorjahr stand auf einer anderen Stromrechnung als derselbe Monat direkt.
Mit mehreren Wärmepumpen nennen Kachel und T-Konto dieselbe Ersparnis. Die Kachel rechnete alle Geräte mit den Angaben der ersten Wärmepumpe (etwa dem Preis der alten Heizung), das T-Konto je Gerät mit seinen eigenen; jetzt ist die Kachel die Summe der Gerätezeilen, auch im Vorjahresmonat und im Jahr.
Die Komponenten-Finanztabelle zieht die Netzladung des Speichers nicht mehr doppelt ab. Sie stand als Aufwand in der Speicher-Zeile und steckte zugleich in der Stromrechnung; jetzt steht sie an der Speicher-Zeile nur als Hinweis, und die Zeile „Monatsergebnis” geht wieder als Summe minus Stromrechnung auf.
Cockpit → Monat und Jahr zählten die V2H-Entladung nicht zum Eigenverbrauch. Was ein E-Auto ins Haus zurückspeist, fehlte dort in Eigenverbrauch, Autarkie, Eigenverbrauchs-Ersparnis und Ergebnis — Übersicht, Jahresbericht und HA-Sensor zählten es längst. Die Monatssicht rechnet ihre Bilanz jetzt über dieselbe Funktion wie alle anderen Sichten.
Cockpit → Monat nimmt die PV-Erzeugung der Strings auch vor dem Monatsabschluss. Wer seinen Strings eigene Zähler und dazu einen Anlagen-PV-Zähler zugeordnet hatte, sah im laufenden (oder noch nicht abgeschlossenen) Monat den Anlagenzähler, nach dem Abschluss die Summe der Strings — die Zahl und mit ihr Eigenverbrauch und Autarkie sprangen beim Abschluss. Jetzt gewinnt auch vor dem Abschluss jede PV-Quelle (String oder Balkonkraftwerk) mit eigenem Wert; der Anlagenzähler steht für die ganze Anlage und füllt nur, was die gemessenen Quellen nicht erklären. Im laufenden Monat gilt das erst jetzt: Sobald für den Monat Tageswerte vorlagen — im Betrieb also immer —, behandelte Cockpit → Monat den Anlagenzähler aus Home Assistant wie einen Teilwert und ersetzte ihn durch den Zähler einer einzelnen Quelle. Mit Anlagenzähler, Balkonkraftwerk-Zähler und Strings ohne eigenen Zähler zeigte der laufende Monat nach drei Tagen 9 statt 63 kWh, Eigenverbrauch und Autarkie 0; mit einem String mit eigenem Zähler 36 statt 63 kWh (seit 4.0.45). Jetzt zählt der Anlagenzähler, weil er den Monat bis jetzt misst. Ein gespeicherter Zwischenstand des laufenden Monats und ein Wert aus einem Geräte-Connector bleiben dort ersetzbar wie bisher; Speicher, Wärmepumpe, Wallbox und Netzwerte ändern sich nicht. Entsteht der Sensor des Anlagenzählers in Home Assistant erst im laufenden Monat, misst seine Statistik nur ab dann — das sieht eedc ihr nicht an.
Cockpit → Tag: eine PV-Quelle mit eigenem Zähler behält ihren Tageswert, wenn die Anlage zusätzlich einen PV-Gesamtzähler hat. Seit 4.0.51 gab eedc in diesem Fall jeder Quelle nur ihren Anteil nach Leistung — ein Balkonkraftwerk mit eigenem Zähler stand mit 1,56 statt 3,0 kWh im Tag, die Strings ohne Zähler mit 11,67 und 7,78 statt 10,8 und 7,2 kWh (die Summe stimmte). Jetzt behält jede Quelle, deren Zähler den Tag misst, ihren Wert — auch wenn der Zähler nachts keine Werte schickt, und auch ein Balkonkraftwerk mit eigenen Modulen; nur die übrigen teilen den Rest nach Leistung und sind als geschätzt gekennzeichnet. Messen die Zähler zusammen mehr als der Gesamtzähler, werden sie gemeinsam auf ihn abgeglichen. Fehlen einem Zähler tagsüber Werte, springt er zurück oder setzt er sich täglich auf 0, bleibt es für diesen Tag beim Anteil. Der laufende Tag rechnet sofort so; gespeicherte Tage seit 4.0.51 ändern sich erst, wenn du sie neu berechnen lässt (Einstellungen → Daten → Energieprofil-Pflege: „Tag neu aggregieren” bzw. „Mehrere Tage neu aggregieren”).
Tageswerte ohne Home-Assistant-Stundenwerte: die PV zählt nicht mehr doppelt. Wo eedc die Leistungswerte einer Anlage über den Tag aufsummiert (ohne Stundenwerte aus Home Assistant) und daneben kWh-Zähler für die PV hat, standen beide Summen nebeneinander im Tag — der laufende Monat zeigte dann das Doppelte (im Beispiel 126 statt 63 kWh), Cockpit → Tag „PV-Anlage” 39 statt 18 kWh. Jetzt zählen nur die Zähler (seit 3.26.8). Betroffen sind Anlagen, deren Leistung live zugeordnet ist, während die Stundenwerte aus Home Assistant fehlen, oder deren Leistung aus Home Assistant kommt und deren Zähler aus MQTT. Bestehende Tage ändern sich erst durch Neuberechnen; Tage älter als 15 Tage lassen sich ohne Home Assistant so nicht neu rechnen, weil die Leistungswerte nicht länger aufbewahrt werden.
Cockpit → Monat: die Zeile „Balkonkraftwerk” nennt im laufenden Monat nur, was das Balkonkraftwerk selbst gemessen hat. Ohne eigenen Zähler stand dort sein Anteil am Gesamtzähler als eigene Erzeugung (im Beispiel 4,68 kWh nach drei Tagen) — im abgeschlossenen Monat stand an derselben Stelle nichts. Die PV-Summe ist unverändert.
Ein Balkonkraftwerk mit eigenen PV-Modulen zählt im Monat nicht mehr neben ihnen. Im laufenden Monat und in einem vergangenen Monat ohne Abschluss zählte Cockpit → Monat den Zähler des Balkonkraftwerks und die gemessenen Module darunter (im Beispiel nach drei Tagen 66,6 bzw. 72 statt 63 kWh, im Juni 666 bzw. 720 statt 630) — nach dem Abschluss stimmte es. Im abgeschlossenen Monat nannte die Zeile „Balkonkraftwerk” weiter eine eigene Erzeugung (90 kWh) neben den Modulen. Jetzt gibt das Balkonkraftwerk seine Erzeugung in jedem Monat an seine Module ab, in dem sie in Betrieb sind: Module mit eigenem Zähler behalten ihren Wert, die übrigen teilen den Rest; die Zeile „Balkonkraftwerk” bleibt leer. Auch der Jahresverlauf vor dem Abschluss führt diese Erzeugung bei den Modulen. In Monaten vor der Anschaffung der Module trägt das Balkonkraftwerk sie weiter selbst. Ein Tag zeigt das Balkonkraftwerk unverändert mit dem, was seine Module nicht selbst messen.
Fehlt einem String der Monatswert und gibt es keinen Gesamtwert, zeigt der abgeschlossene Monat die Erzeugung der übrigen Strings. Bisher fiel dann die ganze String-Summe weg: im Beispiel Süd 360 kWh gemessen, West ohne Wert, Balkonkraftwerk 90 kWh — der Monat nannte in Cockpit → Monat, Übersicht, Jahr, Auswertungen → Tabelle, Jahresbericht, HA-Sensoren und Community-Daten 90 statt 450 kWh, Eigenverbrauch und Autarkie 0, während Komponenten → PV-Strings und derselbe Monat vor dem Abschluss 450 zeigten; ohne Balkonkraftwerk stand der Monat ganz ohne PV da. Jetzt zählen die vorhandenen Werte; Cockpit → Monat und Cockpit → Jahr sagen wie bisher, dass es eine Teilsumme ist — jetzt mit dem Zusatz, dass die Zahl stimmt, wenn der String in dem Monat wirklich außer Betrieb war, und sonst seine Erzeugung fehlt —, und der Daten-Checker nennt den Monat („PV-Erzeugung unvollständig”). Die Prüfungen des Daten-Checkers und die Vorschau des Statistik-Imports rechnen weiter nur mit vollständigen Monaten.
Import-Vorschau einer Anlage nur mit Balkonkraftwerk: Ein abgeschlossener Monat stand dort als „Fehlt lokal: PV Erzeugung Gesamt” und wurde zum Import vorgeschlagen, obwohl er 90 kWh führte. Jetzt kennt die Vorschau den Wert des Balkonkraftwerks (und seinen Anteil an einem gespeicherten Gesamtwert). Ein Monat, in dem einem String der Wert fehlt und kein Gesamtwert gespeichert ist, bleibt „fehlt lokal” — der Import schließt die Lücke.
Ein Balkonkraftwerk mit eigenem Wert zählt neben einem Anlagen-PV-Wert nur noch einmal. Hat die Anlage einen PV-Wert für die ganze Anlage (etwa einen PV-Gesamtzähler aus Home Assistant) und ein Balkonkraftwerk mit eigenem Wert, verteilte ein abgeschlossener Monat den Anlagenwert ganz auf die PV-Module und zählte das Balkonkraftwerk obendrauf — im Beispiel 1045 statt 1000 kWh, Eigenverbrauch und Autarkie entsprechend zu hoch. Jetzt geht der Wert des Balkonkraftwerks zuerst vom Anlagenwert ab, nur der Rest füllt die Module ohne eigenen Wert: in Cockpit → Monat, Übersicht, Jahr, Auswertungen, Jahresbericht, HA-Sensoren und Community-Daten, beim Statistik-Import und in dessen Vorschau (sie vergleicht den Zähler jetzt mit Modulen plus Balkonkraftwerk). Ein gepflegter Anlagenwert wirkt sofort; Monate, die der Statistik-Import schon verteilt hat, zeigt die Vorschau als Konflikt, und ein erneuter Import verteilt sie neu, wenn der Zähler auf mehrere Module ohne eigenen Sensor verteilt worden war. Ein Balkonkraftwerk ohne eigenen Wert bekommt seinen Anteil, sobald der Anlagenwert gespeichert ist (nächster Punkt). Bei betroffenen Anlagen kann sich der HA-Sensor der PV-Erzeugung einmalig verschieben.
Ein Balkonkraftwerk ohne eigenen Wert zählt in Monaten mit gespeichertem PV-Gesamtwert mit. Hatte ein Monat einen gespeicherten PV-Wert für die ganze Anlage (eingetragen oder über einen Portal- oder Datei-Import übernommen) und das Balkonkraftwerk keinen eigenen Wert, fiel sein Anteil aus dem abgeschlossenen Monat heraus, sobald alle PV-Module einen eigenen Wert hatten — im Beispiel Strings 550 + 380 kWh, Gesamtwert 1000 kWh: 930 statt 1000 kWh, während Komponenten → PV-Strings, der Daten-Checker und derselbe Monat vor dem Abschluss 1000 zeigten; eine reine Balkonkraftwerk-Anlage stand in einem solchen Monat ganz ohne Erzeugung da. Jetzt bekommt das Balkonkraftwerk seinen Anteil nach Leistung (im Beispiel 70 kWh). Der Verlauf in Cockpit → Jahr und Komponenten → PV-Anlage führt ihn beim Balkonkraftwerk und kennzeichnet ihn im Tooltip als „davon geschätzt (kWp-Anteil)” (in der Tabellenansicht des Jahres als eigene Spalte); die Werte des Balkonkraftwerks selbst, etwa in Cockpit → Monat, bleiben die gemessenen. Der Anteil wirkt in Cockpit → Monat, Übersicht und Jahr, Auswertungen → Tabelle, im Jahresbericht (Monatstabelle und „String-Vergleich” nennen dieselbe Summe), in den HA-Sensoren, den Community-Daten und der Vorschau des Statistik-Imports. Eigenverbrauch, Autarkie und Ersparnis steigen um diesen Anteil. Ein im Monat erfasster Eigenverbrauch eines Balkonkraftwerks ohne eigenen Erzeugungswert zählt neben einem gespeicherten Gesamtwert nicht mehr extra — auch dann nicht, wenn die Strings den Gesamtwert schon ganz erklären: der Gesamtwert sagt dann, dass das Balkonkraftwerk nichts erzeugt hat (im Beispiel Gesamtwert 930, Strings 550 + 380, Balkonkraftwerk-Eigenverbrauch 30 kWh: Netto-Ertrag 200 → 191 €). Ein Tageswert des Balkonkraftwerks kommt neben dem Anteil nicht obendrauf. Ist die Leistung des Balkonkraftwerks nur als Modulleistung × Anzahl gepflegt, zählt sie bei der Verteilung jetzt mit (bisher 0 — in Komponenten → PV-Strings bekam es dann nichts). Fehlt zusätzlich der Wert eines Moduls, teilen sich Modul und Balkonkraftwerk den Rest: der Monat bleibt bei 1000 kWh, das Modul trägt weniger (im Beispiel 375 statt 450 kWh, sichtbar auch in Auswertungen → ROI). Ausgenommen bleibt der Statistik-Import: Er speichert den Gesamtzähler aus Home Assistant nicht, sondern verteilt ihn beim Import nur auf Module ohne eigenen Wert — dort sieht der abgeschlossene Monat weiter so aus wie bisher, im Beispiel 930 statt 1000 kWh. Der Monatsabschluss mit „Aus HA laden” speichert ihn jetzt (nächster Punkt). Bei betroffenen Anlagen kann sich der HA-Sensor der PV-Erzeugung einmalig verschieben. Der HA-Sensor „spezifischer Ertrag” rechnet jetzt über dieselben Monate wie die Kachel in Cockpit → Übersicht: Monate, in denen nur das Balkonkraftwerk erzeugt hat, zählte er bisher in der Erzeugung, aber nicht in der Laufzeit. Bei Anlagen nur mit Balkonkraftwerk verschiebt er sich deshalb einmalig (im Beispiel 143,75 → 586,73 kWh/kWp; die Kachel zeigte schon 586,7), ebenso bei Anlagen mit Modulen, wenn in einzelnen Monaten nur das Balkonkraftwerk einen Wert hat und die Module keinen — etwa vor ihrer Anschaffung oder wenn für sie nichts erfasst ist. Der Sensor zeigt dann den Wert der Kachel und kann dadurch sinken (im Beispiel 821 → 385 und 744 → 656 kWh/kWp). Fehlen in solchen Monaten nur die Werte der Module, trag sie nach — dann stimmen Sensor und Kachel wieder mit der Anlage überein.
„Aus HA laden” übernimmt den PV-Gesamtzähler der Anlage — als eigene Zeile im Formular. Seit 4.0.48 hieß es, das Formular unter Einstellungen → Monatsdaten werde mit dem PV-Gesamtzähler vorbelegt; angekommen ist er nie: eedc reichte ihn unter einem anderen Namen weiter, als das Formular sucht, und der Vergleichsdialog zeigte seinen gespeicherten Wert immer als „–”. Nach dem Speichern fehlte der Anlagenwert, und der abgeschlossene Monat zeigte weniger als derselbe Monat davor — im Beispiel Gesamtzähler 1000 kWh, Strings 550 + 380 kWh mit eigenem Sensor, Balkonkraftwerk ohne Zähler: 930 statt 1000 kWh; mit einem String ohne eigenen Sensor stand der Monat in Übersicht und Tabelle ganz ohne PV da; mit Strings ohne Sensor und einem Balkonkraftwerk-Zähler (45 kWh) bei 45 statt 1000 kWh. Jetzt kommt der Zähler an und steht in einer eigenen Zeile „PV-Gesamtzähler aus Home Assistant” — auch wenn die Module eigene Werte haben und das Formular sonst nur „PV-Erzeugung (berechnet)” zeigt. Gespeichert wird, was in der Zeile steht; ist sie beim Speichern leer, hat der Monat keinen Gesamtwert. Ein schon gespeicherter Gesamtwert ist jetzt beim Bearbeiten immer sichtbar — auch ohne „Aus HA laden” in einer Zeile „PV-Gesamtwert der Anlage”, änderbar und entfernbar. Bisher ging er unsichtbar mit, sobald die Module Werte hatten, und wirkte trotzdem (er füllt, was die Quellen mit eigenem Wert nicht erklären); entfernen ließ er sich dort nicht. Der Monat nennt danach vor und nach dem Abschluss dieselbe Zahl (im Beispiel jeweils 1000 kWh; mit eigenem Wert für jede Quelle unverändert 975). Weicht ein Gesamtwert im Formular von „PV-Erzeugung (berechnet)” ab, steht er darunter („Gesamtzähler der Anlage” aus Home Assistant, sonst „Gesamtwert der Anlage”). „Aus HA laden” übernimmt außerdem nur noch Zählerfelder — wie Statistik-Import und Monatsabschluss-Vorschläge schon bisher; ein zugeordneter Preis-Sensor (etwa der Ø Strompreis) erscheint im Vergleich nicht mehr mit seiner Monatsspanne. Schon abgeschlossene Monate ändern sich nicht von selbst — „Aus HA laden” → „Mit HA-Werten fortfahren” → Speichern trägt den Zähler nach. „Monat einfügen” schlägt den Gesamtzähler weiterhin nicht vor, der Statistik-Import speichert ihn weiterhin nicht.
Auswertungen → Tabelle: die Spalte „Spez. Ertrag” nennt mit Balkonkraftwerk denselben Wert wie das Cockpit. Sie teilte die PV-Erzeugung einschließlich Balkonkraftwerk durch die Nennleistung ohne Balkonkraftwerk und lag damit um dessen Anteil zu hoch (im Beispiel 10 kWp + 0,8 kWp Balkonkraftwerk: 100,0 statt 92,6 kWh/kWp im Monat, 1200 statt 1111 im Jahr). Jetzt zählt die Nennleistung das Balkonkraftwerk mit — wie Cockpit → Monat und die Übersicht. Die Spalte ist standardmäßig ausgeblendet.
Komponenten → PV-Strings: ein Balkonkraftwerk, dem später PV-Module zugeordnet wurden, behält seine Erzeugung in den Monaten davor. Die String-Sicht wandte die Zuordnung auf die ganze Laufzeit an: Das Balkonkraftwerk hatte in keinem Monat eine eigene Zeile, und in den Monaten vor dem Anschaffungsdatum seiner Module fehlte seine Erzeugung in der Summe (im Beispiel 930 statt 1860 kWh). Jetzt entscheidet jeder Monat selbst: Solange die Module noch nicht angeschafft sind, steht das Balkonkraftwerk mit eigener Zeile, eigenem SOLL-Anteil und eigenem spezifischen Ertrag da, und die Summe je Monat ist dieselbe wie im Cockpit. Auch Alle Jahre zählt ein solches Jahr mit, und das saisonale Mittel der Gesamtlaufzeit teilt Balkonkraftwerk und Module durch die Jahre, in denen einer von beiden erzeugt hat. Dasselbe im Jahresbericht-PDF, Abschnitt „String-Vergleich”: Dort fehlte die Erzeugung des Balkonkraftwerks aus den Monaten vor seinen Modulen ebenfalls, die Summe des Abschnitts widersprach der Monatstabelle desselben Berichts (im Beispiel 930 gegen 1860 kWh, mit Modulen ab September 11.680 gegen 12.276 kWh; im Gesamtzeitraum fehlte jedes Jahr, in dem das Balkonkraftwerk allein erzeugt hat). Jetzt zeigt der Abschnitt dieselben Zeilen wie Komponenten → PV-Strings, seine Summe ist die der Monatstabelle, und das SOLL einer Zeile zählt nur die Monate, in denen sie erzeugt — Balkonkraftwerk und Module stehen nie zugleich im Verteilungsnenner. Dieselbe Regel (erst das Datum bzw. der Aktiv-Status, dann die Zuordnung) gilt jetzt an drei weiteren Stellen: In der Tagesauflösung ändert sich dadurch nichts Sichtbares — gespeicherte Tage werden ohnehin mit den an diesem Tag vorhandenen Geräten gerechnet. Bei der grauen Energie (Auswertungen → CO₂, „klimapositiv ab”): Sind alle Module eines Balkonkraftwerks deaktiviert, zählt das Balkonkraftwerk seine Herstellungs-Last wieder selbst, statt dass sie ganz fehlt (im Beispiel 6.000 → 6.800 kg); der Zeitpunkt „klimapositiv ab” rückt entsprechend nach hinten. In der PV-Prognose mit gepflegter Wechselrichter-Grenze: Hat ein Balkonkraftwerk dieselbe Ausrichtung wie ein String und sind ihm Module mit einem Anschaffungsdatum in den nächsten Tagen zugeordnet, zählt es bis zu diesem Datum weiter mit, statt schon vorher zu fehlen (im Beispiel heute 12,0 → 13,6 kWh, morgen 10,8 → 12,2 kWh). Anlagen ohne nachträglich zugeordnete Module sind unverändert.
Jahresbericht-PDF, Abschnitt „String-Vergleich”: SOLL und spezifischer Ertrag zählen nur die Monate, in denen ein String einen Wert hat. Für SOLL, IST und Abweichung ist das dieselbe Regel wie Komponenten → PV-Strings. Bisher stand je Zeile das SOLL des ganzen Jahres (im Gesamtzeitraum aller Jahre) gegen die Erzeugung der erfassten Monate: im laufenden Jahr, im Jahr der Inbetriebnahme, bei einem Zubau oder einer Stilllegung nannte jede Zeile eine Abweichung, die nur aus fehlenden Monaten kam (im Beispiel 2026 mit sechs erfassten Monaten −52 % statt −2 %, im Gesamtzeitraum mit 30 von 36 Monaten −20 % statt −4 %). Im Anschaffungs- bzw. Stilllegungsmonat zählt das SOLL anteilig nach Tagen, wie dort. Der spezifische Ertrag im Gesamtzeitraum teilte durch alle Jahre des Berichts; jetzt ist er derselbe saisonal gewichtete Jahreswert wie die Kachel in Cockpit → Übersicht, gerechnet über die Monate des Strings — ein Sommermonat zählt mehr vom Jahr als ein Wintermonat (im Beispiel ein String mit Werten nur von Mai bis September, der im Jahr 1.000 kWh/kWp erzeugt: 1.000 statt 610 kWh/kWp; ein Balkonkraftwerk mit 20 Monaten im 36-Monats-Bericht: 1.144 statt 631). Im Einzeljahr bleibt es bei Erzeugung ÷ Nennleistung. Wird ein String über weniger Monate verglichen als der Bericht umfasst, steht „n von N Monaten” an seiner Zeile und der Grund darunter. Ein vollständig erfasstes Jahr bleibt unverändert.
Jahresbericht-PDF, Abschnitt „String-Vergleich”: dieselben Werte je String wie unter Komponenten → PV-Strings. Hat ein Balkonkraftwerk in einem Monat keinen eigenen Wert, die Anlage aber einen Gesamtwert, gab die String-Sicht dem Balkonkraftwerk einen Anteil am Rest nach kWp, der Bericht nichts davon (im Beispiel Balkonkraftwerk 68 gegen 193 kWh, ein String 1.726 gegen 1.602 kWh). Jetzt nennt der Bericht die Werte der String-Sicht und kennzeichnet einen so verteilten Wert wie dort mit „geschätzt (kWp-Anteil)”. Die übrigen Zahlen des Berichts ändert dieser Punkt nicht; dass die Monatstabelle in diesem Fall dieselbe Summe nennt, kommt aus dem Punkt zum Balkonkraftwerk ohne eigenen Wert.
Community: Ausrichtung, Neigung, Wallbox- und Balkonkraftwerk-Leistung beschreiben die Anlage, wie sie heute ist. Stillgelegte, deaktivierte und erst künftig angeschaffte Geräte zählten bisher mit — ein stillgelegter Ost-String machte aus „30°, Süd” ein „20°, gemischt”, eine ersetzte 22-kW-Wallbox stand neben der neuen 11-kW-Box mit 22 kW im Datensatz, ein ausgetauschtes Balkonkraftwerk mit der Summe aus altem und neuem Gerät (1.400 statt 800 Wp). Für den Speicher galt das schon. Beim nächsten Teilen werden die Angaben auf dem Server ersetzt.
Tag-Status, der Daten-Checker-Hinweis zu Tagen ohne Werte und die Vorschauen der Reparatur-Werkbank und von „Tag neu berechnen” lesen für einen Tag nur die Geräte, die an diesem Tag in Betrieb waren — wie die Tagesberechnung selbst. Hatten zum Beispiel später angeschaffte Module eines Balkonkraftwerks schon vorher Sensorwerte, nannten die Hinweise für die Tage davor die Module statt des Balkonkraftwerks, und beide Vorschauen zählten deren Zählerstände mit (175 statt 125 Stände). Was ein Lauf schreibt, ändert sich nicht.
Tagesprognose: Liefert die gewohnte PV-Prognose für einen Tag nichts und springt der Ersatzweg ein, zählt ein String mit Anschaffungsdatum nach diesem Tag nicht mehr mit.
Der Vorjahresvergleich in Cockpit → Monat ist jetzt derselbe Monat. Der Vorjahreswert wurde auf einem eigenen Weg gerechnet und konnte sich vom selben Monat, direkt aufgerufen, unterscheiden; jetzt liest er die Zahlen dieses Monats (Mengen dabei mit zwei Nachkommastellen wie im Monat).
Cockpit → Jahr nennt Monate ohne Monatsabschluss. Ein vergangener Monat, der nur Werte aus Home Assistant hat, zählt im Jahr weiter mit; eine Zeile über dem Vergleich sagt jetzt, welcher es ist und dass Übersicht und Jahresbericht ihn nicht mitzählen. Kann ein Monat nicht berechnet werden, fehlt er nicht mehr still, sondern wird genannt — und wie bei einer fehlenden Stromrechnung bleibt das Jahresergebnis dann leer, statt eine Summe ohne diesen Monat zu zeigen.
Der Tagesverlauf fällt wieder auf MQTT zurück, wenn Home Assistant für den Tag keine Leistungswerte mehr hat (zum Beispiel nach einer umbenannten Entity). Der Rückfall griff nie, weil Home Assistant auch für einen leeren Tag das volle Zeitraster liefert.
Der nächtliche Wetter-Nachzug ersetzt keinen vollständigen Tag mehr durch einen teilweise gelöschten. Bei einer kurzen Recorder-Aufbewahrung zählte seine Vorabprüfung die Zeitpunkte statt der Leistungswerte und erkannte eine verkürzte Kurve nie.
Eine gemessene 0 bleibt eine 0. Zeigte ein Zähler aus Home Assistant im laufenden Monat (oder in einem vergangenen Monat ohne Abschluss) keinen Zuwachs — Netzbezug in einem autarken Monat, Einspeisung bei Nulleinspeisung —, behandelte Cockpit → Monat das wie einen fehlenden Wert: Gesamtverbrauch, Autarkie, Stromrechnung und Ergebnis fehlten, und eedc riet, den längst zugeordneten Zähler zuzuordnen. Jetzt steht dort 0 kWh, im Beispiel Autarkie 100 %, Stromrechnung 0,00 € und Ergebnis 16,20 € statt „—”; auch Cockpit → Jahr hat dann sein Jahresergebnis. Das gilt für Einspeisung, Netzbezug, den PV-Gesamtzähler, Speicher, Balkonkraftwerk, Wallbox und E-Auto aus Home Assistant (Einspeisung und Netzbezug auch aus den Tageswerten ohne Home Assistant); für Wärmepumpe und einzelne Strings noch nicht. Auch ein abgeschlossener Monat zeigt bei Balkonkraftwerk, Speicher und PV-Gesamtzähler 0 statt „—“, wenn der Monatsabschluss dort 0 gespeichert hat (eine gespeicherte Zahl über 0 bleibt immer stehen). Ein nicht zugeordneter Zähler oder einer ohne Werte im Monat bleibt ohne Wert.
Wärmepumpen-Ersparnis: eine Zahl in jeder Sicht. Cockpit → Monat rechnete im laufenden Monat und in einem Monat ohne Abschluss alle Wärmepumpen mit den Angaben der ersten; die Übersicht und die Komponenten-Zeitreihe der Schnittstelle (GET /api/cockpit/uebersicht/{anlage_id}, GET /api/cockpit/komponenten-zeitreihe/{anlage_id}) taten es in jedem Monat, die Übersicht dazu mit dem heutigen Tarif und ohne den Gaspreis des Monats. Jetzt ist die Ersparnis überall die Summe der Geräte je Monat, mit den Angaben jedes Geräts und den Preisen des Monats — im Beispiel mit zwei Wärmepumpen im laufenden Monat 5,76 € statt 1,44 €, in der Übersicht 110 € statt 50 € (die Jahresrendite dort folgt). Sichtbar ist das im laufenden Monat mit mehreren Wärmepumpen, im Monat ohne Abschluss und in Monaten, deren Kühlanteil eedc aus dem Betriebsmodus nachträgt (dort zieht jetzt auch das T-Konto ihn ab, im Beispiel 124 € statt 115 €).
Verbrauchsprognose: Warmwasser und Kühlen folgen nicht mehr der Außentemperatur. eedc korrigiert den Wärmepumpen-Anteil der Prognose mit den Heizgradtagen des Tages und skalierte dabei den ganzen Wärmepumpen-Strom — ein Warmwasser-Zyklus schrumpfte an einem warmen Tag auf ein Zehntel und verdreifachte sich an einem kalten. Jetzt bleiben gemessenes Warmwasser und Kühlen fest (im Beispiel ein Tag mit 16 °C 2,7 statt 0,9 kWh Wärmepumpen-Strom, ein Tag mit 0 °C 23 statt 27 kWh), und nach einer milden Woche bleibt die Prognose bei gleichem Wetter, wie sie ist (9,0 statt 9,64 kWh). Getrennt wird nur bei Anlagen, die Warmwasser oder Kühlen je Stunde erkennen lassen (Betriebsmodus-Sensor oder getrennte Leistungssensoren); bei einer milden Lernwoche ändert sich die Prognose für alle Wärmepumpen leicht.

Changed

Monats- und Jahresergebnis zeigen ihre Rechnung mit allen Posten (#398) — Netto-Ertrag, Wärmepumpe, E-Mobilität, Stromrechnung, Betriebskosten, jeweils mit Betrag. Bisher setzte der Tooltip ein Sammelfeld ein, in dem die Posten nicht zu sehen waren.
Die Komponenten-Finanztabelle schließt mit „Monatsergebnis” bzw. „Jahresergebnis” — dieselbe Zahl wie die Kachel darüber (bisher „Ergebnis nach Stromrechnung”, ohne Betriebskosten). Bei Regelbesteuerung steht die Umsatzsteuer auf den Eigenverbrauch als Aufwand in der PV-Zeile und im T-Konto als eigene SOLL-Zeile.
„Hausverbrauch” heißt jetzt Gesamtverbrauch bzw. Restverbrauch, und jede dieser Zahlen trägt ihre Formel (#407). Das Wort stand für zwei verschiedene Zahlen: in der Live-Kachel für Eigenverbrauch + Netzbezug (jetzt Gesamtverbrauch), in Cockpit → Tag und — als „Haushalt” — im Energiefluss, im Live-Tagesverlauf, im Verbrauchsprofil und in der Monatsauswertung für den Verbrauch, den kein einzeln erfasstes Gerät erklärt (jetzt Restverbrauch = Gesamtverbrauch − separat erfasste Verbraucher). Der Tooltip in der Mitte des Energieflusses nennt die Formel; seine Tageszeile heißt „Heute gesamt (Eigenverbrauch + Netzbezug)”, weil sie den Gesamtverbrauch des Tages zeigt. Die Daten-Checker-Meldungen sagen Gesamtverbrauch. Glossar, Berechnungsreferenz und Handbücher definieren die drei Begriffe. Sensor-Namen und Schlüssel sind unverändert.
Cockpit → Jahr und das Jahres-T-Konto in Auswertungen → Finanzen rechnet das Backend (neue Route GET /api/cockpit/jahr/{anlage_id}?jahr=), statt zwölf Monatsantworten im Browser zusammenzuzählen.

Intern

Neuer Layer core/berechnungen/ergebnis.py: die Ergebnis-Leiter (Netto-Ertrag → Ergebnis vor Betriebskosten → Ergebnis) mit Herleitung und der None-Regel für Pflichtposten, die Jahresfaltung falte_zeitraum (Quoten paarweise) und die SOLL-Erfüllung. Der Umsatzsteuersatz hat einen Eingang: services/ust_satz.py. Das Antwortfeld gesamtnettoertrag_euro entfällt; Nachfolger sind ergebnis_vor_betriebskosten_euro und ergebnis_euro mit ergebnis_herleitung und fehlende_posten.
Wächter: test_ergebnis_leiter_nur_im_layer.py (Backend, baumweit: keine Netto- oder Ergebnisgröße außerhalb des Layers, und der Umsatzsteuer-Jahresanteil nur im Eingang) und npm run check:ergebnis-roh (Cockpit Monat/Jahr und Finanzen rechnen nicht mit Antwortwerten); Symmetrie Monat ↔ Jahr ↔ Übersicht ↔ Jahresbericht ↔ HA-Sensor in test_ergebnis_symmetrie_monat_jahr.py.
Begriffe-Wächter: npm run check:begriffe (kein „Hausverbrauch” in Anzeigetexten, „Haushalt” nur in drei klassifizierten Ausnahmen) und backend/tests/test_begriffe_anwendertexte.py (Daten-Checker-, MQTT- und Felddefinitions-Texte; keine Label „Haushalt”). Der Client-Spiegel lib/emobEffizienz.ts entfällt — die Jahresroute ruft eauto_effizienz_zeitraum selbst.
ADR-001 D3 („ein Jahr ist die Summe der Monate, im Client”) ist zurückgenommen: eine Aggregation im Client ist ein zweiter Code-Pfad. v4/JahrAggregat.tsx entfällt.

[4.1.1] - 2026-10-02 — Ältere Tage bleiben beim Speichern eines Monats erhalten, Verbrauchsprognose auch für morgen

Added

„Sonnenangebot” in Auswertungen → Prognose-vs-IST. Globalstrahlung (Balken) und Sonnenstunden (Linie) je Monat, neben der Mehrjahres-Performance — die Bezugsgröße für die Frage „war mein Jahr schwach, oder meine Anlage?”, ohne dass man eine Performance Ratio lesen muss. Der Jahr-Filter wirkt, Lücken bleiben als Lücken sichtbar, im Fokus gibt es die Tabelle mit CSV-Export. Wunsch aus #395.
Verbrauchsprognose für morgen als HA-/MQTT-Sensor. Neben der Verbrauchsprognose für heute gibt eedc jetzt auch den erwarteten Verbrauch von morgen aus (eedc_verbrauchsprognose_morgen_kwh) — mit derselben Rechnung: das eigene Profil des Wochentags von morgen (am Freitag also das Wochenend-Profil für Samstag) und der Wärmepumpen-Anteil mit der Temperaturvorhersage von morgen. Als Attribute reisen das Stundenprofil, der Wärmepumpen-Anteil darin und das Datum mit, für das der Wert gilt. Gedacht für die Planung über die Nacht, etwa um den Speicher zur günstigsten Stunde so zu laden, dass er bis zum Morgen reicht. Wie jeder neue Sensor startet er nach dem Update abgewählt — unter Einstellungen → Integration → MQTT-Export anhaken (Markierung „Neu”). Wunsch aus #420.

Fixed

Speichern eines Monats überschreibt ältere Tage nicht mehr — Gerätewerte und Aufteilung Heizen/Kühlen bleiben. Seit 4.0.47 rechnet jedes Speichern eines Monats alle seine Tage neu. Für Tage, die Home Assistant nicht mehr im Verlauf hat (standardmäßig älter als rund zehn Tage), bekam eedc dabei 144 Punkte ohne Leistungswert — und schrieb den Tag damit neu: die Gerätewerte je Stunde wurden leer, ebenso die Betriebsart (Heizen/Kühlen/Warmwasser); danach stand der Monat auf „nicht aufgeteilt”. Ein Gerät, das nur einen Leistungssensor und keinen kWh-Zähler hat (etwa eine Split-Klimaanlage), verlor beim Speichern auch seine Tagesmenge. Über „Tag neu aggregieren” / „Mehrere Tage neu aggregieren” in der Reparatur-Werkbank und die Knöpfe „Neu aggregieren” im Daten-Checker gingen Gerätewerte je Stunde und Betriebsart ebenso verloren — deren Rückgriff auf die Langzeitstatistik griff dabei nie. Jetzt bleibt ein Tag ohne Leistungswerte, der schon Gerätewerte trägt, stehen; die Werkbank holt die Kurve aus der HA-Langzeitstatistik, und hat auch die nichts, bleibt der Tag unverändert und die Meldung sagt warum. Ein Tag ohne Gerätewerte wird wie bisher aus den Zählerständen geschrieben. Wird ein Tag neu geschrieben, bleibt die gespeicherte Betriebsart stehen, ebenso Ladestand und Strompreis, wenn deren Sensor keine Langzeitstatistik hat; was HA noch liefert, gewinnt. Schon leer geschriebene Tage: die Gerätewerte holt „Mehrere Tage neu aggregieren” aus der Langzeitstatistik zurück; die Betriebsart nur eine eedc-Sicherung von vorher. Gemeldet in #422.
Der Daten-Checker meldet, wenn eine Aufteilung nach Betriebsart nicht gespeichert werden kann. Ergeben die gemessenen Stunden mehr Heiz-, Kühl- und Warmwasserstrom, als im Monatsabschluss für das Gerät eingetragen ist (über 0,5 kWh), oder fehlt der Monatsstrom, speichert eedc die Aufteilung nicht — bisher still, nur mit einer Log-Zeile. Jetzt steht eine Warnung mit Monat und beiden Zahlen im Daten-Checker, mit Weg zum Monatsabschluss.
Die Wetter-Monatsreihe steht auf einem Lineal. Der CSV-Import holte Sonnenstunden und Globalstrahlung immer von Open-Meteo, der Knopf im Monatsabschluss dagegen von der an der Anlage gewählten Quelle. Beide Anbieter messen Sonnenstunden sehr verschieden (für denselben Monat 380 h gegen 232 h), sodass ein Jahresvergleich über eine gemischte Reihe mehr über die Quelle aussagte als über die Sonne. Jetzt folgen alle Wege der gewählten Quelle, jeder Wert trägt seine Herkunft, der Daten-Checker meldet gemischte und fehlende Werte, und die Reparatur-Werkbank zieht eine Reihe mit Vorschau auf eine Quelle nach („Wetterreihe nachziehen”). Fehlt einem abgeschlossenen Monat ein Wetterwert, füllt eedc die Lücke nachts von selbst — ohne etwas zu überschreiben und ohne ein langjähriges Mittel einzusetzen.
Wetterwerte werden nicht mehr aus dem Vormonat vorbelegt. Im Monatsabschluss stand bei Sonnenstunden und Globalstrahlung der Wert des Vormonats als Vorschlag — und wurde beim Speichern wie eine eigene Eingabe behandelt, also gegen jede spätere Korrektur gesperrt. Ein Wetterwert eines anderen Monats ist keine Schätzung für diesen.
Der statische Rückfall auf PVGIS liefert wieder Werte. Er gab seit April für jeden Monat 0 zurück, weil ein Feldname der Schnittstelle nicht mehr passte; im laufenden Monat trug der Wetter-Knopf dadurch Nullen ein.
„1 Feld” statt „1 Felder”. Bei genau einem Element zeigten rund 65 Stellen die Mehrzahl — etwa „1 Felder noch ohne Quelle” in den Datenquellen. Zahl und Wort kommen jetzt überall aus einer gemeinsamen Regel.
Steht in einer Kachel „—”, zeigt ihr Tooltip keine ausgefüllte Rechnung mehr. Die Autarkie-Kachel zeigte „—” und darunter trotzdem eine Rechnung mit Zahlen, aus der man selbst einen Wert ableiten konnte — einen, den eedc bewusst zurückhält. Die Formel bleibt sichtbar, die Zahlen nicht. Gemeldet im Forum (T89667 #388).
Die Temperaturkorrektur der Wärmepumpe in der Verbrauchsprognose rechnet mit dem Tagesmittel. Bei gleichem Wetter bleibt das gelernte Profil jetzt, wie es ist; vorher bekam jede Stunde einen eigenen Faktor aus ihrer eigenen Temperatur, und dadurch wurden die kalten Nachtstunden zu hoch und die warmen Nachmittage zu niedrig angesetzt — auch dann, wenn der Tag genau so warm war wie die Woche, aus der das Profil stammt. Jetzt fragt die Korrektur nur noch, ob der ganze Tag kälter oder wärmer ist als diese Woche, und verteilt das gleichmäßig auf alle Stunden. Bei Anlagen mit Wärmepumpe ändern sich dadurch die Kachel „Verbrauchsprognose” in Cockpit → Live, der Sensor eedc_verbrauchsprognose_heute_kwh und die Sensoren, die auf dieser Prognose aufbauen (Überschuss-Prognose, Heizfenster).

Changed

Der Tooltip zu „Ladung PV” nennt kein Beispielgerät mehr. Welche Wallbox den PV-Anteil wie ausweist und was davon sich als Zählerstand zuordnen lässt, steht jetzt ausführlich und pflegbar in Discussions → Dein eedc (#417).
Doku: warum eine eingebettete eedc-Karte „401: Unauthorized” zeigt. Der Grund ist ein Neustart von Browser oder Home-Assistant-App — auch wenn du dabei angemeldet bleibst —, nicht eine neue Anmeldung. Das Handbuch (Bedienung §1.5) sagt es jetzt so, der Dialog „Link / Einbetten” nennt es im Add-on-Betrieb direkt, und die Fehlerbehebung im Installationshandbuch verweist darauf. Abhilfe bleibt: einmal eedc in der Seitenleiste öffnen, dann das Dashboard neu laden. Gemeldet in #418.

Intern

Eine Kurve ohne Leistungswert überschreibt keine gespeicherten Gerätewerte: aggregate_day → hole_tagesverlauf erkennt sie über kurve_traegt_leistung (Overlays wie strompreis — der Börsenpreis-Rückfall füllt auch gepurgte Tage — zählen nicht) und steigt aus, wenn der Lauf von der Werkbank kommt (dann zuerst LTS-Rückfall) oder der Tag komponenten trägt; sonst wie bisher aus den Zählern (N-563 O1). Nicht im Prefetch-Zweig, nicht bei synthetischen Slots/MQTT-Energie ohne Leistungszuordnung. Neuer Parameter aggregate_day(…, leere_kurve_erlaubt=…); _reparatur_aggregat antwortet mit „historie” · „lts” · „zaehler” · „unveraendert:”. Proben über echte Einstiege mit Börsenpreis, Einzeltag und Bereichslauf (test_n596_gepurgte_tage_nicht_leer_schreiben.py). (N-596)
Daten-Checker _check_modus_split_nicht_gespeichert: Live-Faltung (lade_modus_split_je_monat, ein Aufruf je Anlage) gegen den gepflegten Monatsstrom mit teilmengen_passen — dieselben Bausteine wie der Schreibpfad; abgeschlossene Monate ohne gespeicherten Split. (N-597)
Neu-Aggregieren rettet je Stunde, was nur der HA-Verlauf kannte: aggregate_day liest vor dem Delete die Stundenzeilen des Tages (und Zeile 23 des Vortags) und führt _STUNDEN_FELDER_RETTEN (betriebsmodus_je_wp, soc_prozent, soc_je_speicher, strompreis_cent) nur dort zurück, wo der neue Lauf nichts liefert — die Betriebsart je Wärmepumpe, alte Zeilen vor N-382 in den Folge-Slot (slot_konvention.betriebsmodus_ziel_slot, Grenze BETRIEBSMODUS_BACKWARD_AB); gerettete Felder behalten ihre alte Herkunft. Neuer Wächter K3 (test_konformitaet_tep_felder.py): jede Spalte der Stundenzeile ist neu berechnet, gerettet oder Identität. (N-595)
Ein Faktor für den Wärmepumpen-Anteil je Tag aus Heizgradtagen (core/berechnungen/heizgradtage.py::wp_tagesfaktor, Referenz = Mittel der Tages-Heizgradtage der Lernwoche) ersetzt den Stundenfaktor wp_temperatur_faktor; Kachel, Live-Kurve, Export-Reihe und der neue Sensor rufen ihn. Proben zu Invarianz, Konvexität und Kälte. (N-593)
Die Verbrauchsprognose für heute und morgen teilt einen Rechenkern; die Temperaturen von morgen kommen aus dem Abruf, den der Prognose-Kanon ohnehin macht — kein zusätzlicher Open-Meteo-Abruf. Sensor-Paket 2. (N-591)

[4.1.0] - 2026-09-28 — Der Energiefluss ordnet sich: Gruppen statt Gedränge, Einzelwerte auf Klick, wahlweise mit Anlagenbild

Added

Der Energiefluss gruppiert, wenn der Platz nicht reicht. Bisher standen alle Erzeuger, Speicher und Verbraucher nebeneinander, bis die Beschriftungen unleserlich wurden — mit sechs PV-Strings war das schon am Laptop der Fall. Jetzt fasst eedc gleichartige Knoten zu einer gestapelten Kachel zusammen: PV-Strings nach ihrer Ausrichtung („Süd (5)”) oder, wo es die Ausrichtung nicht hergibt, nach ihrem Wechselrichter; Speicher nach Kapazität, Verbraucher nach Art. Die Kachel nennt die gemeinsame Leistung. Solange genug Platz ist, bleibt alles einzeln stehen — am Telefon greift die Gruppierung entsprechend früher. Die Karte wird dabei nie höher, und die Schrift bleibt lesbar (mindestens 12 px). Danke @Safi105 für den Anstoß samt Bild (#348).
Ein Klick auf eine Gruppenkachel öffnet die Einzelwerte. Als Liste mit einem Balken je Gerät: aktuelle Leistung, Anteil an der Gruppe und „heute X kWh” in jeder Zeile. Die Liste schließt mit Klick daneben, mit „Schließen” oder mit Esc.
Die Erzeugerreihe trägt ihre Gesamtleistung. Über den Erzeugern steht ein feiner Rahmen mit der Beschriftung „Gesamtleistung” und der Summe — sichtbar, sobald mehr als eine Erzeuger-Kachel da ist. Wunsch aus dem Tester-Sammelthread (#341).
Neue Hintergrund-Variante „Haus”. Unter Cockpit → Live lässt sich der Energiefluss jetzt vor ein Anlagenbild legen — Haus mit Photovoltaik, Speicher, Wallbox und Auto, mit passendem Tag- und Nachtbild, das dem hellen bzw. dunklen Modus folgt. Die Verteilung der Kacheln ist dieselbe wie in der technischen Ansicht. Die Bilder sind KI-erzeugte Beispielbilder und zeigen nicht deine Anlage; die bisherigen Varianten (technisch, schlicht) bleiben unverändert.

Changed

Ein Auto an der Wallbox steckt jetzt in der Wallbox-Kachel statt daneben zu stehen — mit Ladezustand und Richtung. Das war der häufigste Grund, warum die Verbraucherreihe überlief; eine eigene Auto-Kachel gibt es nur noch für Autos ohne Wallbox.

Fixed

Ein bidirektionales Auto hinter einer Wallbox zählt in der Live-Bilanz nur noch einmal. Wer ein V2H-fähiges Auto an einer erfassten Wallbox lädt, sah dessen Leistung doppelt: einmal als Wallbox-Ladung, einmal als Batterie-Ladung — der Eigenverbrauchs-Anteil sank dadurch im Messbeispiel auf 30 % statt 100 %. Jetzt bucht die Wallbox die Richtung (laden wie entladen), und die Batterie-Rolle trägt nur noch eine tatsächlich gemessene Entladung. Betroffen war nur die Live-Ansicht, keine gespeicherten Werte. (N-575)
Der gesamte Stromverbrauch einer Wärmepumpe friert nicht mehr ein. Bei getrennter Strommessung rechnet der Monatsabschluss den Gesamtverbrauch selbst (Heizen + Warmwasser) — bisher aber nur beim ersten Speichern eines Monats. Wurde eine der beiden Achsen später korrigiert, blieb der alte Gesamtwert unsichtbar stehen, und der Daten-Checker warnte über einen Wert, den man im Formular weder sehen noch ändern konnte. Jetzt rechnet eedc die Summe bei jedem Speichern neu. Trägt ein Monat einen eigenen Gesamtwert — von Hand gepflegt oder von einem zugeordneten Gesamtzähler —, zeigt das Formular das Feld Stromverbrauch an; leeren und speichern stellt die Summe wieder her. Die beiden bestehenden Checker-Hinweise nennen diesen Handgriff jetzt mit. Danke @rapahl für die Bilder (#416). (N-578)
„Verbindung testen” beim MQTT-Import meldet kein falsches „Not authorized” mehr. Bei ausgeschaltetem Import schickte der Knopf den Passwort-Platzhalter als echtes Passwort an den Broker — das gespeicherte Passwort war die ganze Zeit in Ordnung. Jetzt löst der Test das Passwort über dieselbe Kaskade auf, mit der sich der Import beim Start verbindet (Web-Einstellungen, sonst Add-on-Konfiguration), und prüft damit genau das, was später läuft. Im selben Zug behoben: Steht das Broker-Passwort nur in der Add-on-Konfiguration, lief der Import nach dem Speichern des Broker-Blocks bis zum nächsten Neustart ohne Passwort. Das Passwort aus der Add-on-Konfiguration wird dabei weiterhin nicht in die Datenbank kopiert. (#415, N-577)
Ein geleertes Prognose-Feld bleibt geleert. PV-Ladeanteil und Benzinpreis am E-Auto sowie der PV-Anteil an der Wärmepumpe standen im Formular mit ihrem Standardwert vorbelegt — jedes Speichern schrieb ihn als gepflegten Wert zurück, auch nachdem man das Feld geleert hatte. Der mit v4.0.52 freigeschaltete Weg zum gemessenen Anteil hielt damit nur bis zum nächsten Speichern. Die Felder starten jetzt leer, und Platzhalter und Hinweis nennen, was der leere Zustand bewirkt. (N-572)
Die Kategorie einer Komponente unter „Sonstiges” wird nicht mehr stillschweigend auf „Erzeuger” gesetzt. Beim Bearbeiten eines Bestandsgeräts ohne gepflegte Kategorie machte die Vorauswahl aus einer datengetriebenen Einschätzung beim nächsten Speichern eine feste Angabe — ein Verbraucher konnte so in die Erzeugungs-Summe kippen. Erste Option ist jetzt „Automatisch (nach den Monatswerten)”, und sie bleibt bestehen. (N-573)

Intern

Das Layout des Energieflusses liegt in einem eigenen, testbaren Modul (energieFlussLayout.ts); die Überlappungsfreiheit ist ein einziger Entscheider und zugleich der Wächter darüber. Die Live-Knoten tragen ihre Gruppierungs-Merkmale (Typ, Kategorie, Ausrichtung, Träger, Kapazität, Fahrzeuge) aus dem Backend.
Die Herkunft eines Werts unterscheidet jetzt die vom Formular gerechnete Summe von einer eigenen Angabe (summe_achsen); die Laderoute des Monatsformulars liefert die Herkunftsmarken mit.
Das lokale Doku-Gate baut kalt — der warme Astro-Store lieferte Exit 0 mit veraltetem dist. (N-574)

[4.0.52] - 2026-09-27 — Leere Eingabefelder legen keine Auswertung mehr lahm, Diagramme mit klarem Kontrast im Dunkelmodus

Fixed

Ein geleertes Zahlenfeld an einer Komponente bricht keine Auswertung mehr ab. Wer an einem E-Auto ein Prognose-Feld leerte — etwa den PV-Ladeanteil, um ab sofort mit dem gemessenen Anteil zu rechnen —, bekam in Auswertungen → ROI nur noch eine Fehlermeldung für die ganze Anlage; dasselbe konnte ein geleerter Speicher-Wirkungsgrad in Cockpit → Aussicht und Komponenten → Speicher auslösen. Jetzt gilt ein geleertes Feld überall als „nicht gepflegt”: Es greift der gemessene Wert, die nächste Stufe der Kaskade oder der Standard — eine eingetragene 0 bleibt dagegen eine 0. Ein neuer Wächter prüft das für jedes Parameterfeld aller Komponententypen, auch künftige. (N-571; betroffen seit v4.0.35)
Die Zählerstand-Linie ist wieder zu sehen. Der Verlauf eines Verbrauchszählers (z. B. Wasser) in Cockpit → Tag/Monat/Jahr zeichnete eine graue Linie, die im Dunkelmodus gegen das Gitter unterging — das Gitter war dort sogar heller als die Linie. Die Linie trägt jetzt ein kräftiges Wasserblau, und das Diagramm-Gitter nimmt sich in allen Diagrammen im Dunkelmodus zurück, statt vor den Daten zu stehen. Danke MartyBr für den Screenshot. (N-570)

Intern

Neuer Chart-Wächter check:charts R4: kein Diagramm-Gitter mehr im hellen Recharts-Default; neuer Backend-Wächter gegen rohe Parameter-Leser (Registry-getrieben, prüft auch null aus Altbeständen).

[4.0.51] - 2026-09-27 — Zählerlücken rechnen wie Home Assistant, jedes E-Auto trägt seine eigene Heimladung, die Prognose ist verfeinert

Fixed

Der Verbrauch eines E-Autos zählt nicht mehr als Ladung — eine Wallbox mit 0 kWh zeigt 0. Am E-Auto gibt es zwei Mengen: die Heimladung (was zu Hause ins Auto geladen wird, gemessen an der Wallbox oder am Auto als „Heim: PV/Netz”) und den Fahrverbrauch (das Feld „Verbrauch”, woraus eedc die kWh/100 km rechnet). eedc hat den Fahrverbrauch bisher als Heimladung eingesetzt, sobald keine Ladung eingetragen war — auch dann, wenn die Wallbox einen Sensor hat und im Monat wirklich nichts geladen hat. Gemeldet mit 1.364 kWh „Ladung” für einen Monat, in dem die Wallbox stillstand. Jetzt gilt: Der Fahrverbrauch springt nur noch ein, wenn über die Heimladung gar nichts bekannt ist — kein Wert (auch keine 0) und, im laufenden Monat, keine zugeordnete Quelle. Dann ist er eine ausdrücklich gekennzeichnete Schätzung. Dasselbe gilt am Tag und in der Stunde; dort zählt neben einer Wallbox mit Zähler der Verbrauch des Autos in keiner Stunde mehr als Ladung, und „Heim: PV” + „Heim: Netz” am Auto gehen jetzt auch am Tag in dessen Ladung ein. Welche Zahlen sich ändern: Monate, in denen die Wallbox 0 kWh trägt und am Auto ein Verbrauch erfasst ist (Heimladung jetzt 0 statt des Verbrauchs, die Ersparnis vs. Verbrenner steigt entsprechend). Zeiträume (Cockpit → Übersicht, Wallbox-Hub, Jahresbericht) sind jetzt die Summe der Monate statt einer Poolung über den ganzen Zeitraum — wo sich Monate mit und ohne Wallbox-Messung mischen, verschieben sich die Summen. An die Community geht für ein E-Auto ohne eigene Lademessung keine geschätzte Ladung mehr (dort gilt sie als Messwert); in eedc selbst bleibt die Schätzung stehen.
Die Startroutine bucht den Fahrverbrauch nicht mehr um. Seit dem 01.05.2026 benannte eedc bei jedem Start das Feld „Verbrauch” am E-Auto in „Ladung” um und löschte den Verbrauch — die kWh/100 km verloren ihren Messwert. Das passiert nicht mehr, und Umbuchungen seit dem 09.05.2026 werden beim ersten Start einmalig zurückbenannt (das Startprotokoll nennt jede Zeile). Umbuchungen vom 01.05. bis 09.05. sind von echten alten Ladungen nicht zu unterscheiden und bleiben stehen.
Der Monatsabschluss schlägt bei der Heimladung auch 0 vor. Hat die Wallbox (bzw. „Heim: Netz” am Auto) laut HA-Statistik oder MQTT im Monat nichts geladen, steht jetzt „0 — kein Zuwachs” als Vorschlag da, statt das Feld leer zu lassen. Fehlen die Daten, bleibt es leer. Bei allen anderen Feldern — auch „Ladung PV” — bleibt es wie bisher. „Aus HA laden” lässt eine gespeicherte 0 bei der Heimladung stehen (mit „überschreiben” nicht).
HA-Sensor „Verbrauch” (kWh/100 km) am E-Auto rechnet wie die App. Je Monat zählt der gemessene Fahrverbrauch, sonst die Ladung (Heim + Extern); über den Zeitraum die Summe der Monatswerte geteilt durch die Kilometer. Das neue Attribut quelle sagt, ob der Wert gemessen oder über die Ladung angenähert ist. Bisher war der Sensor meist leer (der Verbrauch wurde beim Start umgebucht) — er erscheint jetzt neu, ohne Sprung in der Langzeitstatistik.
E-Auto-Hub und T-Konto ziehen die externen Ladekosten auch dann ab, wenn die Heimladung von der Wallbox kommt. Bisher fiel das am Auto erfasste Laden unterwegs in diesem Fall weg — „Extern” stand auf 0, und die Ersparnis gegenüber dem Verbrenner war um genau diese Kosten zu hoch. Wer externe Ladung pflegt, sieht die Ersparnis entsprechend sinken; „Ladung gesamt” im Hub zählt sie mit.
Die HA-Sensoren zur E-Auto-Ersparnis ziehen die externen Ladekosten jetzt ebenfalls ab — nach derselben Regel wie der E-Auto-Hub, sodass Home Assistant und App dieselbe Zahl zeigen. Bisher blieb das Laden unterwegs in Home Assistant unberücksichtigt. ⚠ Wer externe Ladung pflegt, sieht e_auto_ersparnis_vs_benzin_euro und die daran hängenden Anlagen-Sensoren jahres_ersparnis_euro, roi_prozent und amortisation_jahre einmalig springen: die Ersparnis und der ROI werden kleiner, die Amortisation länger — um genau die externen Ladekosten, die vorher fehlten. Wer keine externe Ladung erfasst, merkt nichts (als Probe belegt). Die Langzeitstatistik in Home Assistant bekommt an dieser Stelle einen einmaligen Knick, weil sie nicht rückwirkend neu gerechnet wird; deine Daten ändern sich nicht.
Der Rechenweg im T-Konto steht in deutscher Schreibweise — „1.500 km × 7,5 L/100 km × 1,65 €” statt „1500 km × 7.5 L/100km × 1.65 €”, ebenso bei Balkonkraftwerk, Speicher, Wallbox und Wärmepumpe.
Auch die Aussichten ziehen die externen Ladekosten ab. Die bisherige E-Auto-Ersparnis im Amortisations-Fortschritt (Aussichten → Finanzen, Auswertungen → ROI) rechnete das Laden unterwegs als kostenlos und lag um genau diese Kosten über Hub und HA-Sensor. Jetzt nennen alle drei dieselbe Zahl; wer externe Ladung pflegt, sieht den Fortschritt entsprechend kleiner. Ohne externe Ladung ändert sich nichts.
Die Rechenwege der HA-Sensoren stehen in deutscher Schreibweise — das Attribut berechnung (auch unter Einstellungen → HA-Export zu sehen) schreibt „(1.387,50 ÷ 12) × 12” statt „(1387.50 ÷ 12) × 12”. Die Sensorwerte selbst ändern sich dadurch nicht; wer den Text in einer Vorlage auswertet, muss auf Komma und Tausenderpunkt umstellen.
Das Aktivitätsprotokoll nennt wieder jede Datenquellen-Zuordnung. Seit die Datenquellen-Fläche das frühere Sensor-Mapping abgelöst hat, blieb der Filter in Einstellungen → Protokolle leer. Jetzt steht jedes Zuordnen, Entfernen, Umkehren des Vorzeichens und jede Übernahme der Energie-Dashboard-Vorschläge dort — mit Anlage, Feld und alter → neuer Quelle. Der Filter heißt jetzt „Datenquellen-Zuordnung”.
Wer eine Komponente oder ein Innengerät entfernt, entfernt jetzt auch deren Datenquellen-Zuordnungen. Bisher blieben die Zuordnungen und Vorzeichen-Umkehrungen, die über die Datenquellen-Fläche gesetzt wurden, unsichtbar liegen — beim Innengerät, weil eedc sie unter einer falschen Schreibweise suchte, beim Löschen einer Komponente, weil nur die klassische Zuordnung geräumt wurde. Weil die Datenbank die Nummer der zuletzt angelegten Komponente nach dem Löschen wiederverwendet, hätte die nächste neue Komponente diese Reste geerbt.
Auch eine MQTT-Gateway-Zuordnung geht mit, wenn Komponente oder Innengerät gehen. Bisher blieb ihr Eintrag in der Gateway-Liste aktiv, und eedc abonnierte das Topic weiter; jetzt wird er gelöscht, der Gateway lädt neu, und die Protokollzeile der Löschung nennt das entfernte Topic.
Das Aktivitätsprotokoll nennt Anlegen, Löschen und wesentliche Änderungen einer Komponente (neuer Filter „Komponenten” in Einstellungen → Protokolle): mit Anlage, Typ und Bezeichnung; bei Änderungen an Typ, Aktiv, Anschaffungs- oder Stilllegungsdatum mit alt → neu.
Die CO₂-Einsparung der E-Mobilität im Jahresbericht (PDF) ist dieselbe Zahl wie im Cockpit. Der Bericht rechnete sie bisher pauschal mit 0,12 kg je Kilometer; jetzt nach derselben Regel wie Cockpit → Jahr (Vergleichs-Verbrenner des Fahrzeugs, abzüglich des Netzstroms der Ladung). Die Zahl im PDF ändert sich entsprechend, der Tooltip der eMob-Ersparnis im T-Konto nennt die tatsächlich eingesetzten Werte statt fester 7 L/100 km × 1,80 €.
„Ladung gesamt” zählt jetzt überall die externe Ladung mit, und die kWh/100 km folgen überall derselben Regel. Im Cockpit zeigte „Ladung gesamt” nur die Heimladung, im E-Auto-Hub Heim plus Extern. Jetzt ist es überall Heim + Extern (mit „davon extern … kWh”); der PV-Anteil bleibt auf die Heimladung bezogen. Im laufenden Monat erscheint die externe Ladung mit Sensor sofort, nicht erst nach dem Monatsabschluss. Die kWh/100 km eines Zeitraums sind die Summe der Monatswerte durch die Summe der Kilometer; „gemessen” steht nur, wenn jeder Monat gemessen ist. Cockpit → Jahr rechnete mit Verbrauchssensor bisher Ladung ÷ km und nannte das „gemessen” — mit einem Sensor ab Juli ergab das rund die Hälfte des echten Werts. Beim HA-Sensor „PV-Anteil Ladung” ist nur die Formelbeschreibung berichtigt (PV-Heimladung ÷ Heimladung).
Speicher-Potential: das Überschuss-Fenster lag eine Stunde zu früh. Im Speicher-Hub zeigt eedc, wie viel Strom eingespeist wurde, während der Speicher voll war — und wie viel Netzstrom nötig war, nachdem er leer lief. Bisher zählte dabei auch die Stunde mit, in der der Speicher gerade erst voll bzw. leer wurde: die Stundenzeile trägt ihren Ladestand für die folgende Stunde, ihre Energiemengen aber für die vorangegangene. Beide Fenster sitzen jetzt eine Stunde weiter hinten, wo sie hingehören. An einer Demo-Anlage gemessen: 2 % weniger Überschuss, dafür acht Voll-/Leer-Zyklen mehr — Ihre Zahlen können sich je Voll- oder Leerphase um bis zu eine Stunde Einspeisung bzw. Netzbezug verschieben. Die Kaufempfehlung („lohnt ein größerer Speicher?”) wird dadurch genauer, nicht anders begründet. ⚠ Für alte Tage gilt die alte Zuordnung weiter, und das ist Absicht: Stundenzeilen, die eedc vor dem 04.06.2026 berechnet hat, beschrifteten ihre Energiemengen selbst anders — dort wäre die neue Zuordnung falsch. eedc entscheidet das je Zeile daran, wann sie berechnet wurde. Wer einen alten Zeitraum umstellen möchte, lässt ihn neu berechnen (Reparatur-Werkbank → „Tag neu aggregieren” bzw. „Mehrere Tage neu aggregieren”); danach zählt er wie alle neuen Tage.
Dynamische Tarife: eine Kilowattstunde kostet jetzt den Preis ihrer eigenen Stunde. Wer einen Tibber-, aWATTar- oder EPEX-Tarif nutzt, sieht Kosten je Tag, den Monats-Ø-Preis, die Eigenverbrauchs-Ersparnis, den Ladepreis des Speichers und den Einspeiseerlös bei negativen Börsenpreisen — alle fünf rechneten bisher mit dem Preis der Nachbarstunde. Am Abendpeak ist das der Unterschied zwischen 20 und 45 ct. Gemessen an einer Demo-Reihe: Tageskosten +0,8 %, Eigenverbrauchs-Ersparnis −1,9 %, Monats-Ø-Preis +0,26 ct/kWh; je nach Preisverlauf sind ein bis drei Prozent je Tag üblich. ⚠ Bei einem Festpreis-Tarif ändert sich keine einzige Zahl — dort ist jede Stunde gleich teuer. ⚠ In Home Assistant ziehen bei dynamischem Tarif die Finanz-Sensoren der Anlage (eigenverbrauch_ersparnis_euro, netto_ertrag_euro und die daran hängenden jahres_ersparnis_euro, roi_prozent, amortisation_jahre) sowie eedc_speicher_strom_kosten_cent und eedc_speicher_netzladen_kosten_cent um dieselbe Größenordnung nach. ⚠ Der Einspeiseerlös nach §51 ist ein gespeicherter Tageswert: er zieht erst nach, wenn der betreffende Tag neu berechnet wird (Reparatur-Werkbank → „Tag neu aggregieren”) — und weil er beim Neuberechnen entsteht, trägt er dann ohnehin die neue Zuordnung. ⚠ Auch hier gilt die Bestandsgrenze: Kosten, Ø-Preis und Ersparnis werden für Stundenzeilen, die vor dem 04.06.2026 berechnet wurden, weiter wie bisher zugeordnet; ein Neuberechnen des Zeitraums stellt sie um.
„Größerer Speicher?”: Wirkungsgrad und nutzbare Kapazität werden genauer gemessen. eedc misst beides aus der Bewegung des Ladestands. Ein Ladestand ist dabei immer ein Stundenmittel — der Unterschied zweier solcher Mittel gehört zu je einer halben Stunde vorher und nachher, eedc stellte ihm aber die Energie einer einzigen Stunde gegenüber. Steile Ladeanfänge trieben dadurch den gemessenen Wirkungsgrad nach oben, je nach Zeitraum zwischen 82 und 88 %. An einem echten Jahr nachgemessen: der Wirkungsgrad liegt jetzt stabil bei 72–74 %, und die simulierte Anlage trifft die tatsächlich gemessene Einspeisung und den Netzbezug um ein Drittel besser. Der Simulator rechnet dadurch mit etwas höheren Verlusten, seine Empfehlung für eine größere Kapazität kann sich leicht verschieben. Für Tage, die vor dem 04.06.2026 berechnet wurden, gilt dieselbe Messung in der damaligen Stunden-Zuordnung.
Stundentabelle: der Ladestand steht jetzt bei der Stunde, zu der er gehört. In Cockpit → Tag → Stundenwerte lässt sich die Spalte „SoC” einschalten. Sie zeigte den Ladestand der Nachbarstunde, während die kW-Spalten derselben Zeile schon die richtige Stunde trugen — dieselbe Ursache wie bei den Speicher- und Preiszahlen darüber, nur in einer Tabelle statt in einer Rechnung. Die Zeile trägt jetzt beides aus demselben Zeitfenster. ⚠ Die Kachel „Ladestand” im Speicher-Block ändert sich dadurch nicht: sie zeigt weiter den zuletzt gemessenen Stand des Tages, auch am laufenden Tag. Ohne diese Trennung wäre sie um eine Stunde gealtert.
Eine Vorzeichen-Umkehr aus der Zeit vor Version 4 lässt sich wieder abschalten. Wer noch vor Version 4 ein Vorzeichen umgekehrt hat, etwa an der Speicher-Leistung, konnte den Knopf „Vorzeichen umkehren“ (⇅) in Einstellungen → Datenquellen grau schalten, und der Wert blieb trotzdem umgedreht. In der Live-Ansicht stand dann zum Beispiel eine Ladung als Entladung da, und der Hausverbrauch zeigte PV plus Batterieladung. Nach dem Einspielen eines älteren Backups stand der Knopf grau, obwohl die Umkehr wirkte. Jetzt zeigt der Knopf, was tatsächlich wirkt, und das Ausschalten hebt die Umkehr ganz auf. Die kWh-Zähler waren davon nie betroffen.
Die Prognose rechnet die Wechselrichter-Grenze nicht mehr doppelt heraus. Auf Anlagen mit mehr Modul- als Wechselrichterleistung lernt eedc seinen Korrekturfaktor aus dem Vergleich von Vorhersage und Ernte. Solange das feinere Stundenprofil noch nicht genug Tage gesammelt hat, springt ein einzelner Tagesfaktor ein — und der war auf der ungekappten Vorhersage gelernt, wurde aber auf die bereits gekappte Tagesreihe angewendet: die Abregelung ging zweimal ab, die Tagesprognose lag rund 12 % zu niedrig (an einer Messanlage mit 12-kW-Grenze 0,809 statt 0,923). eedc führt den Faktor jetzt zweimal, einmal je Bezugsgröße, und nimmt an jeder Stelle den passenden. ⚠ Anlagen ohne Abregelung merken nichts — dort sind beide Zahlen gleich. ⚠ Auf betroffenen Anlagen steigen in Home Assistant eedc_prognose_heute_kwh, die Vor-/Nachmittags-Sensoren und eedc_prognose_day_plus_1/2/3_kwh entsprechend — in einem Schritt, sobald sieben Tage mit der neuen Lern-Basis gesammelt sind, und nur, solange das Stundenprofil noch nicht greift. Die Genauigkeits-Auswertung und der Prognosen-Vergleich bleiben unverändert.
Die Prognose lernte gegen ihre eigene Korrektur — und lag dadurch an jedem Tag zu hoch. eedc vergleicht jede Nacht die gemessene Erzeugung mit dem, was es für den Tag vorhergesagt hatte, und zieht daraus seine Stundenfaktoren. Verglichen wurde dabei bisher mit der bereits korrigierten Vorhersage — also mit dem Ergebnis genau der Faktoren, die gerade gelernt werden sollten. Ein Regelkreis, der seine eigene Ausgabe als Maßstab nimmt, findet nicht das wahre Verhältnis, sondern dessen Wurzel: Wer tatsächlich 85 % der Rohprognose erntet, bekam Faktoren um 92 % — gut 8 % zu hoch, jeden Tag, in der Kachel „PV-Prognose heute”, im HA-Sensor und in der Aussicht. Ab jetzt wird gegen die rohe Wetterprognose gelernt, begrenzt auf das, was der Wechselrichter überhaupt abgeben kann. ⚠ Die Umstellung wirkt über Nächte, nicht sofort: eedc wandert Stufe für Stufe auf das wahre Verhältnis, sobald genug neue Vergleichstage aufgelaufen sind. Bis dahin behält jeder einzelne Bereich (Stunde bzw. Sonnenstand) seinen bisherigen Faktor — es geht nichts verloren und nichts springt.
Die Wechselrichter-Grenze zählt nicht mehr als Prognosefehler. Wer mehr Modulleistung als Wechselrichterleistung hat (der Normalfall bei Balkonkraftwerken und vielen Dachanlagen), kann mittags nicht mehr abgeben, als das Gerät durchlässt. Diese Differenz floss bisher in den Lernfaktor ein — die Anlage wurde für eine Abregelung bestraft, die sie nicht vermeiden kann, und die Korrektur zog die Mittagsstunden dauerhaft nach unten. Der Vergleichswert ist jetzt die gekappte Prognose.
Der Import-Wizard bietet keine ausgebauten Geräte mehr an. Wer seinen alten Speicher (oder ein altes PV-Modul, eine alte Wallbox, ein altes Auto) nach unserer Anleitung mit Stilllegungsdatum stehen lässt und das neue Gerät daneben anlegt, bekam im Zuordnungs-Schritt beide angeboten — und der vorgeschlagene Anteil teilte die importierten Mengen zwischen ihnen auf. Bei 12,8 kWh laufend neben 5,06 kWh ausgebaut schlug der Wizard 71,7 / 28,3 vor; wer den Vorschlag übernahm, schrieb gut ein Viertel der Import-Werte auf ein Gerät, das es nicht mehr gibt. Jetzt zählen nur die heute laufenden Geräte: ein Gerät, kein Zuordnungs-Schritt, 100 %.
„Aus Home Assistant übernehmen” schlägt die Batterie-Sensoren am laufenden Speicher vor. Nach einem Gerätetausch landeten Lade- und Entlade-Entität am alten Speicher (er hat die kleinere interne Nummer) — der neue blieb ohne Quelle. eedc wählt jetzt das jüngste heute laufende Gerät.
Die PVGIS-Prognose kappt wieder an der Wechselrichter-Grenze, wenn der DC-Speicher ausgebaut ist. Ein gleichstromseitig angeschlossener Speicher nimmt den Überschuss über der AC-Grenze auf — deshalb wird dann nicht gekappt. Das galt bisher auch für einen stillgelegten Speicher: das SOLL lag dauerhaft über dem, was der Wechselrichter abgeben kann, und der SOLL/IST-Vergleich zeigte ein Minus, das niemand zu verantworten hatte.
Speicher-Hub: eine Zahl für „leer”, nicht zwei. Sizing-Simulator und Speicher-Potential leiten dieselbe Entladegrenze aus den gepflegten Kapazitäten ab, rechneten sie aber verschieden (23,0 % gegen 23,3 % bei 10,24 von 12,8 kWh) — der Potential-Block nahm die gerundeten Anzeigewerte. Eine Nacht mit einem Tiefpunkt dazwischen galt damit im einen Block als aufgebraucht und im anderen nicht, mit gegenteiliger Empfehlung. Die Rundung bleibt in der Anzeige, aus der Rechnung ist sie raus.
Die Ladestands-Aufschlüsselung des Sizing-Simulators nennt keine ausgebauten Speicher mehr. Der Hinweistext darunter zählt seit 4.0.50 nur laufende Geräte — die Liste darüber zeigte weiterhin jede Nummer, die je gemessen wurde. Zwei Zeilen unter der Überschrift „1 Speicher”.
Der HA-Sensor „Speicher-Ladestand” führt keine ausgebauten Geräte mehr in seinem Attribut. eedc_speicher_soc_prozent schlüsselt unter je_speicher nach Gerät auf — und nannte dabei jede Nummer, die an diesem Tag je gemessen wurde, auch die eines längst stillgelegten Speichers. Eine Automation, die das Attribut aufschlüsselt, sah damit ein Gerät zu viel. Der Sensorwert selbst (der kapazitätsgewichtete Ladestand) war und bleibt davon unberührt.
Der Daten-Checker meldet jetzt auch auf dem heutigen Erfassungsweg, wenn zu einer Batterie-Ladung die Entladung fehlt — und sagt dazu, an welchem Gerät. Die Warnung „Batterie-Entladung nicht erfasst” gab es nur für die alten anlagenweiten Felder, und auch dort nur, solange für den Monat gar keine Gerätewerte vorlagen. Wer seine Speicherwerte am Gerät pflegt (der Weg, den eedc seit Langem vorschlägt) und dabei nur die Ladung einträgt, bekam keinen Hinweis — obwohl ohne Entladung weder der gemessene Wirkungsgrad noch die Speicher-Ersparnis entsteht und der HA-Sensor daneben keine-entladung meldet. Bei mehreren Speichern verdeckte die Summe die Lücke zusätzlich: ein vollständig gepflegtes Gerät ließ das zweite unauffällig aussehen. Jetzt steht je Monat und Gerät eine Warnung mit dem Gerätenamen und der vorhandenen Ladung. 0 bleibt ein Wert — ein Monat ohne Abgabe ist erfasst und wird nicht gemeldet.
Der Wirkungsgrad-Sensor sagt jetzt „keine Entladung erfasst”, wenn genau das der Fall ist. Bisher hieß dieser Zustand zu-wenig-monate — ein Rat, der ins Leere führt: Warten hilft nicht, wenn die Entladung des Speichers schlicht nicht erfasst wird. Das Attribut wirkungsgrad_messung kennt dafür jetzt den eigenen Wert keine-entladung (siehe Sensor-Referenz §11).
Im laufenden Monat zählt die Wallbox als Ladequelle — wie nach dem Monatsabschluss. Wer Wallbox und E-Auto erfasst, bekam in Cockpit → Monat für den noch laufenden Monat die größere der beiden Zahlen als „Ladung gesamt”. Überall sonst gilt seit der Neuordnung der E-Mobilität eine feste Regel: Hat die Wallbox eine Heimladung erfasst, ist sie die Quelle, sonst das E-Auto. Der laufende Monat war die letzte Stelle mit der alten Regel — ein Zähler am Auto, der den Fahrverbrauch misst, konnte dort eine kleinere Wallbox-Ladung übertreffen, und die Zahl änderte sich, sobald der Monat abgeschlossen war. Das gilt auch für den Monatsbericht eines laufenden Monats. Abgeschlossene Monate sind unverändert.

Changed

Intern: SQLAlchemy auf die 2.0-Linie gedeckelt, mit dem Extra asyncio. Am 24.09.2026 erschien SQLAlchemy 2.1, das greenlet nur noch als Extra mitbringt — ein frisch gebautes Add-on-Image hätte beim Start nicht mehr importieren können. Der Pre-Release-Smoke-Check (Prod-Parität auf frischem Python 3.11) hat es vor dem Tag gefangen.
Zählerlücken wie HA: fehlt in Home Assistant eine Stunde, rechnet eedc wie das Energie-Dashboard. Schreibt der Recorder eine Stunde nicht (Neustart, Update, WLAN-Ausfall), zeigt HA die Energie der Lücke in der ersten Stunde danach. eedc hat solche Stunden bisher leer gelassen und den ganzen Tag als unvollständig behandelt: Eigenverbrauch, Autarkie und Gesamtverbrauch standen dann auf „—”, obwohl die Tagessumme stimmte. Jetzt legt eedc je Stunde ab, was HA für diese Stunde zeigt; die Summe der Stunden ist der Tag, und der Tag ist die Zahl in HA. Eine Stunde, die mehr als eine reale Stunde trägt, ist in der Stundentabelle und im Tagesverlauf beschriftet („enthält n Stunden“). Stunden-Auswertungen (Korrekturprofil, Verbrauchsprofil, Grundlast, Speicher-Simulation, Spitzenwerte) lassen eine solche Zeile als Stichprobe aus, die Energie zählt aber in jeder Summe. Verworfen wird nur, was keine Anlage erzeugen kann: ein Rücksprung des Zählers oder ein Sprung über der Plausibilitätsgrenze (Anlagen-kWp × 1,5 je Stunde seit der letzten Änderung des Zählerstands — ein Nachtrag nach Stunden, in denen der Zähler stillstand, bleibt deshalb Menge, wie in HA). Nur dann erscheint der Hinweis „Verfügbare Energie“ in der Stundentabelle. Neu im Daten-Checker: Tage, an denen mehr eingespeist als erzeugt und aus dem Speicher entladen wurde („Einspeisung über Erzeugung“, mit Reparaturweg). Ein solcher Nachtrag erscheint im Daten-Checker als Hinweis „Nachtrag nach eingefrorenem Zähler“ mit Tagesliste, damit er sichtbar bleibt. ⚠ Welche Zahlen sich ändern: (1) Cockpit → Tag und → Monat zeigen Eigenverbrauch, Autarkie und Gesamtverbrauch an Tagen mit einer Lücke wieder. Der Tagesverbrauch rechnet nach der HA-Formel (PV + Netzbezug + Entladung − Einspeisung − Ladung); der Monat rechnet dieselbe Regel über seine Tage. Der Eigenverbrauch ist dabei nie negativ: speist ein Tag ohne PV-Messung ein, steht 0 statt eines Minuswerts. (2) Die Energie einer Lücke landet in der Folgestunde bzw. im Folgetag, wie im HA-Dashboard. Über Mitternacht verschiebt sie sich also vom einen in den anderen Tag; Lernfaktor, Prognose-Genauigkeit und der PR-Check lassen beide Tage aus. (3) Balkonkraftwerk mit eigenen Modul-Sensoren: der Teil, den sein eigener Zähler über die Module hinaus misst (je Stunde nie negativ), steht jetzt auch im Tageswert des Geräts (Cockpit → Tag, bisher 0); doppelt zählt dabei nichts. (4) Standalone ohne HA: Gerätetageswerte aus MQTT-Zählerständen rechnen ab dem letzten Stand vor dem Tag, der Rand verschiebt sich um bis zu eine Stunde. (5) Monatswerte aus der HA-Statistik (Monatsabschluss-Vorschlag, Cockpit → Monat, Statistik-Import) zählen die erste Stunde jedes Monats wieder mit und nach einer Lücke über die Monatsgrenze deren Energie. Ein Zählerrücksprung wird verworfen statt abgezogen, bei PV und Einspeisung auch ein Sprung über der Plausibilitätsgrenze, wie am Tag. (6) Jeder Slot mit Zählerwert bekommt eine Stundenzeile, auch ohne Leistungswert; die Stunden summieren sich damit auch dann zum Tag. (7) Im LTS-Tagesverlauf verdrängt eine Wallbox die Kurve des E-Autos erst ab ihrer Anschaffung (vorher über den ganzen Zeitraum); im Leistungspfad gelten für einen vergangenen Tag die Geräte, die an diesem Tag in Betrieb waren — eine seither stillgelegte Wallbox zählt dort mit. Bestandstage: Tage, die vor diesem Update gerechnet wurden, behalten ihre alte Regel, bis sie neu aggregiert werden. Der Daten-Checker nennt sie („n Tag(e) sind vor dem Umbau gerechnet“) und bietet den Knopf „Zeitraum neu aggregieren“ an; eine automatische Umrechnung beim Start gibt es nicht. Wer einen Tag nach einer Lücke über Mitternacht repariert, rechnet den Folgetag mit.
Die HA-Sensoren „Überschuss letzte Stunde“ und „Überschuss verfügbar“ nehmen eine gebündelte Stunde nicht als Stundenmittel. Nach einer Recorder-Lücke trägt die erste Stunde danach die Energie mehrerer Stunden; für diese beiden steuerungsrelevanten Sensoren zählt sie wie eine fehlende Stunde (so war es vor 4.0.51), die Energie bleibt in „Überschuss heute“. Gefunden im Doku-Durchgang vor dem Release, nie ausgeliefert.
E-Mobilität: jedes Auto trägt seine eigene Heimladung, die Wallbox den Rest — und Gast und Dienstwagen zählen nicht mehr als Ersparnis. Bisher kannte eedc je Monat nur eine Heimlade-Quelle: Hatte die Wallbox geladen, galt ihre ganze Menge als private Heimladung und wurde nach Kilometern auf die privaten Autos verteilt; Heimlade-Werte am Auto blieben neben einer Wallbox ohne Wirkung und wurden im Formular gar nicht angeboten. Jetzt gilt: Die Wallbox ist die Summe aller Ladungen an ihr. Jedes Auto mit eigener Messung („Heim: PV”, „Heim: Netz” oder das neue Feld „Heim: gesamt”, auch 0) trägt diese — auch neben der Wallbox und auch in einem Monat ohne Kilometer. Der Rest der Wallbox geht nach Kilometern an die privaten Autos ohne eigene Messung (bei 0 km zu gleichen Teilen); gibt es keines, zählt er nur als Verbrauch (Gäste, Verluste). Ein Dienstwagen mit eigener Messung trägt seine dienstliche Ladung und fehlt im Rest; an einer dienstlichen Wallbox zählt nur deren Menge. Wer gar kein Fahrzeug angelegt hat, behält die ganze Wallbox als Heimladung. „Heim: gesamt” wird mit dem PV-Anteil der Wallbox geteilt; „Heim: PV/Netz” gehen vor. Das Formular bietet die drei Felder jetzt an jedem E-Auto an (nur am Dienstwagen neben einer dienstlichen Wallbox nicht), ebenso die Datenquellen-Fläche, die CSV-Vorlage und MQTT. Im E-Auto-Hub steht ein Monat, in dem ein Auto nur Rest der Wallbox bekommt, als eigene Zeile „aus Wallbox-Rest“ (ohne km) in der Monatstabelle — so ergibt die Tabelle die Kachel „Heimladung“. ⚠ Welche Zahlen sich ändern: (1) Cockpit, CO₂-Bilanz, PV-Anteil der Heimladung, HA-Anlagen-Sensoren, Jahresbericht und Aussichten rechnen mit der privaten Heimladung — ohne Gast-Rest und ohne gemessenen Dienstwagen; wo beides an der Wallbox lud, sinkt die Heimladung und steigt die Ersparnis gegenüber dem Verbrenner. In Home Assistant springen damit einmalig je Auto e_auto_pv_anteil_prozent, e_auto_ersparnis_vs_benzin_euro und — wo kein Fahrverbrauch erfasst ist — e_auto_verbrauch_kwh_100km, dazu die Anlagen-Sensoren jahres_ersparnis_euro, roi_prozent und amortisation_jahre; die HA-Langzeitstatistik bekommt dort einen einmaligen Knick. (2) Der Wallbox-Hub zeigt als „Heimladung” die Messung der Wallbox (mit Gast und Dienstwagen) statt der bisher gewählten Quelle; seine „Ersparnis gegenüber externem Laden” und die Amortisation rechnen dagegen nur mit der privaten Heimladung. Wer mehrere Wallboxen hat, sieht auf jeder Karte deren eigene Messung (bisher die Summe aller Wallboxen); Ersparnis und Amortisation einer Karte sind ihr Anteil nach dieser Messung, gerechnet gegen ihre eigenen Anschaffungskosten. (3) Alte Heimlade-Zuordnungen und -Werte am Auto wirken wieder: eine Sensor-Zuordnung an „Ladung gesamt” aus der Zeit vor April 2026 (jetzt „Heim: gesamt”), Heimlade-Werte am Auto aus CSV-Import, „Aus HA laden”, einer Wiederherstellung oder der Demo-Anlage. Ein alter Gesamtwert mit „Herkunft unbekannt” zählt neben einer Wallbox weiter nicht. (4) Ein Auto, das geladen hat, aber nicht gefahren ist, trägt jetzt seine Stromkosten (Ersparnis negativ statt 0). (5) Die Ersparnis je Fahrzeug in Cockpit → Übersicht nimmt die Netzladung jedes Autos aus seinen eigenen Monaten statt eines Kilometer-Anteils am Ganzen. (6) An die Community geht als Wallbox-Ladung nur noch die private: gemessene Dienstwagen werden abgezogen (kWh und PV), mit einem ungemessenen Dienstwagen entfällt das Feld, die Zahl der Ladevorgänge entfällt, sobald ein Dienstwagen an der privaten Wallbox geladen haben kann. Die Regel „die Wallbox ist die Quelle” aus dem Punkt zum laufenden Monat oben gilt damit für die Menge der Wallbox, nicht mehr für die Heimladung der Autos. Der Daten-Checker meldet statt „Wallbox und E-Auto tragen beide Heimladung” (das ist jetzt der Normalfall) zwei neue Dinge: eine Warnung, wenn die Autos zusammen mehr geladen haben, als die Wallbox gemessen hat (mehr als 10 kWh bzw. 10 % der Wallbox — Streudaten am Auto, eine Quelle, die auch unterwegs zählt, oder Laden an der Steckdose), und einen Hinweis, wenn an einem Dienstwagen, der gefahren ist, die Heimladung fehlt, während die private Wallbox geladen hat (wer nur beim Arbeitgeber lädt, trägt dort 0 ein).
E-Mobilität: mit einem Ladezähler je Auto ordnet eedc jeden Ladevorgang den Stunden der Wallbox zu. Liegt an „Heim: gesamt” ein Zähler, der am Ende eines Ladevorgangs um dessen ganze Menge springt (so verhält sich evccs Fahrzeug-Sensor „Ladevorgänge: Energie [Fzg.]”), sucht eedc bei jeder Tagesberechnung vom Sprung rückwärts die Stunden der Wallbox, in denen dieser Vorgang lief — höchstens bis zum vorigen Sprung irgendeines Autos, eine gemeinsame Stunde wird nach den Restmengen geteilt. Die Menge eines Ladevorgangs bleibt der Sprung des Autos; die Wallbox-Stunden liefern nur, was allein sie wissen: den PV-Anteil dieses Autos (aus derselben Stundenrechnung wie der PV-Anteil der Heimladung) und die Verteilung auf die Monate. Die Heimladung eines Autos im Monat ist dann die Summe seiner Ladevorgänge statt des gespeicherten Monatswerts von „Heim: gesamt”, und der Daten-Checker vergleicht dieselbe Größe mit der Wallbox. Ein Vorgang, dessen Stunden in einer Zählerlücke der Wallbox liegen, zählt mit seiner Menge, sein PV-Anteil kommt dann aus dem Monatsanteil der Wallbox; hat die Wallbox einen Vorgang gar nicht gezählt, zählt er im Monat des Sprungs. Im E-Auto-Hub steht je Monat „aus n Ladevorgängen”, und wie viele davon die Wallbox nicht voll gezählt hat. Ohne Zähler je Auto oder ohne Wallbox-Zähler ändert sich nichts. ⚠ Welche Zahlen sich ändern: (1) Ein Ladevorgang über den Monatswechsel zählt anteilig in beiden Monaten statt ganz im Folgemonat; der Rest der Wallbox und die Warnung „Autos zusammen mehr als die Wallbox” folgen dem. (2) Der PV-Anteil eines Autos mit Zähler kommt aus den Stunden seiner eigenen Ladevorgänge statt aus dem Monatsanteil der ganzen Wallbox — lädt ein Auto mittags und das andere nachts, trennen sich ihre PV-Anteile. In Home Assistant springen e_auto_pv_anteil_prozent und e_auto_ersparnis_vs_benzin_euro dieses Autos und die Ersparnis-Sensoren der Anlage einmalig, sobald der Monat so gerechnet wird. (3) Das gilt für einen Monat nur, wenn jeder seiner Tage mit dieser Version berechnet ist; im Monat des Updates rechnet eedc deshalb wie bisher, bis er in der Reparatur-Werkbank („Mehrere Tage neu aggregieren”) neu berechnet wird. Die Zuordnung liegt in einer eigenen Tabelle neben den Tageswerten; Stunden und Tage selbst ändern sich dadurch nicht.
Der PV-Anteil der Heimladung zählt Strom aus dem Hausakku als eigenen Strom, nicht mehr als Netzstrom — und zeigt, wie viel davon aus dem Speicher kam. eedc leitet den PV-Anteil der Heimladung je Stunde aus Netzbezug und Einspeisung ab. Bisher wurde dabei auch die Entladung des Hausakkus abgezogen: lud das Auto abends aus dem Speicher, galt diese Ladung als Netzstrom. Nachgemessen an echten evcc-Ladevorgängen Juni–August 2026 lag eedc so bei 76 % statt 93,5 %; jetzt bei 94,5 %. Neu steht im E-Auto-Hub unter dem PV-Anteil „davon aus dem Speicher x %” und in der Monatstabelle „davon n kWh aus dem Speicher” — Speicherstrom ist kein Direktverbrauch aus der PV und kostet Wandlungsverluste. Ohne Speicherzähler gibt es diese Zeile nicht; sie ändert keine Kosten, keine Ersparnis und nichts an Community und HA-Sensoren. ⚠ Welche Zahlen sich ändern (nur mit Hausakku und ohne gepflegten PV-Anteil an der Wallbox): Der PV-Anteil der Heimladung steigt (an der Referenzanlage anlagenweit um rund 13 Prozentpunkte), die Stromkosten der E-Mobilität sinken, die Ersparnis gegenüber dem Verbrenner steigt — in Cockpit, E-Auto-Hub, Aussichten, Jahresbericht und den HA-Sensoren (e_auto_pv_anteil_prozent, die Ersparnis- und die daran hängenden Anlagen-Sensoren springen einmalig; die Langzeitstatistik bekommt einen Knick). Der Anteil entsteht beim Berechnen eines Tages: Tage, die vor diesem Update gerechnet wurden, behalten ihren alten Anteil, bis sie in der Reparatur-Werkbank neu aggregiert werden. Wer den PV-Anteil selbst pflegt (etwa aus evcc), sieht keine Änderung.
Die Karte einer dienstlichen Wallbox sagt, warum dort keine Ersparnis steht. Statt „n kWh = 0,00 €” steht in der ROI-Erklärung „dienstlich — keine private Ersparnis; die dienstlichen Ladekosten stehen im Cockpit”.
Anlagen ohne täglichen Blick ins Cockpit bekommen jetzt auch Stundenprofile — und damit erstmals eine Stundenkorrektur. Der Day-Ahead-Schnappschuss, aus dem eedc seine Stundenfaktoren lernt, entstand bisher beim ersten Seitenbesuch von Cockpit → Live. Wer eedc nur gelegentlich öffnet, sammelte deshalb nie genug Stunden, und die Prognose blieb dauerhaft beim gröberen Tagesfaktor. Jetzt legt der Hintergrund-Abruf ihn an, der ohnehin alle 45 Minuten läuft — ohne einen einzigen zusätzlichen Wetterabruf. ⚠ Zwei Folgen, die dazugehören: Das Profil entsteht ab jetzt nach Mitternacht statt beim ersten Besuch — das ist der Zeitpunkt, den „Day-Ahead” eigentlich meint, und der Tagesgang darin stammt damit aus dem Lauf des Vortags. Und an betroffenen Anlagen übernimmt nach etwa einer Woche die Stundenkorrektur die Führung vom bisherigen Tagesfaktor: eedc_prognose_heute_kwh entsteht dann aus 24 einzeln korrigierten Stunden statt aus einem Faktor auf die Tagessumme. Die Zahl ändert sich dadurch sichtbar — sie folgt ab dann dem Tagesgang der Anlage.
Intern: „Tagesprognose” bedeutet jetzt an einer Stelle dasselbe wie an der anderen. Das gespeicherte Feld pv_prognose_kwh wurde von zwei Stellen geschrieben — vom Hintergrund-Abruf als rohe Wetterprognose, beim Seitenbesuch als korrigierte und gekappte. Wer zuletzt schrieb, bestimmte die Bedeutung; die drei Auswertungen, die es lesen (Genauigkeits-Tracking, HA-Abweichungs-Ampel, Tages-SOLL im Energieprofil), rechnen es alle mit dem Lernfaktor hoch und erwarten deshalb die rohe Lage. Beide Schreiber liefern sie jetzt.
„Speicher voll um” startet dort, wo der letzte gemessene Ladestand wirklich steht. Die Simulation hinter eedc_speicher_voll_um, eedc_speicher_voll_um_ts, eedc_speicher_leer_um_ts und eedc_speicher_reicht_bis_mitternacht begann bei der laufenden Uhrzeit und rechnete diese Stunde ganz — ihr Startwert ist aber ein Stundenmittel, also der Ladestand etwa zur Mitte dieser Stunde. Die erste halbe Stunde ging damit doppelt in die Rechnung ein. Hatte Home Assistant die letzte Stunde noch nicht verdichtet, fiel umgekehrt eine halbe bis mehrere ganze Stunden aus der Rechnung heraus — an einem Nachmittag mit Sonne der Unterschied zwischen „wird heute nicht mehr voll” und „voll um 18:00”. eedc startet jetzt bei der zuletzt gemessenen Stunde und rechnet von ihr die halbe Stunde, alle folgenden ganz; eine Lücke bis jetzt wird mitsimuliert. ⚠ Das Textformat „HH:MM” bleibt unverändert (es ist seit 4.0.27 Vertrag) — der Wert kann sich um bis zu eine halbe Stunde verschieben. Die neuen Attribute sim_start_stunde und sim_start_anteil nennen die Annahme an jedem der vier Sensoren. Zwei Folgen, die dazugehören: Gibt es heute noch keinen Ladestand (Home Assistant hat seit gestern nicht verdichtet), simuliert eedc den ganzen Tag ab Mitternacht mit dem letzten Wert von gestern — bisher galt dieser alte Wert als „jetzt”, und der Vormittag fehlte in der Rechnung. Und „Speicher leer um” kann jetzt in der Vergangenheit liegen, wenn der Übergang in die Lücke zwischen letzter Messung und jetzt fällt — der Sensor sagt dann, seit wann der Speicher nach dem Modell leer ist, statt eine Uhrzeit nach vorn zu schieben.
Intern: GET /api/ha/export/mqtt/abwahl trägt ein Antwortmodell. OpenAPI zeigt jetzt, dass die Route seit 4.0.50 das Feld neues_paket liefert. Die Antwort selbst ist unverändert.
Intern: drei Park-Wächter sehen mehr. (1) Eine Fokus-Kachel mit einzeln parkbaren Kindern muss ein Gate auf die Kinder-IDs tragen — eine umhüllende Park-Leiste genügt nicht mehr; sie parkt die Kachel als ein Element und sagt nichts über den Fall, dass jemand alle Kinder einzeln wegräumt. (2) Trägt in einer Kennzahlen-Leiste eine Kachel eine Park-ID, müssen es alle tun; eine ohne war für beide bisherigen Regeln unsichtbar. (3) Der ID-Sammler liest keine Kommentare mehr — eine auskommentierte Park-Leiste galt ihm als Erzeugungsstelle und hätte die Lücke verdeckt, gegen die er gebaut ist.
Intern: die Stundentabelle in Cockpit → Tag hängt nicht mehr, wenn ein Aufrufer die Geräte-Spalten weglässt. Ihr leerer Standardwert war bei jeder Anzeige neu und ließ die Tabelle endlos neu zeichnen; Tagesverlauf und Wärme-Verlauf rechneten aus demselben Grund bei jeder Anzeige neu. Heute übergibt jeder Aufrufer den Wert — betroffen war niemand.

[4.0.50] - 2026-09-22 — eedc@ha, Teil 1: Entscheidungs- und Plan-Sensoren für Home Assistant — und jede Anzeige als Karte im HA-Dashboard

Added

Neue Sensor-Gruppe „Steuerungshilfen” — die Zahlen, aus denen eine HA-Automation ihre Entscheidung baut. Bisher sagte der Export, was ist (57 Sensoren). Dazu kommen jetzt 19 Sensoren, die sagen, was jetzt gilt und wann es gilt: Überschuss heute und der letzten vollen Stunde, Ladestand, „Speicher voll um” als echter Zeitstempel, Netzbezugs-Spitze, die Überschuss-Prognose je Stunde samt zusammenhängender Blöcke, das beste Fenster für eine verschiebbare Last in vier Dauern (1/2/3/4 h) mit Kostenprofil je kWh, ein Arbitrage-Vorschlag für Speicher, die aus dem Netz laden dürfen, und eine Ampel für auffällige Prognose-Abweichungen. Je Gerät kommen Warmwasser-, Heiz- und Kühlfenster der Wärmepumpe dazu sowie Monatsverbrauch und bestes Fenster eines sonstigen Verbrauchers (Pool, Sauna, Trockner, Heizstab mit eigenem Zähler) — für solche Geräte exportierte eedc bisher keinen einzigen Energiewert. Vollständige Liste mit Attributen in der Sensor-Referenz §11.
Erster zweiter HA-Komponententyp: binary_sensor. Fünf der neuen Sensoren sind Schalter statt Zahlen — „Überschuss verfügbar”, „Günstige Stunde”, „Speicher voll”, „Prognose-Abweichung auffällig” und je Wärmepumpe „Warmwasserbetrieb”. ⚠ Ein binary_sensor kennt in Home Assistant kein „unbekannt”; verliert er seine Grundlage, wird er in HA nicht verfügbar (eigener Verfügbarkeits-Kanal je Schalter), statt seinen letzten Zustand stehen zu lassen. Das ist der Unterschied zwischen „keine Daten” und einer falschen Wahrheit: bliebe der alte Zustand stehen, ließe ein ausgefallener Preisabruf „Günstige Stunde” womöglich dauerhaft auf an stehen, und eine Automation lüde zur teuersten Stunde. Ein gewöhnlicher Sensor zeigt bei fehlendem Wert weiterhin „unbekannt” und bleibt verfügbar — dort ist der leere Wert selbst die Aussage.
Die Verbrauchsprognose trägt jetzt ihre Stundenreihe mit. eedc_verbrauchsprognose_heute_kwh bekommt die Attribute stundenprofil_kwh (24 Slots) und wp_stundenprofil_kwh (der darin enthaltene Wärmepumpen-Anteil, temperaturkorrigiert). Aus ihr und der PV-Reihe entsteht die Überschuss-Prognose — die Größe, die weder eine Wallbox noch eine Wärmepumpe selbst bilden kann, weil keine von beiden den Verbrauchsgang dieses Hauses kennt.
Neun Sensoren zu Preisen und Speicher — und die Fenster rechnen erstmals mit dem Preis, den der Anwender zahlt. Bisher standen in den Fenster-Sensoren Börsenpreise, auch für einen Haushalt mit festem Arbeitspreis, der sie nie zu Gesicht bekommt. Neu je Anlage: eedc_bezugspreis_jetzt_cent (Festpreis/Zeitfenster exakt aus dem Tarif; dynamisch (1 + USt) × Börse + Aufschlag), eedc_einspeiseverguetung_cent, eedc_eigenverbrauch_wert_cent (Bezug − Vergütung), eedc_speicher_strom_kosten_cent und eedc_speicher_netzladen_kosten_cent (je ÷ Wirkungsgrad), eedc_speicher_leer_um_ts + eedc_speicher_reicht_bis_mitternacht (eine Regel, derselbe Simulationslauf wie „Speicher voll um”), eedc_abregelung_heute_kwh und eedc_einspeisung_unerwuenscht (negativer Börsenpreis und erwartete Erzeugung derselben Stunde, §51 EEG). Damit sind es 28 neue Definitionen in dieser Vorab-Version (22 je Anlage, 4 je Wärmepumpe, 2 je Sonstiges-Verbraucher).
Der Aufschlag eines dynamischen Tarifs wird abgeleitet, nicht abgefragt. Kein neues Pflegefeld: eedc rechnet ihn aus der letzten Abrechnung im laufenden Tarifzeitraum (Monats-Ø minus verbrauchsgewichtetem Börsenmittel desselben Monats) oder — wenn die fehlt — aus den gemessenen Stunden eines zugeordneten Preis-Sensors (Median über sieben Tage, mindestens 24 Paare). Gelingt beides nicht, bleibt der nackte Börsenpreis als ausdrücklich beschriftete Näherung stehen (preisquelle: boersenpreis, aufschlag_quelle: keiner) — und der Eigenverbrauchs-Wert entfällt dann, weil „Börsenpreis minus Vertragsvergütung” keine Näherung wäre, sondern eine Differenz aus zwei verschiedenen Preisebenen.
Der Wirkungsgrad eines Speichers wird gemessen, nie angenommen. Die beiden Speicherkosten-Sensoren nehmen den aus den erfassten Lade-/Entlademengen gerechneten Wert (an der Demo-Anlage 85,0 % über 34 Monate statt der gepflegten 95); geht das nicht, den gepflegten Parameter — und wirkungsgrad_messung nennt den Grund (fenster-zu-kurz · keine-ladung · nicht-ermittelbar · zu-wenig-monate). Gibt es beides nicht, entsteht der Sensor gar nicht. Derselbe Weg gilt jetzt auch für den Arbitrage-Vorschlag, der bis hierher mit einem Vorgabewert rechnete.
Der REST-Export liefert jetzt die Sensor-Attribute mit (neues Feld attribute je Sensor in /api/ha/export/sensors und /api/ha/export/sensors/{anlage_id}). Bis hierher kam aus dem ganzen Attribut-Block genau ein Wert durch — der Hinweis-Satz; Stundenreihen, Fenster, Quellenangaben (preisquelle, profil_typ, je_speicher …) endeten an der REST-Grenze und waren nur über MQTT zu sehen. Wer eedc über die rest-Plattform einbindet (das Snippet aus Einstellungen → Integration), bekommt damit dieselben Attribute wie über MQTT; das Feld hinweis bleibt unverändert daneben stehen (N-541).
Drei Automations-Beispiele in der Sensor-Referenz §11 — Speicher schonen bei billigem Netz (Bezugspreis gegen Speicherstrom-Kosten), Netzladen unter einer eigenen Preisgrenze (mit „reicht bis Mitternacht” als Sperre) und ein Heizstab in der Abregelung (Stundenreihe der erwarteten Kappung). Alle drei mit nativen HA-Bedingungen, je eine Zeile für die Entität des eigenen Geräts. Dazu eine Korrektur: die drei Template-Vorlagen nannten sensor.eedc_preis_rang — eine Entity-ID, die es in keiner Installation gibt. Home Assistant bildet sie aus dem Gerätenamen und dem Anzeigenamen (sensor.eedc_<anlage>_borsenpreis_rang); die Vorlagen und die Beispiele nennen jetzt diese Form.
Eine einzelne eedc-Anzeige lässt sich in ein Home-Assistant-Dashboard einbetten (Fokus-Deep-Link, FD-1 · FD-2 · FD-3 · FD-5 · FD-6). Jede Anzeige mit ⤢ Fokus/Vollbild hat jetzt eine eigene Adresse: #/<sicht>?fokus=<id>[&ansicht=tabelle]. Sie öffnet genau diese Anzeige als Deep-Link-Ansicht — ohne Zurück-Knopf, ohne ESC-Ausweg, ohne Theme-Umschalter, mit System-Theme (die gespeicherte Vorliebe bleibt unangetastet) und mit read-only Park (geparkt bleibt geparkt; der Parkplatz zum Zurückholen liegt außerhalb des Vollbilds). Bedienbar bleibt, was zur Anzeige gehört: Chart ⇄ Tabelle und die Zeitraum-Auswahl der Bilanzen; datum/jahr/monat/h laufen durch. Niemand baut eine Adresse von Hand: In der Fokus-Kopfzeile steht ein Knopf „Link / Einbetten”, der sie zeigt, kopiert und den Weg in HA erklärt (Dashboard bearbeiten → Karte hinzufügen → Webseite); unter Ingress ist es die Ingress-Adresse, im Standalone-Betrieb steht der ehrliche Hinweis zur Mixed-Content-Grenze daneben. Zeigt die Adresse ins Leere (unbekannte ID, geparkte Kachel, Zeitraum ohne Daten, Live ohne Sensoren), steht ein Hinweis-Overlay im Bild statt kommentarlos einer anderen Ansicht — auch auf Cockpit → Live, die keine Block-Hülle hat. ⛔ Kein Kiosk-Modus, kein theme=, kein zurueck= (Entscheid 22.09.); Deep-Links gibt es nur auf Block-Ebene, nicht je Kennzahl. Die Anzeige-IDs sind ab diesem Release öffentlicher Vertrag — ein Snapshot-Wächter (src/test/fokus-id-vertrag.test.ts, 108 IDs in 22 Dateien) meldet jede Umbenennung rot, weil sie fremde HA-Dashboards bricht. Melder Fesa2702 (Wandtablet, „zurück geht nicht”) und OB73-gif (#395, „Blöcke kopierbar machen”); Roadmap #110. Anleitung: Handbuch Bedienung §1.5.

Fixed

Der Geräte-Sensor investition_gesamt_euro nennt jetzt seine Laufzeit — Attribute anschaffungsdatum, stilllegungsdatum, aktiv, betriebsjahre (N-543, Gernot 21.09.). Bis dahin stand je Gerät ein Kostenwert in HA, dem man weder Laufzeit noch Stilllegung ansah, neben einer anlagenweiten Summe, die stillgelegte Geräte nicht enthält.
„Sensoren entfernen” räumt jetzt auch weg, was eedc vor März 2026 angelegt hat. Bis 77c6e211 (13.03.2026) legte eedc je bequelltem Feld eine number.eedc_…_start-Entität für den Zählerstand vom Monatsanfang an; der Statistik-Import hat diesen Weg ersetzt, die Entitäten blieben aber in Home Assistant stehen — in einer Produktions-Instanz gemessen: 19 Stück, alle „unbekannt”. Die Rücknahme arbeitete definitionsgetrieben und konnte deshalb nur räumen, was eedc heute publiziert; was es früher einmal publiziert hat, kannte nur der Broker. Sie ist jetzt bestandsgetrieben: sie fragt den Broker nach allem, was unter dem Präfix dieser Anlage retained liegt, und nimmt es mit zurück; die Meldung nennt die Zahl getrennt. Ausgenommen sind die retained Monatsabschluss-Nachrichten (eedc/anlage/…/monatsdaten/…): sie liegen unter dem eigenen Präfix, sind aber keine Sensoren, und ein Abschluss publiziert nur einmal — die erste Fassung nahm sie im HAOS-Lab mit (gemessen 21.09.). ⛔ Nur eigene Topics — Entitäten anderer Integrationen werden nicht angefasst. Dazu die Hilfe: §6.3 beschrieb die number-Entitäten und ihre Startwerte weiter als aktuellen Weg.
„Größerer Speicher?” und „Speicher-Potential” rechneten stillgelegte Speicher mit. Wer sein altes Gerät gegen ein neues tauscht und das alte — wie von uns empfohlen — als zweite Komponente mit Stilllegungsdatum stehen lässt, damit die Historie stimmt, sah in beiden Planungs-Sichten die Kapazität beider Geräte: beim Melder 15,3 kWh statt 10,24 kWh (gemeldet von Radiocarbonat, Forum). Betroffen waren drei Größen, nicht nur die Kapazität — auch der Wirkungsgrad (er ist das Minimum über alle Geräte; ein ausgemusterter Speicher mit 85 % zog die Rechnung dauerhaft herunter) und die Schwelle, ab der ein Speicher als leer gilt (sie folgt dem Verhältnis nutzbarer zu Brutto-Kapazität, also beiden Summen). Beide Sichten rechnen jetzt mit den Speichern, die heute laufen — ein deaktiviertes (Häkchen „Aktiv” entfernt) oder vor dem heutigen Tag stillgelegtes Gerät zählt nicht mehr zur Basis. Die Erfassung als zweites Gerät mit Stilllegungsdatum bleibt der richtige Weg: die Vergangenheit rechnet weiterhin mit dem Speicher, der damals dastand; nur die Frage „was bringt ein größerer?” steht auf dem heutigen Gerät (N-546).

Changed

Der Börsenpreis-Block lässt sich auf die Kennzahlen zuschneiden, die man wirklich braucht. Bisher war in Cockpit → Live nur der ganze Block „Börsenpreis heute & morgen” parkbar — entweder neun Kennzahlen und die Kurve oder nichts. Jetzt trägt jede Kennzahl und die Kurve eine eigene Park-Geste (Rechtsklick bzw. langes Drücken); geparkt wird über den Parkplatz am Seitenende zurückgeholt. Parkst du die Kurve, nehmen die Kacheln die volle Breite ein und umgekehrt — es bleibt keine leere Spalte stehen; ist alles geparkt, verschwindet der Block samt Überschrift. Zeigt er statt Preisen nur den Grund, warum gerade keine vorliegen, bleibt dieser Hinweis stehen: dort gibt es nichts zu parken. Vorstufe des Deep-Links — wer den Block künftig in ein HA-Dashboard einbettet, schneidet ihn vorher zu.
Die 28 neuen Sensor-Definitionen starten bei einer BESTEHENDEN Installation abgewählt. Bisher galt: jeder Sensor kommt an, abgewählt wird bewusst (#400, Entscheid 28.08.). Das bleibt für eine Neuinstallation und für alles, was du heute schon hast — aber nicht mehr für ein Paket, das erst mit einem Update dazukommt. Ohne diesen Schritt bekäme jede bestehende Installation mit aktivem Export beim ersten automatischen Publish nach dem Update 28 neue Entitäten, bevor irgendjemand sie ansehen konnte; mit v4.0.27 war genau das der Fall (21 neue Sensoren, zwei Melder binnen 24 Stunden), und in Home Assistant bleibt der Registry-Eintrag danach stehen. Die neuen Sensoren stehen jetzt unter Einstellungen → Integration → MQTT-Export in der Liste, tragen die Markierung „Neu”, und ein Kasten darüber sagt, wie viele es sind; ein Knopf „Alle neuen anwählen” nimmt sie auf einen Griff. Es geht dabei nichts verloren — sie waren nie in Home Assistant, es kann also keine Historie fehlen (genau der Grund, aus dem die Voreinstellung „alles an” im August 2026 entschieden wurde, trägt hier also nicht). Wer einen davon anhakt, behält ihn über jeden Neustart. Je Anlage sind es 22, dazu 4 je Wärmepumpe und 2 je Sonstiges-Verbraucher: eedc_ueberschuss_heute_kwh · eedc_ueberschuss_jetzt_kw · eedc_ueberschuss_verfuegbar (binary) · eedc_guenstige_stunde (binary) · eedc_speicher_voll (binary) · eedc_speicher_voll_um_ts · eedc_speicher_soc_prozent · eedc_netzbezug_spitze_heute_kw · eedc_ueberschuss_prognose_heute_kwh · eedc_arbitrage_vorschlag_kwh · eedc_bestes_fenster_ab · eedc_prognose_abweichung_heute_prozent · eedc_prognose_auffaellig (binary) · eedc_bezugspreis_jetzt_cent · eedc_einspeiseverguetung_cent · eedc_eigenverbrauch_wert_cent · eedc_speicher_strom_kosten_cent · eedc_speicher_netzladen_kosten_cent · eedc_speicher_leer_um_ts · eedc_speicher_reicht_bis_mitternacht (binary) · eedc_abregelung_heute_kwh · eedc_einspeisung_unerwuenscht (binary); je Wärmepumpe wp_warmwasserbetrieb (binary) · wp_warmwasser_fenster_ab · wp_heizfenster_stunden · wp_kuehlfenster_ab; je Sonstiges-Verbraucher sonstiges_verbrauch_monat_kwh · sonstiges_fenster_ab (N-545).
Die Stunden-Achse der Fenster- und Steuerungs-Sensoren liegt jetzt rückwärts — wie überall sonst im Baum und wie im HA-Energie-Dashboard (Slot „14” = 13:00–14:00). Sie folgte bisher der Börsenreihe, die vorwärts beschriftet ist, während PV-Prognose, Verbrauchsprofil und Tagesprofil rückwärts liegen: der Preis einer Stunde wurde damit gegen den Überschuss der Nachbarstunde verrechnet, und fünf Zeitangaben lagen eine Stunde daneben (seit, stunde_max_mittel, die Blöcke der Überschuss-Prognose, die günstigen Heizstunden — sowie stand, das die noch leere Zeile der laufenden Stunde las und deshalb eine Stunde voraus war). ⚠ Jede Zeitangabe sagt jetzt, ob sie Beginn oder Ende meint; das mehrdeutige Attribut stunde an eedc_ueberschuss_jetzt_kw ist durch stunde_von + stunde_bis ersetzt. Wer eine Automation auf die alten Zeiten gebaut hat, verschiebt sie um eine Stunde (N-544, nur diese Vorab-Version betroffen).
Die Prognose-Abweichungs-Ampel vergleicht gleich lange Zeiträume. Ihre SOLL-Summe endete an der Uhr, die IST-Summe an der letzten von Home Assistant geschriebenen Stunde — die kommt gegen Minute 12. Drei Viertel jeder Stunde stand damit eine gemessene Stunde mehr über einer prognostizierten weniger; der Kanon sagt jetzt selbst, bis wohin er gemessen hat.
eedc_bestes_fenster_ab und die Geräte-Fenster tragen den Tarifpreis (Attribut preisquelle: vertrag · zeitfenster · boerse_plus_aufschlag · boersenpreis · keine). Für einen Festpreis ohne Überschuss gibt es folgerichtig keine günstigste Stunde mehr — das Fenster beginnt dann jetzt, und delta_cent_kwh_vs_jetzt steht auf 0. eedc_preis_aktuell_cent und eedc_guenstige_stunde bleiben unverändert die Börsen-Sicht: sie beantworten eine andere Frage.

Intern

Der P10-Wächter erkennt eine Faltung jetzt auch, wenn die Zeilen als Parameter ankommen — die Bauform seit den Orchestrator-Schnitten (Vorlagen 5b/8b, RF-1…RF-3, S3): die eine Funktion lädt, die Phase daneben faltet, und ein select(InvestitionMonatsdaten) steht dort nirgends. Ein zweiter Suchlauf (_p10_imd_falter) sieht backend/api/ und backend/services/ auf drei Marker durch (.verbrauch_daten, imd_typ_beitrag, modus_strom_zeile) — nicht backend/core/, wo nach ADR-001 die Formel steht, die eine übergebene Zeile auswertet. Baseline: 32 Funktionen gemessen, 26 davon im Sichtfeld klassifiziert (11 Phasen mit ihrem Lader, 15 Checker ohne Lader), 0 offen. Heute war keine davon falsch; der Wächter war nur blind für sie (N-542).
Der Bezugspreis je Stunde liegt als Layer-Modul core/berechnungen/preis_reihe.py (Reihe, Endpreis, Aufschlags-Ableitung, gewichtetes Börsenmittel, Eigenverbrauchs-Wert), die Speicherkosten als core/berechnungen/speicher_kosten.py. ist_dynamisch(tarif) ist der eine Diskriminator für „der Preis kommt vom Markt” — er stand bisher an fünf Stellen ausgeschrieben; ein Wächter hält eine sechste fern. Die Eingänge sammelt services/ha_export_bezugspreis.py, einmal je Publish-Lauf und vor beiden Phasen, die sie brauchen.
Der Wirkungsgrad eines Speichers kommt aus einem Helfer (wirkungsgrad_ist_fuer_speicher) statt aus vier Nachbauten derselben vier Schritte; ROI-Dashboard und Speicher-Dashboard nutzen ihn mit.
Die Schwellen der Speicher-Simulation sind Konstanten (SOC_VOLL_PROZENT/SOC_LEER_PROZENT) statt Literale — die beiden neuen Sensoren müssen dieselbe Schwelle anwenden wie der Lauf, aus dem sie lesen.
Der REST-Export trägt attribute je Sensor, und damit sieht der Golden Master diese Hälfte des Exports erstmals (N-541). Die Achsen-Umstellung darüber wäre sonst durch ein grünes Gate gelaufen, das sie strukturell nicht kennt.
Der Fenster-Rechner liegt als ein Modul core/berechnungen/fenster.py mit fünf reinen Funktionen im Berechnungs-Layer; bestes_fenster ist der eine Fenster-Rechner, den P4/P5/P7/P8/P9 rufen — Warmwasser-, Heiz-, Kühl-, Sonstiges- und „bestes Fenster” mit anderen Eingängen. Ein Wächter (test_fenster_rechner_nur_im_layer) hält drei Formen eines zweiten Rechners fern. Dieselbe Bauform für die Heizgradtag-Korrektur des WP-Profils (wp_temperatur_faktor) und den mittleren Prognosefehler (prognose_genauigkeit.py), der bis hierher nur als lokale Funktion in der Genauigkeits-Route existierte.
Die Frage „hat dieses Gerät einen Kühl-Stromzähler?” steht jetzt an einer Stelle (daten_checker/kuehl_zaehler.py) statt als verschachtelte Funktion im Daten-Checker — der Sensor und der Checker beantworten sie damit gleich.
Preis- und Prognosedaten werden je Publish-Lauf einmal beschafft und an alle Geräte weitergereicht; die mengenneutrale Kostenrechnung entsteht einmal je Anlage.
Welches Paket eine Sensor-Definition mitbrachte, steht an ihr (SensorDefinition.seit_paket, 0 = „seit immer”); wie weit eine Installation eingewertet ist, in den Export-Settings (sensor_paket_stand). Bewusst eine ganze Zahl und kein Versionsstring: die Release-Nummer bumpt release.sh in fünf Dateien, nicht in einer Sensor-Definition — ein seit_version = "4.0.x" im Code wäre eine Behauptung über eine Zahl, die dieser Code nicht kennt. Der Erstlauf-Schritt (migrations/migrate_sensor_paket_abwahl.py) läuft bei jedem Start (nicht über die migrations-Tabelle, die gilt einmal je Name) und trägt seine Idempotenz selbst im Paket-Stand; er vereinigt die Abwahlliste und ersetzt sie nie. „Bestand” erkennt er an Spuren tatsächlicher Benutzung (schon publiziert, schon abgewählt, Export-Toggle explizit) — ausdrücklich nicht an export_aktiviert(), das ohne Eintrag auf einen Default auflöst, der im Add-on ab der ersten Minute wahr ist. Ein Wächter (test_n545_neue_sensoren_bei_bestand_abgewaehlt.py) hält gegen eine eingefrorene Liste fest, dass jede Definition ihre Paket-Zuordnung trägt: wer eine anlegt und sie vergisst, bekäme einen Sensor, der wieder unangekündigt erschiene.
Ein binary_sensor belegt vier retained Topics statt drei (dazu …/availability). Publish und Rücknahme bilden die Liste an einer Stelle (MQTTClient.alle_topics), damit die Abwahl eines einzelnen Sensors nichts liegen lässt (#400-Klasse); die bestandsgetriebene Rücknahme deckt den Zweig ohnehin ab.

[4.0.49] - 2026-09-21 — Ein Balkonkraftwerk mit zugeordneten Modulen zählt seine Erzeugung einmal

Fixed

Ein Balkonkraftwerk mit zugeordneten PV-Modulen zählte seine Erzeugung doppelt (gemeldet von Kai2, Forum). Wer seine beiden Module als eigene Komponenten mit dem Balkonkraftwerk als „Gehört zu” anlegt — der Weg, den wir für zwei Ausrichtungen empfehlen — und ihnen eigene Sensoren gibt, sah dieselbe Energie zweimal: im Energiefluss als „Solarleistung 167 W” für 84 gemessene Watt, dazu einen um denselben Betrag zu hohen Hausverbrauch, eine verdoppelte Auslastung und eine zu hohe Autarkie. Betroffen waren die Live-Ansicht, „Heute PV”, das Verbrauchsprofil, der Tagesverlauf sowie die gespeicherten Stunden- und Tageswerte und damit der laufende Monat. Ein Balkonkraftwerk mit Modul-Kindern ist jetzt Träger wie ein Wechselrichter: die Module tragen die Erzeugung, das Gerät trägt nur noch, was ihnen fehlt. Messen alle Module selbst, zählt es nicht mehr mit; misst nur eines, trägt es die Differenz; misst keines, bleibt es wie bisher die einzige Quelle — für den Normalfall (nur der Wechselrichter ist zugeordnet) ändert sich damit keine Zahl. Auf Monats- und Tagesebene wird sein Wert wie bisher kWp-gewichtet auf die Module verteilt und als Zerlegung gekennzeichnet, auf Stunden- und Live-Ebene bleibt er unverteilt beim Gerät (über eine Stunde mittelt sich Ost/West nicht aus). ⚠ Bereits gespeicherte Tage tragen die Zuordnung, mit der sie berechnet wurden — sie ändern sich nicht rückwirkend; ein Zeitraum lässt sich unter Einstellungen → Datenverwaltung neu aggregieren (N-536).

⚠ Nachträglich richtiggestellt (September 2026): „Messen alle Module selbst, zählt es nicht mehr mit“ gilt so nicht mehr. Seit eedc Zählerlücken wie Home Assistant rechnet, trägt ein Balkonkraftwerk mit eigenem Zähler auch dann den Teil, den dieser Zähler über die Module hinaus misst — je Stunde gerechnet und nie negativ; im Tageswert des Geräts steht damit dieser Rest statt 0. Doppelt gezählt wird dabei weiterhin nichts. Bei gut übereinstimmenden Zählern liegt der Rest nahe 0, deshalb fiel der Unterschied nicht auf.
Ein Tages-Lauf ohne Messwerte schrieb leere Stunden statt nichts (Standalone-Betrieb mit MQTT, ohne Leistungs-Zuordnung). Die Vorbedingung „gibt es für diesen Tag MQTT-Zählerstände?” fragte in Wahrheit „gab es nach dem Vortag irgendwann welche” — damit galt jeder Tag bis zum letzten Zählerstand als versorgt, auch Monate vor der Einrichtung. Der Monatsabschluss-Backfill, „Mehrere Tage neu aggregieren” und der Vortagsjob an einem Ausfalltag legten für solche Tage 24 leere Stunden an, die danach als aggregiert zählten; eine bereits gefüllte Tageszeile aus der Home-Assistant-Statistik wurde dabei durch die leere ersetzt. Jetzt gilt nur der Tag selbst (mit dem Vortag für den Anfangsstand) als Fenster: ohne eigenen Zählerstand läuft nichts, gefüllte Tage bleiben, und die Tagessicht nennt den ehrlichen Grund statt einen Knopf anzubieten, der nichts holen kann (N-539).
Der Daten-Checker warnte vor Lücken, die das Balkonkraftwerk längst schließt. Seine Prüfung kannte als Gesamtwert nur den Anlagen-Zählerstand. Hatte ein Balkonkraftwerk einen Monatswert und eines seiner Module keinen, meldete er ⚠️ „PV-Erzeugung unvollständig — kein Gesamtwert zum Verteilen hinterlegt”, obwohl jede Zahl vorhanden war; die Warnung ließ sich nicht abstellen. Jetzt gilt der Wert des Geräts als das, was er ist — das Aggregat seiner Module —, und der Monat erscheint als ℹ️ „über kWp-Anteil geschätzt”. Dazu sagt die Zuordnungs-Fläche an der Zeile des Balkonkraftwerks, welche Wirkung seine Sensoren noch haben, sobald Module eigene tragen (N-537).

Intern

Intern — der Monatsabschluss-Endpunkt ist ein Orchestrator mit 21 Phasen-Funktionen (Refactoring „Funktion vor Datei”, Vorlage RF-1). get_monatsabschluss hinter Cockpit → Monat → Monatsabschluss hatte eine kognitive Komplexität von 264 (SonarQube-Maßstab: 15) und ruft seine Abschnitte jetzt als Funktionen in derselben Datei; der Rest liegt bei 1, die höchste Phase bei 19. Antworten bitgleich (Golden Master über 125 Sichten). Dazu rechnet der Status den gemessenen Monats-Strompreis je Aufruf nur noch einmal statt zweimal (N-535).
Intern — der Portal-Import ist ein Orchestrator mit 23 Phasen-Funktionen (Vorlage RF-2). apply_import (kognitiv 220 → 3, höchste Phase 16) zerlegt in Träger, Ziel-Weg, anlagenweiten Weg, Wallbox/E-Auto und Klammer; Golden Master über 336 Sichten und Schreibschritte bitgleich. Die beiden CSV-Wege (Backup-Restore, CSV-Wizard) führen keinen Schutz-Zähler „X Felder durch manuell gepflegte Werte geschützt” mehr — er konnte seit Mai 2026 (#251: manuell gepflegte Werte schreiben unbedingt) nie feuern und stand in zwei Dateien als toter Zweig (N-538).
Intern — der Tages-Aggregator ist ein Orchestrator mit 21 Phasen-Funktionen (Vorlage RF-3). aggregate_day, die längste Funktion im Baum (kognitiv 201 → 4, höchste Phase 16), bleibt in einer Datei; 25 wortgleiche Rundungs-Ternäre heißen jetzt rund/ganz/nur_positiv, damit „0 ist keine Lücke” und „0 heißt keine Aussage” unterscheidbar sind. Neuer Schreib-Golden-Master über drei Bestände und drei Szenarien (41 292 Zeilen, 0 Unterschiede). Das Refactoring-Kriterium der Serie ist seit dem 19.09. die kognitive Komplexität der Funktion (> 50), nicht mehr die Zeilenzahl der Datei.

[4.0.48] - 2026-09-19 — Die Amortisationskurve zeigt gewachsene Anlagen als Treppe

Fixed

Der Statistik-Import ließ den PV-Gesamtzähler der Anlage liegen (gemeldet von Frank85, Forum). Wer nur einen gemeinsamen PV-Zähler in HA hat, sah ihn in der Vorschau als „PV Erzeugung Gesamt“, aber der Vergleich zählte nur Einspeisung und Netzbezug: der Monat galt als „stimmt überein“, der Import schrieb keine PV, der Daten-Checker meldete „PV-Erzeugung fehlt in 40 Monaten“ und riet zu genau diesem Import. Jetzt zählt jedes zugeordnete Zählerfeld beim Vergleich, ein fehlender Wert ist ein Import, und der Zähler wird wie im Monatsabschluss nach kWp auf die aktiven Module verteilt, als Zerlegung gekennzeichnet; Module mit eigenem Sensor behalten ihren Messwert.
„Aus HA laden“ zeigte für Einspeisung und Netzbezug seit v2.5.3 nur Striche (gemeldet von Frank85, Forum). Dialog und Formular suchten die Felder unter ihrer Mapping-Kurzform, das Backend liefert sie seit März unter dem Datenbanknamen; Komponentenwerte kamen an, die Zählerwerte nicht. Der Vergleich zeigt jetzt jedes gelieferte Zählerfeld samt PV-Gesamtzähler, und das Formular ist damit vorbelegt.
Das Speichern eines Monats unter Einstellungen → Monatsdaten und der Portal-/Cloud-Import brauchten 30 Sekunden — und die Protokollzeile fehlte (N-532). Das Aktivitätsprotokoll öffnete für jeden Eintrag eine eigene Datenbankverbindung. Hielt die Anfrage selbst gerade den Schreib-Lock — nach dem ersten Schreiben eines Imports oder eines Monats —, wartete die zweite Verbindung die volle Lock-Frist von 30 s ab, scheiterte mit „database is locked“, und der Eintrag ging verloren. Beim Monatsdaten-Formular war das eine Regression aus 4.0.47 (der wiederhergestellte Nachlauf des Monatsabschlusses protokolliert seither), beim Portal- und Custom-Import bestand es seit jeher. Gemessen an einer Demo-Kopie: 30,1 s → 0,03 s, Protokollzeile vorhanden. Das Protokoll schreibt jetzt in der Sitzung des Aufrufers; ein Wächter (test_n532_aktivitaetsprotokoll_in_der_sitzung.py) hält das für alle 25 Stellen fest.
Das Bearbeiten-Formular zeigte die Wechselrichter-Leistung eines Balkonkraftwerks beim erneuten Öffnen leer (gemeldet von Kai2, Forum). Gespeichert war der Wert, und er wirkte: Die Prognose wurde stündlich an der eingetragenen Grenze gekappt, im PVGIS-Soll wie in Live und 14 Tagen. Nur das Formular lud den Schlüssel beim Öffnen nicht, deshalb fehlte auch der Überbelegungs-Hinweis. Dieselbe Lücke bei einem Verbrauchszähler unter „Sonstiges”: Zähler-Art und Einheit zeigten beim erneuten Öffnen immer „Gas” und „m³”, gespeichert blieb das Richtige. Beide Formulare laden ihre Werte jetzt wieder; ein baumweiter Wächter hält jedes Feld der acht Typ-Formulare gegen die Initialisierung (F-77).
Der Daten-Checker meldete „Nur Balkonkraftwerk, keine PV-Module angelegt — PVGIS-Prognose und String-Vergleich sind ohne PV-Module nicht verfügbar” (gemeldet von Kai2, Forum). Der Satz stammt vom März; seit v4.0.9 bekommt ein Balkonkraftwerk sein eigenes PVGIS-Soll, und im Vergleich je Erzeuger ist es eine Zeile wie ein String. Ein Anwender las ihn als „deine Module fehlen”. Es fehlt nichts, also gibt es keine Meldung mehr; der Fehler „Keine PV-Module als Investition angelegt” bleibt für Anlagen ohne jeden Erzeuger. Im Handbuch (Einstellungen §3.5) entscheidet jetzt die Messung, wie ein Balkonkraftwerk mit Modulen in verschiedenen Richtungen erfasst wird: Liefert der Wechselrichter die Strings getrennt, werden sie als zugeordnete PV-Module mit eigener Ausrichtung und Neigung erfasst; liefert er nur einen Gesamtwert, bleibt „Ost-West (gemischt)” (N-526).
„Ost-West (gemischt)” rechnete in der Wetterprognose wie Süd. PVGIS teilte eine Ost-West-Komponente seit jeher in zwei halbe Anlagen (Ost −90°, West +90°); der Wetter-Pfad — Live, 14-Tage-Prognose, Prognose-Kanon, Prefetch, die HA- und MQTT-Prognosesensoren — kannte den Wert nicht und fiel auf 0° zurück. Folge: die Süd-Mittagsspitze und eine zu hohe Tagessumme für eine Anlage, die beides nicht hat; der Lernfaktor glich nur die Höhe aus. Jetzt liefert ein Erzeuger seine Abrufe aus einem Ort (pv_orientation.erzeuger_abrufe): Ost-West sind zwei halbe Strings mit derselben Neigung, die sich ihre Wechselrichter-Grenze teilen; alles andere bleibt bitgleich. Gefunden an Kai2s Anlage (Forum). ⚠ Die Prognosesensoren einer Ost-West-Anlage (eedc_prognose_*) sinken einmalig auf das richtige Niveau; bei fester Ausrichtung bewegt sich keine Zahl (als Probe belegt). Dazu: ein Balkonkraftwerk aus dem Einrichtungsassistenten trägt seine Ausrichtung nur im Parameter-JSON — die PVGIS-Prognose las nur die Spalte und rechnete es als Süd; PVGIS, Kappung und Aktualitätsprüfung lesen jetzt beide Ablagen (N-527 · N-528).
Die Break-Even-Kurve in Auswertungen → ROI zeichnet gewachsene Anlagen als Treppe (gemeldet von Radiocarbonat, Forum). Bisher stand der gesamte Kapitaleinsatz ab der frühesten Anschaffung, und die heutige Jahres-Einsparung lief von dort linear — wer über Jahre erweitert hat, las ein zu frühes Jahr; die Fußzeile nannte es „eher optimistisch”. Jetzt zählt jede Komponente ihre Mehrkosten und ihre Netto-Jahres-Einsparung ab ihrem eigenen Anschaffungsjahr, sonstige Ausgaben heben und sonstige Erträge senken die Linie im Jahr ihrer Buchung, und das Break-Even-Jahr in der Kachel „Amortisation” ist der Schnittpunkt genau dieser Reihe. Die Reihe rechnet das Backend (kapitalrechnung.amortisations_verlauf), der Client zeichnet nur noch. Die Dauer in Jahren bleibt wie bisher (Kapitaleinsatz ÷ heutige Jahres-Einsparung); HA-Sensoren, PDF und Aussichten sind unberührt. Benannte Grenze: ein PV-System hat eine gemeinsame Einsparung, ein später ergänztes Modulfeld stuft nur die Kosten (N-525).

Changed

Ein unplausibler Monat weist den Community-Datensatz nicht mehr ab (N-523). Der Community-Server lehnte bisher den ganzen Submit ab, sobald ein einziger Monat als unplausibel galt (Ertrag 0, Zukunftsmonat, über 180 kWh/kWp) — eine Installation verlor damit seit Wochen täglich ihren gesamten Vergleichsdatensatz, ohne es zu sehen. Der Server überspringt den Monat jetzt, nimmt die übrigen an und nennt den Grund; der Teilen-Block zeigt diese Hinweise nach „Jetzt übertragen“, das Aktivitätsprotokoll führt sie mit. Server-Hälfte im Community-Repo, wird mit diesem Release deployt.
Eine eben gespeicherte Komponente ist für den nächsten Aufruf sofort da (N-530). Der Datenbank-Commit lief bisher erst, nachdem die Antwort den Browser erreicht hatte — ein direkt anschließender Aufruf (der Setup-Wizard legt den Wechselrichter an und sofort danach die PV-Module mit seiner Nummer) fand die neue Zeile in etwa 0,4 % der Fälle noch nicht: „Parent-Investition nicht gefunden” oder ein leeres Formular nach dem Speichern. Alle 91 Schreibrouten committen jetzt vor dem Senden (gemessen: 0 statt 4–5 Nachzügler auf 600 Runden); ein Wächter hält die Regel baumweit.
Der HA-Sensor-Export antwortet sofort statt nach bis zu 30 Sekunden (N-531). Die REST-Sichten /api/ha/export/sensors… und der Publish-Knopf warteten bei kaltem Prognose-Cache auf den Zufalls-Jitter vor dem Open-Meteo-Abruf (1 bis 30 s, bei mehreren Ausrichtungen das Maximum), den jede andere Sicht längst überspringt. Home Assistants REST-Integration bricht nach 10 s ab und meldete die Sensoren so einmal je Stunde als nicht verfügbar. Der zeitgesteuerte Publish-Job behält den Jitter, weil er bei allen Installationen zur selben Minute läuft. Gefunden im Golden Master des Refactorings (29 s je Aufruf, auch ohne Netz).
Intern — api/routes/aktueller_monat.py ist ein Paket (Vorlagen 1 und 2 des Refactorings großer Dateien). Die 3.642-Zeilen-Datei hinter Cockpit → Monat ist in acht Module geteilt, Code 1:1 umgezogen: schemas.py (Antwortmodelle, Konstanten), vergleich.py (Vorjahr, PVGIS-Soll, Nachtsockel, Tarifauflösung), tkonto.py (T-Konto-Zeile je Investition), dazu die Abschnitte des Endpunkts als Funktionen mit ausdrücklicher Schnittstelle in aggregation.py (Typ-Aggregation, E-Mob-Pool, Werte, Bilanz), finanzen.py (Tarife und Kosten, Ersparnisse, T-Konto je Investition, eMob-Aggregat), waerme.py (Arbeitszahl, Abgrenzung, Tagesebene, Flags und WP-Zähler) und komponenten.py (Komponenten-Detail, Gerätesicht); die Fassade __init__.py behält Router, die fünf Quellen-Sammler, den Endpunkt als Orchestrator und die Antwort. Endpunkt und Sammler bleiben bewusst in der Fassade: 57 Testpatches setzen Attribute auf diesem Modul. ⚠ Keine Zahl, kein Pfad und keine Anzeige ändern sich — belegt je Commit mit bitgleichen Antworten des Endpunkts vor und nach dem Umzug an drei Beständen (Golden Master, plans/skript-golden-master-aktueller-monat.py), unveränderter Routen-Baseline und identischer Testsammlung.
Intern — core/field_definitions.py ist ein Paket (Vorlage 3). Die 3.554-Zeilen-Registry ist in sieben Module geteilt, Code 1:1 umgezogen: registry.py (die Feldtabellen je Investitionstyp), keys.py (Innengeräte-Schlüssel), bedingungen.py (Bedingungs-Auswerter, Feld-Bedarf, Wärme-Achsen), karten.py (Labels, Einheiten, Zähler- und Snapshot-Ableitungen), auswahl.py (Felder je Investition), reader.py (Lesezugriffe auf die Monatswerte) und wp_strom.py (Stromaufteilung der Wärmepumpe). Die Fassade __init__.py exportiert jeden bisherigen Namen weiter, kein Aufrufer ändert sich. ⚠ Keine Zahl, kein Feld und keine Anzeige ändern sich — belegt mit der vollen Suite, den Registry-Wächtern und bitgleichen Antworten von Cockpit → Monat an drei Beständen (Golden Master) sowie im HAOS-Lab.
Intern — api/routes/energie_profil/views.py ist in sieben Endpunkt-Module geteilt (Vorlage 4). Die 2.935-Zeilen-Datei hinter Cockpit → Tag und dem Energieprofil ist Code 1:1 umgezogen: tage.py (Tagesreihen), waerme.py (Wärme/Klima-Verlauf und -Verteilung), tag.py (Tag-Detail, Tag-Status), serien.py (Stunden, Wochenmuster, Komponenten-Serien), monat.py (Monatsauswertung samt ENERGIE_KATEGORIEN), diagnose.py (Debug, Statistik, Reaggregate-Vorschau) und prognose.py (Tagesprognose). views.py bleibt als Fassade: Router-Bündel in der bisherigen Reihenfolge, alle Endpunkt-Namen weiter importierbar. ⚠ Keine Zahl, kein Pfad und keine Anzeige ändern sich — belegt mit einem Golden Master über alle 17 Endpunkte (Status und Antwort bitgleich, Routen-Baseline gleich) an drei Beständen, der vollen Suite und dem Frontend-Spiegelprüfer, der jetzt monat.py liest.
Intern — api/routes/investitionen/crud.py gibt Schemas und ROI-Dashboard ab (Vorlage 5). Die 2.798-Zeilen-Datei ist Code 1:1 geteilt: schemas.py (die vier Investitions-Schemas samt leistung_kwp_effektiv), roi.py (das ROI-Dashboard hinter Auswertungen → ROI mit seinen Schemas, Helfern, der Gruppierung und den Kennwert-Auflösern), crud.py behält die sechs CRUD-Routen und die Parent-Regel, hängt den ROI-Router wie bisher nach ihnen ein und exportiert die bisherigen Namen weiter. ⚠ Keine Zahl, kein Pfad und keine Anzeige ändern sich — belegt mit einem Golden Master, der neben allen Lese-Sichten eine Schreib-Sequenz (Anlegen, Lesen, Ändern, Löschen je Typ, Parent-Regel, Innengeräte-Aufräumen) auf beiden Ständen identisch fährt, der vollen Suite und dem HAOS-Lab.
Intern — das ROI-Dashboard ist ein Orchestrator mit fünf Phasen-Funktionen (Vorlage 5b). Der 1.592-Zeilen-Endpunkt get_roi_dashboard ruft jetzt lade_roi_eingaenge (roi_eingaenge.py: Anlage, Tarife, Investitionen, sonstige Positionen, Treppen-Anker), pv_einsparung_und_speicher_ist, pv_systeme_zeilen, orphan_modul_zeilen (roi_pv.py) und standalone_zeilen (roi_standalone.py) — jede Phase byte-identisch herausgelöst, Schnittstelle als Schlüsselwort-Parameter und Rückgabe-Dict; in roi.py bleiben Gruppierung, USt, Gesamt-ROI, Treppe und Antwort. ⚠ Keine Zahl und keine Anzeige ändern sich — belegt mit demselben Golden Master (Lese-Sichten und Schreib-Sequenz an drei Beständen, dazu Einspeisevergütung 0 und ein Jahr ohne Daten), den 25 ROI-Testdateien und dem HAOS-Lab.
Intern — api/routes/investitionen/dashboards.py ist in Typ-Module geteilt (Vorlage 6). Die 2.747-Zeilen-Datei der Komponenten-Dashboards ist Code 1:1 umgezogen: je ein Modul dashboard_<typ>.py für E-Auto, Wärmepumpe, Speicher, Wallbox, Balkonkraftwerk und Sonstiges, dazu dashboard_basis.py (Preis-Mittelung, Monatsdaten-Antwortmodell). dashboards.py behält die typunabhängigen Sichten (Monatsdaten je Monat, CO2-Amortisation, Hub-Leer-Grund), hängt die Typ-Router an ihrer bisherigen Stelle ein und exportiert die bisherigen Namen weiter. ⚠ Keine Zahl und keine Anzeige ändern sich — belegt mit dem Golden Master der Investitionen, der jetzt auch alle Dashboards mit Preis-Overrides, die Monatsdaten je Monat, CO2-Amortisation und Hub-Leer-Grund vergleicht, der vollen Suite und dem HAOS-Lab.
Intern — api/routes/aussichten.py ist ein Paket (Vorlage 7). Die 2.619-Zeilen-Datei ist in sechs Module geteilt, Code 1:1 umgezogen: finanzen.py (die Finanz-Prognose hinter Auswertungen → Finanzen), prognose.py (kurzfristig, langfristig), trend.py, wetter.py, schemas.py (die Antwortmodelle) und basis.py (Konstanten, Anlagen-Lader). Die Fassade exportiert jeden bisherigen Namen weiter, kein Aufrufer ändert sich. ⚠ Keine Zahl und keine Anzeige ändern sich — belegt mit einem neuen Golden Master über alle fünf Aussichten-Endpunkte (plans/skript-golden-master-aussichten.py, drei Bestände bitgleich), der vollen Suite und dem HAOS-Lab.
Intern — die Finanz-Prognose ist ein Orchestrator mit zehn Phasen-Funktionen (Vorlage 7b). Der 1.674-Zeilen-Endpunkt get_finanz_prognose (Auswertungen → Finanzen) ruft seine Abschnitte jetzt als Funktionen in vier Modulen: finanz_eingaenge.py (Investitionen, historische Werte, Quoten, PVGIS, Kosten und Parameter), finanz_rueckblick.py (bisherige Erträge in drei Schritten), finanz_prognose.py (Monatsprognose, Jahres-Alternativkosten) und finanz_zerlegung.py (Komponenten-Beiträge, ROI, Fortschritt je Investition); Kopf und Response bleiben in finanzen.py. Code 1:1 umgezogen, Schnittstelle je Phase als Schlüsselwort-Parameter und Rückgabe-Dict; die Wächter-Einträge (P7, P10, P11, Preis-Kaskade, N-252) folgen den Phasen. ⚠ Keine Zahl und keine Anzeige ändern sich — belegt mit dem Golden Master über alle fünf Aussichten-Endpunkte (drei Bestände bitgleich), der vollen Suite und dem HAOS-Lab.
Intern — api/routes/ha_export.py ist ein Paket (Vorlage 8). Die 2.576-Zeilen-Datei hinter dem HA-Sensor-Export ist in sieben Module geteilt, Code 1:1 umgezogen: anlage_sensoren.py und investition_sensoren.py (die zwei Rechenkerne), schemas.py, emob.py (der E-Mob-Pool), konfig.py (MQTT-Konfiguration, Sensor-Abwahl), sensoren.py (REST-Sichten, YAML) und mqtt.py (Discovery). Die Fassade trägt den Router mit dem bisherigen Präfix und exportiert jeden bisherigen Namen weiter; Wächter, Registry und zwei Patch-Ziele folgen den Modulen. ⚠ Keine Zahl und kein Sensor ändern sich — belegt mit einem neuen Golden Master über die Export-Lesesichten (plans/skript-golden-master-ha-export.py, drei Bestände bitgleich), der Routen-Baseline, der vollen Suite und dem HAOS-Lab.
Intern — der Anlagen-Rechner des HA-Exports ist ein Orchestrator mit neun Phasen-Funktionen (Vorlage 8b). calculate_anlage_sensors (1.051 Zeilen) ruft seine Abschnitte jetzt als Funktionen in drei Modulen: anlage_energie.py (Monatsfakten und Energie, Finanz-Aggregat, Investitionen und USt), anlage_komponenten.py (historische Komponenten, Alternativkosten und CO₂, Ertrag und Amortisation, Speicher-KPIs) und anlage_sensorwerte.py (Sensorwerte, Prognose- und Preis-Sensoren, dazu grundlast_sensorwert); Kopf und Rückgabe bleiben in anlage_sensoren.py. Code 1:1 umgezogen, Schnittstelle je Phase als Schlüsselwort-Parameter und Rückgabe-Dict; Wächter (P10, N-252), Registry und ein Patch-Ziel folgen den Phasen. ⚠ Keine Zahl und kein Sensor ändern sich — belegt mit dem Golden Master über die Export-Lesesichten (drei Bestände bitgleich), der vollen Suite und dem HAOS-Lab.
Intern — services/daten_checker/datenquelle.py ist ein Unterpaket (Vorlage 9). Die 2.031-Zeilen-Mixin-Klasse DatenquelleChecks ist in sieben Mixins je Prüf-Familie geteilt, Code 1:1 umgezogen: quellen.py (Provenance, Status, Drift), tage.py, speicher.py, klima.py, connector.py, zeitzone.py und ruecksprung.py; die Fassade trägt DatenquelleChecks als Verbund weiter, der Daten-Checker komponiert wie bisher. Wächter, ein Patch-Ziel und die Doku folgen den Modulen. ⚠ Keine Prüfung und keine Meldung ändern sich — belegt mit einem neuen Golden Master über den Daten-Check je Anlage (plans/skript-golden-master-daten-checker.py, drei Bestände bitgleich), der vollen Suite und dem HAOS-Lab.
Intern — services/monats_fakten.py ist ein Paket (Vorlage 10). Die 2.560-Zeilen-Schicht hinter ADR-002/P10 ist in sieben Module geteilt — fakten (die Feldgruppen), fakten_wp, roh (Rohmonat und Lader), tarif, bau, laden (der Orchestrator) und ableitungen — Code 1:1 umgezogen, die Fassade exportiert die bisherigen Namen weiter; kein Verhaltenswechsel. Gate: alle sechs Golden Master bitgleich, der P10-Wächter nimmt das ganze Paket als Schicht.
Intern — der Testlauf berührt die Entwickler-Datenbank nicht mehr (N-414). Die Produktiv-Engine zeigte in Tests auf data/eedc.db: das Aktivitätsprotokoll, die echte App-Lifespan eines Tests und der Prognose-Cache schrieben dort je Lauf 12–20 echte Zeilen, und ihre nie geschlossene Verbindung erzeugte die seit Wochen wandernde Warnung „Event loop is closed“ (0–12 je Lauf, je nach Worker-Zuteilung). conftest.py gibt der Engine jetzt eine Wegwerf-Datei je Worker, setzt das Cache-Flag je Test zurück und lässt die Lifespan ohne Scheduler starten.

[4.0.47] - 2026-09-18 — Der Monatsabschluss sendet wieder, der Community-Vergleich rechnet gleich auf beiden Seiten — und die Ersparnis kennt den Preis der vermiedenen Stunden

Fixed

Seit v4.0.0 lief nach dem Monatsabschluss nichts mehr nach — kein automatisches Teilen, kein MQTT-Publish der Monatswerte, kein Nachfüllen des Energieprofils. Das Monatsformular der neuen Oberfläche speicherte über einen Weg, an dem der Nachlauf nicht hing; der einzige Aufrufer des alten Wegs war der mit v4.0.0 entfernte 7-Schritt-Wizard. Sichtbar war das kaum: Das Speichern gelang, nur die drei Schritte danach blieben aus — community-weit trugen am 17.09. 19 von 138 Anlagen einen August-Wert. Jetzt laufen alle drei Nachläufe bei jedem Speichern (Anlegen und Ändern) und schreiben ihren Aktivitätseintrag. Wer automatisch teilt, sendet nach dem Update einmal alles nach: Die seit dem 25.07. liegengebliebenen Monate kommen von selbst auf den Community-Server — mit der Einwilligung, die dafür ohnehin vorliegt. Alle anderen finden unter Community einen Hinweis mit Knopf. Eine Meldung von Installationen ohne aktives Teilen gibt es bewusst nicht: eedc nimmt keinen neuen Kontakt nach außen auf (F-73).
„Tag neu aggregieren” meldete „ohne Wert blieb: pv”, obwohl der PV-Wert geschrieben war (gemeldet von Frank85, Forum). Seit v4.0.39 löst der Tagespfad einen zugeordneten PV-Gesamtzähler beim Schreiben in die einzelnen Module auf; die Rückmeldung fragte aber weiter nach dem Gesamt-Schlüssel und fand ihn nicht — bei jeder Anlage mit PV-Gesamtzähler. Derselbe Fehler machte im Tag-Status aus „HA hat Werte” ein „HA hat nichts”, wenn der Gesamtzähler der einzige Zähler war. Die Rückmeldung nennt den Zähler jetzt wie in der Zuordnung, „PV gesamt” mit seinen kWh: „3 von 3 Komponenten neu geschrieben”. An den Tageswerten ändert sich nichts — sie waren richtig (F-75).
Der Community-Vergleich rechnet ein Teiljahr saisonal hoch — die für den 1. September angekündigte Umstellung ist da (#387, gemeldet von azywietz-web). Maßstab ist die PVGIS-Erwartung des eigenen Standorts; unter der Zahl steht „hochgerechnet aus X von 12 Monaten”, ein hochgerechneter Eintrag in der Top-10-Liste trägt „(5/12)” mit Tooltip. Es gibt nur noch einen Community-Durchschnitt, und ohne Vergleichswert gibt es keinen Rang mehr — vorher stand dort Platz 1. Fehlt der Jahreswert, nennt eedc den Grund und den Handgriff (Solarprognose anlegen, erneut teilen) statt „fehlen noch abgeschlossene Monate”. Der Monatsvergleich fällt nicht mehr auf ein Zwölftel des Jahreswerts zurück — die Balkenfarbe sagte damit die Jahreszeit, nicht die Leistung (N-292). Die Server-Hälfte ist seit dem 18.09. live.
Community-Vergleich E-Auto, Wallbox, Balkonkraftwerk und Wärmepumpe: Ø und eigener Wert rechneten in verschiedenen Fenstern. Der Community-Ø lief über die ganze Historie samt laufendem Monat, der eigene Wert über die zwölf abgeschlossenen Monate — zwei verschieden gebildete Zahlen in einer Kachel (Probe: 50,0 gegen Ø 23,3). Jetzt dasselbe Fenster auf beiden Seiten, ohne laufenden Monat, und jede Vergleichskachel nennt ihre Grundgesamtheit: „Ø von 17 Anlagen”. Die Zyklen des Speichers sagen, aus wie vielen Monaten sie hochgerechnet sind. Gefunden hat das die neue Prüfschicht des Community-Servers (17 Proben über vier Achsen), nicht ein Melder (F-76 · N-524).
Die Eigenverbrauchs-Ersparnis rechnet auf jeder Ebene mit dem Preis der vermiedenen Stunden. v4.0.46 hatte das für den Tag gebaut; Monat, Jahr, Netto-Ertrag, PDF und HA-Export bewerteten die vermiedene Menge weiter mit dem bezugsgewichteten Ø — an einem dynamischen Tarif systematisch zu hoch, weil PV-Strom die günstigen Mittagsstunden ersetzt und nicht den teuren Abend (Probe: 0,60 statt 3,00 €). Jetzt gilt derselbe Preis aus denselben Stundenzeilen auf allen Ebenen, auch neben einem gepflegten Abrechnungs-Ø (der bleibt für den Netzbezug maßgeblich; für die Ersparnis gilt darunter die Messung). ⚠ Der HA-Sensor netto_ertrag_euro und die daran hängenden ROI-/Amortisations-Sensoren springen bei einem dynamischen Tarif deshalb einmalig nach unten; bei Festpreis bewegt sich keine Zahl (als Probe belegt, nicht nur beabsichtigt). Dazu: „Ø Netzpreis” im Fuß von Auswertungen → Tabelle ist mengengewichtet statt ein Mittel der Monats-Ø — der Börsenpreis-Ø bleibt ein Zeitmittel, er ist kein bezahlter Preis; unter der Tages-Tabelle steht, dass Tage gemessen und der Monat abgerechnet ist. Konzept: docs/KONZEPT-FLEX-TARIFE.md.
Wärme/Klima: Monat und Jahr sagten „kein Wärmemengenzähler zugeordnet”, wenn der Zähler zugeordnet war und nur nichts lief (gemeldet von dietmar1968, Forum). An seiner Wärmepumpe hängen beide Zähler; im September wurde nicht geheizt. Der Tag sagte richtig „kein Heizbetrieb in diesem Zeitraum”, Monat und Jahr schickten ihn in die Datenquellen, eine Zuordnung zu suchen, die er längst hat — nach dem Summieren über Geräte und Monate waren gemessene Null und fehlender Zähler dieselbe 0. Die Marke „gemessen” wird jetzt je Funktion (Heizen · Warmwasser) getrennt durchgereicht (N-479).
Eine eingetragene Recorder-Adresse, die nicht erreichbar ist, fällt nicht mehr still zurück. eedc wich richtig auf die Datei home-assistant_v2.db aus, der Status sagte danach aber nur „SQLite” — die Konfiguration wirkte unbemerkt nicht, und die Zahlen kamen aus einer Datei, die nach einem Recorder-Wechsel alt sein kann. Der Status unter Einstellungen → Datenquellen nennt jetzt den Rückfall samt Fehler: „SQLite (Rückfall — die eingetragene Recorder-Adresse ist nicht erreichbar: …)”. Aus der Diagnose mit Blockmove (Forum); die Lesbarkeitsprüfung der Datei ist seit v4.0.46 drin.

Changed

eedc_speicher_voll_um nennt als Attribute, mit welchem Verbrauchsprofil die Simulation gerechnet hat (profil_typ, profil_wochen, profil_halbwertszeit_tage, profil_stufe, profil_tage, verbrauch_annahme_kwh). Es ist ein anderes Modell als hinter eedc_verbrauchsprognose_heute_kwh (gewichtete acht Wochen statt 7-Tage-Profil) — eine Automation, die beide verrechnet, mischte zwei Modelle, ohne dass ein Attribut es sagte. Am Wert ändert sich nichts; Sensor-Referenz an beiden Stellen ergänzt (N-392).
eedc nennt dem Community-Server Variante und Version (eedc-homeassistant/<Version> bzw. eedc/<Version>) — auf den Anfragen, die es vorher schon gab, kein neuer Kontakt nach außen und nichts, was eine Installation wiedererkennbar macht; Handbuch §5.3 Datenschutz nennt die Angabe. Für den Maintainer sichert scripts/github-traffic.sh täglich GitHub-Traffic, die HA-Analytics-Zahl des Add-ons je Version und die Community-Zugriffe aus dem Proxy-Log.
Doku: docs/KONZEPT-FLEX-TARIFE.md — welchen Preis eedc einer Kilowattstunde zuordnet, auf welcher Ebene und aus welcher Quelle (abgenommen und gebaut). Die MQTT-Dokumentation führt ladung_pv_kwh und die übrigen Felder der Topic-Registry als lieferbar — sie standen fälschlich unter „nicht per MQTT lieferbar” (Discussion #414, gruaGit); der selbst errechnete PV-Ladezähler steht als Beispiel mit seiner Bedingung drin. Der alte Satz „ein gepflegter Ø gilt rückwirkend für jeden Tag” trägt seinen Aufhebungs-Vermerk; zwei Proben decken den Tag der Zeitumstellung.

[4.0.46] - 2026-09-17 — Flexible Stromtarife rechnen je Stunde statt je Monat, der Speicher wird nicht mehr schlechter gerechnet, als er ist — und die Sichten mit langer Historie öffnen sich schneller

Changed

Wer einen flexiblen Stromtarif hat, sieht seine Tage jetzt mit den Preisen gerechnet, die an diesen Tagen galten. Bisher gewann immer der Monat: Der für einen Monat gepflegte oder abgerechnete Ø-Preis wurde nach unten durchgeschrieben, sodass jeder Tag desselben Monats denselben Strompreis trug — obwohl eedc die Börsen- bzw. Endkundenpreise stundenweise mitschreibt. An einem Tag mit viel Netzbezug in teuren Abendstunden stand damit ein zu niedriger Betrag, an einem günstigen Tag ein zu hoher; in der Summe stimmte der Monat, im einzelnen Tag nichts. Jetzt gilt: Tage sind Messung, Monate sind Abrechnung. Die Tageskosten entstehen als Σ(Preis der Stunde × Menge der Stunde), der Tages-Ø ist der Quotient daraus, und neben jedem Wert steht, woher er kommt und welcher Anteil der Menge bewertet werden konnte. Die Monatskachel zeigt jetzt denselben Wert, den ihre Formelzeile beschreibt — sie las bis hierher den Stammpreis aus dem Tarif, während die Kosten daneben schon mit dem gemessenen Ø gerechnet waren: drei Zahlen in einer Kachel. ⛔ Bei einem Festpreis-Tarif bewegt sich keine einzige Zahl — alle Stunden tragen denselben Preis, und das Ergebnis ist rechnerisch identisch zu vorher. Das ist als Probe festgehalten, nicht nur als Absicht. ⚠ Trägst du später einen abgerechneten Monats-Ø nach, ändert das den Monatsbetrag — die Tage bleiben, wie sie gemessen wurden. Eine Abrechnung gilt für den Zeitraum, für den sie ausgestellt ist; unterhalb davon gilt die Messung.
Der Speicher wird nicht mehr schlechter gerechnet, als er ist — und sein Gewinn nicht mehr erfunden. Drei Stellen liefen bei einem Flex-Tarif systematisch falsch. (1) Die Entladung wurde mit dem Ø-Bezugspreis über die gesamte Lebensdauer bewertet, obwohl entladen wird, wenn der Strom teuer ist — genau deshalb lohnt sich ein Speicher. Sie zählt jetzt mit dem Preis der Stunde, in der sie stattfand, und zwar für beide Anteile der Ersparnis (PV-Anteil und Arbitrage beantworten dieselbe Frage: was hätte diese Kilowattstunde aus dem Netz gekostet?). (2) Der Ladepreis fiel, wenn keine Stundenpreise vorlagen, auf den Monats-Ø des Netzbezugs zurück — eine Bezugsabrechnung sagt aber nichts darüber, was die Ladung des Speichers gekostet hat; aus diesem Rückfall entstand ein Gewinn, den es nicht gab (an einem Beispielbestand 99,09 € aus Daten, die über den Ladepreis nichts aussagen). Der Rückfall ist weg. (3) Der Wirkungsgrad hing am Preis-Spread statt an der Menge — bezahlt wurde die eingespeicherte, nutzbar ist die entladene Kilowattstunde. ⭐ Gemessene Stundenpreise schlagen jetzt den gepflegten Ladepreis: Anders als beim Netzbezug gibt es hier keine externe Wahrheit — ein Ladepreis steht auf keiner Rechnung. Ein selbst eingetragener Wert bleibt als bewusste Korrektur erhalten und trägt seine eigene Herkunft. ⭐ Auch die Eigenverbrauchs-Ersparnis rechnet jetzt mit der tatsächlich vermiedenen Menge statt mit einem pauschalen Mittel. ⛔ Festpreis-Anlagen sehen auch hier keine Änderung.
Der Daten-Checker schreibt Zahlen jetzt so, wie der Rest von eedc sie schreibt: „6,0 kWp” statt „6.0 kWp” und „12.000 kWh” statt „12000 kWh”. Bisher meldete er dieselbe Anlage anders als die Oberfläche und die vier PDF-Berichte — an 85 Stellen in sieben Prüfmodulen. Betroffen waren beide Hälften der deutschen Schreibweise: das Dezimalkomma („6.0 kWp”) und der Tausenderpunkt, der auch bei ganzen Zahlen fehlte („1260 W” statt „1.260 W”, „12000 kWh” statt „12.000 kWh”). ⭐ Damit es so bleibt, hängt die Regel nicht mehr an der Aufmerksamkeit: Die Rechnung steht als einziger Ort im Berechnungskern, und ein neuer Prüfer meldet bei jedem Testlauf rot, sobald im Daten-Checker wieder eine Zahl von Hand formatiert wird. Deine Daten sind unberührt — es ändert sich allein, wie die Meldungen aussehen; eedc liest Zahlen unverändert ein, auch aus importierten Dateien.
Cockpit → Monat, Jahr, Komponenten, Auswertungen und der Investitions-ROI öffnen sich deutlich schneller — und werden nicht mehr jedes Jahr langsamer. Beim ersten Aufruf einer dieser Sichten rechnete eedc die komplette Historie neu durch, und zwar Monat für Monat: An einer Anlage mit 39 gepflegten Monaten waren das 117 Abfragen über die Stundentabelle für ein und dieselbe Frage („welchen Strompreis hatte dieser Monat?”), dazu ein Ladevorgang, der alle Stundenzeilen der Anlage als vollständige Objekte in den Speicher holte — 17.366 Zeilen, nur damit sechs Zahlen summiert werden. Gemessen an einer echten Anlage: Auswertungen → Tabelle 2,4 s, Investitions-ROI 3,9 s, und Cockpit → Jahr im Browser 10,1 s, weil die Sicht mehrere solcher Abrufe gleichzeitig startet und diese sich gegenseitig ausbremsten. ⭐ Der Aufwand hing an der Zahl deiner Monate — jeder neue Monat kostete rund 90 ms mehr, also etwa eine Sekunde pro Jahr, dauerhaft und in jeder dieser Sichten. Jetzt fragt eedc einmal statt 117 Mal, liest von der Stundenebene nur die sechs gebrauchten Spalten und auch nur für die Monate, die sie überhaupt brauchen, lädt die Tarife aller Monate in einer Abfrage statt in 39, holt die Tagesmittel der Temperatur gruppiert statt Zeile für Zeile und baut die Monatswerte im ROI einmal statt zweimal. Im Nachbau derselben Anlage: Auswertungen → Tabelle 1162 → 74 ms, ROI 1289 → 132 ms, CO₂-Bilanz 632 → 52 ms. ⛔ Keine einzige Zahl ändert sich — belegt mit 25 Antwortvergleichen über drei Datenbestände (darunter einer eigens mit Zähler-, Speicher- und Tagesspur-Lücken) gegen den Stand davor, bit für bit. ⭐ Damit es so bleibt, prüft ein neuer Wächter bei jedem Testlauf die Zugriffsform statt der Zahlen: Die Zahl der Abfragen über die Stundentabelle muss bei 12 und bei 24 Monaten gleich sein.

Fixed

Eine alte home-assistant_v2.db im Konfigurationsordner blockiert die Langzeitstatistik nicht mehr. eedc sucht die HA-Statistik in drei Stufen: eine selbst eingetragene Datenbank-Adresse, die Recorder-Datei im Konfigurationsordner, und — falls beides nicht greift — die Home-Assistant-Verbindung selbst. Stufe 2 prüfte nur, ob die Datei existiert. Wer seinen Recorder auf PostgreSQL/Timescale umgestellt hat und die alte SQLite-Datei liegen ließ, blieb damit auf einer Datei hängen, die eedc gar nicht lesen kann — und der Weg, der bei ihm funktioniert hätte, wurde nie versucht. Sichtbar war das als leere Langzeit-Kennzahlen bei einer Protokollzeile, die nur von einem Datenbankfehler sprach. Jetzt prüft eedc die Datei auf Lesbarkeit (eine echte Recorder-Tabelle, nicht bloß „lässt sich öffnen”) und weicht sonst auf die Home-Assistant-Verbindung aus; die Protokollmeldung nennt Datei, Fehler und den Handgriff. ⚠ Das fängt „nicht lesbar”, nicht „alt, aber lesbar” — wessen alte Datei sauber öffnet, bekommt weiterhin veraltete Zahlen und sollte sie nach einem Recorder-Wechsel entfernen. Ein automatisches Frische-Urteil wäre sein eigenes Risiko: Steht Home Assistant eine Nacht still, gälte eine intakte Datenbank plötzlich als veraltet.
Die Rückfrage vor „Energieprofil-Daten löschen” sagt jetzt, was wirklich verloren geht. Sie lautete „Der Scheduler berechnet sie neu (max. 15 Min). Monatsdaten bleiben erhalten.” — eine Beruhigung, die nicht trägt. Zwei Dinge kommen nicht zurück: die aufgezeichneten PV-Prognosen (Grundlage des Genauigkeits-Vergleichs; eine Vorhersage von damals kann niemand neu berechnen) und Messwerte, die weiter zurückliegen als deine HA-Langzeitstatistik — nach einem Recorder-Purge, einem Sensor-Umbau oder einer Neuinstallation reicht sie oft kürzer als dein gepflegtes Profil. Beides steht jetzt in der Rückfrage, in der Rückmeldung danach und im Handbuch. ⛔ An der Funktion selbst ändert sich nichts — sie wird bewusst genutzt und bleibt, wie sie ist; geändert ist nur, dass die Entscheidung informiert fällt.
Ohne E-Auto schreibt eedc keine Benzinpreise mehr in deine Daten. Der wöchentliche Abgleich mit dem EU-Oil-Bulletin füllte das Feld Kraftstoffpreis in Tages- und Monatszeilen jeder Anlage — auch dort, wo es gar kein E-Auto gibt. Der Daten-Checker hatte die Bedingung längst („kein E-Auto ⇒ keine Meldung”), die schreibende Seite nicht. Für Betroffene sichtbar wurde das als Quellen-Konflikt auf kraftstoffpreis_euro, wenn daneben ein eigener Wert stand: ein Hinweis auf ein Auto, das nie angelegt wurde. Beide Seiten benutzen jetzt dieselbe Regel — kein E-Auto, kein Benzinpreis; und erst ab dem Monat, in dem das älteste E-Auto dabei war. ⭐ Nebeneffekt: Für Anlagen ohne E-Auto wird die 4,25-MB-Preistabelle gar nicht mehr geladen. ⚠ Ein auf „inaktiv” gesetztes E-Auto zählt dabei nicht mehr mit — „inaktiv” heißt in eedc überall „wie gelöscht”. Bereits gefüllte Werte bleiben unberührt.

[4.0.45] - 2026-09-15 — Wärme und Klima zeigen, was deine Daten hergeben: wohin der Strom ging, wann und was er gekostet hat — und der Strom der Wärmepumpe wird voll gerechnet

Added

Neu im Wärme/Klima-Block: Verteilung & Verlauf — wohin der Strom gegangen ist, und was er gekostet hat. Der Block sagte bisher, wie viel Strom deine Wärme- und Klimageräte verbraucht haben und wann (der Verlauf). Was fehlte, war das Wofür. In Cockpit → Tag, Monat und Jahr steht jetzt darunter ein weiterer parkbarer Teil mit drei Bildern zu derselben Frage: die Anteile je Gerät und Funktion (Heizen · Warmwasser · Kühlen · Lüften · Entfeuchten und was keine davon erklärt), eine Tabelle Kosten je Funktion mit Herkunft, Arbeitspreis und Betrag, und derselbe Satz Segmente als Verlauf — je Stunde am Tag, je Tag im Monat, je Monat im Jahr, mit der Ø-Außentemperatur als Linie und, wo eedc den Wettercode kennt, einem Wettersymbol über der Zeitachse. ⭐ Jedes Gerät teilt auf dem Weg auf, den seine Zähler hergeben: getrennte Stromzähler ⇒ Heizen und Warmwasser als Summanden (ein gemessener Kühl-, Lüftungs- oder Entfeuchtungszähler steht daneben); sonst Betriebsart-Zähler oder Betriebsmodus-Sensor. Die Spalte Herkunft sagt je Zeile, ob die Menge gemessen oder abgeleitet ist. Zwei Geräte dürfen verschiedene Wege gehen — eine Wärmepumpe mit getrennten Zählern neben einer Klimaanlage mit Modus-Sensor ergibt ein Bild mit beiden. ⚠ Die zwei Restmengen heißen verschieden, und das ist wichtig: System/Standby ist echter Verbrauch, den dein Gesamtzähler mehr misst als deine Funktionszähler (Steuerung, Umwälzpumpen, Standby — bei einem Melder 145 von 2193 kWh im Jahr); Ohne Modus sind Stunden ohne Betriebsmodus-Signal. Sie werden nie addiert — ein Gerät trägt immer nur eine der beiden. ⭐ Die Kosten rechnen mit dem Tarif des jeweiligen Monats (Wärmepumpen-Sondertarif, wenn du einen hast): Eine Preiserhöhung im Juli schreibt den Januar nicht um; im Jahr steht der mengengewichtete Preis, sodass kWh × Preis den Betrag ergibt. ⛔ Es sind die Kosten des verbrauchten Stroms, nicht deines Netzbezugs — welche Kilowattstunde aus der PV kam, weiß eedc je Gerät nicht. ⭐ Das Wettersymbol ist der häufigste Code der Periode, nicht der schlechteste Moment: Ein Tag mit vierzehn Sonnenstunden und einem Schauer ist ein sonniger Tag. Fehlt der Code, fehlt das Symbol. ⚠ Drei Zeilen benennen, was das Bild nicht zeigen kann — „Aufgeteilte Menge X von Y” (ein Gerät ohne jede Aufteilung), „Im Verlauf erfasst X von Y” (der Verlauf kommt aus dem, was eedc täglich mitschreibt, die Anteile aus deiner Monatszeile) und „Strom ohne Stundenzuordnung”. Verteilt wird nichts davon; genannt schon.
Ein gemeinsamer Wärmemengenzähler hat jetzt sein eigenes Feld: Wärme gesamt. Viele Wärmepumpen machen Heizung und Warmwasser über denselben Kreis und messen die abgegebene Wärme mit einem Zähler. Bisher gab es dafür nur das Feld Heizwärme — die Gesamtwärme stand also unter einem Namen, der nur die Hälfte meint. Der neue Monatswert steht im Monatsabschluss unter den beiden Einzelwerten, auf der Datenquellen-Fläche als eigener Slot und in der CSV-Vorlage als eigene Spalte. Trägst du deinen Zählerwert dort ein, rechnet eedc Wärmemenge, Arbeitszahl, Ersparnis und CO₂ wie bisher — in Cockpit (Tag · Monat · Jahr), im Komponenten-Hub, in den HA-Sensoren, in Auswertungen → Aussichten samt ROI-Fortschritt und im Community-Vergleich dieselbe Zahl. Das gilt auch für die Zeile „Ersparnis vs. Alternative“ im T-Konto von Cockpit → Monat und für den laufenden Monat, dessen Werte noch aus Sensoren, MQTT oder Connector kommen. ⭐ Ein gepflegter Gesamtwert gilt vor den beiden Einzelwerten: Er ist die Wärme des Geräts, Heizwärme und Warmwasser-Wärme stehen dann nur noch als Aufteilung daneben. ⚠ Getrennte Arbeitszahlen für Heizen und Warmwasser gibt es dabei nicht — dafür bräuchte es zwei Wärmemengenzähler —, und eedc sagt das mit dem Grund „Wärme nicht je Funktion gemessen”, statt eine Zahl zu zeigen, die zwei verschiedene Dinge ins Verhältnis setzt. ⚠ Ohne getrennte Strommessung schlägt eedc den geschätzten Wert Strom × Arbeitszahl jetzt für Wärme gesamt vor statt für Heizwärme — inhaltlich war es immer schon die Gesamtwärme. ⛔ eedc verschiebt nichts von allein: Wer seine Summe bisher unter Heizwärme geführt hat, sieht exakt dieselben Zahlen wie bisher, bis er sie selbst umträgt. Wer zwei Wärmemengenzähler hat, ändert nichts.
„Leistung Kühlen” wird jetzt angezeigt — bisher war sie nur zuordenbar. Das Live-Feld Leistung Kühlen (W) gibt es seit v4.0.44 an jeder Wärmepumpe und Klimaanlage, und die Versionshinweise haben es damals als Live-Wert angekündigt. Ausgewertet hat es keine einzige Sicht. Jetzt läuft es denselben Weg wie Leistung Heizen und Leistung Warmwasser: In Cockpit → Live zählt es zur Leistung des Geräts und lässt das Symbol auf die Schneeflocke wechseln, sobald der Kühlbetrieb die stärkste Betriebsart ist; im Live-Tagesverlauf und im Stundenverlauf von Cockpit → Tag bekommt es eine eigene Fläche in der Farbe, die Kühlen in dieser Fläche schon überall trägt; im Betrieb ohne Home Assistant wird es alle 5 Minuten mitgeschrieben, damit die Kurve auch dort entsteht. ⛔ Es bleibt reine Anzeige: Aus diesem Feld entsteht keine Kilowattstunde und keine Arbeitszahl — Mengen kommen weiter aus den kWh-Zählern. ⚠ Und es wird von Leistung gesamt verdrängt wie seine beiden Nachbarn — die Datenquellen-Fläche sagt das jetzt auch an dieser Zeile.
Der Daten-Checker trägt die fehlende Ø Temperatur der Vergangenheit nach — aus deinen eigenen Messwerten. Das Feld „Ø Temperatur” im Monatsabschluss wird seit dem 13.09. wieder automatisch gefüllt; das wirkt aber nur nach vorn. Jeder Monat, der zwischen dem Oberflächen-Wechsel im Juli 2026 und dieser Reparatur abgeschlossen wurde, steht ohne Wert da — an der Demo-Anlage 34 von 34. Bisher hätte man jeden einzelnen Monat öffnen und „Wetterdaten holen” drücken müssen. Die neue Daten-Checker-Kategorie Wetterwerte – fehlende Monatswerte nennt beide Zahlen: wie viele Monate leer sind und für wie viele davon die eigene Temperatur-Messreihe zurückreicht. Der Knopf „Temperatur aus Messung übernehmen” trägt genau diese nach — Stundenmittel, sonst Tages-Min/Max. ⛔ Nur Lücken: Ein von Hand gepflegter Wert bleibt unberührt, ein zweiter Klick findet nichts mehr. ⛔ Und keinen Knopf für den Rest: Wo die Messreihe nicht zurückreicht, bliebe nur ein Abruf im Wetter-Archiv — einer je Monat. Das ist etwas, das du auslöst, wenn du den Monat vor dir hast, nicht etwas, das eedc im Hintergrund über drei Jahre laufen lässt; die Zeile sagt das ausdrücklich. ⚠ eedc rechnet mit dem Feld heute keine Kennzahl aus — die Außentemperatur-Linie und der Vergleich je Heizgradtag lesen die feinere Tagesreihe. Es ist die gepflegte Rückfallebene, wo diese Reihe fehlt; deshalb ist der Befund ein Hinweis und keine Warnung. Es ist die erste Daten-Checker-Kategorie für Wetterfelder.
Der Daten-Checker sagt jetzt, wenn der Kühlanteil geschätzt statt gemessen wird. Wer Heizung und Warmwasser getrennt misst und zusätzlich einen Betriebsmodus-Sensor zugeordnet hat, bekam unter Einstellungen → Daten nur die Auskunft „Betriebsmodus ist zugeordnet” — dass eedc den Kühlanteil daneben aus der Summe der beiden vorhandenen Zähler schätzt, stand nirgends. Der neue Hinweis sagt, was eedc rechnet, was es dabei voraussetzt (dass diese zwei Zähler den Kühlbetrieb nicht getrennt führen) und den einen Handgriff, der aus der Schätzung eine Messung macht: Strom Kühlbetrieb zuordnen. ⚠ Er erscheint nur, wo er etwas bewirkt — nicht ohne getrennte Strommessung, nicht ohne Betriebsmodus-Sensor, nicht ohne Kühlbetrieb und nicht, wenn der Kühlzähler schon zugeordnet ist. ⭐ Eine gemessene Kältemenge allein löst den Fall nicht auf: Sie ist kein Stromzähler, der Kühlstrom wird weiter geschätzt.
Wetternormierter Vergleich im Wärme/Klima-Hub: Strom je Heizgradtag über die Saison. Wie viel Strom eine Heizung braucht, hängt vor allem vom Wetter ab — ein milder Winter sieht in jeder Statistik nach einer besseren Anlage aus. Komponenten → Wärme/Klima → Vergleich trägt auf der Achse Saison deshalb eine dritte Kennzahl „kWh/Kd”: den Heizstrom geteilt durch die Heizgradtage des Fensters (je Tag max(0; 15 °C − Tagesmittel der Außentemperatur), über die Monate summiert). Damit lassen sich zwei Heizperioden vergleichen, unabhängig davon, wie kalt sie waren. ⭐ Die Außentemperatur kommt aus eedcs eigener Messreihe — Stundenwerte, ersatzweise Tages-Min/Max — ohne zusätzlichen Wetterabruf; über dem Diagramm steht ihre Herkunft samt Formel, im Tooltip die eingesetzten Werte („0,55 kWh/Kd · 603,9 kWh ÷ 1.089,6 Kd”). ⛔ Normiert wird ausschließlich der Heizbetrieb, und nur mit getrennt gemessenem Heizstrom. Warmwasser hängt nicht vom Wetter ab, der Gesamtstrom enthält es; wer keine getrennte Strommessung führt, sieht statt der Schaltfläche den Grund. ⛔ Und nur über eine Saison, nie je Monat: An derselben Maschine stünden November 0,531 gegen Mai 3,889 kWh/Kd — Faktor 7,3, der nichts über die Wärmepumpe sagt, weil Grundlast und Warmwasser-Beimischung nicht mit den Heizgradtagen skalieren; im Juni gibt es überhaupt keinen Nenner. ⚠ Ein Monat geht nur ein, wenn er Heizgradtage UND Heizstrom trägt — das Balken-Label nennt beide Anteile („25/26 (2/4 · Temp 2/4)”), unvollständige Saisons bleiben blass. ⚠ Ein von Hand gepflegter Monatsdurchschnitt zählt hier bewusst nicht: Er unterschätzt die Heizgradtage in Übergangsmonaten deutlich (an einer Beispielanlage 22,1 statt 30,1 Kd im Mai, −26,6 %), weil warme und kalte Tage sich darin wegmitteln. ⚑ Der zweite Balken kommt mit der nächsten Heizperiode — der Vergleich braucht zwei Winter mit Temperaturreihe; solange nur einer sie hat, steht daneben, ab wann die Messreihe reicht. Cockpit, HA-Export, PDF und Community sind unberührt.
Der Stundenverlauf in Cockpit → Tag trennt Heizen und Warmwasser, wenn die Wärmepumpe getrennte Leistungssensoren hat. Wer Leistung Heizen und Leistung Warmwasser zugeordnet hat und Leistung gesamt leer lässt, sah dieselbe Wärmepumpe in Cockpit → Live als zwei Flächen und einen Klick weiter im Stundenverlauf des Tages als eine graue — obwohl die Aufteilung in derselben Antwort danebenstand, mit fertigen Namen. Jetzt zeigt der Tag dieselben zwei Flächen wie das Live-Bild, in denselben zwei Farben (Heizen rot, Warmwasser blau) und unter denselben Namen. ⭐ Die Aufteilung ersetzt die Fläche, sie liegt nicht darauf: Die Höhe des Senken-Stapels bleibt auf die Kilowattstunde dieselbe wie vorher, die Energiebilanz der Stunde ändert sich nicht. Liegt zusätzlich ein kWh-Zähler am Gerät und weicht er vom Leistungspfad ab, steht die Differenz als eigene Fläche „Wärmepumpe (übrige)” da, statt still zu verschwinden — dieselbe Bauform wie „PV (übrige)” auf der Erzeugerseite. ⭐ Und die Höhe hält in beide Richtungen: Liegt der Zähler unter der Summe der beiden Leistungsreihen, teilt eedc den Zähler nach deren Form auf, statt den Stapel über die Gesamtmenge hinauswachsen zu lassen — der Zähler sagt, wie viel es war, die Leistungsreihen sagen, wie es sich verteilt. ⚠ Aufgeschlüsselt wird ab zwei Funktions-Reihen — bei nur einem zugeordneten Funktions-Sensor wäre die Funktionsreihe die Gerätereihe unter anderem Namen. ⚠ Wer keine getrennten Leistungssensoren hat — der Normalfall — sieht keinen Unterschied; die Stundenwerte-Tabelle daneben führt die Wärmepumpe unverändert als eine Spalte.
Der Wärme/Klima-Verlauf lässt sich zwischen nach Betriebsart und nach Funktion umschalten. Wer getrennte Stromzähler für Heizen und Warmwasser pflegt, konnte diese Aufteilung bisher nur als Tagessumme sehen — der Verlauf in Cockpit → Tag stapelte ausschließlich nach Betriebsart. Jetzt steht über dem Verlauf ein Umschalter, und die zweite Sicht zeigt je Stunde Heizen · Warmwasser · Übriger Strom. ⭐ Warum getrennt und nicht zusammen: Die Betriebsart-Zähler sind Ausschnitte des Stroms (der Rest heißt nicht aufgeteilt), die Funktions-Zähler sind Summanden (Heizen + Warmwasser + Übriger Strom = Gesamtstrom). Beides in einem Balken zu stapeln hieße, Ausschnitte zu Summanden zu addieren; deshalb zeigt eedc immer genau eine der beiden Familien, und der Titel über dem Verlauf nennt sie. ⭐ Ein Betriebsart-Zähler kann Warmwasser gar nicht abtrennen — eedc bietet Betriebsart-Zähler für Heizen, Kühlen, Lüften und Entfeuchten an, nicht für Warmwasser; bei einem solchen Gerät steckt der Warmwasser-Strom im Segment Heizen. Wer die Aufteilung nach Funktion sehen will, braucht die getrennten Zähler. ⚠ Die Stunde verteilt den Tag, sie rechnet ihn nicht neu: Die Stundenmengen folgen der gemessenen Form des jeweiligen Zählers, ihre Summe ist der Tageswert. Was sich keiner Stunde zuordnen lässt, steht unter dem Verlauf als „Strom je Funktion ohne Stundenzuordnung”, statt gleichmäßig verteilt zu werden. ⚠ Ohne Funktions-Zähler gibt es den Umschalter nicht — dann hat die zweite Sicht nichts zu sagen. Voreingestellt bleibt die gewohnte Sicht nach Betriebsart; die Linien für Wärme, Kälte und Außentemperatur stehen in beiden.
Die Datenquellen-Fläche sagt jetzt, wenn „Leistung gesamt” die Aufteilung verdrängt. Wer an einer Wärmepumpe sowohl Leistung gesamt als auch Leistung Heizen bzw. Leistung Warmwasser zuordnet, sah im Live-Tagesverlauf immer nur eine Fläche für das ganze Gerät — die getrennten Reihen entstehen nur ohne Gesamtleistung, und nirgends stand warum. An den betroffenen Feldern steht jetzt der Satz „Solange ‚Leistung gesamt’ zugeordnet ist, wertet eedc ‚Leistung Heizen’ und ‚Leistung Warmwasser’ im Verlauf nicht aus.” ⭐ Als Hinweis, nicht als Vorwurf (blau, kein Warnzeichen): Beide Zuordnungen sind richtig, es ist eine Wahl. ⛔ Und ohne Handlungsempfehlung — die Gesamtleistung ist auf einer frisch eingerichteten Anlage die einzige Quelle des Wärmepumpen-Anteils in der Verbrauchsprognose; ein Rat, sie zu entfernen, hätte den stillschweigend gekostet. ⚠ Der Hinweis erscheint nur bei echten Zuordnungen in Home Assistant, nicht durch automatisch vergebene MQTT-Standardquellen. Mengen, Kennzahlen und der Block Wärme/Klima sind nicht betroffen — die kommen aus den kWh-Zählern.
Der Wärme/Klima-Block ordnet seine Detail-Liste jetzt je Funktion — Heizen, Warmwasser, Kühlen. Bisher standen dort die Zeilen nach Größe: erst zwei Stromzeilen, dann drei Arbeitszahlen; die Wärme je Funktion stand nur in einem Balken darüber, die Kältemenge nirgends als Zahl. Jetzt steht je Funktion beisammen, woraus ihre Arbeitszahl entsteht: Strom Heizen · Heizwärme · Arbeitszahl · Heizen, dasselbe für Warmwasser, und für Kühlen Strom Kühlen · Kälte · Arbeitszahl · Kühlen — in Cockpit → Tag, Monat und Jahr. ⭐ Neu ist die Zeile „Kälte”: Wer einen Kältemengenzähler hat, sieht die abgegebene Kälte jetzt als Zahl, auch im Jahr (aus derselben Rechnung wie die Arbeitszahl, nicht aufaddiert). ⚠ Der Balken „Wärme-Aufteilung” ist entfallen — seine zwei Zahlen stehen jetzt in den Gruppen Heizen und Warmwasser. Der Balken der Betriebsart-Aufteilung bleibt: Er zeigt eine andere Größe (die Betriebsart „Heizen” enthält den Warmwasser-Strom, wenn Warmwasser keine eigene Betriebsart ist). Zeigt die Liste darüber einen getrennt gemessenen Strom, heißt er deshalb jetzt „Strom-Aufteilung nach Betriebsart”. ⚑ Eine Überschrift erscheint nur für Funktionen mit einer Menge — eine Split-Klimaanlage bekommt keine Gruppe „Warmwasser”, eine Heizungs-Wärmepumpe im Winter keine Gruppe „Kühlen”; ihre Gründe stehen wie bisher als einzelne Zeile. ⚑ Wer das Element geparkt hatte (früher Strom-Aufteilung, jetzt Je Funktion), dem bleibt es geparkt — es verbirgt jetzt auch Wärme und Kälte je Funktion.
Die Kälte hat im Wärme/Klima-Verlauf eine eigene Linie — in Tag, Monat und Jahr. Wer einen Kältemengenzähler zugeordnet hat (am Gerät oder je Innengerät), sieht die abgegebene Kälte jetzt neben der Wärme im selben Bild: je Stunde in Cockpit → Tag, je Tag in Cockpit → Monat, je Monat in Cockpit → Jahr. ⭐ Kälte ist keine Wärme: Sie hat eine eigene Farbe, liegt auf derselben kWh-Achse und fließt nie in die Wärme-Linie oder in eine Wärmesumme. Bei einer Multisplit-Anlage zählt eedc die Innengeräte zusammen; ist zusätzlich ein Zähler am ganzen Gerät zugeordnet, gilt dieser. Tage oder Monate ohne gemessene Kälte lassen die Linie aussetzen, statt sie auf 0 zu ziehen. ⚠ Ohne Kältemengenzähler — der Normalfall — ändert sich nichts.
Auch Cockpit → Tag hat jetzt den Wärme/Klima-Verlauf — je Stunde. Dieselbe Darstellung wie in Monat und Jahr, eine Auflösung feiner: der Strom der Wärmepumpe gestapelt nach Betriebsart (Heizen, Warmwasser, Kühlen, Lüften, Entfeuchten, nicht aufgeteilt), darüber die gemessene Wärme als Linie und auf der zweiten Achse die Außentemperatur der Stunde. So siehst du, wann am Tag geheizt, gekühlt oder Warmwasser gemacht wurde — und wie die Wärme dem Strom folgt. ⭐ Die Stunden ergeben genau die Aufteilung darunter: eedc verteilt die Tagesmenge jeder Betriebsart nach ihrer gemessenen Stundenform, statt die Stunden neu zu rechnen. Im Home-Assistant-Add-on ist das ohne jede Umrechnung der Zählerzuwachs selbst. ⚠ Kennzahlen gibt es je Stunde bewusst nicht — Wärme und Strom derselben Stunde gehören nicht zusammen (Aufheizen, Nachlauf, Abtauung); eine Arbeitszahl gibt es ab dem Tag. ⭐ Jedes Gerät bleibt in seinen eigenen Stunden — auch bei zwei Wärmepumpen verteilt eedc die Menge jedes Geräts nach dessen eigener Stundenform. ⚑ Lässt sich ein Teil der Tagesmenge keiner Stunde zuordnen (etwa weil ein Zähler nur in der letzten Stunde des Tages lief), wird er nicht gleichmäßig verteilt, sondern unter dem Verlauf genannt — je Größe als „Strom / Wärme / Kälte ohne Stundenzuordnung”, sodass Linie und genannter Rest zusammen die Tageskachel ergeben. ⚑ Tage vor dem 4. September tragen die Betriebsmodus-Stunden noch in der alten Stundenzuordnung (siehe #405); wer dort einen versetzten Stapel sieht, holt sie mit Einstellungen → Daten → Reparatur-Werkbank → „Mehrere Tage neu aggregieren” nach.
Die Arbeitszahl Kühlen gibt es jetzt auch am einzelnen Tag. Wer neben dem Kühlstrom einen Kältemengenzähler zugeordnet hat, sah sie bisher nur in Monat, Jahr und im Komponenten-Hub; Cockpit → Tag nannte an ihrer Stelle den Grund, dass die Kältemenge nur monatlich gezählt wird. Jetzt rechnet der Tag dieselbe Zahl wie der Monat — Kältemenge des Tages geteilt durch den Kühlstrom des Tages, beide im selben Zeitfenster. ⭐ Auch mit Zählern je Innengerät: Bei einer Multisplit-Anlage mit einem Kältemengenzähler je Innengerät zählt eedc deren Summe; ist zusätzlich ein Zähler am ganzen Gerät zugeordnet, gilt dieser — die Innengeräte sind dann die Aufteilung, nie ein Zuschlag. ⚠ Die Zahl erscheint nur, wenn Kälte und Kühlstrom von denselben Geräten stammen. Trägt an einem Tag ein Gerät Kälte bei, dessen Kühlstrom eedc diesem Tag nicht zuordnen kann, steht dort „Nutzenergie und Strom dieser Funktion stammen von verschiedenen Geräten” statt einer zu hohen Zahl. ⭐ Meldet der Kältemengenzähler an einem Tag null, obwohl Kühlstrom floss — etwa weil das Gerät im Kühlmodus stand und pausierte —, heißt es jetzt „keine Kälte abgegeben in diesem Zeitraum” statt, er sei nicht zugeordnet. ⚠ Wer keinen Kältemengenzähler hat — der Normalfall —, liest unverändert „kein Kältemengenzähler zugeordnet”, jetzt auch am Tag. Monats-, Jahres- und Hub-Werte ändern sich nicht.
Der Wärme/Klima-Block in Cockpit → Jahr hat einen Verlauf. Bisher standen dort Kacheln und Balken — beide sagen, wie viel übers Jahr zusammenkam, aber nicht wann. Der neue Block zeigt je Monat den Strom gestapelt nach Betriebsart (Heizen · Warmwasser · Kühlen · Lüften · Entfeuchten · nicht aufgeteilt) und darüber die gemessene Wärme als Linie. Jede Reihe lässt sich per Klick in die Legende ausblenden; die Reihenfolge im Block bleibt Kacheln → Verlauf → Aufteilung, die gewohnten Anzeigen stehen unverändert an ihrem Platz. ⭐ Die Wärmelinie ist der eigentliche Gewinn: Ein reiner Stromverlauf lässt sich in jedem Dashboard bauen — Strom und Wärme im selben Bild zeigen, ob ein Monat mit mehr Strom auch mehr Wärme gebracht hat. ⛔ Gezeigt wird ausschließlich gemessene Wärme. Wo eedc sie aus Strom × Arbeitszahl schätzt, bleibt die Linie an dieser Stelle unterbrochen: Eine geschätzte Wärme ist ein festes Vielfaches des Stroms und hätte exakt die Form der Fläche darunter — sie sähe aus wie eine zweite Messung und wäre keine. Die geschätzte Menge steht weiterhin in der Kachel, mit ihrer Herkunft daneben. ⚠ Der Stapel beschreibt nur die Geräte mit einer Aufteilung — steht darunter „Aufgeteilte Menge X von Y kWh”, gehört die Differenz zu Geräten ohne Betriebsart-Erkennung; die Kachel darüber zählt alle. Wer gar keine Aufteilung erfasst, sieht keinen Stapel statt einer Reihe von Nullen. ⭐ Dazu die Außentemperatur als zweite Linie (eigene Achse rechts, per Legende abwählbar): Ein kalter Monat braucht mehr Strom, ohne dass die Anlage schlechter arbeitet — erst mit dieser Linie ist ein Verbrauchsanstieg einzuordnen. Sie kommt aus eedcs eigenen Messreihen (stündliche Werte, sonst das Tages-Minimum/Maximum), nicht aus dem Feld Ø Temperatur im Monatsabschluss und ohne zusätzlichen Wetterabruf. Monate ohne Messreihe lassen die Linie aussetzen, statt sie auf 0 °C zu ziehen.
Auch Cockpit → Monat hat jetzt den Wärme/Klima-Verlauf — je Tag statt je Monat. Dieselbe Darstellung wie im Jahr, nur eine Auflösung feiner: Strom gestapelt nach Betriebsart, darüber die gemessene Wärme als Linie, dazu die Außentemperatur auf einer eigenen Achse. ⭐ Damit wird sichtbar, was eine Monatssumme verschweigt: an welchen Tagen die Anlage wirklich lief, wie sie auf einen Kälteeinbruch reagiert hat und ob ein hoher Verbrauch am Wetter lag oder nicht. Die Tages-Wärme kommt aus denselben Wärmemengenzählern, aus denen Cockpit → Tag rechnet — dieselbe Zahl an beiden Orten. ⛔ Auch hier nur gemessene Wärme: Tage ohne Wärmemengenzähler lassen die Linie aussetzen, statt eine geschätzte Kurve zu zeichnen, die nur die Form des Stromverbrauchs hätte. ⚠ Der Stapel beschreibt wie im Jahr nur die Geräte mit einer Aufteilung — steht darunter „Aufgeteilte Menge X von Y kWh”, gehört die Differenz zu Geräten ohne Betriebsart-Erkennung. Tage ohne jede Aufteilung fehlen im Stapel, statt als Nullbalken dazustehen. ⚡ Und er ist sparsam gebaut: Die Tageswerte entstehen aus einer Zählerreihe je Größe statt aus dreißig Einzelabfragen — der Block lädt neben der Sicht und hält sie nicht auf.
Ein Prüfer hält fest, dass jede abgeleitete Kennzahl ihre Rechnung zeigt (interne Qualitätssicherung, für dich unsichtbar). Die Regel gibt es seit dem Style-Guide — geprüft wurde sie nie, und so durfte jede neue Kachel sie brechen, ohne dass etwas auffiel. Der neue Prüfer liest den Quelltext und meldet jede Kennzahl, die eine Formel zeigt, ohne die eingesetzten Werte zu nennen; die begründeten Ausnahmen stehen einzeln aufgeführt und mit Begründung in einer Liste, die von selbst abschmilzt. Stand heute: 84 geprüfte Stellen, 26 begründete Ausnahmen, keine offene. ⭐ Der Gewinn liegt in der Zukunft — der Fall, der die Regel ausgelöst hat, war eine Arbeitszahl von 0,7, deren Ursache (ein falsch zugeordneter Zähler) mit den beiden Zahlen daneben in Sekunden zu sehen gewesen wäre.
Der Wärme/Klima-Block sagt jetzt auch, WO die fehlende Zahl steht. Bleibt eine Arbeitszahl gesperrt, weil sie mehrere Geräte vermischt, führt ein Link direkt zu Komponenten → Wärme/Klima — dort rechnet eedc je Gerät, und die Zahl steht da. ⛔ Der Link erscheint bewusst nicht bei jeder gesperrten Kennzahl: Wo der Komponenten-Hub aus demselben Grund schweigt — bei einer gemeldeten Abgrenzungs-Störung (Heizstab auf dem Zähler, zweiter Erzeuger am Wärmekreis), bei geschätzter Wärme oder bei fehlendem Zähler — führt er zu nichts und bleibt weg. Ein Weg, der im Nichts endet, ist schlechter als kein Weg.
Jedes Feld sagt jetzt, wo sein Wert erscheint. Unter Einstellungen → Datenquellen steht am Info-Symbol jedes Feldes eine Zeile „Ausgewertet in: Cockpit → Monat · Komponenten → Wärmepumpe” — also der Weg zu der Ansicht, in der dieser Sensor tatsächlich wirkt. Der Anlass ist eine Frage, die sich jeder stellt, der einen Zähler zuordnet und danach nichts findet: wofür habe ich den eigentlich zugeordnet? ⭐ Dahinter steht mehr als ein Satz: eedc führt jetzt eine vollständige Liste Feld → Auswertung, und ein Prüfer hält sie gegen die Felder, die die Fläche anbietet. Ein Feld ohne Auswertung fällt damit auf, bevor es ausgeliefert wird — genau so ist der Fehler unten gefunden worden. Die beiden heute bekannten Fälle (der Monatswert am Wechselrichter, der seit August bewusst nichts mehr tut, und der Tachostand, aus dem nur der km-Vorschlag entsteht) stehen namentlich mit Begründung in dieser Liste, statt still zu sein. Dieselbe Spalte findest du in der Sensor-Referenz.

Fixed

Im laufenden Monat stand ein Rat, dem die Tabelle direkt darüber widersprach. Wer Heizung und Warmwasser mit getrennten Stromzählern misst, las in Cockpit → Monat den ganzen Monat lang „Arbeitszahl Heizen · Arbeitszahl Warmwasser — Strom nicht getrennt je Funktion gemessen → Getrennte Strommessung einschalten und beide Zähler zuordnen” — während die Tabelle Zahlen je Gerät zwei Zeilen darüber genau diese beiden Arbeitszahlen zeigte. Der Grund: Die anlagenweiten Größen kamen ausschließlich aus der gespeicherten Monatszeile, und die entsteht erst mit dem Monatsabschluss — einen automatischen gibt es nicht, der laufende Monat hat also nie eine. Jetzt entstehen Heizwärme, Warmwasser-Wärme, Strom Heizen, Strom Warmwasser und das Kennzeichen getrennte Strommessung aus denselben Gerätewerten, aus denen die Tabelle und der Verlauf daneben schon gespeist werden: Arbeitszahl Heizen und Arbeitszahl Warmwasser stehen jetzt auch im laufenden Monat. ⚠ Bei mehreren Geräten kann trotzdem ein Grund stehen — und er ist der zutreffende: Kommen Wärme und Strom derselben Funktion von verschiedenen Geräten (eines misst seine Wärme mit einem gemeinsamen Zähler, ein anderes trennt seinen Strom nicht), gibt es anlagenweit keine gemeinsame Zahl; dort steht jetzt „Nutzenergie und Strom dieser Funktion stammen von verschiedenen Geräten” samt Weg in den Komponenten-Hub, der jedes Gerät für sich zeigt — statt eines Handgriffs, den man längst getan hat. Was du selbst gepflegt oder importiert hast, gewinnt unverändert. (Gemessen an der nachgestellten Prüfstand-Anlage, September 2026.)
In Cockpit → Tag standen zwei Arbeitszahlen, die Cockpit → Monat für dieselbe Anlage zurückhält. Wer mehrere Wärmepumpen hat, sah im Tag Arbeitszahl Heizen und Arbeitszahl Warmwasser ohne jeden Hinweis — auch dort, wo Wärme und Strom einer Funktion von verschiedenen Geräten stammen und die Zahl deshalb nichts bedeutet. Grund: Der Tag holte diese Prüfung aus der gespeicherten Monatszeile, und die gibt es im laufenden Monat nicht; sobald der Monat abgeschlossen war, sperrte dieselbe Sicht mit dem zutreffenden Satz. Jetzt prüft der Tag an seinen eigenen Gerätewerten — dieselbe Rechnung wie der Monat, eine Zeitebene tiefer. ⭐ Und eine Brauchwasser-Wärmepumpe blockiert dabei nichts mehr: Sie hat nur eine Funktion, ihr ganzer Strom ist Warmwasser-Strom — eedc rechnet ihn jetzt auch anlagenweit als solchen, sodass eine Anlage aus Wärmepumpe und Brauchwasser-WP ihre Arbeitszahl Warmwasser aus Wärme und Strom beider Geräte bekommt. ⚠ Für eine Klimaanlage gilt das nicht: Sie kühlt auch, ihr Strom gehört nicht ganz zum Heizen. ⭐ Im Kasten Was noch möglich wäre steht je Größe jetzt genau eine Auskunft — die mit dem Gerätenamen. Vorher standen dort zwei Zeilen für dieselbe Größe, und die allgemeinere empfahl einen Handgriff an einem Gerät, an dem es nichts zu tun gibt. (Gemessen an der nachgestellten Prüfstand-Anlage, 10.09.2026: Heizen 3,35 und Warmwasser 4,21 ohne Grund.)
Eine Arbeitszahl, die dein Gerät gar nicht haben kann — und eine, die direkt danebenstand. Im Block Wärme/Klima führte die Tabelle Zahlen je Gerät für jedes Gerät die Spalten Heizen und Warmwasser. An einer Brauchwasser-Wärmepumpe stand in beiden ein Strich mit dem Satz „Strom nicht getrennt je Funktion gemessen” — obwohl das Gerät gar nicht heizt und obwohl seine Arbeitszahl (3,31) zwei Spalten weiter links stand: Ihr ganzer Strom ist Warmwasser-Strom, ein getrennter Zähler könnte nichts anderes messen. An einer Split-Klimaanlage stand derselbe Satz für einen Warmwasserkreis, den sie nicht hat, und für Heizen nannte er die falsche Seite: Dort fehlt zuerst der Wärmemengenzähler, und getrennte Stromzähler brächten ohne ihn keine einzige Kennzahl. Jetzt gilt: Hat ein Gerät nur eine Wärme-Funktion, ist deren Arbeitszahl seine Gesamt-Arbeitszahl — die Brauchwasser-WP zeigt Warmwasser 3,31, die Klimaanlage nennt bei Heizen den fehlenden Wärmemengenzähler. Die Spalte der anderen Funktion bleibt leer, nicht „—”: Ein Strich heißt „hier fehlt etwas”, und an einer Achse, die es am Gerät nicht gibt, wäre das falsch. ⭐ Das gilt auch anlagenweit: Trägt an einem Tag nur eine Klimaanlage Strom bei, empfiehlt der Kasten Was noch möglich wäre nicht mehr „Getrennte Strommessung einschalten” für eine Warmwasser-Achse, die es an dieser Ausstattung nicht gibt. ⛔ Wo getrennte Zähler eine eigene Zahl hergeben, bleibt sie stehen — die Regel ersetzt einen Grund, nie eine Zahl; Geräte mit beiden Funktionen zeigen unverändert dieselben Werte.
Jeder Strich in der Tabelle sagt jetzt beim Überfahren, warum er dasteht. Im ganzen Block gab es kein einziges Erklärungsfeld an der Tabelle Zahlen je Gerät: Wärme, Arbeitszahl, Heizen, Warmwasser und Kühlen standen als „—” ohne jede Auskunft da, obwohl eedc den Grund je Zelle kennt. Und im Kasten Was noch möglich wäre fehlten die Gründe der einzelnen Geräte ganz — dass einer deiner Wärmepumpen der Wärmemengenzähler fehlt, stand nirgends im Block. Jetzt trägt jede Zelle ohne Zahl ihren Grund als Tooltip, und der Kasten nennt ihn zusätzlich mit dem Gerätenamen und dem Handgriff („Arbeitszahl · Bosch Climate 5000 Multisplit: kein Wärmemengenzähler zugeordnet → Wärmemengenzähler zuordnen”), ohne etwas zu wiederholen, was anlagenweit schon dasteht.
Die Kachel „Ersparnis vs. Alternative” stand in Cockpit → Tag immer als „—”. Ohne Betrag, ohne Untertitel, ohne Tooltip — an jedem Tag jeder Anlage mit Wärmepumpe. Grund: eedc rechnet die Ersparnis gegen die Altanlage monatsweise, weil deren Zusatzkosten Monatsgrößen sind; der Tag hat diese Zahl schlicht nicht. Die Kachel entfällt dort jetzt, statt einen Strich zu zeigen, hinter dem nichts steht. ⛔ Und ohne Kasten-Zeile: Der Kasten nennt Ausstattung, an der du etwas ändern kannst — hier fehlt kein Zähler. In Monat und Jahr steht die Ersparnis unverändert.
Der erste Tag nach einer Zuordnung und der heutige Tag blieben leer — und der Grund daneben stimmte nicht. Cockpit → Tag nannte eine Strommenge („Strom verbraucht 2 kWh”) und direkt daneben „Arbeitszahl — kein Stromverbrauch erfasst” sowie „Wärme erzeugt — für diesen Tag keine Zählerstände”, obwohl seit 11:30 Uhr Zählerstände mitgeschrieben wurden. Grund: Ein Tageswert entsteht aus zwei Randständen, und am ersten Tag fehlt der um 0 Uhr, am laufenden der um 24 Uhr. Jetzt misst eedc ab dem ersten bzw. bis zum letzten Stand des Tages und schreibt es unter die Strom-Kachel: „gemessen ab 11:30 Uhr” bzw. „gemessen bis 05:00 Uhr”. Damit erscheinen an beiden Tagen wieder die Zahlen je Gerät, die Arbeitszahl, die Aufteilung und die Verteilung. ⛔ Hochgerechnet wird nichts — die Zahl ist die Menge des gemessenen Zeitraums, deshalb steht die Uhrzeit daneben. ⛔ Ein zurückgesprungener Zähler bekommt den Rückfall nicht: Dort bleibt es bei „keine Aussage”, statt aus einer abgelehnten Zahl eine kleinere, ebenso falsche zu machen. ⛔ Und liegt an einem Tag gar kein Stand vor, bleibt der bisherige Satz — dann gibt es wirklich nichts zu messen. ⭐ Dieselbe Auflösung schließt eine zweite Lücke: Ein zugeordneter Gesamt-Stromzähler, der an diesem Tag nichts liefert, ließ die gemessenen Zähler für Heizen und Warmwasser daneben nicht tragen — jetzt tragen sie, wie es der Monat seit jeher tut.
„Kein Stromverbrauch erfasst” stand neben einer Strommenge. Der Satz ist eine Aussage über das Gerät und war falsch, sobald ein Stromzähler zugeordnet war und nur an diesem Tag nichts hergab. Er nennt jetzt die tatsächliche Lücke („für diesen Tag keine Zählerstände” samt dem Weg zur Reparatur-Werkbank). An der Demo-Anlage nachgemessen: am 05.12.2025 stand dort „Strom verbraucht 10,3 kWh” neben dem alten Satz. ⛔ Ist gar kein Stromzähler zugeordnet, bleibt der alte Satz — mit seinem Handgriff „Stromzähler zuordnen oder den Monatswert pflegen”.
Wer nur Betriebsart-Zähler zuordnet, bekam gar keinen Strom. An einer Split-Klimaanlage mit Zählern je Betriebsart (Heizen · Kühlen · Lüften · Entfeuchten), aber ohne Gesamtzähler und ohne getrennte Funktionszähler, rechnete eedc 0 kWh — keine Kosten, kein CO₂, keine Kennzahl, kein Tageswert, während die Datenquellen-Fläche daneben „ausgewertet in …” behauptete. Jetzt gilt auch dort der Satz des Erfassungs-Kanons: ein Zähler, der misst, ist die einzige Messung, die es gibt. Die Menge des Geräts ist die Summe seiner gemessenen Betriebsart-Ströme — im Monat, im Tag, in der Stunde, in der Reload-Vorschau und im laufenden Monat. ⛔ Ein Gesamtzähler bleibt die Menge, und eine gepflegte Achse Strom Heizen/Warmwasser schlägt die Teilmenge — die Reihenfolge ist unverändert. ⭐ Und ein gemessener Kühl-, Lüftungs- oder Entfeuchtungszähler zählt am Tag jetzt neben den Funktionszählern mit, wie im Monat seit je: an der Prüfstand-Anlage waren das 0,9 statt 5,4 kWh an einem Kühltag.
Die am Gerät gemessene Heizwärme fehlte im Tag. Wer seine abgegebene Wärme unter Nutzenergie Heizbetrieb zuordnet, sah sie in Cockpit → Monat und im Jahr — im Tag stand „kein Wärmemengenzähler zugeordnet”, obwohl er zugeordnet war. Der Tag liest jetzt dieselbe Weiche wie der Monat (Wärmemengenzähler schlägt Betriebsart-Wärme, nie addiert), und der Daten-Checker liest sie ebenfalls — bis dahin prüfte er eine andere Heizwärme, als die Anzeige zeigte.
Eine gemessene Wärme, die nirgends ankam — Nutzenergie Heizbetrieb. Wer an einer Split-Klimaanlage die abgegebene Wärme je Innengerät misst und unter Nutzenergie Heizbetrieb zuordnet, sah im Komponenten-Hub Heizwärme 0 und darunter den Grund „kein Wärmemengenzähler zugeordnet” — ein Satz, der nicht nur nichts half, sondern falsch war: Der Zähler war zugeordnet, eedc hat ihn nur nie gelesen. Jetzt trägt er die Wärme: Fehlt am Gerät ein eigener Wärmemengenzähler (Heizwärme bzw. Wärme gesamt), gilt die Summe der gemessenen Nutzenergie Heizbetrieb — in Cockpit → Monat und Jahr, im Komponenten-Hub, in Ersparnis, CO₂ und den HA-Sensoren. ⭐ Mehrere Innengeräte werden summiert, ein Wert am Gerät schlägt die Summe seiner Innengeräte und wird nie dazuaddiert. ⛔ Ein Gerätezähler gewinnt weiterhin — er misst mehr als eine einzelne Betriebsart; und eine gepflegte 0 bleibt eine Messung („diesen Monat nicht geheizt”). ⛔ Nichts ändert sich für Anlagen, die dieses Feld nicht pflegen — an beiden Demo-Datensätzen nachgemessen.
Und dasselbe für Nutzenergie Lüften und Nutzenergie Entfeuchten, die es ebenfalls nirgends gab. Sie stehen jetzt als eigene Mengenzeile neben Strom Lüften / Strom Entfeuchten — im Komponenten-Hub und im Wärme/Klima-Block von Cockpit → Monat/Jahr, und nur dann, wenn ein Zähler etwas gemeldet hat. ⛔ Eine Kennzahl bekommen sie weiterhin nicht und sie zählen in keine Wärmesumme: Lüften und Entfeuchten erzeugen keinen Nutzen, den eedc bewerten könnte — daran ändert ein Zähler nichts. Was sich ändert, ist nur, dass die Zahl jetzt irgendwo steht.
Der laufende Monat blieb leer, obwohl die Tageswerte danebenstanden — und sagte nicht warum. Zwei Lagen, ein Bild. (1) Wer eedc mitten im Monat einrichtet und seine Zählerstände per MQTT schickt, hatte für den Monatsersten keinen Stand — und eedc bildet eine Monatsmenge als Differenz zweier Stände. Ergebnis: Cockpit → Monat blieb bis zum 1. des Folgemonats leer. Jetzt misst eedc ab dem ersten Stand, den es für diesen Monat hat, und schreibt den Zeitraum ans Quellen-Etikett: „MQTT (14.–30.09.)”. ⛔ Hochgerechnet wird nichts — die Zahl ist, was seit diesem Zeitpunkt wirklich gelaufen ist. ⛔ Und der Monatsabschluss bekommt diesen Rückfall ausdrücklich nicht: Dort würde eine Teilmonats-Menge als Monatswert gespeichert und sähe später wie eine Messung aus. ⛔ Ein zurückgesprungener Zähler bleibt abgelehnt — der Rückfall greift nur beim fehlenden Rand, nie bei einem Reset. (2) Wer weder HA-Statistik noch Connector noch eine MQTT-Zählerreihe hat, sah dort gar nichts — obwohl eedc die Tageswerte jede Stunde mitschreibt und der Verlauf daneben dieselben Tage vollständig zeichnete. Sie sind jetzt die fünfte Quelle des laufenden Monats: Sie füllt nur, was Monatsabschluss, HA-Statistik, Connector und MQTT nicht beantworten, verdrängt nie einen gepflegten oder gemessenen Wert und nennt sich am Quellen-Etikett „Tageswerte”. Beginnt die Tages-Aufzeichnung erst mitten im Monat, steht auch dort der Zeitraum daneben. ⭐ Das gilt auch für den Block Wärme/Klima — Strom, Wärme, Kälte, Arbeitszahlen und die Tabelle Zahlen je Gerät kommen aus demselben Leser, aus dem der Verlauf darunter seine Tage zeichnet; genau dieses Nebeneinander (Verlauf voll, Kacheln leer) war der Auslöser, und zwei Quellen hätten daraus zwei Zahlen gemacht. ⚠ Ohne zugeordneten Wärmemengenzähler bleibt die Wärme leer — und damit die Arbeitszahl: eine Arbeitszahl aus gemessenem Strom und fehlender Wärme wäre keine halbe Auskunft, sondern eine falsche. ⚠ Nur im laufenden Monat: In einem abgeschlossenen wäre eine Summe über einen Teil der Tage eine stille Untertreibung; dort ist der Monatsabschluss der Weg, und der Daten-Checker zeigt ohnehin darauf. (3) Und bleibt eine Kachel danach immer noch leer, nennt sie ihren Grund: Fahr über das „—”, und dort steht, ob für diesen Monat noch überhaupt nichts vorliegt oder ob nur dieser einen Größe die Zuordnung fehlt — samt dem Weg dorthin. Bisher stand daneben nichts.
Eine zu hohe Arbeitszahl Heizen bei einem gemeinsamen Wärmemengenzähler. Wer Heizung und Warmwasser über einen Wärmemengenzähler misst und den Strom getrennt zählt, bekam die ganze Wärme durch den Heizstrom allein geteilt: an einer nachgestellten Anlage 5,0 statt 3,0 — in Cockpit → Tag, Monat und Jahr und im Komponenten-Hub, ohne jeden Hinweis. Die Zahl sah dabei gut und plausibel aus, was sie besonders teuer machte; das Handbuch versprach für diesen Fall sogar ausdrücklich, dass es keine getrennten Arbeitszahlen gibt. Jetzt steht dort der Grund „Wärme nicht je Funktion gemessen” — sobald der Wert unter dem neuen Feld Wärme gesamt steht (siehe oben). ⭐ Die Mengen waren nie betroffen: Wärmemenge, Gesamt-Arbeitszahl, Ersparnis und CO₂ stimmten und stimmen. ⭐ Und Arbeitszahl Warmwasser nannte einen falschen Grund — „kein Wärmemengenzähler zugeordnet”, obwohl der Zähler zugeordnet ist und nur beide Funktionen misst; wer dem Satz folgte, suchte einen Zuordnungsfehler, den es nicht gab. ⚠ Wer den Wärmemengenzähler nur auf dem Heizkreis hat, behält seine Arbeitszahl Heizen — sie ist dort richtig; deshalb entscheidet dein Eintrag und keine Vermutung von eedc. ⚑ Der Daten-Checker meldet neu, wenn die Gesamtwärme eines Monats kleiner ist als Heizwärme und Warmwasser-Wärme zusammen — dann meint einer der Werte etwas anderes als gedacht, und die Differenz verschwände sonst lautlos aus allen Zahlen.
Der Hinweis „Alter Gesamt-Stromverbrauch-Sensor … obsolet” ist ersatzlos entfallen. Er riet dazu, einen Zähler zu entfernen, der seit dieser Version die Menge trägt (siehe Changed) — und er hatte schon vorher ein zweites Problem: Er versprach, der Eintrag werde „beim nächsten Speichern automatisch” entfernt. Das tat seit der Datenquellen-Fläche nichts mehr; der Satz stammte aus der Zeit des Zuordnungs-Assistenten. Eine Meldung ohne Defekt ist eine Falschmeldung. An ihre Stelle treten zwei Prüfungen, die etwas sagen: die Warnung „Gesamtzähler kleiner als die Summe der Achsen” und die Frage „Der Gesamtzähler misst deutlich mehr als die Achsen — misst er nur die Wärmepumpe?”.
Eine Wärmepumpe, die nur den Kühlstrom misst, verschwand aus dem Live-Bild. Wer als einzigen Leistungssensor Leistung Kühlen zugeordnet hatte, sah sein Gerät in Cockpit → Live gar nicht und im Tagesverlauf darunter den Satz „Nicht dargestellt (kein HA-Leistungssensor)” — obwohl einer zugeordnet war. Wer alle drei Betriebsarten misst, sah das Gerät im Kühlbetrieb mit 0,0 kW, während es lief: Die Summe kannte nur Heizen und Warmwasser. Beides ist behoben.
Ein zugeordneter Gesamtzähler zählt auch bei getrennter Strommessung — in jeder Sicht. Wer den Schalter „Getrennte Strommessung” an einer Wärmepumpe gesetzt hat, ohne (oder ohne beide) getrennten Zähler zu pflegen, sah für dieses Gerät in Cockpit → Monat/Jahr, im Komponenten-Hub, in Kosten, CO₂, PDF, Community und in den Home-Assistant-Sensoren 0 kWh — oder, mit einer gepflegten Seite, nur die Hälfte. Und das, obwohl der Gesamtwert im Monatsabschluss sichtbar danebenstand und Cockpit → Tag ihn seit v4.0.29 zählte. An einer nachgestellten Anlage wies dieselbe Wärmepumpe deshalb eine Arbeitszahl von 5,0 statt 3,0 aus — hoch genug, um zu gefallen, niedrig genug, dass kein Plausibilitäts-Prüfer anschlug. Neu gilt in allen Sichten dieselbe Vorrangkette wie im Tagespfad — und sie ist im selben Release noch einmal geschärft worden (siehe Changed): Gesamtzähler vorhanden ⇒ er ist die Menge, sonst tragen die getrennten Werte. Wer den Schalter nach Monaten mit Gesamtzähler umgelegt hatte, bekommt seine Historie zurück — ohne Neuberechnung. ⚠ Die getrennten Arbeitszahlen bleiben ohne getrennte Zähler weiterhin gesperrt, und der Daten-Checker mahnt jede fehlende Seite unverändert an.
Auch der Stundenverlauf zählt den Gesamtzähler wieder. Derselbe Tag zeigte in der Tageskachel den vollen Wärmepumpen-Verbrauch und im Stundenverlauf von Cockpit → Tag und Energieprofil eine leere Wärmepumpen-Spalte, sobald der Schalter gesetzt und ein getrennter Zähler noch nicht zugeordnet war. Tag, Stunde und Monat nennen jetzt dieselbe Menge.
Im laufenden Monat wurde der Wärmepumpen-Strom bei getrennter Messung doppelt gezählt. Solange für den Monat noch keine abgeschlossene Zeile existiert und die Werte aus Sensoren, MQTT oder Connector kommen, wurden Stromverbrauch, Strom Heizen und Strom Warmwasser schlicht addiert — der Gesamtzähler und die Aufteilung, die ihn ersetzt. An einer nachgestellten Anlage (Gesamt 1.000 kWh, Heizen 600, Warmwasser 400) wies Cockpit → Monat deshalb den ganzen Monat lang 2.000 kWh statt 1.000 aus und eine Arbeitszahl von 1,5 statt 3,0 — die Anlage sah halb so gut aus, wie sie ist. Mit dem Monatsabschluss stimmte die Zahl dann von selbst wieder, weil der abgeschlossene Monat die Vorrangkette schon kannte. ⚠ Der Schalter „Getrennte Strommessung“ schützte nicht davor: Auch ohne ihn wurden alle drei Felder addiert, obwohl die getrennten Werte dann gar keine Summanden sind. Jetzt gilt auch hier dieselbe Kette wie überall — Gesamtzähler ⇒ er ist die Menge, sonst tragen die getrennten Werte —, und sie fällt je Gerät, nicht auf der Anlagensumme.
Der Kühlanteil wird auch dann aus der Arbeitszahl gerechnet, wenn das Gerät auf getrennte Strommessung gestellt ist. Bei einem aus dem Betriebsmodus abgeleiteten Kühlanteil hing der Abzug am Schalter statt daran, welche Menge im Nenner steht: Zählt dort der Gesamtzähler, steckt der Kühlstrom darin und gehört abgezogen. Dieselbe Anlage mit denselben Zählern zeigte mit gesetztem Schalter 3,0 statt 3,75. Betrifft Tages- und Monatswert; bei vollständig getrennt gemessenem Strom bleibt es unverändert dabei, dass eine abgeleitete Aufteilung den gemessenen Nenner nicht kürzt.
Die Zuordnungs-Fläche erklärt kein Feld mehr für erledigt, das ein anderes Gerät betrifft — und bei getrennter Strommessung keines der beiden Stromfelder. Zwei Defekte, eine Ursache: Einstellungen → Datenquellen fragte nur, ob ein Feld einer Alternativ-Gruppe belegt ist, nicht an welchem Gerät. (1) Wer Heizstrom und Warmwasserstrom getrennt misst und erst einen der beiden Zähler zugeordnet hat, las am zweiten „Der WP-Stromverbrauch ist bereits zugeordnet — hier ist nichts einzutragen” — während Einstellungen → Daten für dasselbe Feld eine unvollständige Zähler-Abdeckung meldete. Dieselbe Anlage, zwei Flächen, gegenteilige Aussage. Bei getrennter Messung sind die beiden Stromfelder Summanden, keine Alternativen: erst zusammen ergeben sie den Verbrauch. (2) Bei zwei Geräten desselben Typs schaltete ein zugeordnetes Feld am ersten Gerät die leeren Felder am zweiten ab — dessen Lücke konnte gar nicht erscheinen. Betrifft zwei Wärmepumpen ebenso wie zwei PV-Strings (Ertragssensor am Westdach, Ostdach ohne). ⭐ Gebaut ohne Sonderregel: Die Feld-Registry weiß bereits, welche Felder ein einzelnes Gerät liefern muss — dieselbe Auskunft, die der Abdeckungs-Check liest. Ein Feld, das an diesem Gerät Pflicht ist, wird nicht mehr verdrängt; eines, das die Registry zurückstuft (der Gesamtstrom-Zähler bei getrennter Messung), weiterhin schon. ⛔ Die Anlagen-Ebene deckt unverändert in beide Richtungen — Anlagen-Zählerstand gegen Komponenten-Zähler ist eine echte Alternative und bleibt eine. ⚑ Folge im Daten-Checker: Der Hinweis „Strom Warmwasser fehlt in n Monat(en)” nennt jetzt neben dem Monatsabschluss auch die Zuordnung — er hatte sie bewusst verschwiegen, solange sie ins Leere führte.
Der Quellen-Stapel im Stundenverlauf wächst nicht mehr über die Erzeugungslinie hinaus. Wer seine PV-Strings einzeln misst, sieht in Cockpit → Tag die PV-Fläche in ihre Geräte aufgeteilt; was kein Gerät abdeckt, steht als „PV (übrige)” daneben. Diese Restfläche kann aber nicht kleiner als null werden — und in Stunden, in denen die String-Sensoren zusammen mehr melden als der Anlagenzähler hergibt, hielt sie die Stapelhöhe deshalb nicht: Der Stapel stand höher als die Gesamterzeugungs-Linie darüber. Jetzt gilt hier dieselbe Regel wie seit dem 12.09. auf der Verbrauchsseite: Der Zähler sagt, wie viel es war, die Leistungsreihen sagen, wie es sich verteilt — liegt ihre Summe darüber, werden die String-Flächen proportional auf die gemessene Anlagen-PV gestaucht. In der Gegenrichtung wird nichts gestreckt; was die Strings nicht erklären, bleibt „PV (übrige)”. ⭐ Das Größenverhältnis der Strings bleibt dabei erhalten — es kommt aus der Messung; gestaucht wird nur die Höhe, verteilt wird nichts. ⚠ Sichtbar ist das nur für Anlagen mit String-Sensoren UND einem Anlagen-PV-Zähler, und nur in den Stunden, in denen beide Pfade auseinanderlaufen; die Energiebilanz der Stunde war und bleibt unberührt.
In Cockpit → Tag, Monat und Jahr konnten beim Blättern für einen Moment ZWEI Perioden im selben Bild stehen. Die Tages-Sicht lädt ihre Zahlen aus zwei Abrufen: die Kacheln, die Bilanz und die Stunden im einen, den Wärme/Klima-Verlauf im anderen. Beide starten beim Tageswechsel gleichzeitig, kommen aber nicht gleichzeitig an — und der Verlauf ist der schnellere. Für die Dauer eines Ladevorgangs stand deshalb der Verlauf des neuen Tages unter den Kacheln des alten, im selben Block, ohne jedes Kennzeichen. ⭐ Jetzt gilt eine Regel für beide Abrufe: die Sicht zeigt immer genau einen Tag. Ein Verlauf erscheint nur zu den Kacheln, zu denen er gehört; solange die Zahlen des gewählten Tages laden, bleibt der bisherige Tag vollständig stehen — mit seinem Verlauf, statt mit einer Lücke an dessen Stelle. Sobald die neuen Zahlen da sind, wechselt die Sicht auf einmal. ⭐ Und die Überschrift lügt nicht mehr mit: Bisher sprang das Datum sofort auf den neuen Tag, während die Zahlen darunter noch dem alten gehörten. Jetzt nennt sie den Tag, zu dem die Zahlen gehören, und daneben steht „lädt 12.06.2026 …” für den, auf den umgestellt wird — dasselbe gilt für den Badge heute/abgeschlossen, den Wochentag der Bilanz und das Datum über den Stundenwerten. ⭐ Dieselbe Regel gilt jetzt in allen drei Zeit-Sichten. In Cockpit → Monat betraf es die Auswertungs-Blöcke samt Performance-Ratio-Kachel, den Wärme/Klima-Verlauf, den Vormonats- und Ø-Vergleich und den Monatsnamen in der Bilanz; in Cockpit → Jahr die CO₂-Kurve, die Monatsbalken und die Vorjahres-Vergleiche — dort sogar ohne jede Ladezeit, weil sie aus einer immer geladenen Liste entstehen und deshalb sofort auf das neue Jahr sprangen. ⭐ Auch die Zählerstände gehören zur angezeigten Periode: Der Block zeigt lieber nichts als den Stand eines anderen Zeitraums. ⚠ Es ändert sich keine Zahl — nur, welche Zahlen gleichzeitig zu sehen sind. Auswahl, Zeitstrahl und Stepper reagieren unverändert sofort auf den Klick.
Das Monatsformular füllt die Ø Temperatur wieder — und holt sie zuerst aus deinen eigenen Messwerten. Der Feld-Hinweis versprach seit v4.0.0 wörtlich „Wird automatisch von Open-Meteo geholt”, der Knopf Auto-Fill füllte aber nur Globalstrahlung und Sonnenstunden; das Feld Ø Temperatur blieb leer, und wer dem Hinweis glaubte, hatte am Ende jeden Monat ohne Wert. Der Auto-Fill setzt es jetzt wieder — bevorzugt aus den gemessenen Außentemperaturen des Monats (stündliche Werte, ersatzweise das Tages-Minimum/Maximum), und erst wenn davon nichts vorliegt, aus dem Archiv von Open-Meteo bzw. Bright Sky. Welche der beiden Quellen es war, steht unter dem Knopf. ⭐ Die eigene Messreihe zuerst, weil sie am Standort der Anlage gemessen wurde — nicht an der nächstgelegenen Wetterstation; sie ist außerdem die einzige Quelle für den laufenden Monat, für den das Archiv grundsätzlich nichts liefert. ⛔ Ein selbst eingetragener Wert wird nicht überschrieben — und das gilt jetzt für alle drei Wetterfelder. Globalstrahlung und Sonnenstunden ersetzten bisher auch eine getippte Zahl; der Feld-Hinweis der Globalstrahlung versprach dabei schon immer das Gegenteil („…, wenn nicht manuell gepflegt”). Jetzt füllt der Auto-Fill überall nur Lücken, und unter dem Knopf steht in einem Satz, was übernommen wurde und was stehen blieb. Wer einen Wert doch ersetzen will, leert das Feld und klickt erneut. ⭐ Und der Quellen-Hinweis nennt Bright Sky beim Namen: Bisher las eine deutsche Anlage dort „Geschätzte Durchschnittswerte”, obwohl der DWD misst und Bright Sky für sie die Voreinstellung ist — jetzt steht dort „Messwerte des DWD (Bright Sky)”. ⛔ Bestehende Monate füllt eedc nicht nachträglich — der Auto-Fill wirkt beim Erfassen bzw. Bearbeiten eines Monats. ⚠ Der wetternormierte Vergleich (kWh/Kd) ändert sich dadurch nicht: Er liest die Tagesreihe direkt und nimmt den Monatsdurchschnitt aus diesem Feld weiterhin nicht als Quelle — ein Monatsmittel unterschätzt die Heizgradtage in Übergangsmonaten.
Der Daten-Checker schwieg, wenn bei getrennter Strommessung nur EINE der zwei Stromseiten fehlte — und stellte dem Monat sogar „Monatsdaten vollständig“ aus. Wer Strom Heizen und Strom Warmwasser getrennt misst, bekam eine Warnung nur, wenn beide Felder eines Monats leer waren. Fehlte nur eine Seite, während die zugehörige Wärme erfasst ist — Sensor-Ausfall, spät zugeordneter Zähler, Handeintrag ohne das zweite Feld —, sagte der Daten-Checker nichts dazu; als einziger Befund stand dort die OK-Zeile „Monatsdaten vollständig“. ⚠ Die Folge steht in der Gesamt-Arbeitszahl: eedc bildet jede Arbeitszahl aus abgegebener Wärme ÷ eingesetztem Strom. Die Zeile der betroffenen Funktion sperrt korrekt mit „kein Stromverbrauch erfasst“, die Gesamt-Zahl kann das nicht — sie rechnet die Wärme beider Seiten über den Strom einer. An einem nachgestellten Monat (Heizwärme 1800 kWh + Heizstrom 600 kWh + Warmwasser-Wärme 600 kWh, Warmwasser-Strom fehlt) stand dort 4,0 ohne jeden Grund daneben; der Plausibilitäts-Hinweis greift erst ab 7,0. Jetzt meldet der Checker jede fehlende Seite einzeln — „Strom Heizen fehlt in n Monat(en)“ bzw. „Strom Warmwasser fehlt in n Monat(en)“ —, nennt die Monate, die Folge und den Handgriff (Wert im Monatsabschluss nachtragen). ⛔ Es ändert sich keine Zahl — gesperrt wird nichts, der Checker sagt nur, was er vorher verschwieg. ⛔ Fehlen beide Seiten, bleibt es bei der EINEN gewohnten Meldung „Strom Heizen/Warmwasser fehlt“; ein Sachverhalt, eine Zeile. ⚠ Ein Monat ohne Betrieb ist keine Lücke: Ohne Warmwasser-Wärme wird kein Warmwasser-Strom angemahnt, ohne Heizwärme kein Heizstrom — sonst stünden an jeder reinen Heiz-Anlage zwölf Warmwasser-Lücken im Jahr und an jeder Anlage jeden Sommer eine Heiz-Lücke. ⚠ Eine Split-Klimaanlage bekommt weiterhin keine Warmwasser-Meldung — den Kreis gibt es dort nicht.
Die Arbeitszahl zog einen Kühlanteil ab, den ihr Nenner nie enthielt — betroffen ist, wer Heizung und Warmwasser getrennt misst und dazu einen Betriebsmodus-Sensor hat, aber keinen Zähler für den Kühlbetrieb. In dieser Ausstattung teilt eedc den gemessenen Gesamtstrom aus dem Betriebsmodus auf; der so entstandene Kühlanteil ist ein Ausschnitt aus den beiden vorhandenen Zählern, keine Menge daneben. Trotzdem wurde er vom Nenner abgezogen — die Gesamt-Arbeitszahl (Cockpit → Tag/Monat/Jahr, Komponenten → Wärme/Klima, Auswertungen → Tabelle und der HA-Sensor) fiel dadurch zu gut aus. ⚠ Die Zahl sinkt jetzt. An der Beispielanlage des Handbuchs (3000 kWh Heizwärme auf 750 kWh Strom, 600 auf 200, geschätzter Kühlanteil 100 kWh) stand dort 4,24; richtig sind 3,79 — rund 12 %. Genau diese 3,79 zeigt dieselbe Anlage, wenn sie statt des Betriebsmodus-Sensors einen Kühlzähler hat: Bis hierher machte der Erfassungsweg die Kennzahl besser, und das ist der eigentliche Fehler. ⭐ Ein Sommermonat bekommt seine Zahl zurück: Steht das Gerät den Monat über auf Kühlen, fiel bis hierher der ganze Strom aus dem Nenner, und im Block stand „nur Kühlbetrieb in diesem Zeitraum” — direkt neben einer Arbeitszahl Warmwasser, die aus derselben Zeile stammte. ⛔ Mengen, Kosten, CO₂ und Aufteilung ändern sich nicht — die Betriebsart-Balken zeigen den Kühlanteil unverändert; es ändert sich allein der Nenner einer Kennzahl. ⛔ Die Arbeitszahlen für Heizen und Warmwasser sind unberührt: Sie stehen auf den gemessenen Zählern, dort wurde nie etwas abgezogen. ⚠ Nicht betroffen: wer einen eigenen Kühlzähler führt (dessen Strom ist im Verbrauch enthalten und wird weiterhin abgezogen) und wer keine getrennte Strommessung hat (dort ist der Kühlbetrieb im Gesamtzähler enthalten). ⭐ Der Community-Vergleich zieht mit — er bildet seine Kennzahl selbst, bekommt aber jetzt den fertigen Abzug statt einer Menge, aus der er einen bilden müsste. Wirksam mit dem Update des Vergleichsservers; für bereits geteilte Monate beim nächsten vollständigen Teilen. Im selben Zug geschlossen: Wer Lüften oder Entfeuchten getrennt misst, sah dort bisher eine etwas niedrigere Arbeitszahl als im eigenen Cockpit — der Server kannte nur den Kühlstrom.
Der Plausibilitäts-Hinweis „Arbeitszahl höher, als eine Wärmepumpe leisten kann” sah getrennt messende Anlagen nie. Er las den Stromverbrauch ohne die Geräte-Angaben und damit immer aus dem Gesamtzähler-Feld — bei getrennter Messung steht dort nichts, der Strom liegt in Strom Heizen und Strom Warmwasser. Ergebnis: null Kilowattstunden, Zeile übersprungen, kein Hinweis. Ausgerechnet an diesen Anlagen beschreibt das Handbuch die Falle, die er finden soll: ein Wärmemengenzähler, der die Wärme eines zweiten Erzeugers mitmisst. Dasselbe galt für die Warmwasser-Wärme, deren Geräte-Filter ohne die Angaben ebenfalls fehlte. Es ändert sich keine Zahl — der Prüfer sieht jetzt, was er immer sehen sollte.
Die Fußzeile unter dem Saison-Balken nennt jetzt je Kennzahl, was gezählt ist. In Komponenten → Wärme/Klima → Vergleich stand bei getrennter Strommessung unter jedem Balken derselbe Satz „Saison-Strom = nur Heizung (Warmwasser ausgeklammert)” — für die JAZ stimmt er, für den Strom-Balken nicht: Der zeigt den Gesamtstrom des Geräts, also Heizen und Warmwasser (und, wo ein Kühlzähler misst, auch Kühlen). Jetzt sagt der Satz je Kennzahl, was zusammengezählt ist. Es ändert sich keine Zahl, nur die Auskunft darüber.
Der Glossar-Eintrag „Heizgradtage” beschrieb eine Rechnung, die eedc nie angestellt hat. Dort stand „Differenz zwischen Innenraum-Solltemperatur (typ. 20 °C) und Außentemperatur” — die 20 °C kommen im ganzen Programm nicht vor. eedc rechnet seit jeher mit der Heizgrenze 15 °C (Gradtag-Konvention): je Tag max(0; 15 °C − Tagesmittel der Außentemperatur). Der Eintrag war damit schon für die bestehende Temperaturkorrektur der Verbrauchsprognose falsch, auf die er sich ausdrücklich berief. Es ändert sich keine Zahl, nur die Erklärung — und die Konstante lebt jetzt an einer Stelle, die beide Verwendungen speist.
Der Live-Tagesverlauf behauptet nicht mehr, eine Wärmepumpe fehle, die er zeichnet. Wer Leistung Heizen und Leistung Warmwasser zugeordnet hat und Leistung gesamt leer lässt — genau die Zuordnung, für die eedc die getrennten Flächen baut —, las in Cockpit → Live über seinen zwei gezeichneten Wärmepumpen-Flächen den bernsteinfarbenen Satz „Nicht dargestellt (kein HA-Leistungssensor): «Gerät»”. ⭐ Der Satz behauptet zwei Dinge, geprüft wurde nur eines: eedc sammelte jedes Gerät ohne Leistung gesamt — die getrennten Felder zählten nicht als Leistungsquelle. ⚠ Der MQTT-Weg machte denselben Fehler spiegelverkehrt: Dort war die Wärmepumpe pauschal von der Meldung ausgenommen, sodass ein Gerät ganz ohne Leistungsquelle wortlos verschwand. Beide Wege beantworten die Frage jetzt mit derselben Bedingung: genannt wird, was nicht gezeichnet wird und wofür keine Leistungsquelle zugeordnet ist. ⚠ Geräte, die aus anderen Gründen keine eigene Fläche bekommen, stehen weiterhin nicht dort — ein E-Auto, dessen Ladung die Wallbox schon misst, zwei Geräte an derselben Entity, ein Zähler unter Sonstiges: Sie haben einen Leistungssensor, ihnen fehlt nur eine eigene Reihe. Es ändert sich keine Zahl, nur der Hinweis darüber.
Eine Arbeitszahl aus der Wärme des einen und dem Strom eines anderen Geräts verschwindet — und sagt warum. Wer zwei Wärmepumpen erfasst, von denen die eine ihre Wärme meldet und die andere ihren Strom, las in Cockpit → Monat und Jahr eine Arbeitszahl von 3,0 — gebildet aus 2400 kWh Wärme des einen Geräts und 800 kWh Strom des anderen. Kein Hinweis stand daneben, und an den Community-Benchmark ging der Monat als belastbar hinaus, floss also in die Vergleichswerte fremder Anlagen ein. ⭐ Die Ursache war eine Zählung statt eines Vergleichs: eedc prüfte, ob gleich viele Geräte Zähler und Nenner tragen — „eines hier, eines dort” galt damit als deckungsgleich. Jetzt prüft es, ob es dieselben sind. Dort steht künftig „Wärme und Strom stammen von verschiedenen Geräten”. ⚠ Dieselbe Zählung war zusätzlich einseitig und fing nur eine der beiden Richtungen: Ein Zweitgerät, das Wärme meldet, ohne seinen Strom beizusteuern, hob die Zahl auf 3,75 statt 3,0 — unbemerkt, weil eine zu hohe Zahl plausibel aussieht. Auch die Kreuzung über Monate hinweg (Wärme von Gerät A im März, Strom von Gerät B im Juli) ergab 4,0 ohne jeden Grund. ⭐ In der Gegenrichtung erscheint eine Zahl neu: Ein Zweitgerät, das ausschließlich kühlt, sperrte bisher die Gesamt-Arbeitszahl mit dem Satz „nicht alle Geräte melden Wärme” — obwohl sein Kühlstrom im Nenner gar nicht steht (eedc rechnet ihn seit v4.0.5 heraus) und Heizen und Kühlen daneben beide 3,0 auswiesen. ⚠ Für Betroffene sinkt keine Zahl — sie verschwindet, und das ist die Korrektur: Der bisherige Wert war aus zwei verschieden abgegrenzten Mengen gebildet. Der Weg heraus steht am Gerät — Komponenten → Wärme/Klima nennt je Gerät, welche Seite fehlt, und der Block verlinkt dorthin. ⚑ Eine Kaskade oder mehrere Wärmepumpen an einem gemeinsamen Zähler erfasst du als ein Gerät; getrennt eingetragen kann eedc nicht wissen, dass ihre Zähler zusammengehören.
Die Gesamt-Arbeitszahl unterscheidet jetzt zwischen Geräten und Monaten — in Cockpit → Jahr und im Komponenten-Hub. Wer den Stromzähler seiner Wärmepumpe erst mitten im Jahr in Betrieb genommen hat, las eine Jahres-Arbeitszahl von 6,0: Die Wärme aller Monate stand im Zähler, der Strom nur der gemessenen Monate im Nenner. Die Zeile Arbeitszahl Heizen nannte diese Lage bereits beim Namen, die Gesamtzahl daneben zeigte unbeirrt eine Zahl — dieselbe 6,0 auch im Komponenten-Hub. Beide sagen jetzt „Wärme und Strom stammen aus verschiedenen Monaten”. ⭐ Und in der Gegenrichtung erscheint eine Zahl, die zu Unrecht fehlte: Eine Anlage mit einem Gerät, dessen Wärmemengenzähler im Juli eine gemessene Null meldet, während der Standby-Strom weiterläuft, verlor ihre Gesamt-Arbeitszahl mit dem Satz „nicht alle Geräte melden Wärme” — bei einem einzigen Gerät eine Falschaussage, und daneben stand die Heiz-Arbeitszahl mit 2,77. Jetzt steht dort dieselbe 2,77. ⭐ Der Hub liest die Wärme jetzt wie der Rest von eedc: Ein Monat, der nur eine Gesamtwärme trägt (per Import erreichbar) statt Heiz- und Warmwasser-Wärme getrennt, war für den Hub ein Monat ohne Wärme — er zeigte 3,0, wo das Cockpit sperrte. Dieselbe Zeile, dieselbe Lesart. ⚠ Betroffen ist nur die Gesamtzahl. Die Arbeitszahlen je Funktion und je Gerät im Hub ändern sich nicht.
Die Arbeitszahl Kühlen spricht nicht mehr von Wärme. Bleibt sie gesperrt, weil Nutzenergie und Strom von verschiedenen Geräten stammen, stand dort ein Satz über „Wärme” — unter einer Zahl, deren Zähler eine Kältemenge ist. Der Grund heißt jetzt „Nutzenergie und Strom dieser Funktion stammen von verschiedenen Geräten”, und der Block-Satz „nicht alle Geräte melden Wärme” erscheint unter der Kühlzahl gar nicht mehr — dort steht derselbe Funktions-Satz. Heizen und Warmwasser behalten ihren gewohnten Wortlaut.
Die Strom-Aufteilung einer Wärmepumpe mit Betriebsart-Zählern stimmt jetzt auch am einzelnen Tag (Bauform von dietmar1968 im simon42-Forum). Wer seiner Wärmepumpe oder Klimaanlage eigene kWh-Zähler je Betriebsart zugeordnet hat (Heizen, Kühlen, Lüften, Entfeuchten), sah in Cockpit → Tag und im Tages-Verlauf von Cockpit → Monat einen Anteil „Nicht aufgeteilt”, den es gar nicht gab — oder die Aufteilung fehlte an manchen Tagen ganz. ⭐ Die Ursache war ein Zeitversatz von einer Stunde: Den Tagesstrom des Geräts übernimmt eedc im Home-Assistant-Add-on aus den Stundenwerten der Langzeitstatistik — also von 23 Uhr des Vortags bis 23 Uhr. Die Betriebsart-Zähler las es dagegen von Mitternacht bis Mitternacht. Der Unterschied der beiden Randstunden stand dann als „nicht aufgeteilt” da; war er in die andere Richtung größer, wirkte die Teilmenge größer als das Ganze, und eedc ließ die Aufteilung lieber weg. Jetzt liest eedc beide Werte im selben Zeitfenster. An einem nachgestellten Gerät, das nur heizt: vorher 1,8 von 7,0 kWh „nicht aufgeteilt”, jetzt 0. ⚠ Sichtbar ändern sich die Aufteilungsbalken der Tage — „Nicht aufgeteilt” schrumpft auf den tatsächlichen Leerlauf, und fehlende Aufteilungen tauchen wieder auf. Monats- und Jahreswerte sind nicht betroffen, ebenso wenig Anlagen, deren Tageswerte aus der eedc-eigenen Zählerablage stammen (Standalone, MQTT).
Die Tages-Arbeitszahl der Wärmepumpe teilt Wärme und Strom jetzt aus demselben Zeitraum. In Cockpit → Tag entstand die Arbeitszahl im Home-Assistant-Add-on aus der Wärme von Mitternacht bis Mitternacht und dem Strom von 23 Uhr des Vortags bis 23 Uhr — dieselbe Stunde Versatz wie bei der Strom-Aufteilung darüber. An einer nachgestellten Wärmepumpe, die in jeder Stunde mit 3,0 arbeitet, stand je nach Tag 2,23 oder 4,04; die Formel unter der Kachel zeigte die beiden Zahlen offen, nur ihre verschiedenen Zeiträume nicht. ⭐ Jetzt liest eedc Wärme, Strom und die getrennte Strommessung für Heizen und Warmwasser im selben Fenster — der ganze Wärmepumpen-Block eines Tages rechnet damit auf einem Zeitraum. Der Tages-Verlauf in Cockpit → Monat zieht mit, sodass eine Tagessäule dort dieselbe Wärme nennt wie Cockpit → Tag. ⚠ Sichtbar ändern sich im Add-on die Tageswerte für Wärme und die Arbeitszahlen — um den Unterschied einer Stunde am Tagesrand. Monats- und Jahreswerte sind nicht betroffen, ebenso wenig Anlagen, deren Tageswerte aus der eedc-eigenen Zählerablage stammen (Standalone, MQTT).
Der dynamische Strompreis erreicht jetzt auch Tag und laufenden Monat (gemeldet von OB73-gif, #412). Wer einen Tibber-/aWATTar-/EPEX-Sensor zugeordnet hat, las in Cockpit → Tag und im laufenden Monat den festen Tarifpreis — obwohl eedc die echten Stundenpreise längst mitschreibt und im Monatsabschluss sogar einen Ø daraus vorschlägt. ⭐ Die Zahl war nicht falsch gerechnet, sie war die schlechtere von zweien: Der abgerechnete Ø aus dem Monatsabschluss hatte Vorrang, danach kam sofort der Stammpreis — die Messung dazwischen fehlte. Ab jetzt gilt: dein abgerechneter Wert schlägt alles, sonst der verbrauchsgewichtete Ø deiner Stundenpreise, sonst der über deinen Netzbezug gewichtete Zeittarif (HT/NT), sonst der Stammpreis. ⚠ Nach dem Monatsabschluss ändert sich nichts an der bisherigen Mechanik: Der eingetragene Wert gilt dann rückwirkend für jeden Tag des Monats, damit die Summe der Tage den Monat trifft. ⛔ Aufgehoben mit 4.0.46: Tage sind Messung, Monate sind Abrechnung — ein später eingetragener Monats-Ø lässt die Tage stehen (s. dort). Der Sprung beim Abschluss wird nur kleiner, weil vorher schon ein gemessener statt eines geschätzten Preises stand. ⚠ Betroffen sind Kosten, Ersparnis und Netto-Ertrag in allen Sichten — für Anlagen mit dynamischem Tarif werden diese Zahlen für nicht abgeschlossene Monate genauer und weichen von den bisher angezeigten ab.
Das Feld „Ø Strompreis” erscheint jetzt in jedem Monat, für den eedc Stundenpreise mitgeschrieben hat. Bisher hing es allein an der Vertragsart „dynamisch” in den Stammdaten. ⭐ Das trifft den Fall, der jetzt neu ist: Wo eedc den Bezugspreis aus gemessenen Stundenpreisen bildet, muss man seinen abgerechneten Wert danebenstellen können — sonst rechnet eedc mit einer Messung, die sich durch die Abrechnung nicht ersetzen lässt. ⚠ Bewusst an der Messung dieses Monats festgemacht, nicht am zugeordneten Sensor: Wer von einem dynamischen Tarif auf einen Festpreis wechselt, behält sein Sensor-Mapping — das Feld wäre danach in jedem Monat erschienen, auch in Festpreis-Monaten, wo es nichts einzutragen gibt.
Der abgerechnete Monats-Ø erreicht jetzt ALLE Sichten — auch die HA-Sensoren. Bei der Arbeit an #412 gemessen: Von fünf Stellen, die die E-Auto-/Wallbox-Ersparnis bewerten, nahmen nur zwei den im Monatsabschluss gepflegten Ø; die beiden HA-Sensoren und das Komponenten-Dashboard rechneten weiter mit dem Stammtarif. ⚠ Dieselbe Größe zeigte damit je nach Sicht zwei verschiedene Beträge. ⚠ Für Betroffene ändern sich HA-Sensorwerte (E-Auto-/Wallbox-Ersparnis) — sie folgen jetzt dem Cockpit. Ein eigener Wärmestrom- oder Wallbox-Tarif geht dabei nicht verloren: Er bleibt der Wert, mit dem gerechnet wird, solange kein abgerechneter oder gemessener Ø vorliegt.
Die Oberfläche bleibt bedienbar, während eedc eine Datenlücke aus der Home-Assistant-Statistik nachholt. Fehlt für einen Tag ein Zählerstand, holt eedc ihn aus der Langzeitstatistik nach und merkt ihn sich. Diese Abfrage lief bisher im selben Arbeitsstrang wie die Oberfläche — bei mehreren Lücken hintereinander stand die App für die Dauer aller Abfragen. Sie läuft jetzt daneben. ⭐ Aufgefallen ist es beim Bau des Monats-Verlaufs, der viele solcher Ränder auf einmal prüft; die Blockade gab es aber schon vorher, bei jedem Aufruf von Cockpit → Tag mit einer Lücke. Der Schreib-Teil von eedc kennt diese Regel seit Langem — der Lese-Teil bisher nicht. ⚠ Es ändert sich keine Zahl.
Arbeitszahlen je Funktion erscheinen, sobald sie sauber abgegrenzt sind — statt mit dem ganzen Block zu verschwinden (Bauform gemeldet von dietmar1968 im simon42-Forum). Wer eine Wärmepumpe und eine Split-Klimaanlage betreibt, las in Cockpit → Tag/Monat/Jahr drei Striche bei Arbeitszahl · Heizen, · Warmwasser und · Kühlen — mit dem Grund „Wärmepumpe und Klimaanlage in einer Zahl”. Der Komponenten-Hub zeigte für dieselben Geräte längst 3,0 und 2,5. ⭐ Die Sperre galt dem ganzen Block, obwohl nur die Gesamtzahl vermischt war: Eine Split-Klimaanlage macht kein Warmwasser, und ihr Stromverbrauch steht in einem Feld, das zu keiner Funktion gehört — Heizen und Warmwasser waren reine Wärmepumpen-Größen. Maßstab ist jetzt, ob Wärme und Strom einer Funktion von denselben Geräten stammen. Die anlagenweite Gesamt-Arbeitszahl bleibt unverändert gesperrt — sie mischt wirklich. ⚠ Nicht gelockert wurde die Sperre bei einer gemeldeten Abgrenzungs-Störung (Heizstab auf dem Zähler, zweiter Erzeuger am Wärmekreis) und bei versetzten Messzeiträumen: Die Angabe sagt nicht, welche Funktion betroffen ist, also wird keine freigegeben.
Eine zu hohe Warmwasser-Arbeitszahl bei zwei wärmemeldenden Geräten. Wer neben seiner Heizungs-Wärmepumpe eine Brauchwasser-Wärmepumpe betreibt, bekam eine Arbeitszahl, in deren Zähler die Warmwasser-Wärme beider Geräte stand, während im Nenner nur der getrennt gemessene Strom eines Geräts lag. An einer nachgestellten Anlage: 4,75 statt einer Sperre — und ohne jeden Hinweis, dass die Zahl zwei Geräte im Zähler und eines im Nenner hat. ⭐ Keine der bisherigen Prüfungen konnte das sehen: Beide Geräte sind Wärmepumpen (also keine gemischten Bauarten), beide melden Wärme (also kein fehlender Zähler). Dort steht jetzt „Nutzenergie und Strom dieser Funktion stammen von verschiedenen Geräten”. ⚠ Für Betroffene sinkt keine Zahl — sie verschwindet, und das ist die Korrektur: Der bisherige Wert war zu hoch. ⭐ Und wenn es gar nicht an den Geräten liegt, sagt eedc das auch: Wer den getrennten Stromzähler erst mitten im Jahr in Betrieb genommen hat, hat ein Gerät und trotzdem eine Lücke — dort heißt der Grund „Nutzenergie und Strom dieser Funktion stammen aus verschiedenen Monaten”. Dasselbe greift in der Gegenrichtung, wenn eine Klimaanlage Heizwärme meldet, ohne Heizstrom beizusteuern.
Ein Wärmemengenzähler, der null meldet, gilt nicht mehr als fehlender Zähler (gemeldet von dietmar1968 im simon42-Forum). Wer Heizwärme und Warmwasser getrennt misst, las in Cockpit → Tag an einem Tag ohne Heizbetrieb „Arbeitszahl · Heizen — (kein Wärmemengenzähler zugeordnet)” — obwohl der Zähler zugeordnet ist und korrekt null meldet. Der Melder hat daraufhin nach einem Zuordnungsfehler gesucht, den es nicht gab. Dort steht jetzt „kein Heizbetrieb in diesem Zeitraum” bzw. „keine Warmwasserbereitung in diesem Zeitraum” — derselbe Wortlaut, den die Kühlseite seit v4.0.29 führt. ⭐ Die Ursache war eine Verwechslung von „nichts gemessen” und „null gemessen”: Beide kamen als dieselbe Zahl an, und die Begründung war für den einen Fall wahr und für den anderen falsch. ⚠ Wer wirklich keinen Wärmemengenzähler hat, liest unverändert, dass ihm einer fehlt — der Hinweis auf die fehlende Zuordnung geht nicht verloren. ⛔ Bewusst nur in der Tagessicht: Monat und Jahr summieren ihre Werte, bevor sie die Arbeitszahl bilden, und können die beiden Fälle deshalb nicht auseinanderhalten; dort denselben Satz zu setzen hieße, die Falschaussage nur umzudrehen. Es ändert sich keine Zahl — nur die Begründung, warum an dieser Stelle keine steht.
Ladung zwischen 23 und 24 Uhr zählte in Cockpit → Tag zum falschen Tag — betroffen sind Speicher-Netzladung und die PV-/Netz-Aufteilung der Auto-Ladung. Die Tageszeile stützt sich auf die Stundenwerte und deckt damit die Zeit von 23 Uhr des Vortags bis 23 Uhr des Tages ab; die Zähler daneben wurden aber von Mitternacht bis Mitternacht gelesen. An einem Tag mit Ladung in der letzten Stunde standen Teil und Ganzes deshalb aus verschiedenen Tagen nebeneinander: Die Detailzeile „davon aus dem Netz (Arbitrage)” konnte 0,0 kWh melden, obwohl der Speicher nachts 6 kWh aus dem Netz gezogen hatte — oder umgekehrt eine Menge zeigen, die größer war als die Ladung des ganzen Tages. Beim Auto lief derselbe Fehler über die Kachel „PV-Anteil” und die Zeile „Ladung · Netz-Anteil”. Jetzt kommen Zähler und Bezug aus demselben Fenster. ⚠ Zahlen ändern sich nur an Tagen, in deren letzter Stunde — oder in der letzten Stunde des Vortags — geladen oder entladen wurde, denn genau diese Stunde wandert von einem Tag in den anderen. An einem Demo-Datensatz waren das 10 solche Nächte und 18 von 182 Tagen mit mehr als 5 % Abweichung; an den übrigen bleibt alles Ziffer für Ziffer gleich. Betroffen sind dort die Kachel „Batterieladung Netz” (kWh und €), die Zeile „Wirkungsverluste (Opportunitätskosten)” — in einem nachgestellten Fall −0,32 € statt richtig −0,08 € — sowie PV-Anteil und Netz-Anteil der E-Mobilität. ⛔ Nur die Tagessicht. Monat, Jahr, Auswertungen, Monatsbericht, HA-Sensoren, Community und der Komponenten-Hub rechnen aus den Monatswerten und bleiben unverändert. ⭐ Und die 100-%-Grenze beim Netz-Anteil ist nicht mehr stumm: Sie kann weiterhin greifen, weil der Netzladungs-Zähler brutto zählt und die Tages-Ladung netto (Laden und Entladen in derselben Stunde heben sich darin auf) — dann steht der Grund jetzt im Formel-Tooltip der Zeile, statt dass eine gekappte Zahl wie eine Messung aussieht. ⚠ Die Wärmepumpe ist unberührt: Ihr Fenster hängt an der Herkunft ihrer Tageswerte und wurde bereits mit der vorherigen Korrektur geradegezogen.
Die je-Funktion-Arbeitszahlen der Tagessicht nennen ihren eigenen Grund. Sie liefen bis hierher auf einen gemeinsamen Standardsatz, während die Gesamt-Arbeitszahl darüber längst den tatsächlichen Grund führte. Wer den Wärmemengenzähler für die Heizung zugeordnet hat und den fürs Warmwasser nicht, bekommt jetzt für jede der beiden Zeilen die Auskunft, die zu ihrem Zähler gehört.
Eine Brauchwasser-Wärmepumpe wird nicht mehr nach dem Heizwärmebedarf gefragt. Wer die Wärmepumpenart Brauchwasser gewählt hat, las unter Einstellungen → Daten den Hinweis „Heizwärmebedarf nicht gesetzt“ — an einem Gerät, das keine Heizung macht. Abstellen ließ er sich nur, indem man eine Zahl erfindet; das Wärme/Klima-Handbuch sagt für diesen Fall ausdrücklich zu, dass der Daten-Checker die Heiz-Achse nicht verlangt. ⭐ Stattdessen fragt eedc jetzt nach der Achse, die das Gerät hat: Fehlt der Warmwasserbedarf, steht dort ein Hinweis auf ihn — er versorgt dieselbe Jahres-Einsparungsschätzung, die ohne gepflegten Bedarf gar nicht rechnet („Nicht bewertet“). Es bleibt bei einem Hinweis je Gerät. ⚠ Wer mit einer Klimaanlage heizt, behält den bisherigen Hinweis — für sie ist der Heizwärmebedarf die Grundlage ihrer Ersparnis. ⭐ Welche Achse ein Gerät hat, entscheidet damit auch hier die Feld-Registry und nicht die Bauart — wie schon bei den Monatswerten.
Eine Brauchwasser-Wärmepumpe bekam eine Ersparnis für Heizwärme gutgeschrieben, die sie nie liefert. Das Investitionsformular hat den Heizwärmebedarf auch an einem Gerät angeboten, das ausschließlich Warmwasser macht — und ihn mit 12.000 kWh vorbelegt. Wer das Formular einmal gespeichert hat, trug die Zahl seither in seinen Daten, und Auswertungen → ROI rechnete daraus 714,29 € Jahresersparnis und 1.721 kg CO₂ statt 142,86 € und 344 kg — 571 € im Jahr für Wärme, die das Gerät nicht abgibt, samt Beitrag zu den Anlagen-Summen. Das Feld wird jetzt nicht mehr angeboten, nicht mehr vorbelegt und nicht mehr mitgerechnet; steht bei dir noch die alte Vorbelegung, trägt die ROI-Zeile „Nicht bewertet“ mit dem Weg heraus (Warmwasserbedarf eintragen) statt einer erfundenen Zahl. ⭐ Spiegelbildlich für die Split-Klimaanlage: Sie hat keinen Warmwasserkreis — ein dort gepflegter Warmwasserbedarf zählt nicht mehr mit. ⚠ An einer Wärmepumpe mit Heizung und Warmwasser ändert sich nichts, auch nicht an der Klimaanlage, mit der du heizt: Dort bleibt der Heizwärmebedarf die Grundlage ihrer Ersparnis. ⛔ Es ist dieselbe Regel wie bei den Messwerten: Welche Größe ein Gerät hat, entscheidet die Feld-Registry — nicht seine Bauart.
Die SCOP- und COP-Hinweise des Daten-Checkers verlangen keine Zahl mehr für eine Achse, die es am Gerät nicht gibt. Wer den Effizienz-Modus EU-Label SCOP oder Getrennte COPs gewählt hatte, bekam an einer Brauchwasser-Wärmepumpe eine Warnung, weil der SCOP Heizung fehlte — an einem Gerät, das nicht heizt; an einer Split-Klimaanlage umgekehrt wegen des SCOP Warmwasser, obwohl sie gar keinen Warmwasserkreis hat. Abstellen ließ sich beides nur, indem man eine Zahl erfindet, die anschließend nirgends gerechnet wird. Jetzt wird nur nach der Achse gefragt, die das Gerät hat, und die Meldung nennt sie beim Namen („SCOP Warmwasser fehlt“). ⚠ An einer Wärmepumpe mit beiden Achsen bleiben Wortlaut und Verhalten unverändert. ⭐ Dazu schweigt der Hinweis „Heizwärmebedarf nicht gesetzt“ jetzt auch dann, wenn statt der beiden Einzelwerte ein Gesamt-Wärmebedarf gepflegt ist — die Rechnung liest ihn zuerst.

Changed

Der Block Wärme/Klima zeigt jetzt, was deine Daten hergeben — und sagt EINMAL, was noch möglich wäre. Cockpit → Monat bestand bei gemischter Ausstattung aus vier Strichen mit Grund-Texten: Arbeitszahl „—” (Wärmepumpe und Klimaanlage in einer Zahl), Arbeitszahl Heizen und Warmwasser „—” (Strom nicht getrennt je Funktion gemessen, zweimal derselbe Satz), Arbeitszahl Kühlen „—” (kein Kältemengenzähler zugeordnet) — dazu ein Link in den Komponenten-Hub. Jeder einzelne Grund war richtig; zusammen ergaben sie eine Seite, die vor allem sagt, was sie nicht weiß. Drei Änderungen: (1) Die anlagenweite Arbeitszahl verschwindet nicht mehr, sie sagt „mindestens”. Steckt im Nenner Strom, dem keine gemessene Wärme gegenübersteht — deine Klimaanlage heizt mit, ein Heizstab läuft auf eigenem Zähler —, kann die Zahl nur zu klein sein und nie zu groß. Statt eines Strichs steht dort jetzt „≥ 3,00” mit dem einen Satz „Klimaanlage: Strom ohne Wärmemessung enthalten”. (2) Die Zahlen je Gerät stehen im Block selbst — eine Tabelle Gerät · Wärme · Strom · Arbeitszahl · Heizen · Warmwasser · Kühlen, damit die saubere 3,75 deiner Wärmepumpe neben dem Mindestwert der Anlage steht und nicht nur hinter einem Link. (3) Gründe stehen einmal statt viermal: Was deine Ausstattung nicht hergibt, sammelt der neue, aufgeklappte Kasten „Was noch möglich wäre” am Blockende — je Grund eine Zeile mit den betroffenen Größen, dem Handgriff (den es vorher nirgends gab) und dem Weg dorthin; die Kachel dazu erscheint gar nicht erst. Was deine Ausstattung hergibt und in diesem Zeitraum leer war (die Arbeitszahl Heizen im Juni), bleibt ein „—” ohne Text — dort gibt es nichts zu tun. ⛔ In der Gegenrichtung gibt es keinen Mindestwert: Steuert ein Gerät Wärme bei, ohne dass sein Strom mitzählt, wäre die Zahl zu groß — dort bleibt es beim Strich und beim Grund, ebenso bei deiner eigenen Angabe Fremdanteil auf den Zählern und bei versetzten Messzeiträumen. ⛔ Die Arbeitszahl EINES Geräts ist unberührt: Sie entsteht weiterhin nur, wo Zähler und Nenner dasselbe Gerät und dieselbe Funktion meinen — der Mindestwert ist eine dritte Größe mit eigenem Namen (Systemarbeitszahl der Wärmeerzeugung), keine gemeinsame Arbeitszahl zweier Geräte. ⛔ Der Jahresbericht als PDF ist unverändert — eine Zahl ohne sichtbares „≥” im Druck wäre genau das, was eedc vermeiden will. ⭐ Die Zahlen je Gerät kommen aus derselben Rechnung wie im Komponenten-Hub, nicht aus einer zweiten daneben; die Hub-Zahlen sind dabei auf die Nachkommastelle unverändert geblieben. ⚠ Kleinigkeit am Rande: Wer seinen Heizstrom getrennt misst, las im Sommer „kein Stromverbrauch erfasst” — an einer Anlage, die ihn sehr wohl erfasst, nur eben mit null. Dort steht jetzt „kein Heizbetrieb in diesem Zeitraum”, wie auf der Kühlseite seit jeher.
Ein Gesamtzähler neben getrennten Zählern zählt jetzt — der Rest heißt „nicht aufgeteilt”. Wer Strom Heizen und Strom Warmwasser getrennt misst und zusätzlich einen Gesamtzähler pflegt, dem hat eedc den Gesamtzähler bisher weggeworfen: „Die feine Aufteilung ist vollständig, sie ist die Gesamtmenge — sonst zählte derselbe Strom zweimal.” Der Satz stimmte für die Doppelzählung und war für die Menge falsch. Eine Wärmepumpe zieht Strom, der auf keiner der beiden Achsen liegt — Standby, Steuerung, Umwälzpumpen; bei einem Melder 145 von 2193 kWh im Jahr, knapp 7 %. Diese Kilowattstunden fehlten in Verbrauch, Kosten, CO₂ und im Nenner der Arbeitszahl. Neu gilt ohne Vorbehalt: Der Gesamtzähler ist die Menge; die beiden Achsen sind die Aufteilung darunter, und was er mehr misst, erscheint als „nicht aufgeteilt”. ⭐ Doppelt gezählt wird trotzdem nichts — eedc ersetzt die Summe durch den Gesamtwert, es addiert sie nicht. ⚠ Was sich für dich ändert: Steht dein Gesamtzähler genau auf der Summe der beiden Achsen, ändert sich gar nichts (an der Demo-Anlage: 0 von 680 geprüften Werten). Steht er höher, steigen Verbrauch, Kosten und CO₂ dieser Wärmepumpe um die Differenz, und die Arbeitszahl gesamt fällt entsprechend niedriger aus — Beispiel aus dem Handbuch (Fall B, Gesamtzähler 1145 statt 1050): 3,44 statt 3,79. Das ist die ehrliche Zahl; Standby gehört zur Wärmepumpe. ⛔ Die Arbeitszahlen je Funktion bleiben unberührt — ihr Nenner ist der jeweils eigene Zähler. ⚑ Zwei neue Prüfungen begleiten das: Liegt der Gesamtzähler unter der Summe der Achsen, warnt der Daten-Checker („Gesamtzähler kleiner als die Summe der Achsen”) und eedc rechnet in diesen Monaten mit den Achsen, damit nichts verloren geht. Liegt mehr als ein Viertel des Verbrauchs auf keiner Achse, fragt er einmal nach, ob der Zähler wirklich nur die Wärmepumpe misst — kein Fehler, eine Frage. ⭐ Und die Datenquellen-Fläche sagt das Gegenteil von vorher: Das Gesamtstromfeld hieß dort „bereits zugeordnet — hier ist nichts einzutragen”; jetzt steht da, was es bringt. Wer dem alten Satz gefolgt ist, hat genau diese Kilowattstunden verloren.
Der Strom einer Wärmepumpe wird jetzt überall voll gerechnet — auch der Teil aus der eigenen PV. Dieselbe Wärmepumpe hatte bis hierher vier Ersparnis-Zahlen, weil vier Stellen ihren PV-Anteil verschieden abzogen: die Jahresprognose und die anlagenweiten Alternativkosten pauschal 50 % (eine Konstante, die in keinem Formular stand), der Monats-Layer 0 %, und die ROI-Zeile den am Gerät gepflegten PV-Anteil (%). An der Demo-Anlage hieß das: 1.990,43 € im Komponenten-Hub und in Cockpit → Monat/Jahr, 1.072,04 € in der Aussicht, 1.355,00 € in Auswertungen → ROI. ⭐ Der Abzug war nicht nur uneinheitlich, er war falsch: Der PV-Strom, den die Wärmepumpe verbraucht, ist auf der PV-Seite bereits gutgeschrieben — im Geld als Eigenverbrauch (zum Netzbezugspreis bewertet), im CO₂ als vermiedener Netzstrom. Ihn bei der Wärmepumpe ein zweites Mal abzuziehen zählte dieselbe Kilowattstunde doppelt (ADR-002/P9); an der Demo-Anlage waren das 206,53 €/Jahr. Am Zahlenbeispiel: PV 1.000 kWh, davon 300 in die Wärmepumpe, Netz 30 ct, Gas-Alternative 500 € — wahr sind 556 € Jahresnutzen, eedc wies 646 € aus. ⭐ Die Konstante WP_PV_ANTEIL_DEFAULT ist ersatzlos gelöscht, ebenso der PV-Parameter in der ROI-Formel; es gibt für diese Größe nur noch eine Bildungsvorschrift. Was sich für dich ändert: Cockpit → Aussicht nennt einen niedrigeren Jahres-Netto-Ertrag (Demo: 5.681,57 € → 5.475,04 €, −3,6 %) und eine spätere Amortisation (167 → 175 Monate); in Auswertungen → ROI fällt die Zeile der Wärmepumpe (1.355,00 € → 926,92 €, −31,6 %) samt ihrer CO₂-Zahl (2.343,0 → 1.800,8 kg), die sich damit der Zahl aus Auswertungen → CO₂ angleicht. ⚠ Drei ausgelieferte HA-Sensoren ändern ihren Wert: jahres_ersparnis_euro (−6,6 %), roi_prozent (−6,6 %) und amortisation_jahre (+1,28 Jahre) — die Langzeitstatistik springt an einem Tag. netto_ertrag_euro und der Sensor wp_ersparnis_euro je Wärmepumpe bleiben unverändert. ⛔ Komponenten-Hub, Cockpit → Monat, Cockpit → Jahr und Auswertungen → CO₂ bleiben bitgleich — wer nur ins Cockpit schaut, merkt nichts. ⭐ Das Feld PV-Anteil (%) am Gerät bleibt und behält seine zwei Aufgaben (Eigenverbrauchs-Prognose und Zuordnung des Eigenverbrauchs auf das Gerät); sein Hinweis sagt jetzt, dass es eine Mengen- und keine Preisfrage beantwortet. ⭐ Nebenbei behoben: Ein ausdrücklich leeres Feld PV-Anteil (%) — über die API oder einen Import herstellbar — legte die ganze Sicht Auswertungen → ROI mit einem Fehler lahm; mit dem Leser ist auch der Absturz weg.
Die Angabe „Fremdanteil auf den Zählern” nennt nicht mehr nur den Heizstab. Sie ist die einzige Möglichkeit, eedc zu sagen, dass der Stromzähler der Wärmepumpe mehr misst als die Wärmepumpe selbst — und je Gerät die einzige Lage, in der eedc die Arbeitszahl deshalb weglässt. Die Option hieß bisher „Heizstab-Strom liegt mit auf dem Stromzähler”, der Grund neben der leeren Kachel „Heizstab-Strom auf dem WP-Zähler”. Wer eine Klimaanlage, einen Pool-Heizer oder irgendeinen anderen Verbraucher auf demselben Zähler hat, suchte unter Heizstab, fand seinen Fall nicht — und bekam weiterhin eine Arbeitszahl, die zwei Geräte in einen Quotienten mischt. Option und Grund heißen jetzt „Ein weiterer Verbraucher liegt mit auf dem Stromzähler (z. B. Heizstab)” bzw. „Ein weiterer Verbraucher auf dem WP-Zähler (z. B. Heizstab)”; das Handbuch zieht in der Gründe-Tabelle und in der Erklärung des Feldes mit. ⭐ Dieselbe Bauform wie die Korrektur am bivalenten Fall vom 29.08., nur auf der Gegenseite: Die Regel dahinter war immer allgemein, ihr Anwendertext blieb eine Fallsammlung. Der Heizstab bleibt als Beispiel stehen — er ist der häufigste Fall, und welche der beiden Lagen vorliegt, entscheiden weiterhin die Zähler, nicht das Gerät. ⚠ Es ändert sich keine Zahl, keine Sperre und keine gespeicherte Angabe — eine Beschriftung braucht keine Migration.
Das Handbuch Wärme & Klima nennt jetzt seine Grenzen. Vier Eigenheiten dieser Fläche sind gebaut, begründet und richtig — sie standen aber in keinem Anwendertext, und wer sie bemerkte, musste jede davon für einen Fehler halten. (1) Summe der Tage gegen Monat: Kommen die Tageswerte aus der Langzeitstatistik von Home Assistant, steht ein Tag für das Fenster Vortag 23 Uhr bis heute 23 Uhr — dasselbe Fenster, in dem eedc auch die Stunden zählt, und nur deshalb geht eine Tageszeile in sich auf. Der Monatswert läuft über den Kalendermonat; die Summe der Tagessäulen enthält damit die letzte Stunde des Vormonats und nicht die letzte des Monats. (2) Monat gegen Jahr: Der Monatsverlauf zeichnet mitgeschriebene Tage, der Jahresverlauf die Monatszeile — ein importierter oder von Hand gepflegter Monat hat deshalb einen Jahrespunkt ohne Tagessäulen. (3) Laufender Monat: Aufteilung nach Betriebsart, Kältemenge und Arbeitszahl Kühlen kommen ausschließlich aus der gespeicherten Monatszeile; solange der Monat läuft, können Strom und Wärme daneben aus Sensoren stehen, während diese drei leer bleiben. (4) Stundenverlauf: Er verteilt den Tageswert nach der Form der Stunden, statt jede Stunde einzeln zu messen — über Home Assistant ist das rechnerisch dasselbe, auf dem MQTT-/Standalone-Pfad bleibt es eine Verteilung, und was sich gar keiner Stunde zuordnen lässt, wird genannt statt umgelegt. ⭐ Dazu zwei Erklärungen, die bisher nur im Code standen: warum ein Betriebsmodus-Sensor eine Arbeitszahl Kühlen ergibt, aber keine für Heizen — der Nenner einer Funktions-Arbeitszahl ist der getrennt gemessene Strom dieser Funktion, und was aus dem Betriebsmodus entsteht, ist eine Verteilung des Gesamtstroms, die jede Unschärfe ihres Schlüssels erbt —, und welche zwei Bedingungen der Stundenverlauf braucht, um Heizen und Warmwasser getrennt zu zeigen (beide Leistungs-Sensoren zugeordnet und Leistung gesamt leer), samt dem, was ein danebenliegender kWh-Zähler daran ändert. Die Sensor-Referenz sagt es jetzt an allen drei Leistungsfeldern. ⚠ Es ändert sich keine Zahl, keine Anzeige und keine Zuordnung — nur die Auskunft darüber.
Zwölf Kennzahlen zeigen jetzt die eingesetzten Werte, nicht nur ihre Formel. Wer das ⓘ an Netto-Ertrag öffnete, las bisher nur „Einspeise-Erlös + Eigenverbrauchs-Ersparnis” — die beiden Beträge, aus denen die Summe entstanden ist, standen nirgends. In Cockpit → Monat und Cockpit → Jahr stehen sie jetzt darunter („148,20 € Einspeise-Erlös + 96,40 € Eigenverbrauchs-Ersparnis = 244,60 €”), ebenso an Monats- bzw. Jahresergebnis mit seinen drei Posten und an der Performance Ratio, die jetzt sagt, über wie viele Tage sie mittelt. In Auswertungen → Finanzen betrifft es drei Zeilen des T-Kontos: Der Einspeise-Erlös trennt endlich Formel und Rechnung — bisher stand beides in einer Zeile unter der Überschrift „Formel” —, die Betriebskosten je Gerät nennen den Jahresbetrag, aus dem der Zwölftel entsteht, und die anteiligen Betriebskosten sagen, über wie viele Geräte summiert wurde. In Komponenten → Speicher nennt Zyklen/Monat endlich seinen Divisor („99,2 Vollzyklen ÷ 8 Monate”) — bisher stand dort eine Division, deren zweite Zahl auf keiner Seite zu finden war. Und in Komponenten → Wärme/Klima sagen die drei Arbeitszahlen je Funktion — Heizen, Warmwasser, Kühlen —, aus welcher Wärme- und welcher Strommenge sie entstanden sind („1.000,0 kWh ÷ 250,0 kWh”). ⭐ Das ist der Fall, der die ganze Arbeit ausgelöst hat: Wer über Monate eine Arbeitszahl von 0,7 vor sich hatte — physikalisch unmöglich und ein sicheres Zeichen für einen falsch zugeordneten Wärmemengenzähler —, konnte die Ursache nicht sehen, weil die Kachel nur „Heizwärme ÷ Strom Heizen” sagte. ⛔ Wo eedc die Arbeitszahl sperrt (weil die Wärme gerechnet statt gemessen ist oder die Abgrenzung nicht stimmt), erscheint auch keine Rechnung — dort steht weiterhin der Grund; eine Division aus zwei Zahlen, die eedc bewusst nicht durcheinander teilt, wäre die schlechtere Auskunft. ⭐ Die Zahlen kommen aus derselben Antwort wie der Wert daneben und werden in der Anzeige nicht nachgerechnet: Eine Herleitung, die auf eine andere Zahl führt als die Kachel darüber, wäre schlimmer als keine. ⚠ Es ändert sich keine Zahl, nur die Auskunft darüber — wer das ⓘ nie öffnet, sieht keinen Unterschied. ⛔ Wo eine Kachel bewusst keine Rechnung zeigt, bleibt es dabei: an einem rohen Zählerstand, an einer Summe, deren Summanden daneben stehen, und dort, wo der Tooltip nur sagt, woher eine Zahl kommt („Erfasst im Monatsabschluss als Position vom Typ Ertrag”) — eine Zahl mit „Rechnung: Zählerstand” zu versehen wäre das Rauschen, das die Regel gerade vermeiden will.
Im Jahres-T-Konto stand am Einspeise-Erlös die Rechnung des ersten Monats. Nebenbefund derselben Arbeit: Weil die Erlöszeile ihre Zahlen bisher im Formeltext trug, kopierte die Jahres-Zusammenfassung den Satz des Januar unverändert neben den 12-Monats-Betrag — „… — 123,4 kWh × 8,20 ct/kWh” neben einer Summe, die daraus nicht entsteht. Der Formeltext ist jetzt zahlenfrei und gilt im Jahr wie im Monat; die Rechnung selbst steht dort, wo sie stimmt, also im Monat. ⭐ Dieselbe Stelle hat noch eine zweite Ungenauigkeit abgelegt: Über den Betriebskosten des Jahres stand „Betriebskosten/Jahr ÷ 12” — eine Formel, die einen Monatsbetrag beschreibt, während daneben die Jahressumme steht. Im Jahr heißt sie jetzt „Σ der Monats-Zwölftel”. Beide Beträge waren und sind richtig.
Die Kachel „Ø-Preis Netz” sagt, woher ihre Zahl stammt. Je nach Datenlage steht in der Rechnung jetzt „Dein abgerechneter Ø-Preis aus dem Monatsabschluss”, „Ø deiner gemessenen Stundenpreise, verbrauchsgewichtet (X % der Monatsstunden)”, „Ø aus deinem Zeittarif (HT/NT), über den Netzbezug gewichtet” oder „Arbeitspreis aus dem Strompreis-Tarif”. ⭐ Ohne diese Angabe wäre die neue gemessene Zahl von einem Stammpreis nicht zu unterscheiden gewesen — und ein über HT/NT gewichteter Preis lief schon vorher unter der falschen Beschriftung. ⚠ Die Abdeckung gehört dazu: Im laufenden Monat stammt der Ø zwangsläufig aus wenigen Stunden, und das soll man sehen. Es ändert sich keine Zahl, nur ihre Erklärung.
Such- und Filterfelder sagen dem Browser, dass sie nicht ausgefüllt werden sollen (gemeldet von Radiocarbonat im simon42-Forum). Mit 4.0.44 hat die Suche in den Einstellungen ein eigenes ✕ bekommen — für den Melder war das Feld damit trotzdem nicht zu leeren: Sein Browser setzte den einmal gemerkten Begriff nach jedem Löschen sofort wieder ein, bis er das automatische Ausfüllen im Browser selbst abschaltete. ⭐ Ein automatisch eingesetzter Begriff steht in einem Filterfeld genauso da wie ein getippter — die Liste darunter ist leer, und die Sicht ist von einem Defekt nicht mehr zu unterscheiden. Genau das ist der Unterschied zu einem Datenfeld, in dem Autofill hilft. Sechs Felder tragen den Riegel: die Einstellungen-Suche, die beiden Sensor-Picker der Datenquellen, der Gateway-Picker und die zwei Filter der Protokollansicht. ⛔ Bewusst außen vor: das PIN-Feld der Einstellungssperre (dort ist ein Passwortmanager erwünscht, und Browser ignorieren den Riegel auf Passwortfeldern ohnehin) und das Beschreibungsfeld des Datei-Uploads — ein Datenfeld, kein Filter. ⚠ Nicht behauptet wird, dass jeder Browser sich daran hält: autocomplete="off" ist das standardkonforme Mittel, keine Garantie; das Verhalten ist browserabhängig und von uns nicht gemessen. Es ändert sich keine Zahl und kein Suchverhalten.
Die Finanzprognose rechnet den PV-Anteil der Wärmepumpe mit dem Wert, der am Gerät gepflegt ist — und je Gerät. Die Antwort von GET /api/aussichten/finanzen/{id} trug dieselbe Größe dreimal verschieden: Der Eigenverbrauchs-Fallback liest den gepflegten Anteil seit dem 30.08., die beiden übrigen rechneten weiter mit einem festen Anteil (einmal 50 % als Zahl im Code, einmal als Konstante). Zusätzlich stand in der Liste Komponenten-Beiträge bei zwei Wärmepumpen zweimal derselbe volle Anlagenbetrag — sowohl bei der PV-Nutzung als auch bei der Ersparnis gegenüber Gas oder Öl, und selbst für ein Gerät im Neubau, das gar nichts ersetzt hat. Jetzt bekommt jedes Gerät seinen eigenen Beitrag: PV-Nutzung aus seinem gepflegten Anteil und seinem gemessenen Stromanteil, Gas-/Öl-Ersparnis anteilig nach seiner Wärmemenge und nur, wenn es tatsächlich etwas ersetzt hat. Die Summe der Gerätebeiträge ist exakt der Anlagenwert; beide kommen aus einer Quelle statt aus zwei Rechnungen. ⛔ Eine vierte Stelle bleibt bewusst beim festen Anteil: der Netzanteil, aus dem die angezeigte Alternativkosten-Ersparnis entsteht. Sie dort umzustellen wäre keine Aufräumarbeit, sondern eine Wertänderung an einer Zahl, die im Cockpit steht — das braucht eine eigene Bilanz und einen eigenen Entscheid. ⚠ In der Oberfläche ändert sich nichts: Die betroffenen Felder werden heute von keiner Sicht angezeigt. Wer die Route direkt abfragt, bekommt ab jetzt andere (richtige) Zahlen.
Intern — die zwei Handbuch-Wächter der Wärme/Klima-Fläche messen im Abschnitt statt in der Datei. Sie halten fest, dass das Handbuch jeden Sperrgrund und jeden lesbaren Betriebsmodus-Wert wörtlich nennt — gesucht wurde bisher aber über die ganze Datei. Gemessen: Wird ein Grund aus der Tabelle „Die Gründe, wörtlich” entfernt, bleibt der Test grün, solange derselbe Satz irgendwo sonst steht (bei „Strom nicht getrennt je Funktion gemessen” ist das die Voraussetzungs-Tabelle zwei Kapitel davor). Der Wächter verteidigte damit „das Wort kommt vor”, nicht „die Nachschlagestelle ist vollständig”. Jetzt schneidet er den Abschnitt aus, den er verteidigt, und verlangt die Fundstelle in ihrer Form: die zehn Sperr-Gründe als Zeilenkopf der Tabelle, die drei Tages-Gründe fett im Abschnitt daneben, die Betriebsmodus-Werte in der Tabelle unter Schritt 4. Eine umbenannte Überschrift meldet der Prüfer als Fehler, statt still einen leeren Abschnitt zu durchsuchen. ⚠ Keine Zahl und kein Text ändern sich — der Prüfer misst nur wieder, was er zu messen behauptet.
Intern — die Feldtabellen der Betriebsart-Zähler haben endlich einen Wächter. BETRIEBSART_STROM_FELD und BETRIEBSART_NUTZENERGIE_FELD (die gemessenen Zähler je Betriebsart einer Klimaanlage) wurden von keiner Probe gegen den Betriebsmodus-Kanon gehalten; der Kommentar an ihnen behauptete bis zum 29.08. eine Probe unter dem Namen einer Datei, die es nie gab. Vier Proben stehen jetzt neben dem Nachbar-Wächter für den abgeleiteten Split: beide Tabellen sind exakt an die messbaren Betriebsarten gebunden, die Feldnamen folgen ihrer Konvention, jeder Kanon-Wert ist entweder als messbar eingeordnet oder mit Grund ausgeschlossen — und der Unterschied zwischen „was kann eedc aus einem Modus-Signal ableiten” und „wofür bietet eedc einen eigenen Zähler an” ist selbst gewächtert, damit ihn niemand als Aufräumarbeit einebnet. ⚠ Keine Zahl, kein Feld und keine Anzeige ändern sich.
Das Add-on-Volume-Mapping folgt der aktuellen Home-Assistant-Schreibweise. Der Supervisor meldet die bisherige Kurzform config:ro seit HA 2023.10 als veraltet — aufgefallen, als zum ersten Mal ein echter Supervisor unsere Add-on-Konfiguration eingelesen hat. Das Add-on deklariert jetzt homeassistant_config und hängt es ausdrücklich unter /config ein. ⭐ Der ausdrückliche Pfad ist der eigentliche Punkt: Unter dem neuen Namen allein läge das Home-Assistant-Konfigurationsverzeichnis nach /homeassistant, während eedc an zwei Stellen unter /config sucht — die Recorder-Datenbank (der schnelle Weg zur Langzeitstatistik) und die Energie-Konfiguration (die Vorschläge im Einrichtungsassistenten, #197). Die Statistik wäre still auf den langsameren Weg gefallen, die Vorschläge ersatzlos ausgefallen. ⚠ Für dich ändert sich nichts — der Container sieht exakt dasselbe Verzeichnis wie zuvor, kein Zugriff kommt hinzu, keine Neuinstallation ist nötig.
Intern — die Tages-Kilowattstunden des MQTT-Betriebs lesen über die Sitzung, die der Aufruf schon hält. mqtt_energy_history_service.get_tages_kwh und seine zwei Snapshot-Helfer öffneten je eine eigene Datenbank-Verbindung, obwohl Cockpit → Live seine Sitzung bis dorthin durchreicht. Es ändert sich keine Zahl und keine Anzeige — es ist dieselbe Bauform, die nach v4.0.40 die Testläufe rot gemacht hat, an der nächsten Stelle beseitigt, und der Weg ist jetzt zum ersten Mal durch Proben gedeckt.
Intern — die Fläche Wärme/Klima hat ein Konzept statt vier Papiere. Was für Heizen, Warmwasser und Kühlen gilt, stand verteilt: zwei Bauform-Konzepte zur Split-Klimaanlage in docs/ und zwei Papiere außerhalb des Repos. Die Fehler dieser Fläche saßen genau an der Naht — eine Aussage über eine Klimaanlage (die keinen Warmwasserkreis hat) wurde als Regel über alle Wärmepumpen gelesen; so ist der Betriebsmodus-Kanon ohne warmwasser entstanden. Neu ist docs/KONZEPT-WAERME-KLIMA.md: Grundsatz (der zugeordnete Zähler entscheidet, nicht die Bauart · Zähler und Nutzen müssen dieselbe Abgrenzung tragen), Größen-Matrix und Auflösungen, Erfassungs-Kanon K1–K5, die aus dem Layer erzeugte Vorrangkette der Sperrgründe, Kennzahlen samt Nenner-Herkunft und Wetternormierung, die Sicht-Regeln, Split-Klimaanlagen als Kapitel 8, Datenquellen-Fläche und Daten-Checker, die benannten Grenzen und eine Wächter-Tabelle mit derselben Spalte „gesichert durch”, die ADR-002 führt. Die beiden #263-Dokumente bleiben — sie tragen die Entstehungsgeschichte und bekommen einen Kopfhinweis, dass sie Kapitel 8 sind. Für dich ändert sich nichts: keine Zahl, keine Anzeige, kein Sensor.

[4.0.44] - 2026-09-09 — Eine halbe Prognose ist keine Prognose — und die Ersparnis nennt ihre Alternative beim Namen

Changed

Die Wärmepumpen-Ersparnis heißt „vs. Alternative” statt „vs. Gas” — an sieben Anzeigestellen. Der ersetzte Energieträger ist am Gerät gepflegt und wurde immer korrekt verrechnet (Gas 0,90 · Öl 0,85 · Strom-Direktheizung 1,00) — benannt wurde unbedingt „Gas”. Wer Öl oder eine Strom-Direktheizung ersetzt hat, las über einer richtig gerechneten Zahl die falsche Bezugsgröße. ⚠ Es ändert sich keine Zahl, nur ihre Beschriftung. Die allgemeine Form ist dabei nicht nur höflicher, sondern die einzig mögliche: Der Cockpit-Block fasst mehrere Wärmepumpen zusammen, die verschiedene Träger ersetzt haben können, und „Gas/Öl” ließ den dritten Träger ohnehin aus.

Fixed

Ein unvollständiger Wetterabruf liefert keine Tagesprognose mehr — der HA-Sensor zeigt „unbekannt” (gemeldet von Knallfrosch im simon42-Forum). eedc holt die Prognose je Orientierungsgruppe getrennt; jede hat ihren eigenen Cache-Eintrag. Fiel einer der Abrufe aus, landete nur dessen Eintrag im Negativ-Cache, die übrigen behielten ihren gültigen — und der Lauf rechnete mit den verbliebenen Gruppen weiter. Der Tageswert kollabierte auf deren Anteil: Bei einer Anlage mit 20,24 kWp + 1,74 kWp stand PV-Prognose heute für je eine volle Stunde auf 7,9 statt 92,3 kWh und erholte sich beim nächsten Versand von selbst. ⭐ Das Flag für einen unvollständigen Fan-out gab es seit v3.45.6 — von sechs Konsumenten des Prognose-Kanons hat es genau einer gelesen. Der Riegel sitzt deshalb jetzt im Kanon selbst: Ein Tag mit unvollständigem Fan-out trägt keine Zahlen mehr, die Begründung bleibt stehen und wird protokolliert. ⚠ Sichtbare Folge für Anlagen mit mehreren Ausrichtungen: Der Sensor kann jetzt „unbekannt” melden, wo vorher eine zu kleine Zahl stand. Automationen, die auf Prognose-Sensoren laufen, sollten diesen Zustand abfangen. Anlagen mit einer einzigen Ausrichtung waren nie betroffen — dort entfiele der Sensor lautlos. Die gemessene Erzeugung hängt an keiner Prognose und ist unberührt.
Der Wärme-Vorschlag im Monatsabschluss sieht beide Aufteilungswege (gemeldet von OB73-gif, #411). Wer die Wärme nicht selbst misst, bekommt sie als Schätzung aus Strom × Arbeitszahl vorgeschlagen. Die Weiche, die prüft, ob der Gesamtstrom überhaupt Heizstrom ist, fragte nur den gemessenen Betriebsart-Split ab — den aus dem Betriebsmodus-Sensor abgeleiteten sah sie nicht. Für einen August, in dem eine Split-Klimaanlage ausschließlich gekühlt hat (207 kWh Kühlbetrieb + 7 kWh nicht aufgeteilt), schlug eedc 750 kWh Heizenergie und 186 € Ersparnis vor. Der Code war damit enger als die Regel, die er umsetzt — sein eigener Docstring sagte die richtige Bedingung bereits. ⚠ Betroffen sind nur Anlagen, deren Betriebsart aus einem Modus-Sensor abgeleitet wird; wer eigene Betriebsart-Zähler pflegt, bekam schon vorher keinen Vorschlag. Gespeicherte Werte bleiben unangetastet — eedc ändert nichts von allein; wer einen falschen Vorschlag übernommen hat, korrigiert ihn im Monatsabschluss, und der Daten-Check nennt die betroffenen Monate.
Der Daten-Check rechnet die Arbeitszahl mit denselben Zahlen wie die Anzeige. Die Prüfung auf eine unplausible Arbeitszahl rief die Formel ohne den funktionsfremden Strom auf, während Kachel und Cockpit den Kühl-, Lüft- und Entfeuchtungsstrom aus dem Nenner ziehen. An derselben Zeile rechnete der Prüfer 3,5 und schwieg, während die Oberfläche 107,0 zeigte — genau die Falle, vor der sein eigener Docstring warnt.
Wärmepumpe und Wallbox erscheinen in Cockpit → Tag nur noch, wenn der Tag sie kennt (gemeldet von JayJayX im simon42-Forum). Beide standen unbedingt im Stundenverlauf und als Spalte in der Stundenwerte-Tabelle — als einzige Geräte, die nicht aus der Datenlage kamen. Wer keines von beiden besitzt, sah zwei Flächen im Stapel, zu denen es nichts zu zeigen gab. Beide fragen jetzt dieselbe Erhebung, die Cockpit → Live seit jeher filtert; die Spalte fällt auch aus dem Spalten-Auswähler. ⚠ Ein einzelner fehlender Stundenwert zählt nicht als „nicht vorhanden” — sonst verschwände das Gerät bei der ersten Messlücke. Die flüchtige Legenden-Abwahl bleibt unverändert.
Der gridX-Zugang folgt der neuen Anmeldung und sagt, woran sie scheitert (gemeldet von alexmsenger, #410 — er arbeitet bei gridX und hat denselben Hinweis am selben Tag an vier Projekte gegeben). Beide bisherigen Formen werden nur noch während einer Übergangsfrist akzeptiert: Die Audience ist jetzt an die API-Basis gekoppelt statt fest auf „my.gridx”, und als Bearer dient der access_token statt des id_token. Der alte Token bleibt Rückfall für den Fall, dass der Anmeldedienst keinen access_token liefert, und meldet sich dann im Log; die Audience hat bewusst keinen Rückfall, damit ein Fehler dort sofort durchschlägt statt bis zum Fristende verdeckt zu bleiben. ⭐ Wichtiger als die Umstellung ist der Fehlerpfad: Bis hierher meldete eedc jeden gescheiterten Login als „E-Mail/Passwort prüfen” — auch bei abgelehntem Realm oder abgelehnter Audience, also genau dann, wenn die Zugangsdaten stimmten. Die Begründung des Anmeldedienstes erreicht jetzt die Oberfläche.
Der Anbieter „Viessmann GridBox” nennt E.ON Home beim Namen. Die GridBox ist zum 31.12.2025 samt Daten zu E.ON Home gewechselt, der Viessmann-eigene Zugang ist abgeschaltet — eedc meldet sich längst korrekt dort an, aber es stand nirgends, und die Anleitung wies auf die abgeschaltete Adresse mygridbox.viessmann.com. Anzeigename, Beschreibung und Anleitung nennen jetzt E.ON Home und eon.gridx.de/login. ⚠ Gespeicherte Zugänge und Quellen bleiben gültig — die interne Kennung des Anbieters ändert sich nicht.
Die Suche in den Einstellungen hat einen eigenen Lösch-Knopf (gemeldet von Radiocarbonat im simon42-Forum). Das Suchfeld filtert kategorieübergreifend — steht dort ein Begriff ohne Treffer, bleibt jeder der sieben Reiter leer, und die Sicht ist von einem Defekt nicht mehr zu unterscheiden. Der Melder hielt sie für einen Firefox-Darstellungsfehler. ⛔ Der Weg zurück hing bis hierher am Browser: Auf das native type="search"-✕ ist kein Verlass — Chromium rendert es, Firefox nicht, derselbe Code mit zwei Bedienbarkeiten. Das Feld trägt jetzt ein eigenes ✕, sobald etwas darin steht; das native wird ausgeblendet, damit nicht zwei nebeneinander stehen. ⚠ Es ändert sich keine Zahl und kein Suchverhalten — die Suche gilt weiterhin über alle Kategorien (so beschreibt es das Handbuch), und der Begriff wird weiterhin nicht gemerkt.

[4.0.43] - 2026-09-07 — Abgegebener Strom zählt jetzt auch im Geld — und zwei Zahlen nennen ihre Grundlage

Added

Der Daten-Check erklärt eine unplausibel hohe Arbeitszahl. Wer einen Wärmemengenzähler so verbaut hat, dass er die Wärme von Kessel und Wärmepumpe misst, bekommt eine Arbeitszahl, die durch den Strom nur eines Geräts geteilt wird — im Extremfall Werte um 13. Der Community-Server konnte einen solchen Wert bisher nur sperren; er hat die Geräte nie gesehen. eedc kennt sie und sagt jetzt, woran es liegt und wie du es abgrenzt. ⛔ Deine eigene Anzeige bleibt unverändert — dort siehst du weiterhin, was deine Zähler hergeben; gesperrt wird allein der Vergleichswert in der Community.

Changed

Die Regionalzahl im Community-Vergleich heißt nicht mehr „JAZ”. Unter Community → Regional stand für dasselbe Bundesland eine andere Zahl als unter Community → Komponenten → Wärmepumpe — und beide Sichten öffnet derselbe Mensch. Beide sind richtig, sie beantworten nur verschiedene Fragen: Die regionale Zahl teilt die Wärme aller Anlagen durch den Strom aller Anlagen; Zähler und Nenner stammen damit aus verschiedenen Geräten, eine Arbeitszahl je Anlage ist das nicht. Sie heißt deshalb jetzt „Wärme je kWh Strom” und nennt die Zahl der Anlagen, über die sie mittelt. Die Arbeitszahl der typischen Anlage steht weiterhin unter Komponenten → Wärmepumpe. (Angestoßen von rapahl per PN.)

Fixed

Der Erlös aus „Abgabe an Dritte” kommt jetzt in der Wirtschaftlichkeitsrechnung an (gemeldet von rilmor-mhrs, #402). Mit v4.0.41 kam die Kategorie Abgabe an Dritte dazu; die Energieseite rechnete sofort richtig, die Geldseite nur zur Hälfte. Der gepflegte Erlös stand im SOLL/HABEN-T-Konto und in Cockpit → Jahr, fehlte aber in Auswertungen → Finanzen, im ROI, in den Aussichten und im HA-Sensor — dieselbe Kachel nannte in zwei Sichten zwei Zahlen, und der ROI wurde durch die Umstellung sichtbar schlechter, obwohl das Geld weiterhin floss. ⭐ Jetzt gibt es eine Quelle für den Jahres-Ertrag je Investition, die alle vier Sichten lesen, und in ihr gilt gemessen vor geschätzt: Sobald für mindestens einen Monat ein Erlös gepflegt ist, rechnet eedc aus den gemessenen Monaten hoch und lässt das Feld „Ertrag/Jahr (€)” außen vor. Der Formular-Hinweis am Feld sagt das jetzt auch. ⚠ Ein gepflegtes „Ertrag/Jahr” wird damit an Abgabe-Geräten nicht mehr zusätzlich gezählt — wer beides ausgefüllt hat, sieht jahres_ersparnis_euro, roi_prozent und amortisation_jahre in Home Assistant einmalig sinken; das war vorher eine Doppelzählung. Wer nur Monats-Erlöse pflegt, sieht keine Änderung. ⚑ Und die Zeile heißt jetzt, was sie ist: Im T-Konto stand über dem abgegebenen Strom das Wort „Einspeisung” — eine Einspeisung ist das ausdrücklich nicht. Sie heißt jetzt „Abgabe an Dritte”, mit derselben Bezeichnung wie auf der Energieseite.
Die Vorschau der Reparatur-Werkbank spricht nur noch für das, was sie geprüft hat (gemeldet von Knallfrosch im simon42-Forum). Nach dem Aggregations-Fehler aus v4.0.39 fehlten Stundenwerte. Die Vorschau meldete „keine Wert-Änderungen” und schrieb dazu, ein Neuaufbau würde nichts bewirken — der Melder führte ihn trotzdem aus, und der Tag war repariert. ⛔ Die Meldung war zu weit gegriffen: Die Vorschau vergleicht ausschließlich die gespeicherten Zählerstände mit der Home-Assistant-Statistik. Die Stundenwerte und die Tageszusammenfassung baut der Lauf aus diesen Zählerständen in jedem Fall neu auf — und genau die hatten gefehlt. ⭐ Jetzt nennt die Meldung ihren Gegenstand und ihre Grenze und dazu die eine Zahl, die im Melderfall gefehlt hat: wie viele der 24 Stunden für den Tag gespeichert sind. Im Fall des Melders hätte dort „9 von 24 Stunden gespeichert” gestanden. ⛔ Bewusst kein Abgleich des Aggregats gegen die Snapshot-Summe: Die Aggregation füllt Lücken, löst Doppelzählungen auf und normiert — eine Differenz wäre dort oft legitim, und ein Schwellenwert würde in der Gegenrichtung lügen.
Die Reparatur-Werkbank spricht Deutsch. Sie zeigte die rohen Bezeichner des Backends („0 boundaries_changed”) mitten in einer sonst deutschen Oberfläche. (Aus demselben Screenshot, vom Melder nicht beanstandet.)

[4.0.42] - 2026-09-06 — Das Wetter im Live-Cockpit ist wieder da

Fixed

Cockpit → Live zeigt wieder Wetter, Solar-Aussicht und Verbrauchsprognose. Mit v4.0.40 ist ein Programmierfehler in die Wetter-Route geraten: Beim Umbau für den neuen Verbrauchsprognose-Sensor wanderte die Herkunft des gelernten Verbrauchsprofils in eine eigene Funktion — eine Stelle las sie weiter am alten Ort, an dem es sie nicht mehr gab. ⚠ Betroffen war jede Installation, nicht nur die mit eigenem Verbrauchsprofil: Der Fehler trat auf, sobald der Wetterabruf gelang. ⛔ Und eedc nannte dafür die falsche Ursache — im Live-Cockpit stand „Wetterdaten nicht verfügbar”, als läge es am Wetterdienst; tatsächlich lag es an uns. Der Fehler wurde zusätzlich für bis zu eine Stunde zwischengespeichert, sodass auch ein Neuladen nichts half. ⭐ Jetzt trägt das Verbrauchsprofil seine Herkunft selbst, und eine neue Regression fährt den vollständigen Erfolgsweg der Route — den bisher keine Prüfung durchlaufen hatte: Die drei vorhandenen prüften ausschließlich Abbruchfälle, und eine von ihnen prüfte ausgerechnet auf dieselbe Meldung, die der Fehler erzeugte. Was du tun musst: nichts. Nach dem Update ist das Wetter beim nächsten Aufruf wieder da.

[4.0.41] - 2026-09-06 — Strom, den das Haus abgibt · und ein Community-Vergleich, der die Bauart kennt

Added

Abgabe an Dritte: der dritte Weg hinter deinem Hausanschluss (angestoßen von rilmor-mhrs auf GitHub, #402). eedc kannte für Strom hinter dem Zähler bisher zwei Wege — selbst verbrauchen oder einspeisen. Wer eine Einliegerwohnung, eine Werkstatt oder Mieter mitversorgt, hatte einen dritten: Strom verlässt das Haus, ohne ins Netz zu gehen. Der zählte bis jetzt als Eigenverbrauch und hob Autarkie und Eigenverbrauchsquote an. ⭐ Jetzt gibt es unter Sonstiges die Kategorie „Abgabe an Dritte” mit dem Pflichtfeld Abgabe (kWh); dein Erlös bleibt, wo er ist. Die abgegebenen Kilowattstunden fallen aus Eigenverbrauch, Autarkie und Eigenverbrauchs-Ersparnis heraus und stehen auf der Verwendungsseite als eigene Zeile — in Cockpit → Monat/Jahr, in der Werte-Tabelle, im Tages- und Live-Bild, im Monats- und Jahresbericht. An einer nachgestellten Anlage mit 1.000 kWh PV, 200 kWh Einspeisung und 224 kWh Abgabe: Eigenverbrauch 1.024 → 576 kWh, Autarkie 77,3 → 65,8 %. Was du tun musst: nichts, wenn dich das nicht betrifft. eedc stellt keine bestehende Komponente von allein um — der Daten-Check weist dich an Geräten mit Einspeisung und Erlös darauf hin, umstellen tust du.
Community: JAZ nach Bauart (gefragt von rapahl per PN). Unter Community → Komponenten → Wärme/Klima steht jetzt ein Vergleich, der Luft-Wasser, Sole-Wasser, Grundwasser und Luft-Luft getrennt zeigt, jeweils mit der Zahl der Anlagen dahinter. Die Bauart entscheidet, welche Arbeitszahlen überhaupt erreichbar sind; wer sie in einen Topf wirft, vergleicht Physik statt Anlagen.

Fixed

Der Community-Vergleich der Arbeitszahl rechnet überall gleich (gemeldet von rapahl per PN). Auf einer Seite standen zwei Zahlen über dieselbe Sache: die Kachel oben verglich dich mit deiner Bauart, der Balken darunter gruppierte nach Bundesland und mischte dabei Klimaanlagen mit Erdwärmepumpen. Dahinter lagen fünf Stellen, die die Arbeitszahl mit vier verschiedenen Formeln bildeten — die vollständige stand an keiner: Mal fehlte der Ausschluss nicht belastbarer Monate, mal der Abzug des Kühlstroms, mal der Ausschluss passiv gekühlter Anlagen. ⭐ Jetzt gibt es eine Formel und einen Ort dafür. Deine eigene Zahl und dein Vergleichswert entstehen nach denselben Regeln.
Der Community-Schnitt spiegelt Messungen, nicht Einstellungen. Wer keinen Wärmemengenzähler hat, dessen Wärme rechnet eedc aus Strom × gepflegter Arbeitszahl. Dir selbst hat eedc daraus nie eine Arbeitszahl gezeigt („Wärme ist gerechnet, nicht gemessen”) — an die Community meldete es sie trotzdem, und dort ergab sie durch denselben Strom geteilt exakt die Zahl, die im Einstellungsfeld steht. ⭐ Jetzt gilt dieselbe Sperre in beide Richtungen. Die Mengen — Strom, Heizwärme, Warmwasser — bleiben unverändert und zählen weiter; gesperrt ist allein die Kennzahl. ⚠ Der Vergleich kann dadurch auf weniger Anlagen beruhen als bisher, dafür auf gemessenen.
Der Regionalbalken zeigt nicht mehr die besten Regionen. Er sortierte nach Arbeitszahl und schnitt bei zehn ab — die schwächsten Regionen fielen also systematisch heraus, und jede verbleibende rutschte im Bild nach unten. Die Anlagenzahl in der Überschrift zählte trotzdem alle mit. ⭐ Jetzt entscheidet die Belegdichte: die zehn Regionen mit den meisten Anlagen, deine eigene immer dabei, und die Zahl in der Überschrift meint genau die Anlagen, aus denen die Balken entstanden sind.
Cockpit → Jahr zeigt seine Wärmepumpen-Kennzahlen wieder. Beim Zusammenfassen der Monate gingen 16 Felder verloren: Arbeitszahl, ihr Grund, Zähler und Nenner, die Werte je Funktion, Kühlen, Lüften und Entfeuchten. Die Jahresseite zeigte deshalb „—” ohne Begründung daneben, die Zeilen je Funktion fehlten ganz, und die Restmenge Strom war zu hoch. Die Zahlen lagen längst vor — sie wurden nur nicht gelesen.
Geschätzte Wärme sagt auch im Cockpit, dass sie geschätzt ist. Herkunft („geschätzt: Strom × JAZ 3,5”) und der Vorbehalt an Ersparnis und CO₂ standen bisher nur im Komponenten-Hub. Jetzt tragen Cockpit → Monat und Cockpit → Jahr sie ebenfalls. Es ändert sich keine Zahl, nur was daneben steht.
Der PDF-Jahresbericht liest dieselben Wärmepumpen-Kennzahlen wie das Cockpit. Er bildete seine Arbeitszahl selbst, ohne Grund und ohne die Werte je Funktion — beides steht jetzt dort, aus derselben Quelle wie auf dem Bildschirm.
Der Rechenweg unter der Wärmepumpen-Ersparnis passt zur Zahl darüber. Im Tooltip stand eine Rechnung, die 10 € ergab, während daneben 100 € standen: Der Text wurde im Browser neu zusammengesetzt statt aus dem Ergebnis übernommen. Ebenfalls berichtigt: Der Monatsbericht benennt Herkunft und Vorbehalt jetzt mit denselben Worten wie die übrigen Sichten, die CO₂-Sicht trägt den Vorbehalt bei geschätzter Wärme, und die Kennzahl heißt überall JAZ statt „COP” — eine Jahresarbeitszahl ist keine Momentaufnahme.
Ein HA-Sensor, der seinen Wert verliert, bleibt nicht mit dem alten stehen (⚠ das ändert sichtbar etwas in Home Assistant, s. unten). Ist eine Kennzahl gesperrt — etwa die Arbeitszahl, weil Zähler und Nenner Verschiedenes messen —, meldete eedc bisher gar nichts, und Home Assistant zeigte den zuletzt bekannten Wert unbegrenzt weiter, auch in der Statistik. ⭐ Jetzt meldet eedc den Sensor als „unbekannt” und nennt den Grund als Attribut, und ein Abgleich räumt Sensoren ab, die eedc nicht mehr liefert.
Der Ersparnis-Sensor der Wärmepumpe rechnet wie der Komponenten-Hub. Er baute seine Formel selbst: ohne Abzug des Kühlstroms, mit dem heutigen Tarif für alle Monate — an einer nachgestellten Anlage 10 € statt 100 €, und 66,67 € statt 166,67 €, sobald sich der Strompreis im Jahr geändert hatte. Dieselbe Korrektur erreicht Jahresformel, Vorjahresvergleich und den Detailblock; die Zusatzkosten der alten Heizung zählen jetzt auch im Monatswert, sodass Hub, Cockpit, Export und Aussichten dieselbe Zahl nennen.

Changed

Der Community-Server nennt die Abgabe an Dritte im Datenvertrag. Es kommt kein neues Feld hinzu — was ein Monatswert bedeutet, ändert sich: Eigenverbrauch und Autarkie enthalten den abgegebenen Strom nicht mehr. Bestehende Einträge heilen beim nächsten vollständigen Teilen.

[4.0.40] - 2026-09-05 — Die Tages-Aggregation läuft wieder — und geschätzte Wärme sagt, dass sie geschätzt ist

Fixed

Die Tages-Aggregation schreibt wieder (gemeldet von BMeyendriesch auf GitHub, #408, mit vollständiger Diagnose). Seit v4.0.39 lief bei jeder Anlage, deren Stundenkurve aus Home Assistant kommt, jeder Aggregationslauf ins Leere: der Viertelstunden-Lauf, die Finalisierung um 00:15 und das manuelle Tag neu aggregieren endeten mit „keine Daten”, Cockpit → Tag blieb leer. Die Ursache war eine Weiterleitung, die den mit v4.0.39 eingeführten Vortagsrand nicht kannte — im Log stand bei jedem Lauf ein TypeError, den eedc als „keine Daten” verschluckte. ⚠ Derselbe Fehler hielt still auch den nächtlichen Nachzug der Einstrahlung an, der mit v4.0.39 kam — auf diesen Anlagen ist er dort nie gelaufen. ⭐ Jetzt reicht die Weiterleitung den Parameter durch, und ein Test hält ihre Signatur gegen die ihres Ziels — genau die Stelle, an der es auseinandergelaufen ist. Was du tun musst: einmal Einstellungen → Daten → Mehrere Tage neu aggregieren für die Tage seit deinem Update auf v4.0.39. Die Energie war nie in Gefahr (Zähler und Statistik); die Stundenkurve kommt aus der HA-History und reicht so weit zurück wie deine purge_keep_days (Standard 10 Tage) — für ältere Tage bleibt die Energie, die Kurve nicht.
Die Einstrahlung wird auch für die Vergangenheit nachgezogen (aufgefallen an coolxmad auf GitHub, #353). v4.0.39 ersetzte den vorläufigen Strahlungswert nur für den einen Tag, der gerade die Archivgrenze passiert — alles davor behielt den Modellwert, und ließ sich nicht heilen: Mehrere Tage neu aggregieren braucht die Stundenkurve, die nur wenige Tage zurückreicht. Bei coolxmad hielten sieben August-Tage seinen Doppelerfassungs-Verdacht am Leben. ⭐ Jetzt zieht eedc einmalig je Anlage bis zwei Jahre zurück nur die Wetterzeile nach — Einstrahlung, Bewölkung, Wetterlage und die Performance Ratio —, jede Energie-Spalte bleibt unberührt, keine Stundenkurve nötig. Läuft nachts um 02:20 als zweiter Schritt; ein gescheiterter Abruf kommt beim nächsten Mal wieder.
Die Warmwasser-Achse folgt dem Zähler, nicht der Bauart (gemeldet von 8ear auf GitHub, #404). ⚠ Der Eintrag zu v4.0.39 versprach das schon — dort galt es nur für Split-Klimaanlagen. An einer Luft-Wasser-Wärmepumpe, die nur heizt, weil das Warmwasser ein zweites Gerät macht, standen Balken, Spalte und Legende für Warmwasser weiter als Dauer-Null: die Anzeige fragte allein die Bauart, und eine Luft-Wasser-Wärmepumpe „kann” Warmwasser. ⭐ Jetzt zählt, ob je ein Warmwasser-Wert gepflegt oder ein Zähler zugeordnet ist — nur der Total-Fall lässt die Achse fallen, ein einziger gepflegter Monat (auch mit 0) hält sie. Ein Schieber „macht kein Warmwasser” am Gerät ist bewusst nicht gebaut: Ein Kennzeichen neben dem Zähler müsste bei einer späteren Zuordnung gegen die Messung entscheiden.
Der Wärmepumpen-Hub rechnet die Ersparnis mit dem richtigen Strom. Wer Strom Heizen und Strom Warmwasser getrennt misst und keinen Gesamtzähler daneben pflegt, sah unter Komponenten → Wärme/Klima im Kostenvergleich „Wärmepumpe 0 €” und eine Ersparnis in Höhe der vollen Gaskosten — an einer nachgestellten Anlage 480 € statt 180 €, während Cockpit → Monat und Auswertungen → Komponenten richtig rechneten. Der Hub las den Strom aus dem Gesamtfeld, das bei getrennter Messung leer ist. ⭐ Jetzt rechnet er mit derselben Strom-Definition wie alle anderen Sichten. Dasselbe galt für die Strom-Spalte der Monatstabelle und den Monats-/Saisonvergleich im Strom-Modus — beide zeigten dort 0 bzw. keinen Balken, obwohl die Arbeitszahl daneben stimmte; beide lesen jetzt dieselbe Monats-Zeitreihe wie die Arbeitszahl.
Geschätzte Wärme sagt im Hub, dass sie geschätzt ist. Ohne Wärmemengenzähler rechnet eedc die Wärme aus Strom × gepflegter Arbeitszahl — eine zulässige Schätzung, die Ersparnis und CO₂ speist. Unter Komponenten → Wärme/Klima stand sie bisher als nackte Zahl neben gemessenen; nur die gesperrte Arbeitszahl verriet es. ⭐ Jetzt steht die Herkunft unter der Wärme-Kachel („geschätzt: Strom × JAZ 3,5”), und Ersparnis, CO₂ und der Kostenvergleich tragen den Vorbehalt „Wärme geschätzt — Ersparnis und CO₂ folgen aus der Schätzung”. Denselben Vorbehalt bekommt eine Anlage mit zweitem Erzeuger am Wärmezähler (Gas- oder Ölkessel im selben Heizkreis): Die Ersparnis enthält dessen Wärme, eedc kennt seinen Anteil nicht und rechnet ihn nicht heraus — es sagt, dass er drin ist. Es ändert sich keine Zahl, nur was daneben steht.
Ein Gesamt-Wärmemengenzähler heißt nicht mehr „Heizung 100 %”. Wer Heizung und Warmwasser über einen Wärmemengenzähler misst, trägt die Summe unter Heizwärme ein — und sah im Hub eine Aufteilung „Wärme nach Zweck” mit einem einzigen Segment „Heizung · 100 %”, eine Aussage, die eedc nicht treffen kann. ⭐ Jetzt erscheint die Aufteilung nur, wenn beide Achsen belegt sind; ohne Warmwasser-Achse heißen Verlaufsfläche, Vergleichsserie und Tabellenspalte „Wärme” — das ist in jeder Lage wahr, „Heizung” nur in einer.
Der Wärme-Vorschlag im Monatsabschluss rechnet mit dem Strom derselben Funktion (gemeldet von dietmar1968 im simon42-Forum). An seiner Klimaanlage mit Betriebsart-Zählern wurden 254 kWh Kühlstrom × Arbeitszahl 3,5 = 889 kWh „Warmwasser” vorgeschlagen; und ohne getrennte Strommessung schlug eedc beide Wärmefelder aus demselben Gesamtstrom vor — Lücken füllen übernahm beide, die Gesamtwärme stand doppelt in der Zeile. ⭐ Jetzt entsteht Heizwärme nur aus dem Heizstrom (Betriebsart-Zähler vor getrennter Messung vor Gesamtstrom — und aus dem Gesamtstrom nur, wenn kein Kühl-, Lüft- oder Entfeuchtungsstrom in der Zeile steht), Warmwasser-Wärme nur aus dem getrennt gemessenen Warmwasser-Strom. ⭐ Und der übernommene Vorschlag trägt jetzt die Marke „geschätzt” — bisher galt er jeder Sicht als Messung, und die Arbeitszahl gab die gepflegte Arbeitszahl zurück. Die Beschreibung nennt Basis und Art: „Geschätzt: 254 kWh (Strom Heizbetrieb) × JAZ 3,5 — keine Messung”.
Ein Wert in einem Feld, das dein Gerät nicht führt, lässt sich entfernen (ebenfalls dietmar1968). Verschwindet ein Feld aus dem Monatsabschluss, weil sein Gerät die Größe nicht mehr führt — Warmwasser an einer Split-Klimaanlage, Netzladung ohne „lädt aus dem Netz”, getrennte Ströme nach dem Abschalten der getrennten Messung —, blieb ein vorher gespeicherter Wert unsichtbar in der Zeile: nicht zu sehen, nicht zu entfernen. ⭐ Jetzt meldet der Daten-Checker jeden solchen Wert je Feld und bietet direkt daran „Wert entfernen” — für alle betroffenen Monate, mit Rückfrage und Audit-Eintrag je Monat. eedc löscht und verschiebt weiterhin nichts von allein.
Der Daten-Checker fragt die Zähler-Registry, nicht die Bauart. Vier Prüfungen entschieden nach der Bauart einer Wärmepumpe, welche Zähler sie erwarten und wozu sie schweigen. Für Split-Klimaanlagen war das richtig, für eine Brauchwasser-Wärmepumpe falsch: sie hätte Heizstrom liefern und monatlich Heizwärme pflegen sollen, die dieselbe Registry für dieses Gerät hinter „Weitere Größen” stellt. Und der Hinweis zur Betriebsmodus-Zuordnung erreichte nur Split-Klimaanlagen — eine kühlende Luft-Wasser-Wärmepumpe bekam ihn nie. ⭐ Jetzt fragen alle vier Stellen die Registry, und der Modus-Hinweis erscheint, sobald ein Gerät Kühlbetrieb belegt (Kühlleistung, Kältemenge oder Kühl-Betriebsart), gleich welcher Bauart.

Added

Die Verbrauchsprognose des Tages gibt es als Sensor (gewünscht von OB73-gif auf GitHub, #395). eedc_verbrauchsprognose_heute_kwh über MQTT und HA-Export gleichermaßen — genau die Zahl, die Cockpit → Live unter „Heute” als Verbrauchsprognose zeigt: der Gesamtverbrauch des Tages aus deinem individuellen Stundenprofil, Wärmepumpen-Anteil nach Außentemperatur korrigiert. Der Sensor entsteht erst, wenn eedc ein eigenes Profil aus deiner Historie hat — das Standard-Lastprofil wird bewusst nicht exportiert, ein Modellwert sähe in einer Automation aus wie eine Messung.
Tachostand statt gefahrener Kilometer (Anregung von 8ear auf GitHub, #407). Im Monatsabschluss gibt es beim E-Auto das optionale Feld Tachostand: Trägst du den Kilometerstand vom Monatsende ein, rechnet eedc die gefahrenen Kilometer aus dem Vormonatsstand, zeigt die Rechnung unter dem Feld und übernimmt sie auf Klick in Gefahrene km. Das alte Feld bleibt, wie es ist — wer die Kilometer kennt, trägt sie weiter direkt ein. Ohne Vormonatsstand oder bei rückläufigem Stand gibt es keinen Vorschlag statt eines falschen, dafür einen Hinweis. Mitgenommen: Ein Zählerstand bekommt keine Schätzung aus der Historie mehr — bis jetzt hätte ein Klick auf den vorbelegten Sonstiges-Zählerstand eine Differenz von 0 gespeichert.

Changed

Die Bauart einer Wärmepumpe entscheidet keine Größe mehr — ein Test hält das. Was ein Gerät liefern kann, sagt der zugeordnete Zähler, nicht sein Typ; die Bauart darf vorschlagen (Vorbelegung, Beschriftung) und Kennzahlen abgrenzen, nie entscheiden, was gemessen, gefordert oder gezeigt wird. An dieser Regel ist die Fläche viermal gescheitert. Jetzt steht jede Stelle, die die Bauart liest, klassifiziert in einem Wächter (Backend und Client); eine neue Stelle ist rot, bis sie eingeordnet ist.
API: Die Balkonkraftwerk-Route bietet keinen Vergütungs-Parameter mehr an — sie hat ihn nie gelesen, Balkonkraftwerk-Einspeisung ist unvergütet.

[4.0.39] - 2026-09-04 — Gemessen schlägt vorläufig — und keine Erzeugung fällt mehr unter den Tisch

Fixed

Wer seinem Balkonkraftwerk PV-Module zuordnet, verliert dessen Vergangenheit nicht mehr. Seit v4.0.18 lassen sich einem Balkonkraftwerk eigene PV-Module zuordnen — der Weg, auf dem sich zwei Ausrichtungen abbilden lassen. Wer das an einem bestehenden Gerät tat, dem verschwand dessen Erzeugung anschließend rückwirkend in allen Monaten davor: eedc rechnete die Erzeugung ab da den Modulen zu, und die gab es in jenen Monaten noch gar nicht. ⚠ Auffallen konnte das kaum, weil alle Sichten dieselbe zu kleine Zahl nannten — es gab keinen Widerspruch zu sehen. ⭐ Jetzt entscheidet eedc das je Monat: Solange die Module noch nicht angeschafft waren, trägt das Balkonkraftwerk seine Erzeugung dort selbst. ⚑ Die Werte kommen von allein zurück — sie waren nie gelöscht, sondern wurden beim Anzeigen falsch zugeordnet.
Ein Balkonkraftwerk zählt jetzt auch dort mit, wo es bisher fehlte. Wer ein Balkonkraftwerk ohne zugeordnete PV-Module führt — der Weg, auf dem es bis v4.0.18 erfasst wurde —, bekam an zwei Stellen eine Erzeugung ohne dessen Anteil zu sehen: im Daten-Check und in den Kennzahlen eines einzelnen Monats (Direktverbrauch, Eigenverbrauch, Eigenverbrauchsquote, Autarkie, spezifischer Ertrag). ⭐ Sichtbar wurde es an einer Meldung, die nicht stimmte: Der Daten-Check meldete „Einspeisung (X) > PV-Erzeugung (Y)” und rechnete dabei ohne das Balkonkraftwerk — bei 100 kWh aus den Modulen, 50 kWh vom Balkon und 120 kWh Einspeisung schlug er an, obwohl die Anlage 150 kWh erzeugt hatte. Und die genannte Erzeugungszahl fand man in keiner anderen Sicht wieder, weil Auswertungen → Tabelle und das Cockpit immer schon Module plus Balkonkraftwerk rechnen. ⚠ Bei betroffenen Anlagen ändern sich Zahlen sichtbar, und zwar nach oben: Direktverbrauch und Eigenverbrauch des Monats steigen, Autarkie und Eigenverbrauchsquote ziehen nach. Der spezifische Ertrag rechnet jetzt die Erzeugung beider Erzeuger gegen die Leistung beider — Zähler und Nenner beschreiben wieder dieselbe Anlage. ⚑ Wer seinem Balkonkraftwerk PV-Module zugeordnet hat, war nie betroffen und sieht keine Änderung; dasselbe gilt für Anlagen ohne Balkonkraftwerk. Der Fall des Melders (coolxmad, #353) hat den Weg dorthin gezeigt.
Die Einstrahlung der letzten Tage bleibt kein vorläufiger Wert mehr (aufgefallen an coolxmad auf GitHub, #353). Den Strahlungswert, gegen den eedc die Performance Ratio rechnet, holt es beim Wetterdienst. Für Tage, die weiter als fünf Tage zurückliegen, kommt er aus dem endgültigen Messarchiv; für die Tage davor gibt es das Archiv noch nicht, eedc nahm dort den Modellwert — und ersetzte ihn nie. ⭐ Im Mittel ist dieser Modellwert gut, an bewölkten Tagen aber deutlich zu klein: an einer echten Anlage über 91 Tage gemessen lag er im Median genau richtig, an einzelnen trüben Tagen jedoch bis zum Faktor 8,7 darunter. Eine zu kleine Einstrahlung macht den Vergleichsmaßstab zu klein und die Performance Ratio zu groß — jeder dort gemessene Tag mit einer PR über 1 ging darauf zurück. Und weil der Daten-Check genau daraus seinen Verdacht „PV-Doppelerfassung” bildet, schickte er Anwender in ihre eigene Einrichtung, obwohl dort nichts falsch war. ⭐ Jetzt holt eedc den endgültigen Wert nach, sobald ein Tag alt genug ist: Nachts um 02:20 rechnet es den einen Tag neu, der die Archiv-Grenze gerade passiert hat — mit der endgültigen Einstrahlung, Bewölkung und Wetterlage. Performance Ratio, die Spalte Einstrahlung in Auswertungen → Tabelle und die gelernte Prognose-Korrektur stehen damit auf gemessenen statt vorhergesagten Werten. ⚠ Für die letzten fünf Tage bleibt der Wert vorläufig — das lässt sich nicht abkürzen, das Archiv hat diese Tage noch nicht. ⚑ Tage, die vor dieser Änderung entstanden sind, behalten ihren Wert; wer sie berichtigen will, nimmt Einstellungen → Daten → Reparatur-Werkbank → „Mehrere Tage neu aggregieren”. ⚑ Der nächtliche Lauf lässt einen Tag unangetastet, wenn Home Assistant dessen Stundenverlauf inzwischen nicht mehr vollständig vorhält (kurze Recorder-Aufbewahrung) — eine berichtigte Einstrahlung ist keinen verkürzten Tagesverlauf wert. ⚑ An den Schwellen des Daten-Checks wurde nichts verändert: Steht die Einstrahlung richtig, verschwindet die Falschmeldung von selbst.

⚠ Nachträglich richtiggestellt (September 2026): Auf Anlagen, deren Stundenkurve aus Home Assistant kommt, ist dieser Nachzug in v4.0.39 nie gelaufen — derselbe Fehler, der dort die Tages-Aggregation anhielt (#408), ließ ihn still aussetzen. Seit v4.0.40 läuft er, und der Altbestand wird einmalig nachgezogen. Unauffällig blieb es, weil der Nachzug seinen Abbruch nur ins Log schrieb.
Ein Anlagen-Zählerstand trägt den Tag wieder, auch wenn einzelne Erzeuger eigene Zähler haben (gemeldet von Mathek auf GitHub, #406). Wer seinen PV-Strings am Abend eigene kWh-Zähler zuordnet, deren Sensoren in Home Assistant erst ab dieser Stunde liefern, fand danach den ganzen Tag leer — in seinem Fall 21 Stunden gemessene Erzeugung, die es gab. ⭐ Die Ursache lag tiefer als der Wechseltag: Bisher entschied die Zuordnung, ob der Anlagen-Zählerstand für Tag und Stunde mitzählt — sobald ein Erzeuger einen eigenen Zähler hatte, war er aus. Wer nur einen Teil seiner Strings bezählte, hatte damit eine dauerhaft zu kleine Anlagensumme, und nichts sagte es ihm. ⭐ Jetzt entscheiden die Daten, und zwar je Tag: Liefern alle Erzeuger den ganzen Tag über eigene Werte, gelten diese. Sonst trägt der Anlagen-Zählerstand — und eedc löst ihn auf die Erzeuger auf: Wer gemessen hat, behält seinen Wert, die übrigen bekommen den Rest im Verhältnis ihrer kWp, als abgeleitet gekennzeichnet. Genau so hält es die Monatsebene seit jeher. ⚠ Sichtbar wird das bei Anlagen mit Anlagen-Zählerstand und nur teilweise bezählten Erzeugern: Tages- und Stundenwerte, Performance Ratio, CO₂ und die Finanzen steigen dort auf den Wert, den der Anlagenzähler die ganze Zeit gemessen hat. Anlagen, deren Erzeuger vollständig messen, sehen keine Änderung. ⚑ Zurückliegende Tage holst du mit Einstellungen → Daten → Reparatur-Werkbank → „Mehrere Tage neu aggregieren” zurück — die stündlichen Zählerstände sind gespeichert. Der laufende Tag korrigiert sich binnen einer Viertelstunde von selbst. ⚑ Der bisherige Warnhinweis an der Datenquellen-Zeile („entweder alle oder keiner”) entfällt — er beschrieb eine Einschränkung, die es nicht mehr gibt. ⚑ Im Stundenverlauf wird bewusst nicht verteilt: Was sich dort keinem Erzeuger zuordnen lässt, steht weiterhin als „PV (übrige)” — eine nach kWp verteilte Stundenkurve gäbe Ost und West denselben Verlauf, und den haben sie nicht.
Der Stundenverlauf unter Cockpit → Tag geht wieder auf (gemeldet von BMeyendriesch auf GitHub, #405). Wer seine PV-Strings einzeln misst, sah im Tagesdiagramm einen Quellenstapel, der über der Gesamterzeugung stand — in seinem Beispiel 1,31 kW Strings gegen 0,96 kW Erzeugung; oben stand damit Strom, der unten nirgends blieb. Umgekehrt tauchte an anderen Stunden ein Band „PV (übrige)” auf, obwohl alle Module einen eigenen Sensor haben. ⭐ Beides war dieselbe Ursache: Eine Stundenzeile setzt sich aus zwei Quellen zusammen — den Zählerwerten und der Leistungskurve —, und die beiden meinten verschiedene Stunden. Die Zeile „10 Uhr” trug den Zählerwert von 9–10 Uhr und die Leistungswerte von 10–11 Uhr. ⭐ Jetzt beschreiben beide Hälften dieselbe Stunde. ⚠ Sichtbar ändert sich der Stundenverlauf: Die Aufschlüsselung nach Modulen deckt sich wieder mit der Erzeugungslinie, das Band „PV (übrige)” verschwindet dort, wo es nur aus dem Versatz entstand, und die Aufteilung Heizen/Kühlen einer Wärmepumpe steht in der Stunde, in der sie gemessen wurde. ⚑ Tages-, Monats- und Jahreswerte sind unberührt — über einen ganzen Tag hob sich der Versatz auf; deshalb blieben Bilanz, ROI und CO₂ die ganze Zeit richtig. ⚠ Zurückliegende Tage behalten ihre bisherige Zuordnung, bis du sie neu rechnen lässt (Einstellungen → Daten → Reparatur-Werkbank, Aktion „Mehrere Tage neu aggregieren”); eedc schreibt Vergangenes nicht von allein um. ⚑ Ein kleiner Rest im Stapel kann bleiben und ist dann echt: Wer seine Strings gleichstromseitig misst und die Gesamterzeugung hinter dem Wechselrichter, misst an zwei verschiedenen Stellen — die Differenz ist die Wandlung, keine Rechenfrage.
Die Performance Ratio nennt endlich die Zahl, mit der sie gerechnet hat (aufgefallen an coolxmad auf GitHub, #353). Die Kachel unter Cockpit → Tag zeigt die Formel „Ertrag ÷ (Einstrahlung × kWp)” und setzte darunter eine Einstrahlung ein, die in dieser Rechnung gar nicht vorkommt: die waagerechte Globalstrahlung, wie sie an einer Wetterstation gemessen wird. Gerechnet wird die Kennzahl aber gegen die Einstrahlung auf deine Modulfläche — und die ist bei geneigten Modulen deutlich höher, im Winter um ein Mehrfaches. Wer die Zahl nachrechnete, bekam damit zwangsläufig ein anderes Ergebnis und konnte den Widerspruch nicht auflösen, weil die richtige Bezugsgröße nirgends stand. ⭐ Jetzt steht sie dabei — mit dem Zusatz „auf der Modulfläche” —, und eedc schreibt sie ab sofort zu jedem Tag mit. ⚠ Für Tage vor dieser Änderung bleibt die Zeile leer: die Größe wurde damals nicht gespeichert, und ersatzweise wieder die waagerechte Strahlung zu zeigen wäre derselbe Fehler mit neuem Etikett. Über Verlauf nachberechnen holst du sie für einen Zeitraum nach. ⚑ An der Performance Ratio selbst ändert sich nichts — sie war und ist gegen die Modulfläche gerechnet.
Der Parkplatz-Streifen blitzt beim Öffnen einer Cockpit-Ansicht nicht mehr auf (gemeldet von rapahl im simon42-Forum). Wer Anzeigen geparkt hat, sah den Streifen „Parkplatz (n)” für einen Moment allein neben dem Ladezeichen stehen, bevor Energiefluss und Kennzahlen erschienen — dann rutschte er an seinen Platz. Grund: Was du geparkt hast, weiß eedc sofort (es steht lokal im Browser), der Inhalt der Seite muss dagegen erst geladen werden. ⭐ Jetzt wartet der Streifen, bis die Ansicht steht. ⚑ Betroffen waren die fünf Cockpit-Ansichten (Live, Tag, Monat, Jahr, Aussicht); auf Live fiel es am stärksten auf, weil dort am längsten geladen wird. Es ändert sich keine Zahl und nichts an deinen geparkten Anzeigen.
Ein zweiter Erzeuger mit eigenem Vergütungssatz bringt sein Geld wieder mit (gemeldet von rilmor-mhrs auf GitHub, #402). Wer unter Sonstiges/Erzeuger das Feld „Einspeise-Erlös (€)” pflegt — für eine Erweiterung mit anderem EEG-Satz oder Strom, den er direkt weiterverkauft —, fand den Betrag im SOLL/HABEN-T-Konto nicht wieder: Dort stand statt seiner Zahl das Ergebnis einer eigenen Rechnung mit dem Vergütungssatz der Anlage. Wessen Anlagensatz 0 ct beträgt, sah dadurch gar keine Zeile. ⭐ Jetzt steht dort der Betrag, wie er gepflegt ist — eedc rechnet ihn nicht nach, denn der Satz ist ja ein anderer. Das Jahres-PDF, die Home-Assistant-Sensoren und Cockpit → Jahr tragen ihn seit v4.0.11; das T-Konto zieht damit nach.
Zwei Finanz-Sichten nennen für dieselbe Anlage wieder dieselbe Zahl (ebenfalls rilmor-mhrs, #402). Cockpit → Monat → Finanzen wies der Zeile „PV-Anlage” die gesamte Eigenverbrauchs-Ersparnis zu — obwohl Speicher und Balkonkraftwerk ihren Anteil daran eine Zeile tiefer noch einmal als eigene Zeile führen. Die Summe und die Zeile „Ergebnis nach Stromrechnung” zählten diesen Anteil damit zweimal, und das T-Konto unter Auswertungen → Finanzen kam für denselben Monat auf einen anderen Betrag. ⭐ Die PV-Zeile trägt jetzt ihren eigenen Anteil, und die Kachel sagt es auch dazu. Die Zuordnung bleibt vollständig — der Speicher behält seinen Beitrag, das Balkonkraftwerk seinen; nur beansprucht die PV-Zeile beides nicht mehr zusätzlich. ⚠ Bei Anlagen mit Speicher oder Balkonkraftwerk fällt der Finanz-Saldo im Cockpit dadurch sichtbar niedriger aus — er stimmt jetzt mit dem T-Konto überein. Anlagen ohne beides sehen keine Änderung.
Betriebskosten laufen erst ab dem Anschaffungsdatum (ebenfalls rilmor-mhrs, #402). Die anteiligen Jahres-Betriebskosten einer Komponente standen in jedem Monat im T-Konto — auch in Monaten, die vor ihrer Anschaffung lagen. Bei einem im August gekauften Fahrzeug tauchten sie so noch im September des Vorjahres auf, und zwar allein auf der Kostenseite: Die Ersparnis daneben entsteht aus Messwerten und war dort zu Recht leer. ⭐ Jetzt gilt für die Kosten dieselbe Grenze wie für alles andere — vom Anschaffungs- bis zum Stilllegungsdatum. Vergangene Monate sehen dadurch günstiger aus, und das ist der richtige Wert.
Der Strom eines Erzeugers unter Sonstiges zählt jetzt überall gleich — in der Menge wie im Geld. Ein BHKW, Windrad oder Wasserkraftwerk speist hinter denselben Hauszähler wie die PV-Anlage. In der Energiebilanz zählte sein Strom immer voll mit (Eigenverbrauch, Autarkie, Eigenverbrauchsquote), in der Eigenverbrauchs-Ersparnis dagegen nicht — Auswertungen → Finanzen zeigte deshalb eine Kilowattstunden-Zahl neben einem Euro-Betrag, der zu einer anderen Menge gehörte, und Cockpit → Monat nannte für denselben Monat einen dritten Wert. ⭐ Jetzt liegt beides auf derselben Erzeugung, und Menge × Preis geht wieder auf. ⚠ Bei Anlagen mit einem Erzeuger unter Sonstiges steigen Eigenverbrauchs-Ersparnis, Netto-Ertrag und ROI-Fortschritt dadurch sichtbar — es ist die Zahl, die Cockpit und T-Konto längst zeigten. Anlagen ohne einen solchen Erzeuger sehen keine Änderung. ⛔ Ein Vorbehalt gehört dazu, und er betrifft genau diese Zahl: Wenn du Strom an andere abgibst — Mieterstrom, Allgemeinstrom, ein Nachbarhaus —, dann hat eedc dafür kein Modell. Hinter deinem Hausanschluss kennt die Bilanz nur zwei Wege für eine Kilowattstunde: selbst verbraucht oder eingespeist. Abgegebene Kilowattstunden erscheinen deshalb als dein Eigenverbrauch, und die Ersparnis oben fällt entsprechend zu hoch aus. Das ist keine Folge dieser Änderung — sie macht es nur erstmals in Euro sichtbar. Das Handbuch (Bedienung → Was eedc bei Abgabe an Dritte nicht kann) sagt, was fehlt und warum wir nichts vortäuschen; eine Zusage gibt es dafür nicht. ⚑ Am Gerät ändert sich nichts: Seine Wirtschaftlichkeit steht weiterhin auf „nicht bewertet”, und sein Ertrag wird als „Ertrag/Jahr” gepflegt — eedc kennt bei einem verbrennenden Erzeuger den Brennstoff nicht und bei einem emissionsfreien den Vergleichsmaßstab.
Eine Klimaanlage weist keine Wärme mehr aus, die sie nicht abgeben kann (gemeldet von dietmar1968 im simon42-Forum). Eine Split-Klimaanlage hat keinen Warmwasserkreis — eedc fragt sie deshalb seit einiger Zeit gar nicht mehr nach Warmwasser. Wer den Wert vorher einmal gepflegt hatte, hatte ihn aber weiterhin gespeichert, und gelesen wurde er überall: Unter Komponenten → Wärme/Klima stand er als „Wärme erzeugt”, füllte die Aufteilung Wärme nach Zweck zu 100 % mit Warmwasser, ging in die Arbeitszahl ein und erzeugte eine Ersparnis gegenüber der alten Heizung samt CO₂-Zahl — für Wärme, die das Gerät nie erzeugt hat. Dieselbe Menge lief in Cockpit → Monat, in die Aussichten und in die Home-Assistant-Sensoren. ⭐ Jetzt zählt der Wert an einem solchen Gerät nirgends mehr als Wärme, und wo dadurch keine Arbeitszahl mehr entsteht, steht „—” mit dem Grund daneben statt einer Zahl, die zwei verschiedene Dinge teilt. ⭐ Und die Warmwasser-Achse verschwindet aus der Anzeige — Balken, Spalte und Legende zeigen an einer Klimaanlage keine Größe mehr, die es dort nicht gibt. ⚑ Der gespeicherte Wert bleibt unangetastet: eedc löscht und verschiebt nichts von allein. Der Daten-Checker nennt dir jeden betroffenen Monat und sagt, wohin der Wert gehört, wenn er aus dem Kühlbetrieb stammt — als Nutzenergie Kuehlbetrieb, woraus eedc die Arbeitszahl Kühlen rechnet. ⚠ Bei betroffenen Anlagen fallen „Wärme erzeugt”, die Arbeitszahl, die Gas-Ersparnis und die CO₂-Ersparnis dieses Geräts sichtbar weg — sie standen dort zu Unrecht. Der Stromverbrauch und seine Kosten bleiben vollständig, sie sind ja geflossen. Wärmepumpen mit Warmwasserkreis sehen keine Änderung.
Eine Wärmepumpe zeigt nur noch die Achsen, die es an ihr gibt (angestoßen von 8ear auf GitHub, #404). Unter Komponenten → Wärme/Klima standen Balken, Spalte und Legende für Warmwasser an jedem Gerät — auch dort, wo es dafür weder einen Zähler noch einen Wert gibt. Bei einer Wärmepumpe, die nur heizt (das Warmwasser macht ein zweites Gerät), war das eine Dauer-Null ohne Aussage. ⭐ Jetzt richtet sich die Anzeige danach, was das Gerät liefern kann. ⚑ Ob dir ein Zähler fehlt, sagt weiterhin der Daten-Checker — dieser Block trifft darüber keine Aussage. Es ändert sich keine Zahl.

⚠ Nachträglich richtiggestellt (September 2026): In v4.0.39 galt das nur für Split-Klimaanlagen. An einer Luft-Wasser-Wärmepumpe ohne Warmwasser-Zähler — 8ears Fall — blieb die Achse stehen, weil die Anzeige allein die Bauart fragte. Behoben ist das erst mit v4.0.40.
Der aufgeklappte Speicher-Streifen unter Auswertungen → ROI sagt jetzt, zu welchem Gerät seine Zahlen gehören (gemeldet von Radiocarbonat im simon42-Forum). Wer seinen Speicher erweitert und den alten dabei stillgelegt hat, hat zwei Speicher an einem PV-System — die Zeilenüberschrift nennt auch beide. Der Streifen darunter zeigte trotzdem nur einen Wirkungsgrad, ohne zu sagen welchen: es war immer der des ältesten Geräts, nach einer Erweiterung also der des stillgelegten. Wer dort einen auffällig niedrigen Wert las, suchte den Fehler beim falschen Speicher. ⭐ Jetzt steht jeder Speicher mit seinem eigenen Wirkungsgrad und seinem Namen da. ⚑ Der effektive Ladepreis bleibt bewusst eine einzige Zeile — er ist eine Größe der Anlage und nicht am einzelnen Gerät gemessen; bei mehreren Speichern steht das jetzt auch dran. Wer einen Speicher hat, sieht unverändert das Gewohnte.
Der Hinweis zum Speicher-Wirkungsgrad nennt nicht mehr nur eine mögliche Ursache (ebenfalls Radiocarbonat). Liegt der gemessene Wirkungsgrad deutlich unter dem gepflegten Wert, stand dort ausschließlich „möglicher Hinweis auf Speicher-Degradation”. Bei einem AC-gekoppelten Speicher ist das oft die falsche Fährte: Zwischen den beiden Zählern liegt dann die Wandlung des Batterie-Wechselrichters, sofern hausseitig gezählt wird — der Wert beschreibt die Messstelle und nicht den Speicher. ⭐ eedc kennt die Kopplung deines Speichers und sagt es jetzt dazu. ⚑ Es ist derselbe eine Hinweis, nur ohne die falsche Ausschließlichkeit — und die ausführliche Erklärung steht wie bisher im Handbuch.
Auf dem Telefon lässt sich ein Hinweis wieder lesen, ohne ungewollt in den Parkplatz-Modus zu geraten (gemeldet von Gernot). Wer im Energiefluss einen Knoten antippte, um die Erklärung dazu zu lesen — beim Haus sind das sieben Zeilen —, musste den Finger liegen lassen: Der Hinweis verschwand, sobald man losließ. Nach einer halben Sekunde legte sich dann aber die Parkplatz-Auswahl über die Fläche, denn langes Drücken ist die Geste zum Parken einer Anzeige. Wer lesen wollte, landete im Park-Modus und musste ihn wieder wegtippen. ⭐ Beides ist getrennt: Ein Hinweis bleibt jetzt nach dem Loslassen stehen, bis du woanders hintippst oder weiterscrollst. Und die Park-Geste greift auf dem Telefon nur noch oben am Kopf einer Anzeige, nicht mehr über ihrer ganzen Fläche — der Tipp im Fuß sagt das jetzt auch. ⚑ Am Rechner ändert sich nichts: Der Rechtsklick parkt weiterhin überall auf der Anzeige, dort gibt es die Überschneidung nicht. Es ändert sich keine Zahl.
Wo eedc eine Kennzahl nicht bildet, steht der Grund jetzt sichtbar — auch auf dem Telefon. Sperrt eedc eine Kennzahl bewusst (etwa die Arbeitszahl, wenn Wärme und Strom nicht dieselbe Abgrenzung tragen), stand an ihrer Stelle ein „—”, und der Grund erschien nur, wenn man den Wert mit der Maus berührte oder antippte. Darauf hingewiesen hat einen nichts — der nackte Strich liest sich wie fehlende Datenpflege, und niemand fasst eine leere Zelle an, um eine Erklärung zu suchen. ⭐ Jetzt steht der Grund als sichtbarer Satz unter der Tabelle, einmal je Grund statt in jeder Zeile: in Auswertungen → Tabelle, in der Monatstabelle unter Komponenten → Wärme/Klima und in der Detailübersicht unter Auswertungen → ROI (dort mit dem Namen des Geräts, zu dem er gehört). ⚑ Auf dem Bildschirm bleibt der Hinweis zusätzlich am Wert selbst. Es ändert sich keine Zahl — nur, ob du erfährst, warum eine fehlt.
Der Eigenverbrauch eines sonstigen Erzeugers wird an genau einer Stelle bewertet. Ein BHKW, Windrad oder Wasserkraftwerk speist hinter denselben Hauszähler wie die PV-Anlage — seine selbst verbrauchten Kilowattstunden stecken deshalb bereits in der Eigenverbrauchs-Ersparnis der Anlage. Im T-Konto bekam das Gerät daneben zusätzlich eine eigene Ersparnis-Zeile: derselbe Nutzen, zweimal gezählt. ⭐ Diese zweite Zeile entfällt, und der Hinweis an der Eigenverbrauchs-Ersparnis sagt jetzt, dass der Anteil dort enthalten ist. ⚑ Am Ertrag, den du am Gerät angibst („Ertrag/Jahr”), ändert sich nichts — er bleibt der Weg, einen sonstigen Erzeuger zu bewerten.

Changed

Unter Auswertungen → ROI steht der Wirkungsgrad-Hinweis nicht mehr — er gehört dorthin nicht. In dieser Sicht rechnet eedc mit dem gemessenen Wirkungsgrad, sobald es einen gibt; der gepflegte Wert, über den der Hinweis spricht, geht dort gar nicht ein. ⚑ Im Komponenten-Hub beim Speicher bleibt er — dort zählt der gepflegte Wert wirklich: für die Tages-Vorschau „Speicher voll um”, für Größerer Speicher? und für die Home-Assistant-Sensoren.

[4.0.38] - 2026-09-02 — Eine Arbeitszahl, die überall dieselbe ist

Fixed

Die Arbeitszahl kommt jetzt überall aus derselben Rechnung (gemeldet von dietmar1968 im simon42-Forum). Er sah in Auswertungen → Tabelle eine Arbeitszahl von 0,7, während seine Wärmepumpe bei 2,2 liegt — die Zahl beschrieb kein Gerät seiner Anlage: im Nenner der Strom von Wärmepumpe und Split-Klimaanlage zusammen, im Zähler die Wärme von einem der beiden. eedc kennt die Regeln dafür seit v4.0.36 — eine Arbeitszahl gibt es nur, wenn Wärme und Strom dasselbe meinen —, aber fünf Wege rechneten daneben ihre eigene: die Werte-Tabelle, der COP-Sensor in Home Assistant, der Jahresbericht als PDF, der Monats- und Saisonvergleich und der Effizienz-Trend. ⭐ Jetzt gibt es die Zahl nur noch an einer Stelle — wo Wärme und Strom nicht zusammenpassen, steht überall „—” mit dem Grund daneben, statt an fünf Orten fünf verschiedene Zahlen. ⚠ Zwei Rechenwege ändern sich dabei sichtbar: Strom fürs Kühlen, Lüften und Entfeuchten zählt nicht mehr in den Nenner (er gehört zu keiner Wärme), und der Effizienz-Trend bildet seine Kurve neu aus Wärme und Strom, statt Arbeitszahlen zu mitteln — ein Mittelwert von Quotienten ist keine Arbeitszahl.
Der Community-Vergleich rechnet nicht mehr mit Arbeitszahlen, die keine sind. Wer eine Wärmepumpe und eine Split-Klimaanlage auf einem Stromzähler betreibt, hat eine Arbeitszahl, die zwei Geräte mischt. Bisher ging sie in die anonymen Vergleichswerte ein, die alle anderen sehen. eedc sagt dem Community-Server jetzt mit, ob aus den gemeldeten Mengen überhaupt eine Arbeitszahl gebildet werden darf. ⚑ Spürbar ist das vor allem in kleinen Regionen — dort tragen die Wärmepumpen-Kennwerte oft nur eine Handvoll Anlagen, und eine einzige gemischte Zahl verzieht den Schnitt sichtbar. An deinen eigenen Zahlen ändert sich nichts — nur an denen, die du von anderen siehst, und die anderen von dir.
Das Verbrauchsprofil sagt jetzt, auf wie vielen Stunden es steht. Für die Prognose baut eedc aus deinen Messwerten ein eigenes Tagesprofil, sobald zwei Tage je Wochentag-Klasse vorliegen. Der Hinweis nannte bisher nur die Tage — und ein „Tag” entsteht schon aus einer einzigen gemessenen Stunde. „2 Tage” las sich damit wie eine Güte, die noch nicht da war. Jetzt steht die Zahl der Stunden dabei, aus denen das Profil tatsächlich gebildet ist. ⚑ An der Prognose selbst ändert sich nichts — fehlende Stunden werden weiterhin aus dem Standardprofil ergänzt.
Die Arbeitszahl-Spalte im Wärmepumpen-Hub folgt jetzt derselben Regel wie alle anderen. Unter Komponenten → Wärmepumpe führt die aufklappbare Monatsdaten-Tabelle je Monat eine JAZ-Spalte. Sie rechnete als Einzige noch selbst — Wärme ÷ Strom auf den Rohwerten — und wusste deshalb nichts von dem, was eedc sonst berücksichtigt: Strom fürs Kühlen, Lüften und Entfeuchten gehört nicht in den Nenner einer Wärme-Kennzahl, und wo die Wärme nicht gemessen, sondern gerechnet ist, gibt es überhaupt keine Kennzahl. ⭐ Sie liest den Wert jetzt aus derselben Quelle wie die Kacheln darüber — damit nennt der Hub für denselben Monat am selben Gerät nicht mehr zwei verschiedene Arbeitszahlen. ⚠ Und wo es keine gibt, steht „—” mit dem Grund statt einer 0,00. Das traf vor allem Split-Klimaanlagen: Sie verbrauchen Strom, geben aber bauartbedingt keine messbare Wärme ab — in ihrer Zeile stand deshalb bisher zuverlässig eine Null, die wie ein gemessener Wirkungsgrad von null aussah. ⭐ Und sie zeigt, womit sie gerechnet hat: Wo die Arbeitszahl eines Monats mit anderen Zahlen gebildet wird als in seiner Zeile stehen, steht die Rechnung klein darunter — „210 ÷ 96 kWh“. Damit lässt sich eine Zahl, die auf den ersten Blick nicht zu den Spalten daneben passt, in einem Blick einordnen. Wo Zähler und Nenner die Spalten daneben sind, geht die Zeile ohne Zusatz auf, und es bleibt still. ⚑ Die Mengen sind unberührt — Strom, Heizung und Warmwasser stehen unverändert da.
Die Tageswerte in Auswertungen → Tabelle warten nicht mehr auf den Monatsabschluss (aus #395, OB73-gif). Die Sicht führt zwei Blöcke, und sie leben von verschiedenen Daten: Monatswerte entstehen erst mit einem Abschluss — Tageswerte entstehen von selbst, sobald eedc läuft. Der Tages-Block richtete sich trotzdem nach dem letzten Abschluss. Wer den Vormonat noch offen hatte, landete dort auf einem älteren Monat, und der Knopf „Aktueller Monat” sprang nicht auf den laufenden. ⭐ Er öffnet jetzt auf dem neuesten Monat, für den Tageswerte vorliegen — in aller Regel dem laufenden —, und die Datumsauswahl reicht über den ganzen gemessenen Zeitraum. ⚑ Wer noch gar keinen Monat abgeschlossen hatte, sah dort bisher überhaupt keine Tageswerte, obwohl sie gemessen vorlagen; das betrifft jede frische Installation und ist mit behoben. ⭐ Und der offene Abschluss geht dabei nicht verloren, im Gegenteil: Über der Seite steht jetzt im Klartext, für welchen Monat er fehlt, mit dem Knopf „Abschluss starten” daneben — vorher deutete allein der schiefe Zeitraum darauf hin, und den hielt man eher für einen Anzeigefehler. ⚠ Der laufende Monat gilt nie als versäumt — ein Monat, der noch läuft, kann keinen Abschluss haben. ⚑ Wer rein von Hand pflegt und keine Tageswerte hat, sieht keine Änderung. Es ändert sich keine Zahl, nur welcher Zeitraum beim Öffnen dasteht.
Der Doppelerfassungs-Verdacht nennt jetzt beide Seiten der Rechnung. Meldet der Daten-Check „Verdacht auf PV-Doppelerfassung”, zählte er drei mögliche Ursachen auf — ein Balkonkraftwerk, das im Wechselrichter-Wert schon steckt, einen zweimal zugeordneten Sensor, und eine zu klein eingetragene kWp. ⭐ Eine vierte fehlte, und sie steht im selben Bruch: Die Performance Ratio ist Ertrag ÷ (Einstrahlung × kWp). Sie steigt also nicht nur, wenn die Erzeugung zu hoch ist, sondern auch, wenn die Einstrahlung zu klein angesetzt ist — typisch bei fehlender oder falscher Ausrichtung und Neigung der Module. Wer die drei genannten Ursachen sauber ausschloss, hatte damit keinen nächsten Schritt mehr. Die Meldung nennt die vierte Möglichkeit jetzt samt Weg dorthin, das Handbuch ebenfalls. Angestoßen von coolxmad auf GitHub. ⚠ An der Erkennung ändert sich nichts — dieselben Schwellen, dieselben Tage, es ändert sich keine Zahl.
Eine Diagnose-Meldung im Protokoll verglich Geräte, die nur eine Seite kennt. Im Add-on-Protokoll steht eine interne Prüfung, die zwei Rechenwege gegeneinander hält. Sie verglich dabei verschiedene Mengen: Ein E-Auto mit Leistungs-, aber ohne kWh-Zählersensor taucht nur in einem der beiden Wege auf — und die Prüfung meldete dessen komplette Lademenge Tag für Tag als „Drift”. ⭐ Jetzt vergleicht sie nur Geräte, die beide Wege führen. Auf einer echten Anlage nachgemessen: Die Falschmeldung verschwindet vollständig, die übrigen Abweichungen bleiben unverändert stehen. ⚑ Angezeigte Werte waren nie betroffen — sie stammen aus dem geprüften Weg; betroffen war allein der Eintrag im Protokoll. Aufgefallen bei coolxmad auf GitHub, der der Meldung nachgegangen ist.
Die Arbeitszahl zeigt, womit sie gerechnet hat. Wer im Komponenten-Hub auf die JAZ zeigt (auf dem Telefon: antippen), sah bisher nur die Formel „JAZ = Wärme ÷ Strom”. Jetzt stehen die beiden eingesetzten Zahlen daneben — „209,7 kWh Wärme ÷ 313,6 kWh Strom”. ⭐ Damit lässt sich eine unplausible Zahl selbst einordnen: Eine Wärmepumpe kann nicht weniger Wärme abgeben, als sie Strom aufnimmt — steht dort eine Arbeitszahl unter 1, passt eine der beiden Zahlen nicht zu dem, was das Gerät meldet, und die Ursache liegt in der Zuordnung. ⚠ Der Nenner ist nicht immer der volle Stromverbrauch: Wer den Betriebsmodus erfasst, bei dem sind Kühlen, Lüften und Entfeuchten abgezogen — sonst stünde Kühlstrom im Nenner, ohne dass die Kältemenge im Zähler steht. Die Herleitung zeigt deshalb den Wert, mit dem wirklich gerechnet wurde. ⛔ eedc warnt dabei bewusst nicht: Eine Regel „unter 1 ist falsch” träfe Anlagen mit Heizen und Kühlen auf einem Zähler zu Unrecht. Es ändert sich keine Zahl.
Eine Kilowattstunde sagt jetzt, ob sie Strom oder Wärme ist. Eine Wärmepumpe führt zwei Sorten kWh nebeneinander: den Strom, den sie aufnimmt, und die Wärme, die sie abgibt. Beide tragen dieselbe Einheit — und an mehreren Stellen stand nur „Warmwasser” daneben, ohne zu sagen, welche der beiden gemeint ist. ⭐ Das Feld heißt jetzt „Warmwasser-Wärme”, so wie die Heizwärme daneben schon immer, und die Tabelle unter Einstellungen → Daten nennt die beiden Wärme-Spalten wie Auswertungen → Tabelle: „WP Wärme Heizen” und „WP Wärme WW”. ⭐ Am deutlichsten wirkt das beim Import aus einer eigenen Datei: Beim Zuordnen einer Spalte steht jetzt unter der Auswahl, welche Größe das gewählte Zielfeld erwartet — für jedes Feld, nicht nur für die Wärmepumpe. Diese Erklärung gab es längst, sie war beim Zuordnen nur nicht zu sehen. ⚑ Nützlich, weil viele Hersteller-Exporte die erzeugte Wärme und die aus der Umwelt entnommene Umgebungswärme nebeneinander führen — wird die falsche Spalte zugeordnet, steht die Wärmemenge um ein Vielfaches zu hoch, und die Arbeitszahl rutscht unter 1. Es ändert sich keine Zahl und kein Sensor-Name, nur die Beschriftung. Angestoßen von dietmar1968 im simon42-Forum.
Die Eigenverbrauchs-Ersparnis sagt jetzt, was sie bewertet. Wer einen Erzeuger unter Sonstiges betreibt — ein BHKW, ein Windrad, eine kleine Wasserkraftanlage —, sah im T-Konto eine Herleitung, die sich nicht nachrechnen ließ: Die Kilowattstunden-Zahl daneben enthält diesen Erzeuger (sie muss es, denn der Zähler am Hausanschluss misst die Summe aller Erzeuger dahinter), der Euro-Betrag bewertet aber nur PV und Balkonkraftwerk. Menge × Preis = Betrag ging damit nicht auf. ⭐ Jetzt heißt die Zeile in diesem Fall „PV-Eigenverbrauch-Ersparnis”, und der Tooltip nennt den Grund: Der Anteil aus Sonstiges ist dort nicht bewertet — sein Ertrag wird am Gerät gepflegt (Feld Ertrag/Jahr) und wirkt über ROI und Amortisation. ⚑ Das ist Absicht, keine Lücke: Beide Größen liegen in derselben Summe; würde eedc den Eigenverbrauch zusätzlich in Geld umrechnen, stünde derselbe Nutzen zweimal da. ⚠ Die Multiplikation wird in diesem Fall nicht mehr angezeigt — eine Rechnung, die man nicht nachrechnen kann, ist schlechter als keine; der bewertete Anteil wird bewusst nicht aus zwei gerundeten Zahlen zurückgerechnet. ⚑ Wer keinen Erzeuger unter Sonstiges hat, sieht keine Änderung — Beschriftung und Herleitung bleiben unverändert. Es ändert sich keine Zahl.

Removed

Zwei Felder am Wechselrichter, die nirgends gewirkt haben. Im Formular standen Wirkungsgrad (%) und Hybrid-Wechselrichter — beide wurden erfasst und von keiner Auswertung gelesen. Sie sind entfernt, damit das Formular nur noch fragt, was eedc auch benutzt. ⚑ Deine gespeicherten Angaben bleiben unangetastet und werden nicht gelöscht; sie waren schon vorher ohne Wirkung. Die Wechselrichter-Leistung (kW) bleibt — sie wird gebraucht, unter anderem für die Prognose beim Balkonkraftwerk. Ob dein Speicher am selben Gerät hängt, sagst du eedc weiterhin über die Zuordnung des Speichers, nicht über ein Häkchen am Wechselrichter.

[4.0.37] - 2026-09-01 — Dieselbe Regel auf jedem Weg, und Zahlen, die sagen, was sie sind

Added

Beim Eintippen der nutzbaren Speicher-Kapazität steht daneben, was eedc daraus ableitet (#379, cbrosius). Aus dieser Zahl folgt deine Entladegrenze: eedc rechnet 1 − nutzbar ÷ brutto und behandelt das Ergebnis als den Ladestand, ab dem dein Speicher nichts mehr abgibt — davon hängt unter Wirtschaftlichkeit die Antwort auf „hätte mehr Kapazität geholfen?” ab. Sichtbar war diese Ableitung bisher nur dort, nicht an der Stelle, an der du die Zahl einträgst. ⭐ Das Formular rechnet die Grenze jetzt beim Eintippen vor. ⚠ Mit der Annahme dahinter, ausgeschrieben: eedc unterstellt, die ganze Reserve liege unten. Wer 10/90 fährt, trägt die nutzbare Kapazität korrekt ein (bei 10 kWh brutto also 8), bekommt als abgeleitete Untergrenze aber 20 % statt 10 % — die Kapazitätsfrage fällt dann etwas zu positiv aus. Die Anzeige nennt die Annahme, damit die Abweichung sichtbar ist. ⛔ Ein zweites Feld „Entladegrenze %” gibt es dafür bewusst nicht — es wäre eine Aussage über den Betrieb, und der ist beweglich. Es ändert sich keine Zahl, nur was beim Eintragen dabeisteht.
Die Grundlast lässt sich jetzt Nacht für Nacht ablesen (aus #395, OB73-gif). In Auswertungen → Tabelle führt der Spalten-Picker in der Tagesansicht die neue Spalte „Grundlast”: den Nacht-Sockel dieser einen Nacht in kW — derselbe Median der Nachtstunden 0–5 Uhr, den Cockpit → Monat für den ganzen Monat nennt. ⭐ Damit lässt sich ein Versuch auswerten: Wer ein Gerät über Nacht abschaltet, sieht am nächsten Morgen, was es gekostet hat. Im Tagesverbrauch geht so etwas unter — 50 Watt über acht Stunden sind 0,4 kWh neben vielleicht 20 kWh. Die Spalte ist nicht voreingestellt, sortierbar wie jede andere und geht in den CSV-Export mit ein. ⚠ Sie hat bewusst keine Summen- oder Durchschnittszeile: Ein Median lässt sich nicht addieren, und der Durchschnitt mehrerer Nächte wäre nicht die Zahl, die im Cockpit steht — die bildet ihren Median über alle Nachtstunden des Monats. Beide stimmen und beantworten verschiedene Fragen; eine dritte Zahl soll daneben nicht entstehen. ⚠ Wo für eine Nacht nichts gemessen wurde, steht „—” und keine 0; wurde nur ein Teil der Nachtstunden erfasst, steht der Wert aus diesem Teil.

Fixed

Wer seine Werte per MQTT schickt, bekommt jetzt dieselbe Zähler-Regel wie alle anderen. eedc sagt zu: Entweder die Anlagensumme oder die Einzelwerte — nie beides; sobald ein Erzeuger einen eigenen kWh-Zähler bekommt, zählt für Tag und Stunde nur noch, was je Erzeuger gemessen ist. Im MQTT-Betrieb galt das nicht: Dort gewann das anlagenweite Topic pv_gesamt_kwh, und die je Wechselrichter gemessenen Werte zählten nur, wenn es fehlte. Wer beides lieferte, sah in der Heute-Kachel die Anlagensumme, während ein Home-Assistant-Anwender mit derselben Einrichtung seine gemessenen String-Werte sah. ⭐ Jetzt gilt in beiden Betriebsarten dieselbe Reihenfolge: gemessene Einzelwerte → sonst der Anlagen-Zähler → sonst die Leistungs-Integration. ⚠ Doppelt gezählt wurde nie, und es bleibt dabei — es gilt das eine oder das andere. ⚠ Wenn du das Anlagen-Topic schickst und nur einen von mehreren Wechselrichtern, wird deine Heute-Zahl kleiner: eedc rechnet dann mit dem, was wirklich je Erzeuger gemessen ist. Der Daten-Check nennt dir das Gerät, dem der Zähler fehlt — schick ihn mit, dann stimmt beides. ⚑ Wer nur Wechselrichter-Topics oder nur das Anlagen-Topic schickt, merkt keine Änderung.
Die PV-Prognose-Sensoren tragen eine Nachkommastelle. Die Home-Assistant-Sensoren PV-Prognose heute, Rest heute, morgen, übermorgen, in 3 Tagen, die vier Vormittag-/Nachmittag-Werte und heute (nachgeführt) standen bisher als ganze Zahlen in HA. Für einen Jahresertrag ist das richtig — bei 12.345 kWh sind Nachkommastellen Scheingenauigkeit. Eine Tagesprognose bewegt sich aber zwischen 0 und 60 kWh, und dort ist eine ganze Zahl grob: Rest heute fällt über den Nachmittag in Ein-Kilowattstunden-Stufen, statt gleichmäßig. ⭐ Der eigentliche Grund ist eine Summe: Rest heute plus das heute bereits Erzeugte ergibt heute (nachgeführt). Werden die Summanden einzeln auf ganze Zahlen gerundet, geht diese Rechnung sichtbar nicht mehr auf — aus 12,5 + 6,5 = 19,0 wird 12 + 6 = 18. Dass sie aufgeht, war der Kern der Korrektur aus 4.0.36; die Anzeige nahm sie danach wieder auseinander. Gemeldet von Burkard im simon42-Forum, der den Wert über einen ganzen Nachmittag gegen das Stundenprofil nachgerechnet hat. ⚑ MQTT und REST liefern weiterhin dieselbe Zahl — die Ausnahme gilt an beiden Wegen. ⚠ Alle übrigen kWh-Sensoren bleiben ganzzahlig, und es ändert sich weder ein Sensor-Name noch eine Entität; die HA-Historie zeigt für zurückliegende Zeitpunkte weiter die alten Werte.
Wo eedc nichts bewertet, steht jetzt „—” statt einer Null. In Auswertungen → ROI rechnet eedc bei Wallbox und Sonstiges keine Einsparung selbst — dort zählt allein das gepflegte Feld „Ertrag/Jahr (€)”. War es leer, stand in der Zeile trotzdem eine Zahl: 0,00 €, und bei einer Komponente mit gepflegten Betriebskosten sogar ein negativer Betrag — für ein Mini-BHKW mit 300 €/Jahr Betriebskosten etwa „−300,00 €” in der Spalte Jährliche Einsparung. Der Abzug selbst war richtig, er stand nur in der falschen Spalte: Eine Zahl dort sagt „so viel spart dieses Gerät”, und genau das war unbekannt. ⭐ Jetzt bleiben Einsparung, ROI, Amortisation und CO₂ dieser Zeile leer, und der Tooltip nennt den Grund samt Weg — dieselbe Haltung, die eedc bei einer Wärmepumpe ohne gepflegten Wärmebedarf schon einnimmt. Die Anschaffungskosten zählen weiter, und die Zeile senkt die Anlagensumme nicht mehr. ⚑ Passend dazu: Ein Verbrauchszähler (Gas, Wasser, Öl) wird ausdrücklich nicht bewertet — im Komponenten-Hub stand das längst, in der ROI-Tabelle behauptete eine 0 das Gegenteil. ⚠ Eine gepflegte 0 bleibt deine Aussage und wird weiterhin als bewertete Zeile gerechnet.
Die Speicher-Kapazität steht jetzt so da, wie sie gepflegt ist. Unter den Vollzyklen nennt eedc die Kapazität, auf die sich diese Zahl bezieht — und rundete sie dabei auf ganze Kilowattstunden: Aus gepflegten 7,5 kWh wurde die Zeile „Kapazität 8 kWh”. ⭐ Gerechnet wurde immer mit dem gepflegten Wert — im gemeldeten Fall ergeben 1.433 kWh Entladung die angezeigten 191,05 Vollzyklen, mit 8 kWh wären es 179. Wer die Zahl nachrechnen wollte, kam deshalb auf ein anderes Ergebnis als eedc, obwohl eedc recht hatte. Die Zeile trägt jetzt eine Nachkommastelle, wie überall sonst, wo eine Speicherkapazität angezeigt wird. Gemeldet von Burkard im simon42-Forum, mit der Gegenrechnung. ⚑ Wirkt in Cockpit → Tag, Monat und Jahr/Gesamt. ⚠ Es ändert sich keine Kennzahl, nur ihre Beschriftung.
Cockpit → Jahr/Gesamt sagt, warum zwei Zahlen verschieden weit reichen. Die Kennzahlen oben zählen jeden Monat, der Daten trägt — also auch den laufenden. Die Energie-Bilanz darunter rechnet nur über die abgeschlossenen Monate, damit ihr Vergleich nicht einen angefangenen Monat gegen einen vollen Vorjahresmonat stellt. Beide Zeiträume standen schon dabei; warum sie sich unterscheiden, stand nirgends — und so las sich die größere Zahl direkt über der kleineren wie ein Widerspruch, obwohl beide stimmen. ⭐ Die Blöcke tragen den Grund jetzt in ihrer Kopfzeile („Jan–Aug (bis heute)” gegen „Jan–Jul (abgeschlossen)”), und unter der Vergleichstabelle steht er ausgeschrieben. Danke an Burkard, der beide Zahlen gegen seine Langzeitstatistik geprüft hat, bevor er fragte. ⚠ Bei einem abgeschlossenen Jahr fallen beide Zeiträume zusammen — dort ändert sich nichts. Es ändert sich keine Zahl, nur ihre Einordnung.
Wer eine Prognosequelle wählt, bekommt sie auch für die Folgetage. In der Live-Kachel Solar-Aussicht standen unter der Überschrift der gewählten Quelle für Morgen und Übermorgen trotzdem eedc-Zahlen — bei Solcast für beide Tage, bei Solar Forecast ML für Übermorgen. Grund: eedc las dort nur das Stundenprofil der Quelle; den Tageswert, den dieselbe Quelle danebenstellt, hat es nicht ausgewertet. Wessen Quelle kein Stundenprofil liefert oder nicht so weit reicht, sah deshalb zwangsläufig die eedc-Prognose. ⭐ Jetzt gilt die Reihenfolge: Tageswert der Quelle → ihr Stundenprofil → eedc — und der Rückfall auf eedc steht weiterhin klein am Tag, wenn die Quelle einen Tag wirklich nicht abdeckt. Gemeldet von Burkard im simon42-Forum, mit gegengerechneten Zahlen. ⚑ Auswertungen → Prognose hat schon immer alle drei Tage aus der Quelle gelesen; Cockpit → Aussicht und die Home-Assistant-Sensoren rechnen weiterhin bewusst mit der eedc-Prognose. ⚠ Wer die eedc-Standardquelle nutzt, sieht keine Änderung.
Nach einem Geräte-Tausch meldet der Daten-Check nicht mehr die Zeit davor. Wer seinen Speicher aufrüstet und dabei dem Handbuch folgt (altes Gerät stilllegen, neues mit der Gesamtkapazität anlegen), bekam anschließend eine Warnung über die gesamte Zeit vor dem Wechsel — sinngemäß „114 Tage kennen nur den Ladestand eines von 2 Speichern“. An diesen Tagen gab es aber nur einen Speicher; ein zweiter Ladestand konnte gar nicht entstehen. ⚠ Und der angebotene Knopf konnte es nicht beheben: „Zeitraum neu aggregieren“ lief durch, danach stand dieselbe Meldung wieder da — er kann keinen Wert erzeugen, den es nie gab. Beides ist behoben: Der Check fragt jetzt für jeden Tag, wie viele Speicher an diesem Tag da waren. Gemeldet von Radiocarbonat im simon42-Forum. ⚑ Aus demselben Grund fordert eedc an einem ersetzten Klimagerät keinen Betriebsmodus-Sensor mehr an — auch das war ein Hinweis, den niemand mehr auflösen konnte. ⚠ Wer nie ein Gerät ersetzt hat, sieht keine Änderung.
Die „Beheben“-Verweise im Daten-Checker führen direkt an die richtige Stelle. Klickst du bei einem Befund auf Beheben, öffnet sich jetzt der passende Block auf der Seite — und wo ein bestimmter Monat fehlt, gleich die Erfassung genau dieses Monats. Bisher landetest du bei einem Teil der Befunde auf der Übersicht und musstest den richtigen Block selbst suchen. Danke an Radiocarbonat im simon42-Forum für den Hinweis. ⚠ An den Prüfungen selbst ändert sich nichts — dieselben Befunde, derselbe Text, nur der Weg zur Lösung ist kürzer.
Der Zähler-Hinweis nennt seine teuerste Folge (aus #395, OB73-gif). Meldet der Daten-Check „N von M Komponenten ohne vollständige kWh-Zähler-Abdeckung”, zählte er als Folgen bisher „Prognosen-IST, Heatmap, Lernfaktor und Monatsberichte” auf — lauter Auswertungen, die leer bleiben. Das klingt entbehrlich, und genau deshalb bleibt der Zähler dann offen. ⭐ Die teuerste Folge stand nicht dabei: Der bilanzielle Hausverbrauch je Stunde entsteht als PV + Netzbezug − Einspeisung − Speicher, und ein fehlender Anteil wird darin als 0 gerechnet. Die Stunde bleibt also nicht leer, sie wird zu niedrig — und mit ihr die Grundlast, die als Median der Nachtstunden daraus gebildet wird (Cockpit → Monat, Monatsbericht, HA-Sensor eedc_grundlast_kw). Typisches Bild bei fehlendem Speicher-Zähler: Die Grundlast steht im Sommer nahe null und steigt scheinbar von selbst, je weniger der Akku die Nacht trägt. Beide Meldungen sagen das jetzt, ebenso das Handbuch. ⚑ Nur Speicher und PV sind betroffen — Wärmepumpe, Wallbox und E-Auto stehen gar nicht in dieser Formel, sie sind Teil des Hausverbrauchs. ⚠ Es ändert sich keine Zahl, nur der Text: Wer den Zähler zuordnet, bekommt die richtige Grundlast; wer es nicht tut, weiß ab jetzt, was ihn das kostet.

[4.0.36] - 2026-08-31 — Ein Monat als Bericht, und drei Zahlen, die wieder zusammenpassen

Added

Ein Monat als Bericht (#395, gewünscht von OB73-gif). eedc kannte vier PDF-Berichte, und keiner ließ sich auf einen Monat stellen: Wer die Zahlen eines einzelnen Monats ablegen wollte, hatte keinen Weg dazu. Unter Einstellungen → Berichte & Dokumente steht jetzt der Monatsbericht — die Zahlen eines Monats im Stil der Cockpit-Monatsansicht: Kennzahl-Kacheln, Anteils-Leisten für die PV-Verteilung und die Kategorien, ein Verlaufs-Diagramm mit einem Balken je Tag, das typische Tagesprofil über 24 Stunden, die Spitzenstunden für Netzbezug und Einspeisung, dazu Vorjahresvergleich, Prognose, Grundlast, Speicher, Wärmepumpe, E-Mobilität, Balkonkraftwerk, Sonstiges, Finanzen und CO₂. ⭐ Mit Community-Vergleich: Deine Werte stehen dem Median aller Anlagen gegenüber, die ihre Zahlen für denselben Monat geteilt haben — samt der Angabe, gegen wie viele Anlagen verglichen wurde. ⚑ Du entscheidest beim Erzeugen, was drinsteht: genau ein Monat (voreingestellt der neueste erfasste) und fünf Themenschalter (Energie · Komponenten · Finanzen · CO₂ · Community). ⭐ Und er kann aussehen wie deine Monatsansicht: Hast du dort Anzeigen geparkt, bietet der Dialog an, sie wegzulassen — der Schalter erscheint nur, wenn wirklich etwas geparkt ist, und was er weggelassen hat, steht am Ende des Dokuments. ⚠ Die geparkte Auswahl liegt im Browser, nicht in der Anlage: Wer am Tablet parkt und am PC den Bericht zieht, bekommt dort den vollständigen Bericht. ⚠ Tage ohne gemessene Erzeugung bekommen keinen Balken, auch keinen der Höhe null — eine Null-Säule neben echten Werten würde behaupten, an diesem Tag sei nichts erzeugt worden; wie viele Tage gemessen wurden, steht als Zeile daneben. ⚑ Ist der Community-Server nicht erreichbar, entfällt allein dieser Abschnitt — der übrige Bericht entsteht vollständig, ohne Gedankenstriche und ohne Fehlermeldung. ⛔ Es gibt bewusst kein „anonymisiert” — ein PV-Monatsbericht ist über Ertragsprofil, Standort und Tarif praktisch eindeutig; diese Zusage wäre im Forum nicht zu halten. Wer anonym vergleichen will, nutzt weiterhin den Community-Vergleich mit seiner Kennung. ⛔ Tagesberichte gibt es nicht mit — die Tagesebene trägt dokumentierte Grenzen (Σ Tage ≠ Monat bei CO₂).
Der Dokumente-Dialog ist aufgeräumt. Die Einstellungen eines Dokuments standen bisher außerhalb seiner Karte — der Jahresbericht-Zeitraum in einem Kasten über allen Karten, die Monatsbericht-Optionen in einem Kasten darunter; beide sahen aus, als gälten sie für alles. Jetzt stehen sie in der Karte, die sie steuern. Dazu: Das Auswahl-Kästchen fürs Sammel-ZIP lag genau auf dem Download-Symbol und verdeckte es — es gibt jetzt oben rechts einen Schalter „Mehrere als ZIP”, und im Sammel-Modus wählen dieselben Karten aus, statt zu laden. Die Beta-Kennzeichnung an Anlagendokumentation und Finanzbericht ist entfallen, ebenso der Feedback-Link auf das inzwischen geschlossene Issue #121. ⚠ Und der Zeitraum-Wähler passt wieder in seine Karte: Er war für eine Kopfleiste gebaut und nahm dort die Breite seiner längsten Option — „Gesamtzeitraum (alle Jahre)“ —, ohne zu schrumpfen. In der Kopfleiste war das folgenlos; in der schmaleren Karte stand er über den Rand. Der Monats-Wähler ist mitgezogen: Dort fällt dieselbe Ursache nur nicht auf, weil Monatsnamen kurz sind.

Fixed

Drei Zahlen im Live-Cockpit, die sich nicht addierten (#401, gemeldet von Burkard — und von rapahl am selben Tag per PN, aus der Gegenrichtung). Im Block Solar-Aussicht standen „heute erwartet”, „verbleibend” und der bereits gemessene Ertrag nebeneinander und ergaben zusammen nicht die Kopfzahl: bei Burkard 6,9 kWh gemessen plus 9,0 kWh verbleibend gegen 28,7 kWh erwartet, bei rapahl 23,5 kWh erzeugt gegen eine Kopfzahl von 17,6 kWh. ⭐ Die Ursache waren drei Zahlen aus zwei Rechenwegen: Der Tageswert folgte der Prognosequelle, die du gewählt hast (Solcast, SFML) — „verbleibend” und der nachgeführte Wert kamen dagegen immer aus der eedc-eigenen Prognose. Jetzt stammen alle Zahlen des Blocks aus derselben Quelle, auch Rest, nachgeführter Tageswert und die Vor-/Nachmittagsaufteilung. Damit gilt wieder bisher gemessen + Rest = Tageswert — eine Bilanz, die du nachrechnen kannst. ⚑ Die Kopfzahl „Heute” ist der nachgeführte Wert; die ursprüngliche Tagesprognose steht klein daneben, denn an ihr wird morgens geplant und abends bewertet. ⚠ Deckt deine Quelle einen Tag nicht ab, steht „eedc” dabei, statt still eine fremde Zahl unter ihrer Überschrift zu zeigen; liefert sie gar kein Stundenprofil, gibt es keinen Rest — ihn aus der Kurvenform einer anderen Quelle zu bilden wäre genau die Vermischung, die hier verschwindet. ⚑ Und was der Bildschirm zeigt, geht bei Solcast/SFML ab jetzt bewusst vom HA-Sensor ab: Die MQTT-/HA-Prognosesensoren tragen weiterhin immer die eedc-eigene Prognose — Solcast und SFML liegen über ihre eigene Home-Assistant-Integration ohnehin nativ dort, ein zweiter Export wäre eine zweite Driftstelle. Die Sensor-Referenz sagt das jetzt ausdrücklich; an den Sensorwerten selbst ändert sich nichts. ⚠ Wer die eedc-Standardquelle nutzt, sieht keine einzige veränderte Zahl. Mitgegangen: Die SFML-Spalte der Kennzahl-Matrix trug sieben feste Gedankenstriche, obwohl ihre Werte in derselben Antwort standen; und der Prozentwert des Tagesfortschritts nennt seinen Bezug jetzt im sichtbaren Text.
eedc findet die Prognose-Sensoren jetzt über die Integration statt über ihren Namen (#401, gemeldet von Burkard). Wer Home Assistant auf Englisch eingerichtet hat, dessen SFML- oder Solcast-Entitäten heißen nicht so, wie eedc sie suchte: Die Erkennung lief über eine Liste deutscher Namensteile — die Abschrift einer einzigen Installation. Burkards sechs Entitäten hießen sensor.none_… und fielen durch jede Prüfung; eedc fand null Rollen und sagte es nicht. Er half sich mit sechs Vorlagen-Sensoren, die seine eigenen Werte unter den gesuchten deutschen Namen spiegeln. ⭐ Jetzt fragt eedc Home Assistant, welche Entitäten zu der Integration gehören, und erkennt ihre Rolle an der internen Kennung, die die Integration selbst vergibt — beides unabhängig davon, in welcher Sprache du eingerichtet hast, wie deine Entitäten heißen und ob du sie später umbenannt hast. Eine Entity-ID konnte das nie leisten: Sie entsteht beim Anlegen aus Bereich, Gerät und Entität, du wählst Zusammensetzung und Reihenfolge, und ab Home Assistant 2026.4 lässt sich der Entitätsname ändern. ⚑ Was eedc gefunden hat, steht unter Einstellungen → Stammdaten direkt unter der Quellenwahl — Rolle für Rolle, samt der Angabe, auf welchem der beiden Wege gesucht wurde. Die frühere Namenssuche bleibt als letzter Rückfall erhalten, falls eine Home-Assistant-Version die Frage nicht beantwortet. ⚠ Wer bisher nichts vermisst hat, merkt nichts — es werden dieselben Sensoren gefunden wie zuvor, zusätzlich die, die anders heißen.
Vier Hinweise behaupteten etwas über sich selbst, das nicht zutraf (gemeldet von rapahl per PN, mit Bildern). Kein Rechenweg war falsch — aber zwei der vier rieten zu einer Änderung, die niemand braucht. (1) Ein zugeordneter Kombi-Sensor „Netz (±)” galt als „wirkungslos, wird ignoriert”, sobald daneben die getrennten Felder für Einspeisung und Netzbezug einen Eintrag trugen — auch wenn dort nie eine Nachricht ankam. Ignoriert wurde er nie: eedc verwirft wertlose Felder und benutzt ihn. Jetzt entscheidet auch der Hinweis den Messwert, nicht den Eintrag. (2) Derselbe Preis-Sensor am dynamischen Stromtarif und am Ø-Ladepreis des Speichers galt als „Doppelzählung, nur einem Feld zuordnen” — ein Rat, der eine richtige Zuordnung entfernt hätte. Ein Preis wird nicht summiert; die Warnung gilt jetzt nur noch für Mengen (kWh, km). (3) „Ø Ladepreis fehlt” sagt jetzt, welcher gemeint ist: Es gibt zwei Größen mit fast gleichem Namen — die Annahme aus den Stammdaten, aus der Prognose und ROI rechnen, und den gemessenen Monatswert. Wer den Sensor zugeordnet hatte und den Wert danebenstehen sah, las die Meldung als Widerspruch; sie war richtig, sie nannte nur ihren Gegenstand nicht. (4) Ein Satz neben einer Auswahlliste nannte nur den Zustand („ist bereits zugeordnet”) — daneben liest sich das als Aufforderung, etwas zu tun. Er sagt jetzt, dass nichts zu tun ist.
Rendite und Amortisation im Jahresbericht-PDF standen zu hoch. Der Bericht bildete die Mehrkosten als Summe aller Anschaffungen minus Summe aller Alternativen — über die ganze Anlage und ohne Untergrenze. Hat auch nur eine Position eine teurere Alternative (der Verbrenner, den ein E-Auto ersetzt, ist der Regelfall), zog deren Überschuss die Mehrkosten der anderen Positionen mit herunter: Der Nenner wurde zu klein, Rendite und Amortisationsfortschritt fielen zu günstig aus. ⭐ Cockpit → Übersicht, Auswertungen → ROI, die Aussichten und der Wallbox-Hub rechnen die Größe längst richtig — sie klemmen je Position bei null. Der Jahresbericht war der einzige Ort mit einer eigenen Vorschrift; er nennt jetzt dieselbe Zahl wie der Bildschirm. Deine Daten sind unberührt, es ändert sich allein die Auswertung.
Der gepflegte PV-Anteil der Wärmepumpe wirkt jetzt auch in der Prognose. Unter Cockpit → Aussicht schätzt eedc den Eigenverbrauch aus einem Komponentenmodell, solange keine eigene Historie vorliegt — und rechnete dabei mit einem festen Wert, statt das Feld „PV-Anteil (%)” am Gerät zu lesen. Wer dort einen niedrigeren Anteil gepflegt hatte, sah trotzdem eine zu optimistische Eigenverbrauchs-Ersparnis und einen zu hohen Netto-Ertrag. ⭐ Der Wert bedeutet jetzt, was am Feld steht: Trägst du 30 % ein, deckt die Prognose übers Jahr 30 % des Wärmepumpen-Stroms aus PV — vorher waren es rund 38 %. Die jahreszeitliche Verteilung bleibt dabei erhalten, und das ist der Punkt: Im Januar zieht eine Wärmepumpe am meisten, während das Dach am wenigsten liefert, also liegt der Anteil dort deutlich unter dem Jahresmittel und im Sommer darüber. ⚠ Betroffen ist nur, wer eine Wärmepumpe erfasst, aber noch keine vollständige PV-Bilanz hat; sobald eigene Monatswerte vorliegen, rechnet eedc ohnehin mit den gemessenen Quoten.
Die HA-Sensoren „ROI” und „Amortisation” rechneten mit demselben zu kleinen Nenner — dieselbe Ursache wie im Jahresbericht, hier aber in zwei Werten, die in Home Assistant aufgezeichnet werden. ⚠ Wer mindestens eine Komponente mit einer teureren Alternative pflegt (der häufigste Fall: ein E-Auto, dem ein teurerer Verbrenner gegenübersteht), sieht beide Sensoren einmalig springen: die Amortisation wird länger, der ROI kleiner. In einem gerechneten Beispiel 7,8 statt 10,4 Jahre — die neue Zahl ist die richtige, denn bisher zog der Überschuss dieser einen Position die Mehrkosten aller anderen herunter. Wer keine Alternativkosten pflegt oder überall günstigere, merkt nichts. Deine Daten ändern sich nicht, nur die Auswertung; die Langzeitstatistik in Home Assistant bekommt an dieser Stelle einen einmaligen Knick, weil sie nicht rückwirkend neu gerechnet wird.
Finanzbericht und Anlagendokumentation schrieben ihre Zahlen englisch — „7.9 Jahre”, „12.32 kWp”, „10.0 kWh” in einem ausgelieferten PDF. Der Jahresbericht machte es von jeher deutsch; seine Formatierung lag aber in seiner eigenen Vorlage und war für die anderen Berichte technisch gar nicht erreichbar. Alle vier Berichte nehmen sie jetzt aus einer Quelle. ⚠ Eine Ausnahme bleibt bewusst stehen: Die Koordinaten in der Anlagendokumentation behalten den Dezimalpunkt — sie sind dort kein Messwert zum Lesen, sondern ein Wert zum Weitergeben, und mit Komma ließen sie sich weder in eine Karte noch in ein Formular übernehmen.

[4.0.35] - 2026-08-30 — Eine Auswahl, die sich zurücknehmen lässt

Fixed

Eine einmal getroffene Auswahl ließ sich nie wieder zurücknehmen. Wer am Wärmepumpen-Gerät den „Fremdanteil auf den Zählern” gesetzt hatte, kam nicht mehr auf „Kein Fremdanteil” zurück — die Auswahl wurde beim Speichern stillschweigend verworfen, während sich die beiden anderen Werte speichern ließen. ⭐ Das kostete die Arbeitszahl, und zwar dauerhaft: Ein gesetzter Fremdanteil ist für eedc die Aussage „Zähler und Nutzen stehen für verschiedene Dinge”, also zeigt es statt der Zahl den Grund an. Wer einmal danebengriff — oder die Lagen nur durchprobierte, um sie zu verstehen —, bekam seine Arbeitszahl ohne Eingriff in die Datenbank nicht zurück. Deine Mengen waren nie betroffen, nur diese eine Kennzahl. ⚠ Dieselbe Ursache traf zwei weitere Felder: die Kopplung eines Speichers ließ sich nicht auf „Automatisch (aus der Zuordnung)” zurückstellen, und ein versehentlich eingetragener Verbrenner-Verbrauch an einem E-Auto machte aus einem reinen Stromer dauerhaft einen Plug-in-Hybrid. Alle drei lassen sich jetzt wieder leeren. Gemeldet von rapahl (simon42 T89667).
Der Daten-Check schwieg bei einem Plug-in-Hybrid genau dann, wenn er reden müsste. Stand am Fahrzeug ein unbrauchbarer elektrischer Fahranteil — leer geräumt oder aus einem Import als Text —, hielt der Check ihn für gepflegt und meldete nichts, während die Rechnung mangels Zahl auf 100 % elektrisch fiel: Ersparnis und CO₂-Einsparung fielen zu gut aus, ohne Hinweis. Beide Seiten lesen den Wert jetzt gleich. ⚠ Ein gepflegter Anteil von 0 % war und bleibt ein Wert und entlastet weiterhin.

[4.0.34] - 2026-08-29 — Der Tarif kennt die Uhrzeit, und eine Lücke bleibt eine Lücke

Added

Ein Stromtarif kann jetzt Zeitfenster haben — HT/NT (Discussion #380, gemeldet von MeinerB). Wer zu bestimmten Uhrzeiten einen anderen Arbeitspreis zahlt — „täglich 19 bis 20 Uhr nur die Hälfte”, klassischer Nachtstrom 22 bis 6 Uhr —, konnte das in eedc nirgends hinterlegen: Ein Tarif galt für einen Zeitraum in Tagen und kannte keine Uhrzeit. Jetzt trägst du unter Einstellungen → Strompreise am Tarif ein Fenster ein: Von, Bis, Preis und Wochentage. Mehrere Fenster sind möglich, und ein Fenster darf über Mitternacht laufen. ⭐ Gerechnet wird mit deinen gemessenen Stundenwerten: Jede Stunde bekommt den Preis, der zu ihr gehört, und daraus entsteht der Monatspreis — fielen 3 von 12 kWh ins günstige Fenster, liegt er entsprechend näher am Niedertarif. Dieser Wert steht in Cockpit → Monat als „Ø-Preis HT/NT”, damit er sich nicht mit dem Arbeitspreis aus deinen Stammdaten verwechseln lässt. ⚠ Ohne Stundenwerte rechnet eedc mit dem Preis aus den Stammdaten — also mit dem Hochtarif, und damit zu hoch. Geschätzt wird nichts: Wie viele Kilowattstunden in dein Fenster gefallen sind, weiß eedc nur, wenn der Netzbezug über einen zugeordneten Sensor läuft. Der Daten-Check sagt es dir und nennt beide Wege (Sensor zuordnen, oder im Monatsabschluss unter „Ø Strompreis” den Wert aus deiner Abrechnung eintragen — der schlägt beides). ⛔ Feiertage kennt eedc bewusst nicht, Wochentage schon: Ein Feiertagskalender gilt je Bundesland und Kanton, und ein falscher erzeugte still einen falschen Preis. ⚑ An bestehenden Tarifen ändert sich keine Zahl — ohne Fenster bleibt alles, wie es war. Die dynamischen Börsenpreis-Tarife (Tibber, aWATTar, EPEX) sind davon unberührt; sie lesen Marktpreise und sind etwas anderes als ein fester Zweipreistarif.
Bei „Wäre ein größerer Speicher besser?” lässt sich jetzt der eigene Nachrüstpreis eintragen. Die Auswertung im Speicher-Hub rechnete die Amortisation einer gedachten Erweiterung ausnahmslos mit einem Richtwert von 500 € je kWh — für alle Anlagen gleich, und es gab keinen Weg, eine eigene Zahl einzusetzen. ⭐ Daran hängt kein Zwischenwert, sondern ein Urteil: Unter 15 Jahren sagt eedc „amortisiert in gut X Jahren”, darüber „das rechnet sich nicht”. Wer günstiger nachrüstet, bekam eine entsprechend zu lange Dauer angezeigt — bei 3,2 kWh für 1.000 € statt der angenommenen 1.600 € ist das Faktor 1,6, und damit womöglich ein „rechnet sich nicht” für etwas, das sich zu seinem Preis rechnet. Jetzt steht neben dem Regler ein Feld für den Preis je kWh; bleibt es leer, gilt weiter der Richtwert, und der steht als Vorgabe im Feld. ⛔ Der Wert wird bewusst nicht gespeichert — er gehört zu dieser einen Überlegung, nicht zum Gerät; ein abgelegter Preis würde sonst auch für einen zweiten Speicher gelten, für den er nie gemeint war. Gemeldet von MeinerB (Discussion #380).
Der Daten-Check vergleicht jetzt auch Wallbox, E-Auto und Wärmepumpe mit Home Assistant — bisher tat er das ausschließlich für die PV. Die Prüfung Datenquellen-Drift stellte 90 Tage lang die gespeicherte PV-Tagessumme dem gegenüber, was Home Assistant für denselben Tag ausweist; für jede andere Komponente gab es diesen Abgleich überhaupt nicht. Die Begründung im Code lautete, die anderen Größen „wandern in aller Regel mit” — gemessen war das nie. Diese Werte tragen aber nicht nur die Energiebilanz, sondern auch Amortisation, Ersparnis und CO₂: Eine Abweichung an der Wallbox kostet genauso viel wie eine an der PV. ⭐ Je Gerät, nicht als zweite Summe: In einer gemeinsamen Summe würde ein Plus an der Wärmepumpe ein Minus an der Wallbox ausgleichen, und übrig bliebe eine unauffällige Null. Die PV bleibt eine Summe, weil mehrere Strings dieselbe Sache messen. Es gibt einen Eintrag je Gerät mit dem Tag der größten Abweichung als Beleg — dieselben Schwellen wie bisher (mindestens 2 kWh und mindestens 5 %), damit Rundung still bleibt. ⚠ Ein Wert, den nur eine der beiden Seiten hat, ist eine Lücke und kein Befund — dafür gibt es die eigene Prüfung fehlende Tageswerte; und der Speicher bleibt außen vor, sein Tages-Netto darf 0 sein.
Der Daten-Check meldet eine Ladung, die mehr PV enthält als sie groß ist. Steht an einer Wallbox oder einem E-Auto für einen Monat eine aus PV geladene Menge, die über der gesamten Ladung liegt, sagt eedc das jetzt — mit Gerät, Monat und beiden Zahlen. ⭐ In deinen Auswertungen stand deshalb keine falsche Zahl (eedc rechnet in dieser Lage strukturell mit PV + Netz weiter), und genau das war das Problem: Dabei wird der von dir eingetragene Gesamtwert beiseitegelegt, du siehst also eine Ladung, die du nie erfasst hast — und erfährst nie, dass einer der beiden Werte falsch ist. ⛔ Ohne Reparatur-Knopf: Welcher der beiden stimmt, kann eedc nicht wissen; raten wäre hier so falsch wie beim gebrochenen Zählerstand.

Fixed

Ein Auto, das dein Haus versorgt, zählte in der Live-Ansicht nicht als Speicher. Wer ein bidirektionales E-Auto (V2H) hat, sah unter Cockpit → Live falsche Quoten: Beim Entladen ins Haus stand die Autarkie zu niedrig (67 % statt 86 %), beim Laden die Eigenverbrauchsquote zu hoch (100 % statt 33 %). eedc suchte die Ladung und Entladung des Autos unter einer Bezeichnung, die es im laufenden Betrieb gar nicht gibt — die Rolle „lädt und entlädt” war bekannt, wurde aber eine Zeile später wieder aus dem Namen erraten. Deine erfassten Mengen waren immer richtig, betroffen waren nur die beiden Live-Quoten. ⚠ Ein gewöhnliches, nicht bidirektionales E-Auto ändert sich nicht — unterschieden wird am Häkchen V2H-fähig am Fahrzeug, nicht am Namen.
Ein Speicher, den du unter „Sonstiges” führst, galt beim Entladen als Verbraucher. Legt man einen Stromspeicher als Sonstiges-Gerät mit der Kategorie Speicher an, buchte die Live-Ansicht seine Entladung als Hausverbrauch statt als Erzeugung — dieselbe Verzerrung wie beim V2H-Auto oben, rund 19 Prozentpunkte Autarkie. Ein Speicher, der als eigener Gerätetyp angelegt ist, war nie betroffen. An den erfassten Werten ändert sich nichts, nur die Seite der Bilanz stimmt jetzt.
Der Vergleich „was hätte Gas gekostet” rechnete Zähler und Abzug auf verschiedenen Mengen. Hast du mehrere Wärmeerzeuger und trägt einer davon „Nichts ersetzt (Neubau)” — der Normalfall, sobald eine Split-Klimaanlage neben einer Wärmepumpe steht —, dann verglich eedc die eingesparten Gaskosten nur für die ersetzenden Geräte, zog aber den Stromverbrauch aller ab. Die ausgewiesene Ersparnis war dadurch zu klein (gemessen 704 € statt 1.058 €), und dieselbe Ungleichheit steckte in der CO₂-Ersparnis: Sie buchte die Wärme der ganzen Anlage als vermiedenes Gas und schwieg nur dann, wenn kein einziges Gerät etwas ersetzte. ⚠ Wer genau einen Wärmeerzeuger hat, sieht keine Änderung. Die Verbrauchsanzeigen bleiben bewusst bei allen Geräten — sie beschreiben deine Anlage, nicht die Grundmenge eines Vergleichs.
Unter Cockpit → Tag fehlten die Arbeitszahlen für Heizen, Warmwasser und Kühlen ersatzlos. Der Monat beantwortet diese Frage immer — mit einer Zahl oder mit dem Grund, warum es keine gibt. Der Tag ließ dieselben drei Zeilen kommentarlos weg, und „nicht getrennt gemessen” war damit von „gibt es hier nicht” nicht zu unterscheiden. Jetzt antwortet der Tag wie der Monat. Nichts wird geschätzt: Fehlt ein Zähler, steht der Grund da. ⚠ Kühlen bekommt bewusst keine Tages-Zahl — die Kältemenge wird nicht je Tag aufsummiert, und eine erfundene Erklärung wäre teurer als die fehlende Zeile.
Ein elektrischer Heizstab hinter demselben Wärmezähler kam in keiner Beschreibung vor. Am Wärmepumpen-Gerät gibt es das Feld „Fremdanteil auf den Zählern” mit zwei Lagen — und die Lage „Ein zweiter Erzeuger speist denselben Heizkreis” nannte als Beispiel ausschließlich einen Gas- oder Ölkessel. Bei Daikin- und Nibe-Anlagen ist der Regelfall aber ein anderer: Der Heizstab wird beim Strom getrennt gezählt, seine Wärme läuft durch denselben Wärmemengenzähler. Wer sich in der Beschreibung nicht wiederfand, ließ „Kein Fremdanteil” stehen — und bekam eine systematisch zu hohe Arbeitszahl ohne jeden Hinweis, denn die vorhandene Warnschwelle schlägt nur nach unten aus. Der Heizstab steht jetzt in beiden Beschreibungen, und im Handbuch Wärme & Klima stehen zwei Fragen daneben, mit denen sich die eigene Lage bestimmen lässt. Keine Zahl ändert sich von allein — die Angabe ist und bleibt deine. Gemeldet von rapahl (simon42 T89667).
Ein zurückgesetzter Zähler drückte das individuelle Verbrauchsprofil nach unten. Wer seine Zählerstände per MQTT liefert, bekommt sein Verbrauchsprofil aus stündlichen Differenzen. Sprang ein Zähler dabei zurück — Geräteneustart, Firmware-Update, ein Helfer mit Zyklus —, wertete eedc die betroffene Stunde als 0 kW und nahm sie als vollwertige Messung in den Durchschnitt auf. ⭐ Das Problem war nicht die eine Stunde, sondern ihre Wirkung über die Zeit: Das Profil ist ein Mittelwert über sieben Tage und trägt die gestrichelte Verbrauchsprognose im Live-Chart — eine wiederkehrende Null zog denselben Slot dauerhaft nach unten. Jetzt liefert eine solche Stunde gar keinen Wert, und für die Lücke setzt eedc wie bei jeder anderen fehlenden Stunde seine Standard-Grundlast ein. ⚠ Eine gemessene Null bleibt eine Null — steht der Zähler eine Stunde lang still, ist das eine Aussage und keine Lücke; nur der Rücksprung fällt heraus. ⛔ Hochgerechnet wird nichts: eedc könnte den neuen Stand als Zuwachs deuten, tut es aber bewusst nicht — dieselbe Entscheidung wie bei den Monatswerten in 4.0.33. Betroffen ist ausschließlich der MQTT-Weg; wer Home-Assistant-Sensoren oder die eedc-Datenbank als Quelle hat, merkt nichts.
Der Community-Vergleich deiner Jahresarbeitszahl nannte auf zwei Seiten zwei verschiedene Zahlen. Unter Community → Übersicht wurde deine JAZ mit dem Schnitt von Anlagen derselben Wärmepumpen-Art verglichen, unter Community → Komponenten dagegen mit dem Schnitt über alle Arten — dieselbe Anlage, dieselbe Kennzahl, zwei Prozent-Abweichungen, und keine der beiden Seiten sagte, wogegen sie vergleicht. Eine Sole-Wasser-Wärmepumpe gegen Luft-Wasser-Geräte zu stellen ist die unfairere Messlatte; die Detailseite zeigte ausgerechnet diese. Jetzt gilt überall dieselbe Bezugsgruppe — die eigene Bauart, wo genug Anlagen dafür vorliegen, sonst der Gesamtschnitt —, und die Kachel nennt die Art nur dann, wenn auch wirklich gegen sie gerechnet wurde. ⭐ Vorher hing die Beschriftung an deiner Anlage statt an der Vergleichsgruppe: Bei zu wenigen Anlagen deiner Art stand „JAZ · Luft/Wasser” über einem Vergleich gegen alle. Mit korrigiert: Eine Brauchwasser-Wärmepumpe bekam gar keine Art angezeigt — die Beschriftung kannte vier der fünf Arten. An deinen Werten ändert sich nichts, nur an der Zahl, mit der sie verglichen werden.
Eine unvollständig erfasste PV-Erzeugung sah aus wie eine vollständige. Fehlt in einem Monat bei einem deiner PV-Strings der Wert und ist auch kein Gesamtwert zum Verteilen hinterlegt, kann eedc die Anlagen-Erzeugung dieses Monats nicht bilden — es weiß das intern auch längst, hat es dir aber nirgends gesagt. Die Folge stand trotzdem in deinen Zahlen: Unter Cockpit → Jahr wurde der Monat mit dem summiert, was messbar war, und die Kopfzahl war damit still zu niedrig — mitsamt spezifischem Ertrag und SOLL/IST-Vergleich, die darauf stehen. Am unangenehmsten mit einem Balkonkraftwerk: dann stand in der Monatstabelle eine Zahl, die nur das Balkonkraftwerk enthielt, und in der Spalte PV-Module eine 0,0 — obwohl ein String gemessen hatte (in der Gegenrechnung fehlten 500 kWh in beiden Zahlen). Jetzt sagt eedc es, wo die Zahl steht: unter Cockpit → Monat und → Jahr mit einem Satz über der Bilanz, in der Monatstabelle je Zeile. ⭐ Die Zahl bleibt stehen und wird nicht ausgeblendet — eine Summe mit Lücke ist immer zu niedrig, nie zu hoch; du weißt also, in welche Richtung sie sich bewegt, wenn du nachträgst. Bei einer Differenz ist das anders, und dort blendet eedc weiter aus. ⚠ Kein zweiter Hinweis: Dass die Werte fehlen, meldet der Daten-Check unverändert an einer Stelle mit dem Weg dorthin; der neue Satz beantwortet die andere Frage — worauf diese Zahl beruht.
Ein gemessener Null-Ertrag wurde als „kein Wert” angezeigt. Im Prognosen-Vergleich stand für den heutigen IST-Ertrag ein „—”, sobald er exakt 0 kWh betrug — also nachts, bei Schnee und an dunklen Wintertagen. Das ist genau verkehrt herum: Eine gemessene Null ist eine Aussage („heute kam nichts”), keine fehlende Angabe. Jetzt steht dort 0,0 kWh, und das „—” bleibt dem Fall vorbehalten, für den es gedacht ist: Es wurde tatsächlich nichts gemessen, weil kein Zähler zugeordnet ist.
In der Stundentabelle konnte der Hausverbrauch zu hoch stehen. Er wird als Differenz gebildet — Gesamtverbrauch minus Wärmepumpe, Wallbox und sonstige Verbraucher. Fehlte einem dieser Geräte der Wert einer einzelnen Stunde, wurde es mit 0 abgezogen, und der Hausverbrauch dieser Stunde stand um genau dessen Verbrauch zu hoch da — ohne dass man es sehen konnte. Jetzt bleibt die Zelle leer, wenn ein Gerät, das an diesem Tag misst, für diese Stunde nichts geliefert hat. ⚠ Anlagen ohne das jeweilige Gerät ändern sich nicht: Unterschieden wird über den ganzen Tag — hat ein Gerät zu keiner Stunde etwas beigetragen, ist es schlicht nicht vorhanden, und dann wird auch nichts unterdrückt. Die Summenzeile Verfügbare Energie wird in solchen Fällen stattdessen beschriftet, weil sie als Summe nur zu niedrig sein kann.
Ein stillgelegter Speicher konnte eine Warnung auslösen, die sich nicht wegräumen ließ. Die Prüfung Batterie-Vorzeichen in der Historie vergleicht das gespeicherte Tages-Netto mit einem frischen Abruf aus Home Assistant. Für den Abruf zog sie alle Speicher der Anlage heran — auch einen, der an diesem Tag längst stillgelegt oder auf inaktiv gesetzt war, dessen Sensor in Home Assistant aber weiterläuft. Der stand damit nur auf der HA-Seite, und wenn sein Beitrag das Vorzeichen kippte, meldete eedc einen „vertauschten” Tag samt Knopf Tag reparieren — den die Neuberechnung nicht auflösen kann, weil sie für dieses Gerät nichts schreibt. Die Meldung blieb also stehen, egal wie oft man den Knopf drückte. Jetzt zieht die Prüfung dieselbe Aktiv-Grenze pro Tag wie der Aggregator, der die Werte schreibt. ⚠ Betroffen waren nur Anlagen mit mehreren Speichern; bei einem einzigen greift eine Mindestschwelle vorher.
Vor dem Entfernen von Messwerten wird jetzt gesagt, was ein Zählerstand ist. Meldet der Daten-Check Gerätewerte ohne Monatszeile, steht daneben der Knopf Messwerte entfernen — und darunter stand für jede Datenart derselbe Satz: „Nur wenn sie gar nicht mehr gebraucht werden, entferne sie.” Für einen Zählerstand (Gas, Wasser, Öl) sagt dieser Satz das Gegenteil: Ein Stand ist kein Monatswert, sondern der Anfangswert des Folgemonats. Wird der Juni-Stand entfernt, rechnet Juli gegen den Mai-Stand und weist zwei Monate als einen aus — ohne Hinweis, weil der Zeitraum formal vollständig bleibt. Der Daten-Check und der Lösch-Dialog unter Einstellungen → Daten nennen die betroffenen Zähler jetzt beim Namen und sagen die Folge dazu. ⛔ Verboten wird nichts: Der Knopf bleibt, wo er war — wann ein Stand entbehrlich ist, entscheidest du.
Der HA-Export nannte den falschen Strompreis, sobald ein Spezialtarif der zuletzt gepflegte war. Wer neben dem allgemeinen Tarif einen Wärmepumpen- oder Wallbox-Tarif angelegt hat — beim §14a-WP-Tarif der Normalfall, und meist der zuletzt eingetragene —, bekam dessen Preis als allgemeinen Netzbezugspreis in die eedc-Sensoren. Zwei Stellen des Exports suchten den Tarif von Hand („der mit dem jüngsten Gültig ab”) statt über die dafür zuständige Auflösung, und verloren dabei zwei Unterscheidungen: wofür ein Tarif gilt, und bis wann. Folge: ein ausgelaufener Tarif galt weiter, ein zum 1. des nächsten Monats angekündigter galt schon heute, und ein Spezialtarif galt für alles. ⭐ Die Monatswerte selbst waren richtig — sie lösen den Tarif seit v4.0.5 je Monat auf. Falsch war der Preis, den die Erklärung daneben nannte, und der Rückfallwert, mit dem eedc rechnet, wenn für einen Monat gar kein Tarif hinterlegt ist. In einem gemessenen Fall fiel die E-Auto-Ersparnis dadurch um 18,00 € zu hoch aus (180 kWh Netzladung mit 20 statt 30 ct bewertet).
Vergleichs-Angaben widersprachen den Zahlen, zwischen denen sie standen. Überall dort, wo eedc zwei Zahlen nebeneinanderstellt und dazwischen ein „▲ 12 %“ setzt, kam der Prozentwert aus den Rohwerten hinter den Zahlen — die Zahlen selbst sind für die Anzeige gerundet. Beides zusammen ergab Angaben, die man nicht nachrechnen kann: In der Bilanz unter Cockpit → Tag/Monat/Jahr stand bei einem Netzbezug von 151,4 gegen 150,6 kWh zweimal „151“ mit „▲ 1 %“ dazwischen, im T-Konto neben 250,00 € und 249,50 € ein „▲ 0 %“ — einmal eine Änderung behauptet, wo keine zu sehen ist, einmal umgekehrt. Jetzt beschreibt jede dieser Angaben genau die Zahlen, die daneben stehen, und wo beide gleich aussehen, steht „=“ statt eines Pfeils. ⭐ Dieselbe Klasse hatte Striker in der Werte-Tabelle gemeldet — dort war sie längst behoben, an vier weiteren Stellen aber nicht. ⚠ Im Prognosen-Vergleich wird es dadurch genauer statt gröber: Die Stundentabelle rechnet mit zwei Nachkommastellen, ihre Abweichungsspalte war auf eine festgenagelt — aus „▼ 0,2“ neben 0,20 und 0,04 wird jetzt das richtige „▼ 0,16“.
Die 14-Tage-Prognose rechnete mit dem Bestand von heute — auch für Tage, an denen er ein anderer ist. Wer bei einer Komponente ein Stilllegungsdatum einträgt, liest daneben die Zusage „Ab diesem Datum zählt die Komponente nicht mehr für Live/Prognose”. Für die ersten Tage stimmte das, danach nicht mehr: Unter Auswertungen → Prognose rechneten die weiter entfernten Tage mit der Leistung, die heute installiert ist. Umgekehrt zählte ein PV-Modul, dessen Anschaffungsdatum in der Zukunft liegt, schon ab heute mit — die Prognose stand dann zu hoch für eine Anlage, die es an diesem Tag noch gar nicht gibt. ⭐ Ursache war eine einzige Zahl für alle vierzehn Tage: Die vorderen Tage bekamen ihren Wert aus dem tagesgenauen Rechenweg, der Rest aus einer Kopfzahl von heute — eine Antwort, zwei Bestände. Jetzt fragt jeder Prognosetag denselben Bestand ab, und beide Datumsgrenzen zählen dabei; bisher wurde die Anschaffungsgrenze an dieser Stelle überhaupt nicht geprüft. ⚠ Wer kein Datum im Prognosefenster liegen hat, sieht dieselben Zahlen wie vorher — das ist der Normalfall.
Der Vermerk nach einer Zuordnungsänderung schrieb „Betriebsmodus ()”. Wer bei einer Wärmepumpe oder Klimaanlage die Quelle für den Betriebsmodus ändert, bekommt darunter einen Hinweis, dass die bereits berechnete Historie unberührt bleibt — und in dem stand ein leeres Klammerpaar hinter dem Feldnamen. Grund: Die Beschriftung setzte die Einheit immer in Klammern, und ein Betriebsmodus hat keine. Das ist kein Versäumnis am Feld, sondern seine Natur: Heizen, Kühlen, Aus ist ein Zustand, kein Messwert. Jetzt hängt die Klammer an der Einheit — ist keine da, steht auch keine da.

Changed

Die Karten-Ansicht schmaler Bildschirme hat wieder eine Vorlage. Passt eine Tabelle auf dem Handy nicht, zeigt eedc dieselben Daten als Kartenliste statt sie wegzunehmen. Diese Karte war viermal getrennt gebaut — dreimal von Hand, einmal als Komponente —, und sah deshalb nicht überall gleich aus; eine Änderung an der Darstellung hätte vier Stellen gebraucht, und die fünfte Kopie wäre genauso unbemerkt entstanden wie die vorigen. Jetzt gibt es eine Vorlage, an der die betroffenen Ansichten hängen (PV-Strings, Komponenten-Finanzen, Prognosen-Vergleich); ein Prüfer meldet künftig jeden Nachbau daneben. ⚠ Auf dem Bildschirm ändert sich nichts — die Karten sehen aus wie zuvor, das war die Vorgabe. (Nur Entwicklung, keine Anwender-Wirkung.)

Documentation

Die Sensor-Referenz zeigt jetzt, wie man an die Stundenpreise kommt (Auslöser: Rückmeldung von rapahl per PN). Wer die eedc-Sensorliste in Home Assistant durchsieht, findet neun Preis-Sensoren und darunter keinen Höchstpreis und keinen Preis zu den fünf Rängen — und schließt daraus, dass eedc sie nicht liefert. Er liefert sie, nur als Attribut statt als Sensor: Am eedc_preis_rang hängt rang_profil mit dem Preis jeder Stunde, seit v4.0.27 auch für morgen. Die Referenz nennt jetzt drei fertige Vorlagen für den Template-Editor: Tageshöchstpreis, Ränge mit ihren Preisen und die beste gerichtete Lade-/Entladespanne über die Tagesgrenze hinweg. ⚠ Mit dem Hinweis, der am meisten Zeit spart: Die Ränge werden für Tag und Nacht getrennt vergeben — es kommen bis zu zehn Zeilen, und „Rang 1” kann zweimal vorkommen. Wer auf rang <= 5 filtert, bekommt nicht die fünf billigsten Stunden des Tages.

[4.0.33] - 2026-08-28 — Keine erfundene Zahl, kein ungefragter Sensor

Added

Du entscheidest, welche eedc-Sensoren nach Home Assistant gehen (#400, gemeldet von rapahl (PN) und Knallfrosch (simon42-Forum) unabhängig voneinander innerhalb von 24 Stunden). Seit die gerätebezogenen Sensoren mit v4.0.30 den Weg über MQTT gefunden haben, kommt bei manchem mehr an, als er braucht — und Aufräumen in Home Assistant hilft nicht. rapahl hat den Kern benannt: „Die kann man zwar bereinigen, aber in der Registry bleiben die drin.” Die nächste Discovery bringt den Sensor zurück; eine Abwahl muss deshalb auf der sendenden Seite sitzen. Unter Einstellungen → Home-Assistant-Export lässt sich jetzt jede Sensor-Definition einzeln abwählen (nicht je Gerät — die Auswahl gilt für den Wert, den sie beschreibt). ⭐ Alle Sensoren bleiben per Default an: Eine Voreinstellung wäre eine Wette darauf, welchen Wert du später einmal brauchst — und wer verliert, merkt es erst, wenn die Historie fehlt. Home Assistant kennt keine Zeitmaschine; deshalb kostet die umgekehrte Voreinstellung nur Platz, und der ist zurückholbar. ⛔ Abwählen heißt zurücknehmen, nicht schweigen. Alle drei Topics eines Sensors sind retain — Konfiguration, Wert, Attribute. Würde eedc nur aufhören zu senden, spielte der Broker das festgehaltene Discovery-Topic jedem neuen Abonnenten erneut zu, und die Entität wäre nach dem nächsten HA-Neustart zurück. eedc nimmt deshalb seine eigenen Topics zurück. ⚠ In Home Assistant greift eedc dabei nicht ein — kein Zugriff auf die Registry, keine Statistik wird gelöscht. Die Rückfrage vor dem Speichern warnt bewusst nach der sicheren Seite: lieber zu viel Verlust angekündigt als zu wenig.
Gefahrene Kilometer und Ladevorgänge bilden ihre Monatsmenge jetzt auch über MQTT (Discussion #396, gruaGit). Das Feld bot im Hinweis ausdrücklich den „kumulativen km-Zähler (Auto-Integration/OBD)” als Quelle an — eingelöst war das aber nur für Anwender mit Home Assistant, wo die Statistik die Differenz direkt aus der Recorder-Datenbank rechnet. Wer per MQTT liefert, hat keine Recorder-Datenbank: bei ihm entsteht die Menge nur, wenn eedc die Stände selbst mitschreibt — und genau das tat es für diese beiden Felder nicht. Der Widerspruch war unserer. Jetzt schreibt eedc die Stände mit und schlägt die Differenz vor. ⛔ Nie den Stand: Dass ein roher Tachostand im Monatsfeld landete (13272 statt 1001 gefahrener Kilometer), war ein eigener Fehler und bleibt ausgeschlossen — verboten ist das Durchreichen eines Standes, nicht die Reihe dahinter. Ladevorgänge fahren mit, obwohl es dafür keine Meldung gab: dieselbe Bauform, dieselbe Zeile.
Der Daten-Checker sagt jetzt, warum ein Feld leer bleibt. eedc lehnt einen Zähler ab, der regelmäßig auf null zurückspringt (siehe unten) — für dich sah das bisher genauso aus wie ein Sensor, der schlicht nichts liefert: ein leeres Feld ohne Erklärung. Neu prüft der Daten-Check die MQTT-Zählerreihen der letzten 30 Tage und meldet jede, die fällt — mit Beleg (Zeitpunkt und beide Stände), der Folge und dem Reparaturweg. ⭐ Der Weg führt an die Quelle, nicht in eedc: den fortlaufenden Stand schicken, beim Home-Assistant-Helfer Zurücksetzen auf „nie” stellen. Genau diesen Rat gab eedc bisher nur beim Anlegen eines Helfers — wer seinen Sensor längst zugeordnet hatte, hat ihn nie gelesen. ⛔ Kein Reparatur-Knopf: eedc kann einen Rücksprung nicht heilen, die fehlende Energie steht in keiner Quelle. Der Hinweis verschwindet von selbst, sobald die Reihe wieder steigt — es gibt nichts zu quittieren.

Fixed

Ein täglich zurückgesetzter Zähler ergab einen positiven, plausiblen, falschen Monatswert. Wer per MQTT einen „…heute”-Zähler schickt, bekam unter Cockpit → Monat eine Zahl, die aus dem ersten und letzten Stand des Monats gebildet war — gemessen 5,6 kWh statt 140,0, also eine Monatsmenge unterhalb einer Tagesmenge. Sie sah nicht nach einem Fehler aus, sie kam ungefragt, und sie trug eine hohe Konfidenz. ⚠ Der Tagespfad prüfte längst richtig; der Monatspfad entstand einen Tag später ohne diese Prüfung — und über einen Monat ist der Rücksprung nicht der Ausnahme-, sondern der Normalfall. Ab jetzt liefert eedc dort keine Zahl statt einer falschen, und der Daten-Check daneben sagt dir, warum. ⛔ Hochgerechnet wird sie auch nicht, obwohl es technisch ginge (die Stände liegen stündlich vor; die Summe daraus traf im Versuch 140,2 gegen 144,8 wahre Kilowattstunden, also 3,1 % zu wenig). ⭐ Der Grund ist grundsätzlicher als diese 3 %: eedc will einen täglich zurückgesetzten Zähler gar nicht. Sein Rücksprung liegt auf der Tagesgrenze — und daran hängt fast alles, was danach kommt: Tageswerte, Monatswerte, der Verlauf. Läuft ein Tageswechsel einmal nicht sauber durch, ist nicht eine Zahl etwas zu klein, sondern eine ganze Reihe von Auswertungen betroffen. Genau deshalb rät eedc seit jeher zu einem Zähler ohne Zurücksetzen; eine Hochrechnung würde diesen Rat unterlaufen, statt ihn einzulösen. ⚑ Mitbehoben: Die Rücksprung-Erkennung verglich nur Höchst- und Tiefstwert gegen die Ränder des Zeitraums. Das ist blind, sobald der Startstand zufällig das Minimum und der Endstand das Maximum ist — real trifft das Cockpit → Monat am Monatsletzten spätabends. Geprüft wird jetzt die Folge selbst.
„Sensoren entfernen” räumte unvollständig und meldete trotzdem Erfolg. Der Knopf unter Einstellungen → Home-Assistant-Export zählte drei Sensorlisten von Hand auf. Damit erwischte er 34 der 38 anlagenweiten Sensoren — und keinen einzigen der 18 gerätebezogenen, obwohl die seit v4.0.30 publiziert werden. Zurück blieb, was in der Liste fehlte; die Meldung sagte „erfolgreich entfernt”. Jetzt räumt der Knopf dieselbe Belegung ab, die der Publisher beschreibt.
Prognose- und Preis-Sensoren standen ohne Kategorie in der Liste. In der Sensor-Übersicht erschienen sie mit ihrem rohen internen Namen und einem Platzhalter-Symbol statt mit einer Beschriftung — das sind 20 der 38 anlagenweiten Sensoren. Bestand seit der Einführung der Börsenpreis-Sensoren.
Ein auf Vollbild gestelltes Diagramm ließ sich nicht mit ESC verlassen. Wer eine Anzeige über das ⤢-Symbol vergrößert hatte, kam nur über den Zurück-Knopf wieder heraus — überall in der App, wo dieses Symbol steht, und die Escape-Taste tat nichts. Jetzt schließt ESC das Vollbild. ⚠ Liegt ein Kalender darüber (Cockpit → Tag und → Monat), schließt das erste ESC nur den Kalender und das zweite das Vollbild — jede Ebene für sich, nicht beide auf einmal. Die Bild-Ansicht der Infothek folgt derselben Regel.
Dialoge sagten Hilfsmitteln nicht, dass sie Dialoge sind. Der gemeinsame Dialog-Baustein — er trägt jeden Dialog der App, einschließlich der Rückfragen vor dem Löschen — meldete sich Screenreadern nicht als Dialog und trug keinen Namen, obwohl sein Titel zwei Zeilen weiter steht. Beim Öffnen blieb der Tastaturfokus stehen, wo er war, beim Schließen ging er verloren. Jetzt melden sie sich mit Rolle und Namen, der Fokus springt beim Öffnen in den Dialog und beim Schließen zurück auf den auslösenden Knopf. Sichtbar ändert sich nichts.

Documentation

Die Schwelle im Template-Beispiel nennt jetzt ihre Einheit (Auslöser: Rückmeldung von MartyBr im simon42-Forum). Die Vorlage für einen selbstgebauten Betriebsmodus-Sensor prüft > 20 — in Watt. Wessen Gerät seine Leistung in kW meldet (0,8 statt 800), bei dem ist die Bedingung nie erfüllt: Der Sensor steht dauerhaft auf „aus”, während die Wärmepumpe läuft. ⚠ Und das sieht wie Erfolg aus — man hat gerade alles eingerichtet und liest einen plausiblen Zustand. Das Handbuch nennt jetzt die Einheit, einen Richtwert für kW-Sensoren und den Weg zum Nachsehen (Entwicklerwerkzeuge → Zustände).
Die MQTT-Dokumentation sagt jetzt das Gegenteil von vorher, und das war überfällig. Sie versprach seit jeher, ein täglich zurückgesetzter Zähler „funktioniert ebenfalls; eedc erkennt den Rücksprung”. Im Tagesfenster stimmte das, im Monatsfenster nicht. Statt der Zusage steht dort jetzt die Absage samt Begründung — und der Weg, der funktioniert: den fortlaufenden Stand publizieren. Außerdem hieß die Tabellenzeile für gefahrene Kilometer „Odometer-Differenz” und widersprach damit dem Kasten darüber, der für alle anderen Felder den Zählerstand verlangt.

[4.0.32] - 2026-08-28 — Ein Gerät je Anlage: die eedc-Sensoren ziehen zurück unter ihr Dach

Fixed

eedc legte für jede Komponente ein eigenes HA-Gerät an (gemeldet von rapahl und Knallfrosch, unabhängig voneinander innerhalb von 24 Stunden). Mit v4.0.30 erreichten die gerätebezogenen Sensoren erstmals MQTT — und brachten dabei eine Gliederung mit, die niemand gewollt hatte: Bei einer Anlage mit mehreren Modulflächen, Wechselrichter und Speicher entstanden etliche HA-Geräte mit je einer einzigen Entität, zusätzlich zum Gerät der Integration. rapahls Einwand traf den Kern: „Bisher gab es ein übergeordnetes Gerät mit den darunterliegenden Entitäten … eine einheitliche Struktur wäre mir am liebsten” — und, entscheidend: „Die kann man zwar bereinigen, aber in der Registry bleiben die drin.” Aufräumen in Home Assistant hilft also nicht, es muss auf der sendenden Seite passieren. Ab jetzt hängen wieder alle eedc-Sensoren unter dem einen Gerät deiner Anlage; der Gerätename steht im Sensornamen („Daikin3 ECH₂O COP Durchschnitt”). ⭐ Deine Daten sind davon unberührt: Kennung und Topic hängen an der Komponente, nicht am Gerät — Home Assistant erkennt dieselben Entitäten wieder und hängt sie nur um. Entity-IDs, Langzeitstatistik und Automationen bleiben erhalten, der angezeigte Name ebenfalls. ⚠ Die alten, nun leeren Geräte entfernt HA beim nächsten Neustart; sonst lassen sie sich einmalig von Hand löschen. Kein Sensor entfällt — die Werte je Komponente bleiben vollständig erhalten.

Documentation

Die Sensor-Referenz sagt jetzt, wann ein Sensor als Diagnose gilt. Home Assistant meint damit Systemausgaben über den Gerätezustand (Batterie, Signalstärke, Laufzeit). eedc hat keine Hardware — deshalb gilt: diagnostic trägt, was über eedc selbst aussagt (Letzter Import, Erfasste Monate), nicht über die Anlage. Alles Übrige — auch unveränderliche Stammdaten wie die Investitionssumme — bleibt ein normaler Sensor. Die vier bereits so gekennzeichneten Sensoren entsprechen der Regel; es ändert sich kein einziger Sensor, die Regel war nur nie aufgeschrieben.

[4.0.31] - 2026-08-28 — Taktende Anlagen behalten ihre Betriebsart; zwei Bauarten sind zwei Geräte

Fixed

„Leerlauf” hat die Betriebsart weggeworfen — taktende Geräte verloren ihre Aufteilung (#399, gemeldet und selbst analysiert von Klausnn). Meldet eine Klimaanlage oder Wärmepumpe zusätzlich den Ist-Betrieb (Aktuelle Aktion in Home Assistant), las eedc ihn mit — und behandelte Leerlauf wie „keine Aussage”: Die Stunde fiel unter nicht aufgeteilt, obwohl das Gerät nachweislich auf Kühlen oder Heizen stand. ⚠ Bei einem Inverter-Gerät, das die Solltemperatur hält, ist das der größte Teil der Zeit — die Aufteilung Heizen/Kühlen war damit für genau die Geräte praktisch wirkungslos, für die sie gebaut wurde. Home Assistant selbst macht es richtig und beschriftet die Kachel mit „Leerlauf (Kühlbetrieb)”. Ab jetzt behält Leerlauf den eingestellten Modus; eine Aktion mit Richtung (Heizen/Kühlen/Entfeuchten/Lüften) hat weiterhin Vorrang. ⚠ Sichtbare Folge: Bei taktenden Geräten wandert Strom aus nicht aufgeteilt nach Heizen bzw. Kühlen — die Aufteilung ändert sich deutlich, die Gesamtmenge nicht. Nicht betroffen: Geräte auf Automatik (heat_cool) und Geräte ohne gemeldeten Modus — dort gibt es keine Richtung, auf die zurückzufallen wäre, und geraten wird nicht.
Wärmepumpe und Klimaanlage standen in einer Arbeitszahl (gemeldet von dietmar1968 im simon42-Forum: „Er vermengt vermutlich die Anlagen miteinander”). Wer beides betreibt, hat in eedc zwei Geräte desselben Typs — und ihre Kennzahl wurde über beide gebildet. Das darf sie nicht: Eine Luft-Wasser-Wärmepumpe und eine Split-Klimaanlage haben verschiedene Nutzenergie und verschiedene Vergleichsmaßstäbe, ein gemeinsamer Quotient ist einer aus zwei Welten. eedc zeigt dort jetzt den Grund statt einer Zahl — „Wärmepumpe und Klimaanlage in einer Zahl” —, und im Komponenten-Hub behält jedes Gerät seine eigene Arbeitszahl. ⚠ Sichtbare Folge: Wo bisher schon „—” stand, steht jetzt ein anderer, zutreffender Grund; der alte („nicht alle Geräte melden Wärme”) riet zu einem Wärmemengenzähler, den eine Split-Klimaanlage bauartbedingt nicht haben kann. Neu gesperrt wird nur der Fall, in dem beide Geräte Wärme melden — dort stand bisher eine vermischte Zahl.
Die Tagessicht sagt jetzt, aus welchen Geräten sie summiert (derselbe Melder, derselbe Faden). Unter Cockpit → Monat und → Jahr stand längst „Aggregiert aus: …” mit den Gerätenamen; im Tag fehlte die Zeile — als einzige der drei Sichten. Wer dort einen Balken über zwei Geräte mit dem Zähler einer seiner Anlagen verglich, fand eine Differenz, für die nirgends eine Erklärung stand. Betrifft nicht nur Wärme/Klima: Speicher und E-Mobilität lesen dieselbe Zeile. ⚠ Die Mengen bleiben zusammengefasst — Kilowattstunden über Geräte zu addieren ist richtig; was fehlte, war die Auskunft darüber.

[4.0.30] - 2026-08-27 — Quick-Fix: der Schalter geht auf, der Zählerstand bleibt ein Stand

Added

Deine Wärmepumpe sagt Home Assistant jetzt, was sie gerade tut (#398, gemeldet von MartyBr im simon42-Forum). Er hat gefragt, ob das Symbol beim Kühlen umschaltet — und dabei eine größere Lücke aufgedeckt: eedc liest den Betriebsmodus seit v4.0.21, schreibt ihn stündlich mit und teilt den Strom danach auf, zeigte ihn aber nirgends. Neu gibt es ihn an drei Stellen: als Sensor (Betriebsmodus, Klartext „Heizen”/„Kühlen”/„Entfeuchten”/„Lüften”), im Klartext unter dem Gerät in Cockpit → Live, und als wechselndes Symbol im Energiefluss — Flamme beim Heizen, Schneeflocke beim Kühlen. Wer keine climate-Quelle zugeordnet hat, sieht unverändert nichts: eedc behauptet keinen Modus, den es nicht kennt. ⚠ Der Sensor wird im Publish-Takt aktualisiert (Standard 60 Minuten) — für einen Modus, der saisonal gestellt wird, ist das genug; das Symbol im Energiefluss folgt dagegen dem Live-Takt.
Die Geräte-Sensoren erreichen endlich MQTT. Beim Bau von #398 gemessen: Der einzige MQTT-Publisher kannte nur die anlagenweiten Sensoren. Alles, was je Gerät entsteht — Wärmepumpe, E-Auto, Speicher, Wallbox — gab es ausschließlich im REST-Export. Wer sein Add-on über MQTT-Discovery angebunden hat (der Normalfall), hatte diese Sensoren schlicht nicht, obwohl die Sensor-Referenz sie seit v4.0 zusagt. ⚠ Sichtbare Folge: In Home Assistant erscheinen dadurch erstmals Geräte-Entitäten unter eigenen Geräten. Das ist ein Zuwachs, kein Umbau — bestehende Entitäten und ihre Langzeitstatistik bleiben unberührt.
Vormittags- und Nachmittagsprognose als Sensoren (#395 Punkt 3, OB73-gif). Für netzdienliches Laden: vier neue Sensoren — heute und morgen, je Vormittag und Nachmittag. Vier statt zwei, weil die Entscheidung meist abends fällt und dafür die Zahlen für morgen gebraucht werden. Die Grenze ist der Sonnenhöchststand (astronomische Tagesmitte), genau wie in der Anzeige daneben — und sie reist als Attribut solar_noon mit, damit eine Automation sie lesen kann statt sie zu raten.
Grundlast als Sensor (#395 Punkt 5, OB73-gif). Der Sensor trägt die gemessene Grundlast des laufenden Monats (Median der Nachtstunden 0–5 Uhr) — dieselbe Zahl wie die Kachel in Cockpit → Monat. Wer keine Stundendaten hat, bekommt keinen Sensor statt einer Schätzung.

Fixed

„Weitere Größen erfassen” ließ sich anklicken und tat nichts (gemeldet von pipp086 im simon42-Forum, am Tag der Auslieferung). Der Abschnitt unter Einstellungen → Datenquellen, mit dem v4.0.29 die Zuordnung eines Kühl-, Lüftungs- oder Heizzählers erst möglich gemacht hat, klappte bei keinem Gerät auf. Ein Klick auf den Schalter änderte nichts — die Fläche merkte sich den neuen Zustand, zeigte ihn aber nicht. Damit war die beworbene Neuerung praktisch unerreichbar. Behoben; ein Test klickt den Abschnitt jetzt bei jedem Lauf auf und wieder zu.
Wer per MQTT liefert, bekam seinen Zählerstand als Monatswert vorgehalten (gemeldet von gruaGit, #396). Ein eedc-MQTT-Topic trägt einen Zählerstand — so verlangt es die Topic-Liste, und so sendet der Absender. Gelesen wurde er als Monatsmenge. Die Folge im Monatsabschluss: elf Felder meldeten „weicht ab” und stellten den Lebenszählerstand neben den Monatswert (6675,3 gegen 552,75 kWh; beim Auto den Tachostand gegen die Monatskilometer). Daneben stand „Sensorwert übernehmen” — ein Klick hätte den Zählerstand als Monatswert gespeichert. ⚠ Schwerer wog die zweite Stelle: In Cockpit → Monat war es kein Vorschlag, sondern der angezeigte Wert — im laufenden Monat verdrängte der Zählerstand den gespeicherten Monatswert. Betroffen war, wer eedc ohne Home Assistant betreibt und alles per MQTT schickt. Ab jetzt bildet eedc die Differenz über den Monat aus den mitgeschriebenen Ständen. Liegt kein Anfangsstand vor oder ist der Zähler zurückgesprungen, gibt es keinen Vorschlag statt eines falschen — und der gespeicherte Wert bleibt stehen. ⚠ Sichtbare Folge: Wo bisher ein Zählerstand stand, steht jetzt die Monatsmenge; falsche „weicht ab”-Markierungen verschwinden. Felder ohne Zählerreihe (gefahrene Kilometer, Ladevorgänge) bekommen von MQTT keinen Vorschlag mehr — sie bleiben manuell erfassbar.
„Grundlast” bezeichnete zwei verschiedene Zahlen. In Cockpit → Live stand der Wert aus dem Verbrauchsprofil — ohne eigene Messhistorie ein Standard-Lastprofil, also ein Modellwert. In Cockpit → Monat/Jahr steht die gemessene Grundlast. Beide hießen gleich, und wer sie verglich, musste eine für falsch halten. Die Live-Anzeige heißt jetzt „Grundlast (Prognose)” und erklärt im Tooltip, wo die gemessene steht. Die Zahlen selbst ändern sich nicht — sie sollen verschieden sein, sie sollen nur nicht gleich heißen.
Die Vormittags-/Nachmittags-Grenze war im Code anders dokumentiert als gerechnet. Ein Feld-Kommentar nannte einen festen 13-Uhr-Schnitt, während dieselbe Datei drei Zeilen weiter am Sonnenhöchststand teilt. Der Kommentar hat es bis in eine öffentliche Antwort an einen Melder geschafft. Berichtigt, und ein Test hält die Grenze jetzt am Code fest. Angezeigte Zahlen sind unberührt — falsch war die Beschreibung, nicht die Rechnung.

Changed

Die beiden Release-Pflichtläufe verweigern die falsche Box. check:chart-audit prüfte bisher nur, ob er überhaupt nichts gemessen hat. Gegen eine Box mit dem falschen Frontend-Build maß er 37 statt 44 Charts — und meldete grün. Beide Laufzeit-Prüfer teilen sich jetzt eine Voraussetzungs-Prüfung und brechen ab, statt eine Teilmessung als bestanden auszuweisen. (Nur Entwicklung, keine Anwender-Wirkung.)

[4.0.29] - 2026-08-27 — Der Zähler entscheidet, nicht die Bauart

Added

Neues Handbuch „Wärme & Klima”. Die ganze Fläche an einer Stelle beschrieben: was sie umfasst, welcher Zähler welche Kennzahl möglich macht, was eedc bewusst nicht sagt (kein SEER, keine geschätzte Kältemenge, keine Note für deine Anlage), warum eine Arbeitszahl verschwindet und was jeder Grund bedeutet — dazu die Sensor-Zuordnung Schritt für Schritt, sechs durchgerechnete Beispiel-Anlagen und die häufigsten Missverständnisse. Erreichbar über die In-App-Hilfe und auf der Website. Die Zitate der Sperr-Gründe hält ein Test am Code fest; ein Handbuch, das eine Auskunft nennt, die es nicht mehr gibt, wäre schlechter als keins.
Wer einen Kühlzähler hat, kann ihn jetzt zuordnen — an jeder Wärmepumpe. Gemeldet von MartyBr und pipp086 (Forum simon42 #89667): „Ich habe getrennte Zähler für Heizung, Warmwassererwärmung … und seit dem Sommer auch für den Kühlbetrieb.” Bisher gab es die Kühl-Achse ausschließlich an Geräten mit der Wärmepumpenart „Luft-Luft (Klimaanlage)” — an einer Luft-Wasser- oder Sole-Wasser-Wärmepumpe war sein Zähler nirgends hinterlegbar.

Ab jetzt entscheidet der Zähler, nicht die Bauart. Unter Einstellungen → Datenquellen steht bei jedem Gerät ein neuer, zugeklappter Abschnitt „Weitere Größen erfassen”. Darin liegen die Größen, die es an diesem Gerätetyp selten gibt — die Kühl-, Lüft- und Entfeuchtungs-Achse an einer Heizungs-Wärmepumpe zum Beispiel. Ordnest du dort einen Sensor zu, rückt das Feld nach oben zu den anderen.

Die Fläche bleibt damit so kurz wie bisher, und trotzdem ist kein Fall mehr ausgeschlossen. Dazu neu: Leistung Kühlen (W) als Live-Wert, passend zu „Leistung Heizen” und „Leistung Warmwasser” — MartyBr misst beides.
Brauchwasser-Wärmepumpe als eigene Bauart. Ein Gerät, das ausschließlich Warmwasser macht, ließ sich bisher nicht sauber erfassen: Es bekam eine Heiz-Achse angeboten, die es nicht hat. Die neue Wärmepumpenart fragt nur noch nach dem, was das Gerät tut — die Heiz-Achse bleibt über „Weitere Größen erfassen” erreichbar, falls doch ein Zähler existiert.
Zwei Angaben, die eedc nicht sehen kann — und die es bisher auch nicht erfragt hat. Beim Gerät stehen jetzt zwei neue Felder:

„Fremdanteil auf den Zählern” — für zwei Lagen, die eine Arbeitszahl unbrauchbar machen, ohne dass man es den Zahlen ansieht: Der Heizstab hängt am Stromzähler der Wärmepumpe, seine Wärme läuft aber nicht über den Wärmemengenzähler (dann ist der Stromwert zu groß). Oder umgekehrt: Ein Gas- oder Ölkessel speist denselben Heizkreis, der Wärmemengenzähler misst beide, der Stromzähler nur die Wärmepumpe (dann ist der Wärmewert zu groß). Beides ändert keine Menge — eedc lässt nur die Arbeitszahl weg und schreibt den Grund daneben.

„Kühlung: aktiv oder passiv” — passiv gekühlte Anlagen (nur Umwälzpumpen) erreichen ein Vielfaches der Effizienz aktiv gekühlter. Ihre eigenen Zahlen bleiben unverändert; sie werden im Community-Vergleich nicht mehr gegen aktiv gekühlte Anlagen gestellt.
Eine Kennzahl für den Kühlbetrieb: die Arbeitszahl Kühlen. Wer einen Kältemengenzähler hat, konnte seine Kältemenge seit v4.0.24 eintragen — und sah sie an keiner einzigen Stelle. Es gab keine Kennzahl, die sie benutzt hätte.

Jetzt gibt es sie: Kältemenge ÷ Kühlstrom, im Komponenten-Hub und im Cockpit (Monat), neben den Arbeitszahlen für Heizen und Warmwasser.

Sie heißt bewusst nicht „SEER”. SEER ist eine genormte Größe, die unter definierten Prüfstandsbedingungen ermittelt wird — was eedc bilden kann, ist der Quotient deiner beiden Zähler über einen Zeitraum. Sie „SEER” zu nennen würde eine Vergleichbarkeit mit Datenblatt-Werten behaupten, die sie nicht hat.

Fehlt der Kältemengenzähler — der Normalfall —, steht der Grund dort statt einer Zahl. Geschätzt wird nichts: Aus einem angenommenen Wirkungsgrad käme genau der Faktor zurück, mit dem gerechnet wurde.
Arbeitszahl getrennt für Heizen und Warmwasser — überall und mit Begründung. Wer Strom je Funktion getrennt misst, sah die beiden Zahlen bisher nur im Komponenten-Hub. Im Cockpit (Monat) gab es sie gar nicht, obwohl dieselben Daten dort vorliegen.

Wichtiger als der neue Ort ist, was sich an den Zahlen ändert: Sie wurden bisher an einer eigenen Stelle gerechnet und kannten deshalb die Sperren nicht, die für die Gesamt-Arbeitszahl längst gelten. Liegt ein Heizstab auf dem Wärmepumpen-Zähler, verschwand die Gesamtzahl mit Begründung — „JAZ Heizen” stand unbeeindruckt daneben. Dieselbe Anlage, zwei Aussagen. Jetzt rechnet eine Stelle für alle drei Zahlen.

Und wo eine der beiden Zahlen nicht gebildet werden darf, stand bisher eine 0 — was „Arbeitszahl null” heißt und nicht „unbekannt”. Jetzt steht dort ein „—” mit dem Grund daneben.

Warum die getrennten Zahlen nützlich sind: Warmwasser liegt bauartbedingt niedriger als Heizen (höhere Zieltemperatur). Wer viel Warmwasser macht, hat deshalb eine niedrigere Gesamt-Arbeitszahl, ohne dass die Anlage schlechter wäre — erst die getrennten Zahlen zeigen das.
Lüften und Entfeuchten erscheinen jetzt in der Aufteilung. Wer für diese Betriebsarten einen eigenen Zähler zugeordnet hat, sah seine Kilowattstunden bisher nirgends — sie fielen stumm unter „nicht aufgeteilt”, obwohl eedc die Felder anbietet und den Wert entgegennimmt.

Ab jetzt bekommen beide ein eigenes Segment im Balken und eine eigene Zeile darunter — in Cockpit → Tag, Monat, Jahr und im Komponenten-Hub. Wer keinen solchen Zähler hat, sieht keine Veränderung: Ohne Messung stecken sie weiterhin in der Restmenge, und zwei leere Zeilen an jeder Wärmepumpe wären keine Auskunft.

Bewertet werden sie bewusst nicht — sie erzeugen keine Wärme, die sich messen ließe. Genau deshalb fällt ihr Strom jetzt auch aus dem Nenner der Arbeitszahl, wie der Kühlstrom seit dem Fix darunter. Deine Arbeitszahl kann dadurch steigen, wenn du lüftest oder entfeuchtest und das getrennt misst; die Mengen selbst ändern sich nicht.

Fixed

„Kein Zähler zugeordnet” — obwohl 1.286 kWh über das Feld liefen. Gemeldet von gruaGit (Discussion #396): „Ist die Meldung hier ganz unten ‚Offen: go-e Charger, Ladung PV’ evtl. auch noch fälschlicherweise vorhanden? Tatsächlich existiert dafür ja ein Wert.”

Er hatte recht, und es war mehr als eine falsche Meldung. Für eedc hieß „Zähler zugeordnet” bis jetzt „Home-Assistant-Sensor zugeordnet”. Wer seine Werte per MQTT schickt — der Normalfall im Standalone-Betrieb ohne Home Assistant — hat gar keinen Sensor zuzuordnen, und genau das war die Lücke:
- Der Daten-Check vermisste Zähler, die längst liefern — bis hin zu „Kein Basis-Zähler für: Einspeisung, Netzbezug” bei Anlagen, die vollständig messen. Der Hinweis war nicht abstellbar: Der „Beheben”-Knopf führte in ein Formular, in dem es das Feld gar nicht gibt.
- Schlimmer, und bisher nicht gemeldet: In Cockpit → Tag blieben dieselben Werte wirklich leer — Wärmemenge, getrennter Heiz-/Warmwasserstrom, Netzladung des Speichers, PV-Anteil der Ladung, Kompressor-Starts. Die Zählerstände standen in der Datenbank und wurden nie gelesen. Auch die Tages-Summe je Komponente und die Lebensdauer-Kacheln im Wärmepumpen-Dashboard waren betroffen.
Ab jetzt zählt der Messwert, nicht die Zuordnungsform. Ein Feld trägt einen Zähler, wenn ihm ein Home-Assistant-Sensor zugeordnet ist oder wenn dafür Zählerstände per MQTT ankommen. Wer „Keine” gewählt hat, behält seine Absage.

Was du siehst: Die drei Hinweise verschwinden, wenn deine Werte ankommen — und Cockpit → Tag füllt sich mit Zahlen, die vorher auf „—” standen. Bleibt ein Hinweis stehen, ist er ab jetzt echt: Dann kommt auf diesem Topic seit über einer Woche nichts an.

Und was der Grund unter einem „—” jetzt sagt: Wer per MQTT misst, bekam bis jetzt den Rat „Sensor zuordnen” — für ihn ein Weg ins Leere. Jetzt steht dort, was wirklich fehlt: dass für diesen Tag keine Zählerstände vorliegen.
Ein Tag mit 36 Stunden. Gemeldet von dietmar1968 (Forum simon42 #89667): „Ich verstehe beim Vorhandensein folgender Sensoren jene Anzeige nicht.” Unter Cockpit → Tag stand bei ihm „Modus erfasst: 36 Stunden”. Ein Tag hat 24.

Ursache: Wer mehrere Wärmepumpen oder Klimaanlagen hat, deren Betriebsart eedc mitliest, bekam die erfassten Stunden aller Geräte zusammengezählt. Zwei Geräte, die dieselben 18 Stunden liefen, ergaben 36. Kilowattstunden darf man über Geräte addieren, Stunden nicht — sie beschreiben denselben Zeitraum. Im Monat fiel es nicht auf: Dort standen 372 von 624 möglichen Stunden, plausibel genug, um lange unbemerkt zu bleiben.

Die Mengen sind davon nicht betroffen und ändern sich nicht — nur die Stunden-Angabe darunter zeigt jetzt, wie lange eedc tatsächlich mitgelesen hat.
Der Aufteilungs-Balken beschrieb weniger als die Kachel darüber, ohne es zu sagen. Ebenfalls aus dietmars Bildern: Über dem Balken stand „Strom verbraucht: 284 kWh”, der Balken selbst summierte sich auf 30. Beide Zahlen waren richtig.

Der Grund: Die Aufteilung nach Betriebsart entsteht nur für Geräte und Monate, in denen eedc die Betriebsart auch mitlesen konnte. Die Kachel darüber zählt alle Geräte. Gesagt hat das bisher niemand.

Jetzt steht unter dem Balken eine Zeile „Aufgeteilte Menge: 30 von 284 kWh” — im Cockpit (Tag, Monat, Jahr) und im Komponenten-Hub. Sie erscheint nur, wenn beide Zahlen auseinandergehen. Im Komponenten-Hub korrigiert das zugleich die Prozente: Sie wurden dort gegen den Gesamtstrom gerechnet und summierten sich deshalb auf weniger als 100 %.
eedc forderte, einen Sensor zuzuordnen, der längst zugeordnet war. Der dritte Punkt aus dietmars Meldung, und der ärgerlichste: Unter Cockpit → Tag stand bei Wärme erzeugt ein „—”, und die Erklärung dazu lautete „Tageswert braucht einen Wärmemengenzähler am Gerät (Sensor zuordnen)”. Er hatte zwei zugeordnet.

Der Satz war fest verdrahtet und beschrieb nur einen von drei möglichen Gründen. eedc unterscheidet sie jetzt und nennt den zutreffenden:
- Kein Zähler zugeordnet — dazu der Weg, wo er einzutragen ist.
- Zähler zugeordnet, aber für diesen Tag liegen keine Zählerstände vor. Das ist der Regelfall nach einer frischen Zuordnung: Der Monatswert steht da, weil er aus der Langzeitstatistik von Home Assistant kommt; Tageswerte entstehen erst ab der Zuordnung. Frühere Tage lassen sich in der Reparatur-Werkbank nachrechnen.
- Der Zähler ist an diesem Tag zurückgesprungen. Diesen Fall hat eedc schon immer erkannt und die Tagesaussage bewusst weggelassen — geschrieben hat er es bisher nur ins Protokoll.
Der Grund steht jetzt sichtbar unter der Zahl statt im Tooltip — ein Tooltip ist auf dem Telefon keine Auskunft. Betroffen sind Wärme erzeugt, Ersparnis vs. Gas, die Arbeitszahl und der PV-Anteil der Ladung. Eine falsche Ursache ist schlimmer als keine: Ohne Hinweis sucht man selbst, mit einem falschen sucht man an der falschen Stelle.
Der Komponenten-Hub zeigte eine andere Arbeitszahl als das Cockpit — für dieselbe Anlage im selben Monat. Gefunden beim Aufbau der neuen Simulationstests, nicht gemeldet. Wer heizt und kühlt, sah unter Komponenten → Wärmepumpe eine zu niedrige Zahl (an einer Beispielanlage 2,31 statt 3,00), während Cockpit → Monat richtig rechnete.

Ursache: Der Hub bildete den Quotienten selbst, statt die gemeinsame Rechenstelle zu nutzen. Damit fehlten ihm sämtliche Regeln, die dort gelten — der Kühlstrom blieb im Nenner, ein gemeldeter Fremdanteil auf den Zählern wurde ignoriert.

Zwei Dinge kommen damit neu hinzu, die es dort nie gab: Wo eedc keine Arbeitszahl bilden darf, steht jetzt der Grund statt einer leeren Kachel. Und liegt die Arbeitszahl unter 2, steht der Heizstab-Hinweis daneben — bisher gab es ihn nur im Cockpit.
Wer Heizung, Warmwasser und Kühlung getrennt misst, dessen Kühlstrom fehlte im Stromverbrauch der Wärmepumpe. Betroffen ist genau die Ausstattung, die mit diesem Release erst möglich wird: ein Kühlzähler an einer Luft-Wasser- oder Sole-Wasser-Wärmepumpe.

eedc summierte den Verbrauch aus „Strom Heizen” und „Strom Warmwasser” — eine Formel aus der Zeit, als eine Wärmepumpe nur diese beiden Dinge tun konnte. An einer Beispielanlage fehlten dadurch 100 von 1050 kWh, und das trug in Kosten, CO₂ und den Anteil an der Verbrauchsseite weiter.

Zugleich wurde derselbe Kühlstrom ein zweites Mal abgezogen, weil er im Nenner nie enthalten war — die Arbeitszahl fiel dadurch rund 12 % zu gut aus. Beides ist mit einer Korrektur behoben: Der Kühlstrom zählt im Verbrauch mit und wird genau einmal abgezogen.

⚠ Deine Zahlen können sich dadurch sichtbar ändern, wenn du getrennte Zähler samt Kühlmessung führst: Der Stromverbrauch der Wärmepumpe steigt um den Kühlanteil, die Arbeitszahl sinkt entsprechend auf ihren richtigen Wert.
Zwei Preisfelder, die der Daten-Checker verlangte und die es in keinem Formular gab. Gemeldet von MeinerB (Issue #397): „ich bekomme einen Hinweis dass ich die Felder bearbeiten soll, kann sie aber nicht finden.” Wer bei einem Speicher „Arbitrage-fähig” einschaltet, wurde nach Ø Lade- und Ø Entladepreis gefragt — beide gab es weder im Formular noch in einem Wizard. Der „Beheben”-Knopf führte in genau das Formular, in dem sie fehlten.

Beide Felder stehen jetzt unter Netzladung & Arbitrage, sobald der Schalter an ist. Sie bleiben bewusst leer statt vorbelegt: Ein eingetragener Richtwert würde beim ersten Speichern zu einer gepflegten Zahl, die niemand bestätigt hat. Womit eedc ohne deine Angabe rechnet (12 bzw. 35 ct/kWh), steht als Hinweis unter dem Feld.

Der gleich aussehende Hinweis beim E-Auto ist dagegen ersatzlos entfallen („V2H aktiv, aber Entladepreis fehlt”). Er war sachlich falsch: v2h_entlade_preis_cent ist ein Override, kein benötigter Wert — ohne ihn rechnet eedc mit dem Abstand zwischen deinem Bezugspreis und deiner Einspeisevergütung, also mit gepflegten Zahlen statt einer Schätzung. Wer dem Hinweis folgte, verschlechterte seine Datengrundlage.
Der Kühlstrom drückte die Arbeitszahl. Wer mit derselben Anlage heizt und kühlt, hatte den Kühlstrom im Nenner seiner Arbeitszahl — die abgeführte Wärme steht dort aber in keinem Zähler. Eine Anlage, die im Sommer kühlt, sah dadurch aus wie eine schlechte Heizung, und zwar in Cockpit → Tag, Monat, Jahr, im Komponenten-Hub und im Community-Vergleich.

Für Wirtschaftlichkeit und CO₂ rechnet eedc den Kühlstrom seit 4.0.5 heraus — bei der Arbeitszahl fehlte derselbe Schritt. Deine Arbeitszahl kann dadurch steigen, wenn du kühlst; das ist gewollt. Ist ein ganzer Zeitraum reiner Kühlbetrieb, steht statt der Zahl der Grund dafür.
Die Abgrenzungs-Prüfung erreicht alle Sichten. Ob eine Arbeitszahl überhaupt gebildet werden darf, wurde bisher unterschiedlich streng geprüft: Der Komponenten-Hub kannte die Sperren, Cockpit → Jahr und Cockpit → Tag gar nicht. Dieselbe Anlage konnte an einer Stelle „—” zeigen und an der anderen eine Zahl. Jetzt entscheidet eine Stelle für alle.

Neu erkannt wird dabei auch der Fall, dass Wärme und Strom aus verschieden langen Messzeiträumen stammen — etwa wenn ein Connector erst mitten im Monat zu zählen begann. Der Quotient wäre einer aus zwei Wirklichkeiten; die Mengen bleiben, die Kennzahl entfällt mit Begründung.
Die Zuordnungs-Fläche bot einer Split-Klimaanlage Warmwasser-Felder an. Ein Klimagerät hat keinen Warmwasserkreis — im Monatsabschluss fragte eedc längst nicht mehr danach, unter Einstellungen → Datenquellen standen die beiden Felder trotzdem. Dieselbe Anlage, zwei Flächen, gegenteilige Aussage. Hast du dort bereits einen Sensor zugeordnet, bleibt das Feld sichtbar, damit du die Zuordnung auch wieder entfernen kannst.
Der Gesamt-Stromzähler bleibt pflegbar, auch bei getrennter Messung. Wer „Heizen und Warmwasser getrennt gemessen” eingeschaltet hat, konnte den Gesamtzähler im Monatsabschluss nicht mehr nachtragen — obwohl eedc ihn mit diesem Release wieder auswertet, solange die Aufteilung unvollständig ist.

[4.0.28] - 2026-08-25 — Anzeigen ist nicht mitschreiben

Fixed

Die Börsenpreis-Kurve nutzt die Höhe, die der Block ohnehin hat. Gemeldet von rapahl: Die Kurve unter Cockpit → Live wirke flach. Nachgemessen an einer laufenden Instanz: Der Chart war 300 px hoch, die Kennzahlen-Spalte direkt daneben 434 px — unter der Kurve blieb Platz ungenutzt, den der Block bereits belegt. Die Kurve steht jetzt auf 400 px und damit nahezu bündig mit den Kennzahlen.

Das ist die zweite Rückmeldung desselben Melders zu dieser Grafik: Mit 4.0.27 waren Kurve und Kennzahlen nebeneinander gerückt (sein eigener Vorschlag), was die Kurve schmaler gemacht hat — aber nicht höher. Es ändert sich keine Zahl, nur die Ablesbarkeit.

Aus derselben Meldung stammt die etwas größere Legende unter der Kurve. Sie lag als einzige Chart-Legende der App auf der kleinsten Schriftstufe, während alle anderen eine Stufe darüber stehen — das ist damit angeglichen, nicht ausgeschert.
Der Daten-Check verlangte von einer Split-Klimaanlage einen Warmwasser-Zähler. Gemeldet von OB73-gif (#263): Sein Daten-Check meldete „1 von 4 Komponenten ohne vollständige kWh-Zähler-Abdeckung — Midea Portasplit: strom_heizen_kwh, strom_warmwasser_kwh”.

Die Meldung war nicht abstellbar. Eine Split-Klimaanlage hat keinen Warmwasserkreis, und eedc bietet das Feld für so ein Gerät im Monatsabschluss längst nicht mehr an. Wer den Hinweis auflösen wollte, hätte einen Wert für einen Kreis beschaffen müssen, den das Gerät nicht besitzt.

Die Regel selbst gab es bereits an zwei Stellen im Daten-Check — bei den Monatsdaten und bei den Zusatz-Zählern. Nur die Prüfung der kWh-Abdeckung kannte sie nicht.

Ab jetzt erwartet sie von einer Klimaanlage mit getrennter Strommessung nur noch die Heiz-Seite. Für Luft-Wasser- und Sole-Wasser-Wärmepumpen ändert sich nichts — dort bleiben beide Seiten gefordert.

Danke an Oskar, der die Meldung nicht weggeklickt, sondern hergezeigt hat.
Wer Heizen und Kühlen getrennt misst, sieht die Aufteilung jetzt auch unter Tag. Bei einer Split-Klimaanlage kann der Verbrauch je Betriebsart gemessen vorliegen — über eigene Zähler für Heizen, Kühlen, Lüften und Entfeuchten, statt ihn aus der Betriebsart ableiten zu lassen. Diese Geräte sahen ihre Aufteilung in Cockpit → Monat und → Jahr, unter Cockpit → Tag dagegen nie: Der Tag hat die Zähler gar nicht erst abgefragt.

Sichtbar wurde es nicht als Fehlermeldung, sondern als fehlender Block — dieselbe Kachel Wärme/Klima, in der Monatsansicht mit Aufteilung, in der Tagesansicht ohne. Wer nur abgeleitete Betriebsarten nutzt, war nie betroffen; für ihn war der Block immer da.

Ab jetzt gilt im Tag dieselbe Regel wie im Monat: Gemessen schlägt abgeleitet, und zwar ganz oder gar nicht je Gerät. Eine Anlage darf eine Klimaanlage mit Zählern und eine Wärmepumpe ohne haben — jedes Gerät wird auf seinem eigenen Weg aufgeteilt, und keines zählt doppelt. Steht in der Aufteilung „Herkunft: gemessen”, stammt sie aus deinen Zählern; sonst nennt sie weiterhin die Zahl der erfassten Stunden.

Lüften und Entfeuchten haben eigene Zähler, aber kein eigenes Segment — sie zählen wie bisher unter „nicht aufgeteilt”, genau wie in der Monatsansicht.

An deinen Daten ändert sich nichts, und die Monats- und Jahreswerte bleiben, wie sie waren.

Added

Der Börsenpreis-Block zeigt jetzt auch, was du wirklich zahlst. Wunsch von rapahl: Alle Kacheln dort trugen den Börsenpreis — die richtige Größe für die Frage „wann laden”, aber nicht die, die auf der Rechnung steht. Dazwischen liegen Netzentgelte, Steuern und Abgaben, und wer das nachsehen wollte, brauchte einen zweiten Blick in Home Assistant.

Neu ist die Kachel „Endpreis jetzt” direkt neben dem aktuellen Börsenpreis. Sie zeigt den Preis der laufenden Stunde inklusive aller Bestandteile; beide nebeneinander machen den Aufschlag ohne Rechnen sichtbar. Der Börsenpreis und alle anderen Kennzahlen bleiben unverändert an ihrem Platz.

Voraussetzung ist ein zugeordneter Strompreis-Sensor (Tibber, aWATTar, EPEX-Endpreis) unter Einstellungen → Datenquellen. Fehlt er, fehlt die Kachel — und das ist Absicht: eedc setzt dann nicht ersatzweise den Arbeitspreis aus dem Tarif ein. Bei einem dynamischen Tarif ist das ein Mittel- oder Schätzwert, der als „Preis dieser Stunde” eine Genauigkeit behaupten würde, die es nicht gibt.
Der Daten-Check verlangte einen Wert, den eedc an dieser Stelle gar nicht haben will. Gemeldet von gruaGit (Discussion #396): Sein Daten-Check meldete „VW ID.3: Ladung PV fehlt in 8 Monaten”, während dieselbe App für genau diese Monate PV-Anteile seiner Ladung auswies. Beides stimmte — sie sprachen nur über verschiedene Stellen.

Wer eine Wallbox hat, dessen Heimladung führt eedc dort. Die Aufteilung in Sonne und Netz am Fahrzeug wird deshalb im Monatsabschluss gar nicht mehr angeboten: Sie stünde sonst zweimal in den Daten. Der Daten-Check kannte diese Regel als einziger nicht und forderte den Wert weiter ein.

⚠ Nachträglich richtiggestellt (September 2026): „Die Aufteilung am Fahrzeug wird gar nicht mehr angeboten“ gilt nicht mehr. Seit September 2026 bietet der Monatsabschluss „Heim: PV“, „Heim: Netz“ und das neue „Heim: gesamt“ wieder an jedem E-Auto an; eine eigene Messung am Auto zählt auch neben der Wallbox, die Wallbox trägt den Rest. Die Daten-Check-Regel dieses Eintrags bleibt: neben einer Wallbox ist eine Messung am Auto freiwillig und wird nicht als fehlend gemeldet.

Die Meldung war damit nicht abstellbar. Ihr „Beheben”-Knopf führte in ein Formular, in dem es dieses Feld nicht gibt. Und wer den Wert von Hand beschafft und eingetragen hätte, hätte genau die Doppelzählung erzeugt, die die Regel verhindern soll.

Ab jetzt fragt der Daten-Check das Feld nur noch bei Fahrzeugen ohne Wallbox — dort, wo es das Formular auch anbietet. Für Dienstwagen galt diese Ausnahme bereits.

Wen es betrifft: alle Anlagen mit Wallbox und E-Auto. Dort verschwindet die Meldung. An deinen Daten ändert sich nichts, und die PV-Anteile deiner Ladung werden weiterhin so ausgewiesen wie bisher.

Danke an gruaGit, der zwei Aussagen derselben App nebeneinandergelegt hat, statt einer davon zu glauben.
Die Aufteilung Heizen/Kühlen sagt jetzt, warum ein Teil nicht aufgeteilt ist. Gemeldet von Klausnn (#263) und, am selben Tag, von dietmar1968 (simon42-Forum): Beide sahen unter Cockpit → Tag im Block Wärme/Klima einen großen Anteil unter „Nicht aufgeteilt” — bei Klausnn 100 %, bei dietmar 74 % — und hielten die Aufteilung für kaputt, obwohl die Betriebsart in den Datenquellen korrekt anlag.

Die Zahlen waren richtig. „Nicht aufgeteilt” ist Standby und alles, was weder Heizen noch Kühlen war — Lüften, Entfeuchten, Automatik ohne Rückmeldung — dazu die Zeit ohne Modus-Signal. Bei einem Gerät, das an diesem Tag überwiegend aus war, gehört der Strom genau dorthin. Was fehlte, war dieser Satz neben der Zahl: Im Komponenten-Hub steht er seit jeher, im Cockpit stand nur der nackte Balken.

Ab jetzt zeigt das Cockpit dieselbe Erklärung wie der Komponenten-Hub und nennt zusätzlich, in wie vielen Stunden eedc eine Betriebsart mitlesen konnte. Stammt die Aufteilung aus zugeordneten Betriebsart-Zählern, steht dort „gemessen” statt einer Stundenzahl.

Wen es betrifft: alle mit einer Klimaanlage oder Wärmepumpe, für die eedc den Betriebsmodus mitschreibt. Es ändert sich keine Zahl — nur ihre Erklärung kommt dazu.

Danke an Klausnn und dietmar1968. Zwei Meldungen am selben Tag zur selben Anzeige sind das deutlichste Zeichen, dass nicht die Rechnung das Problem war, sondern das Schweigen daneben.
Sechs Home-Assistant-Sensoren zeigten einen Wert und merkten sich nichts. Gemeldet von rapahl: In seinem Home-Assistant-Protokoll standen fünf Warnungen zu den PV-Prognose-Sensoren — Home Assistant lehnte eine Kombination aus zwei technischen Angaben ab, die eedc beim Anmelden der Sensoren mitschickt.

Die Warnung war nicht der eigentliche Schaden. Home Assistant nimmt Sensoren mit einer solchen Kombination von der Langzeitstatistik aus: Der Sensor zeigt in der Übersicht seinen aktuellen Wert, aber Home Assistant schreibt ihn nirgends mit. Verlaufsdiagramme bleiben leer, und eine Auswertung über Tage oder Monate gibt es für ihn nicht — dauerhaft, auch rückwirkend nicht.

Die Ursache war ein naheliegender Fehlschluss: Die Prognose-Sensoren tragen Kilowattstunden, also lag device_class: energy nahe. Home Assistant meint mit dieser Angabe aber einen Zähler, der nur steigt oder sich sauber aufsummieren lässt. Eine Tagesprognose ist das nicht — sie springt jeden Tag zurück, und die Summe zweier Prognosen ergibt keine sinnvolle Zahl.

Ab jetzt melden diese Sensoren ihre Einheit weiterhin in kWh, aber ohne die Zähler-Zuordnung. Damit akzeptiert Home Assistant sie und schreibt für sie wieder Statistik — Minimum, Mittelwert und Maximum je Stunde. Es kommt also etwas dazu, es fällt nichts weg.

Betroffen sind sechs Sensoren. Fünf hatte rapahls Protokoll genannt: eedc_prognose_heute_kwh, eedc_prognose_rest_today_kwh sowie die drei Tagesprognosen eedc_prognose_day_plus_1/2/3_kwh. Beim Nachzählen über alle Sensoren kam ein sechster dazu, den das Protokoll nicht zeigte, weil er unter einer anderen Meldung lief: jahres_ersparnis_euro. Er trug device_class: monetary — dafür verlangt Home Assistant ebenfalls einen aufsummierbaren Betrag, und eine Jahresersparnis in €/Jahr ist keiner, sondern eine Rate.

Wen es betrifft und was sich sichtbar ändert: alle Anwender mit aktiviertem Home-Assistant-Export. In Home Assistant verschwinden die Warnungen aus dem Protokoll, und für die sechs Sensoren entstehen ab dem Update Verläufe, wo vorher keine waren. Rückwirkend gibt es keine Werte — Home Assistant legt Statistik erst ab dem Zeitpunkt an, ab dem ein Sensor sie führen darf. An deinen Daten in eedc ändert sich nichts.

Danke an rapahl, der ein Protokoll gelesen hat, das die meisten überblättern. Die Meldung sah nach einer Randnotiz aus und war der Hinweis auf sechs Sensoren ohne Gedächtnis.

[4.0.27] - 2026-08-24 — Gemessen statt geschätzt

Fixed

Der Daten-Check meldete eine PV-Doppelerfassung, die es nicht gab — und rechnete dabei mit einer Anlagengröße, die niemand mehr prüfte. Gemeldet von NoahPaulick (simon42-Forum): Sein Daten-Check warnte an vier Tagen vor „PV-Doppelerfassung” mit spezifischen Tageserträgen über 10 kWh/kWp — physikalisch unmöglich für ein deutsches Dach. Er hatte Rohsensor, Tageswerte, Monatswerte und Investitionen gegengeprüft: alle vier stimmten überein und lagen im plausiblen Bereich.

Die Ursache lag im Nenner. eedc kennt die Anlagengröße an zwei Orten: als Feld Anlagenleistung unter Einstellungen → Anlage und als Summe der angelegten PV-Module. Beim Einrichten erzeugt eedc die Module aus dem Feld, beide stimmen also anfangs überein. Wer danach seine Module korrigiert — bei Noah nach dem Trennen zweier ursprünglich gemeinsam erfasster Anlagen —, verändert nur eine der beiden Zahlen. Der Abgleich, der so etwas gemeldet hätte, war seit 4.0.10 versehentlich entfallen, und der Daten-Check bestätigte die abweichende Anlagenleistung sogar eine Zeile über der Warnung ausdrücklich als in Ordnung.

Ab jetzt rechnet eedc überall mit derselben Basis: der Summe der PV-Module, die zum jeweiligen Zeitpunkt in Betrieb waren. Das betrifft den spezifischen Ertrag in Tages-, Monats- und Jahressicht, die Performance Ratio, die PV-Auslastung im Live-Dashboard, den Jahresbericht als PDF und alle Plausibilitätsprüfungen. Anders als das Feld kennt diese Summe Zubau und Stilllegung — ein im Sommer erweitertes Dach zählt ab dem Erweiterungsmonat, ein stillgelegter String danach nicht mehr.

Das Feld Anlagenleistung bleibt und wird nicht überschrieben. Es ist weiterhin Pflicht, geht unverändert an den Community-Vergleich und dient als Rückfallwert, solange keine PV-Module angelegt sind. Neu ist: Passt es weder zur Summe deiner Module noch zu dieser Summe plus Balkonkraftwerk, sagt der Daten-Check es dir und nennt beide Zahlen. Wer sein Balkonkraftwerk eingerechnet hat und wer es weggelassen hat, bekommt weiterhin keine Meldung — beide Schreibweisen sind üblich.

Wen es betrifft und was sich sichtbar ändert: alle Anlagen, deren Feld Anlagenleistung von der Summe ihrer PV-Module abweicht. Dort verschieben sich spezifischer Ertrag und Performance Ratio auf den richtigen Wert — nach unten, wenn das Feld zu klein war, nach oben, wenn es zu groß war. Stimmen beide Zahlen überein, ändert sich nichts. An deinen Daten wird nichts geändert.

Danke an NoahPaulick für einen Fehlerbericht, der vier unabhängige Quellen gegeneinander gehalten hat. Die Analyse hat die Suche von Anfang an in den richtigen Teil der Rechnung gelenkt.
Ein PV-Zähler am Wechselrichter wurde von niemandem gelesen — und blockierte dabei die Stelle, die funktioniert hätte. Gemeldet von Mathek (#388): Die Live-Kachel PV-Erzeugung heute zeigte rund 31 % zu viel, und auch nach der Korrektur in 4.0.22 änderte sich bei ihm nichts.

eedc führt die PV-Erzeugung an den PV-Modulen und — für die ganze Anlage — unter Einstellungen → Datenquellen in der Gruppe Anlage (Basis) als PV-Erzeugung Zählerstand. Am Wechselrichter gab es trotzdem ein gleichnamiges Feld. Ein Wert dort zählte nirgends mit; das Gerät ist für eedc ein Durchleiter, keine Messstelle. Schlimmer war die Nebenwirkung: Das Feld galt als vollwertige PV-Quelle, und sobald dort ein Zähler hing, meldete eedc die PV als abgedeckt — der Anlagen-Zähler und das Modul-Feld standen auf „bereits an anderer Stelle zugeordnet”. Alle drei Wege inaktiv, keiner wirksam. Für die Kachel blieb nur die Hochrechnung aus der Momentanleistung, und die schätzt zwischen zwei Messpunkten nach oben.

Ab jetzt: Das Feld wird nicht mehr angeboten. Wer dort noch eine Zuordnung hat, sieht sie weiterhin — sie lässt sich also entfernen — und der Daten-Checker sagt, wohin der Sensor gehört. Danach wird der Anlagen-Zähler wieder eingefordert, und die Kachel liest ihn. Wer je String misst, ordnet wie bisher am PV-Modul zu; wer einen Zähler für die ganze Anlage hat, unter Anlage (Basis) — eedc verteilt die Menge dann nach kWp auf die Module.

Wen es betrifft: nur Anlagen mit einem Wechselrichter-Gerät, an dem ein PV-Zähler oder ein PV-Monatswert hängt. Deine Daten werden nicht angefasst. Nach dem Umziehen des Sensors steht in der Live-Kachel ein gemessener Wert statt einer Schätzung — die Zahl ändert sich also sichtbar, und zwar nach unten auf den Wert deines Zählers.

Danke an Mathek, der ein zweites Mal geschrieben hat, als die erste Korrektur bei ihm nicht wirkte. Ohne diesen zweiten Bericht wäre die eigentliche Ursache nicht gefunden worden.
Der PV-Anteil der Heimladung stand bei manchen Anlagen auf 0 %, obwohl eedc ihn kannte. Wer eine Wallbox hat, dessen Heimladung führt eedc seit v3.36.0 dort — die Aufteilung in Sonne und Netz am Fahrzeug wird seither nicht mehr angeboten und nicht mehr verwendet. Ein alter Wert, der aus der Zeit davor am Fahrzeug stehengeblieben ist, hat trotzdem weitergewirkt: Er galt als „der Anwender hat die Aufteilung erfasst” und hat damit verhindert, dass eedc sie für die Wallbox aus den eigenen Stundenwerten ableitet. Ergebnis war keine falsche Zahl, sondern gar keine — die Heimladung stand vollständig auf der Netz-Seite.

Ab jetzt entscheidet allein die Quelle, die eedc auch wirklich verwendet: Trägt die Wallbox eine eigene Aufteilung, gilt sie unverändert. Trägt sie keine, leitet eedc den Anteil aus dem gemessenen Tagesverlauf ab — so wie bei jeder Anlage ohne solchen Altbestand.

Wen es betrifft und was sich sichtbar ändert: nur Anlagen mit Wallbox und einem alten Aufteilungswert am Fahrzeug, und dort nur Monate, für die eedc Stundenwerte hat. In diesen Monaten steigt der ausgewiesene PV-Anteil der Heimladung — im Cockpit, im Komponenten-Hub, in den Auswertungen und in den Home-Assistant-Sensoren. Es wird nichts an deinen Daten geändert: Der Wert am Fahrzeug bleibt stehen, er zählt nur nicht mehr gegen eine Quelle, die er nicht ist. Monate ohne Stundenwerte bleiben unverändert.

⚠ Nachträglich richtiggestellt (September 2026): „Die Aufteilung am Fahrzeug wird nicht mehr verwendet“ gilt nicht mehr. Seit September 2026 zählt ein Heimlade-Wert am Fahrzeug („Heim: PV“, „Heim: Netz“, „Heim: gesamt“) als eigene Messung dieses Autos, auch neben der Wallbox; die Wallbox trägt nur noch den Rest. Ein alter Aufteilungswert am Fahrzeug wirkt damit wieder — stimmt er nicht, gehört er im Monatsabschluss korrigiert. Nur ein alter Gesamtwert mit „Herkunft unbekannt“ zählt neben einer Wallbox weiterhin nicht.
Der Ø-Benzinpreis fehlte in frisch entstandenen Monaten bis zu eine Woche lang. Gemeldet von gruaGit (Discussion #394): Ihm war geantwortet worden, eedc trage jeden Monat ohne Benzinpreis von selbst nach — er sah nach, und Juni 2026 war leer. Die Automatik gab es tatsächlich, sie lief aber nur wöchentlich, als einziger Wochen-Takt unter sechzehn Hintergrund-Aufgaben. Eine Monatszeile, die zwischen zwei Läufen entsteht — beim Monatsabschluss, beim Import, bei der Ersteinrichtung —, blieb deshalb bis zu sieben Tage ohne Marktpreis, und der Kostenvergleich des E-Autos rechnete solange still mit dem hinterlegten Modellwert statt mit dem Preis des Monats. Der Fortschritt behauptete eine Messung und lieferte ein Modell.

Ab jetzt läuft der Abgleich täglich um 06:00, dazu einmal kurz nach jedem Start von eedc — ein Neustart genau zur Laufzeit hat bisher eine ganze Woche gekostet. Zusätzlich fragt eedc erst nach, wenn es überhaupt eine offene Monatszeile gibt; ohne Lücke geht keine einzige Anfrage hinaus, der tägliche Takt kostet also nichts. Und wenn doch einmal ein Monat ohne Preis bleibt, sagt der Daten-Checker es dir — neue Kategorie Vergleichspreise → Ø Benzinpreis, mit dem Nachtrag-Knopf daneben. Sie erscheint nur, wenn du ein E-Auto hast, und erst ab dessen Anschaffungsmonat.

Danke an gruaGit, der eine Zusage nicht geglaubt, sondern nachgeprüft hat.
Die verbleibende PV-Menge des Tages schrumpfte, wenn die Sonne besser lief als vorhergesagt. Gemeldet von rapahl: Das Live-Board rechnete „verbleibend” als Tagesprognose minus bisherigem IST. In der Tagesprognose stecken für die vergangenen Stunden aber die vorhergesagten Werte, nicht die gemessenen — lief der Vormittag über Plan, fiel die ausgewiesene Restmenge, obwohl die Sonne unverändert weiterschien. An seinen Zahlen: 35,7 kWh Prognose minus 29,8 kWh IST ergaben „~5,9 verbl.”, während die reine Restprognose 12,0 kWh sagte.

Ab jetzt zeigt das Live-Board die Restprognose der noch kommenden Stunden — dasselbe Verfahren, das der Prognosen-Vergleich seit 4.0.x verwendet. Die beiden Sichten beantworten dieselbe Frage jetzt auf dieselbe Weise. Neu daneben: die prozentuale Tagesabweichung des nachgeführten Werts von der Tagesprognose, sichtbar ab 5 % — darunter ist es Rauschen. Sie erscheint nur, wenn eedc den IST-Wert des Tages kennt; die Restmenge erscheint immer, sie ist reine Vorhersage.
Fünf Stellen lasen Parameter-Namen, die es seit v3.25.0 nicht mehr gibt. Damals wurden die Kennwerte der Investitionen auf einheitliche Namen gezogen und der Bestand beim Start umbenannt — fünf Stellen wurden dabei übersehen, und weil ein fehlender Name in der Programmiersprache still nichts liefert statt zu klagen, ist es niemandem aufgefallen. Sichtbar war es an drei Stellen: Die Demo-Daten erzeugten ein E-Auto ohne wirksame Jahresfahrleistung, ohne PV-Ladeanteil, ohne V2H und ohne Batteriekapazität sowie eine Wallbox ohne Ladeleistung — leer ausgerechnet in den Sichten, für die die Demo gebaut ist. Im Daten-Checker haben zwei Prüfungen (V2H aktiv, Entladepreis fehlt und Arbitrage aktiv, Ladepreis fehlt) nie gemeldet, eine dritte meldete eine fehlende Fahrleistung nie. Im Anlagendokumentations-PDF blieben vier Zeilen leer, die nicht erscheinen konnten.

Wen es betrifft: Deine gespeicherten Daten sind unberührt — die Umbenennung des Bestands lief 2026 korrekt, betroffen waren nur diese fünf lesenden bzw. schreibenden Stellen. Nach dem Update meldet der Daten-Checker fehlende Vergleichspreise wieder, das Dokumentations-PDF ist vollständig, und ein neu erzeugter Demo-Bestand rechnet.
Der Zählerstands-Verlauf beschriftete in der Tagesansicht jeden Punkt mit demselben Datum. Gemeldet von dietmar1968 (simon42-Forum) als Wunsch nach der Uhrzeit — gemessen war es ein Fehler: Unter Cockpit → Tag trug die Achse des Zählerstands-Verlaufs an jedem stündlichen Punkt das Datum dieses einen Tages, und der Tooltip zeigte dasselbe Label. Die Achse trug damit keine Information, und die Uhrzeit war die ganze Zeit vorhanden, wurde beim Beschriften aber weggeworfen.

Ab jetzt zeigt die Achse, was im gewählten Fenster variiert: in der Tagesansicht die Uhrzeit, im Jahr den Monatsnamen, über den Gesamtzeitraum Monat und Jahr. Der Tooltip nennt immer Datum und Uhrzeit — damit ist ein einzelner Messwert auch dort eindeutig, wo mehrere Punkte auf denselben Achsenpunkt fallen (im Monatsfenster liegen bei stündlicher Messung 24 Punkte auf einem Tag). Die Monatsansicht sieht unverändert aus, sie war bereits richtig beschriftet.

Danke an dietmar1968, dessen Bildschirmfoto den Fehler gleich mitbewiesen hat.

Added

Die Börsenpreise von morgen stehen jetzt auch in Home Assistant. Der Sensor eedc_preis_rang trug bisher nur den laufenden Tag, während der Preis-Chart unter Cockpit → Live längst beide Tage zeigt. Wer die Nachtladung für den Folgetag planen wollte, musste sich die Kurve selbst besorgen — rapahl hat sich dafür einen eigenen Template-Sensor gebaut. Ab jetzt tragen die Attribute des Sensors einen zweiten Satz: rang_profil_morgen mit allen 24 Stunden, dazu guenstig_schwelle_cent_morgen und optimierter_durchschnitt_cent_morgen, damit sich auch für morgen eine eigene Regel rechnen lässt. morgen_verfuegbar ist immer vorhanden und sagt, ob die Zahlen schon da sind — die Day-Ahead-Auktion veröffentlicht sie gegen 13 Uhr, vorher fragt eedc gar nicht an.

Jeder Tag behält seine eigene Schwelle, und das ist Absicht: Day-Ahead ist ein Tagesprodukt. Ein gemeinsamer Durchschnitt über 48 Stunden würde an einem teuren Tag keine einzige günstige Stunde ausweisen und am billigen fast alle. Neu ist außerdem datum — der Kalendertag, für den ein Profil gilt. Ohne ihn ist ein stehengebliebenes Profil nach Mitternacht nicht von einem aktuellen zu unterscheiden, und eine Automation, die dann auf „morgen” plant, plant auf gestern. Kein bestehender Wert und kein bestehendes Attribut ändert sich — es kommt nur hinzu.
Der gewöhnliche Tagesdurchschnitt des Börsenpreises steht jetzt im Kennzahlenblock. Angeregt von rapahl: „Nicht jeder will ja seinen Akku mit Netzstrom laden.” Nachgemessen war der Punkt schärfer als die Anregung — von sieben Kacheln bezogen sich drei auf dieselbe Größe, nämlich den Durchschnitt ohne die teuersten Stunden (Ø ohne 3 Peaks, Günstig-Schwelle, Abstand zum Ø). Der schlichte Tagesmittelwert, nach dem man zuerst fragt, kam im Kennzahlenblock gar nicht vor.

Neu ist die Kachel „Ø heute”, bewusst vor den Optimierer-Werten. Dazu gibt es den Home-Assistant-Sensor eedc_preis_tages_durchschnitt_cent. Der optimierte Durchschnitt bleibt unverändert — er ist die Bezugsgröße der Günstig-Schwelle, und die verschiebt sich durch die neue Kachel nicht.
Ein zweiter Prognose-Sensor für den nachgeführten Tageswert. Auf Wunsch von rapahl (ausdrücklich für MQTT): eedc_prognose_heute_rollend_kwh — „PV-Prognose heute (nachgeführt)” — trägt den bisher gemessenen Ertrag plus die Prognose der noch kommenden Stunden. Er steht neben eedc_prognose_heute_kwh und ersetzt ihn nicht: Jener bleibt der kanonische Wert, den App, MQTT und Speicherung gemeinsam tragen. Die Differenz der beiden ist keine sinnvolle Größe, und die Sensor-Referenz sagt das jetzt auch.

Changed

Preiskurve und Kennzahlen stehen unter Cockpit → Live nebeneinander statt untereinander. Ebenfalls von rapahl angeregt: Über die volle Seitenbreite wirkte die Preiskurve flach; in zwei Dritteln der Breite wird derselbe Verlauf sichtbar steiler. Auf schmalen Bildschirmen bleibt es einspaltig wie bisher.

Removed

Ein Endpunkt und eine Namens-Heuristik, die niemand benutzt hat. GET /api/anlagen/prognose-quellen/discover hatte keinen einzigen Aufrufer, und der daraus gelieferte Anzeigename der Prognose-Integration wurde per Zeichenketten-Vergleich aus dem HA-friendly_name erraten. Die Erkennung der Prognose-Sensoren selbst bleibt unberührt — sie läuft über die Entity-IDs und wird an anderer Stelle produktiv genutzt.

[4.0.26] - 2026-08-22 — Ein weiterer Benutzerwunsch

Added

Einstellungen lassen sich mit einer PIN schützen — und eedc erscheint bei allen Home-Assistant-Benutzern. Zwei Meldungen, die dieselbe Lücke von zwei Seiten beschreiben: jedema1805 (#393) betreibt Wandtablets mit einem HA-Benutzer ohne Administratorrechte — dort fehlte eedc in der Seitenleiste, weil panel_admin in der Add-on-Konfiguration nicht gesetzt war. Mathek (Discussion #391) möchte umgekehrt, dass Familie und Besucher die Auswertungen ansehen, aber nichts verstellen können. Beides zusammen ergibt eine Funktion: panel_admin: false macht eedc für alle angemeldeten HA-Benutzer sichtbar, und eine optionale PIN unter Einstellungen → Anlage fragt beim ersten Änderungsversuch je Browser-Sitzung nach. Ansehen ist nie gesperrt, hell/dunkel bleibt immer frei, und ohne gesetzte PIN ändert sich gar nichts — der Auslieferungszustand ist unverändert. Der Rückweg bei vergessener PIN verlangt Zugriff auf die Maschine (Add-on-Option einstellungen_pin_zuruecksetzen bzw. EEDC_PIN_RESET=1) und ausdrücklich keine öffentlich aufrufbare Adresse.

Bewusst kein Berechtigungssystem: eedc kennt weiterhin keine Benutzer, keine Rollen und kein Login. Ein naheliegender Weg wäre gewesen, die Benutzerkennung auszuwerten, die der HA-Supervisor als X-Remote-User-* ans Add-on durchreicht — verworfen, weil das genau das Rollenmodell wäre, das es nicht geben soll, und weil es im Standalone-Betrieb gar nicht existiert (dort spricht der Browser eedc direkt an, ohne Supervisor dazwischen). Die Sperre funktioniert in beiden Betriebsarten gleich.

Durchgesetzt wird sie im Backend über die HTTP-Methode, nicht über eine gepflegte Routenliste: Jeder schreibende Aufruf ist erfasst, auch jeder künftige. Ein Wächter (test_einstellungs_sperre_konformitaet.py) liest die Routen aus der OpenAPI und prüft das für jede einzelne; ein zweiter (npm run check:sperre-fetch) hält fest, dass kein Client-Aufruf an der Sperre vorbeigeht. In Cockpit → Tag und Auswertungen → Prognose wird der Knopf „Tag neu berechnen” bei gesetzter PIN ausgeblendet statt abgewiesen — ein Angebot, das zuverlässig in einer Fehlermeldung endet, ist schlechter als keines.

[4.0.25] - 2026-08-21 — Ablesen, nicht aufsummieren

Fixed

Der Zählerstand eines Gas-, Wasser- oder Ölzählers war nicht der Zählerstand. Gemeldet von dietmar1968 (simon42-Forum), und sein Bild hat es bewiesen: Sein Wasserzähler meldete in Home Assistant 47,360 m³, eedc zeigte 90. Betroffen ist jeder Verbrauchszähler, der über einen HA-Sensor läuft — die Kategorie gibt es seit 4.0.23.
- Die Ursache: eedc holt jeden zugeordneten Zähler stündlich aus Home Assistants Langzeitstatistik, und die führt zwei Spalten — state (den abgelesenen Stand) und sum (die reset-bereinigte Verbrauchssumme seit Aufzeichnungsbeginn). Für einen Stromzähler ist sum die richtige und ausdrücklich gewählte Spalte: Ein Tageszähler springt um Mitternacht zurück, nur sum läuft durch. Der Zählerstand eines Gaszählers ist aber keine Menge, sondern ein Stand — und der steht in state. Er lief auf der falschen Schiene mit.
- ⚠ Ein zweiter, stiller Fall steckte darin: Meldet ein Zähler seinen Stand ohne HA-Statistiksumme, verlangte derselbe Weg eine Energie-Einheit — „m³” gehört nicht dazu. Solche Zähler bekamen überhaupt keinen mitgeschriebenen Stand, ohne Meldung.
- Was du davon merkst: Ab dieser Version steht dort die Zahl deines Zählers. Die Verbrauchszahlen waren immer richtig — die einzige Rechnung ist Ende minus Anfang, und die ist gegen einen konstanten Versatz unempfindlich. Wo die alte und die neue Zahl aufeinandertreffen, zeigt eedc keine Differenz, sondern sagt „Der Stand ist gefallen — die Reihe hat einen Bruch”. Ein Zählerstand läuft nicht rückwärts; eine negative Menge auszuweisen wäre die schlechtere Antwort. Die Historie zieht Einstellungen → Daten → Tag neu berechnen nach, soweit Home Assistant die Statistik noch hat.
- ⛔ Ein Startwert- oder Offset-Feld gibt es weiterhin nicht — und braucht es auch nicht. Weicht die Zahl im Sensor von der auf dem Zähler ab, gehört die Korrektur an den Sensor: dort stimmt sie danach überall, auch in deinen HA-Dashboards und Automationen.
- Danke an dietmar1968, der der Antwort widersprochen und den Beleg mitgeliefert hat. Ohne sein Bild wäre der Fehler weiter als Eigenart seines Sensors durchgegangen.
Die HA-Sensoren kannten die gemessene Aufteilung Heizen/Kühlen nicht. Wer die mit 4.0.24 eingeführten Betriebsart-Zähler zuordnet — also genau der, an den sich die Version richtet —, sah die Aufteilung in eedc und bekam in Home Assistant keinen Wert: Der Sensor-Export las die Rohdaten an der Weiche gemessen schlägt abgeleitet vorbei. Betroffen waren REST-Export und MQTT. Die Weiche liegt jetzt als eine Formel im Berechnungs-Layer, die beide Seiten aufrufen.

Changed

Eine Split-Klimaanlage fragt im Monatsabschluss nicht mehr nach Warmwasser. Ein Luft-Luft-Gerät hat keinen Warmwasserkreis; ein dort gepflegter Wert erzeugte eine eingesparte Wärme, die das Gerät nie erzeugt hat — mit Wirkung auf die Gas- und CO₂-Ersparnis. Das Feld verschwindet am Monatsabschluss und in der Feldliste (11 → 10 Felder), bleibt aber in der Zuordnungsfläche sichtbar, damit eine bestehende Zuordnung löschbar bleibt. Die Heizwärme bleibt selbstverständlich — gerade bei Luft-Luft trägt sie die ganze Gas- und CO₂-Ersparnis.

[4.0.24] - 2026-08-21 — Was das Gerät wirklich tut

Added

Alle MQTT-Topics auf einen Blick — neuer Block MQTT-Topics am Ende von Einstellungen → Datenquellen. Zugeklappt, nach Gerät gruppiert, je Zeile das vollständige Topic mit Feldname und Einheit, dazu ein Kopier-Knopf je Zeile und ein „Alle kopieren”. Für alle, die ihre Werte aus ioBroker, FHEM oder einem eigenen Skript schicken und die Topics bisher aus der Sensor-Referenz zusammensuchen mussten.
- Gezeigt werden nur die Topics vorhandener Geräte — nur die sind wirksam. Zuordnen muss man vorher nichts: Ein Feld stellt sich beim ersten empfangenen Wert selbst auf Inbound.
Split-Klimaanlage: Verbrauch je Betriebsart — und je Innengerät (#263). Bisher konnte eedc nur ableiten, was ins Heizen und was ins Kühlen ging: aus dem zugeordneten Betriebsmodus und den Stunden, in denen er galt. Wer die Anteile messen kann, trägt sie jetzt direkt ein — für Heizen · Kühlen · Lüften · Entfeuchten, dazu optional die abgegebene Nutzenergie je Betriebsart. Gemessenes schlägt Abgeleitetes.
- Mehrere Innengeräte: Am Gerät lässt sich unter Innengeräte eine Liste anlegen (Bezeichnung, z. B. „Büro”). Jedes Innengerät bekommt danach eigene Felder — Verbrauch je Betriebsart, Leistung, Soll- und Raumtemperatur —, zuordenbar wie jedes andere Feld (HA-Sensor · MQTT · Connector). Im Live-Bild erscheinen sie unter Auf einen Blick → Innengeräte.
- Alles ist optional, und nichts ändert sich ohne Zutun. Ohne Innengeräte und ohne Betriebsart-Zähler verhält sich eedc exakt wie bisher. Eine Luft-Wasser-Wärmepumpe sieht die neuen Felder gar nicht.
- ⚠ Was ein Innengerät nicht misst: An einem Multisplit hängt ein Außengerät an mehreren Innengeräten. Was eine Hersteller-App dort als Verbrauch eines Innengeräts anzeigt, ist der Anteil des Außengeräts — zugeschrieben an das gerade anfordernde Innengerät, und welches das ist, entscheidet die Einschaltreihenfolge. Der Hersteller sagt es selbst. eedc nimmt die Zahl entgegen und schreibt dazu, was sie bedeutet; die belastbare Menge ist ein eigener Zähler am Außengerät.
- Woher die vier Zähler kommen: In Home Assistant liefert sie ein Utility Meter mit einem Tarif je Betriebsart, umgeschaltet von einer Automatisierung am Zustand der climate-Entität. Die Anleitung dazu steht in der Sensor-Referenz §4a.
- Danke an kingcap1, Klausnn und OB73-gif — ohne ihre Messungen an drei verschiedenen Anlagen wäre daraus eine Rechenregel geworden statt einer Messung.
Börsenpreise: Höchst- und Tiefstpreis des Tages und der Monatsdurchschnitt (angeregt von rapahl). Der Block zeigte, wie teuer die aktuelle Stunde gegenüber heute ist — aber nicht, ob heute überhaupt ein teurer Tag ist. Jetzt stehen Höchstpreis und Tiefstpreis (je mit ihrer Uhrzeit) sowie der Monatsdurchschnitt aus eedcs eigener Mitschrift vorn; die Optimierer-Werte (Ø ohne die 3 teuersten Stunden, Günstig-Schwelle, Abstand) folgen dahinter.
Die Aufteilung Heizen/Kühlen gibt es jetzt auch für einen einzelnen Tag (#263, angeregt von OB73-gif). Bisher stand sie nur je Monat; in Cockpit → Tag fehlte sie. Der Block „Aufteilung Heizen/Kühlen” erscheint dort jetzt im Wärmepumpen-Abschnitt — mit denselben drei Größen wie im Monat: Heizen · Kühlen · nicht aufgeteilt.
- Die Rechnung ist dieselbe, nicht eine zweite. eedc faltet die Stunden ohnehin tageweise; die Monatssicht summiert sie nur hinterher auf. Beide Sichten nehmen jetzt denselben Weg — was der Tag zeigt, steckt unverändert in der Monatssumme.
- ⚠ Ohne zugeordneten Betriebsmodus erscheint der Block gar nicht — statt mit drei Nullen dazustehen. Eine 0 hieße „hat nicht geheizt”; das weiß eedc ohne Sensor nicht.

Changed

Die Günstig-Schwelle sagt jetzt, was 0 % bedeutet (angeregt von rapahl). Der Hinweis dazu erschien bisher erst, nachdem man die 0 eingetippt hatte — also nach der Entscheidung. Wer die Schwelle „abschalten” wollte, bekam damit mehr günstige Stunden statt keine. Die Erklärung steht jetzt in der Beschreibung des Felds: 0 % schaltet nichts ab — die Schwelle liegt dann genau auf dem Tagesdurchschnitt.

Fixed

Die CSV-Vorlage erzeugte drei Spalten, die der eigene Import nicht annahm. Wer unter Einstellungen → Daten die personalisierte Vorlage herunterlädt, ausfüllt und wieder importiert, bekam „Import erfolgreich” gemeldet — und drei Werte fehlten danach, ohne jeden Hinweis:
- Netzladung eines Speichers mit Arbitrage,
- Einspeise-Erlös eines Erzeugers unter Sonstiges (z. B. BHKW),
- der Zählerstand eines Verbrauchszählers — bei diesem Gerät ist das der einzige Wert überhaupt, er war über die Vorlage seit seiner Einführung in 4.0.23 nie importierbar.
- Die Ursache: Die Vorlage baute ihre Spaltennamen aus einer eigenen, von Hand gepflegten Liste, während Export und Import den Namen aus der gemeinsamen Feld-Definition lesen. Die beiden waren auseinandergelaufen. Jetzt kommt der Spaltenname überall aus derselben Quelle; eine neue Prüfung fährt bei jedem Bau den vollständigen Rundlauf über alle Gerätetypen — Vorlage erzeugen, ausfüllen, importieren, jeden Wert wiederfinden.
- Was du tun kannst, wenn du betroffen warst: Lade die Vorlage neu herunter (die alte trägt die falschen Spaltennamen), trage die fehlenden Werte ein und importiere sie mit gesetztem Haken Bestehende Monate überschreiben. Alle anderen Spalten deiner alten Datei sind angekommen — es fehlen ausschließlich die drei genannten.
- ⚠ Nebenbei geradegerückt: Steht bei dir eine Wallbox, bot die Vorlage am E-Auto zusätzlich Spalten für PV-Ladung und Netz-Ladung an, obwohl der Monatsabschluss sie dort ausblendet — die Wallbox misst die Heimladung. Diese Spalten sind aus der Vorlage verschwunden; eingetragen bleibt eingetragen, der Import nimmt sie weiterhin an und wirft nie still etwas weg.
Wärmepumpe und Wallbox blieben in der Tagesansicht leer, obwohl der Wert daneben stand (gemeldet von OB73-gif). Wer sein Gerät über einen Leistungssensor erfasst und keinen kWh-Zähler zugeordnet hat — bei Split-Klimaanlagen der Normalfall —, sah in Cockpit → Tag eine leere Spalte „Wärmepumpe”, während dieselbe Stunde in der gerätebenannten Spalte danebenstand und die Monatsansicht korrekt damit rechnete.
- Die Ursache: Dieselbe Größe liegt an zwei Stellen — die Sammelspalte las nur den Zählerpfad, die Gerätespalte und die Monatsauswertung den Leistungspfad. Beide Spalten werden jetzt aus beiden Pfaden bedient: liegt ein Zähler vor, bleibt er die Wahrheit; fehlt er, trägt der Leistungswert die Spalte. Gibt es zu einem Gerät gar keine Spur, steht dort weiterhin ein Strich und keine erfundene Null.
- ⚠ Mitbehoben, und es war der schwerere Teil: Der Hausverbrauch derselben Tabelle zieht Wärmepumpe und Wallbox vom Gesamtverbrauch ab. Fehlte der Zähler, wurde nichts abgezogen — der Hausverbrauch stand um den Verbrauch dieser Geräte zu hoch, während sonstige Verbraucher in derselben Zeile korrekt abgezogen wurden. Diese Zahl stimmt jetzt.
- ✅ Unberührt bleiben PV und Gesamtverbrauch. Das sind Bilanzgrößen, an denen Performance-Ratio sowie Überschuss und Defizit hängen — dort etwas zu ändern hieße, die Bilanz zu ändern statt eine Anzeige. Keine bestehende Bilanzzahl bewegt sich.
Der Ist-Betrieb einer Klimaanlage kam in der Aufteilung nicht an — betroffen ist jedes Gerät, dessen Integration den laufenden Betrieb meldet (hvac_action): Panasonic, Daikin und die meisten Luft-Wasser-Wärmepumpen. Bei ihnen landete die gesamte Heizen/Kühlen-Aufteilung in „nicht aufgeteilt”, statt auf die beiden Seiten zu gehen.
- Die Ursache war eine Vorrangregel, die sich selbst aushebelte. eedc liest zwei Dinge: den eingestellten Modus (cool) und, wo vorhanden, den laufenden Betrieb (cooling, idle). Der laufende Betrieb soll den eingestellten schlagen — er weiß, ob das Gerät gerade wirklich kühlt oder nur wartet. Beim Lesen der Historie wurde er aber anstelle des Modus eingetragen; danach war nicht mehr unterscheidbar, welches von beidem vorlag, und die Vokabeln des laufenden Betriebs (heating, cooling, defrosting, drying, fan) waren an dieser Stelle unbekannt. Alles davon wurde zu „unbestimmt”.
- ⚠ Geräte ohne dieses Signal waren nie betroffen — eine Mitsubishi-Anlage über MELCloud etwa hat den laufenden Betrieb gar nicht, ihr eingestellter Modus wurde immer richtig gebucht. Das bessere Signal führte zum schlechteren Ergebnis.
- ⚠ Still war es obendrein: Unter Einstellungen → Datenquellen stand beim Betriebsmodus der richtige Klartext („Kühlen (cool)”), weil die Fläche den Momentanwert anders liest als die Aufzeichnung. Wer dort nachsah, sah keinen Fehler.
- ✅ Keine Zahl der Energiebilanz war betroffen. Der Stromverbrauch der Wärmepumpe ist und bleibt die einzige Bilanzgröße; Heizen und Kühlen sind Teilmengen daneben. Falsch war ausschließlich deren Aufteilung.
- Was du tun kannst, wenn du betroffen warst: Die Aufteilung repariert sich für alle Tage, die du über Einstellungen → Daten → Energieprofil neu berechnen lässt — soweit die Historie in Home Assistant noch reicht. Bei der Standardeinstellung sind das etwa 10 Tage, mit erhöhter Aufbewahrungsdauer entsprechend mehr. Ältere Monate lassen sich nicht nachträglich aufteilen: Home Assistant hält Gerätezustände nicht dauerhaft vor.

[4.0.23] - 2026-08-20 — Was zählt, und was nicht

Added

Verbrauchszähler für Gas, Öl und Wasser — erfassen und anzeigen, ohne zu bewerten (#377). Unter Sonstiges gibt es eine vierte Kategorie: Verbrauchszähler. eedc führt dafür den Zählerstand mit — genau die Zahl, die auf dem Zähler steht — und die einzige Rechnung darauf ist die Differenz zwischen Anfang und Ende des betrachteten Zeitraums.
- Vier Anzeigen: aktueller Stand und Veränderung heute in Live → Auf einen Blick; Stand am Anfang/Ende, Differenz und Verlauf als eigener Block in Cockpit → Tag / Monat / Jahr; Stand und Verbrauch je Monat unter Komponenten → Sonstiges; eine Spalte je Zähler in Auswertungen → Tabelle (wählbar, nicht vorausgewählt).
- Der Wert kommt aus einem Sensor (stündlich mitgeschrieben) oder von Hand aus dem Monatsabschluss — wo ein Sensor läuft, wird der mitgeschriebene Stand als Vorschlag angeboten. Die Einheit (m³, l, kg, t, kWh) gehört zum Gerät und ist reine Anzeige: eedc rechnet Zählerstände nie um.
- ⛔ Was ausdrücklich NICHT passiert, und warum das der Kern des Ganzen ist: Der Wert geht in keine Energiebilanz, keine Autarkie- oder Eigenverbrauchsquote, keinen ROI, keine CO₂-Bilanz, nicht in den Gemeinschaftsdatensatz, nicht in den HA-Sensor-Export und in keine Serie des Energieflusses. Gas- und Wasserkosten sind Haushaltskosten; sie in die Rechnung der PV-Anlage zu ziehen, machte deren Zahlen unbrauchbar. Die Wirtschaftlichkeit eines Zählers steht deshalb auf „nicht bewertet” statt auf vier Nullen. Wer keinen Zähler anlegt, merkt von alldem nichts — keine bestehende Zahl bewegt sich.
- ⚠ Zählerwechsel: altes Gerät stilllegen, neues anlegen. Beim alten Zähler ein Stilllegungsdatum setzen und ihn dabei aktiv lassen — dann bleibt seine Historie in allen Auswertungen erhalten, in deren Zeitraum er gemessen hat, und der Verbrauch über den Wechsel hinweg ist die Summe beider Differenzen. Den Haken aktiv zu entfernen bedeutet in eedc „wie gelöscht” und blendet die Ablesungen auch rückwirkend aus.
- Nebenbei behoben: Der Snapshot-Job fragte stillgelegte Geräte weiter bei Home Assistant ab, solange ihre Zuordnung stehenblieb — stündlich, ohne Nutzen. Er überspringt sie jetzt.

Fixed

Ein Cloud-Import erzeugt keinen Geräte-Connector mehr, den es nie gab (#390, gemeldet von gruaGit). Wer seine Daten aus einem Hersteller-Portal holt (Fronius Solar.web, SolarEdge, Growatt, EcoFlow …) und keinen Geräte-Connector eingerichtet hat, sah drei Dinge, die alle nicht stimmten — und der Daten-Checker schickte ihn los, sie zu reparieren.
- Der Daten-Checker meldete „Connector „Connector” liefert für MM/JJJJ keinen Wert” — für ein Gerät, das nie eingerichtet wurde. Der Hinweis war damit nicht auflösbar; wer ihm folgte, landete auf einer Fläche, auf der es nichts zu tun gab. Er erscheint jetzt nur noch bei einem wirklich eingerichteten Geräte-Connector.
- Die Fläche zeigte „Connector aktiv” mit leerem Gerät, leerem Host, leerer Seriennummer und 0 Zählerständen. Sie zeigt jetzt wieder den Einrichtungsschritt.
- „Jetzt ablesen” endete mit „Unbekannter Connector: None” — einer Aussage über ein Gerät, das der Anwender nie angelegt hat. Der Text sagt jetzt, was fehlt.
- ⚠ Der ernsteste Teil war ein Knopf, den niemand drücken musste: Entfernen stand direkt neben diesem Phantom-Gerät — und hätte die Zugangsdaten des Cloud-Imports gelöscht, weil beide in derselben Ablage liegen. Entfernt wird jetzt nur, was dem Geräte-Connector gehört; ohne Geräte-Connector ist der Knopf wirkungslos. Wer betroffen war und nicht geklickt hat, verliert nichts — die Korrektur wirkt lesend, es gibt nichts nachzutragen.
- ✅ Der nächtliche Abruf und die MQTT-Weitergabe waren nie betroffen — beide haben von jeher richtig geprüft, ob ein Gerät eingerichtet ist. Deshalb stand im Aktivitätsprotokoll des Melders auch kein einziger Connector-Fehler. Betroffen waren ausschließlich die vier Stellen, die der Anwender sieht.
- ⚑ Dies ist die Fortsetzung eines Befunds aus 4.0.22, nicht seine Wiederholung: Dort wurde der Wortlaut des Hinweises korrigiert („Der tägliche Abruf ist ausgeschaltet” war frei erfunden). Der Melder bekam den Hinweis danach weiter — nur mit besserem Text. Erst jetzt ist die Ursache weg.
Die Aufteilung Heizen/Kühlen erscheint sofort, statt erst nach dem Monatsabschluss (#263, gemeldet von kingcap1). Wer den Betriebsmodus seiner Klimaanlage zuordnet, sah bisher nirgendwo ein Ergebnis: nicht im Komponenten-Hub, nicht in Cockpit → Monat und → Jahr, und die beiden Home-Assistant-Sensoren blieben leer. Der Melder hat am selben Tag zugeordnet und gefragt, ob „erst ein Tag durchlaufen” müsse.
- Die Ursache war weder ein Tag noch ein Rechenfehler: Die drei Werte standen ausschließlich in der Monatszeile, und die entsteht erst beim Monatsabschluss — den man in eedc von Hand startet. Für den laufenden Monat gibt es ihn nie. Wer heute zuordnet, hätte damit bis Anfang des Folgemonats nichts gesehen.
- Was jetzt gilt: Solange kein Abschluss vorliegt, rechnet eedc die Aufteilung aus den mitgeschriebenen Stunden — dieselbe Rechnung, dieselben Zahlen, nur eben schon während des Monats. Das gilt für alle vier Anzeigen, die beiden Home-Assistant-Sensoren eingeschlossen. Wo ein Abschluss gelaufen ist, bleibt dessen Ergebnis stehen: ein abgeschlossener Monat wird nicht rückwirkend umgeschrieben, und nichts wird doppelt gezählt.
- ⚠ Unverändert bleibt die Grenze: Der Modus wird ab der Zuordnung mitgeschrieben, nicht rückwirkend — Home Assistant bewahrt Zustände wie „Heizen”/„Kühlen” nur wenige Tage auf.
Ein zugeordneter Betriebsmodus zeigt seinen Wert, statt „–” (ebenfalls #263). Unter Einstellungen → Datenquellen stand neben dem zugeordneten Feld ein Strich, obwohl Home Assistant sauber „cool” meldete — die Zeile konnte nur Zahlen anzeigen, und ein Betriebsmodus ist keine. Für den Anwender sah eine einwandfreie Zuordnung damit wie ein Ausfall aus.
- Jetzt steht dort der Klartext mit dem Rohwert daneben: „Kühlen (cool)”. Kennt eedc eine Schreibweise nicht, heißt sie ausdrücklich „Unbestimmt” — dann weiß man, dass diese Zeit später unter „nicht aufgeteilt” landet und nicht still einer Seite zugeschlagen wird. Ein echter Ausfall (unavailable) zeigt weiterhin „–”.
- ✅ Betroffen war ausschließlich die Anzeige — mitgeschrieben wurde die ganze Zeit. Der Betriebsmodus wird über die Historie-Schnittstelle von Home Assistant gelesen, nicht über den Pfad, an dem der Strich entstand. Wo eine Zuordnung stand, ist die Aufteilung ab dem Tag der Zuordnung vorhanden; niemand hat Aufzeichnungszeit verloren. Der Satz steht hier, weil zwei von zwei Meldern aus dem Strich geschlossen haben, die Funktion tue nichts (#263, kingcap1 und OB73-gif) — eine reine Anzeige kann echten Schaden anrichten.

[4.0.22] - 2026-08-20 — Nur sagen, was man weiß

Fixed

Der Community-Vergleich rechnet ein Teiljahr nicht mehr flach auf zwölf Monate hoch (#387, gemeldet von azywietz-web). Wer im laufenden Jahr in Betrieb gegangen ist, hat nur Monate mit Sonne im Datensatz — die schwachen Wintermonate fehlen. Der Community-Server hat aus diesen Monaten einen Mittelwert gebildet und ihn mit zwölf multipliziert. Der Melder hat es an seiner eigenen 2-kWp-Anlage vorgerechnet: aus 636,8 kWh/kWp in sechs Monaten wurden 1.273,6 — und damit Rang 3 von 112, obwohl der Standort realistisch bei etwa 940 liegt.
- Was künftig gilt: Ein Teiljahr wird weiter hochgerechnet, aber saisonal — mit der Ertragserwartung deines eigenen Standorts als Maßstab, nicht mit dem Faktor zwölf. Ein Frühling zählt dann als Frühling und nicht als Zwölftel eines Jahres. Für die Anlage des Melders ergibt das rund 980 statt 1.273,6 kWh/kWp.
- ⚠ Diese Umstellung greift nicht mit diesem Update, sondern am 1. September 2026. Sie braucht Daten, die erst diese Version mitschickt (siehe unten), und die müssen erst bei genügend Anlagen angekommen sein. Der Community-Server rechnet bis dahin unverändert weiter — die Rangliste ändert sich an einem Tag, nicht schleichend über Wochen.
- Was diese Version dafür schon kann: Sobald der Server umgestellt ist, weist eedc einen hochgerechneten Wert als solchen aus („hochgerechnet aus 5 von 12 Monaten”). Dafür ist kein weiteres Update nötig — die Kennzeichnung erscheint von selbst.
- Mit derselben Umstellung kommen zwei weitere Korrekturen: Der Community-Durchschnitt hatte zwei verschiedene Werte (im Add-on 662 kWh/kWp, auf der Community-Seite 840 — dieselbe Größe, derselbe Moment), und Anlagen ohne Vergleichswert bekamen ersatzweise die Platzierung 1 gemeldet. Beides ist im 1.-September-Schritt enthalten.
Der angefangene Monat wandert nicht mehr in den Gemeinschaftsdatensatz. Bisher ging jeder Monat mit Zählerwerten raus — auch der laufende, halb volle. Wer den Abschluss des aktuellen Monats schon anlegt oder ihn importiert, stellte damit ein Bruchstück neben lauter ganze Monate. Messbar war das im Vergleichswert selbst: für August 2026 wies die Community am 19. August 46,3 kWh/kWp aus fünf Anlagen aus — kein August, sondern fünf halbe. Genau diese Reihe benutzt eedc als monatlichen Vergleichswert; wer seinen August damit verglich, sah sich weit über dem Schnitt.
- „Zu Ende” heißt Kalendermonat vorbei, nicht „Monatsabschluss erledigt”. Sonst hinge die Vergleichbarkeit daran, wie früh jemand seine Daten pflegt.
- Was du verlierst: deinen neuesten Monat in der Gemeinschaftssicht, bis er vorbei ist. In eedc siehst du ihn unverändert — vergleichbar war er dort nie.
Warnungen zu MQTT-Topics, die du bewusst abgewählt hast (#389, gemeldet von gruaGit). Wer die Datenquelle eines Feldes auf Keine stellt, weil der Wert von einer anderen Komponente kommt, bekam es trotzdem dauerhaft als „erwartet, nie empfangen” gemeldet — beim Melder vier Stück. Ein abgewähltes Feld, das trotzdem noch Werte bekam, stand zusätzlich als „veraltet” in der Liste.
- Der Grund: Die Liste der erwarteten Topics entstand aus den Feldern, die dein Anlagentyp kennt — sie hat nie nachgesehen, welche Quelle du dem einzelnen Feld zugewiesen hast.
- Ebenfalls behoben, ohne dass es jemand gemeldet hatte: Dasselbe galt für Felder, die du einem HA-Sensor zugeordnet hast. Über MQTT kann dort nie ein Wert ankommen, gemeldet wurde er trotzdem.
- Was weiterhin gemeldet wird: Felder ohne zugewiesene Quelle (dafür ist die Warnung da) und Felder über ein MQTT-Gateway — dessen Werte laufen durch denselben Kanal, ein stummes Gateway ist also eine echte Lücke.
- Dazu: Die Warnung nennt jetzt den vollen Topic-Pfad statt nur des letzten Teils. „leistung_w” gibt es an jedem Gerät; erst der Pfad sagt, an welchem.
Ein Connector-Hinweis nannte eine Ursache, die es nicht gab (Diskussion #390, gemeldet von gruaGit). Fehlten Zählerstände für den laufenden Monat, sagte eedc: „Der tägliche Abruf ist ausgeschaltet.” Das stimmte nie — der Abruf läuft bei jedem eingerichteten Connector täglich um 3:30 Uhr, und einen Schalter dafür gab es überhaupt nicht. Der Knopf Beheben führte zudem auf die Datenquellen-Seite, wo sich nichts daran ändern ließ.
- Jetzt nennt der Hinweis die Uhrzeit des Abrufs und wann er zuletzt lief, und führt zum Geräte-Connector mit dem Knopf Jetzt ablesen — dem Weg, den es wirklich gibt. Scheitert ein Abruf, steht der Grund dort und im Aktivitätsprotokoll.
Die Live-Ansicht zeigte eine zu hohe PV-Erzeugung für heute (#388, gemeldet von Mathek). In der Kachel Heute standen 10,0 kWh, während sein eigener Zähler in Home Assistant zeitgleich 7,65 zeigte — rund 31 % zu viel. Der Grund: eedc hat für diese eine Kachel die Leistung hochgerechnet, statt den Zählerstand zu lesen — obwohl der Zähler zugeordnet war und Einspeisung und Netzbezug direkt daneben genau daraus kamen.
- Betroffen war, wer seine PV über den anlagenweiten Zähler erfasst und keine Messung je Modulgruppe hat — der Normalfall. Bei zugeordneten Einzelzählern je Erzeuger galt weiterhin deren Messung.
- Die Tages- und Monatsansichten waren nicht betroffen; sie lasen immer den Zählerstand. Das erklärt, warum dieselbe Anlage in Live und Tag verschiedene Zahlen zeigte.
- ⚠ Der Hinweistext auf der Datenquellen-Seite hatte recht und der Code nicht: Dort steht bei Modulgruppen ohne eigenen Zähler „Über den Anlagen-Zählerstand abgedeckt — als Summe der ganzen Anlage, auch für Tag und Stunde”. Für Tag und Stunde stimmte das, für die Live-Kachel nicht.

Added

eedc schickt der Community jetzt seinen eigenen Maßstab mit. Vier Angaben kommen neu in den anonymen Datensatz: die PVGIS-Ertragserwartung deines Standorts je Monat und je Jahr, die CO₂-Ersparnis nach eedcs Rechnung und der gemessene Eigenverbrauch in kWh.
- Warum das nötig ist: Der Community-Server hat deine Rohdaten nie gesehen. Er kann nicht wissen, wie viel an deinem Dach zu erwarten war — deine Ausrichtung, deine Neigung, dein Horizont, dein Anschaffungsdatum auf den Tag genau. Genau das braucht die neue Hochrechnung, und genau das weiß nur eedc bei dir zu Hause.
- Nebeneffekt, der eine falsche Zahl korrigiert: Der Server hat die CO₂-Ersparnis bisher selbst gerechnet — aus dem Eigenverbrauch mal einem festen Faktor, ohne Wärmepumpe und E-Mobilität. Bei ausgewiesenen 318,9 Tonnen fehlten allein durch die Wärmepumpen rund 22 %. Künftig steht dort dieselbe Zahl, die dein Cockpit zeigt.
Wer automatisch teilt, sendet den neuen Maßstab einmalig von selbst nach. Damit die Umstellung am 1. September auf möglichst vielen Anlagen aufsetzt, schickt eedc nach dem Update einmal den vollständigen Datensatz — nur bei aktiviertem automatischen Teilen nach dem Monatsabschluss, also mit der Zustimmung, die dafür ohnehin vorliegt. Es wird niemand erstmals geteilt und keine neue Einwilligung eingeführt.
- Alle anderen, die schon einmal geteilt haben, bekommen einen Hinweis mit Knopf — stillschweigend passiert dort nichts.

[4.0.21] - 2026-08-19 — Heizen und Kühlen getrennt

Added

Deine Klimaanlage kann eedc jetzt sagen, ob sie gerade heizt oder kühlt. Eine Split-Klimaanlage ist technisch eine Wärmepumpe: dasselbe Gerät heizt im Winter und kühlt im Sommer — über denselben Stromzähler. eedc sah deshalb nur eine Zahl „Stromverbrauch” und konnte nicht sagen, welcher Teil davon ins Heizen ging. Nachrechnen lässt sich das aus keinem vorhandenen Wert; es geht nur, wenn eedc zur Messzeit mitschreibt, in welchem Modus das Gerät läuft. Genau das ist jetzt möglich: Unter Einstellungen → Datenquellen gibt es bei jeder Wärmepumpe das neue, freiwillige Feld Betriebsmodus. Dort ordnest du die climate-Entität deines Geräts zu (in Home Assistant meist climate.… — die Kachel, auf der Heizen/Kühlen/Aus steht), und eedc hält von da an stündlich fest, in welchem Modus gelaufen wurde. Der Daten-Check weist bei Klimaanlagen darauf hin, solange nichts zugeordnet ist.
- Was du davon siehst: die Aufteilung nach Heizen und Kühlen — siehe den nächsten Punkt. Sie entsteht ab dem Moment der Zuordnung; für die Zeit davor gibt es sie nicht.
- ⚠ Die Aufteilung lässt sich nicht rückwirkend nachtragen. Home Assistant bewahrt Zustände wie „Heizen”/„Kühlen” nur wenige Tage auf — die Langzeit-Statistik gibt es nur für Zahlen-Sensoren. Wer den Sensor heute zuordnet, hat die Aufteilung ab heute; wer wartet, verliert die Zeit dazwischen dauerhaft. Deshalb steht das Feld jetzt schon bereit.
- ⚠ Wer nichts zuordnet, merkt nichts. Der Stromverbrauch zählt unverändert vollständig, keine Zahl bewegt sich, keine Sicht ändert sich.
- ⚠ Es braucht eine laufende Verbindung zu Home Assistant. Wer seine Klimaanlage über den Monatsabschluss, den Statistik-Import oder CSV pflegt, bekommt die Aufteilung nicht — dort gibt es keinen Zeitpunkt, an dem ein Modus mitgeschrieben werden könnte. Über MQTT geht es aus demselben Grund nicht: dieser Weg nimmt nur Zahlen entgegen, keine Zustände.
- ⚠ Ehrlich zur Erprobung: für diesen Schritt stand kein Gerät zum Testen zur Verfügung. Er ist gegen nachgebaute Daten abgesichert, nicht an einer echten Klimaanlage. Das ist der Grund, warum das Feld freiwillig ist und nichts an bestehenden Auswertungen anfasst. Rückmeldungen aus der Praxis sind ausdrücklich willkommen (#263).
- Nebenbei klarer beschriftet: Das Feld Wärmepumpenart trug den Hinweis „Wird für den fairen JAZ-Vergleich in der Community verwendet” — das ist die Nebenwirkung. Die Hauptwirkung stand nirgends: Die Art entscheidet, welche Messwerte eedc von dem Gerät überhaupt erwartet (eine Klimaanlage wird nicht nach Heizwärme gefragt). Zwei gemeldete Klimaanlagen liefen deshalb als „Luft-Wasser”. Der Hinweis sagt es jetzt.
Und jetzt sagt eedc dir auch, was dabei herausgekommen ist: Heizen und Kühlen getrennt. Der Schritt darüber legt die Mitschrift an — dieser wertet sie aus. Unter Komponenten → Wärme/Klima steht bei einem Gerät mit zugeordnetem Betriebsmodus jetzt ein Block „Aufteilung Heizen/Kühlen”: wie viel Strom ins Heizen ging, wie viel ins Kühlen, was übrig bleibt — und über wie viele Stunden des Monats eedc überhaupt mitlesen konnte. Dieselbe Aufteilung steht in Cockpit → Monat und Cockpit → Jahr, und zwei neue Sensoren tragen sie nach Home Assistant.
- „Nicht aufgeteilt” ist eine ehrliche Zeile, keine Restgröße. Darin steckt Standby und alles, was weder Heizen noch Kühlen war (Lüften, Entfeuchten, Automatik ohne Rückmeldung) — und die Zeit, in der eedc keinen Modus mitlesen konnte. Die Stundenzahl daneben trennt die zwei Fälle: Ist sie hoch und bleibt trotzdem ein Rest, lief dein Gerät anders. Ist sie niedrig, hat eedc nicht hingesehen. Diese Zeile wird nie gespeichert, sondern immer frisch gerechnet — sie stimmt deshalb auch für Monate, die du von Hand nachpflegst.
- Heizen und Kühlen sind Teilmengen, keine Summanden. Dein Gesamtverbrauch bleibt exakt der, der er war; die Aufteilung steht daneben und wird nirgends dazugezählt. Alle Bilanzgrößen — Autarkie, Eigenverbrauchsquote, Energiebilanz — sind unberührt.
- Ohne Wärmemengenzähler rechnet eedc die Heizwärme jetzt aus dem Heiz-Strom und deiner gepflegten JAZ — und kennzeichnet sie als abgeleitet. Damit wird deine Klimaanlage in Kostenvergleich, CO₂-Bilanz und Monatsbericht zur ganz normalen Wärmepumpe. ⚠ Die JAZ-Kachel bleibt in diesem Fall „—”, und das ist Absicht: Wärme durch Strom zu teilen, wenn die Wärme aus genau diesem Strom gerechnet wurde, ergibt wieder nur die JAZ, die du eingetragen hast — eine Zahl, die nichts misst. ⚠ Ohne gepflegte JAZ wird nichts abgeleitet, auch nicht aus einem Vorgabewert. ⚠ Ein vorhandener Wärmemengenzähler oder ein von Hand gepflegter Wert gewinnt immer — abgeleitet wird nur, wo nichts Gemessenes steht.
- ⚠ Eine später korrigierte JAZ heilt alte Monate nicht. Jeder Monat behält den Faktor, der beim Abschluss galt — genauso wie ein Tarif den Preis seines Monats behält. Das hält deine Historie stabil, heißt aber auch: Wer die JAZ nachträglich richtigstellt, korrigiert damit nicht die Vergangenheit.
- ⚠ Kühlen spart nichts — es kostet. Die Ersparnis gegenüber deiner alten Heizung wird nur aus der Heizhälfte gerechnet; der Kühlstrom taucht in den Stromkosten auf, aber nicht im Vergleich. Ohne diese Trennung wies eine überwiegend kühlende Klimaanlage eine negative Ersparnis und eine negative CO₂-Bilanz aus, obwohl sie im Winter sauber geheizt hat. Für dieselbe Anlage stehen jetzt +2,48 € statt −45,04 € und +8,2 kg CO₂ statt −52 kg.
- ⚠ Widersprüche werden nicht stillschweigend zurechtgebogen. Trägst du den Monats-Stromverbrauch nachträglich kleiner ein als die bereits erfasste Aufteilung, verwirft eedc die Aufteilung, statt sie passend zu kürzen — und der Daten-Check sagt dir, welche Monate betroffen sind und wie du sie auflöst.
- ⚠ Ehrlich zur Erprobung, unverändert: es stand kein Gerät zum Testen zur Verfügung. Die Auswertung ist gegen nachgebaute Daten und eine eigene Testinstanz abgesichert, nicht an einer echten Klimaanlage. Rückmeldungen aus der Praxis sind ausdrücklich willkommen (#263).

Fixed

In Österreich und der Schweiz holte eedc die Wetterdaten beim Deutschen Wetterdienst — teils gar keine. (Gemeldet von gruaGit, #386.) Die Wetterquelle „Automatisch” soll Bright Sky (DWD) nur in Deutschland verwenden — so steht es im Handbuch und so steht es im Auswahlfeld. Entschieden wurde es aber über ein Koordinaten-Rechteck, und das schließt halb Österreich und die Nordostschweiz mit ein: Salzburg, Innsbruck, Linz, Bregenz, Zürich und Basel liegen darin. Das Feld Land aus deinen Stammdaten wurde an dieser Stelle nie gelesen — wer „Österreich” einstellte, bekam trotzdem den DWD.
- Schlimmer als die falsche Quelle war das Ergebnis: eine stille Null. Bright Sky liefert Messwerte deutscher Wetterstationen. Für einen Standort ohne solche Station in Reichweite kommt zwar eine Antwort zurück, aber ohne einen einzigen Strahlungswert — und eedc nahm sie als gültig an, statt die zweite Quelle zu fragen, die längst in der Kette stand. Am Standort des Melders (Salzkammergut) bot der Monatsabschluss deshalb 0,0 kWh/m² Globalstrahlung an; richtig waren 206,5. In Zürich dasselbe (0,0 statt 222,4). Bei Salzburg fiel es nicht einmal auf: Dort gibt es eine deutsche Station 11,5 km hinter der Grenze, die Zahl sah gültig aus und war 17 % zu niedrig.
- Das betrifft auch deutsche Standorte. Wo die nächste DWD-Station keine Strahlung misst, gab es dieselbe Null — auf Sylt zum Beispiel. Auch dort kommt jetzt ein echter Wert (182,1 kWh/m²).
- Was sich für dich ändert: Steht bei dir Österreich, Schweiz oder Italien, rechnet „Automatisch” ab sofort mit Open-Meteo. Steht dort Deutschland — oder gar nichts, wie bei den meisten Bestandsanlagen —, bleibt alles wie es war; das ist auf die Nachkommastelle gegengemessen.
- Und das Land wird jetzt beim Eintragen der Adresse erkannt. eedc hat die Länderangabe bisher nicht nur ignoriert, sondern bei der Adresssuche aktiv „Deutschland” mitgeschickt — auch für einen österreichischen Ort. Jetzt übernimmt eedc das Land aus dem Suchergebnis (und den passenden USt-Satz gleich mit), solange du es nicht selbst gesetzt hast. Auch der Einrichtungs-Assistent legt Anlagen damit nicht mehr grundsätzlich als deutsche an.
- Die gespeicherte Wetterquelle wirkt jetzt überhaupt. Wer unter Einstellungen → Anlage bewusst „Open-Meteo” oder „Bright Sky” gewählt hatte, bekam beim Wetter-Autofill trotzdem „Automatisch” — die Einstellung wurde gespeichert, angezeigt und beim Abruf nie gelesen. Ein Feld, das nichts tut, ist schlimmer als keins.
- Was eedc außerhalb Deutschlands leistet und was nicht, steht jetzt zusammenhängend im Handbuch (Einstellungen → §2.1a): Die Rechenkerne, PVGIS und Open-Meteo tragen überall; Börsenpreise gibt es für DE und AT, Bright Sky nur für DE. Steuerrecht, Netzentgelte und Förderprogramme bildet eedc bewusst nicht nach — es rechnet mit den Zahlen, die du einträgst.
Der Jahresbericht erfand einer Klimaanlage drei Wärmemengen. Eine Split-Klimaanlage hat keinen Wärmemengenzähler — sie kann gar nicht sagen, wie viel Wärme sie abgegeben hat. Im PDF standen trotzdem Wärmeenergie gesamt 0 kWh · davon Heizung 0 kWh · davon Warmwasser 0 kWh, während die Jahresarbeitszahl in derselben Tabelle korrekt „–” sagte. Eine Null ist eine Behauptung — sie heißt „gemessen, war nichts”, und das stimmte hier nicht. Jetzt steht auch dort „–”. Der Stromverbrauch bleibt eine Zahl: Er ist gemessen und die einzige Aussage, die es über das Gerät zu treffen gibt. Cockpit und Auswertungen haben das schon immer richtig gemacht; nur der Bericht nicht.
Drei Daten-Checker-Hinweise, die niemand auflösen konnte. Alle drei gemeldet von azywietz-web (#382, #384, #385); keiner von ihnen bewegt eine Zahl — es ging jedes Mal darum, was eedc über deine Anlage behauptet.
- „Einspeisevergütung fehlt” bei Nulleinspeisung (#382). Der Hinweis erschien, sobald irgendeine Kilowattstunde eingespeist war — auch wenn es die reine Regelungstoleranz eines Balkonkraftwerks mit Nulleinspeisung war (beim Melder rund 5 kWh in fünf Monaten). Abstellen ließ er sich nur mit einem falschen Vergütungssatz. Jetzt gilt eine Schwelle von 50 kWh im Jahr, und der Hinweis fordert nichts mehr: Er sagt, womit eedc rechnet (0 ct/kWh, so wie es im Tarif steht), und nennt Nulleinspeisung ausdrücklich als richtigen Fall. Entsprechend ist er jetzt eine Info, keine Warnung — was du einträgst, wird gerechnet.
- Fehlender Zähler am Balkonkraftwerk, obwohl das Modul misst (#384). Seit v4.0.18 dürfen PV-Module an einem Balkonkraftwerk hängen; gemessen wird dann am Modul. Der Daten-Checker wusste davon nichts und forderte weiter einen eigenen Zähler am Balkonkraftwerk — für einen Wert, den es dort nicht zu holen gibt. Jetzt erkennt er die Zuordnung und sagt es mit einer eigenen Zeile („N Balkonkraftwerk(e) über die zugeordneten PV-Module gedeckt”). ⚠ Ein Balkonkraftwerk ohne Modul-Kinder misst weiterhin selbst und wird unverändert geprüft.
- „Verdacht auf PV-Doppelerfassung” nach einem Verbindungsausfall (#385). Fällt die Verbindung zu einem kumulativen Zähler aus, liefert das Gerät den Zuwachs beim Wiederverbinden nach — Home Assistant bucht ihn in eine einzige Stunde, und der Tag steht weit über dem physikalisch Möglichen. eedc deutete das als Doppelerfassung und behauptete sogar eine Ursache, die nicht geprüft war. Diese Tage erkennt eedc längst als „Counter-Spike” und meldet sie mit dem passenden Reparatur-Weg — nur wusste die eine Prüfung nichts von der anderen. Jetzt zählen Spike-Tage nicht mehr als Beleg für Doppelerfassung; sind alle auffälligen Tage so erklärt, sagt eedc das ausdrücklich, statt zu schweigen. Bleiben unauffällig erklärte Tage übrig, kommt der Verdacht wie bisher — dann aber mit einer Liste möglicher Ursachen statt einer einzigen Behauptung. ⚠ Es werden keine Werte korrigiert, gekappt oder ausgeblendet: Der Ausfall ist eine Sache deiner Datenquelle, eedc sagt nur nicht mehr, es wisse etwas, das es nicht weiß.
Wärmepumpen im Neubau bekamen drei Hinweise, die sie nicht auflösen konnten — Klimaanlagen, mit denen geheizt wird, bekamen keinen einzigen. (Gemeldet von azywietz-web, #383.) Seit v4.0.18 kannst du bei einer Wärmepumpe „Nichts ersetzt (Neubau)” eintragen; die Wirtschaftlichkeitsrechnung nimmt das seither ernst und schreibt „nicht bewertet” statt einer erfundenen Gaskessel-Ersparnis. Der Daten-Check wusste davon nichts. Er fragte stattdessen die Bauart ab — und lag damit an beiden Enden daneben: Wer im Neubau baut, las weiter „Alter Energiepreis nicht gesetzt” und „Heizwärmebedarf nicht gesetzt”, obwohl es keine alte Heizung gibt, gegen die sich etwas rechnen ließe. Und wer mit seiner Klimaanlage tatsächlich heizt, bekam die beiden nie zu sehen — obwohl seine Ersparnis genau daran hängt. Jetzt entscheidet die Pflege: Steht dort „Nichts ersetzt”, bleiben beide Hinweise aus; steht dort Gas, Öl oder Strom, erscheinen sie — bei jedem Gerät gleich, egal welcher Bauart. ⚠ Was sich bei dir sichtbar ändert: Jede Wärmepumpe mit „Nichts ersetzt” verliert zwei Hinweise. Jede Klimaanlage, bei der noch der alte Vorgabewert „Gas” steht, bekommt sie neu — dann aber auflösbar: Trag „Nichts ersetzt (Neubau)” ein, wenn du mit dem Gerät nur kühlst. Es werden keine Daten still geändert und nichts migriert.
- Der dritte Hinweis war eine andere Frage, als sein Text vermuten ließ. „Alternativkosten (Gas-/Ölheizung) fehlen” klingt nach der ersetzten Heizung, meint aber die vermiedene Anschaffung: Was hättest du stattdessen kaufen müssen? Der Betrag mindert die Anschaffungskosten, nur die Differenz muss sich amortisieren. Ein Neubau ersetzt keine Heizung — hat aber trotzdem keinen Gaskessel gekauft. Der Hinweis gilt deshalb jetzt für jede Wärmepumpe und sagt, was er vorher verschwieg: 0 ist eine gültige Antwort und lässt ihn verschwinden. Dieselbe Formulierung steht auch im Eingabefeld, so wie bei fünf anderen Komponententypen längst.
Eine Klimaanlage bekam im Komponenten-Hub vier Nullen statt vier ehrlicher Striche. Unter Komponenten → Wärme/Klima stand für ein Gerät mit 4.375 kWh gemessenem Stromverbrauch: JAZ 0,00 · Stromkosten 0,00 € · Gas/Öl 0,00 € · Ersparnis 0,00 €, dazu ein Block „CO₂-Ersparnis: 0 kg gegenüber fossiler Heizung” und ein Balkendiagramm „Kostenvergleich WP vs. Gas/Öl” mit zwei leeren Balken. Dieselbe Anlage sagte in Cockpit → Jahr korrekt „—” und in Auswertungen → ROI „nicht bewertet” — drei Sichten, drei Antworten auf dieselbe Frage. Eine 0 ist eine Aussage („es war nichts”), und die war hier falsch: Es gab keinen Wärmemengenzähler und keine ersetzte Heizung, also nichts zu berichten. Jetzt zeigen alle drei Sichten dasselbe. ⚠ Eine Zahl kommt dabei neu hinzu, statt zu verschwinden: die Stromkosten. Sie hängen an Verbrauch und Tarif und haben mit der alten Heizung nichts zu tun — im gemessenen Beispiel 1.340,50 €. Der Block heißt in diesem Fall „Stromkosten” statt „Kostenvergleich” und sagt daneben, warum es nichts zu vergleichen gibt. ⚠ Wärmepumpen mit gemessener Wärme und gepflegtem Energieträger sehen keine einzige veränderte Zahl. ⚠ Trägt dein Gerät eine gemessene Wärmemenge, bleibt die JAZ stehen — auch wenn es nichts ersetzt hat; sie ist dann eine echte Kennzahl, nur der Geld-Vergleich entfällt. (Der Punkt geht auf eine Zusage an alex_s9027 vom Mai zurück, die JAZ-Kachel bleibe „sauber leer” — für das Cockpit stimmte sie, für den Hub nicht.)

[4.0.20] - 2026-08-18 — Eine Kilowattstunde, ein Preis

Fixed

Die Ersparnis eines Speichers wurde zu einer Zahl addiert, die ihn schon enthielt. Unter Auswertungen → ROI rechnet eedc die Ersparnis der Anlage aus dem Eigenverbrauch — also aus allem, was erzeugt und nicht eingespeist wurde. Was durch den Akku läuft, steckt darin: Es wurde ja nicht eingespeist, sondern später im Haus verbraucht. Daneben stand der Speicher trotzdem noch einmal mit seinem eigenen Beitrag, und beides wurde addiert. An einer gemeldeten Anlage waren das 2.133 kWh Eigenverbrauch zu 31,95 ct plus 717 kWh Entladung zu 23,95 ct — 55,9 ct für eine Kilowattstunde, die einmal geflossen ist. Die Jahres-Ersparnis stand bei 896 € statt 724 €, die Amortisation bei 2,2 statt 2,8 Jahren. Jetzt wird zerlegt statt addiert: Die Gesamtzahl kommt weiterhin aus der Anlagen-Rechnung, und der Speicher bekommt seinen Anteil daraus — er behält also seine eigene Zahl, sie zählt nur nicht mehr doppelt. ⚠ Betroffen war jede Anlage mit Speicher, unabhängig davon, ob er einem Wechselrichter oder Balkonkraftwerk zugeordnet ist oder eigenständig geführt wird — der häufigste Fall ist der eigenständige AC-Speicher ohne Zuordnung. ⚠ Deine Zahlen werden kleiner und deine Amortisation länger. Das ist die Korrektur einer Überschätzung, keine Verschlechterung deiner Anlage. ⚠ Wer Strom aus dem Netz in den Speicher lädt (dynamischer Tarif, Arbitrage), behält diesen Anteil unverändert: Er stammt aus der Tarifdifferenz und steckt gerade nicht im Eigenverbrauch. ⚠ Energiebilanz, Autarkie, Eigenverbrauchsquote und CO₂ waren nie betroffen — dort war die Sperre gegen Doppelzählung immer richtig. (Gefunden beim Nachstellen der Anlage aus Issue #381 an einer Testinstanz.)

[4.0.19] - 2026-08-18 — Zahlen, die ihre Grundlage kennen

Fixed

Wer ein bestimmtes Wettermodell gewählt hat, sah am Rand von dessen Reichweite einen Tag mit fast 0 kWh. In Cockpit → Live und in der 14-Tage-Prognose stand dort ein Tag mit einem Ertrag nahe null und einer Temperatur von „—” — eingerahmt von normalen Werten davor und danach. Es sah nach einem außergewöhnlich schlechten Tag aus, war aber gar keine Wettervorhersage: Jedes Wettermodell hat eine Reichweite, und am letzten Tag innerhalb dieser Reichweite liefert es oft nur noch die ersten Stunden. Ein gemessenes Beispiel: DWD ICON-D2 (Reichweite 2 Tage) endete um 08:00 — die 15 Stunden danach, also der gesamte Ertragszeitraum, fehlten schlicht. eedc holt für solche Fälle zusätzlich eine allgemeine Vorhersage, verwarf sie aber genau dann, wenn das gewählte Modell für den Tag „irgendetwas” geliefert hatte — auch wenn es nur ein paar Nachtstunden waren. Jetzt entscheidet nicht mehr, ob das Modell etwas zu dem Tag sagt, sondern wie viel des Tages es abdeckt: Wo die allgemeine Vorhersage mehr Stunden trägt, trägt sie den Tag. ⚠ Deine Modellwahl bleibt unangetastet — bei gleicher Abdeckung behält dein Modell den Vorrang, Tag für Tag. Wer automatisch eingestellt hat, war nie betroffen und sieht keine veränderte Zahl. ⚠ Der Tag bekommt auch seine übrigen Werte zurück — Temperatur, Nachmittagsertrag und Niederschlag standen dort ebenfalls leer. ⚠ Die Quellenangabe nennt beide Modelle, wenn sich ein Zeitraum zwei Quellen teilt. ⚠ Betroffen war mehr als die Anzeige: dieselbe Prognose speist die Sensoren in Home Assistant und die nächtliche Genauigkeits-Mitschrift, aus der eedc seinen Lernfaktor bildet — ein Tag mit erfundenen 0 kWh ging dort als Messpunkt ein. (Gefunden an der eigenen Anlage.)
Bei einem Balkonkraftwerk mit zugeordneten Modulen und Speicher zählte eedc dieselbe Ersparnis dreimal. Wer sein Balkonkraftwerk so erfasst hat, wie es seit v4.0.18 möglich ist — PV-Module und Speicher als zugeordnete Komponenten darunter —, bekam unter Auswertungen → ROI für jede der drei Ebenen eine eigene Zeile mit eigener Jahres-Ersparnis, und die Gesamtzeile addierte sie. Alle drei Beträge stammen aber aus derselben Energie: dem Strom der Module. An der gemeldeten Anlage standen so 1.079 € Ersparnis im Jahr statt der gemessenen 606 €, und die Gesamt-Amortisation bei 1,9 statt 3,3 Jahren — die Anlage sah rund 43 % schneller bezahlt aus, als sie ist. Bei einem Wechselrichter war das nie so: dort fasst eedc Gerät, Module und DC-Speicher seit jeher zu einer Systemzeile zusammen, gerade weil sich ihre Ersparnisse nicht addieren lassen. Diese Regel gilt jetzt für das Balkonkraftwerk genauso: hängen Komponenten daran, ist es der Kopf eines Systems und bekommt eine gemeinsame Zeile, in der die Komponenten aufgeklappt danebenstehen. ⚠ Die Zeile behält den Namen deines Geräts und sein Symbol — sie heißt nicht „PV-System”. ⚠ Nebenbei behoben: Das zugeordnete Modul stand mit dem Zusatz „(ohne WR)” und der Aufforderung „bitte zuordnen” da — obwohl es zugeordnet war, nur eben an ein Balkonkraftwerk. ⚠ Ein Balkonkraftwerk ohne zugeordnete Komponenten sieht keine einzige veränderte Zahl. ⚠ Betroffen war auch, wer nur einen Speicher zugeordnet hat (seit v4.0.5 möglich) — dort standen zwei Zeilen statt drei; die Summe bleibt dort unverändert, sie steht jetzt nur an einer Stelle statt an zweien. (Gemeldet von azywietz-web mit Rechnungen, Messdaten und Rechenweg.)
Ein Balkonkraftwerk mit mehreren Modulen rechnete nur mit einem davon. Wo eedc die Wirtschaftlichkeit eines Balkonkraftwerks schätzt — also überall dort, wo keine gemessenen Modulwerte vorliegen —, las es die Nennleistung eines einzelnen Moduls und ließ die Anzahl außer Acht. Ein Balkonkraftwerk mit 4 × 500 Wp rechnete damit mit 500 Wp statt 2.000 und meldete rund ein Viertel seiner Ersparnis; unter Auswertungen → ROI stand dort eine viel zu lange Amortisation. Die Leistung kommt jetzt aus derselben Quelle wie überall sonst im Programm — sie findet die Angabe unabhängig davon, ob sie als „Leistung pro Modul × Anzahl”, als berechneter kWp-Wert oder aus einem Import stammt. ⚠ Deine Zahlen bewegen sich, wenn du eine Anzahl gepflegt hast — nach oben, und zwar in die richtige Richtung. Ein Balkonkraftwerk mit einem einzigen Modul sieht keine veränderte Zahl. ⚠ Der Hinweistext nennt jetzt dieselbe Leistung, mit der gerechnet wurde — vorher stand dort „500 Wp” neben einer Zahl, die zu 500 Wp passte, obwohl das Gerät 2.000 hat. (Gefunden beim Nachrechnen der Tabelle aus Issue #381 — der Melder hatte den Fehler mitgeliefert, ohne ihn zu kennen.)
Im Monat der Inbetriebnahme sah jede Anlage schlecht aus. Unter Auswertungen → Prognose stellt eedc der gemessenen Erzeugung je Modul den PVGIS-Erwartungswert gegenüber. Im Anschaffungsmonat stand dort die Erwartung für den ganzen Monat — auch wenn die Anlage erst am 19. ans Netz ging. Die Kennzahl maß damit das Inbetriebnahme-Datum statt die Anlage: An der gemeldeten Anlage stand der März bei 0,35 (175,1 kWh erwartet gegen 60,8 gemessene), während dieselbe Anlage in jedem vollen Monat über 1,0 lag — und dieser eine Monat zog die Jahresbilanz von etwa 1,08 auf 0,97. Jetzt zählt der Erwartungswert nur die Tage, an denen es das Gerät gab: im Beispiel 13 von 31, also 73,4 kWh und eine Kennzahl von 0,83, die zu den übrigen Monaten passt. ⚠ Der Monat der Stilllegung wird genauso behandelt. ⚠ Volle Monate ändern sich um keine Stelle, und die Historie ebenfalls nicht. ⚠ Innerhalb des Monats wird gleichmäßig verteilt — im Frühjahr trägt die zweite Monatshälfte etwas mehr, der gekürzte Erwartungswert fällt dort also eher zu niedrig aus. ⚠ Der saisonale Vergleich („wie fällt der Mai typischerweise aus”) bleibt bewusst ungekürzt: er mittelt über Jahre, dort wäre die Kürzung eine doppelte Strafe. (Gemeldet von azywietz-web in einer GitHub-Discussion, mit einer Monatstabelle als Beleg.)

[4.0.18] - 2026-08-17 — Einrichtung, die nicht gegen dich arbeitet

Added

Ein Balkonkraftwerk kann jetzt mehrere Ausrichtungen abbilden — über zugeordnete PV-Module. Ein Balkonkraftwerk trägt in eedc eine Ausrichtung und eine Neigung für das ganze Gerät. Wer seine Module über Eck hängen hat — Balkon und Terrasse, Ost und West —, konnte das bisher nicht erfassen, und der naheliegende Ausweg über Einstellungen → PV-Module war gesperrt: Ein PV-Modul musste einem Wechselrichter zugeordnet werden, und ein Balkonkraftwerk war keiner. Dabei ist ein Balkonkraftwerk funktional Erzeuger und Wechselrichter in einem, und einen Akku durfte es längst tragen. Das war keine Entscheidung, sondern eine Lücke. Jetzt gilt: PV-Module lassen sich einem Balkonkraftwerk zuordnen — im Formular unter Einstellungen → Investitionen und im Einrichtungsassistenten. Jedes Modul trägt dann seine eigene Ausrichtung und Neigung, und die Prognose rechnet jede Richtung getrennt (bei einer Ost/West-Aufteilung ein sichtbar anderer Tagesverlauf als bei einer gemittelten Annahme). ⚠ Was das Balkonkraftwerk dabei abgibt: Nennleistung, Ausrichtung und Neigung kommen ab dann von den Modulen — das Gerät zeigt als Leistung die Summe seiner Module, und die eigenen Felder beschreiben nur noch das Gerät. Das Formular sagt es an der Stelle. ⚠ Was es behält: die Wechselrichter-Leistung. Die 800 W gehören dem Gerät und begrenzen weiter die Summe seiner Module — sie ergeben sich gerade nicht aus ihnen. Das sind zwei verschiedene Grenzen, und nur die Modulleistung wächst mit der Zuordnung. ⚠ Der Monatswert Erzeugung am Balkonkraftwerk bleibt voll nutzbar — bei einem Set ist der Wechselrichter meist der einzige Zähler, den es gibt. Er gilt dann als Gesamtsumme der Module: Wo ein Modul einen eigenen Messwert hat, gewinnt der; die übrigen bekommen den Rest nach Leistungsanteil. Doppelt gezählt wird nichts — Autarkie, Eigenverbrauchsquote, CO₂, Finanzen, der Community-Datensatz und die HA-Sensoren tragen die Erzeugung genau einmal. ⚠ Nachträglich richtiggestellt (August 2026): Für „Finanzen” stimmte dieser Satz nicht. Unter Auswertungen → ROI zählte eine Hierarchie aus Balkonkraftwerk, Modulen und Speicher ihre Ersparnis mehrfach; die Gesamt-Amortisation stand dadurch deutlich zu kurz. Behoben in v4.0.19. Unauffällig war es, weil die Sperre gegen Doppelzählung auf der Energieseite saß — dort galt der Satz — und die Wirtschaftlichkeit über die Struktur einen anderen Weg nahm. ⚠ Wer keine Module zuordnet, sieht keine einzige veränderte Zahl. (Gewünscht von azywietz-web in einer GitHub-Discussion und von Daniel im Forum simon42 — unabhängig voneinander, mit demselben Punkt.)

Fixed

Ein Balkonkraftwerk aus dem Einrichtungsassistenten bekam keine Solarprognose. Wer sein Balkonkraftwerk über den Einrichtungsassistenten angelegt hat, sah in Cockpit → Live und Cockpit → Aussicht keine Prognose — obwohl Leistung pro Modul, Anzahl, Ausrichtung und Neigung sauber gepflegt waren. Ursache waren zwei Hälften desselben Problems: Der Assistent hat die Nennleistung nur als „Anzahl × Leistung pro Modul” hinterlegt (das Investitionsformular schreibt zusätzlich einen berechneten kWp-Wert), und drei Stellen im Prognose-Pfad lasen ausschließlich diesen berechneten Wert. Sie fanden dort 0 kW, verwarfen das Gerät als „ohne Leistung” — und bei einer Anlage, die nur aus einem Balkonkraftwerk besteht, blieb damit nichts übrig, worüber sich eine Prognose rechnen ließe. Beide Hälften sind behoben: Die Lesestellen fragen jetzt die Nennleistung so ab, wie sie beim Balkonkraftwerk zustande kommt, und der Assistent hinterlegt sie zusätzlich berechnet — wie das Formular. ⚠ Der Fix wirkt ohne Zutun und rückwirkend, auch für Anlagen aus einem Backup: Die Prognose ist ab dem nächsten Aufruf da, es muss nichts nachgepflegt und nichts neu angelegt werden. ⚠ Betroffen war mehr als die Anzeige: Der nächtliche Vorablauf, der die Prognosegenauigkeit mitschreibt und daraus den Lernfaktor bildet, brach bei diesen Anlagen ebenfalls ab — er bekam nur an Tagen einen Messpunkt, an denen jemand Cockpit → Live geöffnet hat. ⚠ Wer sein Balkonkraftwerk über das Formular angelegt hat, war nie betroffen und sieht keine veränderte Zahl. ⚠ Nebenbei: In der gespeicherten PVGIS-Prognose stand die Zeile des Balkonkraftwerks mit „0,0 kWp” — jetzt mit seiner echten Leistung. (Gefunden über eine Rückmeldung von Daniel im Forum simon42, der eedc mit ausschließlich einem Balkonkraftwerk einrichtete.)
Im Reiter Komponenten blitzte nach dem Erfassen kurz noch der Hinweis „noch keine Monatswerte erfasst” auf. Der Reiter erklärt bei einem leeren Gerät, warum dort nichts steht. Diese Erklärung wurde zwischengespeichert — mit der Folge, dass sie nach dem Erfassen von Monatswerten beim Zurückwechseln für einen Moment über den nun gefüllten Blöcken stand, bis die Antwort des Servers eintraf. Ein Hinweis über die Abwesenheit von Daten darf nicht aus dem Zwischenspeicher kommen: Er wird jetzt jedes Mal frisch geholt und erscheint erst, wenn er zutrifft. ⚠ Kein Nachteil beim Laden: Solange die Antwort aussteht, zeigt der Bereich gar nichts — vorher wie nachher gibt es dort keinen Platzhalter. ⚠ Der Hinweis selbst ist unverändert, samt Knopf und Ziel.
Nach dem Löschen der letzten Anlage endete jedes Speichern in „Anlage nicht gefunden”. eedc merkt sich, welche Anlage zuletzt ausgewählt war. Diese Merkung wurde beim Löschen nie geräumt — und die Prüfung, ob es die gemerkte Anlage überhaupt noch gibt, stieg ausgerechnet dann aus, wenn gar keine Anlage mehr da war. Wer seine einzige Anlage löschte und danach eine Komponente anlegen wollte, füllte das Formular aus, klickte auf Speichern und bekam die technische Meldung „Anlage nicht gefunden” — für eine Anlage, die er selbst gelöscht hatte. Dasselbe im Einrichtungsassistenten: Er lud die gemerkte Anlage beim Start, bekam die Auskunft „gibt es nicht mehr” und verwarf sie stillschweigend; die tote Merkung blieb liegen und fiel erst beim Speichern auf. eedc räumt die Merkung jetzt, sobald feststeht, dass keine Anlage existiert, und der Assistent kehrt in diesem Fall zum Schritt Anlage zurück. ⚠ Ein kurzer Verbindungsabbruch räumt nichts — nur die belegte Auskunft „diese Anlage gibt es nicht mehr” zählt, ein Ladefehler nicht. Sonst ginge bei jedem Aussetzer die Auswahl verloren. ⚠ Wer eine Anlage hat, sieht keine Änderung. ⚠ Der Ausweg war bisher, einfach eine neue Anlage anzulegen — dann lief die Prüfung wieder und ersetzte die tote Merkung. Das musste man nur erst einmal wissen. (Gefunden über eine Frage im Forum simon42 bei der Ersteinrichtung.)
Ein Gerät unter Sonstiges stand in der Stundentabelle mit negativem Verbrauch. Wer einen Heizstab, eine Poolpumpe oder eine Klimasteckdose als Sonstiges/Verbraucher führt, las in Cockpit → Tag Werte wie −3,14 und −2,45, in der Summenzeile −5,59 kWh — ein Verbrauch mit Minuszeichen. Ursache war eine Vorzeichen-Regel aus dem Diagramm: Der Tagesverlauf stellt Quellen nach oben und Senken nach unten dar, jede Senke bekommt dafür ein Minus. Genau diese Werte werden gespeichert und landeten unverändert in der Tabelle, wo dasselbe Minus etwas anderes behauptet. In der Tabelle, der Summenzeile und im CSV-Export steht jetzt der Betrag. ⚠ Die Batterie behält ihr Vorzeichen — dort ist die Richtung die Aussage (Laden gegen Entladen), genau wie bisher. ⚠ Es wurde nichts umgerechnet: Der Fix wirkt in der Anzeige, deshalb sind auch alle zurückliegenden Tage sofort richtig — niemand muss etwas neu berechnen. Die Energiebilanz, der Hausverbrauch und alle Monatswerte waren nie betroffen. (Sichtbar geworden an einem Screenshot von rapahl.)
Hat ein Sonstiges-Gerät einen kWh-Zähler, rechnet eedc damit — statt aus der Leistung zu schätzen. Bisher fiel ein solches Gerät als einziges durch die Zähler-Erkennung: Seine Stundenwerte entstanden aus dem Mittelwert des Leistungssensors, auch wenn ein Energiezähler zugeordnet war. Bei Geräten, die in kurzen Stößen laufen — ein Heizstab schaltet mit 6 kW ein und wieder aus —, ist so ein Mittelwert grob: gemeldet wurden 5,59 kWh für einen Tag, an dem der Energiezähler 3,0 kWh zeigte. Wärmepumpe, Wallbox und PV nutzen den Zähler längst; Sonstiges zieht jetzt nach. ⚠ Die Kurvenform bleibt aus dem Leistungssensor — nur die Energiemenge kommt aus dem Zähler, wie bei den anderen Geräten auch. ⚠ Wer nur einen Leistungssensor zugeordnet hat, sieht keine Änderung; dort gibt es nichts Genaueres. ⚠ Zurückliegende Tage übernehmen den genaueren Wert über Einstellungen → Daten → Tag neu berechnen. (Gemeldet von rapahl — er hat die Ursache selbst richtig vermutet.)
Der erste Stromtarif einer Anlage gilt jetzt ab Monatsanfang — vorher fiel der Inbetriebnahme-Monat durch. Wer seinen ersten Tarif anlegt, bekommt „Gültig ab” vorbelegt: mit dem Inbetriebnahme-Datum der Anlage. Das ist gut gemeint — es verhindert, dass importierte Altmonate hinter den Tarif fallen —, aber bei den wenigsten ist die Inbetriebnahme der Monatserste. Und eedc fragt beim Rechnen mit dem Monatsersten nach dem gültigen Tarif: Ein Tarif ab dem 03.08. deckt den August damit nicht ab, der ganze Monat rechnet mit den Standardwerten (30 ct Netzbezug), obwohl sichtbar ein Tarif gepflegt ist. Wer die Vorbelegung stehen ließ, verlor also reproduzierbar seinen ersten Monat. Die Vorbelegung wird jetzt auf den Monatsersten desselben Monats gezogen — an drei Stellen: im Setup-Assistenten, bei dessen „Standardwerte verwenden” und im Formular unter Einstellungen → Strompreise. ⚠ Die Stichtagsregel selbst bleibt unverändert: Ein Monat hat genau einen Preis, ein Tarif ab Monatsmitte wirkt weiterhin erst im Folgemonat. Geändert wird nur der Vorschlag, nicht die Rechnung. ⚠ Ab dem zweiten Tarif ändert sich nichts — dort ist „heute” die richtige Annahme (Tarifwechsel), und ihn auf den Monatsanfang zu ziehen würde den Wechsel rückdatieren. ⚠ Bestehende Tarife werden nicht angefasst. Wer den Effekt bei sich vermutet, sieht ihn im Daten-Checker: Er meldet seit v4.0.16 als Fehler, wenn Monate mit Daten vor dem ersten Tarif liegen — das Datum lässt sich dort von Hand korrigieren. (Gefunden von Knallfrosch, Forum simon42, der die Differenz nachgerechnet hat: 14,27 € erwartet gegen 16,05 € angezeigt.)
Ein Gerät unter Sonstiges ohne gepflegte Kategorie bekommt jetzt die Felder beider Richtungen angeboten — vorher nur die der Erzeugung. Ein Sonstiges-Gerät ist entweder Erzeuger, Verbraucher oder Speicher; welches, sagt das Feld Kategorie. Ist es nicht gepflegt — das passiert bei Geräten aus einem alten Backup oder aus einem Import —, hat eedc bisher Erzeuger angenommen und nur dessen vier Felder angeboten: Erzeugung, Eigenverbrauch, Einspeisung, Einspeise-Erlös. Für einen Verbraucher waren das die vier falschen: Sein Verbrauch, sein PV-Anteil und sein Netzbezug ließen sich in Einstellungen → Datenquellen und im Monatsabschluss gar nicht erst zuordnen oder eintragen — und die Auswerte-Pfade suchen für dasselbe Gerät genau diese drei. eedc bot damit ausschließlich Felder an, die es für dieses Gerät nirgends liest. Ohne gepflegte Kategorie stehen jetzt alle sieben Felder bereit; man trägt ein, was das Gerät hat. ⚠ Wer eine Kategorie gepflegt hat, sieht keine Änderung — dort bleibt es bei genau den Feldern dieser Kategorie. ⚠ Es verschwindet nichts: Auch die Erzeugungs-Felder bleiben sichtbar, bereits gepflegte Werte stehen unverändert da. ⚠ Der saubere Weg bleibt, die Kategorie zu setzen (Einstellungen → Investitionen) — dann wird die Erfassungsmaske wieder kurz.
Das Speicher-Dashboard und die ROI-Liste runden einen unmöglichen Wirkungsgrad nicht mehr still auf 100 %. Zweite Hälfte des Punktes darunter: Während die übrigen Sichten seit diesem Stand „—” schreiben, zeigten diese beiden bei denselben Daten glatt 100,0 % — sie kappten den Quotienten stumm, statt ihn zu verwerfen. Für dieselbe Anlage standen damit zwei verschiedene Wirkungsgrade nebeneinander, und ausgerechnet die plausibel aussehende Zahl war die falsche: An ihr ließ sich nicht erkennen, dass gemessen etwas anderes dasteht. Beide rechnen jetzt nach derselben Regel. ⚠ Für die Wirtschaftlichkeits-Prognose ändert sich nichts an der Systematik: Wo kein Wirkungsgrad ermittelbar ist, rechnet eedc weiter mit dem gepflegten Wert aus den Speicher-Parametern — wie bisher schon bei zu kurzem Zeitraum, und wie bisher als solcher gekennzeichnet. ⚠ Nebeneffekt, gewollt: Die Degradations-Warnung („IST-Wirkungsgrad deutlich unter dem gepflegten”) konnte bei gekappten 100 % nie auslösen. Jetzt greift sie in diesen Fällen gar nicht erst, statt scheinbar Entwarnung zu geben.
Ein Speicher-Wirkungsgrad über 100 % wird nicht mehr angezeigt — an keiner Stelle mehr. Ein Speicher kann nicht mehr abgeben, als er aufgenommen hat. Trotzdem stand in Cockpit → Jahr, in Auswertungen → Komponenten, in Auswertungen → Tabelle, im Speicher-Dashboard (Kachel und Verlaufskurve), im BKW-Dashboard und im HA-Sensor speicher_effizienz_prozent gelegentlich ein Wert wie 104 %. Die Regel dagegen gab es längst — sie deckte seit v4.0.16 aber nur Cockpit → Tag und Cockpit → Monat; die übrigen acht Stellen bildeten den Quotienten jeweils selbst, ohne Obergrenze. Am deutlichsten war es in Cockpit → Jahr: Dort stand unter der unmöglichen Zahl zusätzlich der bestätigende Satz „über das ganze Fenster gerechnet”. Alle Sichten rechnen jetzt nach derselben Regel und schreiben statt einer unmöglichen Zahl „—” mit dem Grund daneben. ⚠ Ein Wert über 100 % ist keine Aussage über den Speicher, sondern über die erfassten Mengen — die häufigste Ursache ist eine „Ladung”, die nur die PV-Ladung enthält, während die Netzladung als zweiter Posten daneben steht. Der Daten-Checker meldet genau das, mit Hinweis auf das betroffene Feld. ⚠ Wer plausible Werte hat, sieht keine Änderung; unterhalb von 100 % steht dieselbe Zahl wie bisher. ⚠ Folge für Home Assistant: Der Sensor Speicher-Effizienz liefert in diesem Fall keinen Wert mehr (unknown) statt einer falschen Zahl. In der Langzeitstatistik entsteht dadurch eine Lücke — genau an den Tagen, an denen dort bisher ein unmöglicher Wert stand.
Im Komponenten-Hub zeigt ein Sonstiges-Gerät ohne gepflegte Kategorie seine echten Zahlen statt lauter Nullen. Dieselbe Ursache an einer zweiten Stelle: Das Gerät galt dort ungefragt als Erzeuger, also summierte eedc über Erzeugung, Eigenverbrauch und Einspeisung — bei einem Verbraucher stand daneben überall 0, obwohl gepflegte Verbrauchswerte in der Datenbank lagen. Liegt keine Kategorie vor, entscheidet jetzt der Bestand: Wo Erzeugung erfasst ist, wird als Erzeuger ausgewertet, sonst als Verbraucher. ⚠ Gepflegte Geräte sind unberührt — auch solche mit der Kategorie Speicher.

Changed

Intern: die Demo-Daten enthalten jetzt auch einen Verbraucher unter Sonstiges. Bisher stand dort nur ein Erzeuger (das Mini-BHKW). Das war eine Prüf-Blindstelle: Ein Sonstiges-Erzeuger heißt intern auf beiden Seiten gleich und war von dem Feldnamen-Fehler aus v4.0.17 nie betroffen — ein Sonstiges-Verbraucher schon. Neu ist ein „Heizstab Warmwasser” mit saisonalen Monatswerten. Für Anwender ändert sich nichts außer einem zusätzlichen Gerät im Demo-Bestand.

[4.0.17] - 2026-08-16 — Nicht bewertet heißt keine Zahl

Fixed

Eine Zeile mit dem Hinweis „nicht bewertet” zeigt in der Spalte Jahres-Einsparung keine Zahl mehr — und die Anlagen-Summe trägt sie auch nicht. In Auswertungen → ROI stand bei einer Wärmepumpe, für die eedc bewusst keine Ersparnis bewertet, trotzdem ein Betrag: −200,00 €. Das ist die Höhe der bei diesem Gerät gepflegten Betriebskosten — und sie wurden von einer Ersparnis abgezogen, die es gar nicht gibt. Die Gesamt-Einsparung der Anlage fiel dadurch um 1.555 € statt um die 1.355 €, die mit der Bewertung entfallen sind. ⚠ Es war nie ein Rechenfehler: Die Betriebskosten fallen real an, und sie zählen weiterhin überall dort, wo sie hingehören — in der Amortisationsdauer und in deren Annahme-Satz („inkl. 200,00 €/Jahr Betriebskosten”). Falsch war die Aussage: Eine Zahl in der Spalte Jahres-Einsparung behauptet „so viel spart dieses Gerät”, und genau das ist bei einer unbewerteten Zeile unbekannt. Dort steht jetzt „—”, wie in allen anderen Spalten dieser Zeile auch. ⚠ Das gilt nicht nur für Wärmepumpen: Ein Speicher ohne gepflegte Kapazität trägt denselben Hinweis und hatte denselben Fehler. ⚠ Wer gepflegte Daten hat, sieht keine Änderung — an der Demo-Anlage vor und nach dem Update auf den Cent gleich (1.355,00 € je Gerät, 5.911,92 € Anlagen-Summe).
In Auswertungen → Prognose stehen die Quellen-Spalten aller Tabellen jetzt untereinander. OpenMeteo, eedc, Solcast und IST kommen auf dieser Seite in vier Tabellen vor — Quellen-Genauigkeit, Stundenvergleich, 7-Tage-Vergleich und Genauigkeits-Tracking. Jede legte ihre Spalten bisher selbst fest, und keine zwei begannen an derselben Stelle: Wer die Seite von oben nach unten las, musste für dieselbe Quelle jedes Mal den Blick versetzen. ⚠ Mit v4.0.16 waren nur zwei der vier zur Deckung gebracht (Stundenvergleich und 7-Tage-Vergleich, 110 Pixel Versatz) — der Meldung ging es aber um das Gesamtbild. Jetzt kommt der Spaltenplan aus einer Stelle: Wer eine Spalte ändert, ändert sie für alle, und eine neue Tabelle erbt ihn. ⚠ Zwei sichtbare Folgen: Tabellen ohne eigene Abweichungs-Spalte tragen an deren Stelle eine leere Spalte, damit die Quellen fluchten; und das Genauigkeits-Tracking zeigt die Solcast-Spalten nur noch, wenn Solcast eingerichtet ist — vorher standen dort drei Striche. ⚠ Es ändert sich keine Zahl. (Gemeldet von rapahl, PN 16.08.2026.)
Ein Gerät unter Sonstiges mit der Kategorie Verbraucher hat wieder Stunden- und Tageswerte. Wer einem Heizstab, einer Poolpumpe oder einer Klimasteckdose einen eigenen kWh-Zähler zugeordnet hatte, sah dessen Verbrauch im Monat, aber auf Tagesebene nirgends: keine Spalte in Auswertungen → Tabelle, kein Anteil im Stundenverlauf, kein Gerätebeitrag im Tagesdetail. Ursache war ein Feldname, der an zwei Stellen verschieden hieß: Die Zuordnungsfläche schreibt das Feld als verbrauch_sonstig_kwh und eedc veröffentlicht unter diesem Namen auch sein MQTT-Topic — der Auswerte-Pfad suchte dagegen nach verbrauch_kwh, einem Namen, den es für diesen Gerätetyp gar nicht gibt. eedc hat damit ein Topic selbst publiziert und beim Einlesen wieder verworfen. ⚠ Ein Sonstiges-Erzeuger war nie betroffen (ein Mini-BHKW etwa) — dort heißen beide Seiten gleich; genau deshalb fiel es so lange nicht auf. ⚠ Keine Zahl war falsch: Der Tagesverbrauch wird aus Erzeugung, Netzbezug, Einspeisung und Speicher gebildet, nicht aus der Summe der Geräte — es fehlte die Aufschlüsselung, nicht die Menge. Autarkie, Kosten und CO₂ waren unberührt, und der Monat stimmte durchgehend. ⚠ Zur Vergangenheit: Wer den Zähler als Home-Assistant-Sensor führt, holt die zurückliegenden Tage über Einstellungen → Daten → Tag neu berechnen nach — dort wird die HA-Langzeitstatistik neu gelesen. Wer die Werte per MQTT liefert, bekommt Tageswerte ab jetzt: Die Messwerte von damals sind nie gespeichert worden. (Gemeldet von rapahl, PN 16.08.2026.)
Ein gepflegter Wartungsposten macht aus einer unbewerteten Zeile keine bewertete mehr. Sobald an einem Gerät sonstige Erträge oder Ausgaben erfasst waren — eine Wartungsrechnung, eine Förderung —, verschwand der Zusatz „· nicht bewertet” an der Zeile, und der Betrag aus dem Punkt darüber wurde sichtbar angezeigt statt unterdrückt. Der Gedanke dahinter war: „Hat jemand selbst einen Betrag gepflegt, zeigen wir seine Zahl statt eines Strichs.” ⚠ Die Annahme traf nicht zu, und das ist nachgemessen: Die Einsparungs-Spalte trägt diesen Betrag nie. Eine gepflegte Förderung von 180 € ließ die Zeile „0,00 €” zeigen — also die Behauptung „spart nichts”, während in Wahrheit nichts bewertet war; ein Wartungsposten ließ sie „−200,00 €” zeigen. Der gepflegte Betrag wirkt weiterhin unverändert dort, wo er hingehört: im Kapitaleinsatz dieser Zeile (im Beispiel 8.000 € → 7.820 €) und in der Detail-Aufschlüsselung. ⚠ Betroffen war praktisch jede gepflegte Anlage, denn eine Wartungsrechnung an der Wärmepumpe hat fast jeder. ⚠ An bewerteten Zeilen ändert sich nichts — sie waren von diesem Hinweis nie betroffen, mit oder ohne gepflegte Position.

[4.0.16] - 2026-08-16 — Gepflegt statt geraten

Added

„Sonstiges” ist jetzt als Spalte in der Tages- und der Monatstabelle wählbar. Wer ein Gerät unter Sonstiges führt — ein Mini-BHKW, einen Heizstab, eine Poolpumpe —, konnte in Auswertungen → Tabelle bisher nicht nachsehen, ob dessen Werte überhaupt ankommen: Der Spalten-Picker kannte die Gruppe nicht, weder für Monate noch für Tage. Neu ist die Gruppe „Sonstiges” mit zwei Spalten, Sonstiges Erzeugung (kWh) und Sonstiges Verbrauch (kWh); die Richtung ergibt sich aus der bei jedem Gerät gepflegten Kategorie (Erzeuger / Verbraucher). Beide sind nicht voreingestellt — wählbar, nicht vorgegeben, damit sich keine vertraute Tabelle ungefragt ändert. ⚠ Die Verbrauchsspalte addiert nichts: Der Verbrauch steckt bereits im Gesamtverbrauch, die Spalte schlüsselt ihn nur auf. ⚠ Monat und Tag speisen sich aus verschiedenen Quellen, und das ist beim Lesen wichtig: Die Monatsspalte zeigt, was beim Gerät erfasst ist (Monatsabschluss, Import oder Sensor); die Tagesspalte kann nur zeigen, was ein eigener Sensor bzw. Zähler gemessen hat. Ein nur monatlich gepflegtes Gerät hat deshalb einen Monats- und keinen Tageswert — die Tagesspalte steht dann auf „—”, und die Summe der Tageszeilen ergibt nicht den Monatswert. Genau diese Unterscheidung war der Anlass der Meldung. ⚠ Ein Gerät mit der Kategorie Speicher bleibt in der Tagesansicht außen vor: dort gibt es je Gerät nur eine Zahl, und die ist bei einem Speicher ein Saldo aus Laden und Entladen — sie ließe sich weder der Erzeugung noch dem Verbrauch zuschlagen. ⚠ Bewusst kWh im Spaltennamen: Gas-, Öl- und Wasserzähler (#377) bringen eine Menge in m³ oder Litern ohne kWh-Bezug — eine Litermenge unter der Beschriftung „kWh” wäre schlicht falsch. Käme so etwas einmal, dann in eigenen Spalten mit eigener Einheit und nicht durch Überschreiben dieser beiden; ob und wann, ist offen. (Gemeldet von rapahl, 14.08.2026.)
Der Fortschritt gegen die volle Monatsprognose ist wieder da — als zweite Angabe neben der bestehenden. In Cockpit → Monat steht in der Energie-Bilanz jetzt die Kachel „Monatsprognose (PVGIS)”: wie viel der für den ganzen Monat prognostizierten Erzeugung bisher erreicht ist, mit Balken und der Zeile „264 von 1.388 kWh · ganzer Monat (Tag 4 von 31)”. Sie ist einzeln parkbar und erscheint nur im laufenden Monat — ist er vorbei, ist sie dieselbe Zahl wie die Kachel daneben. ⚠ Sie ersetzt nichts: „IST/SOLL (PVGIS)” beantwortet weiterhin liefert die Anlage, was sie bis heute liefern sollte? und rechnet gegen die abgelaufenen Tage. Beide Zahlen sind richtig und beantworten verschiedene Fragen; jede nennt ihr Fenster im Untertitel. ⚠ Sie erscheint auch dort, wo die Kachel daneben die Grundlast zeigt — sonst hätte eine Anlage mit Stundenprofilen gar keine Einordnung des laufenden Monats mehr. Hintergrund: Mit v4.0.10 wurde der SOLL-Nenner im laufenden Monat auf die abgelaufenen Tage gekürzt (die Erfüllungsquote maß vorher das Datum statt die Anlage). Richtig war das — nur ist dabei der Bezug auf die ganze Monatsprognose aus der Anzeige verschwunden, und der war einem Anwender wichtig. (Gemeldet von dietmar1968, Forum T89667 #155.)
Die beiden Sonstiges-Spalten gibt es auch in der Monatsdaten-Liste (Einstellungen → Daten). Sie hat einen eigenen Spalten-Wähler mit eigener Spaltenliste — die Gerätegruppe Sonstiges fehlte dort genauso wie in der Werte-Tabelle, und es ist der Ort, an dem man nachsieht, ob ein erfasster Wert angekommen ist. Auch hier: beide Spalten unter „Komponenten”, nicht voreingestellt, „—” wo es kein solches Gerät gibt. (Gemeldet von Gernot beim Gegenlesen, 15.08.2026.)
Der Daten-Checker sagt jetzt, wenn ein Gerät älter ist als deine Anlage — und dass das in Ordnung ist. Ein E-Auto von 2017 an einer PV-Anlage von 2022 ist der Regelfall, und das Anschaffungsdatum gehört dann auch auf 2017. Bisher stand dazu nirgends etwas; wer sich wunderte, warum die Wirtschaftlichkeit dieses Geräts anders aussieht als erwartet, fand keine Erklärung. Neu ist ein Hinweis (kein Fehler, keine Warnung) unter Stammdaten: „Gerät älter als die Anlage: „Passat GTE” seit 12.03.2017”. Er nennt das älteste Gerät, die Anzahl der betroffenen und den Grund — für die Monate vor der Anlage gibt es keine Einspeisungs- und Netzbezugswerte und damit keine Bilanz; eedc kann dort nicht sagen, ob der Strom gekauft oder selbst erzeugt war. ⚠ Die Richtung des Textes ist Absicht: Er rät dazu, Zählerwerte nachzupflegen oder das Datum der Anlage zu korrigieren — und ausdrücklich davon ab, das Gerät umzudatieren. Genau das hat ein Anwender getan, um eine ältere Meldung loszuwerden, und dabei die echte Anschaffungshistorie seines Fahrzeugs verloren. ⚠ Erzeuger bekommen diesen Hinweis nicht — bei ihnen stimmt wirklich eines der beiden Daten nicht, dafür gibt es weiterhin die eigene Warnung. ⚠ Ohne gepflegtes Inbetriebnahme-Datum der Anlage schweigt der Hinweis, statt sich einen Vergleichspunkt auszudenken.

Changed

Eine Wärmepumpe, die nie eine Heizung ersetzt hat, bekommt keine Gaskessel-Ersparnis mehr angerechnet — und eine Klimaanlage, die heizt, bekommt endlich ihre. Beim ersetzten Energieträger gibt es jetzt die Option „Nichts ersetzt (Neubau)”. Bisher kannte das Feld nur Erdgas, Heizöl und Strom, mit Erdgas als Vorgabe — es war schlicht nicht ausdrückbar, dass es gar keine Vorgängerheizung gab. Dadurch rechnete eedc auch einer Wärmepumpe im Neubau eine Ersparnis gegenüber einer Gasheizung an, die es dort nie gegeben hat: in der ROI-Tabelle, in den Aussichten, im WP-Dashboard, im Jahresbericht und im HA-Sensor wp_ersparnis_euro. Wer „Nichts ersetzt” wählt, sieht dort jetzt „nicht bewertet” statt einer Zahl; Stromverbrauch, PV-Anteil, Kosten und CO₂ des Geräts selbst bleiben unverändert. ⚠ Der Umweg über den Gerätetyp entfällt damit, und das ist eine Korrektur: Für Split-Klimaanlagen (Luft-Luft) hat eedc die Wirtschaftlichkeit bisher grundsätzlich unterdrückt, mit der Begründung, ein solches Gerät ersetze keine Heizung. Das stimmt nicht — eine Luft-Luft-Wärmepumpe kann sehr wohl eine Gasheizung ersetzen, und viele heizen damit. Wer das tut und seinen Heizwärmebedarf pflegt, bekommt seine Wirtschaftlichkeit jetzt wie bei jeder anderen Wärmepumpe; die beiden Bedarfsfelder werden dafür wieder angezeigt (ohne Vorbelegung). ⚠ Für bestehende Klimaanlagen ändert sich zunächst nichts: Wo noch die alte Vorbelegung von 12.000 kWh Heizwärme und 3.000 kWh Warmwasser steht — Werte, die eedc selbst eingesetzt hat und die seit v4.0.6 unsichtbar waren —, bleibt die Zeile „nicht bewertet” und sagt genau das. Erst ein eingetragener eigener Wert schaltet die Bewertung frei. Es wird nichts automatisch umgeschrieben.
Ohne gepflegten Wärmebedarf erfindet eedc keinen mehr. Fehlte bei einer Wärmepumpe der Heizwärme- und Warmwasserbedarf, sprang in der ROI-Auswertung ein Standardwert von 12.000 + 3.000 kWh ein und erzeugte daraus eine Ersparnis — eine Zahl, die niemand eingegeben hatte. Betroffen waren vor allem Geräte, die nie über das Investitionsformular gespeichert wurden (Import, Setup-Assistent). Ihre ROI-Zeile steht jetzt auf „nicht bewertet” mit der Bitte, den Bedarf einzutragen. ⚠ Das ist eine sichtbare Änderung nach unten — die alte Zahl war aber keine Schätzung von dir, sondern eine Behauptung von eedc. ⚠ Wer den Bedarf gepflegt hat, sieht keinen Unterschied. Auch die halbe Pflege wird jetzt ehrlich gerechnet: Wer nur den Warmwasserbedarf einträgt, bekommt für die Heizwärme 0 statt der erfundenen 12.000 kWh.
Eine Split-Klimaanlage verlangt in Einstellungen → Datenquellen keinen Wärmemengenzähler mehr. Wer sein Gerät als Wärmepumpenart Luft-Luft (Klimaanlage) führt, sah dort das Feld Heizwärme rot markiert, mit aufgeklapptem Hinweis und als offenen Punkt mitgezählt — obwohl eine Split-Klimaanlage üblicherweise gar keinen Wärmemengenzähler hat und eedc das an anderer Stelle längst weiß: Der Daten-Checker verlangt diesen Wert bei einer Klimaanlage seit v3.30.3 ausdrücklich nicht. Zwei Flächen sagten damit über dasselbe Gerät das Gegenteil, und die eine forderte etwas ein, das sich nicht auflösen ließ. Das Feld ist bei dieser Wärmepumpenart jetzt optional: leise, grau, zählt nicht als Lücke. Dieselbe Einstufung gilt für die MQTT-Themenliste, die sich aus derselben Quelle speist. ⚠ Der Stromverbrauch bleibt Pflicht — bei einer Klimaanlage ist er die Messgröße, um die es geht. ⚠ Wer doch einen Wärmemengenzähler an seiner Klimaanlage hat, ordnet ihn weiterhin zu — das Feld verschwindet nicht, es fordert nur nichts mehr ein. ⚠ Für klassische Wärmepumpen (Luft-Wasser, Sole-Wasser) ändert sich nichts, dort bleibt die Heizwärme Pflicht; ebenso bei Altgeräten ohne gepflegte Wärmepumpenart, denn eine fehlende Angabe darf diese Erwartung nicht stillschweigend abschalten. (Gemeldet von dietmar1968, Forum T89667 #87, und kingcap1, Issue #263.)
Fehlende Zählerwerte sind jetzt ein Fehler, keine Warnung — und das Inbetriebnahme-Datum der Anlage ebenso. Einspeisung und Netzbezug sind die Basis, auf der eedc überhaupt eine Bilanz bildet. Fehlen sie für einen Monat, weiß eedc nicht, woher der Strom eines Geräts kam — und rechnet trotzdem weiter: Der Direktverbrauch entsteht als Erzeugung minus Einspeisung minus Speicherladung, und eine fehlende Einspeisung liest diese Rechnung als 0. Dann gilt die ganze Erzeugung als Eigenverbrauch und wird mit dem Netzpreis statt der Einspeisevergütung bewertet. An einem echten Monat nachgerechnet: 622 € statt 282 €, bei einem Hausverbrauch von 1.838 statt 520 kWh. Die alte Zahl war also nicht ungenau, sondern systematisch zu gut — deshalb steht ein fehlender Monat ab sofort als Fehler in der Liste, nicht als Warnung. Dasselbe gilt für ein fehlendes Inbetriebnahme-Datum der Anlage: Ohne es weiß eedc nicht, ab wann es Zählerwerte erwarten darf, weicht auf die Erzeuger aus und zuletzt auf die erste vorhandene Datenzeile — dann wird der Anfang aus der Lücke abgeleitet, und eine fehlende Zeile am Beginn der Historie fällt niemandem mehr auf. ⚠ Keine gerechnete Zahl ändert sich. Es ist derselbe Befund an derselben Stelle mit demselben „Beheben”-Link — nur die Einstufung ist eine andere, und die Statusfußzeile zeigt ihn entsprechend rot statt amber. ⚠ Wer vollständige Daten hat, sieht keinen Unterschied.
Im Setup-Assistenten gibt es fürs Balkonkraftwerk jetzt alle neun Ausrichtungen. Wer sein BKW beim Einrichten anlegte, bekam nur sechs zur Auswahl — Nordost, Nord und Nordwest fehlten. Wer dasselbe Gerät danach unter Einstellungen → Investitionen bearbeitete, bekam alle neun. Die Auswahl hing also davon ab, über welchen Weg man das Gerät angelegt hat; für ein Fassaden-BKW nach Nordosten war der eine Weg schlicht versperrt. Es gibt jetzt eine Liste für Setup und Formular, für PV-Module wie fürs Balkonkraftwerk. ⚠ Bereits gepflegte Ausrichtungen bleiben unverändert — es kommen nur Auswahlmöglichkeiten dazu.
„Einspeisung und Netzbezug sind beide 0” sagt jetzt, was gilt, wenn man nichts tut. Der Befund trug als vollständige Begründung den Satz „Wahrscheinlich fehlende Daten”. Für eine Anlage ohne Netzanschluss (Inselbetrieb) oder einen Monat außer Betrieb (Umzug, Defekt) ist die 0 aber richtig — und der Hinweis war für sie durch keine Eingabe abstellbar. Genau das soll es in eedc nicht geben: Ein Befund, den du nicht auflösen kannst, ist ein Fehler bei uns und keine Aufgabe für dich. Der Text nennt jetzt zuerst den Regelfall (nachtragen, der Link führt direkt in den Monat) und sagt danach, dass 0 richtig sein kann und dann nichts zu tun ist — dasselbe Muster wie beim Wärmepumpen-Spezialtarif und bei „Tarif ohne Einspeisevergütung”. ⚠ Bewusst kein Stammdaten-Schalter „Inselanlage”: Er wäre die richtige Bauform, zöge aber die Finanzseite nach sich — eedc bewertet Eigenverbrauch als eingesparten Netzbezug, und eine Insel-Anlage spart nichts ein — und es ist kein einziger Anwender mit einer solchen Anlage bekannt. Ein Satz löst hier, was eine Stammdaten-Angabe erst ab dem zweiten Abnehmer verdient.
Das Inbetriebnahme-Datum ist beim Anlegen einer neuen Anlage jetzt Pflicht — beim Bearbeiten bewusst nicht. Im Setup-Assistenten lässt sich der Schritt ohne dieses Datum nicht mehr abschließen; der Hinweis dabei sagt, warum: ab diesem Monat erwartet eedc Zählerwerte. Im Anlagen-Formular (Einstellungen → Stammdaten) bleibt es freiwillig und zeigt bei leerem Feld nur eine Warnung — wer eine bestehende Anlage bearbeitet, will meist etwas ganz anderes ändern und soll daran nicht hängenbleiben. ⚠ Die Hinweistexte an beiden Feldern sind neu geschrieben: Sie beschrieben das Datum bisher als nachrichtlich („für Stromtarif-Gültigkeit und Community-Vergleichszeitraum”) und sagen jetzt zuerst, was es steuert. ⚠ Für den Bestand ändert sich nichts erzwungen — dort meldet es der Daten-Checker, siehe oben.
Und wo eedc es nicht wissen kann, sagt es das jetzt. Dieselbe Aussage — „ein größerer Speicher hätte nichts gebracht” — stand auch dann da, wenn der Speicher dem Boden nie nahe kam und die nutzbare Kapazität nicht gepflegt ist. Dann gibt es aber zwei mögliche Erklärungen mit entgegengesetzten Folgen: Entweder ist der Speicher groß genug (dann stimmt der Satz), oder es läuft eine Entlade-Untergrenze, die niemand eingetragen hat (dann ist er falsch). eedc kann die beiden ohne diese Angabe nicht unterscheiden — und behauptet deshalb keine von beiden mehr. Stattdessen steht dort, was Sache ist: „Das lässt sich hier nicht beurteilen”, mit dem tiefsten gemessenen Ladestand als Beleg und dem Hinweis, welches Feld die Frage klärt. Die Kachel Nutzbares Zusatzpotential zeigt dann „—” statt 0 kWh — eine 0 wäre auch dort eine Aussage, die niemand gemessen hat. ⚠ Wo die Aussage belegt ist, bleibt sie unverändert klar: Ist die nutzbare Kapazität gepflegt und der Speicher blieb trotzdem über seiner Grenze, war er wirklich groß genug. Und wer seinen Speicher real leerfährt — im Winter etwa auf 3 % —, bekommt weiterhin die eindeutige Antwort. Die gemessenen Mengen daneben (Überschuss bei vollem Speicher, Ladestandsverlauf) ändern sich in keinem Fall.
„Ein größerer Speicher hätte nichts gebracht” — diese Aussage war für alle falsch, die ihren Speicher nicht ganz leerfahren. Im Speicher-Hub beantwortet der Block Hätte mehr Kapazität geholfen? die Frage bewusst streng: Zusätzliche Kapazität nützt nur, wenn der Speicher nachts auch wirklich leer wird — sonst hätte die zusätzlich gespeicherte Energie niemand abgenommen. „Leer” war dabei fest auf 5 % Ladestand verdrahtet. Wer eine eigene Entlade-Untergrenze fährt — 10 %, 20 %, was die Zellchemie schonen soll —, dessen Speicher erreicht diese 5 % nie. Damit lief er rechnerisch in keiner Nacht leer, und das Nutzbare Zusatzpotential konnte gar nichts anderes als 0 kWh ergeben. Darüber stand dann der Satz „Ein größerer Speicher hätte hier nichts gebracht” — als Tatsache formuliert, obwohl eedc es nicht gemessen hatte. Im gemeldeten Fall: 4.974 kWh Überschuss bei vollem Speicher, 0 von 207 Nächten leer, während die Ladestandskurve nachts auf 21 % läuft und dort dreht. Der Speicher war aufgebraucht. Jetzt leitet eedc die Grenze aus der nutzbaren Kapazität ab, die beim Speicher gepflegt ist: 24 von 30 kWh nutzbar heißt 20 % Reserve, und ab dort gilt er als leer. Die Kachel nennt die Zahl und ihre Herkunft („deine Entladegrenze”). ⚠ Wer die nutzbare Kapazität nicht gepflegt hat, sieht keine einzige geänderte Zahl — dann bleibt es bei den 5 %. Wer sie pflegt, bekommt hier erstmals eine belastbare Antwort. ⚠ Ein kleiner Aufschlag gehört dazu: Ein Speicher hält seine Untergrenze mit Puffer ein, der Ladestand wird in ganzen Prozent gemeldet, und diese Auswertung rechnet mit Stundenmitteln — deshalb zählt eedc drei Prozentpunkte über der eingestellten Grenze bereits als leer. Ohne das hätte die neue Grenze denselben Fehler gemacht wie die alte, nur mit einer anderen Zahl. ⚠ Dieselbe Grenze gilt jetzt auch im Block „Größerer Speicher?” daneben — dort zählte „Tage leergelaufen” bisher nach der alten festen Regel. (Gemeldet von kingcap1, Issue #379.)
Der Block „Hätte mehr Kapazität geholfen?” lässt sich jetzt stückweise parken. Bisher lag über dem ganzen Block eine Park-Umhüllung: Befundsatz, die drei Kacheln, die Monats-Grafik und der Mehrgeräte-Hinweis ließen sich nur gemeinsam wegräumen, und beim Rechtsklick auf eine einzelne Kachel verdunkelte sich der komplette Block statt der angefassten Anzeige. Jede der sechs Anzeigen ist jetzt einzeln parkbar, wie überall sonst; der Block verschwindet erst, wenn die letzte geparkt ist. ⚠ Eine bereits gemerkte Parkung dieses Blocks geht dabei verloren — die alte Sammel-Kennung existiert nicht mehr; der Block ist dann wieder sichtbar und lässt sich neu parken. ⚠ An Zahlen und Grafik ändert sich nichts. (Der zuständige Prüfer konnte das nicht sehen: Er schlägt bei neu umhüllten benannten Komponenten an, hier stand ein generischer Container dahinter — eine im Prüfer selbst dokumentierte Grenze. Gemeldet von Gernot am Bild, 15.08.2026.)
Auch der Block „Kategorien” in Cockpit → Monat ist jetzt stückweise parkbar. Über den beiden Balken (Erzeugung nach Kategorie · Verbrauch nach Kategorie) lag ebenfalls eine gemeinsame Park-Umhüllung — wer nur den Verbrauchs-Balken wegräumen wollte, verlor den Erzeugungs-Balken mit. Anders als beim Speicher-Regler hängt hier nichts voneinander ab; jeder Balken ist für sich lesbar. ⚠ Auch hier geht eine bereits gemerkte Parkung dieses Blocks verloren. ⚠ Gefunden durch eine Erhebung über alle 226 Park-Umhüllungen des Baums, ausgelöst von Gernots Frage nach weiteren Stellen derselben Art. Übrig bleibt genau eine Bündel-Umhüllung, und die ist bewusst so: Beim Sizing-Regler („Größerer Speicher?”) gehören Regler, Ergebnis und Methoden-Hinweis zusammen — ein Bedienelement ohne seine Anzeige wäre sinnlos.
Ein Gerät unter Sonstiges ohne gepflegte Kategorie war in Cockpit → Monat unsichtbar — und zählte trotzdem mit. Der Block „Sonstige Geräte” ordnete ein Gerät ohne die Angabe Erzeuger/Verbraucher stillschweigend den Erzeugern zu und zeigte dort nur, was auch erzeugt hat. Ein Verbrauchsgerät fiel dadurch durch beide Maschen: In der Liste tauchte es nicht auf, in den Summen darüber lief sein Verbrauch mit. Die Richtung kommt jetzt aus dem Wert, wenn keine Kategorie gepflegt ist — eine gepflegte Kategorie schlägt sie weiterhin. ⚠ Für gepflegte Geräte ändert sich nichts, und keine Zahl bewegt sich; das Gerät wird nur dort sichtbar, wo es hingehört. Der Erzeuger-Default war zugleich die einzige Stelle ihrer Art: Die beiden Tages-Schreibpfade und die Tages-Auswertung lesen eine leere Kategorie seit jeher als Verbraucher.
Monate, für die kein Strompreis hinterlegt ist, meldet der Daten-Checker jetzt als Fehler statt als Warnung. eedc rechnet für solche Zeiträume mit einer Vorbelegung (30 ct/kWh Netzbezug, 8,2 ct/kWh Einspeisung) — das muss es, sonst gäbe es gar keine Finanzzahl. Das Ergebnis ist dann aber ein geratener Preis auf gemessenen Mengen: Netto-Ertrag, ROI und Jahresbericht dieser Monate tragen eine Zahl, die nicht aus deinen Daten stammt. Der Hinweis nennt unverändert den einen Schritt, der ihn auflöst — beim ältesten Tarif das „Gültig ab” auf den Beginn deiner Daten zurückziehen. (Der typische Weg dorthin: erst Monate aus der HA-Statistik importieren, danach den Tarif anlegen — dessen Formular schlägt „heute” vor.)
Ein Speicher-Wirkungsgrad über 100 % steht nicht mehr kommentarlos in der Tagesansicht. In Cockpit → Tag zeigte die Kachel „Wirkungsgrad” den rohen Quotienten Entladung ÷ Ladung — und der kann an einem einzelnen Tag über 100 % liegen, ohne dass etwas kaputt wäre: Wer morgens mit vollem Speicher beginnt und abends leer endet, entnimmt mehr, als er an diesem Tag geladen hat. Über einen Monat mittelt sich das aus, über einen Tag nicht. Cockpit → Monat rechnet den Ladestand am Rand deshalb schon länger heraus und sagt dazu, worauf der Wert beruht; die Tagesansicht tat beides nicht. Jetzt gilt derselbe Maßstab: Ist der Ladestand des Tages gemessen, wird der Übertrag herausgerechnet („Ladestand am Rand herausgerechnet”); ist er es nicht und der rohe Wert bleibt unter 100 %, steht er weiterhin da — aber als „ohne Ladestand gerechnet — ungenau”; und liegt er ohne Ladestand über 100 %, steht statt einer unmöglichen Zahl ein „—” mit Begründung. ⚠ An Lade- und Entlademenge ändert sich nichts, nur an der einen Prozentzahl daneben. (Gemeldet von Knallfrosch, Forum T89667 #163, 15.08.2026 — mit der richtigen Erklärung von rapahl im selben Faden.)
Zwei Geldbeträge auf der Tagesseite widersprachen einander um einen Cent. Die Kachel „Netto-Ertrag” zeigte 16,05 €, die Finanz-Bilanz-Tabelle darunter summierte dieselben zwei Posten zu 16,04 € — beide Wege waren für sich richtig, nur wurde einmal die Summe gerundet und einmal die Summanden. Dieselbe Ursache traf die Kachel „Ø-Preis Netz”: Sie teilte zwei bereits gerundete Zahlen und kam an einem Tag mit 0,19 kWh Netzbezug auf 31,6 ct/kWh, während dieselbe Seite mit rund 29,5 ct rechnete. Die Tageswerte werden jetzt ungerundet weitergereicht und erst bei der Anzeige gerundet — wie es die Monatsansicht schon immer tat —, und der Ø-Preis nennt den hinterlegten Tarif des Tages statt ihn aus zwei Anzeigewerten zu rekonstruieren. ⚠ Auch die Summenzeile der Werte-Tabelle rechnet dadurch exakt, statt gerundete Tageswerte zu addieren. (Beim Nachmessen zu #163 gefunden.)
Die beiden Tabellen im Block „Tages-/Stundenprofil” stehen wieder spaltengleich untereinander. In Auswertungen → Prognose folgt der 7-Tage-Vergleich unmittelbar auf den Stundenvergleich heute — beide zeigen dieselben Quellen in derselben Reihenfolge (OpenMeteo · eedc · Solcast · IST, dazu SFML, wenn es die gewählte Quelle ist). Die Spalten der oberen Tabelle begannen dabei rund 110 Pixel weiter links als die der unteren, weil der 7-Tage-Vergleich vor dem Datum noch das Wetter-Symbol führt und der Stundenvergleich diese Spalte nicht hatte. Wer die Tabellen untereinander las, musste den Blick versetzen; die rechte Hälfte deckte sich, die erste Quelle nicht. Der Stundenvergleich führt jetzt dieselbe Spalte mit — sie bleibt leer, hält aber den Aufbau beider Tabellen deckungsgleich. ⚠ Es ändert sich keine Zahl und keine Spalte verschwindet — die Werte stehen nur dort, wo man sie beim Vergleichen sucht. (Gemeldet von rapahl, 14.08.2026.)
Die Δ-Spalte der Werte-Tabellen widerspricht nicht mehr den zwei Spalten daneben. Im Vergleichs-Modus (Auswertungen → Tabelle, ebenso in den eingebetteten Tabellen des Cockpits) stand in einer Tageszeile „Aktuell 0 · Vorperiode 12 · Δ ▼ 11 (−97,6 %)” — 12 − 0 ist nicht 11. Zwei Zeilen tiefer standen zweimal 0 nebeneinander und dazwischen ein „▼ 0 (−73,3 %)”. Beides war rechnerisch erklärbar und trotzdem falsch dargestellt: Die Spalten zeigen gerundet, die Δ-Spalte rechnete mit den ungerundeten Werten dahinter weiter. Sie rechnet jetzt mit denselben Zahlen, die daneben stehen. ⚠ Was unterhalb der Anzeige-Genauigkeit liegt, ist damit kein Unterschied mehr — solche Zeilen zeigen „=” statt einer Prozentzahl ohne sichtbare Grundlage. Wer die Feinheit braucht, schaltet die Spalte auf mehr Nachkommastellen oder nimmt den CSV-Export, der unverändert die Rohwerte trägt. ⚠ Keine gespeicherte Zahl ändert sich, nur die Δ-Anzeige. (Gemeldet von Striker, Forum T89667 #162, 14.08.2026 — an seinen Bildern nachgemessen.)
„0 kWh” behauptet die Tagesansicht nur noch, wo wirklich gemessen wurde. In derselben Tabelle stand für den Januar „PV — · Einspeisung 106 kWh · Netzbezug 0 · Gesamtverbrauch 0”: Die Einspeisung kam aus der Home-Assistant-Historie, für PV und Netzbezug gab es in diesen Monaten gar keinen Zähler — und die 0 war die einzige Zahl der Zeile, hinter der keine Messung stand. Die PV-Spalte sagte das schon länger richtig („—”); die Netz-Seite konnte es bisher gar nicht ausdrücken. Jetzt sagen es alle vier Größen — Einspeisung, Netzbezug, Gesamtverbrauch, Direktverbrauch — und ebenso Überschuss und Defizit. ⚠ Eine gemessene Null bleibt eine Null: Wer einen Tag lang nichts aus dem Netz zieht, sieht weiterhin „0” — maßgeblich ist, ob ein Wert erfasst ist, nicht ob er größer als 0 ist. ⚠ Die Balken der Monatsgrafik zeigen an solchen Tagen eine Lücke statt einer 0-Fläche. ⚠ Und die Geldbeträge folgen der Menge: Wo der Netzbezug nicht erfasst ist, stehen Netzbezug-Kosten, Eigenverbrauchs-Ersparnis, Netto-Ertrag und Netto-Bilanz dieses Tages auf „—” statt auf „0,00 €” — ein Betrag auf einer Menge, die es nicht gibt, ist keine Null. Der Einspeise-Erlös steht auf einer gemessenen Menge und bleibt. (Ebenfalls aus Strikers Bildern, #162 — er hatte danach gefragt, ob diese Werte Einfluss auf die Berechnungen haben. Hatten sie.)
Intern: die Monatsprognose steht als eigenes Feld in der Antwort. Das PVGIS-SOLL wird im laufenden Monat gekürzt geliefert; die ungekürzte Monatssumme ließe sich daraus zurückrechnen, weil die Kürzung linear über die Tage läuft. Sie wird trotzdem mitgeliefert statt zurückgerechnet: Der gekürzte Wert ist auf eine Stelle gerundet, und die Umkehrung vervielfacht diesen Rest mit Tage_gesamt ÷ Tage — am Monatsersten das 28- bis 31-Fache. Ein zusätzlicher Abruf entsteht dadurch nicht.

[4.0.15] - 2026-08-14 — Kein stummes Nichts

Changed

„Hätte mehr Kapazität geholfen?” zeigt jetzt Balken statt Farbnuancen — und zwei Dinge, die vorher unsichtbar waren. Die Monat-×-Ladestand-Heatmap aus v4.0.14 war schwer zu lesen, und der Grund war kein Geschmack, sondern ein Skalierungsfehler: Die Deckkraft aller Zellen wurde gemeinsam über alle Monate normiert. Ein einzelner Extremwert — im November steht der Speicher hunderte Stunden fast leer — setzte damit die Skala für das ganze Bild und drückte alles übrige in einen schmalen Graubereich; Oktober und November sahen gleich aus, Februar und März auch. An seine Stelle tritt ein Balken je Monat, der zeigt, wo der Ladestand in acht von zehn Stunden lag, mit dem typischen Wert als Linie darin und zwei Strichen an den Rändern: wie oft der Speicher voll (≥ 95 %) und wie oft leer (≤ 5 %) war. Erst wenn beide Striche breit sind, ist mehr Kapazität eine ernsthafte Überlegung — genau die Aussage, die der Block trifft, jetzt im Bild statt nur im Text. Jeder Monat trägt seine eigene Skala; ein Extremmonat kann die anderen nicht mehr unkenntlich machen. Neu daneben: der Durchsatz je Monat in Vollzyklen — ohne ihn sieht ein Speicher, der dreimal am Tag durchfährt, aus wie einer, der stillsteht, und ein Durchsatz über 100 % der Kapazität war schlicht nicht darstellbar — sowie der Anteil der Ladung aus dem Netz, der nur erscheint, wenn es sie gab: Netzladung füllt den Speicher ohne Sonne, und solche Monate beantworten die Frage nach mehr Kapazität nur eingeschränkt (der Anteil ist eine Obergrenze, innerhalb einer Stunde trennt kein Zähler Haus und Akku). Die Grafik nutzt jetzt die volle Breite des Blocks. ⚠ Bewusst ohne Ampelfarben, obwohl danach gefragt wurde: Ein voller Speicher ist nicht „gut” und ein leerer nicht „schlecht” — Grün für „immer voll” würde ausgerechnet den Zustand belohnen, in dem Überschuss verschenkt wird. ⚠ Die Zahlen selbst ändern sich nicht; der Durchsatz ist derselbe Vollzyklen-Wert wie im Cockpit, im HA-Sensor und im Jahresbericht. (Gemeldet von rapahl, 13.08.2026.)
Intern: die Reste der alten Oberfläche sind entfernt — inklusive fünf Endpunkten, die noch schreiben konnten. Der IA-V4-Flip hatte 34 Quelldateien zurückgelassen, die sich gegenseitig am Leben hielten: der alte Sensor-Mapping-Wizard, der 7-Schritt-Monatsabschluss und die früheren Community-Reiter. Gemessen wurde nicht „wer importiert mich”, sondern die transitive Erreichbarkeit ab dem Produktions-Einstieg — der Unterschied ist der ganze Befund, denn ein Rückwärts-Grep hätte die Gruppe komplett übersehen (eine Datei hatte acht Importeure, alle acht aus dem toten Cluster selbst). Von 552 Quelldateien sind 378 produktiv erreichbar. ⚠ Für Anwender ändert sich nichts — kein Verhalten, keine Zahl, keine Fläche. ⚠ Eine Ausnahme, falls du eigene Skripte betreibst: Von den sechs Endpunkten unter /api/sensor-mapping sind fünf stillgelegt (Mapping lesen, Sensor-Liste, speichern, löschen, Status); erreichbar bleibt allein /{id}/suggest, den der Setup-Assistent nutzt. Die eigene Oberfläche rief die fünf seit dem Flip nirgends mehr auf. Der Grund für das Stilllegen war nicht der tote Code, sondern was er noch konnte: POST /{id} schrieb weiter auf die Sensor-Zuordnung, ohne den Hinweis auszulösen, dass die gespeicherte Historie dabei bestehen bleibt — wer die Alt-Route noch traf, änderte seine Zuordnung stumm. Mitentfernt wurden zwölf Ausnahme-Einträge in den Prüfskripten, die auf nicht mehr existierende Dateien zeigten; ein solcher Eintrag ist nicht harmlos, er stellt eine künftige gleichnamige Datei stumm frei.
Intern: das gebaute Frontend liegt nicht mehr im Repository. eedc/frontend/dist war versioniert — 4,5 MB in 86 Dateien, die nach jedem Build als geändert dastanden. Die Begründung dafür („schnellere Add-on-Installation”) ist seit dem Multi-Stage-Build überholt: Add-on- und Standalone-Image bauen das Frontend in einer eigenen Stage und kopieren nur deren Ergebnis; ausgeliefert wird ohnehin ein fertiges Image. Das Verzeichnis aus dem Repository hat damit nie ein Anwender gesehen. ⚠ An Installation und Update ändert sich nichts — der Release-Lauf baut das Frontend weiterhin, jetzt als Prüfung „kompiliert es überhaupt?” vor dem Tag. Im Standalone-Spiegel lag zusätzlich ein Build aus v3.8.17 (April), den seit Monaten kein Release mehr angefasst hatte; er wird beim nächsten Release mit ausgetragen.

Fixed

Der Block „Speicher im Jahr” ließ sich nicht ganz wegräumen. Wer in Cockpit → Jahr alle Anzeigen parkt, soll eine leere Seite bekommen — beim Speicher-Block blieb stattdessen die Hülle samt Überschrift stehen, obwohl nichts mehr darin war. Er war als einziger Block der Sicht ohne Park-Prüfung eingehängt. ⚠ Gefunden hat es der eigene Prüfer, der dafür gebaut wurde — er verlangt eine laufende Testinstanz und lief deshalb monatelang nicht mit; jetzt sind alle 18 geprüften Sichten sauber. (Ein Prüfer, den man nicht laufen lässt, ist keiner — dieselbe Klasse wie die beiden CI-Ausfälle zu v4.0.13 und v4.0.14.)
Der Reiter „Komponenten” stand bei einem neuen Gerät auf lauter Nullen und sagte nicht, warum. Wer ein Gerät mit einem Anschaffungsdatum im laufenden Monat einträgt, sieht es in Cockpit → Tag und Cockpit → Monat sofort — im Reiter Komponenten dagegen zeigten Vollzyklen, Wirkungsgrad, Durchsatz und Ersparnis eine glatte 0, ohne ein Wort dazu. Damit ließ sich „es ist noch nichts da” nicht von „ich habe etwas falsch eingerichtet” unterscheiden, und genau so wurde es auch gemeldet. Über den Blöcken steht jetzt der Grund: dass der Reiter die Lebenslauf-Sicht eines Geräts ist und mit abgeschlossenen Monaten rechnet, seit wann das Gerät erfasst ist und was als Nächstes passieren muss. ⚠ Der Weg daneben richtet sich nach der Lage, nicht nach der Bequemlichkeit: Bei einem Gerät, das jünger ist als der erste abschließbare Monat, führt der Knopf zu Cockpit → Monat — dort steht das Gerät bereits — und ausdrücklich nicht zum Monatsabschluss, denn es gibt noch keinen Monat, den man abschließen könnte. Erst wenn abgeschlossene Monate vorliegen, für die nichts erfasst wurde, verweist er dorthin. Unterschieden werden außerdem stillgelegte und auf inaktiv gesetzte Geräte sowie Altbestand ohne Anschaffungsdatum. ⚠ Es ändert sich keine einzige Zahl — die Sicht sagt nur, was sie vorher verschwiegen hat. (Gemeldet von CHI3fx117, Forum T89667 #152.)
Das Balkonkraftwerk fehlte in der PV-Erzeugung — aber nur im laufenden Monat. Wer neben seinen PV-Modulen ein Balkonkraftwerk erfasst hat, las in Cockpit → Monat eine zu kleine PV-Erzeugung: Die große Kennzahl oben und die Zeile in der Energie-Bilanz zählten nur die Module, während der Block „Kategorien” darunter beide Erzeuger korrekt auswies. Bei einem Melder standen dort 679 kWh gegen 679 + 45 kWh — die 45 Kilowattstunden des Balkonkraftwerks tauchten in keiner Bilanzgröße auf, und damit stimmten auch Autarkie und Eigenverbrauchsquote des laufenden Monats nicht. ⚠ Der Fehler heilte sich beim Monatsabschluss selbst, und genau das machte ihn schwer zu fassen: eedc bezieht die Zahlen eines laufenden Monats aus den Sensoren, die eines abgeschlossenen aus den gespeicherten Werten — und nur der erste Weg ließ das Balkonkraftwerk aus. Derselbe Monat zeigte also je nach Zeitpunkt zwei verschiedene Zahlen. Beide Wege rechnen jetzt gleich. ⚠ An abgeschlossenen Monaten ändert sich nichts, sie waren nie betroffen; ebenso wenig an Anlagen ohne Balkonkraftwerk. ⚠ Die eigene Zeile des Balkonkraftwerks in der Wirtschaftlichkeit bleibt unangetastet — dort hat es weiterhin eine getrennte Position und wird nicht doppelt gezählt. Wer einen Gesamt-Erzeugungssensor für die ganze Anlage zugeordnet hat, war nie betroffen und bleibt es auch: Ein solcher Sensor misst beides bereits, und eedc addiert dann nichts hinzu. (Gemeldet von dietmar1968, Forum T77723 #775.)
Ein E-Auto von 2017 verlangte Stromzähler-Werte ab 2017. Der Zeitraum, für den eedc Monatsdaten erwartet, hing am ältesten Gerät — nicht an der Anlage. Wer sein Fahrzeug korrekt mit dem Anschaffungsdatum 2017 eingetragen hatte, bekam an einer PV-Anlage von 2022 Einspeisung und Netzbezug ab 2017 abverlangt, und der Sprung „Nächster offener Monat” landete entsprechend weit in der Vergangenheit. Maßgeblich ist jetzt das Installationsdatum der Anlage; ohne gepflegtes Datum das älteste Anschaffungsdatum der Erzeuger (PV-Module, Balkonkraftwerk), erst danach die früheste vorhandene Datenzeile. Eine Monatszeile ist eine Aussage über die Anlage — ein Gerät begründet keine Einspeisungszeile. ⚠ Wer sich bisher mit Umdatieren beholfen hat, kann das echte Anschaffungsdatum wieder eintragen — genau das war die naheliegende Abhilfe und sie kostet die Wirtschaftlichkeits-Historie des Geräts. ⚠ An der Auswertungs-Grenze ändert sich nichts: Ob eine Komponente in einem Monat mitrechnet, entscheidet unverändert ihr eigenes Anschaffungs-/Stilllegungsdatum. Neu daneben: Der Daten-Checker meldet einen Erzeuger, der älter ist als das Anlagendatum — dann wurde erzeugt, bevor die Anlage laut Stammdaten existierte, und eines der beiden Daten stimmt nicht. Bei allen anderen Komponententypen erscheint bewusst keine Meldung, weil ein früheres Datum dort der Normalfall ist. (Gemeldet von fridolin22, Forum T77723 #773, und van; intern hatten drei Stellen drei verschiedene Antworten auf dieselbe Frage — Daten-Checker, „nächster offener Monat” und die Monatsdaten-Tabelle lesen jetzt denselben Anker.)
Der Legacy-Hinweis forderte eine Handlung, die er nie überprüft hat — und wiederholte sie endlos. Wer Monatsdaten aus der Zeit vor seinen Komponenten pflegt, las in der Monatsdaten-Liste „Bitte jeden betroffenen Monat einmal öffnen und speichern”. Bei einer Bestandsanlage, deren Komponenten mit einem späteren Anschaffungsdatum eingetragen sind, konnte das nie wirken: eedc ordnet einen PV-Gesamtwert nur Modulen zu, die im betreffenden Monat auch existiert haben — sonst würde eine Erweiterung rückwirkend Strom erzeugen, den sie nie erzeugt hat (#236). Es gibt in diesen Monaten also gar kein Gerät, das den Wert übernehmen könnte, und die Meldung blieb nach jedem Speichern unverändert stehen. Ein Melder ist ihr über 14 Monate gefolgt. Der Hinweis prüft jetzt seine eigene Vorbedingung und nennt in diesem Fall den Grund statt einer Handlung: dass laut Anschaffungsdatum keine passende Komponente aktiv war, dazu den direkten Weg zu den Komponenten. ⚠ Für den echten Migrationsfall bleibt alles wie es war — steht ein Gerät im Monat bereit, ist „öffnen und speichern” weiterhin der richtige und einzige Weg. ⚠ An den Daten ändert sich nichts: Sobald das Anschaffungsdatum auf den tatsächlichen Zeitpunkt zurückgezogen ist, lösen sich die betroffenen Monate von selbst auf — die Zuordnung wird bei jedem Aufruf gerechnet, nicht einmalig weggeschrieben. (Gemeldet von van, 13.08.2026.)
Beim Öffnen von Cockpit → Live sprang der Börsenpreis-Block. Für rund eine Sekunde stand der Börsenpreis-Verlauf ganz oben und als einziger Inhalt auf der Seite, danach erschienen Energiefluss und Kennzahlen und schoben ihn um mehrere hundert Pixel nach unten — in Edge und Chrome deutlich, in Firefox kaum. Der Eindruck war, der Block werde überschrieben. ⚠ Überschrieben wurde nichts, und die Ursache ist eine Reihenfolge: Beim ersten Render steht der Ladezustand noch auf „nicht ladend”, die Seite ist praktisch leer; danach erscheint ein knapp 80 Pixel hoher Ladebalken. Die Börsenpreise sind öffentliche Marktdaten ohne Sensor-Abruf und deshalb zuerst zurück, während der Live-Abruf an den Sensoren hängt — der Block erscheint damit direkt unter dem Ladebalken. Der Platzhalter ist also viel kleiner als das, was er ersetzt. Der Block wartet jetzt darauf, dass der Ladezustand entschieden ist. ⚠ Er bleibt bewusst außerhalb der Verfügbarkeits-Prüfung (Begründung unverändert seit #335): Wer noch keine Leistungssensoren zugeordnet hat, sähe sonst nur „Keine Live-Daten verfügbar” und nie einen Block, der ohne jede Einrichtung funktioniert. Ein Platzhalter in voller Blockhöhe wurde verworfen — er hätte die Sicht für alle anderen dauerhaft verlängert. (Gemeldet von rapahl, 13.08.2026, und an der eigenen HA-App bestätigt.)
In den Import-Vorschauen standen die Zahlen englisch. Wer Daten aus der Cloud, aus einer eigenen Datei oder aus einem Portal importierte, sah in der Monatsübersicht vor dem Import Werte wie „1234.5” statt „1.234,5” — Dezimalpunkt statt Komma, kein Tausenderpunkt. Betroffen waren PV-Erzeugung, Einspeisung, Netzbezug und beide Speicher-Größen in allen drei Import-Assistenten, dazu die Prozentangaben bei der Verteilung auf mehrere Komponenten. Im Daten-Checker nannte außerdem eine Fehlermeldung das Datum roh („Reparatur für 2026-08-13 fehlgeschlagen” statt „13.08.2026”). ⚠ Die importierten Werte waren immer richtig — es ging allein um die Anzeige der Vorschau. (Ursache war nicht der Code, sondern sein Prüfer: der Wächter, der solche Anzeigen seit Juni verhindert, kannte die betroffenen Flächen nicht — er folgte nur statischen Importen und brach an der Einstellungs-Registry ab. Beides ist behoben; die sieben Assistenten und die zehn Einstellungs-Flächen liegen jetzt in seinem Prüfbereich.)

[4.0.14] - 2026-08-13 — Gemessen statt geschätzt, gesagt statt geschwiegen

Added

Neue Auswertung im Komponenten-Hub Speicher: „Hätte mehr Kapazität geholfen?” (#358 Phase 2). Sie beantwortet die Frage aus den vorhandenen Stundendaten — und zwar gedeckelt: Überschuss, der ins Netz ging, während der Speicher voll war, zählt nur so weit, wie der Speicher ihn bis zum nächsten Sonnenaufgang auch wieder abgegeben hätte. ⚠ Der Unterschied ist keine Feinheit. An zwölf Junitagen einer echten Anlage weist die naheliegende Rechnung 471,6 kWh „ungenutztes Potential” aus, während der Speicher in keiner dieser Nächte unter 31 % fiel: Zusätzliche Kapazität hätte dort nichts gebracht, weil niemand sie abgenommen hätte. Umgekehrt im Winter, wo kaum Überschuss anfällt, der Speicher aber jede Nacht leer läuft. Der Block zeigt deshalb die gedeckelte Zahl groß, die naive Summe ausdrücklich als Obergrenze daneben, dazu die eigentliche Begrenzung („in wie vielen Nächten lief der Speicher überhaupt leer?”) und eine Heatmap Monat × Ladestand: eine dunkle Zeile oben heißt „lief oft voll”, eine dunkle unten „lief oft leer” — erst beides zusammen macht mehr Kapazität sinnvoll. Bei mehreren Speichern sagt die Sicht, dass der Ladestand anlagenweit erfasst wird und die Aussage nicht je Gerät gilt.
Neuer Block im Komponenten-Hub Speicher: „Größerer Speicher?” (#358 Phase 3). Ein Schieberegler von 50 % bis 200 % der heutigen Kapazität, und dahinter eine Simulation über die tatsächlich gemessenen Stundenwerte: dieselbe Sonne, derselbe Verbrauch, nur eine andere Speichergröße. Ausgegeben werden der Netto-Nutzen pro Jahr, der veränderte Netzbezug und die Amortisationsdauer, dazu die Kurve über alle Kapazitätsstufen und ein Klartext-Satz, der ein „das rechnet sich nicht” auch ausspricht. Drei Dinge unterscheiden das von einer Überschlagsrechnung, und alle drei sind gemessen (355 Tage einer echten Anlage): (1) Gerechnet wird mit der Kapazität, die die Anlage im Alltag wirklich bewegt — aus dem Verlauf des Ladestands abgeleitet, nicht vom Typenschild. Der Unterschied entscheidet über die Aussage: mit den gepflegten Parametern verfehlt die Simulation den gemessenen Netzbezug um −17,5 %, mit der abgeleiteten Basis um −5,4 %. ⚠ Das ist kein Gerätemangel — eine Gegenprobe an 28 Tagen mit vollem Durchlauf bestätigt die gepflegte Kapazität; die kleinere Zahl ist der Teil, der nach Reserven, Ladestrategie und Standby übrig bleibt, und die Sicht sagt das auch so. (2) Bewertet wird der Spread: Ein größerer Speicher senkt den Netzbezug und die Einspeisung — wer nur den gesparten Bezug rechnet, verkauft die entgangene Vergütung als Gewinn (an derselben Anlage 67 € statt 49 €). (3) Der methodische Hinweis ist Pflicht und lässt sich nicht getrennt wegräumen: Die Simulation kennt nur das beobachtete Wetter und ein Verbrauchsverhalten, das bereits auf den vorhandenen Speicher eingespielt ist. Reicht die Historie nicht (unter ~180 Tagen) oder lässt sich die Basis nicht aus dem Ladestand ableiten, steht das ebenfalls dort, statt still mit anderen Annahmen zu rechnen. Für die Referenzanlage lautet die Antwort „lohnt nicht”: +50 % Kapazität bringen 49 €/Jahr bei rund 2.100 € Anschaffung.
Der Speicher-Hub sagt jetzt, wie groß der Speicher wirklich ist — und woran ein Unterschied liegt. Neben der gepflegten nutzbaren Kapazität steht die Zahl, die eedc aus dem gemessenen Ladestands-Verlauf ableitet („im Alltag bewegt”), dazu der Bereich, in dem der Speicher tatsächlich lebt, und an wie vielen Tagen er voll bzw. leer wurde. ⚠ Die gepflegte Zahl bleibt maßgeblich und wird nicht ersetzt: Sie trägt eine Absicht — es gibt Anwender, die ihren Speicher bewusst nicht dauernd auf 100 % laden, und für die wäre eine „Korrektur” nach unten falsch. Deshalb erklärt eedc den Unterschied statt ihn zu beheben, und es unterscheidet dabei zwei Fälle, die vorher nicht auseinanderzuhalten waren: Wird der Speicher regelmäßig voll und geht trotzdem weniger durch, sind es Ladeverluste (gegen Ende der Ladung nimmt ein Speicher viel Energie auf, die den Ladestand kaum noch bewegt — an einer echten Anlage im obersten Ladestands-Fünftel 18,7 kWh je 100 % gegen 7–9,5 in der Mitte); wird er nie voll, ist die kleinere Zahl die eigene Ladestrategie und die Meldung verweist auf die Einstellungen der Komponente.

Fixed

Der Statistik-Import erfand eine Messung, wenn keine Zähler zugeordnet waren — und schwieg im anderen Fall. Wer nur Erzeuger-Sensoren zugeordnet hat, bekam beim HA-Statistik-Import eine Monatszeile mit 0 kWh Einspeisung und 0 kWh Netzbezug: Werte, die niemand gemessen hat und die der Daten-Checker anschließend zu Recht als unplausibel meldete („beide 0”). Wählte man die Basis-Felder in der Vorschau dagegen ausdrücklich ab, entstanden Gerätewerte ganz ohne Monatszeile — der Monat verschwand aus allen Listen, die an der Zählerzeile hängen, und der Import sagte dazu nichts. Zwei Wege, zwei verschiedene Fehlbilder, derselbe Sachverhalt. Jetzt entsteht keine Zeile ohne Zählerwert, und der Import nennt nach dem Lauf die betroffenen Monate samt Weg zum Nachtragen. ⚠ Ein Zähler, der ehrlich 0 meldet, schreibt seinen Monat weiterhin — die Unterscheidung ist „kein Wert” gegen „gemessene Null”, nicht „0 oder nicht”. Bestehende 0-Zeilen bleiben unangetastet; sie sind über den Monatsabschluss korrigierbar. (N-240 — dieselbe Klasse wie die #349-Kette, hier auf dem HA-Weg.)
Eine geänderte Datenquelle wirkte ab sofort — und niemand sagte, dass die Vergangenheit unberührt bleibt. Wer einem Feld einen anderen Sensor zuordnet, ein Vorzeichen umkehrt oder eine neue Komponente ergänzt, bekommt ab diesem Moment richtige Werte; die bereits gespeicherten Tages- und Stundenwerte tragen aber weiter die Zuordnung, die zum Zeitpunkt ihrer Berechnung galt. eedc quittierte die Änderung bisher kommentarlos, und der Anwender bemerkte die Lücke über eine Drift-Beobachtung oder gar nicht. Die Datenquellen-Fläche zeigt jetzt nach jeder echten Änderung einen nicht-blockierenden Hinweis mit den betroffenen Feldern und dem Datum, ab dem die Werte neu sind, dazu den direkten Weg zur Reparatur-Werkbank („Zeitraum neu aggregieren”). Er überlebt einen Neustart — die Frage stellt sich oft erst Tage später — und verschwindet erst auf „Verstanden”. ⚠ Automatisch passiert weiterhin nichts: Die Historie neu zu rechnen kann Stunden dauern und ist selten gewollt, und die Quittung bedeutet „zur Kenntnis genommen”, nicht „erledigt”. ⚠ Betroffen sind alle Zuordnungen, nicht nur die Zähler — Leistung (Kurvenform der Stunden), Ladestand und Strompreis landen ebenso in den gespeicherten Tageswerten. Ohne aggregierte Historie — also im Erst-Setup — schweigt der Hinweis. (Konzept #192 B.)
Wer zwei Wechselrichter über die Cloud importiert, bekam keinen Monatsabschluss mehr. Seit dem Import je Station („Diese Quelle misst”) landeten Erträge und Speicherwerte richtig am jeweiligen Gerät — Einspeisung und Netzbezug wurden dabei aber verworfen. Die Folge: Der Import lief durch, die Zahlen standen im Cockpit, in der Monatsdaten-Liste blieb der Monat leer, und kein erneuter Import konnte das heilen. Der Daten-Checker meldete den Monat als „fehlt” und bot zugleich an, die vorhandenen Messwerte zu löschen. Die Ursache war eine falsche Annahme auf unserer Seite: Wir hatten den Wert einer Station für eine Teilsumme gehalten, so wie es die Erzeugung tatsächlich ist. Einspeisung und Netzbezug misst ein Wechselrichter jedoch gar nicht — er liest sie vom Smartmeter am Hausanschluss. Alle Geräte an einem Anschluss melden denselben Wert; er ist redundant, nicht anteilig. eedc übernimmt ihn jetzt einmal in den Monat, und zwar auf beiden Wegen (Cloud-Import und Cloud-Abruf im Monatsabschluss). ⚠ Addiert wird nichts — eine zweite Station bestätigt den Wert, sie erhöht ihn nicht. Meldet ein Wechselrichter keine Zählerwerte, weil kein Smartmeter angebunden ist, überschreibt seine 0 keinen echten Wert. Und wenn zwei Geräte verschiedene Zählerstände melden, sagt eedc es, statt still eines davon zu nehmen. Erzeugung und Speicherumsatz bleiben unverändert gerätebezogen — dort wäre der Wert einer von zwei Stationen wirklich nur die halbe Wahrheit. (Gemeldet von OliS2811, #349.)
„Bestehende Monate überschreiben” überschrieb nicht — und sagte es erst hinterher. Wer beim Import den Haken setzte, bekam Werte, die er einmal von Hand korrigiert hatte, nicht ersetzt; stattdessen meldete der Assistent nach dem Lauf „6 Felder durch manuell gepflegte Werte geschützt”. eedc tat damit etwas anderes, als angekreuzt war. Praktisch hieß das: Ein einmal korrigierter Monat ließ sich nie wieder importieren — bei OliS2811 (#349) war das der Grund, warum er Monate erst löschen musste, um überhaupt weiterzukommen. Zusätzlich war es inkonsistent: Ein CSV-Import galt als Handarbeit und kam durch, ein Cloud-Import mit demselben Klick nicht — derselbe Anwender, dieselbe Absicht, zwei Ergebnisse. Der Haken wirkt jetzt. ⚠ Und er sagt vorher, was er kostet: Der Assistent nennt Anzahl, Monate und Beispiele der manuell gepflegten Werte, die ersetzt würden — ohne Haken bleiben sie unangetastet. Die Schutzregel selbst bleibt unverändert für alles, was im Hintergrund schreibt (Sensor-Abrufe, automatische Aggregation): Handarbeit wird von der Maschine nicht überschrieben, das war und bleibt der Sinn der Regel (FrodoVDR #251). Nur der ausdrückliche Klick zählt jetzt als das, was er ist. Technisch behält der Wert dabei die Herkunft „Import” — sonst wäre der nächste reguläre Import an einer Reparatur-Markierung abgeprallt und die Falle nur verschoben.
„Monat löschen” löschte nur die Hälfte. Die Voreinstellung entfernte die Zählerzeile und ließ die Messwerte der Komponenten stehen — gedacht als Schonung, weil gemessene Gerätewerte oft die teureren Daten sind. Herausgekommen ist der Zustand, der die #349-Kette überhaupt erst ausgelöst hat: ein Monat, der in keiner Liste mehr auftaucht und trotzdem jeden erneuten Import abweist, unsichtbar und wirksam zugleich. Einspeisung und Netzbezug sind Pflichtfelder eines Monats; eine Hälfte allein zu löschen ergibt keinen Zustand, den eine Auswertung sinnvoll darstellen könnte. Gelöscht wird jetzt immer der ganze Monat, und der Dialog nennt vorher die betroffenen Komponenten beim Namen. Für Reste, die auf anderen Wegen entstehen — etwa ein HA-Statistik-Import ohne Zähler-Sensoren —, bleibt der Weg über den Daten-Checker.
Der Hinweis auf Gerätewerte ohne Zählerzeile nannte eine Ursache, die er nicht kennen kann — und führte ins Leere. Die Meldung im Daten-Checker behauptete „Der Monat wurde gelöscht” und bot als sichtbare Handlung an, die Messwerte zu entfernen. Gelöscht ist aber nur einer von mehreren Wegen, auf denen dieser Zustand entsteht: Auch ein HA-Statistik-Import ohne Zähler-Sensoren hinterlässt Gerätewerte ohne Monatszeile, und wer nur Erzeuger-Sensoren zugeordnet hat, trifft genau das. Die Meldung beschreibt jetzt den Zustand statt seiner vermuteten Ursache, nennt Nachtragen als Regelfall und Entfernen als Ausnahme — und ihr Link führt direkt in das Monatsformular dieses Monats, statt auf die Liste, in der man ihn erst suchen muss.
Bei mehreren Speichern kannte die gespeicherte Historie nur den Ladestand eines Geräts. Wer zwei Speicher mit je eigenem Ladestands-Sensor betreibt, bekam in allen Auswertungen den Ladestand eines davon — welches, entschied die Reihenfolge, in der die Sensoren zugeordnet wurden. eedc wies diesen Wert als anlagenweit aus; betroffen waren die Vollzyklen des Tages, die SoC-Hübe und die beiden Speicher-Auswertungen im Komponenten-Hub. Erzeugung, Verbrauch und Netzbezug waren es nicht. Jetzt liest eedc jeden zugeordneten Ladestands-Sensor und bildet daraus den Anlagenwert kapazitätsgewichtet: ein 15-kWh-Speicher auf 20 % und ein 5-kWh-Speicher auf 100 % ergeben zusammen 40 % — der naheliegende Mittelwert behauptete 60 % und damit anderthalb Mal so viel Energie, wie im Haus steht. Die Ladestände der einzelnen Geräte werden zusätzlich gespeichert und im Block „Größerer Speicher?” angezeigt. ⚠ Anlagen mit einem Speicher ändern sich nicht — dort ist das gewichtete Mittel über ein Gerät exakt dessen Ladestand. ⚠ Bereits gespeicherte Tage rechnet eedc nicht von selbst neu: der Daten-Checker meldet betroffene Zeiträume und stellt „Zeitraum neu aggregieren” daneben.
„Speicher voll um” meldete zu früh — die Rechnung kannte keine Ladeverluste. Die Schätzung, wann der Speicher heute voll ist (HA-Sensor eedc_speicher_voll_um und die Kachel in der Tages-Vorschau), rechnete den Ladeweg verlustfrei: Um 12 kWh einzulagern, hielt sie 12 kWh Überschuss für ausreichend. Real sind es bei einem Wirkungsgrad von 95 % rund 12,7 kWh, bei 85 % über 14 — die gemeldete Uhrzeit lag damit systematisch vor der tatsächlichen, und je schlechter der Speicher, desto weiter. Gerechnet wird jetzt mit dem gepflegten Wirkungsgrad des Geräts; bei mehreren Speichern mit dem niedrigsten, weil eine Kette nicht besser sein kann als ihr schwächstes Glied. ⚠ Die gemeldete Uhrzeit rückt dadurch nach hinten — das ist die Korrektur. Wer eine Automation an dem Sensor aufhängt, bekommt sie eine Stunde später als bisher, aber dann, wenn der Speicher wirklich voll ist. Im selben Zug lesen beide Pfade (Sensor und Vorschau) Kapazität und Wirkungsgrad über eine gemeinsame Stelle, statt dieselbe Aggregation zweimal zu bilden.
Die Sensoren wechselten nicht zur vollen Stunde, sondern zu der Minute, in der eedc zuletzt gestartet wurde. Am deutlichsten beim Börsenpreis: Er gilt je Stunde, in Home Assistant kam der neue Wert aber erst Minuten später an — an zwei Verläufen gemeldet um 09:12:56 und, nach einem Update-Neustart am selben Tag, um 11:08:02. Der Wert war dabei jedes Mal richtig, nur zu spät. Ursache war der Takt des MQTT-Versands: Er lief ab dem Startzeitpunkt des Add-ons durch statt an der Uhr, und bei der Voreinstellung von 60 Minuten bestimmte damit allein der letzte Neustart, wie weit der Versand hinter der vollen Stunde lag. Wer Laden oder Entladen an den Preis-Sensoren aufhängt — Preis, Rang, Abstand zum Mittel, Anzahl günstiger Stunden —, steuerte nach jedem Stundenwechsel im Mittel eine halbe Stunde lang mit den Werten der Vorstunde. Der Versand richtet sich jetzt nach der Uhr: bei 60 Minuten zur vollen Stunde, bei kürzeren Abständen im passenden Raster (:00, :15, :30, :45), bei ganzen Stundenschritten zur vollen Stunde des Tages. ⚠ Ein krummes Intervall wie 90 Minuten behält den bisherigen Takt — dort gibt es keinen Rasterpunkt, der sich wiederholt, und jede Ausrichtung würde den eingestellten Abstand still verändern. Betroffen waren alle per MQTT versandten Sensoren; auffallen konnte es nur beim Preis, weil nur er zur vollen Stunde springt. (Gemeldet von rapahl.)

[4.0.13] - 2026-08-12 — Es zählt die Verbindung, nicht die Betriebsart

Added

Neuer Sensor: der Abstand des Börsenpreises zum Tagesmittel in ct/kWh. eedc meldet diesen Abstand bisher nur in Prozent — und diese Zahl bedeutet für jeden Anwender etwas anderes. Wer einen dynamischen Tarif bezieht, zahlt nicht den Börsenpreis, sondern Börsenpreis plus feste Bestandteile (Netzentgelt, Abgaben, Marge). Ein solcher Aufschlag verschiebt den Stundenpreis und das Tagesmittel um denselben Betrag: die Differenz bleibt dieselbe, der Prozentwert nicht. An einem echten Tag gemessen (11.08., Ø 9,92 ct): die billigste Stunde liegt −9,93 ct unter dem Mittel — auf der Börsenkurve wie auf der Endpreiskurve —, während die Prozentangabe zwischen −100,1 % und −33,2 % springt. Der neue Sensor eedc_preis_abstand_cent liefert die Größe, die sich übertragen lässt; sie eignet sich für Regeln wie „lade, solange der Strom 5 ct unter dem Schnitt liegt” und macht einen Ja/Nein-Schalter überflüssig (<= 0 ist in HA eine Zeile). Das Rang-Profil trägt den Wert zusätzlich je Stunde, sodass sich eine eigene Schwelle über den ganzen Tag auswerten lässt. In Cockpit → Live steht der Abstand als vierte Kachel neben den Börsenpreis-Kennzahlen. ⚠ Der prozentuale Sensor bleibt unverändert — bestehende Automationen ändern sich nicht. (Angeregt von rapahl.)
Die fünf günstigsten Stunden sind im Börsenpreis-Diagramm jetzt als Rang zu sehen. Cockpit → Live markierte bisher nur, welche Stunden unter der Günstig-Schwelle liegen — das können an einem billigen Tag auch zehn sein. Die Kurve trägt jetzt zusätzlich die Ziffern 1 bis 5 an den günstigsten Stunden, getrennt für das Tag- und das Nachtfenster; es ist derselbe Rang, den der Sensor eedc_preis_rang meldet. ⚠ Die Zählung günstiger Stunden bleibt ungekappt: Sie dient in Automationen als Divisor und wurde mit v4.0.10 bewusst vom Rang gelöst — die Fläche sagt weiterhin „unter der Schwelle”, die Ziffer sagt „eine der fünf besten”. (Angeregt von rapahl.)
Der Daten-Checker erkennt eine Speicher-Kapazität, die in Wh statt in kWh eingetragen wurde. Ein Balkonkraftwerk fragt die Kapazität seines Akkus in Wh ab (so steht sie auf dem Gerät und in der Hersteller-App), die Speicher-Komponente daneben in kWh. Wer den Zahlenwert von oben nach unten überträgt, liegt um den Faktor 1000 daneben — und nichts fiel bisher auf: Vollzyklen, Auslastung und die Wirtschaftlichkeit des Speichers rechneten still gegen einen Nenner, den es nicht gibt. Gemeldet wird nicht „zu groß” (das wäre geraten und träfe echte Großspeicher), sondern der Widerspruch: zwei gepflegte Felder desselben Geräts mit demselben Zahlenwert in zwei Einheiten. Die Meldung nennt die Zahl, die einzutragen ist. (Gefunden beim Durchgehen der Anker-Solix-Sensorliste von azywietz-web, Discussion #366.)

Fixed

Nach einem Speicher-Tausch führte eedc alt und neu zusammen als Kapazität der Anlage. Wer sein Gerät ersetzt oder erweitert, legt in eedc den alten Speicher mit Stilllegungsdatum ab und den neuen daneben — beide bleiben in der Historie, das ist so gewollt. Drei Stellen summierten daraufhin aber beide Kapazitäten: Cockpit → Monat, der Jahresbericht und der anonyme Community-Datensatz. An einem echten Bestand gemessen: 46,2 statt 30,8 kWh. Im Community-Vergleich war das am teuersten — der Server rechnet nichts nach, die Anlage stand also in einer Größenklasse, die es nie gab, und verzog die Vergleichswerte für alle anderen mit. Gezählt wird jetzt das Gerät, das zum jeweiligen Zeitpunkt vorhanden war; im Jahresbericht die Ausstattung zum Ende des Berichtsjahres. ⚠ Betroffene Anlagen melden ihre Speichergröße künftig kleiner — das ist die Korrektur, kein Verlust; sie wirkt beim nächsten vollständigen Teilen.
Im Docker-Betrieb mit Home-Assistant-Anbindung per Token entstanden nie Tageswerte. Wer eedc als eigenen Container betreibt und Home Assistant über einen langlebigen Zugriffstoken angebunden hat, bekam in Cockpit → Tag dauerhaft „—” und als Quelle „Prognose” — obwohl die Live-Ansicht normal lief und ein von Hand nachgezogener Tag vollständig war. Ursache: Für den Tagesverlauf kannte eedc nur zwei Fälle, „läuft als HA-Add-on” und „bekommt seine Werte per MQTT”. Der dritte — Container mit HA-Verbindung — landete beim MQTT-Weg, fand dort nichts und brach die Tagesaggregation ab, bevor sie die Zählerstände überhaupt erreichte. Jetzt entscheidet die Zuordnung über den Weg, nicht die Umgebung: Wo HA-Sensoren zugeordnet und erreichbar sind, liest eedc aus Home Assistant; MQTT bleibt für alle, die es nutzen — und greift zusätzlich als Rückfall, wenn der HA-Weg leer bleibt. An einer echten Installation gemessen: aus „kein Tageswert” wurde eine vollständige Tageszusammenfassung mit 24 Stundenzeilen. Dieselbe Umgebungs-Abfrage verschwieg dem Container-Betrieb außerdem den Speicher-Ladestand (und damit die Vollzyklen des Tages), die Tages-Spitzenwerte und den eigenen Strompreis-Sensor. ⚠ Bereits fehlende Tage holt der Daten-Checker nach („Zeitraum neu aggregieren”) — rückwirkend füllt sich nichts von selbst. (Gemeldet von IdleBit im simon42-Forum.)
Sieben weitere Funktionen fragten nach der Betriebsart statt nach der Verbindung — sie sind mitgegangen. Es ist dieselbe Weiche wie beim Tagesverlauf, an sieben anderen Stellen, und sie betrifft denselben Betrieb (eigener Container, Home Assistant per Token): Die Prognosequellen Solar Forecast ML und Solcast führten stillschweigend auf die eedc-Prognose zurück, mit dem Hinweis, sie seien „nur im HA-Add-on verfügbar”, während ihre Sensoren über dieselbe Verbindung lesbar sind (dazu ein Statustext, der „nicht eingerichtet” meldete, wo der Abruf daneben erfolgreich gewesen wäre). Bei SFML war zusätzlich das Auswahlfeld gesperrt, das seine Bedingung ebenfalls an der Betriebsart festmachte statt an der Verbindung — der Backend-Weg wäre sonst für genau den Betrieb unerreichbar geblieben, für den er gebaut wurde. Die kWh-Werte für heute und gestern kamen nur aus MQTT, das Verbrauchsprofil nicht aus der HA-Historie, und die Langzeitstatistik erreichte weder Cockpit → Monat noch die Vorschläge im Monatsabschluss — dort war jeder Wert von Hand einzutragen, obwohl Home Assistant ihn kannte. Unter jeder dieser Stellen liegt ein Dienst, der seine Erreichbarkeit selbst prüft; zwei Stellen stellten die Frage sogar unmittelbar davor noch einmal.

⚠ Korrektur einer früheren Angabe: Der v4.0.10-Abschnitt sagte, fünf bis dahin Add-on-gebundene Funktionen arbeiteten „jetzt auch mit einer Remote-Verbindung”. Zutreffend war das nur für eine (die Daten-Checker-Prüfung auf vertauschte kW-/kWh-Sensoren). Bei den übrigen vier wurde die Verbindung darunter hergestellt, die vorgeschaltete Abfrage aber nicht nachgezogen — sie kamen nie bei ihr an. Mit dieser Version stimmt die Aussage.
Der Statistik-Import ist jetzt auch ohne Add-on erreichbar — und jede gesperrte Einstellung sagt, was ihr fehlt. Einstellungen → Integration → Statistik-Import holt vergangene Monate aus der Home-Assistant-Langzeitstatistik. Diese Fläche war dem Add-on-Betrieb vorbehalten, obwohl der Zugriff darunter längst über die verbundene Instanz läuft — im Handbuch stand der Token-Weg sogar schon als gültige Voraussetzung. Wer eedc im Container betreibt, konnte damit zwar laufende Monate aus Home Assistant lesen, seine Historie aber nicht nachholen. Zugleich unterscheidet eedc jetzt zwei verschiedene Voraussetzungen, statt beide „HA-Integration” zu nennen: Was den HA-Supervisor braucht (Add-on-Protokolle, direkter HA-Import, die alte Sensor-Zuordnung), bleibt dem Add-on vorbehalten; was nur eine erreichbare Instanz braucht, steht jeder Verbindungsart offen. Der Hinweis auf einer gesperrten Kachel nennt entsprechend den konkreten Grund — „gibt es nur im Add-on” ist etwas anderes als „verbinde zuerst Home Assistant”, und bisher stand dort für beide Fälle derselbe Satz.
Ein gelöschter Monat ließ die Messwerte seiner Komponenten zurück — und blockierte damit den erneuten Import. Ein Monat besteht aus zwei Teilen: der Zählerzeile der Anlage und den Messwerten je Komponente (PV je Modul, Speicher, Wallbox …). „Monat löschen” entfernte nur die Zählerzeile. Der Monat verschwand damit aus allen Listen, die Gerätewerte blieben aber stehen — unsichtbar und trotzdem wirksam: Ein erneuter Import dieses Monats schrieb nichts und meldete nur „Felder wurden durch manuell gepflegte Werte geschützt”. Wer vorher bewusst gelöscht hatte, suchte den Fehler bei sich. Drei Änderungen: Der Lösch-Dialog nennt jetzt, wie viele Komponenten-Messwerte an dem Monat hängen, und bietet an, sie mitzulöschen (ohne Haken bleiben sie erhalten — gemessene Werte sind meist die teureren Daten). Der Daten-Checker meldet einen bereits entstandenen Rest und entfernt ihn auf Knopfdruck, denn ohne Zählerzeile gibt es keine Zeile mehr, über die man ihn sonst aufräumen könnte. Und der Reset in der Reparatur-Werkbank findet endlich die Werte, die der Import wirklich schreibt: Er suchte bisher nach einer internen Quellen-Bezeichnung, die kein Import je vergibt — die Funktion fand damit strukturell nie etwas, während die Import-Meldung ausdrücklich auf sie verwies. (Gemeldet von OliS2811, #349.)
Im Community-Bereich zeigte das Performance-Profil den ältesten statt den neuesten Monat. Autarkie und Eigenverbrauch standen im Radar auf dem Wert des ersten jemals geteilten Monats — bei einer Anlage, deren erster Monat ein Wintermonat war, also bei knapp 5 %, während das Cockpit für denselben Zeitraum 100 % meldete. Ursache war die Reihenfolge der Monatsliste: Der Community-Server liefert sie mit dem neuesten Monat zuerst, gelesen wurde aber der letzte Eintrag. Betroffen waren außerdem die Auszeichnungen „Autarkiemeister” (prüfte den ältesten Monat) und „Dauerbrenner” (prüfte die zwölf ältesten Monate statt der zwölf letzten). Die anderen Community-Ansichten — PV-Ertrag und Trends — sortieren selbst und waren nie betroffen. (Gemeldet von kingcap1, #375.)
In Auswertungen → Prognose standen die Zahlen der Spalte „PVGIS Prognose” und die ganze Gesamt-Zeile nicht unter ihren Überschriften. Die Spaltenköpfe sind rechtsbündig, die Werte waren es nicht — im großen Fenster lief die Tabelle dadurch sichtbar auseinander. (Gemeldet von Radiocarbonat.)

Changed

Intern: Die Testsuite geht nicht mehr ans Netz. Zweimal ist der Testlauf auf GitHub rot geworden, obwohl derselbe Stand lokal grün war — beide Male, weil ein Test unbemerkt eine echte Wetter-API abgefragt hat und die dort nicht antwortete. Ein Test, der ans Netz geht, prüft nicht mehr nur den Code, sondern auch die Verfügbarkeit eines fremden Servers. Der Testlauf blockiert echte Verbindungen jetzt und nennt jeden Versuch beim Namen. Für die Anwendung ändert sich nichts — es betrifft ausschließlich die Entwicklung.

[4.0.12] - 2026-08-11 — Nutzerwünsche und notwendige Korrekturen

Added

Jede Komponente zeigt jetzt ihren eigenen Amortisations-Fortschritt. Auswertungen → ROI hatte bisher zwei Zahlen je Zeile, die beide in die Zukunft rechneten (ROI und Amortisationsdauer) — daneben steht nun die Messung: „wie viel von dieser Anschaffung ist bereits zurückgeflossen?”. Die neue Spalte „Fortschritt” rechnet die tatsächlich erzielten Erträge gegen den eingesetzten Betrag derselben Zeile, ganz ohne Annahme über die Zukunft. Wo sich ein Ertrag keiner einzelnen Komponente zuordnen lässt — etwa eine Förderung, die im Monatsabschluss für die ganze Anlage gebucht wurde —, steht bewusst ein „—” statt einer erfundenen Aufteilung; der Betrag bleibt in der Gesamtzahl enthalten. Die Erlöse aus Einspeisung und Eigenverbrauch entstehen am Hauszähler und werden deshalb nach gemessener Erzeugung auf die Erzeuger verteilt, nicht nach installierter Leistung.
Ein zweiter Erzeuger mit eigenem Einspeisetarif rechnet jetzt selbst ab. eedc kennt genau einen Einspeisesatz pro Anlage — wer einen zweiten Erzeuger mit abweichender Vergütung betreibt (zweiter Wechselrichter, Anlagenerweiterung mit neuem EEG-Satz), musste dessen Erlös bisher Monat für Monat von Hand als sonstigen Ertrag buchen. Eine Komponente vom Typ Sonstiges mit Kategorie Erzeuger hat dafür jetzt das Feld „Einspeise-Erlös (€)”: Es lässt sich wie jedes andere Feld einer Datenquelle zuordnen, also einem Helfer- oder Template-Sensor aus Home Assistant, der den Erlös mit deinem Satz rechnet. Der Betrag kommt damit monatsgenau und ohne Handarbeit — und wird im Monatsabschluss als Vorschlag angeboten.

Er wirkt überall dort, wo eine Zeitraum-Bilanz steht: Cockpit → Jahr, Aussichten, HA-Sensor netto_ertrag_euro, Jahresbericht-PDF — und über den Amortisations-Fortschritt auch in der Wirtschaftlichkeit. ⚠ Er wird nicht gegen den Anlagen-Einspeiseerlös gerechnet: Zwei Vergütungssätze bedeuten zwei Messungen, in den Einspeisezähler der Anlage gehört also nur die Menge, die zum Anlagentarif abgerechnet wird. Wer den Erlös künftig hier pflegt, sollte die monatlichen Handbuchungen dafür einstellen — sonst zählt derselbe Betrag zweimal. (Aus #310, rilmor-mhrs.)
Der Daten-Checker erkennt jetzt, wenn ein wiederkehrender Betrag am falschen Ort steht. eedc unterscheidet einmalige und wiederkehrende Beträge nicht an ihrer Bezeichnung, sondern am Erfassungsort: ein Jahresbetrag an der Komponente wirkt jedes Jahr (auch in der Prognose), eine Position im Monatsabschluss wirkt einmal. Genau dort kann man sich vertun — und nur dort ist es erkennbar. Zwei neue Hinweise: „Wartung steht in 4 Monaten im Monatsabschluss” (Vorschlag: als Betriebskosten/Jahr bzw. Ertrag/Jahr an die Komponente, dann wirkt der Betrag auch in der Prognose) und „… obwohl Betriebskosten/Jahr gepflegt ist” (dann gehört in den Monatsabschluss nur die Abweichung vom Plan, sonst zählt derselbe Betrag doppelt).

Beides sind Hinweise, keine Fehler — die Erfassung ist nicht falsch, sie kann an der einen Stelle nur weniger. Erkannt wird ausschließlich die Wiederholung derselben Bezeichnung, nie die Bedeutung eines Wortes: aus „Restwert” oder „Förderung” etwas abzuleiten wäre geraten, und eedc rät nicht. Bei Komponenten ohne Feld Ertrag/Jahr (alles außer Wallbox und Sonstiges) schweigt der Hinweis, statt auf ein Feld zu verweisen, das es dort nicht gibt.
Neues Feld „Ertrag/Jahr (€)” an der Komponente — das Gegenstück zu den Betriebskosten pro Jahr. Wer einen wiederkehrenden Ertrag hat, der sich nicht aus den Zählerdaten ergibt — etwa den Einspeise-Erlös eines zweiten Erzeugers mit eigenem Vergütungssatz, den eedc nicht kennen kann (es gibt genau einen Einspeisesatz je Anlage) —, trägt ihn dort einmal ein statt Monat für Monat. Das Feld steht bei Wallbox und Sonstiges unter Bearbeiten → Weitere Angaben & Kosten und wirkt in der Finanz-Prognose, in Auswertungen → ROI und in den HA-Sensoren jahres_ersparnis_euro, roi_prozent und amortisation_jahre. Bei allen anderen Komponenten rechnet eedc die Jahres-Einsparung selbst; dort gibt es das Feld bewusst nicht.

Die Spalte existierte seit jeher in der Datenbank, war aber über kein Formular und keinen Import erreichbar — im PDF-Finanzbericht stand deshalb dauerhaft „—”. Sie wird jetzt auch beim Datenexport mitgesichert; bestehende Sicherungen bleiben lesbar.

Changed

Jede Amortisationsdauer sagt jetzt, worauf sie beruht. „15,8 Jahre” ist keine Messung, sondern eine Rechnung mit einer Annahme über die Zukunft — und die lautet bei eedc: es geht nie wieder etwas kaputt. Das steht jetzt neben der Zahl, statt stillschweigend vorausgesetzt zu werden: in Auswertungen → ROI an der Kachel, an der Break-Even-Kurve, je Zeile in der Tabelle und in der Summenzeile, beim „voraussichtlich JJJJ” der Fortschritts-Kachel, im Komponenten-Hub der Wallbox, im PDF-Finanzbericht und als Teil des Rechenwegs am HA-Sensor amortisation_jahre. Der Satz richtet sich nach deinen Daten: Wer an einer Komponente Kosten/Jahr gepflegt hat, liest dort „inkl. 200,00 €/Jahr Betriebskosten, ohne weitere Instandhaltung” — denn dieser Betrag ist in der Zahl bereits abgezogen. Wer mit künftigen Reparaturen rechnen will, trägt sie genau dort ein; keine Zahl ändert sich durch diese Neuerung, nur ihre Beschriftung.
Betriebskosten belasten eine Komponente nur noch, solange sie läuft. Die Jahres-Betriebskosten aller Komponenten wurden bisher über den gesamten Beobachtungszeitraum abgezogen — auch für Monate, in denen ein Gerät noch gar nicht angeschafft oder bereits stillgelegt war. Eine 2024 gekaufte Wärmepumpe zahlte damit rückwirkend ab 2023 Versicherung, und eine stillgelegte Komponente verlängerte die Amortisation dauerhaft. Betroffen waren Aussichten, Cockpit → Jahr und die USt-Bemessung in Auswertungen → ROI; der HA-Export rechnete an dieser Stelle schon immer richtig, weshalb die Sichten untereinander verschiedene Zahlen nannten. Gemessen an der Demo-Anlage: 1.291,67 € statt 725,00 € Betriebskosten über 31 Monate — der Amortisations-Fortschritt der Anlage steigt dadurch von 10,8 % auf 11,4 %.
⚠ Fünf ausgelieferte HA-Sensoren ändern ihren Wert — die Amortisation wird kürzer. Betroffen sind amortisation_jahre, roi_prozent und jahres_ersparnis_euro sowie die Amortisations-Anzeigen in Auswertungen → ROI und in den Aussichten. Grund ist die korrigierte Kapitalrechnung: Eine einmalige Ausgabe (Reparatur, Ersatzteil) erhöht jetzt einmal den eingesetzten Betrag, statt jedes künftige Jahr von der Ersparnis abgezogen zu werden — und jede Ersparnis wird mit ihrer eigenen Laufzeit hochgerechnet statt mit der Laufzeit der Anlage. Bisher wurde eine 2025 nachgerüstete Komponente zeitanteilig verdünnt, während ihre Kosten voll gegenrechneten. An der Demo-Anlage: 26,4 → 18,5 Jahre. Dazu kommt der Ertrags-Anteil derselben Rechnung (s. u.), der den eingesetzten Betrag zusätzlich mindert. In der Langzeitstatistik ist das ein Sprung an einem Tag, kein Datenverlust. netto_ertrag_euro bleibt unberührt — die Monatsbilanz rechnet unverändert.
Einmalige Beträge aus dem Monatsabschluss werden nicht mehr in die Zukunft hochgerechnet — jetzt auch auf der Ertragsseite. Eine THG-Quote, eine Förderung oder ein einmaliger Erlös unter Sonstige Positionen erhöhte bisher jedes Prognosejahr, als käme der Betrag jährlich wieder. Er zählt weiterhin dort, wo er geflossen ist: in der Monatsbilanz und im Amortisations-Fortschritt („wie viel ist zurückgeflossen?”). In Prognose, ROI-Zähler und HA-Jahresersparnis geht er nicht mehr ein. Gemessen an der Demo-Anlage: Jahres-Netto-Ertrag der Aussichten 5.794,52 → 5.618,39 €, Amortisation in Auswertungen → ROI 15,4 → 15,8 Jahre, HA amortisation_jahre 18,48 → 19,16. Unverändert bleiben netto_ertrag_euro, der Amortisations-Fortschritt und der Kapitaleinsatz.

⚑ Wenn der Betrag jedes Jahr wiederkommt, ist dafür jetzt das neue Feld „Ertrag/Jahr (€)” an der Komponente da (s. u.) — dort wirkt er weiterhin in Prognose und Amortisation. Bitte nicht beides pflegen, sonst zählt derselbe Erlös doppelt.
Eine Förderung senkt jetzt dein eingesetztes Geld, statt die Ersparnis zu erhöhen. Damit ist die Kostenrechnung vollständig: beide Seiten des Monatsabschlusses wirken auf denselben Betrag — eine Ausgabe (Reparatur, Ersatzteil) erhöht den Kapitaleinsatz, ein Ertrag (THG-Quote, Förderung, einmaliger Erlös) mindert ihn. Geld, das du nie ausgeben musstest, muss auch nicht wieder hereinkommen; deine Amortisation wird dadurch kürzer, und der Tooltip in Auswertungen → ROI schreibt den Abzug aus („90.900 € + 1.015 € sonstige Ausgaben − 455 € sonstige Erträge”). Betroffen sind alle vier Sichten mit demselben Nenner: Auswertungen → ROI (gesamt und je Zeile), die Aussichten, der PDF-Finanzbericht und die HA-Sensoren. In der Monatsbilanz ändert sich nichts — dort bleibt der Betrag ein Ertrag des Monats, in dem er geflossen ist (netto_ertrag_euro unverändert).

Gemessen an der Demo-Anlage (455 € Ertrags-Positionen): Kapitaleinsatz 91.915 → 91.460 €, die Zeile des Fahrzeugs 17.560 → 17.105 € (14,3 → 14,0 Jahre), HA amortisation_jahre 19,16 → 19,07, roi_prozent 5,22 → 5,24 %. Der Amortisations-Fortschritt sinkt dabei leicht (11,4 → 10,9 %) — das ist kein Verlust, sondern die Folge derselben Regel: der Betrag zählt nicht mehr als zurückgeflossener Ertrag, weil er nie eingesetzt wurde.

⚑ Wenn der Erlös jedes Jahr wiederkommt — der klassische Fall ist ein zweiter Erzeuger mit eigenem Einspeisetarif —, gehört er nicht in den Monatsabschluss, sondern an die Komponente: als „Ertrag/Jahr (€)” oder, besser, als „Einspeise-Erlös (€)” bei Sonstiges/Erzeuger (s. o.); nur dort wirkt er in Prognose und Amortisationsdauer. Der Daten-Checker weist darauf hin, wenn derselbe Posten Monat für Monat auftaucht. Bestehende Buchungen musst du nicht umstellen — sie bleiben erhalten und in allen Auswertungen sichtbar.

Fixed

Der Speicher-Wirkungsgrad wird jetzt gerechnet statt verworfen — leere Monate füllen sich, und über 100 % kann er nicht mehr. Der Wirkungsgrad eines Monats ist nicht einfach „Entladung ÷ Ladung”: Was am Monatsende im Speicher steht, wird erst im nächsten Monat entladen. eedc hat diesen Übertrag zwar erkannt, aber die falsche Konsequenz gezogen — bei größeren Ladestandssprüngen erschien „—” statt einer Zahl, und darunter stand der rohe, unkorrigierte Wert. Korrigiert wurde nie, obwohl die Funktion dafür seit Längerem existiert und nur zwei von zwölf Sichten erreichte.

Gemessen an der Demo-Anlage: Der November 2025 zeigte „—”, obwohl 81,6 % ermittelbar waren; der Oktober zeigte 83,1 % statt korrekt 82,4 %. Über 27 Monate steht jetzt in jedem eine Zahl. Wo überhaupt kein Ladestand aufgezeichnet ist, erscheint weiterhin der rohe Wert — aber gekennzeichnet („ohne Ladestand gerechnet — ungenau”) statt stillschweigend; und ist er physikalisch unmöglich, wird er unterdrückt mit Begründung statt kommentarlos. In Cockpit → Jahr stand die Warnung „SoC-Drift — Monats-η ausgeblendet” bisher sogar neben einer Zahl, sobald ein einzelner Monat betroffen war; über ein ganzes Jahr mittelt sich der Übertrag aus, dort ist sie ersatzlos weg.

Neu im Daten-Checker: Meldet ein Speicher über die gesamte Historie mehr Entladung als Ladung, sagt eedc das jetzt — mit der häufigsten Ursache im Klartext: Ins Feld „Ladung” gehört die Gesamtladung, die Netzladung ist ein Teil davon und kein zweiter Posten daneben. Passend dazu heißt die Zeile in der Monatsansicht jetzt „davon aus dem Netz” statt „Netzladung (Arbitrage)” — zwei Zeilen ohne dieses Wort liest man als Doppelzählung. (F-22, gemeldet von rapahl — zum zweiten Mal nach Mai 2026; die damalige Lösung war gebaut, erreichte die Ansicht aber nie.)
Der Community-Vergleich zeigte einen Speicher-Wirkungsgrad von 128,6 % — physikalisch unmöglich, und es war unser Rechenfehler. eedc überträgt gar keinen Wirkungsgrad an den Community-Server, sondern nur die reinen kWh; der Prozentwert entstand erst dort. Er wurde ohne Plausibilitätsprüfung, ohne Mindest-Laufzeit und über den gesamten Zeitraum seit der ersten Einreichung einer Anlage gebildet — während die Zyklen in derselben Tabellenzeile auf zwölf Monate normiert waren und mindestens sechs Monate Daten verlangten. Zwei verschiedene Zeiträume nebeneinander, und ein einzelner fehlerhafter Datensatz kippte das Klassenmittel (nachgerechnet: +38 Prozentpunkte durch eine Anlage).

Jetzt gelten für den Wirkungsgrad dieselben Regeln wie für die Zyklen daneben: gleiches Zeitfenster, gleiche Mindest-Laufzeit. Unmögliche Werte fließen nicht ein — sie werden übersprungen, nicht gestutzt (ein auf 100 % gekappter Wert sähe aus wie ein perfekter Speicher), und wie viele es waren, steht in der Antwort. Statt des Mittelwerts steht der Median, den ein Ausreißer nicht mehr kippt. Auch die Rangliste „Top Wirkungsgrad” wird nicht länger vom kaputtesten Datensatz angeführt. Neu: eine Klasse bis 5 kWh — kleine Speicher fehlten in dieser Auswertung bisher vollständig, weshalb auch die genannte Anlagenzahl zu klein war; und die eigene Zeile wird jetzt auch oberhalb von 15 kWh als „(Du)” markiert. (F-23, gemeldet von rapahl.)
Der PDF-Finanzbericht nennt jetzt dieselbe Amortisationsdauer wie die Oberfläche — vorher stand dort strukturell „—”. Er rechnete Gesamt-Anschaffung ÷ Σ einsparung_prognose_jahr: Der Nenner war die Gesamt-Anschaffung statt der relevanten Kosten (die Größe, die alle anderen Sichten seit N-137 teilen), und der Zähler ein Datenbankfeld ohne Schreiber — es stand in keinem Formular, keinem Schema und keinem Import und war an der vermessenen Anlage in 12 von 12 Komponenten NULL. Das PDF zieht die Kennzahl jetzt aus derselben ROI-Auswertung wie Oberfläche und HA-Sensoren. (N-213; das Feld selbst ist mit „Ertrag/Jahr (€)” erstmals pflegbar, s. o.)
Der ausgeschriebene Rechenweg am HA-Sensor amortisation_jahre passte nicht zu seinem eigenen Wert. Das Attribut nannte (Netto-Ertrag ÷ Monate) × 12 und ließ den Betriebskosten-Abzug sowie die unterschiedlichen Laufzeiten der einzelnen Posten weg — an der vermessenen Anlage wich die ausgeschriebene Rechnung um rund 500 € vom danebenstehenden Wert ab. Der Rechenweg nennt jetzt jeden Posten mit seiner eigenen Monatszahl und den Abzug. (N-212)
Zwei Prüf-Ergebnisse der E-Mobilität erreichten die Daten-Checker-Seite nicht. Die Kategorien emob_doppelzaehlung_tage (Warnung, dieselbe Ladung an Wallbox und E-Auto gemessen — mit der Reparatur-Aktion „Zeitraum neu aggregieren”) und phev_anteil_unbestimmt (Hinweis, dass eedc Monate ohne Fahrverbrauch mit 100 % elektrisch rechnet) wurden mit v4.0.11 gebaut, standen aber nicht in KATEGORIE_REIHENFOLGE im Client. Diese Liste ist kein Sortier-Wunsch, sondern ein Filter: Die Seite rendert map über sie, eine fehlende Kategorie erscheint also gar nicht — und der Doppelzählungs-Befund trug zusätzlich keine investition_id, war damit auch im Komponenten-Hub unsichtbar. Beide Kategorien sind eingetragen; ein Wächter im Frontend liest jetzt jede Backend-Kategorie und schlägt an, sobald eine ohne Label oder ohne Platz in der Reihenfolge bleibt. (F-21)
Eine im Monatsabschluss ohne Komponente gebuchte Position wirkte nur in einem Teil der Sichten. Sonstige Positionen, die zur ganzen Anlage gehören (Förderung, Versicherung, eine Reparatur ohne einzelnes Gerät), stehen auf der Monatsdaten-Zeile und nicht an einer InvestitionMonatsdaten-Zeile. Auswertungen → ROI und die Aussichten lasen aber nur letztere: Eine anlagenweite Ausgabe von 3.000 € bewegte den Kapitaleinsatz dieser Sichten um 0 €, während der HA-Sensor sie voll trug (18.000 gegen 15.000 €); eine anlagenweit gebuchte Förderung war in der Wirtschaftlichkeit überhaupt nicht sichtbar. Beide Seiten wirken jetzt in allen vier Sichten mit demselben Betrag, gelesen über die Monats-Fakten (ADR-002/P10) und damit ohne Doppelzählung der bereits komponentengebundenen Beträge. Auf einer einzelnen ROI-Zeile stehen sie weiterhin nicht — sie gehören zu keinem Gerät; dort steht „—”, der Betrag bleibt in der Gesamtzahl. (Bauschritt 4 des Wirtschaftlichkeits-Konzepts §8)
Zwei Wechselrichter, zwei Cloud-Konten, eine Anlage: die zweite Einfuhr verdrängt die erste nicht mehr. Wer mehrere Wechselrichter betreibt, findet sie in der Hersteller-Wolke oft als getrennte „Stationen” wieder (Solarman führt je Gerät eine eigene) — in eedc gehören sie trotzdem in eine Anlage, denn Netzbezug, Einspeisung und Eigenverbrauch gibt es je Hausanschluss nur einmal. Der Import konnte das bisher nicht: Er schrieb immer auf die ganze Anlage. Beim zweiten Durchgang blieb deshalb nur „überspringen” (dann kam der zweite Wechselrichter gar nicht an) oder „überschreiben” — und das verteilte dessen Ertrag anteilig auf alle Stränge und ersetzte obendrein die Hauszähler-Werte des ersten. Beides ohne Warnung.

Der Cloud-Import fragt jetzt in der Vorschau: „Diese Quelle misst — die ganze Anlage / diesen Wechselrichter”. Ist ein Gerät gewählt, gehen die Werte ausschließlich an seine PV-Module und seinen Speicher; Netzbezug, Einspeisung und Eigenverbrauch bleiben unberührt, und der bereits erfasste Monat blockiert den zweiten Erzeuger nicht mehr. eedc sagt in der Ergebnismeldung ausdrücklich, dass die Hauszähler-Größen nicht übernommen wurden. Ohne Auswahl ändert sich nichts — wer eine einzelne Anlage importiert, merkt von der Neuerung nichts. (Gemeldet von OliS2811, #349.)

Auch die Zugangsdaten liegen jetzt nebeneinander. Bisher merkte sich eedc ein Cloud-Konto je Anlage — jedes Speichern überschrieb das vorige. Du speicherst jetzt je Gerät eines, und der monatliche Abruf beim Monatsabschluss holt alle: jede Station liefert die Werte ihres Wechselrichters, keine überschreibt die andere. Ist eine davon gerade nicht erreichbar, liefern die übrigen trotzdem — mit Hinweis, welche gefehlt hat, damit eine halbe Erzeugung nicht wie die ganze aussieht. Netzbezug und Einspeisung kommen nur aus einer Quelle ohne Geräte-Zuordnung; misst keine deiner Quellen den Hausanschluss, bleiben diese beiden Felder leer und eedc sagt warum, statt den Zählerstand einer einzelnen Station als Hauswert auszugeben. Bestehende Konfigurationen werden beim Lesen übernommen — nichts neu einzurichten.

⚑ Wer bereits zwei Stationen in eine Anlage importiert hat, sollte die Monatswerte seiner PV-Module prüfen (Komponenten → PV-Modul → Monatswerte): Ein früherer Import mit „überschreiben” hat dort den Ertrag der zuletzt importierten Station nach kWp verteilt stehen lassen. Ein erneuter Import je Wechselrichter mit der neuen Zuordnung setzt beide Stränge wieder auf ihre eigene Messung.

[4.0.11] - 2026-08-08 — Nichts raten, wo sich messen lässt

Added

Plug-in-Hybride werden nicht mehr als reine Elektroautos gerechnet (#331). Die Fahrzeug-Investition unterstellte bisher 100 % elektrisch gefahrene Kilometer — für ein BEV richtig, für einen Plug-in-Hybrid zu gut: der Benzin-Anteil fiel gleich zweimal unter den Tisch, weder als Kosten noch als Emission. Neu ist am E-Auto das Feld „Eigener Verbrauch (L/100 km)”; ist es gepflegt, hat das Fahrzeug einen Verbrenner. Es gibt bewusst kein Fahrzeugtyp-Feld und keinen Schalter — das gepflegte Feld ist die Aussage, und wer es leer lässt, sieht exakt dieselben Zahlen wie bisher (kein Breaking Change für Bestandsfahrzeuge, nicht um einen Cent).

Den elektrischen Anteil bestimmt eedc bevorzugt gemessen: aus dem monatlich erfassten Fahrverbrauch (kWh) und dem Fahrzeug-Kennwert kWh/100 km, gedeckelt auf die tatsächlich gefahrenen Kilometer. Ist der Fahrverbrauch nicht erfasst, greift der optionale „Elektrische Fahranteil (%)”. Fehlt beides, bleibt es beim bisherigen Verhalten (100 % elektrisch) — einen Richtwert erfindet eedc nicht, das wäre eine Behauptung über ein fremdes Fahrzeug; stattdessen sagt der Daten-Checker, dass die Angabe fehlt.

Was sich dadurch ändert: Der Vergleich „was hätte ein Benziner gekostet” bleibt über alle Kilometer stehen (sonst verglichen wir ein Auto mit einem halben), die real getankten Liter stehen als eigene Kostenposition daneben und mindern zusätzlich die CO₂-Einsparung. Die gemessene Ladung wird nicht zusätzlich skaliert — ein Hybrid lädt ohnehin weniger, ein zweiter Abzug wäre Doppelzählung. Der Anteil wirkt in beiden Rechenachsen über dieselbe Formel: im IST (Komponenten-Hub, Cockpit, HA-Export, CO₂-Bilanz) und in der ROI-Prognose. Angezeigt wird er im Komponenten-Hub als „Verbrenner-Anteil” (km) und „Kraftstoffkosten” (€), mit dem Hinweis, ob er gemessen oder geschätzt ist. (Discussion #330, Safi105.)
Das Einspeisevergütungs-Feld sagt jetzt, wie eedc damit rechnet — und schlägt keinen Satz mehr vor. Auf die Frage aus dem simon42-Forum, ob eedc flat mit der eingetragenen Zahl rechnet oder im Hintergrund einen Misch-Vergütungssatz aus der Anlagengröße ermittelt, gab die Oberfläche bisher keine Antwort: Das Feld hieß an beiden Eingabestellen nur „Einspeisevergütung (ct/kWh)”. Jetzt steht daneben — und in der Hilfe —, dass eedc flat mit dem eingetragenen Satz rechnet und bei gestaffelter EEG-Vergütung der nach kWp gewichtete Mischsatz ins Feld gehört.

⚠ Der Setup-Wizard schlägt keinen Vergütungssatz mehr vor. Bisher trug er den Satz der erreichten Stufe ein (bis 10 kWp 8,2 ct, bis 40 kWp 7,1 ct, darüber 5,8 ct). Das EEG staffelt aber nach installierter Leistung, nicht nach eingespeister Menge: Für die Gesamtanlage gilt der gewichtete Mischsatz, der höher liegt — bei 20 kWp etwa 7,65 statt 7,1 ct. Wer den Vorschlag übernommen hat, rechnet seinen Einspeise-Erlös zu niedrig; bitte den Satz aus deinem Vergütungsbescheid prüfen. Korrigiert wurde die Tabelle nicht, sondern entfernt: Die Sätze ändern sich laufend, und welcher für deine Anlage gilt, weißt nur du. Ein neuer Tarif startet deshalb mit 0 — eine geschätzte Zahl sähe aus wie eine gepflegte.

Damit die 0 nicht unbemerkt bleibt, sagen beide Formulare, was sie bedeutet (kein Einspeise-Erlös), und der Daten-Checker meldet sie — aber nur, wenn im Gültigkeitszeitraum des Tarifs tatsächlich Einspeisung erfasst ist. Bei Volleinspeisung ohne Vergütung oder ausgelaufener Förderung ist 0 richtig und nichts zu tun. Bestehende Tarife sind unberührt.
eedc schätzt, wie viel deiner Autoladung aus der eigenen Sonne kam — auch ohne evcc. Eine Wallbox zählt Kilowattstunden, nicht deren Herkunft. Wer keinen Sensor für den PV-Anteil hatte, bei dem galt bisher die gesamte Heimladung als Netzstrom: 0 % Sonne im Komponenten-Hub, die volle Ladung als Netzbezug in der CO₂-Bilanz, und eine entsprechend zu kleine Ersparnis. Das war keine Messung, sondern eine Annahme — und die ungünstigste.

Jetzt leitet eedc den Anteil aus den eigenen Stundenwerten ab, nach derselben Idee wie evcc: Was in einer Ladestunde weder aus dem Netz noch aus dem Speicher kam, kann nur aus der PV gekommen sein, und was gleichzeitig eingespeist wurde, hätte stattdessen laden können. Die Regel ist an einer echten Anlage gegen evcc als Referenz vermessen worden (963 kWh Heimladung über sieben Monate): evcc kam auf 67,9 % Sonnenanteil, eedcs Rechnung auf 64,7 % — sie untertreibt also eher, als zu schmeicheln. Der Wert ist in der Datenherkunft ausdrücklich als abgeleitet gekennzeichnet, und wo nicht jede Ladestunde auswertbar war, steht das ebenfalls dran.

⚠ Ein selbst gepflegter Wert wird nie überschrieben — auch eine bewusst eingetragene 0 nicht. Wer den PV-Anteil erfasst (etwa über evcc), sieht keine Änderung. Für alle anderen ändern sich Zahlen, und zwar überall dieselbe: im Komponenten-Hub (E-Auto und Wallbox), in Cockpit → Monat und → Jahr, in Auswertungen → Komponenten, in den Aussichten, im Jahresbericht-PDF, in der Monats-Tabelle und in der CO₂-Bilanz. Die E-Auto-Netzladung sinkt, die ausgewiesene Ersparnis steigt. ⚠ Rückwirkend passiert nichts: Die Schätzung entsteht beim Aggregieren eines Tages, bereits abgeschlossene Zeiträume bleiben unverändert — deine historischen Werte bleiben deine.

⚠ Der HA-Sensor „PV-Anteil” springt einmalig. sensor.*_e_auto_pv_anteil_prozent meldete bisher 0 % und zeigt künftig den abgeleiteten Anteil — in der Langzeitstatistik ist das ein Sprung an einem Tag, kein Datenverlust. Betroffen ist nur, wer keinen eigenen PV-Ladesensor pflegt.

⚠ Nachträglich richtiggestellt (September 2026): Die Regel oben zog auch die Entladung des Hausakkus ab: lud das Auto aus dem Speicher, galt das als Netzstrom. Seit September 2026 zählt Speicherstrom als eigener Strom — was in einer Ladestunde nicht aus dem Netz kam, gilt als PV-Anteil, und der E-Auto-Hub weist „davon aus dem Speicher“ getrennt aus. Nachgemessen an echten evcc-Ladevorgängen Juni–August 2026: 94,5 % gegen evcc 93,5 % (mit der alten Regel 76 %). Die Messung oben (64,7 % gegen 67,9 %) stammt aus einem überwiegend winterlichen Zeitraum, in dem das Auto kaum aus dem Speicher lud.

Die ROI-Prognose rät den Anteil ebenfalls nicht mehr. Sie rechnete bisher mit einem Vorgabewert von 60 %, während dieselbe Anlage im IST 0 % zeigte — zwei Zahlen für dieselbe Größe, nur auf zwei Zeitachsen. Jetzt nimmt sie den tatsächlich erreichten Anteil, solange am Fahrzeug keiner gepflegt ist; dein eigener Wert im Feld „PV-Ladeanteil (%)” hat weiterhin immer Vorrang.

⚑ Der Community-Vergleich bleibt bei gemessenen Werten. Der Benchmark-Server bekommt weiterhin nur, was wirklich gezählt wurde — eine Schätzung wäre dort nicht mehr als solche erkennbar. Dein geteilter Datensatz ändert sich durch diese Neuerung nicht.
Die Solarprognose zieht selbst nach, wenn sie nicht mehr zur Anlage passt. Eine PVGIS-Prognose wird beim Abruf eingefroren — baust du danach um, rechnet eedc jede SOLL-Zahl weiter gegen die alte Anlage. Im gemeldeten Extremfall stand für ein 2,4-kWp-Balkonkraftwerk ein Jahres-SOLL von 357 MWh, weil die gespeicherte Prognose zu einem weit größeren System gehörte. Jetzt prüft eedc jede Nacht, ob die aktive Prognose noch zur Anlage passt, und holt bei Bedarf eine neue — mit deinen eingestellten Systemverlusten, nicht mit dem Standardwert. Ausgelöst wird das von einer geänderten Nennleistung, Ausrichtung, Neigung, einem geänderten Standort oder einem hinzugekommenen bzw. entfernten Horizontprofil. Die bisherige Prognose bleibt in der Historie und ist jederzeit wieder aktivierbar — es geht nichts verloren. Jeder automatische Abruf steht mit seinem Grund im Aktivitätsprotokoll. (#363)

⚠ Das Alter einer Prognose ist ausdrücklich kein Grund für einen Neuabruf — und die Einstellungs-Kachel warnt auch nicht mehr davor. PVGIS rechnet mit einem Langzeit-Mittel über viele Jahre; eine ein Jahr alte Prognose liefert für dieselbe Anlage dieselbe Zahl wie eine von heute. Die bisherige Meldung „Letzter Abruf vor N Tagen” (ab sieben Tagen) hat damit ein Problem angezeigt, das es nicht gab. An ihrer Stelle steht jetzt, was nicht mehr passt — zum Beispiel „Nennleistung 9,80 → 2,40 kWp”.

Changed

eedc rechnet die Solarprognose auf dem neueren PVGIS-Strahlungsdatensatz. Die PVGIS-Schnittstelle wechselt von v5.2 auf v5.3 und damit von PVGIS-SARAH2 (Messjahre 2005–2020) auf PVGIS-SARAH3 (2005–2023). ⚠ Deine SOLL-Zahlen ändern sich dadurch einmalig um rund 2 % nach oben (an einer Beispielanlage gemessen: 9,8 kWp Süd 35° — 10.496 → 10.728 kWh im Jahr). Sichtbar wird das in Auswertungen → Prognose vs. IST, im Monatsbericht und beim Performance-Ratio-Hinweis des Daten-Checkers. Bestehende Prognosen werden dafür einmalig automatisch neu abgerufen, damit nicht Bestands- und Neuinstallationen dauerhaft auf verschiedenen Grundlagen rechnen; die bisherige Prognose bleibt in der Historie erhalten.
Die Datenquellen-Seite und der Daten-Checker sagen über den Anlagen-Zählerstand dasselbe. An den Erzeuger-Zeilen stand bisher „Die PV-Erzeugung ist bereits an anderer Stelle zugeordnet”, während der Daten-Checker dieselbe Stelle gleichzeitig als Lücke meldete — beides kann nicht stimmen. Jetzt gilt an beiden Stellen: Ein belegter Anlagen-Zählerstand ist eine vollständige Erfassung, kein Mangel; er bekommt kein Warndreieck mehr, und der Daten-Checker führt die Erzeuger als abgedeckt. Beide Texte nennen dafür, was ein eigener Zähler je Erzeuger zusätzlich brächte (die Aufschlüsselung) und was er kostet (alle oder keiner). Gewarnt wird nur noch bei einem halb erledigten Umbau — wenn also einzelne Erzeuger einen eigenen Zähler haben und andere nicht; dann ist die Tagessumme still zu niedrig, und der Hinweis nennt beide Auswege. Wer je String aufschlüsseln will und dort nur einen Leistungssensor hat, findet den Weg über den HA-Integral-Sensor (Riemannsche Summe) in der Hilfe.

Fixed

Zwei Daten-Checker-Befunde waren gebaut, aber unerreichbar. Der Hinweis auf doppelt gezählte Ladetage (Wallbox und E-Auto tragen denselben Ladevorgang) samt seinem Reparatur-Knopf „Zeitraum neu aggregieren” und der Hinweis „elektrischer Anteil unbestimmt” bei Plug-in-Hybriden erschienen auf der Daten-Checker-Seite nicht: Die Anzeige rendert nur Kategorien, die in ihrer Reihenfolge-Liste stehen, und dort fehlten beide seit ihrem Bau. Wer betroffen war, sah den Befund nie — und damit auch nicht den Weg zur Korrektur. Beide sind jetzt eingetragen, und ein Test prüft künftig jede Checker-Kategorie gegen die Anzeige.
Die E-Auto-Ersparnis wurde in drei Sichten mit dem HEUTIGEN Strompreis gerechnet — auch für Ladungen von vor drei Jahren. Wer seinen Tarif einmal gewechselt hat, sah dadurch für dieselbe Größe zwei verschiedene Zahlen: Cockpit → Jahr und die HA-Sensoren bewerteten die gesamte Ladehistorie mit dem aktuellen Arbeitspreis, der Komponenten-Hub mit den Preisen, die damals galten. An einer Anlage mit vier Tarifstufen (40 → 32 → 34 → 31,5 ct) waren das 41,10 € Unterschied bei identischer kWh-Basis. Insgesamt gab es vier verschiedene Preisformen für einen Wert; zwei Sichten nahmen zusätzlich den allgemeinen Tarif statt eines gepflegten Wallbox-Tarifs. Jetzt bewertet jede Sicht die Ladung eines Monats mit dem Tarif dieses Monats, inklusive abgerechnetem Durchschnitt bei dynamischen Tarifen.

⚠ Vier HA-Sensoren springen dadurch einmalig — e_auto_ersparnis_vs_benzin_euro, netto_ertrag_euro, roi_prozent und amortisation_jahre. In der Langzeitstatistik ist das ein Sprung an einem Tag, kein Datenverlust. ⚠ Wer seinen Tarif nie gewechselt hat, sieht keine einzige veränderte Zahl — der Durchschnitt eines einzigen Tarifs ist dieser Tarif.
Bei evcc-Setups fehlten in den Aussichten die Netz-Stromkosten des Autos vollständig. Liegt die Ladung an der Wallbox statt am Fahrzeug — der Normalfall bei evcc —, fand Auswertungen → Aussichten als einzige Sicht gar keine Ladedaten: sie suchte nur an der Fahrzeug-Investition. Folge: Die ausgewiesene historische Ersparnis war um die kompletten Netzstromkosten zu hoch, und die Prognose rechnete mangels Datenlage mit geratenen 50 % Netzanteil. An einer echten Anlage gemessen (März–Juli 2026, ausschließlich Sensordaten): 0 statt 126 kWh Netzladung und 0 statt 620 kWh PV-Ladung. Diese Sicht zieht jetzt dieselbe Ladung heran wie Cockpit, Komponenten-Hub und HA-Export.
Derselbe Ladevorgang konnte im Tagesverlauf zweimal auftauchen. Messen Wallbox und E-Auto beide mit einem eigenen kWh-Zähler und ist das Fahrzeug der Wallbox nicht ausdrücklich zugeordnet, zählte eedc die Ladung doppelt. Behoben wurde das in zwei Schritten desselben Release — zuerst für die Leistungsmessung, dann für die Zählermessung; jetzt gilt in allen Pfaden dieselbe Regel: Trägt eine Wallbox die Ladeenergie, ist sie die Quelle. ⚠ Bereits gespeicherte Tage bleiben unverändert. Der Daten-Checker meldet sie jetzt und bietet „Zeitraum neu aggregieren” an — bewusst als Knopf und nicht als automatischer Lauf beim Start, weil die Reparatur vorhandene Tageswerte überschreibt.
Eine Einspeisevergütung von 0 ct wurde an drei Stellen still durch 8,2 ct ersetzt. Wer bewusst 0 gepflegt hatte (unvergütete Einspeisung), sah in Cockpit → Monat beim Vorjahresvergleich und im T-Konto je Investition sowie in der Wirtschaftlichkeit je Komponente einen Erlös, den es nicht gab — während Jahresbericht, Aussichten und HA-Export korrekt mit 0 rechneten. Ursache war eine Fallback-Prüfung, die eine gepflegte Null nicht von „nichts eingetragen” unterscheiden konnte. Alle Sichten nennen jetzt dieselbe Zahl.
Der MQTT-Export meldet keinen Erfolg mehr, wenn er gescheitert ist. Wer den Sensor-Export einrichtete, ohne einen Monat abgeschlossen zu haben, bekam „0 von 0 Sensoren publiziert” mit grünem Häkchen — und daneben die Zusage, die Sensoren erschienen automatisch in Home Assistant. Das Backend hatte den Grund korrekt genannt (Keine Monatsdaten vorhanden), die Oberfläche hat ihn verschluckt und den Fehlschlag als Ergebnis dargestellt. Jetzt steht der Grund da, in Rot. Dazu erklärt sich die leere Sensorliste selbst: alle Export-Sensoren werden aus abgeschlossenen Monatsdaten gerechnet, Live- und Tageswerte genügen dafür nicht. Gemeldet von Phir0n im simon42-Forum.
Der Deye/Solarman-Import holt endlich Daten (#349). Anmeldung, Server-Region und Header stimmten seit v4.0.10 — der eigentliche Datenabruf wurde von der Hersteller-API danach trotzdem mit 2101006 invalid param abgewiesen. Ursache: eedc fragte den Zeitraum für Monatsdaten mit einem Tagesdatum ab (2025-01-01 bis 2025-06-28), die Solarman-Schnittstelle verlangt dort aber einen Monatsstempel (2025-01 bis 2025-06). Der Melder hat das an zwei Anlagen (Sofar 2200 und 1100) gegengemessen, inklusive einer Kontrollprobe, die den Fehler reproduziert. ⚠ Der Provider bleibt vorerst als nicht mit echten Geräten getestet gekennzeichnet, bis ein vollständiger Import beim Anwender durchgelaufen ist.
Die Prognose rechnet den Akku nicht mehr weg. Seit v4.0.9 begrenzt eedc das SOLL an der Wechselrichter-Leistung — richtig bei überbelegten Anlagen, aber es galt bisher auch dann, wenn ein DC-gekoppelter Speicher hinter demselben Erzeuger hängt. Genau dort ist der Überschuss aber nicht verloren: er läuft gleichstromseitig in den Akku, ohne je durch den Wechselrichter zu müssen. Betroffen war vor allem der Normalfall beim Balkonkraftwerk mit Speicher (etwa 2 kWp Module an 800 W mit Akku), wo die Kappung täglich die Mittagsspitze traf, und jeder Hybrid-Wechselrichter am Dach. Folge: ein zu niedriges SOLL, eine zu hohe Performance Ratio und ein SOLL/IST-Vergleich, der besser aussah als die Anlage ist. Die Kappung setzt jetzt aus, wo ein DC-gekoppelter Speicher am Träger der Grenze hängt; bei AC-Kopplung bleibt sie, denn dort läuft die Energie tatsächlich durch den Wechselrichter. ⚠ Damit bewegt das Feld „Kopplung” erstmals eine Zahl — bis dahin war es rein beschreibend. Die Wirkung bleibt auf SOLL-Werte beschränkt; Energiebilanz, Eigenverbrauch und Wirtschaftlichkeit sind unberührt.
Ein Balkonkraftwerk erscheint jetzt auch im String-Vergleich, in der Mehrjahres-Performance und im Jahresbericht. Wer nur ein Balkonkraftwerk hat, sah in Auswertungen → Prognose unter „SOLL/IST pro PV-String” und „Mehrjahres-Performance” die Meldung „Keine PV-Module gefunden” — ebenso blieb der String-Abschnitt im Jahresbericht-PDF leer. Mit v4.0.9 war nur der Jahresvergleich gegen PVGIS erweitert worden; die drei übrigen Sichten hängen an anderen Abfragen und filterten weiter hart auf den Typ pv-module. Sie fragen jetzt nach dem PV-Erzeuger, nicht nach dem Typ, und rechnen die Nennleistung über denselben Helfer wie die Prognose (beim Balkonkraftwerk aus Leistung je Modul × Anzahl). Ein zweiter Erfassungsweg entsteht dabei ausdrücklich nicht — das Balkonkraftwerk bleibt eine Investition, seine Erzeugung zählt weiterhin genau einmal, und die ROI-Sicht ist unverändert. (Discussion #366; der Melder hatte den Rest nach dem Schließen von #367 gemeldet.)
Der Community-Vergleich bekam für reine Balkonkraftwerk-Anlagen erfundene Stammdaten. Neigung und Ausrichtung wurden ausschließlich aus Investitionen vom Typ pv-module gemittelt — gab es keine, meldete eedc dem Community-Server ersatzweise 30° und „Süd”, obwohl beides im Balkonkraftwerk-Formular gepflegt ist. Der Server rechnet nichts nach, die Anlage wurde also still gegen die falsche Vergleichsgruppe gemessen. Jetzt zählen beide Erzeuger-Typen, und die Werte werden auch dann gefunden, wenn sie aus einem Import nur im Detail-Feld stehen. Bestehende Einträge korrigieren sich beim nächsten vollständigen Teilen.
Ost- und West-Anlagen bekommen die richtige Prognose statt einer Süd-Prognose. Wurde die Ausrichtung eines Strings nur als Text geführt („Ost”, „West”, „Südwest” …) und nicht zusätzlich als Gradwert, hat eedc sie beim PVGIS-Abruf falsch übersetzt: 11 von 16 Himmelsrichtungen kamen falsch heraus — Ost, West und alle vier Zwischenrichtungen landeten auf Süd, Nord auf Ost. Betroffen waren vor allem ältere Bestände und JSON-Importe; wer seine Komponenten im aktuellen Formular gespeichert hat, hatte den Gradwert hinterlegt und war nicht betroffen. Die Folge war eine deutlich zu hohe SOLL-Prognose — eine Ost-Anlage wurde an einer Süd-Erwartung gemessen und sah dauerhaft schlecht aus. Betroffene Prognosen werden durch die neue Aktualitätsprüfung automatisch nachgezogen.
Ein PV-Zähler für die ganze Anlage reicht jetzt auch für Tages- und Stundenwerte. Wer seine PV über den Anlagen-Zählerstand pflegt (Anlage (Basis) → PV-Erzeugung Zählerstand (kWh)) — typisch bei einem Wechselrichter, der nur eine Summe über mehrere Ausrichtungen liefert —, hatte bisher korrekte Monatswerte und in Cockpit → Tag gar keine PV: die Tagesebene entstand ausschließlich aus Zählern je Erzeuger. Der Anlagen-Zählerstand versorgt jetzt Monat, Tag und Stunde als Summe der ganzen Anlage. Damit füllen sich Tagesbilanz, Eigenverbrauch, spezifischer Ertrag, Performance Ratio, CO₂ und der Stundenverlauf. Alles rückwirkend, ohne Zutun — die Werte werden aus der bereits vorhandenen Zähler-Historie gebildet, sobald ein Tag neu aggregiert wird. (Forum-Meldung.)

⚠ Was der Anlagen-Zählerstand nicht kann, ist die Aufschlüsselung je Erzeuger — dafür braucht jeder String seinen eigenen Zähler. Und dann brauchen ihn alle: Sobald ein einziger Erzeuger selbst misst, zählt für Tag und Stunde nur noch, was je Erzeuger gemessen ist, und der Anlagenwert ist dort aus. Sonst stünde die Anlagensumme neben ihren eigenen Bestandteilen und alles würde doppelt gezählt. Entweder alle oder keiner — die Monatswerte bleiben in jedem Fall vollständig.

⚠ Die Ausrichtungen dafür zu einer Investition zusammenzufassen, wäre der falsche Weg. eedc rechnet Prognose und SOLL je Ausrichtung (Neigung + Himmelsrichtung); eine zusammengelegte Anlage bekäme einen systematisch falschen Tagesgang — auch in den Prognose-Sensoren für Home Assistant.
Im Börsenpreis-Block war „über dem Durchschnitt” von „mittel” kaum zu unterscheiden. Die drei Preisstufen waren zwei Lila-Töne und ein Grün — die beiden Lila unterschieden sich nur in der Helligkeit und standen bei 1,76 bzw. 1,61 Kontrast zueinander, in der kleinen Legende erst recht nicht auseinanderzuhalten. Über die Helligkeit allein war die Trennung nicht herstellbar: Solange die mittlere Stufe die Rollenfarbe behält, sind die geforderten 3:1 rechnerisch unerreichbar (15 Kandidaten durchgerechnet, bester Wert 2,35). Die Unterscheidung läuft deshalb jetzt über den Farbton: grün unter der Günstig-Schwelle, lila dazwischen, rot über dem Tagesdurchschnitt. An den Zahlen ändert sich nichts. (Gemeldet von Radiocarbonat im simon42-Forum.)
Die Anleitung für den HA-Integral-Helfer empfahl eine Methode, die die Nacht als Erzeugung verbucht. Wer sich für einen String nur einen kWh-Zähler aus einem Leistungssensor bauen kann, fand in der Hilfe die Integrationsmethode Trapez — ohne Begründung und ohne die Bedingung, unter der sie gilt. Home Assistant speichert aber keine Wiederholung gleicher Werte: Ein stillstehender Sensor erzeugt gar keinen Messpunkt, und die Trapezregel zieht über die Nachtlücke eine gerade Linie und schreibt Energie gut, die es nie gab (gemessen: rund 60 Wh pro Nacht, proportional zum ersten Morgenwert — bei gröberer Meldeschwelle des Wechselrichters entsprechend mehr). Die Hilfe empfiehlt jetzt die linke Riemann-Summe und nennt den Grund. ⚠ Wer den Helfer bereits mit Trapez angelegt hat, stellt die Methode in den Helfer-Optionen um; der Zählerstand läuft weiter, der bereits aufgelaufene Wert korrigiert sich nicht rückwirkend. (Eingewandt von dietmar1968 im simon42-Forum.)
Ein Tag ganz ohne PV-Zähler zeigt keine Zahlen mehr, die es nicht gibt. Hat eine Anlage weder je Erzeuger noch für die Anlage einen kumulativen Zähler, stand in Cockpit → Tag 0 kWh PV neben einer gemessenen Einspeisung, und daraus errechnete sich ein Eigenverbrauch von −25 kWh, eine Performance Ratio von 0 % („auffällig niedrig”) und eine negative CO₂-Einsparung — während im selben Block die Peak-Leistung aus dem Watt-Sensor korrekt stand. Erzeugung, Eigenverbrauch, spezifischer Ertrag, Performance Ratio, CO₂ und die SOLL-Erfüllung zeigen in dieser Lage jetzt „—”. Eine gemessene Null bleibt eine Null: Nacht, Schnee oder eine abgeschaltete Anlage sind ein gültiger Messwert und werden weiterhin als 0 angezeigt — unterschieden wird „nicht erfasst” von „nichts erzeugt”. (Forum-Meldung.)

[4.0.10] - 2026-08-06 — Jede Stunde trägt ihren eigenen Preis · jeder Tag sein eigenes Datum

Added

Die Börsenpreise von heute und morgen stehen als eigener Block auf Cockpit → Live. Bisher gab es sie dort nur als dünne, einfarbige Linie über dem Tagesverlauf — für heute, ohne jede Kennzeichnung, welche Stunde günstig ist. Wer wissen wollte, wann morgen der günstige Block liegt, musste zu seinem Stromanbieter wechseln. Der neue Block „Börsenpreis heute & morgen” zeigt beide Tage auf einer durchgehenden Zeitachse als Stufenlinie (ein Börsenpreis gilt eine ganze Stunde — eine schräge Verbindungslinie behauptete Preise, die es nie gab). Die Linie ist nach Preisniveau abgestuft: grün unterhalb deiner Günstig-Schwelle, in der Strompreis-Farbe zwischen Schwelle und Tagesdurchschnitt, abgesetzt darüber; zusammenhängende günstige Stunden sind zusätzlich als Fläche hinterlegt. Darüber stehen drei Kennzahlen für heute — aktueller Preis, der Ø ohne die 3 teuersten Stunden und die Günstig-Schwelle mit der Anzahl der Stunden darunter. Es sind dieselben Zahlen, die auch die HA-Sensoren melden: Chart und Sensor lesen aus derselben Schicht, damit nicht zwei Stellen etwas Verschiedenes „günstig” nennen. (Community-Wunsch, zuletzt in einer Fassung mit ausdrücklichem Wunsch nach zwei Tagen auf einer Achse.)
- Jeder Tag trägt seine eigene Schwelle — Day-Ahead ist ein Tagesprodukt. Ein gemeinsamer Durchschnitt über beide Tage würde an einem teuren Tag keine einzige Stunde als günstig ausweisen und am billigen fast alle, und beides widerspräche den Sensoren derselben Anlage.
- Die Preise für morgen veröffentlicht die Auktion gegen 13 Uhr. Vorher zeigt der Block nur heute — und sagt, warum die zweite Hälfte fehlt, statt sie leer zu lassen.
- Der Block braucht keine zugeordneten Sensoren. Börsenpreise sind öffentliche Marktdaten; er erscheint deshalb auch dann, wenn Live sonst „Keine Live-Daten verfügbar” meldet. Gepflegte Anlagen-Koordinaten braucht er dennoch: Aus ihnen ergibt sich, welche Stunden Tag und welche Nacht sind.
- An den Zeitumstellungstagen hat ein Tag 23 bzw. 25 Stunden. Die fehlende Stunde bleibt eine Lücke in der Linie und wird unter dem Chart benannt — nicht mit dem Nachbarwert aufgefüllt.
- Angezeigt werden Börsenpreise, netto — ohne Steuern, Abgaben und Netzentgelte; das steht auch so unter dem Chart. eedc zeigt Preise und empfiehlt keine Handlung: Wann geladen oder pausiert wird, entscheidest du in deiner Automation.
Der Speicher-Block in Cockpit → Tag zeigt jetzt auch den Ladezustand. Dort standen bisher Ladung, Entladung, Wirkungsgrad und Vollzyklen — der Ladestand fehlte, obwohl er stündlich aufgezeichnet wird; erreichbar war er nur, indem man in der Stundenwerte-Tabelle die Spalte „SoC” einblendete. Die neue Kachel „Ladezustand” nennt den Stand am Ende des Tages und darunter die Spanne, zwischen der der Speicher an diesem Tag geschwungen ist (z. B. „64 %, Spanne 12–98 %”). Am laufenden Tag ist „Ende” die zuletzt aufgezeichnete Stunde — fehlende Stunden am Tagesrand werden nicht als Ladestand 0 % ausgegeben. Bewusst nur auf Tagesebene: Ein Ladestand ist ein Bestand und keine Summe, ein Monatsmittel daraus wäre eine Zahl ohne Aussage. Neu ist außerdem, dass der Speicher-Block schon dann erscheint, wenn an einem Tag keine Lade- oder Entladebewegung stattfand, ein Ladestand aber gemessen wurde. (Anregung aus dem Forum-Thread zu v4.0.0 — dietmar1968; Ladung und Entladung standen dort bereits, der Ladestand nicht.)
eedc kommt jetzt auch ohne Zugriff auf die Home-Assistant-Datenbank an die Langzeitstatistik. Wer eedc als eigenen Container neben Home Assistant betreibt — also ohne Add-on, verbunden über einen Long-Lived-Token —, hatte bisher keinen Weg zu den historischen Stunden- und Tageswerten: eedc kannte nur die Recorder-Datei (/config/home-assistant_v2.db) bzw. eine direkte Datenbank-Verbindung. Ohne eines von beidem entstanden Tageswerte ausschließlich aus eedcs eigenen 5-Minuten-Messungen, also ab dem Tag der Installation vorwärts; Cockpit → Tag blieb für die Vergangenheit leer, der Voll-Backfill war gesperrt, und die Reparatur-Werkbank scheiterte an „Lücken aus HA-LTS nachfüllen”. Der bisher empfohlene Ausweg — das HA-Konfigurationsverzeichnis lesend einhängen — setzt voraus, dass eedc auf demselben Host läuft und Home Assistant gerade läuft, und hilft bei MariaDB/MySQL als Recorder gar nicht. eedc liest die Statistik jetzt alternativ über die HA-eigene Schnittstelle, mit derselben Verbindung, über die auch die aktuellen Sensorwerte kommen — ohne zusätzliche Einrichtung. Wo eine Datenbank erreichbar ist, wird sie weiterhin bevorzugt (schneller, ohne Netz); der neue Weg springt ein, wo es sie nicht gibt. Es ist dieselbe Quelle über ein anderes Kabel: die Werte stammen aus derselben Statistik, und wie eedc daraus Stunden, Tage und Monate bildet, ist unverändert. Am produktiven Bestand wurden beide Wege parallel gemessen — 27 Monatswerte und 26 Monatsanfangswerte, kein einziger Unterschied. (Betrifft Monatswerte, Voll-Backfill, Tagesaggregation, die Reparatur-Werkbank und den Daten-Checker gleichermaßen.)

⚠ Was auch dieser Weg nicht kann: weiter zurückreichen als Home Assistant selbst. Die Langzeitstatistik beginnt mit der Einrichtung des jeweiligen Sensors — für die Zeit davor bleibt der Datei-Import (CSV/Excel) die Antwort.
Der Daten-Checker meldet, wenn eedc und Home Assistant mit verschiedenen Zeitzonen rechnen. Ein Docker-Container läuft ohne die Umgebungsvariable TZ auf UTC — unabhängig davon, wie der Rechner eingestellt ist. eedc bildet Tage aber nach seiner eigenen Systemzeit: Der Tag endet dann faktisch um 22:00 Ortszeit, und die letzten beiden Stunden werden dem Folgetag zugerechnet. Betroffen sind alle Tageswerte gleichermaßen — Cockpit → Tag, Energieprofil, Tagesabschlüsse. Sichtbar war davon bisher nichts: Die Zahlen sahen plausibel aus, sie standen nur am falschen Tag. Der neue Befund vergleicht den Zeitabstand beider Systeme zu UTC, nicht den Namen der Zeitzone — Wien, Zürich und Amsterdam gehen wie Berlin, und dort wäre eine Meldung falsch. Der Hinweis nennt den Weg passend zur Betriebsart: Als Add-on übernimmt eedc die Zeitzone beim Start von Home Assistant (einmal neu starten genügt), im eigenen Container ist TZ zu setzen. In der mitgelieferten docker-compose.yml steht sie bereits; wer docker run oder eine eigene Compose-Datei nutzt, gibt sie selbst an — das steht jetzt auch so in der Installationsanleitung. Ohne HA-Verbindung schweigt die Prüfung, weil es dann nichts zu vergleichen und nichts zu tun gäbe.

⚠ Was der Befund nicht leistet: Er beschreibt den Zustand von jetzt und korrigiert keine bereits gespeicherten Tage. Die lassen sich nach dem Neustart über Einstellungen → Datenverwaltung neu berechnen.
Drei neue Börsenpreis-Sensoren: der aktuelle Preis, der optimierte Ø und ihr Abstand zueinander. Bisher lieferte der Export nur die fertige Zerlegung — den Rang der laufenden Stunde und die Anzahl günstiger Stunden. Der Preis selbst und die Bezugsgröße der Günstig-Schwelle verließen eedc nie, obwohl beide intern längst berechnet wurden. Die Frage „liegt der Strom gerade über oder unter dem optimierten Tagesdurchschnitt?” — die Grundlage einer Nicht-Entlade-Strategie — war damit nicht beantwortbar. Neu sind eedc_preis_aktuell_cent, eedc_preis_optimierter_durchschnitt_cent (Ø der Tagespreise ohne die 3 teuersten Stunden) und eedc_preis_abstand_prozent: negativ = billiger als der Ø, positiv = teurer. Damit ist „nur entladen, wenn der Strom gerade teurer ist als der Tagesschnitt” eine Bedingung auf einen Zahlenwert — ohne Template. Bezugsgröße des Abstands ist der Betrag des Ø, damit das Vorzeichen auch bei negativen Börsenpreisen die richtige Aussage macht. eedc liefert weiterhin nur Trigger-Werte, keine Lade-/Entlade-Strategie.
Das Rang-Profil trägt jetzt Rohmaterial statt nur einer fertigen Bewertung. Das Attribut rang_profil am Börsenpreis-Rang-Sensor führte je Stunde nur 1–5 oder 99 — der Stundenpreis stand nicht darin. Damit ließ sich in Home Assistant weder eine eigene Schwelle noch ein eigenes Zeitfenster auswerten, obwohl die Sensor-Referenz genau das anbot. Je Stunde stehen jetzt zusätzlich preis_cent und unter_schwelle, und der optimierte Ø reist als Attribut optimierter_durchschnitt_cent mit. Bestehende Attribute sind unverändert — Templates, die stunde/rang lesen, laufen weiter.

Changed

⚠ „Günstige Stunden” ist nicht mehr bei 5 je Fenster gedeckelt — die drei Zähler-Sensoren melden ab jetzt höhere Werte. eedc_preis_guenstige_stunden_anzahl, …_tag und …_nacht zählten bisher nur Stunden mit einem Rang 1–5. Lagen sieben Nachtstunden unter der Günstig-Schwelle, meldete der Sensor trotzdem fünf. Als Anzeige war das stimmig, als Divisor in einer Automation nicht: eine daraus gerechnete Ladeleistung fiel zu hoch aus. Gezählt wird jetzt, was der Name sagt — jede Stunde unter der Schwelle. Der Rang (eedc_preis_rang) bleibt unverändert bei 1–5/99, denn er beantwortet eine andere Frage („eine der fünf billigsten ihres Fensters?”). Wer diese drei Sensoren in Automationen verwendet, prüft seine Schwellen einmal nach — der Verlauf in Home Assistant zeigt an der Umstellung einen einmaligen Sprung nach oben.
Was 0 % bei der Günstig-Schwelle bedeutet, steht jetzt richtig da. Oberfläche und Handbuch sagten „0 % schaltet die Schwelle ab — dann zählen wieder die 5 günstigsten Stunden je Fenster”. Das hat eedc nie getan: Bei 0 % liegt die Schwelle genau auf dem optimierten Ø, günstig ist also alles darunter. Der bisherige Top-5-Deckel hat den Unterschied verdeckt; mit dem Wegfall des Deckels wird er sichtbar. Reine Text-Korrektur — am Rechenweg ändert sich dadurch nichts.
Cockpit → Monat geht auf dem laufenden Monat auf, solange kein Abschluss offen ist. Die Sicht wählte bisher immer den neuesten Monat vor, für den es eine Zählerzeile gibt — bei gepflegten Abschlüssen also den Vormonat, während Cockpit → Tag („neuester Tag mit Daten”) und Cockpit → Jahr längst auf dem Aktuellen aufgehen. Wer sehen wollte, wie der laufende Monat steht, musste ihn jedes Mal selbst anklicken. Neu ist die Unterscheidung, nicht ein neuer Automatismus: Ist noch ein Monatsabschluss offen, bleibt es beim bisherigen Verhalten — die Sicht führt dann dorthin, wo etwas zu tun ist, samt „Abschluss starten” daneben. Ein Sprung in einen Monat nach dem laufenden findet nie statt. (coolxmad, #353)
- Mitkorrigiert: „offen” heißt jetzt auch mitten in der Historie offen. Ob noch etwas aussteht, beantwortete die Monats-Sicht bisher mit „ist der jüngste gepflegte Monat älter als der Vormonat?” — ein fehlender Monat mitten in einer sonst lückenlosen Reihe fiel damit durch. Der Hinweis in der Status-Fußzeile hat ihn längst gemeldet; die Monats-Sicht rechnete daran vorbei und zeigte den Knopf „Abschluss starten” nicht. Beide leiten sich jetzt aus derselben Vollständigkeits-Prüfung ab. Sichtbar wird das nur bei einer Lücke: dort erscheint der Knopf, und die Sicht öffnet weiterhin auf dem jüngsten gepflegten Monat statt auf dem laufenden.
Fünf Funktionen, die für Container-Nutzer still abgeschaltet waren, sind wieder da. Der Zugriff auf aktuelle HA-Sensorwerte war fest an das Add-on gebunden und meldete sich bei einer Token-Verbindung wortlos als „nicht verfügbar” — obwohl die Verbindung stand. Betroffen waren der Live-Tagesverlauf, die Solcast-Anbindung, die Prognose-Erkennung, die Speicher-Ladestand-Historie und der Daten-Checker-Test auf vertauschte Leistungs- und Energie-Sensoren (kW statt kWh). Gerade der letzte schwieg ausgerechnet bei den Anwendern, die diese Verwechslung am ehesten machen: Er nannte als Grund „HA nicht erreichbar” — erreichbar war sie, nur der eingeschlagene Weg war der falsche.

⚠ Nachträglich richtiggestellt (August 2026): „Sind wieder da” traf auf eine der fünf Funktionen zu (den Daten-Checker-Test auf vertauschte kW-/kWh-Sensoren). Bei den übrigen vier — Live-Tagesverlauf, Solcast-Anbindung, Prognose-Erkennung, Speicher-Ladestand-Historie — wurde die Verbindung darunter hergestellt, die vorgeschaltete Abfrage nach der Betriebsart aber nicht nachgezogen; sie kamen deshalb nie bei ihr an. Unauffällig war das, weil im Add-on-Betrieb — dem Regelfall — beide Wege dasselbe liefern. Eingelöst ist die Aussage mit dem Abschnitt „Es zählt die Verbindung, nicht die Betriebsart”.

Fixed

Die Börsenpreise der Nachtstunden gehörten dem falschen Tag. eedc holt die EPEX-Day-Ahead-Preise stundenweise ab — und hat dabei einen Tag von Mitternacht bis Mitternacht UTC angefragt, die Antwort aber nach deiner lokalen Uhr einsortiert. In Mitteleuropa passt das nicht zusammen: Die Stunden 0 und 1 des angefragten Tages fielen aus dem Fenster heraus (in der Winterzeit die Stunde 0), und an ihrer Stelle standen die Preise des Folgetages. Das Ergebnis hatte trotzdem 24 Einträge und sah damit vollständig aus. Sichtbar war es an der Preislinie im Live-Tagesverlauf: Sie begann erst um 02:00 Uhr, solange die Preise für morgen noch nicht veröffentlicht waren (das geschieht gegen 13 Uhr) — und danach zeigte sie für die Nacht die Zahlen des nächsten Tages. Betroffen war alles, was auf dieser Preisreihe steht: die HA-Sensoren zu Rang, günstigen Stunden, aktuellem Preis und Abstand zum Durchschnitt, und die stündlich mitgeschriebene Spalte, aus der später Tagesmittel und der effektive Speicher-Ladepreis gebildet werden. Ein Tag ist jetzt der Tag der Marktzone — Fenster und Stundenzuordnung kommen aus derselben Uhr, unabhängig davon, in welcher Zeitzone dein Container läuft. Auch die beiden Zeitumstellungs-Tage stimmen: Der März-Tag hat 23 Stundenpreise, der Oktober-Tag behält die erste seiner beiden Zwei-Uhr-Stunden statt sie still überschreiben zu lassen.

⚠ Was sich dadurch an deinen Werten ändert: Die Sensoren eedc_preis_rang, eedc_preis_guenstige_stunden_*, eedc_preis_aktuell_cent und eedc_preis_abstand_prozent rechnen ab jetzt mit den richtigen Nachtpreisen. Weil Durchschnitt und Günstig-Schwelle über alle Stunden des Tages gebildet werden, können sich dadurch auch Ränge einzelner Tagesstunden verschieben. Wer nachts zwischen 0 und 2 Uhr auf den aktuellen Preis reagiert, bekommt jetzt den Preis der Stunde, in der er sich befindet. Bereits gespeicherte Tage bleiben, wie sie sind — sie tragen für die Nachtstunden weiterhin keinen oder den falschen Börsenpreis. Wer sie berichtigen möchte, rechnet die betroffenen Tage unter Einstellungen → Daten mit „Mehrere Tage neu aggregieren” neu; automatisch angefasst wird nichts.

⚠ Warum kein Test das gefunden hat: Alle vorhandenen Prüfungen ersetzten den Preisabruf durch ein selbst gebautes, immer vollständiges 24-Stunden-Ergebnis — die Zuordnung von Zeitfenster zu Stunde wurde damit nie geprüft. Dieselbe Lehre wie beim Solarman-Import: Ein nachgebauter Fremdsystem-Aufruf ist eine Behauptung über fremde Technik. Der neue Test antwortet deshalb wie der echte Server auf das tatsächlich gesendete Zeitfenster, und im Test steht, woher diese Antwortform stammt.
Zwischen Mitternacht und 2 Uhr zeigten mehrere Ansichten den falschen Tag. Gemeldet für den Prognosen-Vergleich: dort standen nachts zwei Kalendertage mit identischen Werten in allen drei Quellenspalten (OpenMeteo, eedc, Solcast) — die Zeile für „heute” trug das Datum von gestern, aber die Zahlen von heute, und der heutige Tag erschien daneben gleich noch einmal. Ursache war ein Datum, das der Browser in UTC statt in deiner Zeitzone gebildet hat: Zwischen 00:00 und 02:00 Ortszeit (im Winter 00:00–01:00) ist das UTC-Datum noch der Vortag, während eedc im Hintergrund bereits mit dem neuen Tag rechnet. Tagsüber stimmten beide überein — deshalb ist es lange niemandem aufgefallen, und deshalb war es aus der App heraus schwer nachzuvollziehen. Betroffen war mehr als die gemeldete Ansicht: Der Knopf Tag neu berechnen hat nachts gestern neu berechnet, die Tagesleiste markierte den Vortag als „heute”, Cockpit → Tag öffnete auf gestern, eine zum heutigen Tag stillgelegte Komponente galt noch als aktiv, und ein heute beginnender Stromtarif galt noch nicht. Alle zehn Stellen rechnen jetzt mit der lokalen Uhr — über eine gemeinsame Funktion, die ein neuer Prüflauf im Entwicklungs-Werkzeug baumweit durchsetzt, damit die nächste Stelle nicht ungebremst nachkommt. Gefunden durch eine Anwender-Meldung mit Screenshots um 00:40 und 01:15 Uhr.
Der Deye/Solarman-Cloud-Import funktioniert jetzt tatsächlich — die Korrekturen aus v4.0.9 liefen ins Leere. OliS2811 hatte gemeldet, dass der Import nicht einzurichten war; v4.0.9 hat daraufhin zwei belegte Ursachen behoben (die fehlende Auswahl der Server-Region — ein europäisches Konto existiert auf der chinesischen Wolke schlicht nicht — und das fehlende bearer-Präfix im Autorisierungs-Kopf). Beide Korrekturen waren richtig, und der Import scheiterte trotzdem weiter. Der Melder hat daraufhin denselben Anmelde-Aufruf mit eigenen Mitteln gegen die Solarman-Schnittstelle gefahren und dessen Antwort danebengelegt: Die Anmeldung gelingt, eedc findet den zurückgegebenen Zugriffsschlüssel nur nicht. eedc suchte ihn eine Ebene zu tief in der Antwort — dort steht er nicht, er liegt direkt neben der Erfolgsmeldung. Das Ergebnis war ein Zugriffsschlüssel, der immer leer blieb, und die irreführende Meldung „Antwort enthielt keinen access_token”. Damit konnten weder der Regions- noch der bearer-Fix je greifen: Es gab nie einen Schlüssel, den man hätte mitsenden können. eedc liest die Antwort jetzt an der belegten Stelle — und zusätzlich weiterhin an der alten, damit eine abweichende Verpackung den Import nicht erneut scheitern lässt. Die Anmelde-Anfrage entspricht außerdem in allen Punkten der, von der nachgewiesen ist, dass sie durchgeht (ergänzter language-Parameter). (#349, OliS2811 — Folgemeldung nach v4.0.9)

⚠ Warum das durch alle Tests kam, und was sich daran ändert: Die automatischen Prüfungen zu #349 waren grün — sie prüften gegen eine selbst gebaute Nachbildung der Solarman-Antwort, in der der Schlüssel genau dort lag, wo eedc ihn vermutete. Damit prüfte eedc die eigene Annahme gegen sich selbst. Die Nachbildung folgt jetzt der belegten echten Antwortform, und im Test steht, woher diese Form stammt. Für alle Cloud-Anbindungen, die mangels Testgerät als ungetestet gekennzeichnet sind, gilt daraus die Lehre: Eine nachgebaute Hersteller-Antwort ist eine Behauptung über fremde Technik und braucht eine Quelle.
Eine leere Tagessicht sagt jetzt, warum sie leer ist — und bietet den Knopf nur an, wo er wirklich etwas holt. In Cockpit → Tag stand für einen Tag ohne Werte ein einziger Satz: „Für diesen Tag liegen keine Daten vor. Wähle einen Tag mit Messwerten.” Kein Grund, kein Weg nach vorn — und die Aufforderung war für den häufigsten Fall auch noch irreführend, weil sie klingt, als hätte man den falschen Tag erwischt. Erreichbar ist der Zustand nämlich nicht nur an einzelnen Lücken-Tagen: Die Datumsauswahl gibt ab dem ersten Tag des ältesten bekannten Monats frei, die Tageswerte beginnen aber oft später — an einer produktiven Anlage nachgemessen sind das 30 Kalendertage, die sich anwählen lassen und garantiert leer bleiben. Wer eedc über Monatsabschlüsse pflegt und gar keine Tagesebene hat, sieht den Satz an jedem Tag. Die Sicht nennt jetzt die Lage beim Namen — und zwar in der Sprache des jeweiligen Falls: der Tag liegt vor der Inbetriebnahme der Anlage · an ihm war kein kWh-Zähler zugeordnet · der Tag wurde nie aggregiert, Home Assistant hat die Werte aber noch · auch Home Assistant hat für ihn nichts aufgezeichnet · der Tag läuft noch. Der Reparatur-Knopf „Tag nachrechnen” steht direkt daneben — aber nur im dritten Fall, dem einzigen, in dem es etwas zu holen gibt. Liegt der Tag vor der Inbetriebnahme oder hat Home Assistant selbst nichts, gibt es nichts nachzuaggregieren; ein Knopf verspräche dort eine Wirkung, die es nicht gibt, und genau das ist der Fehler, den v4.0.7 an der Reparatur-Werkbank behoben hat. Statt eines toten Knopfes sagt der Text die Absage offen und nennt, wo sie sich beheben lässt (etwa die fehlende Zuordnung unter Einstellungen → Datenquellen). Der Grund kommt dabei aus eedcs Rechenteil, nicht aus einer zweiten Beurteilung in der Oberfläche — sonst stünden über kurz oder lang zwei verschiedene Erklärungen für denselben Tag nebeneinander. (Forum-Thread zu v4.0.0 — kaba-kakao; die Auswahl-Hälfte desselben Befunds steht oben)

Zwei Nebenwirkungen derselben Arbeit: Sind in Cockpit → Tag alle Anzeigen geparkt, stand dort bisher ebenfalls „Keine Daten für diesen Tag vorhanden” — das Gegenteil der Lage, denn die Werte sind da und liegen im Papierkorb; der Satz sagt das jetzt. Und die Rückmeldung nach einer Tages- oder Zeitraum-Reparatur nennt das Datum in deutscher Schreibweise (28.07.2026 statt 2026-07-28).
Der Daten-Checker behauptet keine Tageszusammenfassung mehr, die es nicht gibt. Wer eedc frisch einrichtet, bekam in der ersten Stunde — und dauerhaft, wenn die kWh-Zähler nicht zugeordnet sind — einen Hinweis zu lesen, der wörtlich lautete: „die TagesZusammenfassung vom ? wurde aber noch aus ‘unbekannt’ geschrieben”. Gemeint war ein ganz anderer Zustand: der Hinweis ist dafür gedacht, dass bereits aggregierte Tage noch aus einer älteren Quelle stammen und beim nächsten Lauf auf HA-Statistics umgestellt werden. Existiert dagegen überhaupt keine aggregierte Tageszeile, passte der Satz nicht — er schickte den Anwender auf die Suche nach einer falschen Quelle, während in Wahrheit schlicht noch nichts da war. Für diesen Fall gibt es jetzt eine eigene Meldung, „Noch keine Tageswerte aggregiert”, und sie sagt, was zu tun ist: abwarten (die Aggregation läuft stündlich), die kWh-Zeilen unter Einstellungen → Datenquellen belegen — nicht nur die Watt-Zeilen —, oder zurückliegende Tage über „Lücken aus HA-LTS nachfüllen” in der Reparatur-Werkbank holen. Die beiden Nachbarzweige sind unberührt: wer schon Tage aggregiert hat, liest weiterhin die Quelle samt echtem Datum, und im Standalone-Betrieb ohne Zugriff auf die HA-Recorder-Datenbank bleibt es beim bisherigen Hinweis — dessen Verdrängung wäre der schlimmere Fehler gewesen, denn er ist dort die einzige Meldung, die die Lage beschreibt. (gefunden beim Messen einer Fehlermeldung aus dem Forum; der Befund selbst betrifft den HA-Add-on-Betrieb)
Die Monatsauswahl in Cockpit → Monat kennt jetzt dieselben Monate wie die Sicht daneben. kaba-kakao hat im Forum ein Bild geschickt, auf dem der Widerspruch in einem Blick steht: die Sicht zeigt „Jul 2026 · abgeschlossen” mit vollständigen Werten — 1.097 kWh PV, 106 % SOLL, 80 % Autarkie, 241,05 € Monatsergebnis —, während links in der Monatsleiste als einziger Eintrag „Aug · läuft” steht. Weder der Juli noch die Historie, die er seit 2021 eingepflegt hatte, war dort auswählbar. Der angezeigte Monat fehlte also in seiner eigenen Auswahlliste. Die Ursache war nicht fehlende Historie, sondern zwei Quellen für eine Auswahl: Die Leiste holte ihre Monate aus der lokalen Tagesebene (den Tageszusammenfassungen, die eedc aus Sensorwerten bildet), die Sicht dagegen aus den Monatsdaten. Wer eedc über Monatsabschlüsse oder Import pflegt — also der Standalone-Fall, für den eedc ausdrücklich gebaut ist —, hat auf der Tagesebene nichts stehen; die Leiste blieb dann leer und zeigte nur noch den laufenden Monat, den die Oberfläche ohnehin immer anhängt. Die Leiste liest jetzt beide Grundgesamtheiten und zeigt deren Vereinigung: jeden Monat mit Monatsdaten und jeden Monat, dessen einzige Spur die Tagesebene ist. Keine der beiden allein genügt — Cockpit → Jahr hatte genau denselben Fehler und brauchte für seine Heilung ebenfalls beide Hälften. Für bestehende Anlagen ändert sich keine Zahl, nur die Auswahl wird vollständig; wer bisher alle Monate sah, sieht dieselben. Nebenbei fällt damit auch der Umweg weg, ältere Monate über Auswertungen → Tabelle ansteuern zu müssen. (Forum-Thread zu v4.0.0 — kaba-kakao)

[4.0.9] - 2026-08-05 — Der laufende Monat zählt nur seine Tage · jede PV-Zahl nennt ihre Herkunft

Added

Die Kopplung eines Speichers ist jetzt eine Angabe, die man machen kann — und keine Folgerung mehr aus der Wechselrichter-Zuordnung. JayJay fragte im Forum zu v4.0.0: „Ich habe einen AC-gekoppelten Speicher … unter Komponenten/Speicher steht bei Kopplung DC-gekoppelt. Wo kann ich die Kopplung einstellen?” Die ehrliche Antwort war bis hierher: gar nicht. eedc leitete die Kopplung ausschließlich daraus ab, ob dem Speicher ein Wechselrichter zugeordnet ist — zugeordnet hieß DC, nicht zugeordnet hieß AC. Als Vorbelegung ist das richtig und trifft die meisten Anlagen; als Wahrheit ist es falsch, denn zwei ganz normale Bauformen fallen durch: ein AC-Speicher an einem Hybrid-Wechselrichter (fachlich üblich — er wurde zwangsweise als DC geführt, sobald man ihn zuordnete) und ein DC-Speicher ohne erfassten Wechselrichter (er galt als AC). In der Investitionspflege steht deshalb jetzt das Feld „Kopplung” mit den Möglichkeiten Automatisch (aus der Zuordnung) · AC-gekoppelt · DC-gekoppelt. Die Vorbelegung bleibt „Automatisch”, und sie sagt dazu, was sie ableitet („Ohne Angabe: DC-gekoppelt — abgeleitet aus der Wechselrichter-Zuordnung”); im Komponenten-Hub steht die Kopplung als eigene Zeile neben der Zuordnung, bei ungepflegtem Feld mit demselben Vermerk. An keiner Zahl ändert sich dadurch etwas — das ist Absicht: die Zuordnung entscheidet weiterhin allein darüber, ob die Wirtschaftlichkeit des Speichers als Teil des PV-Systems oder eigenständig gerechnet wird, und die Ersparnis selbst rechnet eedc für beide Bauformen identisch. Wer also seinen AC-Speicher am Hybrid-Wechselrichter korrekt einträgt, verliert dadurch nicht dessen Zugehörigkeit zum PV-System. Was sich ändert, ist die Aussage: In der ROI-Antwort stand bisher für jeden zugeordneten Speicher hart „DC-gekoppelt”, und für jeden nicht zugeordneten hieß der Hinweis wörtlich „AC-gekoppelter Speicher” — beides Behauptungen über eine Eigenschaft, die nie erhoben worden war. Der Hinweis beschreibt jetzt, was er wirklich meint (dass dieser Speicher eigenständig gerechnet wird), und die Kopplung steht daneben in ihrem eigenen Feld. Wozu die Angabe gut ist, sobald man sie hat: Sie sagt, wo Ladung und Entladung gemessen werden. Genau das war bisher nirgends festgelegt — die Feldbeschreibung sagte nur „Gesamte in den Speicher geladene Energie”, womit ein Zähler direkt an der Batterie (DC) und einer hinter dem Batterie-Wechselrichter (AC) beide korrekt waren und trotzdem verschiedene Zahlen lieferten; dazwischen liegt der Wandlungsverlust. Wer Ladung von der einen und Entladung von der anderen Seite erfasst, bekommt einen Wirkungsgrad, der die Messstelle beschreibt und nicht den Speicher — bei Anker-Cloud-Werten ist genau das aufgefallen. Die Feldbeschreibungen von Ladung und Entladung nennen die Messstelle jetzt und verlangen ausdrücklich dieselbe Seite für beide. (#351, aus dem Forum-Thread zu v4.0.0 — JayJay · N-60)
Welcher String, welches Balkonkraftwerk hat heute was gebracht? Das steht jetzt da — tagesgenau. Wer mehrere Dachflächen oder mehrere Balkonkraftwerke betreibt, konnte deren Erträge bisher nur monats- oder jahresweise trennen (Prognosen-Sicht „SOLL/IST pro PV-String”, Komponenten-Hub, PDF-Jahresbericht). Für einen einzelnen Tag gab es die Aufteilung nirgends — obwohl eedc die Werte je Gerät stündlich mitschreibt, sobald jedes Gerät einen eigenen Ertragssensor hat. Rainer (rapahl) hat genau danach gefragt: „Ein oder mehr BKW’s, verschiedene Solar-/Dachsegmente … wie kann ich sehen, welchen Ertrag mein BKW im Vorgarten, mein Süd-Ost-Dach oder mein Nord-West-Dach täglich gebracht hat?” Zwei Sichten antworten jetzt darauf. In Cockpit → Tag ist die PV-Fläche im Stundenverlauf in ihre Geräte aufgeteilt statt als ein Block gezeichnet, und die Stundenwerte-Tabelle bekommt je Gerät eine Spalte direkt hinter „PV”; die Stapelhöhe bleibt dabei exakt die Erzeugung — was die Geräte nicht abdecken, steht als „PV (übrige)” daneben, statt auf die Dächer verteilt zu werden. In Auswertungen → Tabelle → Energieprofile stehen die Geräte als eigene Spalten je Tag zur Auswahl (Spalten-Picker, Gruppe „Je Erzeuger”) — mit Summenzeile, Vorjahresvergleich und CSV-Export wie jede andere Spalte, also auch über einen ganzen Monat oder ein Jahr lesbar. Aufgeschlüsselt wird ab zwei Geräten: bei einem einzigen wäre die Gerätespalte die Anlagenspalte unter anderem Namen. Was hier bewusst nicht passiert, ist Verteilen. Auf Monatsebene füllt eedc fehlende Modulwerte notfalls nach kWp-Anteil auf und kennzeichnet das; auf Tagesebene gibt es das nicht — wer für ein Gerät keinen eigenen Sensor hat, bekommt dort keine Spalte, sondern den Hinweis, welches Gerät fehlt und wo man den Sensor zuordnet (Einstellungen → Datenquellen). Eine verteilte Tageszahl unter der Überschrift „Dach Süd” wäre eine Messung, die niemand gemessen hat. (#350, aus einer PN von rapahl)
Der Speicher bekommt seine eigene Jahres-Auswertung: Monatstabelle, Auslastung, Solar-Anteil und Netto-Nutzen. Bis hierher war der Speicher in Cockpit → Jahr vier Kacheln lang — Ladung, Entladung, Wirkungsgrad, Vollzyklen —, und wer wissen wollte, wann er gearbeitet hat und was er gebracht hat, musste die Monate einzeln durchklicken. Unter dem Speicher-Abschnitt steht jetzt der Block „Speicher im Jahr” mit einer Zeile je Monat: Ladung, Entladung, Vollzyklen, Solar-Anteil der Ladung, Auslastung und Netto-Nutzen in Euro, dazu eine Gesamtzeile und ein Vergleich der beiden Saison-Fenster (Sommer Jun–Aug gegen Winter Nov–Feb). Zwei der Spalten sind neu im Programm: die Auslastung setzt die Entladung ins Verhältnis zu dem, was der Speicher im Zeitraum überhaupt hergäbe (Kapazität × Tage) — anders als die Vollzyklen ist sie dadurch zwischen einem Februar und einem Juli vergleichbar, und im laufenden Monat zählen nur die abgelaufenen Tage, damit am Dritten nicht eine Zahl steht, die mehr über das Datum sagt als über den Speicher. Der Netto-Nutzen ist dieselbe Zahl, die im T-Konto desselben Monats steht — sie wird dort abgeholt, nicht zweitgerechnet. Für die Jahreszeile werden Entladung und Bezugsgröße summiert und einmal geteilt; Monats-Prozente zu mitteln wäre falsch, weil ein Februar weniger wiegt als ein Juli. Ohne gepflegte Kapazität bleiben Vollzyklen und Auslastung leer („—”) statt 0 — ein Speicher ohne Kapazitätsangabe ist ein unbekannter, kein ungenutzter; die fehlende Angabe meldet der Daten-Checker mit Link auf die Investitionspflege. Wer die Netzladung nicht pflegt, sieht beim Solar-Anteil ebenfalls „—” und nicht 100 %. Der Block kostet keinen zusätzlichen Abruf: er faltet dieselben Monats-Antworten, aus denen die Jahres-Sicht ohnehin besteht — was dort steht, kann deshalb nicht von den Kacheln darüber abweichen. Der Ort folgt der Ortsregel nach Zeitraum: zeitbezogene Sichten stehen im Cockpit, im Komponenten-Hub bleibt, was über die Lebensdauer des Geräts geht. (#358 Phase 1, aus #142/rapahl)
Der Amortisations-Fortschritt ist zurück — als eine Zahl, nicht als zweite Meinung. Auswertungen → ROI zeigte bisher nur ein Modell: „Amortisation in 9,2 Jahren”, hochgerechnet aus einer prognostizierten Jahres-Einsparung. Die andere Hälfte der Frage — wie viel ist tatsächlich drin? — gab es am Bildschirm nirgends; sie stand nur im Jahresbericht-PDF, obwohl das Backend sie durchgehend mitrechnet. Der zugehörige Block hatte den V4-Flip nicht überlebt, und das war eine bewusste Entscheidung: zwei Amortisations-Zahlen nebeneinander bergen die Gefahr widersprüchlicher Sichtweisen mit aufwendig zu erklärenden Unterschieden. Am Code nachgemessen war die Sorge berechtigt — nur lag die Ursache nicht in den zwei Sichtweisen, sondern im gemeinsamen Nenner: Auf die Frage „was hat die Anlage relevant gekostet?” gab es drei Antworten. Die ROI-Sicht rechnete Σ (Anschaffung − Alternative) ohne Klemmung je Position; die USt-Bemessung Σ max(0, Anschaffung − Alternative); und Aussichten wie Cockpit trugen — wortgleich, also eine Kopie — eine Hybrid-Summe aus „PV-System voll + WP-/E-Auto-Mehrkosten + Sonstiges voll”, deren Mehrkosten aus einem Parameter-Schlüssel kamen, den nichts im ganzen Programm jemals schreibt. Sie fiel damit immer auf die Festannahmen 8.000 € für die Heizung und 35.000 € fürs Auto zurück — und ging genau an dem Feld vorbei, das eedc im Daten-Checker mit einer Warnung einfordert („werden für ROI-Berechnung benötigt”): den gepflegten Anschaffungskosten der Alternative. Seit diesem Paket gibt es eine Definition (Layer-SoT core/berechnungen/investitionskosten.py, identisch mit der USt-Bemessungsgrundlage), und die beiden Kacheln stehen nebeneinander in Auswertungen → ROI: „Amortisation” (Modell) und „Amortisations-Fortschritt” (Messung: „40,0 % · noch 7.200 € · voraussichtlich 2030”). Beide Tooltips sagen ausdrücklich, welche hochgerechnet und welche gemessen ist. Sichtbare Folge für Betreiber von Wärmepumpe oder E-Auto: Wer die Alternativkosten nicht gepflegt hat, sah seine Amortisation bisher zu günstig — eedc setzte eine Annahme an seiner Stelle ein. Jetzt zählen dort die vollen Anschaffungskosten, die Amortisation fällt entsprechend länger aus; wer das Feld pflegt, bekommt seine eigene Zahl. Für PV, Speicher und Wechselrichter ändert sich nichts (keine Alternative), und wer zufällig genau 8.000/35.000 gepflegt hatte, sieht ebenfalls keinen Unterschied — das ist auch der Grund, warum am Demo-Datenbestand beide Summen identisch sind (76.500 €) und der Fehler dort nie auffiel. Der Beweis ist ein Symmetrie-Test, der Aussichten, Cockpit und ROI-Sicht auf einer Anlage vergleicht, deren Alternativkosten bewusst von den Festannahmen abweichen (43.000 € statt der alten 25.000 €) — gegen den vorherigen Stand fällt er. Die neue Fortschritts-Kachel rechnet selbst nichts: sie zeigt die Zahl, die schon vorher an genau einer Stelle entstand. (N-137 · N-134)
Wer SFML als Prognosequelle gewählt hat, sieht sie jetzt auch im Prognosen-Vergleich — als Wert, nicht als Note. Bisher zeigten Auswertungen → Prognose dort OpenMeteo, eedc, Solcast und IST; ausgerechnet die Quelle, mit der eedc bei diesen Anwendern tatsächlich rechnet, fehlte in Stundenvergleich, 7-Tage-Vergleich und Tagesverlauf. Die Daten lagen die ganze Zeit an — das Backend liefert sfml_* mit, sobald SFML gewählt ist, die Vergleichssicht las sie schlicht nie. Sie erscheinen jetzt als zusätzliche SFML-Spalte und als eigene Kurve im Tagesverlauf, in beiden Fällen nur dann, wenn SFML wirklich die gewählte Quelle ist. Was SFML bewusst nicht bekommt, ist eine Δ-Spalte, und im Genauigkeits-Tracking (MAE/Bias samt Tagestabelle) erscheint es weiterhin gar nicht: eedc stellt eine spezialisierte fremde Prognosequelle nicht bewertend gegen die eigene. Für zurückliegende Tage führt eedc über SFML deshalb auch keine Mitschrift — im 7-Tage-Vergleich steht dort „—”, gefüllt sind heute und morgen. Möglich wurde diese Zwischenstufe erst durch die Spaltentrennung im selben Paket: solange Wert und Bewertung in einer Zelle standen, gab es „anzeigen, ohne zu bewerten” nicht, und die Regel musste gröber ausfallen als nötig.
Ein Geräte-Connector, der nur einen Teil des Monats gemessen hat, sagt das jetzt — und wenn er gar nichts liefern kann, sagt es der Daten-Checker. Ein Connector-Wert ist immer die Differenz zweier Zählerstände. Wer seinen Connector mitten im Monat einrichtet, bekommt für diesen Monat deshalb ein Bruchstück: bei coolxmad (#353) waren es fünf Zählerstände vom 28.–30. Juli, geliefert als Juli-Wert von 51,3 kWh, während die HA-Statistik für denselben Monat rund 996 kWh auswies. Dass dieser Wert keinen gepflegten Monatswert mehr verdrängt, ist seit v4.0.5 erledigt; unbeschriftet stand er trotzdem da, sobald er als einzige Quelle übrig blieb — und genau das war bei coolxmad der Fall, weil die HA-Statistik für die PV ausfiel. In Cockpit → Monat trägt das Quellen-Etikett jetzt den gemessenen Zeitraum: „Connector (28.–30.07.2025)”, im Tooltip mit der Einordnung „misst nur 2 von 31 Tagen des Monats”. Deckt der Connector den Monat ab dem Ersten ab, ändert sich nichts — die Grenze ist dieselbe, an der das Backend ohnehin schon entscheidet, ob er überschreiben darf. Die Jahres-Sicht bleibt bewusst außen vor: sie faltet zwölf Monate zu einer Quellen-Liste, ein einzelner Zeitraum wäre dort entweder falsch oder eine Liste von zwölf. Zweitens gibt es den Fall, dass gar kein Wert entsteht — liegt kein Zählerstand vor dem Monatsbeginn oder keiner danach, liefert der Connector schlicht nichts. Das war nirgends zu sehen: die zuständige Route sagt es mit einem 404, hat aber keinen Aufrufer in der Oberfläche, und in der Monats-Sicht stand einfach eine Quelle weniger. Der Daten-Checker meldet das jetzt als eigene Kategorie, mit dem Bestand (wie viele Zählerstände, wie alt) und dem Weg heraus (täglichen Abruf einschalten bzw. Verbindung prüfen). Am Monatsersten schweigt er, solange der Abruf läuft — dort fehlt der Zählerstand im Monat bei jedem aktiven Connector, bis der Tagesabruf durch ist; gemeldet wird erst, wenn der jüngste älter als zwei Tage ist. Kein Connector eingerichtet ⇒ kein Befund. Kein neues Backend-Feld war dafür nötig: die Abdeckung liegt seit v4.0.5 in der Antwort, sie wurde nur von keiner einzigen Oberfläche gelesen. (#360 · N-73)

Changed

Der Prognosen-Vergleich ist auf dem Handy nicht mehr weggesperrt, sondern als Karten lesbar. Drei der vier Tabellen in Auswertungen → Prognose — die Kopf-Matrix (Heute/Morgen/Übermorgen), das Genauigkeits-Tracking und der 7-Tage-Vergleich — zeigten auf schmalen Bildschirmen gar keine Daten, sondern den Satz „Datendichte Tabelle — bitte Gerät ins Querformat drehen oder Desktop verwenden”. Wer drehte, bekam den nächsten Satz: „Auflösung zu gering für datendichte Anzeige — bitte Desktop verwenden”. Der Inhalt war mobil also nicht erreichbar, auch nicht mit Mühe. Jetzt steht dort, was im Rest des Programms schon lange die Antwort auf schmale Bildschirme ist: eine Karte je Zeile — je Tag eine Karte, darin die Quellen untereinander mit Wert und Abweichung, so wie es die String-Tabelle, das T-Konto und die Komponenten-Finanzen längst machen. Auf breiten Bildschirmen ändert sich nichts: dort steht dieselbe Tabelle wie bisher. Mitgenommen: die relative Abweichung ist nach oben gekappt — bei einem Ausfalltag (IST 0,2 kWh gegen 5,0 kWh Prognose) stand dort „(2400 %)”, jetzt „> 999 %”; der absolute kWh-Wert daneben bleibt unverändert und trägt die Größenordnung. (N-127 · N-128)
In Auswertungen stehen jetzt dieselben Euro-Beträge wie im Cockpit — die Seite hat bis hierher nebenher selbst gerechnet. Die Finanzspalten von Auswertungen → Tabelle und die Blöcke in Auswertungen → Finanzen entstanden im Browser: eigene Suche nach dem zum Monat gültigen Tarif, eigener §51-Abzug, eigene Eigenverbrauchs-Ersparnis. Daneben gibt es seit v4.0.5 eine Stelle, die genau das für Cockpit, Jahresbericht-PDF, HA-Export und Aussichten tut — und dieselbe Tabelle bezog ihre Tages-Zeilen längst von dort. Zwei Rechner, eine Tabelle. Die Monatswerte kommen jetzt fertig aus derselben Quelle wie alles andere; im Browser wird nichts mehr nachgerechnet. Drei Zahlen bewegen sich dadurch sichtbar, alle drei in Richtung der Zahl, die das Cockpit ohnehin schon zeigte: (1) Wer einen Erzeuger unter „Sonstiges” mit Brennstoff betreibt — ein Mini-BHKW etwa —, bekam dessen Strom als volle Netzbezugs-Ersparnis gutgeschrieben, so als koste er nichts. Am Demo-Datenbestand nachgestellt sind das 477 € über fünfzehn Monate, in den betroffenen Monaten rund ein Viertel zu viel. Die Energiebilanz bleibt unberührt — Eigenverbrauch, Autarkie und EV-Quote zählen das BHKW weiterhin mit, seine Wirtschaftlichkeit gilt in eedc aber seit v3.45.4 bewusst als „nicht bewertet”, weil der Brennstoff auf der anderen Seite Geld kostet. (2) Bei Regelbesteuerung fehlte die Umsatzsteuer auf den Eigenverbrauch (unentgeltliche Wertabgabe, § 3 Abs. 1b UStG). Cockpit, PDF, HA-Export und Aussichten ziehen sie ab, Auswertungen nicht — der Netto-Ertrag stand dort entsprechend zu hoch. Er trägt den Abzug jetzt, und damit die Zahl nicht unerklärt schrumpft, gibt es in der Werte-Tabelle die neue, abschaltbare Spalte „USt Eigenverbrauch”. Wer nicht regelbesteuert ist — der Normalfall —, sieht hier keinen Unterschied. (3) Ein Balkonkraftwerk, bei dem nur der Eigenverbrauch gepflegt ist und die Erzeugung fehlt, trug in dieser Sicht bisher gar nichts bei; sein gemessener Eigenverbrauch zählt jetzt, ohne dass er doppelt zählt, sobald die Erzeugung nachgepflegt wird. Gegengerechnet, bevor umgestellt wurde: über ein einzelnes Jahr bleiben Auswertungen und Cockpit-Kachel jetzt bis auf 2,55 € bzw. 12,78 € beieinander (vorher lagen Welten dazwischen); der Einspeise-Erlös war schon vorher deckungsgleich und ändert sich um Rundungsbeträge. Eine Folge, die man kennen sollte: bei Regelbesteuerung ist die Summe der Tageszeilen nicht mehr der Monatswert des Netto-Ertrags — die USt ist eine Jahresgröße (Selbstkosten je kWh aus Investitionssumme und Jahresertrag) und lässt sich keinem einzelnen Tag zuordnen. Dieselbe bewusste Asymmetrie trägt die CO₂-Spalte. (N-22)
Die drei Tabellen im Prognosen-Vergleich beschreiben eine Abweichung endlich gleich — und Wert und Bewertung stehen jetzt in getrennten Spalten. Auf einer Seite standen bisher zwei Sprachen untereinander: das Genauigkeits-Tracking sagte rein relativ „+16 %”, Stundenvergleich und 7-Tage-Vergleich sagten rein absolut „▲ 9,7”. Das war kein Randfall, sondern betraf systematisch dieselben Zeilen: die 7-Tage-Tabelle zieht ihre Vergangenheits-Tage aus derselben Liste wie das Tracking darüber, die letzten vier Tage stehen also doppelt auf der Seite. An der Anlage nachgestellt (04.08.): der 03.08. stand oben als „69,7 +16 %” und zwei Blöcke tiefer als „69,7 ▲ 9,7”. Beide Zahlen sagen etwas Eigenes — 0,3 kWh sind mittags ein Treffer und morgens um sieben eine Fehlprognose —, deshalb steht ab jetzt überall beides: die Abweichung absolut in kWh, dahinter dieselbe Abweichung relativ, „▲ 9,7 (16 %)”. Damit die Prozentangabe die rechtsbündigen Werte nicht mehr verschiebt, hat jede Quelle zwei Spalten: ihren Wert und daneben unter Δ die Einwertung — die Zahlen fluchten wieder untereinander, und die Bewertung wird zu einer eigenen Leseachse. Drei Unstimmigkeiten fallen dabei mit weg: (1) Ein IST zwischen 0,05 und 0,5 kWh — die frühen Morgenstunden — bekam im Tracking gar keine Annotation, während der Stundenvergleich dieselbe Paarung rot färbte. (2) Der Rotton war in einer Tabelle red-500, in der anderen red-400; er kommt jetzt wie Grün und Gelb aus der Farb-Zentrale. (3) Der 7-Tage-Vergleich unterdrückte als einzige Tabelle die Abweichung auch für abgeschlossene Tage, sobald sie unter 0,03 kWh lag — er rief die Annotation nie mit dem Hinweis, dass seine Referenz ein gemessenes IST ist. Für Tage ohne Messung — heute und die Zukunft, die gegen das Mittel der Prognosen laufen — bleibt die Unterdrückung bewusst bestehen: dort ist ein „± 0,0” keine Aussage über die Wirklichkeit. Der eigentliche Beweis ist ein Test, der dieselbe (Prognose, IST)-Paarung durch alle drei Tabellen schickt und auf denselben Text prüft. (N-50 · Paket P-5)
Bei Regelbesteuerung nennen Cockpit, PDF, HA-Export und Auswertungen endlich dieselbe Umsatzsteuer — und über mehrere Jahre war sie bisher um ein Vielfaches zu niedrig. Die USt auf den Eigenverbrauch (unentgeltliche Wertabgabe, § 3 Abs. 1b UStG) leitet sich aus den Selbstkosten je kWh ab: Jahresabschreibung plus Betriebskosten, geteilt durch den Jahres-Ertrag. Genau dieses „je Jahr” ging verloren, sobald eine Sicht einen längeren Zeitraum zeigte: Cockpit ohne Jahresfilter, der Anlagenbericht über den Gesamtzeitraum, die bisherigen Erträge in Aussichten und der HA-Export — sie alle reichten die Erzeugung des ganzen Zeitraums als Jahres-Erzeugung durch. Im Nenner stand damit eine mehrjährige Menge, im Zähler eine einzelne Jahresabschreibung, und die Steuer fiel um den Faktor der Jahresanzahl zu klein aus. Am Demo-Datenbestand über 34 Monate: 390 € statt 1.183 € in der Cockpit-Kachel. Der Netto-Ertrag stand entsprechend zu hoch, und weil der ROI-Fortschritt in Aussichten auf denselben Erträgen aufsetzt, sah auch die Amortisation zu günstig aus. Zweitens war die Bemessungsgrundlage selbst uneins: vier Sichten setzten die Vollkosten aller Investitionen ein — beim E-Auto also den ganzen Kaufpreis —, das Cockpit dagegen eine eigene, zusammengesetzte Summe, die als einzige Stelle im Programm die gepflegten Alternativkosten gar nicht las, sondern mit festen Annahmen (35.000 € fürs Auto, 8.000 € für die Heizung) rechnete. Dieselbe Anlage bekam so je nach Sicht eine andere Steuer; nachgemessen lagen Cockpit-Kachel und HA-Sensor 324 € auseinander, obwohl der Sensor die Kachel abbilden soll. Beides ist jetzt eine Stelle: Bemessungsgrundlage sind die Mehrkosten — was eine Anschaffung gegenüber ihrer Alternative gekostet hat, mit dem Feld, das man in eedc ohnehin pflegt —, und gerechnet wird Jahr für Jahr. Ein angefangenes Jahr trägt anteilig ab: wer im Juni in Betrieb geht, bekommt für dieses Jahr sieben Zwölftel Abschreibung, nicht zwölf gegen sieben Monate Ertrag. Das war vorher nirgends so. Wer nicht regelbesteuert ist — der Normalfall — sieht keinen Unterschied. Wer es ist, sollte wissen: die Zahlen bewegen sich in beide Richtungen. Über einen mehrjährigen Zeitraum steigt die USt deutlich (der Zeitraum-Fehler überwiegt), für ein einzelnes Jahr sinkt sie meist, weil die Bemessungsgrundlage von den Voll- auf die Mehrkosten wechselt. Am Demo-Bestand: Cockpit über alle Jahre 390 € → 1.183 €, Auswertungen über alle Jahre 2.447 € → 1.074 €, Anlagenbericht-PDF-Netto 5.489 € → 5.062 €. Cockpit und HA-Export stimmen danach auf den Cent überein. (N-129 · N-130)
Intern (ohne Nutzer-Wirkung): der P10-Wächter verweist für seine Gegenbuchung nicht mehr auf eine Datei neben dem Code. P10_NOCH_NICHT_MIGRIERT in backend/tests/test_wurzelmuster_konformitaet.py ist die gedeckelte, einzige Fassung der verbliebenen anlagenweiten Faltungen — der Kommentar darüber und zwei Fehlermeldungen verlangten daneben aber einen Eintrag in einer Übergabe-Datei, die nicht Teil des Repositories ist. Damit stand dieselbe Schuld an zwei Orten, und nur einer davon hatte einen Test. Der Wächter sagt jetzt, dass die Liste selbst die Buchung ist, und verlangt die Fund-ID im Kommentar über dem Eintrag — genau die Form, die die drei Migrationsschritte C1a–C1c ohnehin benutzt haben. docs/KONZEPT-MONATS-FAKTEN.md meldet die zugehörige Nebenfunde-Runde als abgearbeitet und datiert einen Protokollsatz, der im Präsens über den Stand vom 31.07. sprach. Kein Verhalten, keine Zahl, kein Testergebnis ändert sich — vier Kommentar- bzw. Meldungstexte und zwei Doku-Absätze. (N-63 · N-110)

Fixed

Ein gerechneter PV-Wert gibt sich nicht mehr als Messung aus. eedc füllt fehlende Pro-String-Werte notfalls aus dem Anlagen-Gesamtwert auf, anteilig nach kWp — zur Lesezeit, gekennzeichnet, und genau dafür gedacht. Zwei Wege schrieben eine solche Aufteilung aber in die Datenbank: der Import einer Legacy-Gesamtspalte (CSV-Backup, Portal- und Custom-Import) und der Monatsabschluss, wenn man den Vorschlag von Geräte-Connector oder Cloud-Import übernimmt, der bei mehreren Strings ebenfalls der zerlegte Anlagenwert ist. Ab da war die Rechnung von einer Messung nicht mehr zu unterscheiden — im CSV-Fall trug sie buchstäblich dieselbe Herkunft wie eine echte Pro-Modul-Spalte. Zwei sichtbare Folgen: Die String-Sichten in Auswertungen → Prognose und im Komponenten-Hub kürten einen „besten” und einen „schwächsten String” aus Zahlen, die per Konstruktion proportional zur Nennleistung sind — die Rangfolge war damit reines Artefakt, und die Sperre, die genau das verhindern soll, griff nicht. Und der Daten-Checker meldete den Monat grün („PV-Erzeugung vollständig gemessen”), obwohl kein einziger String gemessen hatte. Bei ungleich ausgerichteten oder verschatteten Dächern liegt eine kWp-Aufteilung im zweistelligen Prozentbereich neben der Messung; als „gemessen” etikettiert wanderte diese Abweichung unmarkiert in Auswertungen, Berichte und den Community-Vergleich. Jetzt vermerken alle Schreibwege am Wert, dass er gerechnet ist, und die Lesezeit stuft ihn als „verteilt” ein: Ranking gesperrt, Kennzeichnung „geschätzt (kWp-Anteil)”, im Daten-Checker der bekannte INFO-Hinweis statt eines grünen Hakens. Der Wert selbst bleibt unverändert — es geht um seine Herkunft, nicht um die Zahl. Bei genau einem Modul bzw. einem Speicher ändert sich nichts: dort geht der Gesamtwert unverzerrt an ein Gerät, das ist eine Messung und bleibt so etikettiert. Dasselbe gilt für den Speicher, dessen Lade-/Entladewerte nach Kapazität zerlegt werden. Was rückwirkend nicht geht: bereits gespeicherte Werte bleiben mehrdeutig — dieselbe Herkunft steht dort für „echte Pro-Modul-Spalte aus der CSV” und für „verteilt”; sie unterscheiden sich nachträglich nicht. Die Kennzeichnung wirkt ab dem nächsten Import bzw. Monatsabschluss. (#352)
Der Solarman-Cloud-Import erreichte europäische Konten nicht — jetzt ist die Server-Region wählbar, und Fehler nennen ihren Grund. Solarman betreibt zwei getrennte Wolken: api.solarmanpv.com (China, Portal home.solarmanpv.com) und globalapi.solarmanpv.com (international, Portal globalhome.solarmanpv.com). Der Host stand als Konstante im Provider — auf der chinesischen Seite, auf der ein europäisches Konto schlicht nicht existiert; die Einrichtung brach ab (#349, OliS2811, mit exakter Ursachenangabe). Der Provider bekommt deshalb ein Pflichtfeld „Server-Region” (type=select, Vorauswahl „Global / Europa”), genau nach dem Muster der fünf Geschwister-Provider (Anker, EcoFlow ×2, Sungrow, Huawei). Zwei weitere Befunde am Code, die nicht im Issue standen: (1) Der Authorization-Header ging ohne das von der SolarMAN Open API geforderte bearer-Präfix raus — der Token wurde also korrekt geholt und jeder fachliche Aufruf danach abgelehnt, auf beiden Regionen; damit konnte dieser Provider seit seiner Einführung nirgends einen Import abschließen, und der Wechsel der Default-Region bricht folglich keinen funktionierenden Bestand. (2) _get_token gab für HTTP-Fehler, fachliche Ablehnung und Exception gleichermaßen None zurück, worauf die Oberfläche immer denselben Satz zeigte („Bitte appId, appSecret, E-Mail und Passwort prüfen”) — die Meldung der Hersteller-API erreichte den Anwender nie. Jetzt trägt der Verbindungstest msg/code und den angesprochenen Host im Klartext, der Provider protokolliert Antwort-Status und -Körper (Diagnose-Logging wie bei den EcoFlow-Providern, solange getestet=False gilt), und ein Import, der vor dem ersten geholten Monat abbricht, wirft mit Grund statt „keine Monatsdaten gefunden” zu melden — ein Teilergebnis bleibt dagegen erhalten. Gegengeprüft und unverändert richtig: das Passwort geht als kleingeschriebener SHA256-Hex-Digest raus (die zweite Vermutung des Melders). getestet bleibt False, bis eine erfolgreiche Einrichtung zurückgemeldet ist.
Solcast zeigte für morgen die Kurve von heute — dabei liefert es für morgen längst eine eigene. Die Tagesmengen der Solcast-Prognose stimmten immer; was fehlte, war die Form des Tages. Wer sich in Cockpit → Aussicht den Stundenverlauf für morgen ansah, bekam das heutige Profil, auf die Tagesmenge von morgen skaliert — ein Tag mit Morgennebel und klarem Nachmittag sah damit aus wie der Vortag, nur höher oder flacher. eedc hat das nie verschwiegen (die Antwort trug den Hinweis „Stundenprofil von HEUTE als Näherung”), aber es war eben auch nicht nötig: rapahl hat am 30. Juli belegt, dass die HA-Solcast-Integration je Tages-Sensor ein eigenes Detail-Attribut führt, und der API-Zugang liefert ohnehin 168 Stunden in einem Abruf. Beides wurde bis hierher weggeworfen — der HA-Pfad las nur den Heute-Sensor, der API-Pfad verwarf jeden Halbstunden-Block, der nicht auf heute fiel. Jetzt bekommt jeder Tag, für den Solcast Stundenwerte liefert, sein eigenes Profil; wo die Quelle nur die Tagesmenge kennt (je nach Integration die weiter entfernten Tage), bleibt es bei der Näherung — samt Kennzeichnung, die dann auch wirklich nur dort steht. Es gibt keinen zusätzlichen Abruf: die Daten lagen in derselben Antwort, sie wurden nur nicht ausgewertet. Sichtbar wird das an zwei Stellen: der Tagesverlauf für morgen zeigt Solcasts eigene Kurve, und im Prognosen-Vergleich stammen die Vormittags-/Nachmittags-Werte der Solcast-Spalte für morgen jetzt aus Solcast selbst — bisher wurden sie aus der OpenMeteo-Verteilung geschätzt, die Solcast-Spalte trug dort also fremde Form. Für Tage ohne eigenes Solcast-Profil bleibt diese Schätzung bestehen, weil eine geschätzte Aufteilung mehr sagt als gar keine. (#357, gemeldet und belegt von rapahl)
Ohne PVGIS-Prognose zeigte die String-Sicht gar nichts — auch nicht die gemessenen Erträge. Auswertungen → Prognose → „SOLL/IST pro PV-String” brach mit dem Satz „Keine PVGIS-Prognose vorhanden” ab, sobald keine aktive Prognose hinterlegt war. Mit ihr verschwanden auch alle Zahlen, die keine Prognose brauchen: die gemessenen Erträge je String, deren Anteil am Gesamtertrag und der spezifische Ertrag in kWh/kWp — also genau die Kennzahl, mit der man zwei Dächer überhaupt vergleicht. Wer nie eine Prognose abgerufen hat, sah für seine Anlage einen Hinweissatz statt seiner Daten. Jetzt steht die Sicht: Erträge je String, Anteil, kWh/kWp und der saisonale Verlauf des gemessenen Durchschnitts sind da; weg bleibt nur, was ohne SOLL keine Aussage hat — SOLL, Abweichung und Performance. Der Hinweis bleibt als Zeile oben stehen und sagt, was fehlt und wo es herkommt (Einstellungen → PVGIS). Mit hinterlegter Prognose ändert sich nichts. (#350)
Die SOLL-Erfüllung des laufenden Monats maß das Datum, nicht die Anlage. PVGIS liefert eine Monatssumme — und genau die stand im laufenden Monat als Nenner über einem Ertrag, der erst ein paar Tage alt war. In Cockpit → Monat wurde daraus am 4. August eine SOLL-Erfüllung von 19 % (264,8 kWh IST gegen 1.387,9 kWh SOLL) für eine Anlage, die über Januar bis Juli auf 119 % kam; am Monatsersten stand dort faktisch eine Null-Meldung für eine völlig gesunde Anlage. Weil die Jahres-Sicht die Monatswerte summiert, zog der volle Monats-Nenner die Jahres-Kachel mit nach unten: 104 % statt 119 % an derselben Anlage, gemessen am 4. August. Der Fehler bestand seit jeher und war in der Oberfläche bereits sichtbar gewesen — die Block-Kopfzeile in Cockpit → Jahr unterdrückt die SOLL-Prozentzahl im laufenden Jahr genau deshalb. Das SOLL des laufenden Monats trägt jetzt nur die abgelaufenen Tage (SOLL × Tage ÷ Tage im Monat); der laufende Tag zählt dabei voll mit, weil die konservative Richtung die ist, die die Quote nicht überzeichnet. Damit die gekürzte kWh-Zahl nicht als Monats-SOLL missverstanden wird, weisen Kachel-Tooltip und Block-Kopfzeile das Fenster aus: „anteilig · 4 von 31 Tagen”. Abgeschlossene Monate, die gesamte Historie und alle Jahre ohne laufenden Monat bleiben unverändert — dort waren Zähler und Nenner schon immer deckungsgleich. Ein Monat in der Zukunft bekommt kein SOLL mehr zugerechnet (null abgelaufene Tage) und zeigt gar keine Quote, statt 0 % für einen Monat zu melden, der noch nicht stattgefunden hat. Gegenprobe an der gemessenen Anlage: die Jahresquote liegt mit gekürztem August bei 119,8 % und damit 0,6 Prozentpunkte neben den 119,2 %, die die abgeschlossenen Monate allein ergeben. (N-69)
Das PVGIS-SOLL kannte die Grenze des Wechselrichters nicht — überbelegte Anlagen liefen gegen ein Ziel, das ihr Gerät nie erreichen kann. Mehr Modulleistung zu installieren, als der Wechselrichter abgeben kann, ist keine Fehlplanung, sondern die übliche Auslegung: man tauscht Ertrag in der Mittagsspitze gegen Ertrag im Schwachlicht. Die PVGIS-Prognose rechnet aber aus der Modulleistung (DC) und weiß von der AC-Grenze nichts. Was das Gerät mittags abriegelt, stand deshalb im SOLL — und tauchte im SOLL/IST-Vergleich als Minus auf, das der Betreiber nicht zu verantworten hat (#354, kingcap1: 22 × 440 Wp an einem 7-kW-Fronius; #367, azywietz-web: 4 × 500 Wp an einem 800-W-Mikrowechselrichter). Die stündliche Kappung an der AC-Grenze gibt es seit v4.0.4 — bisher nur für das Balkonkraftwerk, wo die Grenze in einem eigenen Feld steht, und nur in der Tages-Prognose. Bei PV-Strings liegt sie längst in den Daten: am Wechselrichter, dem der String zugeordnet ist, im Feld „Max. Leistung (kW)”. Sie wirkt jetzt in beiden Pfaden. Der schwierige Teil war, dass die Grenze dem Gerät gehört und nicht der Himmelsrichtung: hängen ein Ost- und ein West-String am selben 7-kW-Wechselrichter, gelten die 7 kW für ihre Summe. Die Prognose gruppiert intern aber nach Ausrichtung, die beiden Strings liegen also in verschiedenen Gruppen — eine Kappung je Gruppe hätte dasselbe Gerät zweimal bis an seine Grenze liefern lassen. Am Demo-Datenbestand (Süd 12 · Ost 5 · West 3 kWp an einem 10-kW-Gerät) ist das der ganze Effekt: je String einzeln gekappt bliebe das SOLL unverändert, weil kein einzelner String allein 10 kW erreicht; gemeinsam sind es 1.227 kWh im Jahr, die das Gerät nie abgeben kann (20.812 → 19.585 kWh, −5,9 %; im April −10 %, im November und Dezember 0). Weil PVGIS für die Monatsprognose nur Monatssummen liefert und eine Monatssumme sich nicht nachträglich stundenweise kappen lässt, holt eedc dafür ein stündliches Profil derselben Anlage von PVGIS und leitet daraus einen Faktor je Monat ab — gemittelt über drei Jahre, damit nicht das Wetter eines Einzeljahres in einer Zahl steckt, die eine Anlagen-Eigenschaft beschreiben soll. Wer keine Wechselrichter-Leistung gepflegt hat, sieht keinen Unterschied: ohne Grenze wird nicht gekappt und PVGIS auch nicht zusätzlich gefragt. Sichtbare Folge für überbelegte Anlagen: das SOLL sinkt, die SOLL-Erfüllung und die Performance Ratio steigen entsprechend — die IST-Werte ändern sich nicht. Wirksam wird das erst mit einem neuen Abruf: die gespeicherte Prognose wird bewusst nicht nachträglich umgerechnet (Einstellungen → Solarprognose → „Neue Prognose abrufen” → „Speichern & Aktivieren”), die bisherige bleibt in der Historie. (#354 · #367)
Eine reine Balkonkraftwerk-Anlage bekam überhaupt kein PVGIS-SOLL. Beide PVGIS-Endpunkte filterten hart auf den Typ pv-module und antworteten sonst mit „Keine PV-Module für diese Anlage gefunden” — obwohl ein Balkonkraftwerk alles trägt, was PVGIS braucht: Leistung, Ausrichtung und Neigung stehen in seinen eigenen Formularfeldern, und zwei andere Prognose-Routen behandeln es seit v4.0.4 gleichberechtigt als String. Der Melder hatte sich mit einem fiktiven Wechselrichter als Eltern-Komponente beholfen und den Umweg zu Recht wieder zurückgenommen — er erzeugte doppelte kWp und ein Modul ohne Energiehistorie. Das Balkonkraftwerk erscheint jetzt als eigene Zeile in der Anlagen-Prognose (⚠ Korrektur August 2026: „SOLL/IST je String inklusive” traf nicht zu — die String-Sichten und der PDF-Abschnitt hängen an anderen Abfragen und blieben leer; s. Eintrag unter [4.0.11]); ein zweiter Erfassungsweg für dieselbe Erzeugung entsteht dabei ausdrücklich nicht. Zusammen mit der AC-Kappung oben ist das SOLL damit auch erreichbar: 2 kWp an einem 800-W-Gerät wären sonst ein Ziel, das die Anlage per Konstruktion verfehlt. (#367, aus Discussion #366)
Der Daten-Checker meckerte Überbelegung an — und meldete bei jedem Balkonkraftwerk eine Abweichung, die keine war. Die Prüfung „PV-Module kWp stimmt nicht mit Anlagenleistung überein” verglich die Summe aller Modul- und BKW-Komponenten mit dem Feld Anlagenleistung. Zwei Dinge stimmten daran nicht. Erstens gehört ein Balkonkraftwerk fachlich nicht in die kWp der Hauptanlage — es ist eine eigene Anlage mit eigener MaStR-Registrierung; solange es mitgezählt wurde, bekam jeder Anwender mit BKW diese Warnung, ohne dass etwas falsch gepflegt gewesen wäre (am eigenen Demo-Datenbestand 20,8 gegen 20,0 kWp). Zweitens war die Prüfung die einzige Stelle im Programm, die die kWp überhaupt gegen etwas hielt — und sie kannte Überbelegung nicht, konnte also nur zum Eintragen falscher Zahlen erziehen. An ihre Stelle tritt eine Prüfung, die das DC/AC-Verhältnis je Wechselrichter ansieht und erst oberhalb des Zweifachen meldet: bis dahin ist Überbelegung eine Entwurfsentscheidung (üblich 1,1–1,3, bei Ost/West bis etwa 1,5 — der Melder von #354 liegt bei 1,38), darüber ist ein Pflegefehler wahrscheinlicher, und die Meldung nennt ihn beim Namen: steht in einem „Leistung (kWp)“-Feld versehentlich die Wechselrichter-Leistung? Das Feld Anlagenleistung meint ab sofort unmissverständlich die installierte Modulleistung (DC); die Summenzeile des Checkers weist sie so aus. Wer weder BKW noch eine Überbelegung über 2,0 hat, sieht eine Meldung weniger und keine neue. (#354 · N-76 Stufe 1)
Wer E-Auto und Wallbox beide erfasst, sah seinen Netz-Ladeanteil doppelt — im Monat, im Jahr und in den Kosten. Eine Wallbox misst den Strom am Ladepunkt, ein E-Auto meldet dieselbe Ladung aus Fahrzeugsicht. Wer beides gepflegt hat, hat eine Ladung mit zwei Messgeräten dokumentiert, nicht zwei Ladungen — und das Programm weiß das: es wählt für die Heimladung überall genau eine Quelle (die Wallbox, wenn sie Heimladung meldet, sonst das Fahrzeug). Genau diese Regel fehlte an einer Stelle, und ausgerechnet an einer sichtbaren: die Zeile „Ladung · Netz-Anteil” in Cockpit → Monat addierte beide Seiten roh. Die Zahl lief von dort weiter in die Jahres-Summe und — teurer — ins T-Konto, wo sie mit dem Arbeitspreis multipliziert als Kostenposition steht. Am Demo-Datenbestand nachgestellt: über 25 Monate 5.976 statt 3.831 kWh, also 56 % zu viel, und betroffen war jeder Monat mit Ladung. Wer nur eines von beidem pflegt — der häufigere Fall —, sieht keinen Unterschied; dort gibt es nichts zu poolen. Wer beides pflegt, sieht einen niedrigeren, richtigen Netz-Anteil und entsprechend niedrigere Ladekosten im T-Konto — dieselbe Zahl, die ROI-Sicht, Aussichten, HA-Export und der Community-Benchmark schon vorher nannten. (N-107, Paket C1d)
Eine Komponente, die es im fraglichen Monat noch gar nicht gab, trägt keine Werte mehr bei. Alle Auswertungen in eedc respektieren seit v3.29 das Anschaffungs- und Stilllegungsdatum — eine Wärmepumpe, die im April gekauft wurde, taucht in den Monaten davor nicht auf. Der Komponenten-Block in Cockpit → Monat war die letzte Stelle, an der dieser Filter fehlte: er nahm jede erfasste Monatszeile seines Gerätetyps, unabhängig davon, ob das Gerät zu dieser Zeit schon existierte. Sichtbar wird das bei jedem, der Werte rückwirkend importiert oder nachpflegt — was etwa der HA-Statistik-Import über die volle Reichweite der Langzeitstatistik tut. Am Demo-Datenbestand standen so vier Monate lang Heizwärme und Warmwasser einer Wärmepumpe, die erst später angeschafft wurde; 3.400 kWh davon summierte die Jahres-Sicht ins Jahr 2024. Beide Grenzen greifen jetzt, Anschaffung wie Stilllegung. Wer keine Zeilen außerhalb der Laufzeit seiner Geräte hat — der Normalfall —, sieht keinen Unterschied. Wo ein Anschaffungsdatum fehlt, gilt die Komponente unverändert als von Anfang an vorhanden. (N-107, Paket C1d)
Was der Speicher einbringt, stand je nach Sicht um 36 % auseinander — und bei Arbitrage-Speichern zählte dieselbe Kilowattstunde zweimal. Der wirtschaftliche Nutzen eines Speichers ist der Spread: die entladene kWh ersetzt Netzbezug, hätte aber sonst Einspeisevergütung erbracht — es zählt die Differenz, nicht der volle Strompreis. So rechnen ROI-Sicht und Aussichten seit jeher, und so steht es als Entscheidung im Programm dokumentiert. Das T-Konto in Cockpit → Monat und → Jahr hielt sich nicht daran: es rechnete Entladung × Netzbezugspreis und wies bei einem typischen Tarif (30/8 ct) rund ein Drittel zu viel aus — 120,00 € statt 88,00 € bei 400 kWh Entladung. Dieselbe Anlage nannte in der ROI-Sicht die kleinere Zahl. Zweitens im Komponenten-Hub → Speicher: die Wirtschaftlichkeits-Aufstellung dort addiert „Eigenverbrauchs-Ersparnis” und „Arbitrage-Gewinn” — der erste Posten enthielt aber die gesamte Entladung inklusive der aus dem Netz geladenen Energie, die im zweiten Posten noch einmal auftauchte. Netzgeladene Energie hätte nie eingespeist werden können; ihr Vorteil ist Bezugspreis − Ladepreis, nicht der PV-Spread. Beides läuft jetzt über eine Formel, die die Entladung nach Herkunft trennt: der PV-Anteil bekommt den Spread, der Netz-Anteil seinen Arbitrage-Vorteil, und die beiden Posten der Aufstellung ergeben zusammen exakt die ausgewiesene Ersparnis. Sichtbare Folge: Wer einen Speicher hat, sieht im T-Konto einen niedrigeren, aber richtigen Beitrag — er stimmt jetzt mit der ROI-Sicht überein. Wer zusätzlich aus dem Netz lädt (Arbitrage), sah bisher im Hub eine zu hohe Gesamt-Ersparnis. Ohne Netzladung ändert sich am Hub nichts. (#358)
Die Vollzyklen in der Cockpit-Übersicht zählten die Ladung statt der Entladung. Ein Vollzyklus meint die einmal entnommene Kapazität — das ist die Größe, auf die sich Hersteller-Garantien beziehen, und sie ist unabhängig von den Verlusten des Ladepfads. Diese Festlegung gilt seit v4.0.4 im ganzen Programm; eine Route wurde beim damaligen Durchgang übersehen und rechnete weiter mit der Ladung. Die beiden Zahlen liegen genau um den Speicher-Wirkungsgrad auseinander — bei η 80 % sind das 10,0 statt 8,0 Zyklen. Bisher hat das niemand gesehen: der Wert wurde zwar ausgeliefert, aber von keiner Oberfläche gelesen. Mit der neuen Speicher-Auswertung bekommt er einen Auftritt, und damit wäre die falsche Zahl sichtbar geworden. (#358)
Ein Speicher ohne gepflegte Kapazität steht in der ROI-Tabelle nicht mehr mit „0 €” da. Auswertungen → ROI zeigte für einen AC-Speicher, dessen Kapazität nie eingetragen wurde, eine harte Null — also die Aussage „spart nichts”, wo „lässt sich nicht berechnen” gemeint war. Das Programm wusste es die ganze Zeit und schrieb den Grund sogar in die Antwort; die Tabelle las nur ein anderes Feld. Die Zeile trägt jetzt denselben Leerwert und denselben Zusatz „· nicht bewertet” wie die Split-Klimaanlage seit v4.0.6, mit dem Hinweis im Tooltip. Ihr Beitrag zu den Summen war schon vorher null und bleibt es. Nebenbei sprechen die Leerwerte dieser Tabelle jetzt ein Zeichen: an sechs Stellen stand noch der ASCII-Bindestrich - neben bereits umgestellten Nachbarn mit —. (N-89 · N-90)
Wer eine Wärmepumpe, ein E-Fahrzeug oder eine Wallbox anschafft, bekommt im Folgejahr keine Netzbezugs-Warnung mehr für den Verbrauch, den er selbst dazugebaut hat. Der Daten-Checker vergleicht jeden Monat mit demselben Monat im Vorjahr und meldet ab dem Dreifachen. Für die Einspeisung kennt er dabei seit v3.x eine Ausnahme: ist die installierte Erzeugerleistung zwischen beiden Monaten gewachsen, erklärt der Ausbau den Sprung und die Prüfung setzt aus. Für den Netzbezug gab es dieses Gegenstück nicht — obwohl der Kommentar an genau dieser Stelle im Programm die Ursache selbst benannte: „er wächst mit neuen Verbrauchern (WP, E-Auto, Wallbox)”. Wer im September eine Wärmepumpe einbaut, sieht seinen Winter-Netzbezug im Folgejahr planmäßig auf ein Mehrfaches steigen und bekam dafür Monat für Monat eine Warnung, an der nichts zu korrigieren war. Das Handbuch riet ihm bis hierher, sie zu „akzeptieren” — und genau das soll ein Hinweis des Daten-Checkers nicht verlangen: er ist kein Postfach, das man abarbeitet, sondern eine Anomalie-Anzeige, und eine Anomalie, die eedc selbst erklären kann, gehört gar nicht erst gemeldet (dieselbe Überlegung wie beim Inbetriebnahme-Monat, #240). Der Netzbezug bekommt jetzt die Ausnahme, die zu seiner Ursache gehört: ist zwischen Vergleichs- und Prüfmonat ein Verbraucher dazugekommen — Wärmepumpe, E-Fahrzeug, Wallbox oder ein Eintrag unter „Sonstiges” mit der Kategorie Verbraucher —, setzt die Prüfung für dieses Monatspaar aus. Die beiden Ausnahmen bleiben streng getrennt: ein PV-Ausbau entschuldigt weiterhin nur die Einspeisung, ein Verbraucher-Zubau nur den Netzbezug; springt die jeweils andere Größe, wird sie unverändert gemeldet. Gezählt wird dabei die Anzahl der Geräte, nicht eine Leistung — Wärmepumpe, Wallbox und Auto haben keine gemeinsame Kennzahl, aus der sich ein Erwartungsfaktor ableiten ließe; er wäre geraten. Ein Austausch ist deshalb kein Zubau: wer die alte Wärmepumpe stilllegt und eine neue anschafft, bekommt die Warnung weiterhin, denn dann erklärt nichts den Sprung. Ein Dienstwagen zählt mit — er lädt aus demselben Netzanschluss, auch wenn er in der Wirtschaftlichkeit getrennt behandelt wird. Voraussetzung ist ein gepflegtes Anschaffungsdatum: steht dort nichts, gilt das Gerät als von Anfang an vorhanden, und die Meldung bleibt — das ist dann der richtige Hinweis darauf, das Datum nachzutragen. (N-75, aus #362)
Der Stundenvergleich zeigt jetzt auch eine Stunde, für die nur die eedc-Spalte einen Wert hat. Der Zeilenfilter der 24-Stunden-Tabelle prüfte OpenMeteo, Solcast und IST — die eedc-Spalte nicht, obwohl das Diagramm zwei Bildschirme weiter oben genau sie mitzählte. Zwei Fassungen derselben Frage; welche Stunden zu sehen sind, hing davon ab, welche man ansah. Beide benutzen jetzt dieselbe Definition davon, welche Spalten als Wert zählen; die Schwelle bleibt bewusst verschieden, weil das Diagramm den hellen Bereich sucht und absichtlich eine Randstunde daneben legt, während die Tabelle Zeilen auswählt. An einem normalen Tag ändert sich nichts — an der Anlage nachgemessen: 15 Zeilen vorher wie nachher. Erreichbar wird der Unterschied nur bei einem Lernfaktor über 1 in einer Fast-Null-Stunde; die Uneinigkeit war trotzdem real. (N-51 · Paket P-5)
Der Verlauf in Cockpit → Jahr zeigt jetzt auch den laufenden Monat — und jeden anderen ohne Monatsabschluss. Oben stand „Jan–Aug · 9.653 kWh”, darunter zeichnete der Verlauf sechs Balken: Juli und August fehlten. Das ist dasselbe Bild, das v4.0.7 bereits beseitigen sollte; der damalige Schritt hat nur die Bedingung „hat Zählerwerte” aufgehoben, während die dahinterliegende Schicht einen Monat weiterhin nur kannte, wenn er irgendeine Zeile in der Datenbank hatte. Ein Monat ohne Monatsabschluss und ohne Komponenten-Zeile existierte für sie schlicht nicht. Das ist kein Randfall: einen automatischen Monatsabschluss gibt es nicht, deshalb fehlte im Verlauf immer mindestens der laufende Monat — und wer den Vormonat noch nicht abgeschlossen hatte, verlor auch den. An der Anlage, an der es auffiel, war das der Juli, der ertragsstärkste Monat des Jahres. Solche Monate werden jetzt aus der Tagesebene gerechnet, die eedc ohnehin führt, und im Tooltip als „aus Tageswerten” gekennzeichnet. Das kostet keine einzige zusätzliche Abfrage an Home Assistant — die Tageswerte liegen lokal und werden von den Snapshot-Jobs geschrieben, die ohnehin laufen; die mit v4.0.7 gewonnene Entlastung von HA bleibt damit unangetastet. Gemessen wurde vorher, ob die beiden Wege überhaupt dasselbe sagen: über sechs Monate, für die es beide Quellen gibt, weicht die Tagessumme um maximal 0,8 kWh (0,05 %) von der gepflegten Zeile ab, und für Juli und August trifft sie die Zahl der Kachel darüber auf allen vier Größen (PV 1843,2 gegen 1843,25 · Einspeisung 1343,9 gegen 1343,91 · Netzbezug 10,3 gegen 10,31). Gepflegte Werte gewinnen immer: die Tageswerte füllen nur Lücken, sie überschreiben nichts — auch nicht feldweise. Unverändert bleibt alles andere: Auswertungen → Tabelle zeigt weiterhin ausschließlich echte Datensätze (dort wäre so ein Monat eine Zeile, die man weder bearbeiten noch löschen kann), ebenso Monatsbericht, HA-Export und Community-Übertragung. Wer keine Datenquellen zugeordnet hat, hat auch keine Tageswerte — dort füllt sich allerdings die Kachel ebenso wenig, es gibt also keine Abweichung zu heilen. Dass der Monatsabschluss fehlt, meldet unverändert der Daten-Checker, mit Link direkt auf den Abschluss.

[4.0.8] - 2026-08-03 — Nach einem Neustart stimmen die Einheiten sofort

Fixed

In der ersten Stunde nach einem Neustart der Box kannte eedc die Einheiten seiner Sensoren nicht — Regression aus v4.0.7. Die Einheiten-Abfrage merkt sich je Sensor, wann sie ihn zuletzt geholt hat, und fragt nach einer Stunde erneut. Für einen Sensor, der noch nie geholt wurde, stand dort ein Platzhalter-Zeitpunkt, der mit der Laufzeit des Systems verglichen wurde — und die ist direkt nach einem Neustart kleiner als eine Stunde. Folge: der leere Vorrat galt als eben erst gefüllt, es wurde nichts abgefragt, und die Einheiten-Liste blieb leer, bis die Box eine Stunde gelaufen war. Sichtbar wurde das dort, wo aus der Einheit ein Umrechnungsfaktor folgt: Ein Sensor, der seine Leistung in kW meldet, wurde im Live-Tagesverlauf in dieser ersten Stunde nicht auf Watt umgerechnet und stand damit um den Faktor 1000 daneben; ebenso betroffen waren die Einheiten-Prüfung des Daten-Checkers (kW ≠ kWh) und der Energieprofil-Pfad. Wer seine Box durchlaufen lässt, hat davon nichts gemerkt — die Fehlstellung endete nach einer Stunde von selbst und kam erst mit dem nächsten Neustart wieder. Geprüft wird jetzt, ob ein Sensor überhaupt schon geholt wurde, statt einen Platzhalter-Zeitpunkt zu verrechnen. (Beleg gegen eine simulierte Laufzeit von 42 Sekunden; er fällt gegen die alte Fassung unabhängig davon, wie lange die prüfende Maschine schon läuft — genau daran war der Vorgänger auf einem Entwicklungsrechner grün und im CI rot.)

[4.0.7] - 2026-08-03 — Nichts kleinrechnen · nichts behaupten

Changed

eedc fragt Home Assistant nicht mehr nach allem, wenn es zwanzig Sensoren braucht — spürbar für alle, die eedc als Add-on betreiben. Das Live-Cockpit holte alle 5 Sekunden GET /api/states, und dieser Endpunkt liefert jede Entity der Instanz samt Attributen. Auf einer Installation mit 3457 Entities gemessen: ~2,4 MB je Abruf, also rund 470 kB/s Dauerlast — und zwar im Event-Loop von HA Core selbst, der daneben die Oberfläche bedient. Im Add-on läuft jedes dieser Pakete zusätzlich durch den Ingress-Proxy, damit ein zweites Mal durch denselben Event-Loop; als externe Docker-Instanz entfällt dieser Weg, weshalb dort niemand etwas gemerkt hat. Abgefragt werden jetzt genau die zugeordneten Entities (GET /api/states/<id>, gebündelt über eine Verbindung), dazu ein 3-Sekunden-Cache, damit zwei offene Tabs die Last nicht verdoppeln. Beide Live-Pfade sind umgestellt — Supervisor und Remote-HA; einer allein wäre kein Fix gewesen. Zusätzlich pollt eine unsichtbare Seite gar nicht mehr: ein vergessener Tab oder ein Wandtablet im Standby fragte bisher rund um die Uhr weiter, bei Rückkehr wird sofort aufgefrischt. Der 5-Sekunden-Takt selbst bleibt — er ist für den Energiefluss richtig, solange jemand hinsieht. Auslöser waren zwei Meldungen aus Discord, die HA-Oberfläche werde mit eedc als Add-on unbedienbar; die dort vermutete Ursache (zu viele MariaDB-Abfragen) war die kleinere der beiden.
Die Abfragen an die Recorder-Datenbank nutzen wieder den Index — spürbar für alle mit großer Historie, besonders mit MariaDB. Der Recorder indiziert (metadata_id, start_ts). Vier Abfragen verglichen aber nicht die Spalte, sondern eine Funktion darauf (FROM_UNIXTIME(start_ts) >= … bzw. datetime(start_ts,'unixepoch','localtime')) — damit fällt die Index-Nutzung für den Zeitbereich weg: die Datenbank liest die gesamte Historie des Sensors, rechnet je Zeile um und sortiert anschließend, um eine einzige Zeile zu behalten. Betroffen war unter anderem get_value_at, der Pfad, den der Snapshot-Job je Zähler stündlich betritt (bei aktiviertem 5-Minuten-Snapshot alle fünf Minuten). Zeitgrenzen werden jetzt in eedc zu Timestamps gerechnet und roh verglichen; die Monatsübersicht kommt zudem mit einer Aggregat-Abfrage statt zwei sortierten aus. Die Sensor-Metadaten werden fünf Minuten gemerkt, statt vor jedem Wert erneut aufgelöst zu werden. Ein Nebeneffekt kann Zahlen bewegen: FROM_UNIXTIME rechnet in der Zeitzone der Datenbank-Sitzung, eedc in seiner eigenen. Wer MariaDB auf UTC betreibt, während der Container auf Europe/Berlin läuft, bekam bisher einen um den Zonenversatz verschobenen Monatsausschnitt — ab jetzt gilt durchgehend die Zeitzone von eedc, dieselbe, in der die Monatsgrenzen gebildet werden.
Die Snapshot-Jobs halten eedc nicht mehr an. Die stündlichen und 5-minütigen Zählerstands-Abrufe sind synchrone Datenbank-Aufrufe, liefen aber direkt im Event-Loop — für die Dauer aller Abfragen einer Anlage stand die Oberfläche von eedc still. Sie laufen jetzt in einem Arbeits-Thread. Der Rest gleichartiger Aufrufe (Import-Vorschau, Reparatur-Werkbank, Tages-Aggregation) ist unverändert, aber ab sofort gezählt und gegen Zuwachs gesichert.
Der REST-Export liefert jetzt dieselben Zahlen wie MQTT — sichtbare Änderung für alle, die eedc-Sensoren über die rest-Plattform eingebunden haben. v4.0.6 hat die Rundung je Größenart eingeführt (B7, services/ha_sensors_export.py::runde_exportwert), aber nur an einem der beiden Export-Wege verdrahtet. Beide teilen sich den Produzenten (calculate_anlage_sensors / calculate_investition_sensors); danach trennten sie sich: MQTT rundete mit dem SoT, REST serialisierte roh weiter, was der Produzent geliefert hatte — und der rundete in 27 eigenen Sensorzeilen vor. Dieselbe Jahressumme kam über MQTT als 39692 an und über REST als 39692.4. Der MQTT-Wert wurde dabei zweimal hintereinander gerundet (18,45 → 18,5 → 18 statt 18,45 → 18). Gerundet wird jetzt nur noch an der Serialisierungsgrenze: bei REST im Pydantic-Modell SensorExportItem selbst, nicht in den drei Routen, die es bauen — an ihm vorbei kommt kein Sensorwert nach außen, auch eine vierte Route nicht; bei MQTT unverändert in publish_sensor. Der Produzent liefert ungerundet. Gegen die Demo-Anlage gemessen: 16 von 54 numerischen Sensorwerten ändern ihre Darstellung, 38 sind identisch — durchweg kürzer (39692.4 → 39692, 23408.7 → 23409, 13902.3 → 13902, Prognose 31.5 → 32). Eine Ausnahme geht in die andere Richtung: speicher_zyklen trug 380.0 und trägt jetzt 380.19 — Vollzyklen sind eine dimensionslose Kennzahl und bekommen damit dieselben zwei Stellen, die die Speicher-Kachel in eedc längst zeigt; die alte Ganzzahl war die Abweichung, nicht die neue Nachkommastelle. Unverändert: Sensor-Namen, Einheiten, device_class/state_class, die Anzahl der Entitäten, das YAML-Snippet und die HA-Historie zurückliegender Zeitpunkte. Der Nullkipp-Schutz gilt im REST-Pfad genauso (0,35 kW wird nicht 0). Der eigentliche Beweis ist ein Test, der denselben Sensor über beide Wege abfragt und die Strings vergleicht — für je eine kWh-, Geld-, Prozent- und dimensionslose Größe; eine Gegenprobe hält die Rundung davon ab, in den Produzenten zurückzuwandern. (N-55, Nebenfund aus Rainer-PN 89905/2 — #371)
Auch der zweite MQTT-Payload rundet. publish_monatsdaten (Topic eedc/anlage/{id}/monatsdaten/{jahr}/{monat}, retained) machte json.dumps roh — derselbe Client, der für die Sensoren den SoT benutzt. Heute trägt der Payload nur jahr, monat und die selbst eingetippten Zählerwerte, die Wirkung ist also klein (1234.5678 → 1235); die Lücke lag darin, dass eine später aufgenommene gerechnete Größe die langen Stellen sofort wieder mitgebracht hätte. Feldnamen, Reihenfolge und Topic bleiben unangetastet — daran hängen fremde HA-Automationen; ein Test pinnt genau das. Weil die Felder ihre Größenart nicht mitbringen, steht sie als Liste direkt neben der Stelle, die die Felder auswählt: wer eines aufnimmt, sieht die Einheit daneben. Ein Feld ohne Eintrag fällt bewusst auf zwei Nachkommastellen zurück — die Stellenzahl, die der Export bis v4.0.6 für alles benutzt hat, also nie gröber als vorher. (N-54)
Zwei Daten-Checker-Hinweise sagen jetzt, was ohne sie gilt — statt eine Handlung zu fordern, die nicht jeder ausführen kann. Beide standen dauerhaft und ließen sich durch keine Eingabe abstellen; ein Anwender bat deshalb ums Quittieren (Forum simon42 #89667/87, dietmar1968). Ein „Akzeptiert”-Häkchen bleibt ausgeschlossen — ein Hinweis, den man wegklicken kann, ist ein Hinweis, den man nicht mehr liest. Der Weg ist deshalb Bedingung schärfen oder Wortlaut ehrlich machen, und für diese beiden gibt es keine schärfere Bedingung. (1) „Kein WP-Spezialtarif hinterlegt” feuerte, sobald eine Wärmepumpe existiert; ob jemand einen Wärmestrom-Tarif hat, ist im Datenmodell nicht von „noch nicht eingetragen” zu unterscheiden. Die Meldung heißt jetzt „Wärmepumpe rechnet mit dem allgemeinen Tarif” — ein Zustand statt eines behaupteten Mangels — und der Text nennt den Rückfall (allgemeiner Arbeitspreis) samt der Auskunft, dass beim Einheitstarif nichts zu tun ist und der Hinweis dann als Information stehen bleibt. Vorbild ist der Nachbar-Hinweis „Kein Ladetarif hinterlegt”, der seinen Rückfall seit v4.0.5 ausspricht. (2) „PVGIS-Systemverluste ggf. zu hoch” nannte Befund (Performance Ratio über 12 Monate) und Handlung („Systemverluste reduzieren?”), aber nicht die Folge — wörtlich: „Für den ersten Hinweis bräuchte ich eine Erklärung.” Der Text sagt jetzt, dass die 14 % eine Annahme der Prognose sind und keine Messung, dass eine Änderung erst mit einem neuen PVGIS-Abruf wirksam wird („Speichern & Aktivieren”), und was dann passiert: das SOLL steigt, deshalb sinken Performance Ratio und SOLL-Erfüllung in Prognose-vs-IST und im Jahresbericht — die IST-Werte ändern sich nicht. Dazu, dass der Schritt umkehrbar ist (die bisherige Prognose bleibt als Historie erhalten) und dass man sie bewusst als konservative Untergrenze behalten darf. Kein Befund erscheint oder verschwindet dadurch — es ändert sich der Text. Der Regressionstest, der den WP-Hinweis für stillgelegte Wärmepumpen fernhält, filterte auf den alten Wortlaut und wäre durch die Umformulierung stumm geworden (er hätte auf eine Liste geprüft, die dann immer leer ist); er filtert jetzt auf die Kategorie und greift weiter. (N-83, N-84)
Auswertungen → Tabelle und Cockpit → Jahr rechnen jetzt über dieselbe Aufbereitung wie alle anderen Sichten — zwei Zahlen ändern sich dabei sichtbar. list_monatsdaten_aggregiert faltete die InvestitionMonatsdaten bis hierher selbst: eine eigene 320-Zeilen-Schleife mit eigener PV-Auflösung, eigenen Zeitfiltern und eigenem Dienstwagen-Filter. Sie war damit eine der drei letzten anlagenweit selbst faltenden Sichten (Register N-15, gedeckelt im P10-Wächter), und ausgerechnet die sichtbarste: sie speist die Tabelle und die Jahres-Kacheln. Seit diesem Paket kommen ihre Monatsgrößen aus services/monats_fakten.py (ADR-002/P10) — Zeitfilter, Dienstwagen-Filter, P7-PV-Auflösung und Monatstarif gelten dort genau einmal. (1) Die E-Mobilitäts-Ladung wird abgeleitet statt roh addiert: die alte Schleife summierte ladung_pv_kwh + ladung_netz_kwh direkt aus den gespeicherten Feldern. Wer nur die Gesamt-Ladung und den PV-Anteil pflegt — bei evcc-Importen der Normalfall —, hatte kein ladung_netz_kwh, und die Netzladung fiel still weg; ausgewiesen wurde nur der PV-Anteil. Die Schicht liest über denselben Helfer wie alle anderen Sichten und leitet den Netzanteil aus Gesamt − PV ab (die #262-Familie): aus 150 werden 200 kWh, die Spalte wird also größer und war vorher zu klein. (2) Die §51-Spalte sagt „—” statt 0,0, wenn für den Monat keine Börsenpreis-Mitschrift vorliegt — eine 0 wäre dort eine Aussage, die niemand belegen kann; betroffen sind nur Anlagen mit gesetztem §51-Schalter. Unverändert und ausdrücklich getestet: die Zeilenmenge (nur Monate mit Zählerzeile, neueste zuerst), None statt 0 für jeden Gerätetyp ohne gepflegte Zeile, eine gemessene 0 (Wärmepumpe mit 0 kWh Heizung im Sommer bleibt 0,0), der Dienstwagen-Ausschluss, die Anschaffungsdatum-Grenze — und der BKW-Akku, der hier seit jeher in dieselbe anlagenweite Speicher-Summe zählt wie ein echter Speicher (die Schicht hält ihn getrennt; still zu vereinheitlichen hätte die Speicher-Summe genau bei den Anwendern gesenkt, die noch auf dem alten Weg pflegen — das erledigt der Erfassungs-Kanon, nicht dieser Umbau). Der Beleg für die Verhaltensgleichheit ist negativ und deshalb stark: die 32 vorhandenen Tests dieser Route liefen ohne eine einzige Anpassung durch; die 11 neuen halten die zwei Änderungen und die neun Regressionen fest. Die gezählte Restschuld des P10-Wächters fällt von 4 auf 3. (N-15 · Paket C1a)
Auswertungen → Komponenten rechnet über dieselbe Aufbereitung wie alle anderen Sichten — ohne dass sich eine gemessene Zahl ändert. get_komponenten_zeitreihe war nach C1a die letzte Sicht der Restschuld außerhalb des Monatsberichts (Register N-17): sie lud InvestitionMonatsdaten und Monatsdaten selbst und faltete beide nach (jahr, monat). Die Monatszeile kommt jetzt aus services/monats_fakten.py (ADR-002/P10). Der Schritt war als deckungsgleich geplant und ist es geblieben — belegt statt behauptet: die vorhandenen Tests liefen ohne eine einzige Anpassung durch, und sechs der sieben neuen Tests sind auch gegen die Fassung vor dem Umbau grün, halten also Eigenschaften fest, die der Umbau erhalten musste. Namentlich gepinnt: hat_arbitrage/hat_v2h bleiben Aussagen über den ganzen Zeitraum (das auslösende Ereignis darf in einem anderen Monat liegen als der Rest der Daten), der Ø-Arbitragepreis bleibt mengengewichtet (25,00 ct statt 20,00 ct beim ungewichteten Mittel; eine Netzladung ohne gepflegten Preis zählt in die Menge, aber nicht in die Gewichtung), der BKW-Akku bleibt vom stationären Speicher getrennt — anders als bei C1a gibt es hier den Altbestand N-28 nicht —, und der Blockschalter (aktiv_im_jahr) ist vom Zeilenfilter (ist_aktiv_im_monat, jetzt in der Schicht) getrennt belegt: eine Mitte 2025 stillgelegte Komponente behält ihren Block für 2025, aber die im August gepflegte Zeile erzeugt keinen Monat. Genau eine sichtbare Änderung, und sie ist der siebte Test: ein Monat, dessen einzige Spur ein als dienstlich markiertes Fahrzeug ist, erzeugt keine Zeile aus lauter Nullen mehr. Der alte Loop legte den Monatseintrag an, bevor er den Dienstwagen übersprang — die Tabelle behauptete danach „0 kWh geladen” über ein Fahrzeug, das diese Sicht ausdrücklich nicht auswertet. Seine Finanz-Positionen zählen unverändert weiter und tragen den Monat (#310): er fällt aus dem Energie-Pool, nicht aus der Buchhaltung. Nebenbei fallen zwei Query-Muster weg — §51 kostete bisher eine Rundreise je Monat und wird jetzt in einem Zug geladen, der Tarif-Stichtag löst über den geteilten Cache der Schicht auf. Die gezählte Restschuld des P10-Wächters fällt von 3 auf 2; offen ist nur noch aktueller_monat.py (N-16). (N-17 · Paket C1b)
Cockpit → Monat rechnet über dieselbe Aufbereitung wie alle anderen Sichten — fünf Zahlen ändern sich sichtbar, alle zugunsten der Anwender. Der Monatsbericht war die letzte Sicht der P10-Restschuld (Register N-16) und die einzige mit einer echten Abgrenzung: er führt vier Datenquellen nach Präzedenz zusammen (gespeichert · Connector · MQTT · HA-Statistics), und die Monats-Fakten-Schicht kennt ausdrücklich nur die erste. Umgezogen ist deshalb genau der DB-Zweig; die Präzedenz-Regeln, die Bedingungen, unter denen ein Feld überhaupt gesetzt wird, und die Teilzeitraum-Logik für frisch eingerichtete Connectoren (#361) sind unangetastet — dafür stehen eigene Tests, denn ein „Aufräumen” an dieser Stelle wäre eine andere Route, nicht dieselbe mit anderer Herkunft. (1) Die PV des Monatsberichts wird aufgelöst statt roh summiert: wer keinen Sensor je String hat und nur die Gesamterzeugung der Anlage pflegt, sah hier bisher gar keine PV — und im selben Cockpit unter Übersicht den vollen Wert. Das ist derselbe Befund, der die Schicht ausgelöst hat (85 % Abweichung zwischen zwei Sichten derselben Anlage), an der letzten Sicht, die ihn noch trug. (2) Der Eigenverbrauch eines Balkonkraftwerks ohne Messwert wird nicht mehr als „die gesamte Erzeugung” behauptet: der alte Sonderweg setzte die volle Erzeugung ein, wenn der Eigenverbrauch nicht gepflegt war — Komponenten-Hub und Übersicht zeigten daneben den Rohwert. (3–5) Der Vorjahresvergleich verliert drei Divergenzen, die im Code als bewusst konserviert markiert waren: die PV wird jetzt genauso aufgelöst wie im laufenden Monat, der Eigenverbrauch enthält die Rückspeisung aus dem E-Auto ins Haus (V2H) und damit steigen auch Autarkie und EV-Ersparnis, und die E-Mob-Ladung kommt als geschlossene Trias aus einer Quelle statt als max() je Feld. Der letzte Punkt ist der greifbarste: am Demo-Bestand wies der Vorjahresvergleich für einen Monat 223,8 kWh Ladung aus, davon 50 kWh an einer öffentlichen Ladesäule — Strom, der nie durch das Haus floss; derselbe Monat als laufender Monat gelesen zeigte längst die richtigen 174 kWh. Eine Größe, zwei Sichten, ab jetzt eine Zahl (#262). Unverändert und gemessen: gegen den Demo-Datenbestand (34 Monatsabfragen, 7.582 verglichene Werte) ändert sich im laufenden Monat kein einziger Wert; alle 68 Abweichungen liegen im Vorjahresblock und sind die drei genannten Punkte — dazu Rundungsverschiebungen von 0,1 kWh bzw. 0,01 €, weil die Bilanz nicht mehr aus der bereits gerundeten PV gerechnet wird. Der Dienstwagen bleibt in beiden Pfaden außen vor, die Anschaffungsdatum-Grenze gilt weiter, ein Vorjahr ohne Zählerzeile blendet den Vergleich weiter aus. Fünf der zwölf neuen Tests sind gegen die Fassung davor rot verifiziert. Die gezählte Restschuld des P10-Wächters fällt von 2 auf 1: offen bleibt der Komponenten-Detailblock derselben Route, dessen anlagenweite Summen die Schicht heute nur zum Teil abbildet — ihn umzubuchen wäre Umetikettieren statt Tilgen. (N-16 · N-98 · Paket C1c)
Intern (ohne Nutzer-Wirkung): release.sh kehrt nur noch ein, was es selbst geschrieben hat. Die Vorab-Prüfung des Scripts lief über git diff und git diff --cached — beide sehen keine untracked Dateien. Eine neue, noch nicht eingecheckte Datei aus einer parallelen Arbeitssitzung passierte die Prüfung unbemerkt und wurde anschließend von git add -A in den Release-Commit gezogen. Geprüft wird jetzt mit git status --porcelain (untracked eingeschlossen), und gestaget werden benannte Pfadlisten statt -A; ist eine Liste unvollständig, bricht das Script ab, statt still weniger einzukehren. Gegen v4.0.6 nachgestellt: identische Dateimenge (130 bzw. 68). (N-56)
Intern (ohne Nutzer-Wirkung): unterhalb der Stunde gilt die Slot-Regel des Style-Guides ausdrücklich nicht. Regel B7 legt die Zeitachse für Stundenraster fest; für Sub-Stunden-Raster ist sie nie entschieden worden, und der Live-Butterfly beschriftet seine 10-Minuten-Punkte mit dem Beginn des Intervalls, während der Block „Wetter heute” direkt darüber das Ende nennt. Statt das nebenbei in einem Bug-Auftrag zu entscheiden — es gälte dann für Live-Kurve, Snapshot-Tabelle, Energieprofil-Tag, Fokus-Tabelle und die CSV-Spalte „Zeit” zugleich —, benennt der Style-Guide die Lücke jetzt als Lücke: keine neue Sub-Stunden-Beschriftung erfinden, der benachbarten Sicht folgen. (N-44)
Intern (ohne Nutzer-Wirkung): wann ein unvollständiger Wert beschriftet und wann er unterdrückt wird, steht jetzt als Regel fest. Neu docs/KONZEPT-UNVOLLSTAENDIGE-WERTE.md: eine additive Größe, der ein Summand fehlt, darf mit Kennzeichnung erscheinen; eine Differenz oder ein Quotient mit fehlendem Glied wird unterdrückt, weil niemand die Fehlerrichtung kennt. Bis dahin entschied das jede Sicht für sich — die beiden Korrekturen an Cockpit → Live und Cockpit → Tag in dieser Version sind die ersten beiden Anwendungen der Regel. Reine Dokumentation, kein Code.

Fixed

Der Tages-Einspeiseerlös wurde bei Anlagen gekürzt, die dem §51 EEG gar nicht unterliegen — sichtbare Zahlenänderung nach oben für jede Bestandsanlage mit Börsenpreis-Mitschrift. Seit Solarpaket I entfällt die Einspeisevergütung in Stunden mit negativem Börsenpreis; das gilt nur für Neuanlagen und ist deshalb ein bewusst manueller Schalter (Einstellungen → Anlage, Default aus). Das Gate dafür sitzt im Erlös-Service services/einspeise_erloes_service.py, dessen Modul-Docstring seit jeher zusicherte: „alle Read-Sites gehen über diesen Service, daher genügt die Prüfung an dieser Stelle”. Der Tagespfad ging nicht über ihn: services/energie_profil/tage_werte.py und api/routes/energie_profil/views.py lasen TagesZusammenfassung.einspeisung_neg_preis_kwh roh aus der Tabelle und gaben sie ungeprüft in die Erlösformel. Die Spalte selbst wird völlig zu Recht immer befüllt, sobald eine Strompreis-Mitschrift negative Stunden enthält (energie_profil/aggregator.py) — sie ist eine Messung; erst ihre Verwendung als Vergütungsabzug hängt am Schalter. Gemeldet für einen sonnigen Sonntag mit 45 kWh Einspeisung, für den Cockpit → Tag 1,86 € auswies — rechnerisch 4,1 ct/kWh, was es als Vergütung nicht gibt. Betroffen waren der Tages-Einspeiseerlös, die daraus abgeleitete Kachel Netto-Ertrag, der Finanzen-Block derselben Seite sowie die Spalte „Einspeisung bei neg. Preis” in der Tages- und der Monatsauswertung. Es ist derselbe Fehler, der für den Cockpit-Pfad bereits behoben und getestet war (test_cockpit_einspeise_neg_preis.py::test_ohne_eeg51_flag_kein_abzug_trotz_tages_aggregaten, damals ebenfalls von rapahl gemeldet) — der Tages-Zwilling wurde beim damaligen Fix nicht mitgezogen, die klassische Aggregations-Drift über parallele Pfade. Statt eines zweiten Gate-Codes im Tagespfad prüft jetzt eine vierte Funktion desselben Service (neg_preis_einspeisung_tageswert), die den bereits geladenen Tages-Rohwert und die bereits geladene Anlage entgegennimmt — kein zusätzlicher Query, und die Zusicherung im Docstring stimmt wieder. Die Ausweis-Spalte wird mitgegatet: sonst nennt die Tagestabelle eine §51-Menge, die die Monatstabelle bei derselben Anlage verschweigt. Unverändert: Anlagen mit gesetztem Schalter rechnen exakt wie bisher (eigener Test, ausdrücklich als Regressionsschutz markiert), die Kennzahl „negative Preisstunden” bleibt für alle sichtbar — sie ist Marktinfo und kein Abzug —, und Monats-, Jahres- und Cockpit-Pfad waren nie betroffen. Gepinnt mit einer Gegenprobe, die das Gate deaktiviert: drei der vier neuen Tests fallen dann. (PN Rainer 89905 vom 2026-08-02 — N-100)
Cockpit → Live zeigt keinen Hausverbrauch mehr, der ohne Kennzeichnung zu niedrig ist. Die „Heute”-Kachel Hausverbrauch (und derselbe Wert im Tooltip des Energieflusses) entsteht aus Eigenverbrauch + Netzbezug. Lieferte der Netzbezugs-Zähler für den Tag nichts — kein Sensor zugeordnet, Home-Assistant-Historie nicht erreichbar, MQTT-Topic still —, wurde die Lücke als 0 eingesetzt und die Kachel zeigte trotzdem eine Zahl: nämlich den Eigenverbrauch allein, um den gesamten Netzbezug zu niedrig und äußerlich nicht von einem gemessenen Wert zu unterscheiden. Sie schweigt jetzt, wie es die Nachbar-Kacheln bei fehlender Quelle längst tun. Dahinter stand die eigentliche Ursache: eine einzige Funktion wandte auf vier Sensoren drei verschiedene Regeln an — PV oder Einspeisung fehlt → beide Werte weg, Batterie fehlt → still als 0 gerechnet, Netzbezug fehlt → stillschweigend ergänzt. Es gilt jetzt eine Regel, und sie fragt nicht „ist irgendein Sensor ausgefallen”, sondern „braucht dieser Wert den fehlenden Sensor”: ein Wert wird geliefert, wenn seine eigenen Summanden vorliegen. Der Eigenverbrauch bleibt deshalb stehen, wenn nur der Netzbezug fehlt — er braucht ihn nicht; die daraus abgeleitete Autarkie entfällt weiterhin, weil sie ihn braucht. Unverändert: fehlt die PV oder die Einspeisung, schweigen beide Werte wie bisher — der Eigenverbrauch ist eine Differenz, und ob sie ohne den fehlenden Summanden zu hoch oder zu niedrig wäre, hängt davon ab, welcher fehlt; ein Wert, dessen Fehlerrichtung niemand kennt, ist schlechter als eine Lücke. Eine gemessene 0 bleibt eine 0 und wird nicht zu „—”: eine Batterie, die heute nichts tat, und ein Tag ohne Netzbezug sind Aussagen, keine Lücken (das galt für die Batterie-Summe bisher über eine Wahrheitswert-Prüfung, die eine echte 0 mitverworfen hätte). Alle vier Stellen, die die beiden Werte anzeigen, kommen mit dem zusätzlichen Schweigen um: sie blenden ihre Kachel bzw. Tooltip-Zeile aus, statt „0” zu schreiben — nachgesehen, nicht angenommen. Der Beleg für die Änderung ist eine Gegenprobe gegen den alten Stand: von neun Fällen ändert genau einer sein Ergebnis, die übrigen acht pinnen das bisherige Verhalten. Regel und Begründung stehen in docs/KONZEPT-UNVOLLSTAENDIGE-WERTE.md §3. (PN Rainer 89905 — erster Bau-Schnitt des Konzepts)
Die Stundenwerte-Tabelle in Cockpit → Tag behauptet keinen Hausverbrauch von 0,00 mehr, wo sie ihn nicht kennt — die gemeldete Stelle. In der Spalte Hausverbrauch stand für jede Stunde ohne vollständige Bilanz 0,00 kW, während die Spalte Gesamtverbrauch direkt daneben für dieselbe Stunde „—” zeigte: zwei verwandte Spalten, zwei Antworten auf denselben fehlenden Wert. Gemeldet wurde es für einen Tag, an dem in den Stunden 0–7 die PV-Zeile leer war, Batterie (0,27 kW) und Netzbezug (0,01 kW) aber weiter maßen — dort standen 0,00 kW Hausverbrauch, obwohl nachweislich rund 0,28 kW flossen. Das Backend hatte recht und der Client hat es überschrieben: die Stunden-Bilanz setzt den Gesamtverbrauch bewusst auf „unbekannt”, solange PV, Einspeisung und Netzbezug nicht alle drei vorliegen (snapshot/aggregator.py, lts_aggregator.py) — die Tabelle machte daraus per Vorgabewert eine 0 und rechnete munter weiter. Der Hausverbrauch ist eine Differenz (Gesamtverbrauch − Wärmepumpe − Wallbox − sonstige Senken); fehlt ihr Ausgangswert, ist sie nicht bestimmbar, und die Zelle trägt jetzt „—” wie ihre Nachbarin. Die Σ-Zeile ändert sich nicht — die unterdrückten Stunden trugen vorher exakt 0,00 bei und fehlen jetzt in der Summe, das ist derselbe Betrag; auch der CSV-Export bleibt in den Zahlen gleich und trägt an den betroffenen Stellen eine leere Zelle statt 0.00. Wer keinen Gesamtverbrauch messen kann, sieht die Spalte jetzt durchgehend leer statt durchgehend 0,00 — das ist die ehrlichere Auskunft, und die Zeile „PV” daneben sagt seit jeher dasselbe. Unverändert: eine gemessene 0 bleibt 0,00 (ein Haus, das in dieser Stunde nichts verbraucht hat, ist eine Aussage), Anlagen ohne Wärmepumpe oder Wallbox rechnen weiter wie bisher, und die abgezogenen Verbraucher werden unverändert abgezogen. Bewusst nicht mitgeändert: ob eine fehlende Wärmepumpen- oder Wallbox-Zahl „Gerät nicht vorhanden” oder „Sensor hat nicht gemessen” heißt, ist am Wert heute nicht zu unterscheiden — beides als Lücke zu werten hätte jede Anlage ohne Wärmepumpe verstummen lassen. Die Regel steht als benannte Stelle (berechneHausverbrauch) mit sieben Tests daneben; zwei davon fallen gegen den alten Stand, fünf pinnen das bisherige Verhalten. (PN Rainer 89905, gefunden an einem Screenshot aus dem Forum)
Eine Split-Klimaanlage bekommt in der ROI-Auswertung keine Ersparnis mehr gegen eine Heizung, die es nie gab — sichtbare Zahlenänderung für jeden, der eine Klimaanlage erfasst hat. Auswertungen → ROI behandelte jede Wärmepumpe als Ersatz einer Gasheizung. Fehlte der dafür nötige Wärmebedarf, füllten ihn Vorbelegungen auf: 12.000 kWh Heizwärme + 3.000 kWh Warmwasser. Daraus wurden bei den übrigen Standardwerten (JAZ 3,5 · 30 % PV-Anteil · Gas 12 ct) rund 1.100 €/Jahr und 2.210 kg CO₂/Jahr Ersparnis — Zahlen, die niemand eingegeben hat, für ein Gerät, das keinen Warmwasserkreis besitzt und typischerweise keine Heizung ersetzt hat. Die Beträge blieben nicht in ihrer Zeile: sie liefen in Gesamt-Ersparnis, ROI %, Amortisation, Break-Even-Jahr und Gesamt-CO₂ der ganzen Anlage. Dieselbe Komponente trug in Cockpit → Nachhaltigkeit 0 kg — alle vier gemessenen Auswertungswege (Cockpit, Nachhaltigkeit, Aussichten, JAZ/COP-Kachel) liefern ohne Wärmemengenzähler 0 bzw. „—”; die ROI-Sicht war die einzige, die den fehlenden Wert konstruierte. Für Luft-Luft-Wärmepumpen entfallen Ersparnis und CO₂-Ersparnis jetzt: die Zeile bleibt mit ihren Anschaffungskosten sichtbar und zeigt in den Wert-Spalten den Leerwert „—” samt sichtbarem Grund („nicht bewertet”) statt einer 0 — eine 0 wäre die Behauptung „spart nichts”, während in Wahrheit der Wert fehlt. Passend dazu fragt das Komponenten-Formular bei Wärmepumpenart Luft-Luft (Klimaanlage) Heizwärme- und Warmwasserbedarf nicht mehr ab und belegt sie nicht mehr vor — die Vorbelegung wurde beim Speichern mit übernommen und sah danach aus wie eine Anwender-Eingabe, weshalb der Fix an der Wärmepumpenart hängt und nicht an „kein Wert gepflegt”: nur so heilt auch der Bestand. Drei Daten-Checker-Hinweise, die ausschließlich diesen Gas-Vergleich füttern (Alternativkosten Gas-/Ölheizung, alter Energiepreis, Heizwärmebedarf), entfallen für Klimaanlagen ebenfalls — der letzte wäre sonst unauflösbar geworden, weil es das Feld dort nicht mehr gibt. Klassische Wärmepumpen rechnen unverändert, und eine Wärmepumpe ohne Angabe der Art zählt weiter als klassische; beides ist die zweite Hälfte der Tests, damit aus dem Fix kein Blindmacher wird, gemessen mit einer Gegenprobe, die den Fix zurückdreht und die 1.100 € wieder auftauchen sieht. Gespeicherte Werte werden nicht gelöscht — die Klima-Unterstützung ist nicht abgeschlossen, und was heute unbenutzt in den Parametern liegt, wird nicht weggeworfen. (Forum simon42 #89667/87, dietmar1968 · offenes Issue #263, 3dmaster90 — N-87)
Eine Split-Klimaanlage wird nicht mehr nach einem Wärmemengenzähler gefragt, den es dort nicht gibt. Der Daten-Checker meldete „1 Komponente(n) ohne Zusatz-Zähler für Tageswerte — Offen: Klimaanlage: Heizwärme, Warmwasser”. Beide Felder setzen einen Wärmemengenzähler voraus, und einen Warmwasserkreis hat ein Split-Gerät ohnehin nicht: der Hinweis war für den Anwender unauflösbar und widersprach der Zusage, die eedc im Komponenten-Formular selbst gibt („Es genügt der Stromverbrauchs-Sensor. Heizenergie/Warmwasser sind bei Klimas meist nicht gemessen.”). Der Sonderfall existierte im Baum bereits an zwei Stellen — die Monatsdaten-Prüfung nimmt Luft-Luft-Wärmepumpen seit jeher von der „Heizwärme fehlt”-Meldung aus, und JAZ/COP liefert dort bewusst „—” statt 0 —, nur die Tages-Zusatzfelder kannten ihn nicht. Es fehlte eine Bedingung, gebaut wie der Nachbar-Zweig daneben (E-Auto mit vorhandener Wallbox). Die Unterscheidung steht dabei nicht ein drittes Mal als Vergleich im Code, sondern als benannter Helfer neben ist_dienstlich; eine Wärmepumpe ohne Angabe der Art zählt weiter als klassische Wärmepumpe, damit eine fehlende Angabe die Erwartung nicht stillschweigend abschaltet. Klassische Wärmepumpen melden unverändert — das ist die zweite Hälfte der Tests, damit aus dem Fix kein Blindmacher wird; gemessen mit einer Gegenprobe, die die Bedingung entfernt und den Test fallen sieht. Nicht betroffen: die eigentliche Zähler-Abdeckung fordert von einer Wärmepumpe nur den Stromverbrauch, deckungsgleich mit der Zusage des Formulars. (Forum simon42 #89667/87, dietmar1968 — N-82)
Die Kachel „Ø-Preis Netz” (Cockpit → Monat) stellt keine zwei Zahlen mehr nebeneinander, die sich nicht ineinander umrechnen lassen. Unter dem Ø-Preis standen netzbezug_kwh und netzbezug_kosten_euro — letzteres inklusive Grundpreis (SoT core/berechnungen/netzbezug_kosten.py). Wer dividiert, und genau das tat der Melder, landet zwangsläufig daneben: 559 kWh · 210,45 € ⇒ 37,6 ct, während oben 33 ct steht. Der Tooltip sagte zwar „Kosten inkl. Grundpreis”, wird aber erst nach dem Stolpern gelesen und ist deshalb keine Lösung. Die Unterzeile trägt jetzt den Arbeitspreis-Anteil aus dem neuen Response-Feld netzbezug_arbeitspreis_kosten_euro (184,47 €), die Herleitung weist den Grundpreis mit der Gesamtsumme daneben aus („= 184,47 € · + 25,98 € Grundpreis = 210,45 € gesamt”). Das Feld ist reiner Ausweis — netzbezug_kosten_euro bleibt unverändert die verrechnete Rechnungssumme (T-Konto, Netto-Ertrag, Finanz-Block), es kommt kein Posten weg. Bewusst kein Client-Rechenweg aus netzbezug_kosten_euro − grundgebuehr_euro, obwohl beide Felder vorliegen: der Client konstruiert keine Größe (Linie hinter check:co2-roh/check:kennwert-roh). Befüllt an beiden Pfaden (laufender Monat + _load_vorjahr) und additiv in die Jahres-Summe (JahrAggregat) aufgenommen, damit die Kachel dort nicht zwölf Grundpreise im Divisor hätte, falls sie jemand in die Jahres-Sicht holt. (Forum simon42 #89667, Algie)
Bei flexiblem Tarif rechnete der laufende Monat Geld mit dem falschen Preis. Beim Nachprüfen der Ø-Preis-Kachel gefunden: aktueller_monat.py trug seit jeher den Kommentar „Flexibler Durchschnittspreis überschreibt Netzbezugspreis für Finanzberechnung — Platzhalter für spätere Überschreibung” — gebaut war sie nie. Netzbezugskosten, Eigenverbrauchs-Ersparnis und (ohne eigenen WP-Tarif) die WP-Ersparnis des laufenden Monats rechneten mit dem Tarif-Arbeitspreis, während der Vorjahres-Pfad (_load_vorjahr) und die per-Investition-Detailzeilen den verbrauchsgewichteten Monatsdurchschnitt aus Monatsdaten.netzbezug_durchschnittspreis_cent längst nahmen. Derselbe Monat trug damit je nach Sicht zwei Beträge, und die Kachel konnte gar nicht aufgehen: oben stand der Durchschnitt, darunter Kosten aus dem Tarifpreis. Der effektive Preis ist jetzt eine benannte Größe (netzbezug_preis_effektiv_cent) statt eines x or y an fünf Stellen; das ausgelieferte netzbezug_preis_cent bleibt daneben unverändert der Tarif-Wert („Verwendeter Tarif”). Betroffene Monate ändern ihre Euro-Beträge sichtbar — sie waren vorher falsch. Gepinnt mit einer Gegenprobe, die den Fix zurückdreht und die Tests fallen sieht (66,00 € statt 56,00 € EV-Ersparnis). Nebenbei fielen zwei identische Monatsdaten-Queries auf eine zusammen, weil der Durchschnittspreis nun vor dem Finanzblock vorliegen muss. (Befund aus Forum simon42 #89667)
Cockpit → Jahr vergleicht das laufende Jahr nicht mehr mit einem vollen Vorjahr. Die Spalten Vorjahr und Ø Jahre der Energie-Bilanz — und die VJ:-Zeilen der Kennzahl-Kacheln — summierten alle Zeilen des jeweiligen Jahres, unabhängig davon, wie weit das angezeigte Jahr überhaupt reicht. Auf Winterborn standen damit sechs gelaufene Monate 2026 gegen zwölf volle von 2025: 7.696 kWh gegen 14.221 kWh, „▼ 46 %”, und gegen den Ø der übrigen Jahre „▼ 30 %” — eine Zahl, die im Wesentlichen den Kalender maß und sich bis Dezember von selbst zurückgebildet hätte. Beschnitten wird jetzt auf die Monate, für die das angezeigte Jahr Daten hat — und zwar auf allen Spalten inklusive IST (die zweite Hälfte kam mit dem Fix darunter dazu); dieselben Daten ergeben 9.450 kWh gegen 9.912 kWh, „▼ 5 %” bzw. Ø 8.816 kWh, „▲ 7 %”, Autarkie 77,9 % gegen 82,0 % statt 77,6 %. Eine Lücke mitten im Jahr wirkt genauso — verglichen werden gleiche Monate, nicht „die ersten N”. In den Ø geht nur ein Jahr ein, das dieses Fenster ganz abdeckt: 2023 (Inbetriebnahme Juni) trug zu einem Jan–Jun-Vergleich sonst eine Ein-Monats-Summe bei, der Ø fiel von „aus 3 Jahren” auf „aus 2 Jahren”. Ohne jede Überschneidung entfällt die Vergleichsspalte („—”) statt 0 zu behaupten. Steht dort weniger als ein volles Jahr, sagt die Anzeige es — am Spaltenkopf, an den Kacheln (VJ (Jan–Jul): 6.198 kWh) und als Satz unter der Tabelle; ohne diese Angabe wäre die kleinere Zahl nur ein anderer Irrtum (ADR-002/P4 in klein). Abgeschlossene Jahre bleiben unverändert — bei voller Deckung ist die Beschneidung wirkungslos und die Beschriftung entfällt; gepinnt mit ausdrücklich als Regression markierten Tests. Gegenstück zur Summenzeilen-Regel aus v4.0.6 (vergleichsAggregatBasis), die in derselben Lage anders entscheidet: ein Tabellenfuß muss die Summe der Spalte über ihm sein und verwirft den Vergleich lieber ganz; eine Vergleichsspalte darf beschneiden, solange sie das Fenster nennt. Die Begründung steht am Code, damit der Unterschied nicht wie eine Drift aussieht.
Cockpit → Jahr zählt einen Monat, sobald er Daten trägt — nicht erst nach dem Monatsabschluss. ladeJahr bestimmte die Monatsmenge aus /monatsdaten/aggregiert, also aus den Monatsdaten-Zeilen. Die entstehen erst beim Monatsabschluss; ein längst gelaufener Monat mit vollständigen InvestitionMonatsdaten und Snapshots existierte für die Jahres-Sicht schlicht nicht. An der Box gemessen (Winterborn, 02.08.2026): das Aggregat meldet Jan–Jun, /aktueller-monat liefert für Juli 1.843,25 kWh — angezeigt waren 7.703 kWh (Jan–Jun + August), der volle Juli fehlte, der angefangene August war drin. Rund 24 % der Jahresernte, ausgerechnet der stärkste Monat. Die Kopfzahl steht jetzt bei 9.547 kWh; Autarkie 75,5 → 78,0 %, spez. Ertrag 625 → 775 kWh/kWp, SOLL-Erfüllung 98,7 → 102,5 %, Netto-Ertrag 1.242 → 1.493 €, und die Komponenten-Kennzahlen ziehen mit. Gefragt wird ein Intervall (erster Datenmonat der Anlage … laufender Monat bzw. Dezember), kein blindes 1–12: für jedes abgeschlossene Jahr ist die Menge damit exakt so groß wie bisher, nur das laufende Jahr wächst um seine Lücken (Winterborn: 7 → 8 Requests). Mehrere offene Monate und Lücken mitten im Jahr sind mitgefangen, weil es ein Intervall ist und keine Aufzählung; eine erfasste Zeile bleibt immer enthalten, die Menge ist nie kleiner als die bisherige. Die Antworten werden an gemessenen Mengen gefiltert (monatHatDaten) — der Endpoint beantwortet auch Monate vor der Inbetriebnahme und liefert dort soll_pv_kwh (Januar 2023: 396,1 kWh), Tarifpreise und Speicher-Kapazität; ein Fanout ohne diesen Filter hätte das SOLL aufgebläht und die SOLL-Erfüllung gedrückt. Ladezeit gemessen statt geschätzt (Median aus 10 Läufen gegen die Box, nach Warmlauf): laufendes Jahr 1.402 ms alt gegen 1.231 ms neu, abgeschlossenes Jahr 2.030 ms unverändert — der achte parallele Request verlängert die Wanduhr nicht, die Streuung beider Läufe ist größer als ihr Abstand. Das Abbruchkriterium (erst die Ladestrategie klären, statt Requests zu vervielfachen) greift damit nicht. Warum Juli keine Zählerzeile hat, bleibt unangetastet — der offene Monatsabschluss wird weiterhin gemeldet, in der Status-Fußzeile (amber, mit Deep-Link) und im Daten-Checker („07/2026 fehlt”, Abdeckung 37/38); beides an der Box gegengeprüft, ein dritter Hinweis wäre eine Dublette. (N-65, Folgefund aus dem Jahr-Vergleichs-Fix darüber)
Dieselbe Sicht trennt jetzt Kopfzahl und Vergleich. Die Kacheln zeigen „das Jahr bis heute” (alle Monate mit Daten, inkl. dem laufenden), die Vergleichstabelle rechnet über die abgeschlossenen Monate — auf beiden Seiten. Nur das Vergleichsjahr zu beschneiden hätte den laufenden Monat auf der IST-Seite gelassen: zwei Augusttage gegen einen vollen August 2025, also derselbe Fehler wie oben, nur kleiner (Winterborn: acht IST-Monate gegen sieben Vorjahres-Monate, „▼ 3,7 %” statt der richtigen „▼ 4,7 %”). Der Unterschied wird ausgewiesen (ADR-002/P4): der Kennzahlen-Block-Kopf nennt sein Fenster (Jan–Aug · 5 Energie-Kennzahlen …), der Bilanz-Block-Kopf und der Kopf der IST-Spalte das ihre (Jan–Jul), und der Satz unter der Tabelle nennt beide („… · Kennzahlen oben: Jan–Aug”). Die Angabe steht nicht an der Kachel-Zweitzeile, obwohl dort geplant: die ist truncate und fasst rund 22 Zeichen — an der Box gemessen schnitt das Präfix genau die Vorjahres-Angabe ab, die es einordnen sollte (IST Jan–Aug · VJ (Jan–…). Die SOLL-Erfüllung bleibt bewusst allein an der PV-Kachel: über Jan–Jul gerechnet ergäbe der Bilanz-Kopf eine zweite Prozentzahl für dieselbe Größe (119 % gegen 103 %), weil der laufende Monat sein volles PVGIS-SOLL mitbringt und nur ein paar Tage Ertrag — der Unterschied ist echt, vorbestehend und gehört an eine Stelle. Abgeschlossene Jahre sind unverändert: beide Fenster fallen zusammen, es wird nichts beschriftet, die Requests bleiben zwölf — gepinnt mit ausdrücklich als Regression markierten Tests. (N-65, Entscheid Gernot 2026-08-02)
Der Reparatur-Knopf erscheint nur noch für Zeiträume, die eedc überhaupt rechnen darf. Der Daten-Checker-Befund „Zähler zugeordnet, Tageswerte fehlen” verglich die gespeicherten Tage gegen alle Komponenten der Anlage — der Reparatur-Lauf dagegen nimmt für jeden Tag nur die Komponenten, die an diesem Tag aktiv waren (angeschafft, nicht stillgelegt, nicht auf inaktiv gesetzt). Wo beide auseinanderliefen, meldete der Checker eine Lücke und bot „Tag reparieren” an; der Lauf schrieb für diese Komponente nichts, antwortete mit HTTP 200, und die Meldung stand nach dem Klick unverändert da. Gemeldet wurde das für eine Klimaanlage, die inaktiv und zugleich erst zum 01.08. angeschafft war — die Lücke lief über den halben Juni und ganzen Juli. Die erwartete Schlüsselmenge ist jetzt tagesabhängig und benutzt dieselbe Aktiv-Definition wie der Lauf (ist_aktiv_an, In-Memory-Zwilling von aktiv_am_tag); eine gemeinsame Stelle (erwartete_komponenten_keys) beantwortet für Checker und Reparatur die Frage „was verspricht die Zuordnung an diesem Tag”. Der Fix ist ausdrücklich kein Filter an der Abfrage: die Menge wird einmal fürs 90-Tage-Fenster gebaut, die Aktivität ist aber pro Tag verschieden — gepinnt mit Tests für Anschaffung und Stilllegung mitten im Fenster (Stilllegungstag inklusiv), die ein Abfrage-Filter nicht bestehen würde. Echte Lücken aktiver Komponenten werden unverändert gemeldet — das ist die zweite Hälfte der Tests, damit aus dem Fix kein Blindmacher wird. (Forum simon42 #89667/83, dietmar1968 — #368)
Die Tagesreparatur sagt jetzt, für welche Komponente sie nichts schreiben konnte. status: "ok" heißt „durchgelaufen”, nicht „etwas geschrieben” — der Bereichs-Lauf wertet das seit v4.0.5 aus, der Einzeltag-Lauf war der eine Pfad ohne diese Aussage. Er meldete immer Erfolg und zeigte nur die PV-Tagessumme vor/nach dem Lauf (#290); eine Wärmepumpe, für die nichts geschrieben wurde, war davon nicht zu unterscheiden, solange sich die PV bewegt hatte. Die Antwort trägt jetzt je Komponente, ob der Lauf einen Wert hinterlassen hat, und die Meldung formuliert daraus dieselben drei Fälle wie der Bereichs-Pfad — aus einer Datei, damit nicht zwei Formulierungen nebeneinander wachsen: alles geschrieben (Erfolg), teilweise („2 von 3 Komponenten neu geschrieben — ohne Wert blieb: Wärmepumpe”) oder gar nichts (Hinweis, kein Erfolg). Bei den beiden letzten steht die häufigste Ursache dabei: kein Leistungssensor zugeordnet, oder die Home-Assistant-Historie reicht nicht so weit zurück. Die PV-Aussage bleibt — sie beantwortet die #290-Frage „hat sich etwas bewegt?” — und wird ergänzt, nicht ersetzt. Die Ergebnisseite kommt aus dem tatsächlichen Lauf, nicht aus einer zweiten Rechnung daneben; ein Lauf, der mangels frischer Werte nur den Bestand stehen lässt, zählt ausdrücklich als „nichts geschrieben”. (Forum simon42 #89667/83, dietmar1968 — #369)
Der Verlauf in Cockpit → Jahr zeichnet jetzt jeden Monat, den die Kennzahl darüber zählt — sichtbar für jeden, der einen Monat noch nicht abgeschlossen hat. Auf derselben Seite standen zwei Grundgesamtheiten nebeneinander: die Kachel PV-Erzeugung zählt seit v4.0.7 jeden Monat mit Mengen (der vorige Eintrag zum Jahres-IST), der Verlauf-Chart darunter und die Jahres-Rail links hingen weiter an /monatsdaten/aggregiert — und eine Monatsdaten-Zeile entsteht erst beim Monatsabschluss. An der Box hieß das: acht Monate in der Kopfzahl, sechs Balken darunter, und der Mini-Balken des laufenden Jahres in der Rail fiel entsprechend zu kurz aus. Es war dieselbe Lücke wie bei der Kopfzahl, nur eine Ebene tiefer; sie blieb offen, weil die Quelle damals ausgenommen war. Die Route liefert die Monate ohne Abschluss jetzt auf Anfrage mit (inkl_ohne_zaehlerzeile), und Cockpit → Jahr fragt sie an. Der Default bleibt aus, und das ist Absicht: Auswertungen → Tabelle ist eine Liste von Datensätzen — dort stünde sonst eine Zeile, die man weder bearbeiten noch löschen kann; eine Zeitreihe hat diese Bindung nicht. Solche Zeilen tragen deshalb id: null und behaupten keine Zählerwerte: Globalstrahlung, Sonnenstunden und der Ø-Bezugspreis bleiben leer statt still auf 0 zu fallen. Die aus den Komponenten gerechneten Größen — PV, Speicher, Wärmepumpe, E-Mobilität, Autarkie — sind vollständig, denn sie stammen ohnehin aus den Komponenten-Monatsdaten. Die Vorjahres- und Ø-Jahres-Spalten der Bilanz profitieren mit, sie lasen dieselbe Quelle. Unverändert: Monate ohne jede Spur bleiben draußen — ein Balken aus lauter Nullen für einen Monat, in dem nichts erfasst wurde, wäre schlechter als der fehlende Balken; das laufende Jahr trägt in der Rail weiterhin „läuft” statt einer Summe; und die Zeilen mit Abschluss kommen bitgleich wie bisher (eigener Test, der die ganze Zeile vergleicht, nicht eine Auswahl von Feldern). Drei der vier neuen Client-Tests fallen gegen den alten Stand. (N-68)
Drei Komponenten-Sichten bewerteten eingespeisten Strom mit einer Vergütung, die zu ihren Zahlen nicht passt — sichtbare Änderung für jeden mit mehr als einem Strompreis-Eintrag, und für jeden mit einer Komponente unter „Sonstiges”. v4.0.5 hat den Arbeitspreis aller Komponenten-Dashboards auf den Monats-Stichtag gezogen (ADR-002/P8): Eine Preiserhöhung sollte nicht rückwirkend die ganze Historie umschreiben. Die Einspeisevergütung daneben blieb dabei der heute gültige Wert. Überall dort, wo beide Preise in dieselbe Formel gehen, standen danach zwei Summanden aus verschiedenen Jahren. Betroffen sind alle drei Stellen mit einem Spread Bezugspreis − Einspeisevergütung: die Arbitrage-Ersparnis des Speichers, die V2H-Ersparnis des E-Autos (Rückspeisung ins Haus) und die Speicher-Kategorie unter Sonstiges. Der Effekt kippt in die Richtung, in die sich die Vergütung bewegt hat: Wer eine Altanlage mit hoher EEG-Vergütung betreibt und für einen neueren Anlagenteil einen Tarif mit niedrigerer Vergütung eingetragen hat, sah eine zu hohe Ersparnis — im nachgestellten Fall (12 ct damals, 5 ct heute, 1.200 kWh V2H-Entladung) 300,00 € statt 216,00 €, also 39 % zu viel. Komponenten → Sonstiges war gröber betroffen: dort waren Strompreis und Einspeisevergütung Pflicht-Parameter der Schnittstelle mit den festen Vorgaben 30,0 und 8,0 ct/kWh, und die Oberfläche übergibt keine Preise — die beiden Konstanten galten also immer, unabhängig vom gepflegten Tarif. Ein Mini-BHKW rechnete seine Einspeisung mit 8 ct, auch wenn im Vertrag 12 ct standen, und seinen Eigenverbrauch mit 30 ct bei einem 24-ct-Tarif. Das ist dieselbe Klasse, die beim Balkonkraftwerk mit v4.0.5 bereits behoben wurde (Befund F-4) — dort für den Strompreis, hier für beide Preisseiten. Beide Preise kommen jetzt aus dem Tarif, der im jeweiligen Monat galt, gewichtet mit der Menge, die die Sicht auch tatsächlich bewertet (Eigenverbrauch beim Erzeuger, Netzbezug beim Verbraucher, Entladung beim Speicher). Die Preis-Parameter der Schnittstelle bleiben als Override erhalten. Unverändert: Anlagen mit nur einem Strompreis-Eintrag — und das ist der Normalfall — rechnen exakt wie bisher, weil „der Tarif des Monats” dort derselbe ist wie „der heutige Tarif”. Ebenso unverändert bleiben Wallbox- und Wärmepumpen-Dashboard (sie rechnen keinen Spread), das Balkonkraftwerk (seine Einspeisung ist unvergütet, die Vergütung ging dort nie in eine Rechnung) und die ROI-Auswertung, die bewusst einen Durchschnitts-Jahreswert für die Amortisationsrechnung nach vorn bildet und dafür zu Recht den heutigen Tarif nimmt. Warum kein Bestandstest das gefunden hat, ist der eigentliche Befund: die vorhandenen Tarif-Fixtures variieren die Vergütung nicht — sie legen zwei Tarife mit verschiedenen Arbeitspreisen an und tragen in beiden dieselben 8,0 ct Vergütung ein. Ein Symmetrie-Test deckt nur die Achsen ab, die seine Fixture bewegt. Die vier neuen Tests bewegen genau diese Achse und halten den Arbeitspreis dafür konstant; gegen den alten Stand fallen alle vier. (N-113 — aus der Nachprüfung von N-67, dessen eigene Fundstellen sich am Code als bereits gedeckt erwiesen)

[4.0.6] - 2026-08-01 — Vergleichbares vergleichen · Gemessenes behalten

Changed

Intern (ohne Nutzer-Wirkung): der Stunden-Slot hat im Style-Guide eine benannte Stelle. Regel B7 verlangte die Backward-Zeitachse schon („Zeitachse Slot-Konvention backward”) — es gab dafür nur keinen SoT im Client, also baute sich jede Sicht die Zeitspanne selbst. Mit lib/stundenSlot.ts existiert sie; die Regel zeigt jetzt darauf, statt sie zu wiederholen. Ausdrücklich mitgeschrieben, was nicht gedeckt ist: es gibt keinen baumweiten Wächter, drei Stellen sind gepinnt, eine vierte Sicht fängt heute kein Skript — sonst läse sich die Regel wie eine Zusicherung.

Fixed

Der Vorjahresvergleich in der Werte-Tabelle vergleicht wieder mit dem echten Vorjahr. Über einen mehrjährigen Zeitraum („Alle Jahre”) wurden alle Jahrgänge desselben Monats verwechselt: jede Zeile bekam den jüngsten davon als „Vorjahr” — Dezember 2025 stand damit sich selbst gegenüber (identische Zahlen, Δ 0,0 %), ältere Zeilen einem Jahrgang aus der Zukunft. Jetzt steht jede Zeile ihrem eigenen Vorjahresmonat bzw. -tag gegenüber; wo es keinen gibt (weil die Aufzeichnung später beginnt), bleibt die Spalte leer statt einen Ersatzwert zu spiegeln. Auch die Summenzeile hört auf, Zeitspannen ungleicher Länge gegenüberzustellen: Sie zeigt einen Vergleich nur noch, wenn jede angezeigte Zeile ein Gegenstück hat, sonst „—”. Vorher stellte sie über „Alle Jahre” 37 Monate neben 31 (mit den Monaten der Primärperiode selbst darin) und im laufenden Jahr sechs Monate neben die vollen zwölf des Vorjahrs — auf Winterborn las sich das als „+23,1 % gegenüber dem Vorjahr”. Die „aktuell”-Zelle bleibt unverändert die Summe der Spalte darüber. Damit die schweigende Zelle nicht wie der Fehler aussieht, den sie behebt, steht der Grund unter der Tabelle — mit der Anzahl der Monate bzw. Tage ohne Gegenstück; derselbe Satz hängt als Hinweis an der leeren Zelle. Der CSV-Export trägt dieselben Werte wie die Tabelle — Fuß eingeschlossen, gegengeprüft mit einem Test, der Tabelle und Export auf derselben Eingabe vergleicht. Im Einzeljahr-Modus war der Zeilen-Fehler nie sichtbar. (PN Rainer 90204)
Der Monatsabschluss meldet „weicht ab” nicht mehr für reine Rundungsunterschiede. Ob Sensorwert und gespeicherter Wert als gleich gelten, entschied bisher eine feste Schwelle von 0,005 — der Sensorvorschlag kommt aber auf eine Nachkommastelle gerundet an, der gespeicherte Wert trägt zwei. Damit galten 2,3 und 2,33 als unterschiedlich, und weil Speichern daran nichts ändert, stand der orange Hinweis „Sensor meldet X · gespeichert Y” nach jedem Öffnen wieder an denselben Feldern — auf einem Testsystem an fast allen. Verglichen wird jetzt mit der Genauigkeit des Sensorwerts: eine Nachkommastelle vom Sensor heißt Vergleich auf eine Nachkommastelle, mehr als drei werden auf drei gedeckelt. Echte Abweichungen bleiben markiert — 453,7 gegen 454,74 ist gut eine Kilowattstunde und kein Rundungsrest. Dieselbe Regel gilt für die Liste „andere Quelle”, die einen bereits übernommenen Vorschlag nicht mehr als Alternative anbietet. Gemessen auf der Dev-Box am selben Monat: vorher zwei markierte Felder (eines davon reine Rundung), nachher nur noch die echte Abweichung. (PN Rainer 90128)
In Cockpit → Live „Wetter heute” liegen IST-Kurve und Prognose wieder auf derselben Stunde. Eine Stunde steht in eedc für die Zeit davor (Spalte 11 = 10:00–11:00, seit v3.20.0 baumweit) — dieser eine Block hielt sich nicht daran: Er beschriftete die Stunde vorwärts („11:00–12:00 Uhr”) und legte zugleich seine gemessene PV-Kurve eine Spalte zu früh ab. Beides zusammen ließ die Prognose daneben aussehen, als käme sie eine Stunde zu spät, und dieselbe Stunde trug in Auswertungen → Prognose eine andere Zeitspanne als im Cockpit. Gemessen an der Live-Anlage: die Live-Sicht zeigte in Spalte 10 die 5,61 kW, die überall sonst zu Spalte 11 gehören. Mit korrigiert: die laufende, erst angefangene Stunde erscheint nicht mehr als Einbruch der IST-Kurve, die Marker für Sonnenauf-/-untergang und Sonnenhöchststand stehen in der Stunde, die den Zeitpunkt enthält (05:56 → Spalte 6), und das hervorgehobene Wettersymbol ist wieder das der laufenden Stunde. Der Popover „IST unvollständig” nannte die fehlende Stunde ebenfalls vorwärts. Kein Wert ändert sich — die Tagessumme, die Kacheln und alle Auswertungen bleiben gleich; verschoben wird nur, in welcher Spalte ein bereits gemessener Wert steht. Beschriftung und Einsortierung kommen jetzt aus einer Stelle (lib/stundenSlot.ts, Spiegel der Backend-Konvention), damit sich die nächste Sicht die Zuordnung nicht wieder selbst baut. (PN Rainer 90106)
Bei frisch eingerichteten Anlagen und im Standalone-Betrieb lag auch die gestrichelte Verbrauchs-Kurve eine Stunde zu früh. Das individuelle Verbrauchsprofil hinter dieser Kurve wird aus den letzten sieben vollen Tagen gelernt und hat drei Quellen: die eigenen Aufzeichnungen (Vorrang), Home-Assistant-Historie und MQTT-Werte. Nur die erste bündelte die Stunden rückwärts, wie es die Konvention seit v3.20.0 überall sonst tut (Spalte 11 = 10:00–11:00); die beiden Fallback-Quellen ordneten vorwärts zu. Damit lag das Profil genau dort eine Stunde daneben, wo niemand einen Vergleichswert hat — bei der Neuinstallation und im Betrieb ohne Home Assistant. Wer bereits eigene Historie aufgezeichnet hat, war nie betroffen. Die Zuordnung passiert jetzt an einer Stelle im Modul und über dieselbe Backend-Konvention wie alle anderen Stundenwerte; das Abfragefenster beginnt dafür eine Stunde vor Mitternacht, weil die Spalte 0 eines Tages die letzte Stunde des Vortags trägt. Kein Wert ändert sich — nur die Spalte. Gepinnt mit je einer Regression pro Fallback-Pfad und einem Symmetrie-Test, der alle drei Quellen auf dieselbe Wirklichkeit ansetzt und dasselbe Profil verlangt (dritte Fundstelle derselben Klasse nach #297 und der Live-Kachel). (Befund aus PN Rainer 90106)
Dieselben zwei Wege rechneten das Verbrauchsprofil auch zu niedrig — die gestrichelte Kurve liegt jetzt höher, weil sie zu tief lag. Zwei getrennte Fehler mit derselben Handschrift: Aus unbekannt wurde war nichts. Im Standalone-Betrieb (MQTT) war der Stundenwert die Differenz zwischen dem ersten und dem letzten Zählerstand innerhalb der Stunde — das letzte Messintervall bis zum Stundenschlag fiel jedes Mal heraus, bei einem Snapshot alle fünf Minuten rund 8 %; ein Verbrauch, der erst gegen Ende der Stunde anfiel, ging ganz verloren. Gemessen wird jetzt von Stundengrenze zu Stundengrenze, und weil benachbarte Stunden denselben Randwert lesen, geht dort weder etwas verloren noch wird etwas doppelt gezählt. Über Home Assistant hängte jede Stunde eine Stichprobe an den Mittelwert — auch eine Stunde, für die der Recorder gar nichts geliefert hatte: mit 0 kW. Ein einziger Ausfalltag im Sieben-Tage-Fenster drückte damit jeden Werktags-Slot auf 4/5 des wahren Werts. Beide Wege lassen eine unvollständige Stunde jetzt aus, statt sie zu schätzen oder als Null zu zählen — genau wie es der Vorrangs-Weg über die eigenen Aufzeichnungen immer schon tat. Bleibt für eine Stunde keine einzige Stichprobe übrig, sagt das Ergebnis das und der Live-Chart setzt seine Standard-Grundlast ein, statt still 0 kW zu behaupten (lokale Ausprägung von ADR-002/P4). Als „gemessen” gilt bei MQTT ein Zählerstand an beiden Intervallgrenzen (höchstens 6 Minuten alt — der Scheduler schreibt alle 5 Minuten und nicht auf die volle Stunde gerastert), bei Home Assistant ein Messpunkt irgendeines Netz-Sensors; PV und Wärmepumpe taugen dort nicht als Beleg, weil sie nachts bzw. im Stillstand berechtigterweise stundenlang schweigen. Betroffen sind nur Neuinstallationen und der Betrieb ohne Home Assistant — wer eigene Historie hat, liest sie aus der ersten Quelle. Erfasste Daten bleiben unberührt. Die Fixture des Symmetrie-Tests aus dem Slot-Fix variiert jetzt beide Achsen (Zuwachs am Stundenende, ein Tag ohne Messung) — mit ihr fällt der Test gegen den Stand davor, ohne sie war er grün, während beide Fehler offen waren. (Befunde aus PN Rainer 90106)
„Gespeicherten behalten” überlebt jetzt das Speichern. Bei einer echten Abweichung zwischen Zähler und gespeichertem Wert bot der Monatsabschluss die bewusste Entscheidung an — merkte sie sich aber nur bis zum Speichern. Das war mehr als lästig: „weicht ab” zählt in der Kopf-Ampel als prüfen, ein Monat mit echter Zähler-Differenz konnte also nie „alles fertig” erreichen, obwohl der Knopf mit „→ geprüft” genau das versprach. Gespeichert wird jetzt die Situation, nicht ein Häkchen: gegen welchen Sensorwert bestätigt wurde und welcher Wert behalten wurde (neue Spalte geprueft_gegen auf monatsdaten und investition_monatsdaten, Migration idempotent, Bestandsdaten leer). Meldet der Zähler später etwas anderes oder ändert sich der gespeicherte Wert, ist die Bestätigung hinfällig und das Feld meldet sich wieder — ohne diesen Bezug wäre es eine Stummschaltung statt einer Entscheidung. Die Abweichung bleibt sichtbar: Badge „geprüft (weicht vom Sensor ab)”, darunter unverändert „Sensor meldet X · gespeichert Y · von dir behalten” samt „Sensorwert übernehmen” als Rückweg. Gilt für Basis- und Investitionsfelder — gemessen auf der Dev-Box, dass 25 der 26 Markierungen eines Monats Investitionsfelder waren, ohne sie hinge die Ampel weiter. Gegenprobe ebenfalls gemessen: nach geändertem Sensorwert steht wieder „weicht ab” (Kopf-Ampel 30 fertig/0 prüfen → 3 fertig/27 prüfen). (PN Rainer 90128, Befund b)
Ein frisch verbundener Connector setzt den Monatswert nicht mehr auf 0. Hängt der PV-Zähler an der Komponente — der empfohlene Fall, sobald eine PV-Komponente existiert —, liefert die HA-Statistik nur inv_<id>_pv_erzeugung_kwh. Der Connector meldet dagegen einen Anlagen-Gesamtwert, und jeder Top-Level-Wert sperrt die Aggregation der Komponenten-Werte (direct_fields), damit dieselbe Erzeugung nicht zweimal zählt. Beides zusammen ergab: Connector verbinden → laufender Monat auf 0. Sein Delta misst nur die Zeit zwischen zwei Zähler-Abrufen; abends eingerichtet sind das 0,0 kWh, und calc_difference filtert Nullen nicht — das Bruchstück verdrängte die vollständige HA-Summe. Der #360-Fix greift hier nicht: ohne gespeicherten Top-Level-Monatswert setzt auch der setdefault-Zweig den Schlüssel und landet genauso in direct_fields; die Verdrängung sitzt eine Ebene tiefer als die Merge-Präzedenz. Neu teilzeitraum_felder neben merge_datenquellen (ADR-001, gleiche Argumente): welche Gewinner messen nur ein Bruchstück? Diese Felder sperren die Aggregation nicht mehr und werden vom ersten aggregierten Beitrag ersetzt statt addiert — die Doppelzählung, gegen die die Sperre steht, bleibt verhindert. Deckt der Connector den Monat ab, bleibt alles wie bisher. Der laufende Monat heilt sich beim nächsten Aufruf; ein bereits über den Monatsabschluss gespeicherter 0-Wert bleibt stehen und ist einmal zu übernehmen. (#361, gefunden bei coolxmad #353)
Die Σ-Zeile im „Stundenvergleich heute” verglich den ganzen Tag mit dem halben. In Auswertungen → Prognose summierte sie die Prognose über alle 24 Stunden und stellte sie ist_heute_kwh gegenüber — dem IST bis jetzt. Gemessen an der Live-Anlage stand dort um 13 Uhr „Σ 78,1 ▲ 52,0” gegen „26,1”; die Abweichung maß im Wesentlichen die Uhrzeit und schrumpfte im Lauf des Tages von selbst. Sie summiert jetzt beide Seiten über dasselbe Fenster — bis zur letzten Stunde mit Messwert, höchstens bis zur laufenden Stunde —, kennzeichnet das mit bis HH:00 und nennt die Abweichung zusätzlich prozentual: dieselben Daten ergeben „30,2 ▲ 4,1 (16 %)” gegen „26,1”. Eine Stunde ohne IST (Datenlücke mittendrin) bleibt in allen vier Spalten außen vor, sonst zählte ihre Prognose als Fehlprognose. Bei abgeschlossenem Tag verhält sich die Zeile wie bisher (volle Tagessummen, keine Kennzeichnung); für einen Tag ohne jede Messung steht dort die Prognosesumme und kein Delta — kein 0-%-Ergebnis gegen eine nicht vorhandene Referenz (ADR-002/P4). Zweiter Teil derselben Meldung: in den Stundenzeilen darüber fehlte die Abweichungs-Annotation sporadisch — unterdrückt wurde jedes |Δ| < 0,03 kWh, was je Spalte unterschiedlich zuschlug (im Bild trugen OM und SC eine Abweichung, die eedc-Spalte daneben nicht) und wie eine Datenlücke aussah. Liegt ein IST vor, annotiert jetzt jede Prognosespalte — ein Treffer sichtbar als „± 0,0” statt eines Richtungspfeils, den die angezeigte Zahl nicht hergibt. Die drei Spalten rendern dafür dieselbe Zelle statt dreier fast gleicher Ausdrücke nebeneinander. (PN Rainer 90004/89980)
Der Jahres-Ø-Preis und das „Aktuell”-Badge sagen dasselbe wie die Rechnung darunter. Die Jahres-Kachel „Ø-Preis Netz” nannte für 2023 oben 28,0 ct und darunter „559 kWh · 210,45 €” — rund 37,6 ct. Zwei Ursachen, beide reine Anzeige; gerechnet wurde in beiden Fällen richtig. (1) Der Jahres-Ø war ein ungewichtetes Monatsmittel (JahrAggregat), während kWh und € Summen sind — ein teurer Januar mit 400 kWh wog so viel wie ein billiger Juli mit 20. Jetzt Σ(Preis × Menge) / Σ Menge, dasselbe Muster, das der Speicher-Netzpreis daneben schon benutzte. Gewichtet wird der effektive Monatspreis (Ø-Bezugspreis vor Tarif-Arbeitspreis, wie resolve_netzbezug_preis_cent), sonst fiele ein Jahr mit dynamischem Tarif auf den Referenzpreis zurück, obwohl die Kosten darunter mit dem Stundenpreis gerechnet sind; Monate ohne Menge fallen aus beiden Summen, ohne jede Menge bleibt das Mittel als Rückfall. Gleiches für die Einspeisevergütung. (2) „Aktuell” trug jeder Tarif ohne „Gültig bis” — istAktuell prüfte nur den einzelnen Eintrag. Die Auswahl spiegelt jetzt lade_tarife_fuer_anlage: gültig am Stichtag und je Verwendung der jüngste gueltig_ab (aus dem Prädikat wird aktuelleTarifIds(liste); istGueltigHeute bleibt als reines Gültigkeits-Prädikat). Standard- und Spezialtarif können weiterhin gleichzeitig aktuell sein. Die Kopfzahl selbst zog bis v4.0.4 den heutigen Tarif — das ist mit P8 (v4.0.5) erledigt. (Forum simon42 #89667/67, Algie)
Auf der Datenquellen-Fläche heißt das Speicher-Feld „Ladung”, wie es gemeint ist. Ein Wechselrichter, der charge_from_pv und charge_from_grid getrennt liefert, verführt zu „PV-Anteil auf Ladung, Netz-Anteil auf Netzladung” — im gemeldeten Fall 421 statt der gemessenen 494 kWh, und die Netzladung zählte doppelt. Das richtige Label gibt es seit #281 („Ladung (gesamt, inkl. Netz)”, label_wenn), nur löste die Fläche es nicht auf: sie zieht ihre Felder über get_alle_felder_fuer_investition — bewusst ohne Bedingungsfilter, damit eine bestehende Zuordnung nicht unsichtbar verschwindet — und die Funktion reichte die Roh-Definition durch. Jetzt löst sie das Label an der konkreten Investition auf und lässt die Steuer-Keys unangetastet; die Bedingungs-Auswertung liegt in einem gemeinsamen Helfer, damit Monatsabschluss und Fläche nicht zweierlei sagen können (Kopie je Feld — die Dicts sind Modul-Konstanten). Zweiter Befund derselben Fläche: „Ø Ladepreis” ist nur_manuell. Ein Monatswert in ct/kWh, für den es keinen Erfassungsweg aus Sensor oder Topic gibt (snapshot/keys.py schließt ihn ausdrücklich aus) — angeboten wurde er trotzdem, der zugeordnete Sensor bewirkte nichts, löste aber eine Daten-Checker-Meldung aus (im Forum landete dort ein €/kWh-Sensor in einem ct/kWh-Feld). Erfassbar bleibt er im Monatsabschluss, im CSV-Import und über den errechneten Vorschlag bei dynamischem Tarif; wer heute eine Quelle darauf gesetzt hat, sieht das Feld weiter und kann sie entfernen. (Forum simon42 #89667/62 + /64 + /71, MartyBr; /54 + /58)
Die Tagesreparatur reicht so weit zurück wie Home Assistant, nicht nur zehn Tage. Der Daten-Checker meldete 39 Tage ohne Werte zwischen dem 16.06. und dem 30.07. und bot für jeden einen Reparatur-Knopf an; wer ihn drückte, bekam „keine Live-/MQTT-Daten gefunden” — für Tage, deren Werte in der HA-Langzeitstatistik lagen, aus der der Checker sie zum Melden gelesen hatte. Ursache: aggregate_day holt die Stunden-Leistungskurve über get_tagesverlauf aus der HA-Historie, und die reicht nur so weit zurück wie der Recorder aufhebt (Default 10 Tage). Ohne Kurve stieg der Lauf aus, bevor er die Zähler anfasste — während der Checker 90 Tage weit prüft. Falsch war das Angebot, nicht die Bedienung. Der Vollbackfill hat den zweiten Weg längst (Stunden-Leistungen gebündelt aus der Langzeitstatistik, durchgereicht als prefetched_tagesverlauf); er lag in backfill.py fest und ist jetzt als energie_profil/lts_tagesverlauf.py herausgelöst und von beiden benutzt. Bleibt der reguläre Weg leer, holt die Reparatur dieselbe Kurve aus HA-LTS und reicht sie durch — kein zweiter Aggregations-Pfad, aggregate_day bleibt der einzige Schreiber. Gilt für den Einzeltag wie für den Bereichs-Lauf. Dazu nennt der Fehlschlag den Zustand, statt zu raten: LtsTagesverlauf.grund unterscheidet „keine Leistungs-Zuordnung” (Handgriff: Datenquellen), „HA nicht erreichbar” und „HA hat für den Tag nichts” (keine Fehlfunktion), jeder mit einem Anwender-Satz — der Bereichs-Lauf schrieb bisher pauschal „keine_daten”. Der Backfill verhält sich unverändert (frühe Abbrüche liefern weiter das leere Status-Dict, damit die Skip-Zahlen aus #190 nur echte Datenlücken zählen). (Forum simon42 #89667/72, dietmar1968)
Ein Anlagen-Ausbau ist keine Einspeise-Anomalie mehr. Die Prüfung „Einspeisung > 3× Vorjahr” kannte genau eine Ausnahme — der Vergleichsmonat liegt vor oder in der Inbetriebnahme der Anlage (#240). Eine in Stufen ausgebaute Anlage erzeugt den Sprung aber selbst: drei Meldungen, die niemand beheben kann und die von selbst nie verschwinden, weil der Vergleich an den Monatsdaten hängt und nicht an einem Zeitfenster. Neu _erzeugung_ausgebaut: ist die installierte Erzeugerleistung zwischen beiden Monaten um mindestens 10 % gewachsen (Σ get_erzeuger_kwp über die im Monat aktiven PV-/BKW-Investitionen, ADR-002/P3-a), setzt die Einspeise-Prüfung für dieses Monatspaar aus. Bewusst aussetzen statt die Schwelle skalieren: Die Einspeisung ist eine Differenzgröße (Erzeugung − Eigenverbrauch) — bleibt der Verbrauch gleich, landet vom Zubau fast alles im Netz (die gemeldete Anlage wuchs um das Vierfache, ihre Mai-Einspeisung um das Fünfzehnfache, 61 → 888 kWh); eine aus der kWp abgeleitete Schwelle wäre geraten, nicht gerechnet, und hätte den Fall auch nicht gefangen. Nur für die Einspeisung — der Netzbezug sinkt mit mehr PV und wächst mit neuen Verbrauchern (WP, E-Auto, Wallbox); dort wäre der Zubau die falsche Erklärung. (#362, kingcap1 #354)
Der Daten-Checker empfiehlt für einen Zähler ohne Statistik jetzt den Helfer über die HA-Oberfläche statt der configuration.yaml. Drei Hinweistexte der Kategorie „Sensor-Zuordnung – HA-Statistics” rieten zuerst dazu, state_class per customize in einer YAML-Datei nachzutragen — ein Weg, den viele Anwender bewusst nicht gehen. Erste Empfehlung ist ab jetzt ein Verbrauchszähler-Helfer (Einstellungen → Geräte & Dienste → Helfer) auf den vorhandenen Sensor, ohne Zyklus: er bringt die Statistik-Angaben mit, und sein Name überlebt einen Gerätetausch, weil man nur die Quelle wechselt. Ohne Zyklus deshalb, weil ein zurückgesetzter Zähler auf dem Snapshot-Pfad einen Sprung erzeugt, den eine auf Tageszähler getunte Heuristik erkennen müsste. Dazu steht in jedem der drei Texte, dass die Historie eines neuen Helfers bei null beginnt — Home Assistant sammelt Vergangenes nicht nach. Der YAML-Weg bleibt als Nebensatz stehen. Eine vierte Meldung derselben Prüfung — Counter-Sensor ohne Summen-Spalte — nannte gar keinen Weg, sondern nur das Ziel („Empfohlen: state_class: total_increasing setzen”); sie trägt jetzt denselben Text wie die anderen drei. Mitgezogen: Handbuch Daten-Checker §4.9/§5.1 (Anleitung jetzt zweigeteilt, Helfer zuerst; die beiden „ohne Summen-Spalte”-Meldungen standen bisher gar nicht in der Melde-Tabelle) und die Sensor-Referenz §10. Ein Test hält die Pflichtaussagen an allen vier Meldungen fest, damit der nächste Textdurchgang sie nicht wieder verliert. (PN Rainer 90057)
Der MQTT-Export liefert kurze Zahlen — je Größenart passend gerundet. Der Publisher rundete jeden Wert gleich auf zwei Nachkommastellen, egal ob kWh-Jahressumme, Euro-Betrag oder Prozentquote; bei 12.345,67 kWh sind die beiden letzten Stellen reine Anzeige-Länge. Gerundet wird jetzt nach der Einheit der Sensor-Definition: Energie und Mengen (kWh, kWh/kWp, km, kg) ganzzahlig, Geld auf zwei Stellen, Prozent auf eine, Leistung (kW) und dimensionslose Kennwerte (COP, Zyklen, Rang) auf zwei. Die Regel steht einmal neben den Sensor-Definitionen (services/ha_sensors_export.py::runde_exportwert) statt an jeder Sensorzeile im Route-Modul. Leitplanke: kein echter Wert kippt durch die Rundung auf 0 — wer bei seiner Stellenzahl auf 0 fiele, bekommt so viele Stellen wie nötig (höchstens drei), damit aus 0,35 kW keine 0 wird und die Rest-Prognose am Abend sichtbar bleibt. Sensor-Namen, Einheiten, Discovery-Payload und die Anzahl der Entitäten sind unverändert; ein Test misst die erzeugte Payload je Größenart und hält das fest. (PN Rainer 89905, zweiter Absatz)

[4.0.5] - 2026-07-31 — Preise je Monat · CO₂ auf dem Eigenverbrauch · eine Zahl je Kennwert

Added

Cockpit → Jahr/Gesamt: neuer Block „CO₂-Bilanz”. Er zeigt Monat für Monat die vermiedene CO₂-Menge, getrennt nach den drei Quellen — PV-Eigenverbrauch (vermiedener Netzstrom), Wärmepumpe (vermiedene fossile Wärme) und E-Mobilität (vermiedener Kraftstoff) —, mit der Autarkie desselben Monats als Linie. Wie jeder Block ist er fokussierbar, im Vollbild auf Tabelle umschaltbar und als CSV exportierbar. Zwei Kennwerte darüber mit ausgewiesenem Zeitraum: „CO₂ eingespart” (Summe des gewählten Jahres) und „CO₂ kumuliert” (gesamte Historie). Die Daten kommen aus /cockpit/nachhaltigkeit, also aus derselben Quelle wie Auswertungen → CO₂ und der HA-Sensor. Nicht zu verwechseln mit der CO₂-Amortisation unter Auswertungen → CO₂ (Herstellungs-CO₂ über die gesamte Laufzeit) — der neue Block beantwortet „wann habe ich wie viel gespart”.
Der Strompreis-Sensor lässt sich wieder zuordnen (Forum simon42 #89667/55). sensor_mapping["basis"]["strompreis"] speist die Strompreis-Mitschrift (stündlicher LTS-Mittelwert → Tages-Energie-Profil → Ø-Bezugspreis + Ø-Ladepreis der Speicher-Netzladung). Setzen ließ sich das Feld bis v3 im Sensor-Mapping-Wizard; beim V4-Umbau ist der Slot ersatzlos entfallen, während das Backend ihn weiter las — im Forum verwies ein Tester noch auf den Weg, den es nicht mehr gab. Bestehende v3-Zuordnungen waren nie betroffen und tauchen mit dem Slot wieder auf. Drei bewusste Eigenschaften: kein MQTT-Topic (ein erwartetes Topic, das niemand bedienen kann, wäre eine Lücke in der Abdeckungs-Prüfung #134), HA-only (Gateway/Inbound ausgeblendet, der API-Weg antwortet mit 400 — kein Versprechen ohne Leser) und nur bei dynamischem Tarif sichtbar (bei Festpreis gehört der Preis in die Stammdaten; ein angebotener Preis-Slot verleitet sonst zum Konstanten-Sensor).
Daten-Checker: Migrationshinweis für den BKW-Akku. INFO-Meldung für Anlagen, die die BKW-eigenen Felder speicher_ladung_kwh/speicher_entladung_kwh gepflegt haben und noch kein Speicher-Kind am Balkonkraftwerk führen — mit Monatszahl, Zeitraum, benannter Handlung und der Zusicherung, dass nichts verloren geht. Kein Umbau, nur ein Hinweis.

Changed

Der Akku am Balkonkraftwerk hat einen Erfassungsweg statt zwei. Kanon: ein BKW-Akku wird als eigene Investition vom Typ speicher mit dem Balkonkraftwerk als Parent erfasst — dieser Weg trägt Live-Leistung, Ladestand, einen eigenen Energiefluss-Knoten und den Tages-/Stunden-Zählerpfad. Die BKW-eigenen Felder speicher_ladung_kwh/speicher_entladung_kwh kennen dagegen nur einen Monatswert. Sie bleiben deshalb erfassbar (neues Feld-Attribut nur_manuell: Monatsabschluss, CSV-Import und Export unverändert — gepflegte Werte bleiben lesbar und änderbar), verschwinden aber als zuordenbare Quelle aus Datenquellen-Fläche, Topic-Liste und HA-Energie-Übernahme. Liegt heute eine Quelle darauf, zeigt die Fläche das Feld weiter an — sonst verschwände die Zuordnung unsichtbar und ließe sich nicht mehr entfernen. Der Einrichtungs-Assistent bietet den BKW-Parent erstmals an: ein Kanon, den der Einstiegspfad nicht anbietet, ist keiner.
Die Social-Media-Textvorlage ist entfernt. Der kopierfertige Monatstext hing am Teilen-Symbol im Kopf des alten Cockpits und ist mit der V4-Oberfläche (v4.0.0) unerreichbar geworden; das Handbuch beschrieb ihn bis heute mit vier Bedienschritten. Backend-Endpoint, Client-Aufruf und Handbuch-Sektion sind zurückgebaut. Das Community-Teilen bleibt vollständig erhalten (Benchmark teilen, im Browser öffnen, zurückziehen) — zwei verschiedene Dinge, die beide „teilen” heißen.
Der Daten-Checker meldet Monate ohne Tarif-Abdeckung. Die Prüfung gab es bereits, sie hing aber vollständig an anlage.installationsdatum — nullable, bei frischen Installationen also leer, und der Check wurde still übersprungen. Gemessen wird jetzt an den vorhandenen Monatsdaten; die Meldung nennt die Monatszahl und die 30-ct-Vorbelegung.
„Gültig ab” wird beim ERSTEN Tarif einer Anlage mit dem Inbetriebnahme-Datum vorbelegt — so macht es der Setup-Wizard seit jeher, die Einzelseite folgt jetzt derselben Mechanik. Ab dem zweiten Tarif bleibt „heute” richtig (Tarifwechsel). Am Feld steht der Hinweis, dass frühere Monate mit der Vorbelegung rechnen. (Auslöser: Forum simon42 #89667/60, Algie — 36 Monate importiert, danach den Tarif angelegt, überall standen die Standardpreise. Die Ursache war ein Datum, kein Rechenfehler.)
Intern (ohne Nutzer-Wirkung): die Monats-Fakten-Schicht (ADR-002/P10). services/monats_fakten.py bereitet eine Monatszeile genau einmal auf — Auflösung, Zeitraum- und Dienstwagen-Filter, Aufruf der Layer-Formeln — statt dass jede Read-Site InvestitionMonatsdaten selbst faltet. Umgehängt in sechs Schritten: Aussichten · Jahresbericht-PDF · Investitions-ROI (S2), Cockpit/CO₂ + Social (S3), Cockpit/Übersicht + HA-Export (S4), Komponenten-Dashboards + Prognose-Pfade (S5), Community-Payload (S6). Der baumweite Wächter test_wurzelmuster_konformitaet.py::test_p10_* ist scharf (funktions-granular, drei klassifizierte Ausnahme-Kategorien); die verbliebene Schuld steht gezählt in P10_NOCH_NICHT_MIGRIERT (4). Auslöser war die Drift-Inventur vom 31.07.: sechs Befunde, kein Rechenfehler im Berechnungs-Layer — sechsmal dieselbe Aufbereitungs-Struktur. Detail: docs/KONZEPT-MONATS-FAKTEN.md.
Intern (ohne Nutzer-Wirkung): drei neue Invarianten in ADR-002. P8 — ein Tarif-Wert trägt den Stichtag seines Monats (lade_tarife_fuer_anlage ohne target_date liefert den heute gültigen; für die Sicht nach vorn richtig, für jede Aussage über einen vergangenen Monat falsch). Zwei Wächter, Baseline 0, acht klassifizierte Module mit Klartext-Begründung. P9 — der BKW-Eigenverbrauch kommt aus core/berechnungen/bkw_finanz.py, nie vom Aufrufer kombiniert. P10 s. o. Dazu eine neue Layer-Formel core/berechnungen/dienstliche_ladekosten.py samt AST-Wächter (eine dienstlich…-benannte Größe darf außerhalb des Helpers nicht multipliziert werden) und der SoT models/investition.py::ERLAUBTE_PARENT_TYPEN/PARENT_PFLICHT_TYPEN, der drei uneinige Kopien der Parent-Regel ablöst (client-seitig parentTypenFuer).
Intern (ohne Nutzer-Wirkung): Doku- und Wächter-Hygiene. Die vierte CHANGELOG-Datei eedc/frontend/CHANGELOG.md ist gelöscht (eingefroren auf v3.30.1, ein einziger Commit auf ihr, kein Leser, alle 313 Versionen byte-gleich auch im Root); check:co2-roh fängt jetzt auch den Mischfall wert * FAKTOR * 1000 und beschreibt seine vier Grenzen vollständig; SENSOR-REFERENZ.md behauptete das Gegenteil des Codes zum USt-Abzug im Export-Sensor; der Symmetrie-Helfer _vier_netto_ertraege trägt seine Grenze jetzt am Helfer statt in der Fixture-Doku. Neu bzw. fortgeschrieben: BERECHNUNGEN.md §1/§3.1/§3.8/§3.10, ADR-001, ADR-002, ARCHITEKTUR.md §7, HANDBUCH_BEDIENUNG §4.4/§4.5.

Fixed

Tarife werden je Monat aufgelöst — nicht nach dem heutigen Stand. Eine Preiserhöhung schrieb bisher rückwirkend die Historie um. Sieben Fundstellen, aus der Analyse zu Forum simon42 #89667/60:
- GET /monatsdaten/{id} baute seine Tarif-Query von Hand und ließ dabei gueltig_bis und den verwendung-Filter weg: ein beendeter Tarif galt weiter, und ein später angelegter WP-/Wallbox-Spezialtarif verdrängte über ORDER BY gueltig_ab DESC den allgemeinen — er wurde zum Arbeitspreis der ganzen Anlage. Jetzt über lade_tarife_fuer_anlage(target_date=Monatserster), Defaults aus wirtschaftlichkeit_defaults statt inline 30,0/8,2.
- Der Flex-Ø (Monatsdaten.netzbezug_durchschnittspreis_cent, der abgerechnete Monatsdurchschnitt eines dynamischen Tarifs) erreichte die Tagespfade nicht: Cockpit → Tag rechnete mit dem Referenzpreis, Monat und Jahr mit dem Ø — Summe der Tage ≠ Monat, und „Ø-Preis Netz” nannte je Ebene eine andere Zahl. Der Symmetrie-Test deckte diese Achse nicht ab (nur fester Tarif geseedet) und trägt sie jetzt.
- aussichten.py lud die Tarife einmal ohne Stichtag und rechnete damit auch die Historie (E-Auto-Ersparnis, dienstliche Ladekosten, entgangene Einspeisevergütung), während die Finanz-Zeilen daneben korrekt je Monat auflösten. Die Sicht nach vorn (Hochrechnung, ausgewiesener Tarif) bleibt bewusst beim heutigen Tarif.
- Das Feld „Ø Strompreis” im Monatsabschluss erschien nach der heutigen Vertragsart — nach einem Wechsel dynamisch → fest kam man an den abgerechneten Ø eines Altmonats nicht mehr heran.
- Kosmetik ohne Verhaltensänderung: is not None statt Truthiness beim Monats-Ø, Signatur-Defaults auf die SoT-Konstanten.
Neun weitere Stellen rechneten mit dem heutigen Tarif (ADR-002/P8). Sichtbar: das WP-Dashboard summierte die Energien über die gesamte Lebensdauer und multiplizierte einmal (erledigt nebenbei den TODO „monatlicher Gaspreis-Override”); das Speicher-Dashboard löst den Basistarif des Monats jetzt im gewichteten Ø auf; aktueller_monat.py bedient jeden Monat über jahr/monat, nicht nur den laufenden; der HA-Export und core/berechnungen/alternativkosten.py bekommen den WP-Strompreis jetzt als Perioden-Mapping herein, wie den Gaspreis daneben. Eine Grenze, benannt statt kaschiert: wo die Aggregation die Monatsauflösung konstruktionsbedingt verliert (attribute_emob_pool_by_km, #262), mittelt _gewichteter_monatspreis die gültigen Monatstarife mengengewichtet — im Wallbox-Dashboard mangels Monats-kWh gleichgewichtet.
Der Börsenpreis ist kein Ladepreis bei Festpreis-Vertrag (Forum simon42 #89667/56, MartyBr). Die Kachel „Batterieladung Netz” zeigte 6,4 ct/kWh, während der Betreiber 28,67 ct zahlt: ohne zugeordneten Preis-Sensor sprang in berechne_effektiver_ladepreis der EPEX-Börsenpreis als Stundenpreis ein — gedacht als Näherung für dynamische Tarife (richtige Stundenform, fehlende Aufschläge), bei einem Festpreis schlicht der falsche Preis. Über die Kette TEP-effektiv → IMD-Ø → Bezugspreis gewann er zudem bedingungslos gegen die Handeingabe. Die Regel stand bereits im Baum („Börsenpreis ist kein Endkundenpreis”, strompreis_aggregator.py) — diese Kette hielt sich nicht daran. Der Ersatz gilt jetzt nur noch bei ausdrücklich dynamischem Tarif (Strompreis.vertragsart, Verwendung allgemein); sonst fällt die Kette auf IMD-Ø bzw. Arbeitspreis durch. Bewusst positive Evidenz statt == "fix": die Vertragsart ist ein optionales Dropdown, leer ist der Normalfall — eine Regel auf „fix” hätte die Mehrheit der Festpreis-Anlagen nicht erreicht. Sichtbare Folge für Anlagen mit dynamischem Tarif OHNE gepflegte Vertragsart: sie rechnen ab jetzt mit ihrem Referenz-Arbeitspreis statt mit dem Börsenpreis. Dazu die Gegenrichtung desselben Fehlers: die Kachel behauptete pauschal „aus der Strompreis-Mitschrift”, auch wo der Preis aus dem Tarif kam — sie benennt jetzt die tatsächliche Herkunft und sagt bei unbekannter Quelle „Herkunft unbekannt”, statt zu raten.
USt auf den Eigenverbrauch in allen vier Finanz-Sichten (#326-Inventur, Dimension 2 — bisher als „latent” geparkt). Bei Regelbesteuerung zogen nur das Cockpit und die Aussichten-Jahresprognose die USt auf den Eigenverbrauch ab. Nicht abgezogen wurde sie im Jahresbericht-PDF, im HA-Export-Sensor netto_ertrag_euro und — überraschend — in den bisherigen Erträgen der Aussichten, die den ROI-Fortschritt und die Amortisationsprognose tragen. Diese drei Zahlen lagen um den vollen USt-Betrag zu hoch (im Test-Fixture 68,40 € auf 212 €). Die Vorprüfung (Regime-Check + Satz-Default 19 %) stand doppelt im Baum und liegt jetzt als ust_eigenverbrauch_fuer_anlage in core/calculations.py; alle vier Sites rufen sie. Neuer Symmetrie-Test test_netto_ertrag_vier_wege_symmetrie.py auf EINEM Fixture mit Regelbesteuerung — genau diese Achse hat bisher keine Fixture variiert. Entwarnung an einer Stelle: der Grundpreis ist keine Divergenz, er geht nirgends in den Netto-Ertrag ein.
Der BKW-Eigenverbrauch zählt genau einmal (ADR-002/P9). Die Finanz-Zeile hat zwei BKW-Eingänge, die sich bedingt überlappen — pv_erzeugung_kwh (Erzeugung hinter dem Hauszähler, Module und BKW) und bkw_eigenverbrauch_kwh —, und alle vier Read-Sites hatten die Kombination verschieden gewählt: die Aussichten zählten beides und damit doppelt, Cockpit und PDF ließen ein BKW ohne erfasste Erzeugung ganz weg, der HA-Export trug die BKW-Ersparnis in netto_ertrag_euro gar nicht (nur im ROI-Pfad, und dort mit statischem Netzbezugspreis — P8-Klasse). Kanon: das BKW speist hinter denselben Hauszähler, seine Erzeugung gehört also in die Summe, aus der der Eigenverbrauch abgeleitet wird; der separate Term ist kein Zusatzposten, sondern der Ersatzträger für die Datenlücke „nur eigenverbrauch_kwh gepflegt”. Entschieden wird das je (BKW, Monat) im neuen SoT core/berechnungen/bkw_finanz.py, nie vom Aufrufer. Warum die Lücke überhaupt vorkommt: pv_erzeugung_kwh ist beim BKW Pflichtfeld und das einzige, das der Sensor-/MQTT-Pfad schreiben kann. Ersatzlos entfallen ist berechne_bkw_alternativkosten_ersparnis (nach dem Umbau ohne Aufrufer und Träger des statischen Preises).
Dienstliche Ladung: eine Formel für drei Sichten, PV-Ladung nicht mehr doppelt gutgeschrieben. Wer PV-Strom in einen Firmenwagen lud, bekam ihn als „eingesparter Netzbezug” gutgeschrieben (30 ct) und nur die entgangene Einspeisevergütung abgezogen (8 ct) — netto 22 ct Plus je Kilowattstunde, die das Haus nie verbraucht hat. In der Messreihe stand eine Anlage mit Dienstwagen damit über derselben Anlage ohne Auto (196 € gegen 168 €): verschenkter Strom war profitabler als verkaufter. Neue Layer-Formel core/berechnungen/dienstliche_ladekosten.py (PV-Anteil × Netzbezugspreis, Netzanteil × Wallbox-Preis, je Monat); alle drei Sichten rufen sie — cockpit/uebersicht.py (rechnete inline), aussichten.py (bewertete den Netzanteil mit dem allgemeinen statt dem Wallbox-Tarif) und ha_export.py (zog gar nichts ab, sein netto_ertrag_euro-Sensor stand entsprechend über der Kachel). Gemessen fällt der Netto-Ertrag von 196 € auf 152 €; die Anlage ohne Auto liegt mit 168 € dazwischen. Eigenverbrauch, Eigenverbrauchsquote und Autarkie bleiben exakt gleich — der Strom ist hinter dem Zähler verbraucht worden; korrigiert ist nur die Bewertung in Euro. Die AG-Erstattung steht weiterhin als Ertrag daneben, erst der Saldo ist der Vorteil. Die In-App-Warnhinweise bei „Firmenwagen” und „ausschließlich dienstliches Laden” beschrieben wörtlich das alte (falsche) Verhalten und tragen jetzt die neue Bewertung samt der Zusicherung zur Energiebilanz.
Eine CO₂-Definition im ganzen Produkt (ADR-001/DI-2 vollendet). Zwei Stellen rechneten weiter die abgelöste Formel Erzeugung × 0,38 — ein Spiegelpaar aus Monatstabelle (Client) und Tagestabelle (Backend). Beide schrieben auch der eingespeisten Kilowattstunde die volle Netzstrom-Vermeidung gut und kannten weder Wärmepumpe noch E-Mobilität; nach dem neuen Cockpit-Block standen damit drei CO₂-Zahlen im Produkt. Auswertungen → CO₂ bezieht seine Reihe jetzt aus /cockpit/nachhaltigkeit (derselbe Abruf wie Cockpit → Jahr, ein Fetch für CO₂-Sicht und Werte-Tabelle); createMonatsZeitreihe schlägt den Monat nach, statt zu rechnen, und lässt die Spalte ohne Reihe leer statt genähert. Der Tages-Pfad (tage_werte.py) ruft den Kanon und trägt bewusst nur co2_pv_kg — WP-Wärme und E-Mob-Kilometer sind Monatsgrößen —, die Spalte heißt deshalb „CO₂-Einsparung (PV)” und Σ Tage ≠ Monatswert, sobald WP oder E-Auto im Spiel sind. Sichtbare Folge: die CO₂-Zahl auf der Auswertungs-Seite wird kleiner (bei etwa hälftiger Einspeisung ungefähr um die Hälfte, gemessen 2,05 statt 6,08 t), gleichzeitig zählen WP und E-Mobilität dort erstmals mit. Der CO₂-Sensor in Home Assistant rechnete schon vorher richtig — er war es, von dem die Seite abwich. Neuer Wächter npm run check:co2-roh: CO2_FAKTOR_KG_KWH darf im Client nur noch angezeigt werden.
Aussichten, Jahresbericht-PDF, ROI, Prognose-vs-IST, Langfrist-Prognose und CO₂-Zeitreihe finden die PV wieder. Wer seine Erzeugung als einen Gesamtwert pflegt (manuell oder über einen einzigen PV-Sensor) statt je Modul, sah in diesen Sichten viel zu kleine Zahlen: die Eigenverbrauchs-Ersparnis fehlte komplett (im Beispiel 32 € statt 212 €), der Jahresbericht wies 0 kWh Erzeugung aus, der String-Vergleich −100 % gegen die Prognose, Prognose-vs-IST für jeden Monat ein IST von 0 kWh, die Langfrist-Prognose fiel auf ihre Default-Güte zurück und sagte die volle statt der halben Erzeugung voraus (6.000 statt 3.000 kWh), und die CO₂-Zeitreihe blieb ganz leer. Cockpit und HA-Sensoren waren nie betroffen. Ein Fall geht nach unten (bei der Rot-Verifikation gemessen): wer mehrere Module hat, nur einen Teil misst und keinen Gesamtwert pflegt, sah bisher die Teilsumme als Anlagenerzeugung (92 € statt 32 €) — eine Teilsumme als „Gesamt-PV” auszuweisen wäre irreführend (ADR-002/P2-A). Abhilfe: alle Module messen oder den Gesamtwert pflegen.
CO₂-Zeitreihe und Community-Payload rechnen wieder mit V2H und dem BHKW. Wer ein E-Auto mit V2H oder einen weiteren Erzeuger hinter dem Hauszähler (BHKW, Mini-KWK) hat, sah bzw. übertrug eine zu niedrige Bilanz, während das Cockpit auf derselben Seite die richtige Zahl nannte (Autarkie 90,9 % statt 85,7 %, CO₂ 538,8 kg statt 374,9 kg). Ein als dienstlich markiertes Fahrzeug zählte in beiden voll mit — Dienstwagen sind in eedc überall von der Anlagen-Auswertung ausgenommen, hier waren sie es als Letztes nicht. Der Benzin-Vergleich nutzt jetzt den gepflegten Verbrauch des jeweiligen Fahrzeugs (bei mehreren km-gewichtet) statt fester 7 l/100 km; ohne Pflege gilt der kanonische Default von 7,5 l, wodurch die ausgewiesene E-Mobilitäts-Ersparnis um gut 7 % steigt.
Anlagen ohne Pro-String-Messung können wieder am Community-Vergleich teilnehmen. eedc fand für sie keine Erzeugung, schickte eine leere Monatsliste und bekam vom Community-Server „Keine Monatsdaten vorhanden. Bitte zuerst Daten erfassen.” zurück — auch bei jahrelang gepflegten Werten; beim automatischen Teilen nach dem Monatsabschluss passierte dasselbe stillschweigend. Bereits übertragene Monate behalten ihre alten Werte, bis die Anlage das nächste Mal teilt (manuell oder nach dem nächsten Monatsabschluss); der Server bekommt nur die fertigen Zahlen, nie die Rohdaten, ein Eingriff von außen ist nicht möglich. Ebenfalls behoben: wer seine Ladedaten über evcc importiert und dort kein getrenntes „Netz”-Feld hat, meldete eine zu kleine Gesamtladung (im Testfall 150 statt 200 kWh).
HA-Sensoren tragen die Historie stillgelegter Komponenten wieder mit. Der HA-Export lud die Investitionen über aktiv_jetzt() — bei gesetztem Stilllegungsdatum fiel die gesamte Vergangenheit aus Eigenverbrauch, Autarkie, Netto-Ertrag und den Speicher-Sensoren, während das Cockpit dieselbe Anlage immer richtig rechnete. Ein stillgelegtes Gerät zählt jetzt bis zu seinem Stilllegungsdatum mit, danach nicht; deaktivierte Komponenten (aktiv = nein) bleiben wie bisher überall ausgeblendet. Dazu fehlte ist_dienstlich in der V2H-Schleife: ein dienstliches Fahrzeug, das ins Haus entlädt, zählte in den Sensoren als privater Eigenverbrauch.
Komponenten → Balkonkraftwerk zeigt eine Ersparnis. Wer nur die Erzeugung eines BKW erfasst — der vorgesehene Weg —, sah dort 0 €: die Karte bewertete ausschließlich einen separat gepflegten Eigenverbrauch, den weder der Sensor- noch der MQTT-Pfad schreibt, während das Cockpit dieselbe Energie auf der Nachbarseite immer bewertete. Der Eigenverbrauch wird jetzt aus der Hausbilanz abgeleitet (bei 1.000 kWh Erzeugung und 400 kWh Einspeisung: 180 € statt 0 €); steht daneben eine Dachanlage, bekommt das BKW seinen Anteil an der Erzeugung — an einem Hauszähler ist nicht messbar, welches Modul die verbrauchte Kilowattstunde geliefert hat. Dieselbe Karte rechnete zudem fest mit 30 ct/kWh über die ganze Historie und rechnet jetzt je Monat mit dem damals gültigen Tarif. Ohne Hauszähler-Erfassung (typisch in der Mietwohnung) weist sie die Monate als nicht bewertbar aus, statt still 0 € zu zeigen.
Komponenten → E-Auto und → Wallbox berücksichtigen das Dienstwagen-Kennzeichen. Ein als dienstlich markiertes Fahrzeug wurde dort voll als private Ersparnis ausgewiesen — in seiner eigenen Karte und, weil die Ladung anteilig verteilt wird, zusätzlich in der Ersparnis der privaten Fahrzeuge und jeder Wallbox. Cockpit, Aussichten, Jahresbericht und HA-Sensoren berücksichtigen das Flag längst; der Komponenten-Hub war die letzte Stelle ohne. Das Fahrzeug bleibt mit allen gemessenen Größen sichtbar (Kilometer, Ladung, PV-Anteil), nur seine Euro- und CO₂-Ersparnis steht auf 0 und ist als dienstlich gekennzeichnet.
Die historische Performance Ratio summierte die PV roh. Langfrist-Prognose und Trend fielen ohne Pro-Modul-Werte auf die Default-PR 1,0 zurück. Beide Pfade lesen die Monats-PV jetzt über denselben Weg wie das Cockpit.
BKW-Eigenverbrauch per MQTT überschreibt die Erzeugung nicht mehr. _MQTT_FIELD_TO_LIVE_KEY bildete eigenverbrauch_kwh auf denselben Live-Key ab wie pv_erzeugung_kwh — ein Balkonkraftwerk, das beide Topics publiziert, überschrieb damit seine eigene Erzeugung: aus 10 kWh PV-Zuwachs und 4 kWh Eigenverbrauch wurden gemessen pv = 4.0, die „Heute”-Kachel zeigte den Eigenverbrauch statt der Erzeugung. Über Home Assistant zugeordnete Sensoren waren nie betroffen.
Der Daten-Checker hält Preis- und Zählfelder nicht mehr für kWh-Sensoren (Forum simon42 #89667/54, MartyBr). Der LTS-Summen-Check meldete „kWh-Sensor(en) ohne Summen-Spalte” für den Ø Ladepreis eines Speichers (ct/kWh) — ein Preis-Sensor mit state_class: measurement ist korrekt konfiguriert und hat naturgemäß kein has_sum; die Meldung schickte auf eine Fehlersuche, die es nicht gab. Die Basis-Ebene zieht diese Grenze seit dem 04.05.2026 per Whitelist, die Investitionsebene nahm dagegen jedes zugeordnete Feld als kWh-Sensor; ebenso betroffen waren km_gefahren, ladevorgaenge, ladung_extern_euro, soc und warmwasser_temperatur_c. Gefiltert wird jetzt über die Feld-Einheit (FELD_EINHEITEN + einheit_klasse), nicht über KUMULATIVE_ZAEHLER_FELDER — dort fehlen echte kWh-Felder wie ladung_extern_kwh und v2h_entladung_kwh. Ein Wächter hält fest, dass jedes Zähler-Feld den Filter passiert.
Der Ladetarif-Hinweis im Daten-Checker war nicht abstellbar. Der Check fragte bei vorhandenem E-Auto nach einem Strompreis mit der Verwendung e-auto — die es nicht gibt (Strompreis.verwendung kennt allgemein | waermepumpe | wallbox). Der Hinweis stand damit dauerhaft bei jedem E-Auto-Besitzer, ohne dass irgendeine Eingabe ihn hätte abstellen können; ein Daten-Checker-Hinweis ohne Handgriff ist Rauschen. Gemeint war der Wallbox-Tarif (beide Dashboards lesen ihn): die Prüfung zielt jetzt dorthin, löst auch bei einer Wallbox ohne E-Auto aus und nennt die Verwendung beim Namen.
Aus der HA-Statistik werden nur noch Zählerfelder gelesen. Die Monatswert-Pfade iterierten ungefiltert über alles im Sensor-Mapping und rechneten ausnahmslos MAX(sum) − MIN(sum) — für einen Zählerstand richtig, für ein Preis-Feld die Monats-Spreizung. Folgen: der Monatsabschluss bot diesen Wert mit Konfidenz 92 an (über dem korrekt gerechneten Vorschlag), der Statistik-Import schrieb ihn persistent nach verbrauch_daten, und eine EUR/kWh-Entität wurde dabei nicht nach ct/kWh umgerechnet. Meist blieb das folgenlos, weil ein measurement-Sensor still None liefert — mit dem wieder eingeführten Strompreis-Slot wäre der Pfad aber regelmäßig belegt. Neues Prädikat ist_zaehler_differenz_feld als eine Wahrheit für Vorschau, Import und Vorschlag; keine Einheiten-Umrechnung ergänzt — die ehrliche Antwort ist, diese Felder gar nicht erst so zu lesen.
Eine Teilzeitraum-Messung überschreibt keinen Monatswert mehr (#325). Der Connector liefert die Differenz zweier Zähler-Snapshots; beginnt der erste Snapshot mitten im Monat (frisch eingerichteter Connector), misst das Delta nur einen Teilzeitraum — im laufenden Monat überschrieb es trotzdem den gespeicherten Monatswert aus dem Import und zeigte still zu wenig. Der Connector überschreibt jetzt nur noch, wenn seine gemessene Abdeckung am Monatsanfang beginnt; sonst füllt er nur, was sonst fehlt. Abgeschlossene Monate bleiben unberührt. Bewusst nicht: Import und Delta zusammenrechnen (die Abdeckung des Imports ist unbekannt) oder den Monatswert auf Tage herunterbrechen (ADR-002/P7). Betroffen ist genau der Monat, in dem die Messung beginnt; ab dem Folgemonat rechnet sich alles von selbst.
GET /monatsdaten/{id} fand die PV bei Pro-String-Erfassung nicht (Fortsetzung des v4.0.4-Fixes) und rechnete zusätzlich mit einer selbstgebauten Tarif-Query. Betrifft nur direkte API-Nutzer; die Oberfläche liest diesen Endpoint nicht.
Cockpit/Übersicht: ?jahr= filterte die PV nicht mit. Der Jahresfilter griff auf den Investitions- und Monatsdaten-Queries, nicht aber auf der PV-Auflösung — Kachel, spezifischer Ertrag und Energiebilanz trugen die PV aller Jahre. Kein Frontend-Aufrufer übergibt heute ein Jahr, es bewegt sich also keine angezeigte Zahl.

[4.0.4] - 2026-07-30 — Leere Sichten erklären sich · Balkonkraftwerk in der Prognose · PV je String bleibt gemessen

Added

Balkonkraftwerk: die Wechselrichter-Leistung lässt sich erfassen — und die Prognose hält sich daran. Ein BKW ist fast immer überbelegt: drei Module à 420 Wp ergeben 1,26 kWp, der Wechselrichter gibt aber nur 600 oder 800 W ab. Bisher gab es für diese Grenze kein Feld, und eedc prognostizierte die volle Modulleistung — an sonnigen Tagen deutlich mehr, als das Gerät je einspeisen kann. Unter Einstellungen → Investitionen (und im Setup-Wizard) steht jetzt bei jedem Balkonkraftwerk das Feld Wechselrichter-Leistung (W). Die Kappung wirkt stündlich, nicht als Deckel auf die Nennleistung: morgens und abends bleibt die volle Ausbeute stehen — dort begrenzt der Wechselrichter gar nicht —, gekappt wird nur die Mittagsspitze. Ein kWp-Deckel hätte die Randstunden mitgekürzt und läge systematisch zu niedrig. Das Feld ist optional: bleibt es leer, wird nichts gekappt — es gibt bewusst keinen Standardwert, der aus „nicht gepflegt” eine Zahl machen würde. Wer es ausfüllt, sieht seine Prognose an sonnigen Tagen sinken; das ist die Korrektur.
- Der Daten-Checker weist darauf hin, damit „leer” kein stiller Verzicht ist: Leisten die Module mehr als 800 W (die typische Einspeisegrenze) und ist keine Wechselrichter-Leistung gepflegt, erscheint eine Warnung mit der tatsächlichen Modulleistung. Unterhalb der Schwelle bleibt es still — dort ist Überbelegung nicht zu erwarten, und der Hinweis wäre reines Nörgeln.
(#347, Rainer)
Daten-Checker: „Zähler zugeordnet, aber keine Tageswerte” — mit Reparatur-Knopf daneben. Nach dem Fix in v4.0.3 steht die Sensor-Zuordnung wieder überall — die Historie davor bleibt trotzdem leer, denn für diese Tage hat nie eine Auswertung stattgefunden. Der Daten-Checker meldete dafür bisher „Zähler-Abdeckung: OK”: sachlich richtig (der Zähler ist zugeordnet) und für den Anwender trotzdem irreführend — mehrere Melder sind genau hier hängengeblieben. Neu vergleicht eedc die gespeicherten Tageszeilen der letzten 90 Tage mit dem, was die Home-Assistant-Langzeitstatistik für dieselben Tage hergibt, und meldet jeden Tag, an dem HA einen Wert hat und eedc keinen. Dabei steht der Knopf gleich mit dabei: „Zeitraum neu aggregieren” für die ganze Lücke (bis 31 Tage pro Lauf) und „Tag reparieren” je Einzeltag.
- Ehrlich über die Grenze: Reicht die Lücke weiter zurück als die HA-Historie selbst, liefert HA nichts — dann meldet eedc auch nichts und sagt stattdessen, dass sich diese Tage nicht mehr füllen lassen. Ein Knopf, der nichts holen kann, wäre schlimmer als keiner.
- Und über die Reichweite: Die Tagesreparatur heilt Tages- und Stundenwerte, nicht die Monatswerte — dafür steht der Weg über Einstellungen → Integration → Statistik-Import in der Meldung.
- Nichts davon passiert automatisch beim Start: eedc erkennt, benennt und bietet an — auslösen tut es der Anwender.
(Forum simon42, v4.0.0-Thread: pipp086, Algie; #353 coolxmad)

Fixed

Reparatur-Knöpfe melden keinen Erfolg mehr, den es nicht gab. „Mehrere Tage neu aggregieren” im Daten-Checker meldete nach dem Lauf immer „Zeitraum … neu aus HA-Statistics aggregiert” — auch dann, wenn kein einziger Tag nachgerechnet werden konnte. Der Lauf braucht nämlich mehr als den Zählerstand: ohne zugeordneten Leistungssensor (W) und ohne Home-Assistant-Historie für den Zeitraum findet er keine Kurvendaten und überspringt den Tag. Jetzt steht dort, was wirklich passiert ist — „7 Tage aggregiert, 4 ohne verwertbare Daten übersprungen” bzw. bei komplettem Leerlauf ein Hinweis samt der beiden häufigsten Ursachen. Und der Knopf wird gar nicht mehr angeboten, wenn er garantiert nichts holen kann: hat eine Anlage keinen Leistungssensor zugeordnet (und keine MQTT-Energiedaten), nennt die Meldung den Befund weiterhin, erklärt aber, dass zuerst unter Einstellungen → Datenquellen ein Leistungssensor gebraucht wird. Ein Knopf, der ins Leere läuft, ist schlimmer als keiner — der Anwender sucht den Fehler sonst bei sich.
Cockpit → Tag: „Eigenverbrauch” hieß dort etwas anderes als überall sonst. Dieselbe Kachel trug an zwei Stellen zwei verschiedene Größen: Live, Monat, Jahr und die Wirtschaftlichkeit meinen den PV-gedeckten Hausverbrauch (Direktverbrauch + Entladung aus dem Speicher), Cockpit → Tag dagegen PV-Erzeugung − Einspeisung — dort steckt also auch die Speicherladung mit drin. Die Differenz ist genau das, was an dem Tag netto in den Speicher ging; an einem gemessenen Tag waren das 12,6 gegen 11,2 kWh. Entschieden wurde benennen statt umrechnen: die Tages-Kachel heißt jetzt „PV-Eigenverbrauch” und sagt in Untertitel und Rechenweg „inkl. Speicherladung”; die Vergleichstabelle darunter genauso. Keine einzige Zahl ändert sich — beide Größen sind sinnvoll, nur hießen sie gleich.
Cockpit → Tag: der Autarkie-Rechenweg passte nicht mehr zum angezeigten Wert. Der Tooltip der Autarkie-Kachel zeigte „Eigenverbrauch ÷ Gesamtverbrauch” und rechnete das auch vor — das Backend rechnet seit v4.0.2 aber mit dem netzunabhängig gedeckten Verbrauch (Gesamtverbrauch − Netzbezug). An einem realen Tag las sich der Rechenweg dadurch als „12,6 ÷ 11,3 = 111 %”, während daneben 98,7 % stand. Ein Prozentwert über 100 kann es hier nicht geben. Formel und Rechenweg stehen jetzt auf dem tatsächlichen Zähler; der angezeigte Wert war und bleibt korrekt.
Cockpit → Tag sagt am laufenden Tag, worauf es steht. Am heutigen Tag steht die Tages-Sicht auf den abgeschlossenen Stunden, während Live „Heute” die laufende bereits mitzählt — an einer gemessenen Anlage waren das 1,5 kWh Unterschied bei identischer Datenquelle. Sachlich richtig, aber nirgends ausgewiesen: der Kopf sagte nur „Quellen: gespeichert”. Jetzt steht dort zusätzlich „Stand: n von 24 Std. · laufende Stunde fehlt”. Ändert keine Zahl.
Daten-Checker nennt bei „Einspeisung > PV-Erzeugung” die wahrscheinlichste Ursache zuerst. Die Meldung riet bisher als Erstes zu „Einspeise- und Netzbezugs-Sensor vertauscht”. Nach einer Tages-Reparatur trifft das oft gar nicht zu: die Tage stehen dann voll da, nur der Monatswert wurde nie nachgezogen. Genau das lässt sich prüfen — summieren sich die Tageswerte des Monats auf deutlich mehr als der gespeicherte Monatswert (mindestens 20 % und 20 kWh darüber), nennt die Meldung diese Ursache zuerst und beschreibt den Weg: Einstellungen → Integration → Statistik-Import, „Vorschau laden” — bereits belegte Monate stehen dort unter „Konflikte” und sind zum Überschreiben vorausgewählt, also vor dem Import einmal durchsehen. Die bisherigen Ursachen bleiben in der Meldung, nur nachgeordnet. Es gibt bewusst keine vierte Meldung über denselben Sachverhalt. (#353, coolxmad)
Daten-Checker fragt nach, wenn mehr PV verwendet als erzeugt wurde. Bisher verglich die Plausibilitätsprüfung nur Einspeisung ↔ Erzeugung. Was in den Speicher geladen wurde, kam aber ebenfalls aus der PV — die Kombination „viel eingespeist und viel geladen” bei kleiner Erzeugung blieb unbemerkt. Neu wird der ganze Stapel geprüft: Einspeisung + (Speicherladung − Netzladung) gegen die Erzeugung des Monats. Bewusst als Frage und als Warnung, nicht als Fehler — der häufigste Auslöser ist ein ungepflegtes Feld Ladung aus Netz (Arbitrage/Notladung); dann stimmt die Energie, nur die Zuordnung fehlt. Die Meldung nennt die drei möglichen Ursachen in der Reihenfolge ihrer Häufigkeit. Kleine Abweichungen (bis 2 % der Erzeugung, mindestens 5 kWh) bleiben still — Zählerstände runden, und die drei Zahlen kommen aus verschiedenen Sensoren. Rein diagnostisch: es ändert sich keine Berechnung und keine Anzeige.
Datenquellen: der Hinweis „Gesamt-Zuordnung ist wirkungslos” kam zu früh — und riet zum Falschen. Sobald ein PV-Komponentenfeld belegt war, meldete die Fläche die Zuordnung PV gesamt (kWh) als wirkungslos und bot „auf ‚keine’ setzen” an. Bei nur teilweise erfassten Strings ist der Gesamtzähler aber genau die Quelle, aus der die Anlagensumme kommt: wer dem Rat folgte, stand für die ganze Anlage auf 0. Der Hinweis erscheint für das kWh-Feld jetzt erst, wenn jede PV-Quelle einen eigenen Zähler hat. Für PV gesamt (W) bleibt es beim bisherigen Verhalten — im Live-Dashboard genügt ein einziger String-Sensor, damit der Gesamtsensor nicht mehr gelesen wird; umgekehrt löst ein reiner kWh-Zähler diesen Hinweis nicht mehr aus.
Daten-Checker erkennt Zähler ohne Summen-Spalte — die stille Ursache leerer Tageswerte. Ein kWh-Zähler kann in Home Assistant sauber aussehen und trotzdem für eedc unbrauchbar sein: steht sein state_class auf measurement statt total_increasing, führt HA für ihn nur Mittel-, Min- und Max-Werte und keine Zählerstände. eedc kann daraus keine Stunden- und Tagesdeltas bilden — Cockpit → Tag und die Stundenwerte bleiben auf 0, während die Live-Ansicht ganz normal Werte zeigt, weil sie aus den Watt-Sensoren rechnet. Genau diese Spreizung machte den Fall bisher unsichtbar: die Prüfung „kWh-Sensoren in HA-Long-Term-Statistics” fragte nur, ob der Sensor überhaupt in der Statistik steht — und das tut er in diesem Zustand. Sie meldete deshalb grün. Jetzt unterscheidet sie beide Fälle und nennt die betroffenen Zähler beim Namen, mit der Lösung dabei (state_class: total_increasing setzen, danach die Tage über die Reparatur-Werkbank neu berechnen). Wen es betrifft: vor allem Zähler, bei denen state_class von Hand nachgetragen wird — die bitShake/Tasmota-Familie setzt von sich aus keines. Für Counter-Sensoren (z. B. WP-Kompressor-Starts) gibt es die eigene Meldung: der laufende Betrieb funktioniert dort weiter, nur die Korrektur-Werkzeuge greifen nicht. (Forum simon42, v4.0.0-Thread: pipp086)
Daten-Checker prüft auch den PV-Gesamtzähler auf Langzeitstatistik. Der Sensor für PV Erzeugung Gesamt fehlte in der Prüfung „kWh-Sensoren in HA-Long-Term-Statistics” — ohne state_class liefert er für die Monatswerte still nichts, und die Reparatur-Werkzeuge greifen auf ihm nicht. Geprüft wird die Zuordnung, nicht ob die Rechnung ihn diesen Monat gerade liest: fällt ein String-Sensor aus, ist er sofort wieder die einzige Quelle.
PV-Monatswerte: gemessene Strings behalten ihren Wert, der Gesamtzähler füllt nur noch die Lücken. Bisher galt anlagenweit: sobald ein Modul für einen Monat keinen eigenen Wert hatte, wurde der Monats-Gesamtwert nach Nennleistung über alle Module verteilt — die echten Messwerte der übrigen Strings wurden dabei verworfen. Ein einziger Sensor-Aussetzer reichte, und die anderen Dächer standen für diesen Monat auf kWp-Anteilen. Jetzt gilt die Regel je Modul: ein Messwert zählt immer, verteilt wird nur der Rest (Gesamtwert − Summe der gemessenen) auf die Module ohne eigenen Wert. Wen es betrifft: Anlagen mit mehreren Strings, die teilweise messen — typisch nach einem Sensor-Ausfall, nach dem Anlegen eines neuen Strings und in allen Monaten vor der Umstellung auf Pro-String-Messung. In Komponenten → PV → Verlauf/Vergleich stehen dort ab jetzt die gemessenen Zahlen; die Anlagensumme bleibt in allen Fällen unverändert. Wer alle Strings misst oder nur einen Gesamtwert pflegt, sieht keine Änderung.
- Zielbild für die Erfassung: alle Strings erfassen und die Zuordnung „PV gesamt” auf „keine” setzen. Zusammenfassen höchstens je Ausrichtung/Neigung — sonst kann eedc die Prognose für Anlagen mit mehreren Ausrichtungen nicht mehr getrennt rechnen. Die anteilige Verteilung ist ein Übergangswerkzeug, kein Dauerzustand.
Cockpit, HA-Sensoren und Monatsbericht verlieren die Vorgeschichte nicht mehr. Wer mitten in der Historie auf Pro-String-Messung umgestellt hat, verlor in Erzeugungs-Kachel, spezifischem Ertrag und den Finanzzeilen alle früheren Monate: sobald irgendein Monat Pro-Modul-Werte hatte, zählten die Monate mit gepflegtem Gesamtwert gar nicht mehr (sie standen auf 0). Der HA-Export rechnete in dieser Lage zusätzlich mit einer Schätzung aus Einspeisung + Eigenverbrauch weiter, obwohl echte Werte vorlagen. Beide Sichten laden die Monats-PV jetzt über denselben Weg. Wen es betrifft: genau die Umstellungs-Anlagen — dort steigen Jahres-Erzeugung, spezifischer Ertrag und Netto-Ertrag auf die tatsächlichen Werte. Wer durchgehend gleich erfasst, sieht keine Änderung.
Daten-Checker rechnet Monate mit teilweise gemessenen Strings nicht mehr klein. Der Checker summierte die Pro-Modul-Werte roh und griff nur ersatzweise auf den Gesamtwert zurück. In einem Monat mit teilweiser Messung ging damit eine Teilsumme in die Prüfung — und meldete einen Ertragseinbruch, den es nicht gab: Ø Performance Ratio (Stammdaten-Prüfung), die SOLL/IST-Abweichung und die Plausibilitätsprüfung „PV ungewöhnlich niedrig/hoch” lagen daneben. Dazu kam ein Fehlalarm „Energiebilanz ergibt negativen Hausverbrauch”: fehlte die PV eines Monats, wurde sie als 0 in die Bilanz gestellt. Ist die PV eines Monats nicht auflösbar, schweigt die Bilanzprüfung jetzt, statt eine Rechnung zu bewerten, die nicht prüfbar ist.
Einzelne Monatsdaten über die API: Kennzahlen mit PV = 0. GET /monatsdaten/{id} las die PV ausschließlich aus dem Gesamt-Feld — bei Pro-String-Erfassung steht dort nichts, und Autarkiegrad, Eigenverbrauchsquote und Erträge dieser Antwort waren entsprechend falsch. Betrifft nur direkte API-Nutzer (eigene Skripte, Automationen); die Oberfläche liest diesen Endpoint nicht.
Balkonkraftwerke zählten in der Tagesprognose gar nicht mit. Wer neben seiner PV-Anlage ein Balkonkraftwerk erfasst hatte, bekam dessen Anteil in der eedc-Tagesprognose, im Stundenprofil, im Live-Wetter und in den Prognose-Sensoren für Home Assistant nicht mitgerechnet — die Prognose lag um die BKW-Leistung zu niedrig. Ursache: Die Leistung eines Balkonkraftwerks wird als Anzahl Module × Wp gepflegt; die Prognose-Gruppierung las aber nur das kWp-Feld, das dabei leer bleibt, und ließ die Komponente deshalb ganz aus. Die 14-Tage-Aussicht rechnete sie mit — dieselbe Anlage hatte damit zwei verschiedene Prognosen für denselben Tag. Beide Sichten lesen die Leistung jetzt gleich. Wen es betrifft: alle Anlagen mit mindestens einem Balkonkraftwerk. Bei gemischtem Bestand (PV + BKW) steigen die Prognosewerte sichtbar um den BKW-Anteil; eine reine BKW-Anlage rechnete bisher ersatzweise mit der Anlagen-Gesamtleistung und rechnet jetzt mit der Summe ihrer Komponenten. Anlagen ohne Balkonkraftwerk sind unverändert — auf die Nachkommastelle.

(Zusammen mit #347 gefunden: die beiden Fehler zeigten in entgegengesetzte Richtungen und trafen dieselben Anlagen.)
JSON-Import: die Sensor-Zuordnung der Komponenten geht nicht mehr verloren. Der JSON-Export ist kein Datenbank-Backup, sondern der Weg für einen Umzug oder einen sauberen Neuanfang — für die vollständige Wiederherstellung gibt es das Home-Assistant-Backup (Add-on, am besten zu jedem Release) bzw. bei der Standalone-Installation die Sicherung des eedc-Verzeichnisses. Auch für den Umzug galt aber bisher: beim Einspielen verlor man die Zuordnung aller Komponenten — Speicher, Wallbox, PV-Strings, Wärmepumpe. Der Import meldete das als Warnung, die im Erfolgs-Rauschen unterging; sichtbar wurde es erst daran, dass Stundenwerte, Prognose-IST, Heatmap und Monatsbericht für die betroffenen Komponenten leer blieben. Besonders bitter beim erneuten Einspielen einer korrigierten Datei: eine vorher funktionierende Zuordnung war danach weg.
- Ursache: Beim Import bekommen alle Komponenten neue interne Nummern, und die Zuordnung hängt genau an diesen Nummern — die Datei enthielt sie nicht, also konnte der Import sie nicht umschreiben und hat sie verworfen.
- Jetzt trägt die Datei die Nummern mit (Dateiformat 1.3), und der Import schreibt die Zuordnung auf die neuen Komponenten um — für die Auswertungen wie für die Anzeige unter Einstellungen → Datenquellen. Das Ergebnis meldet, für wie viele Komponenten die Zuordnung übernommen wurde.
- Ältere Dateien (Format 1.0–1.2) lassen sich nicht umschreiben — ihnen fehlen die Nummern. Dort bleibt es beim bisherigen Verhalten; der Import sagt jetzt aber ausdrücklich, dass die Datei aus einer älteren Version stammt und welche Einträge deshalb neu zuzuordnen sind.
- Basis-Zähler (Einspeisung, Netzbezug, PV gesamt) waren nie betroffen und bleiben es auch — sie hängen an keiner Komponenten-Nummer.
- Nicht auflösbare Einträge werden entfernt statt stehengelassen: eine Zuordnung zu einer Komponente, die es nicht mehr gibt, wäre für alle Auswertungen tote Last.
(#353, coolxmad)

[4.0.3] - 2026-07-29 — Zugeordnete Sensoren wirken überall · Daten-Checker weist den richtigen Weg

Fixed

In der Datenquellen-Fläche zugeordnete Sensoren wirken jetzt überall — Cockpit und Daten-Checker bleiben nicht mehr leer. Wer seine Sensoren ab v4.0.0 über Einstellungen → Datenquellen oder im Setup-Wizard über „Energiekonfiguration aus Home Assistant übernehmen” zugeordnet hat, sah ein widersprüchliches Bild: die Fläche zeigte den Sensor samt aktuellem Zählerstand, das Live-Dashboard lief — aber Cockpit → Tag/Monat/Jahr, das Energieprofil und die Monatsabschluss-Vorschläge blieben leer, und der Daten-Checker meldete „Kein Basis-Zähler für: Einspeisung, Netzbezug” für genau die Zähler, die eine Zeile darüber mit ihrem Wert standen.
- Ursache: Die neue Fläche schrieb die Zuordnung nur als Herkunfts-Angabe („dieses Feld kommt aus Home Assistant, Entität X”). Die Auswertungen zählen ihre Zähler aber über die Sensor-Zuordnung der Anlage auf — und die blieb leer. Beide Angaben werden ab jetzt gemeinsam geschrieben; das war die eine Stelle, an der die neue Oberfläche eine halbe Wahrheit hinterließ.
- Wen es betrifft: vor allem Neuinstallationen ab v4.0.0 sowie alle, die seither eine Zuordnung in der Fläche geändert oder ergänzt haben (z. B. eine neu angelegte Komponente). Wer aus v3 aktualisiert und seine Zuordnung nicht angefasst hat, war nie betroffen — dort steht sie noch aus dem alten Wizard. Anlagen ohne Home Assistant (MQTT/Standalone) waren ebenfalls nicht betroffen.
- Was beim Update passiert: Eine einmalige Reparatur zieht bestehende Zuordnungen selbsttätig nach. Es muss nichts neu zugeordnet werden, es geht nichts verloren, und wer eine Quelle bewusst auf „keine” oder MQTT gestellt hat, behält diese Wahl.
- Vergangene Tage: Die Zählerstände wurden die ganze Zeit mitgeschrieben — die Historie ist also da, nur nicht verrechnet. Sie lässt sich unter Einstellungen → Energieprofil-Pflege mit „Tag neu berechnen” bzw. „Mehrere Tage neu aggregieren” nachziehen. Ab dem Update rechnen neue Tage von selbst richtig.
(Forum simon42, Beiträge 36–41 im v4.0.0-Thread: Algie und CHI3fx117)
Daten-Checker: die Meldungen führen wieder dorthin, wo man es repariert. Sechs Meldungen verwiesen weiterhin auf den Sensor-Mapping-Wizard, den v4.0.0 durch die Datenquellen-Fläche abgelöst hat — der Link leitete zwar um, der Text schickte aber sichtbar an eine Stelle, die es nicht mehr gibt. Alle Meldungen zeigen jetzt auf Einstellungen → Datenquellen. Nebenbei sind die internen Kürzel raus (leistung_w in einer Anwender-Meldung), und die LTS-Hinweise nennen die Feld-Bezeichnung statt des Roh-Schlüssels („Basis: Einspeisung” statt „Basis: einspeisung”). (Forum: Algie, pipp086)
Daten-Checker sagt jetzt, wie weit sein „alles in Ordnung” reicht. Wer seine Monatsdaten importiert oder von Hand pflegt, bekam die grüne Meldung „Basis-Zähler über … befüllt” — die sich wie eine Gesamt-Freigabe las. Sie gilt aber nur für die Monatsauswertungen: Tages- und Stundenwerte lesen ausschließlich kumulative kWh-Zähler, ohne sie bleiben Cockpit → Tag und die Stundenwerte leer. Genau diese Kombination (voller Monat, leerer Tag, stiller Checker) stand im Forum. Der Satz steht jetzt in der Meldung; grün bleibt es trotzdem — eine importiert gepflegte Anlage soll keine Dauerwarnung bekommen.
Cockpit → Aussicht: keine „verbleibende” Menge, wenn das heutige IST unbekannt ist. Solange für heute noch kein gemessener PV-Wert vorliegt, wurde er als 0 behandelt — die Zeile „verbl.” behauptete daraufhin die volle Tagesprognose als noch ausstehend. Unbekannt ist aber keine Null: ohne gemessenen Wert entfällt die Zeile jetzt. Eine echte 0 („PV noch nicht gestartet”) bleibt eine gültige Aussage und zeigt weiterhin die volle Restmenge.

[4.0.2] - 2026-07-28 — Speicher rechnet mit der nutzbaren Kapazität · Prognose folgt dem Wettermodell · Autarkie wieder plausibel

Added

String-Tabelle: „Anteil”-Spalte, Summenzeile und ein Satz zur Performance. In Komponenten → PV → Vergleich stand die Spalte Performance direkt neben dem absoluten Ertrag — und wurde als Rangliste der Dächer gelesen: „das kleine Dach ist 20 % besser, liefert aber weniger”. Beide Zahlen stimmten, sie beantworten nur verschiedene Fragen. Performance misst jeden String gegen seine eigene Prognose, in der Ausrichtung und Neigung schon stecken; für den Vergleich der Dächer untereinander zählt kWh/kWp. Das steht jetzt als Satz über der Tabelle. Neu daneben: die Spalte Anteil (Gewicht am Gesamtertrag) und eine Summenzeile mit kWp, SOLL, IST und Gesamt-kWh/kWp — damit ist auch die Gesamt-Modulleistung direkt ablesbar. Ein einzelner String bekommt weiterhin keine Summenzeile. (Rainer, PN)
Stundenwerte der Aussicht zeigen für heute das gemessene IST. Steht der Tages-Picker in Cockpit → Aussicht → Stundenwerte auf heute, erscheint neben der Prognose die Spalte PV IST mit den bereits vergangenen Stunden; die Summenzeile addiert nur das Gemessene. Bisher musste man für denselben Blick in die Auswertungen wechseln. Für andere Tage bleibt die Tabelle unverändert — dort gibt es kein IST. (Rainer, PN)
PV-Module: Querprüfung von Modulanzahl × Wp gegen die eingetragene Leistung. Wer sich bei den optionalen Modul-Details vertippt, sieht die Abweichung jetzt im Formular („Berechnete Leistung: 7,20 kWp — weicht von der eingetragenen Leistung (4,00 kWp) ab”), und der Daten-Checker nennt den betroffenen String beim Namen statt nur die Anlagensumme zu bemängeln. Die Warnung blockiert nichts: die Modul-Details bleiben optional, maßgeblich bleibt das Feld Leistung (kWp). (Rainer, PN)

Changed

Datenquellen: „ohne Quelle” heißt nicht mehr automatisch „hier fehlt was”. Die Zuordnungs-Fläche zählte jedes leere Feld und färbte den Block-Kopf amber („8 Felder · 3 ohne Quelle”). Auf einer richtig eingerichteten Anlage sind das aber gerade die Felder, die leer sein sollen — und die Meldung lud dazu ein, sie trotzdem zu füllen. Genau das führt in die Irre: wer die PV-Erzeugung je Modul erfasst, soll den Anlagen-Sammelzähler leer lassen. Jetzt sagt die Fläche bei jedem Feld, woran du bist:
- Pflichtfelder tragen einen roten *. Fehlt dort die Quelle und ist kein Ersatzweg belegt, steht der Hinweis rot und automatisch aufgeklappt — er nennt den passenden Sensortyp, statt stumm zu bleiben.
- Optionale Felder bleiben leise grau. Der Zähler im Block-Kopf zählt nur offene Pflichtfelder: steht dort nichts, ist die Zuordnung fertig.
- Felder, die an anderer Stelle erfasst werden, nennen jetzt den Grund statt „keine Quelle” zu melden — PV-Erzeugung und -Leistung (anlagenweit oder je Modul), „Netz kombiniert (±)” gegenüber getrennten Einspeise-/Bezugs-Sensoren, und die Heimladung am E-Auto, sobald eine Wallbox existiert.
- Alle Feld-Hinweise überarbeitet: die 13 Leistungs- und Ladestand-Felder hatten bisher überhaupt keinen (also kein ⓘ), und einzelne Texte waren überholt — beim Speicher stand „kein MQTT-Topic”, obwohl es längst eines gibt.
„Keine Quelle” bleibt ausdrücklich kein Fehler: alle kWh-Felder lassen sich im Monatsabschluss auch von Hand pflegen. Rot heißt „hier fehlt noch etwas”, nicht „falsch”.

Fixed

Tages-Vorschau: die Autarkie kann nicht mehr über 100 % steigen. In Cockpit → Aussicht und Auswertungen → Prognose stand über der Stunden-Vorschau ein Autarkiegrad, der an sonnigen Tagen mit ladendem Speicher bis zu 125 % erreichte — eine Zahl, die es nicht geben kann. Ursache: die Vorschau setzte den PV-Eigenverbrauch ins Verhältnis zum Tagesverbrauch. Was in den Speicher geladen wird, ist aber Eigenverbrauch der Anlage und noch kein Verbrauch des Tages — an einem Tag mit viel Sonne und wenig Last wird der Zähler dadurch größer als der Nenner. Die Vorschau rechnet jetzt wie alle anderen Sichten: Autarkie = (Verbrauch − Netzbezug) ÷ Verbrauch. Die angezeigten Werte sinken damit auf plausible Größen; an Tagen ganz ohne Netzbezug stehen weiterhin 100 %. Alle übrigen Autarkie-Anzeigen (Monat, Jahr, Live) waren nie betroffen — sie rechneten schon immer so.
Speicher ohne gepflegte Kapazität: keine erfundene Ersparnis mehr. Wer beim Speicher das Feld Kapazität (kWh) leer gelassen hat — es ist optional —, bekam trotzdem überall Zahlen: eedc rechnete still mit 10 kWh. Daraus entstand in Auswertungen → ROI eine Jahres-Ersparnis samt Amortisationszeit und in Komponenten → Speicher eine Vollzyklen-Zahl, die beide nichts mit der Anlage zu tun hatten — bei einem 20-kWh-Speicher die Hälfte, bei einem 5-kWh-Speicher das Doppelte. Was sich sichtbar ändert: Ohne gepflegte Kapazität stehen diese Felder jetzt auf „—” und sagen daneben, warum („keine Kapazität gepflegt”), mit Verweis auf die Investitionspflege; die Komponente selbst bleibt mit ihren Kosten in der Liste. Der Daten-Checker hatte den fehlenden Wert schon immer gemeldet — jetzt hat die Meldung auch Folgen. Wo bereits Lade- und Entladewerte erfasst sind, ändert sich nichts: die Wirtschaftlichkeit rechnet dort aus den gemessenen Werten und braucht die Kapazität gar nicht. Wer die Kapazität gepflegt hat — der Normalfall —, sieht keinerlei Änderung.
Wettermodell: die eedc-Prognose folgt jetzt deiner Wahl — auch im Home-Assistant-Export. Unter Einstellungen → Anlage lässt sich ein Wettermodell festlegen (Standard: „Automatisch”). Das Live-Wetter, die 14-Tage-Wettertabelle und die OpenMeteo-Spalte der Aussicht nutzten es längst — die eedc-eigene Tagesprognose nicht: sie rechnete an jeder Stelle mit „Automatisch”. Auf derselben Seite standen dadurch ein OpenMeteo-Balken aus dem gewählten Modell und ein eedc-Wert aus einem anderen, und die Prognose-Sensoren in Home Assistant folgten dem eedc-Wert. Wen es betrifft: ausschließlich Anlagen mit einem anderen Modell als „Automatisch”. Wie viele das sind, lässt sich hier nicht feststellen — eedc erhebt keine Nutzungsdaten. Was sich sichtbar ändert: Tagesprognose heute/morgen/übermorgen, Stundenprofil, die Vorschau „Speicher voll um …” und die MQTT-/HA-Prognose-Sensoren springen einmalig auf das gewählte Modell. An der Demo-Anlage nachgemessen (München, 20,8 kWp, 28.07.2026): mit ICON-EU heute −1,7 kWh und morgen −14,0 kWh, mit MeteoSwiss ICON-CH2 +0,9 / −2,9 / +3,3 / +12,4 kWh über die vier Prognosetage. Bei „Automatisch” ändert sich nichts — auf die Nachkommastelle gegengemessen. Modelle mit kurzem Vorhersagehorizont (ICON-D2: 2 Tage) decken weiterhin nur ihre eigenen Tage ab; die übrigen kommen wie bisher aus „Automatisch”, erkennbar an der Quellen-Angabe der Prognose.
Nicht mehr verfügbare Wettermodelle fallen sauber auf „Automatisch” zurück, statt die Prognose zu leeren. Beim Nachmessen des Punktes darüber kam heraus: Open-Meteo liefert für ECMWF Seamless, MeteoSwiss Seamless und ECMWF IFS (9 km) keine Strahlungsdaten mehr — die ersten beiden Namen kennt der Dienst gar nicht mehr, das dritte Modell antwortet mit einer vollständig leeren Vorhersage. Bisher fiel das nicht überall auf, weil die eedc-Prognose ohnehin mit „Automatisch” rechnete; mit der Umstellung oben hätten diese Anlagen ihre Prognose komplett verloren (leere Kacheln, fehlende HA-Sensoren). Jetzt erkennt eedc die leere Antwort, rechnet mit „Automatisch” weiter und schreibt es ins Protokoll; die Prognose weist „best_match” als Quelle aus. Wer eines dieser drei Modelle eingestellt hat, bekommt also dieselben Zahlen wie bisher — die Modellwahl greift dort schlicht nicht. Das Aufräumen der Auswahlliste selbst steht noch aus.
Frische Installation: die Tagesprognose zeigt jetzt die PV-Vorschau, statt eine Fehlermeldung. In Cockpit → Aussicht → Stunden-Prognose/Stundenwerte und in Auswertungen → Prognose verlangte die Tagesprognose mindestens 3 vollständige Tage Energieprofil — und verweigerte ohne sie die ganze Antwort („Zu wenig historische Energieprofil-Daten”). Mitgefallen ist dabei der PV-Teil, der gar keine Historie braucht: er kommt aus Wetterdienst und Nennleistung und stünde vom ersten Tag an zur Verfügung. Betroffen war damit jede neue Installation in ihren ersten Tagen. Jetzt kommt die Antwort: PV-Stundenverlauf und PV-Tagessumme stehen, und ein Hinweis über Chart und Tabelle sagt, dass die Verbrauchsprognose noch Historie sammelt. Verbrauch, Netzbezug, Einspeisung, Eigenverbrauch, Autarkie und die Speicher-Vorschau bleiben in dieser Zeit leer („—”) — bewusst keine 0, denn eine 0 läse sich wie ein gemessener Wert. Sobald drei Tage aufgezeichnet sind, füllen sie sich von selbst. Für Anlagen mit Historie ändert sich nichts.
Komponenten-Liste: PV-Module zeigen wieder ihre Werte. In Einstellungen → Komponenten blieb die graue Detailzeile ausgerechnet bei den PV-Modulen leer, während Speicher, Wärmepumpe, Wallbox, Wechselrichter und Balkonkraftwerk ihre Eckdaten nannten. Ursache: PV-Module wurden mit den Feldern des Balkonkraftwerks gelesen, die es bei ihnen nicht gibt. Sie zeigen jetzt Leistung (kWp), Modulanzahl und Wp pro Modul — die kWp auch dann, wenn sie bei Import-/Altbestand nur im Detail-Feld gepflegt ist (#229). (Rainer, PN)
Günstig-Schwelle: 0 % sagt jetzt, was es bedeutet. Der Wert 0 war schon immer erlaubt, schaltet die Schwelle aber faktisch ab — es zählen dann wieder allein die 5 günstigsten Stunden je Fenster. Das stand nirgends; jetzt steht ein Hinweis am Feld, in der Sensor-Referenz und im Handbuch. Der Standard war und ist 10 %; kein Update hat den Wert je auf 0 gesetzt (Model-Default, Migration und API stehen übereinstimmend auf 10). (Rainer, PN)

⚠ Nachträglich richtiggestellt (August 2026): Die Aussage „0 schaltet die Schwelle faktisch ab” war falsch. Bei 0 % liegt die Schwelle genau auf dem optimierten Ø — günstig ist dann alles darunter. Abgeschaltet hat eedc sie nie; der damalige Deckel auf die 5 günstigsten Stunden je Fenster hat den Unterschied verdeckt. Der Rechenweg war und ist derselbe, korrigiert wurde der Text am Feld und in der Doku.
Speicher-Vollzyklen: eine Zahl statt drei. Dieselbe Kachel „Vollzyklen” rechnete je nach Sicht verschieden — Cockpit → Tag zählte Ladestands-Bewegungen, Cockpit → Monat/Jahr, der Komponenten-Hub und der PDF-Jahresbericht die geladene Energie, der HA-Sensor die entladene. Auf derselben Anlage standen dadurch Zahlen nebeneinander, die um den Speicher-Wirkungsgrad auseinanderlagen, und die Tageswerte summierten sich nicht auf den Monat. Ab jetzt gilt überall: Vollzyklen = entladene Energie ÷ Kapazität — die Größe, auf die auch Hersteller-Garantien zielen.
- Was sich sichtbar ändert: In Komponenten → Speicher, Cockpit → Monat/Jahr und im PDF-Jahresbericht sinkt die Zyklenzahl um den Wirkungsgradverlust (typisch 5–10 %, bei schwächeren Speichern mehr). Der HA-Sensor eedc_speicher_zyklen bleibt unverändert — er rechnete schon immer so. Cockpit → Tag zeigt jetzt dieselbe Größe wie Monat und Jahr statt der Ladestands-Bewegungen.
- Die Ladestands-Bewegungen sind nicht verschwunden, sie heißen nur ehrlich: „SoC-Hübe”, als optionale Spalte in der Energieprofil-Tagestabelle. Sie sind die einzige Zahl, die eine schonende Fahrweise abbildet — wer den Speicher zwischen 10 und 90 % fährt, sieht dort 0,8 pro vollem Hub statt 1,0. Dafür braucht es einen SoC-Sensor.
- Warum die Brutto-Kapazität im Nenner bleibt: Die optionale „nutzbare Kapazität” ist bei den meisten Anlagen nicht gepflegt; ein Nenner, der je nach Pflegezustand wechselt, wäre unberechenbarer als ein durchgehend leicht konservativer Wert. Sie wirkt weiterhin auf den Wirkungsgrad.
Speicher: eedc nimmt keinen Ziel-Ladestand an. Auf die Rückfrage, woher eedc den gewünschten SOC kenne: Vollzyklen und Wirkungsgrad kommen aus gemessenen Lade- und Entlademengen — eine schonende Fahrweise steckt dort bereits drin. Angenommen wird nur an zwei klar benannten Stellen: in der Wirtschaftlichkeits-Prognose, solange keine Messdaten vorliegen (250 Vollzyklen pro Jahr), und in der Tages-Vorschau „Speicher voll um …”. Beides steht jetzt in Berechnungen §3.3. Beide Stellen rechnen ab sofort mit der nutzbaren Kapazität — s. den Punkt darunter. (Rainer, PN)
Speicher-Vorschau und -Prognose rechnen mit der nutzbaren Kapazität. Beim Speicher gibt es zwei Kapazitätsfelder: die Kapazität (kWh) vom Typenschild und die optionale nutzbare Kapazität (kWh) — das, was nach Entladetiefe und Reserve wirklich durch den Speicher geht. Zwei Rechnungen benutzten bisher die Typenschild-Zahl, obwohl sie eine durchgefahrene Energiemenge meinen: die Tages-Vorschau „Speicher voll um …” lud von 0 auf 100 % (wer bei 90 % abriegelt, ist real früher voll), und die Wirtschaftlichkeits-Prognose rechnete Kapazität × 250 Zyklen × Wirkungsgrad. Beide setzen jetzt die nutzbare Kapazität ein.
- Wen es betrifft: ausschließlich Anlagen, bei denen das Feld „nutzbare Kapazität” gepflegt ist. Es ist optional; wer es nie ausgefüllt hat, sieht keinerlei Änderung — dann bleibt die Typenschild-Zahl die Rechengröße, ohne Hinweis und ohne Nachfrage. Das ist Absicht: die Typenschild-Zahl ist nicht falsch, sondern die andere Lesart derselben Größe.
- Was sich sichtbar ändert (gemessen an der Demo-Anlage, 15,4 kWh Typenschild gegen 13,9 kWh nutzbar, Prognosetage 28.07.–02.08.2026): In Cockpit → Aussicht und Auswertungen → Prognose nennt die Erläuterung unter dem Chart jetzt „13,9 kWh nutzbar” statt 15,4 kWh. Die Kachel „Speicher voll” rückt an einem der sechs Tage von 11:00 auf 10:00 — an den übrigen bleibt sie gleich, weil die Vorschau in ganzen Stunden rechnet. Mit ihr ändern sich die anderen Kacheln desselben Tages: ein kleinerer Puffer nimmt weniger Überschuss auf, also Einspeisung +0,8 bis +1,1 kWh und Eigenverbrauch entsprechend niedriger. Die Autarkie kann an Tagen, an denen der Speicher abends früher leer ist, ebenfalls etwas sinken — an Tagen ohne Netzbezug bleibt sie bei 100 %. (Die ursprünglich hier genannte Spanne „−1,7 bis −3,2 Prozentpunkte” war vor dem Autarkie-Fix weiter unten gemessen und ist damit hinfällig.) Der Home-Assistant-Sensor eedc_speicher_voll_um zieht mit — er zeigt dieselbe Vorschau und darf keine zweite Uhrzeit nennen.
- In Auswertungen → ROI sinkt die jährliche Einsparung des Speichers — aber nur, solange keine Lade- und Entladewerte erfasst sind. Gemessen an derselben Anlage ohne Messdaten: 431,59 € → 389,55 € pro Jahr, CO₂ 1.389,8 → 1.254,5 kg. Wo Messdaten vorliegen — der Regelfall bei laufenden Anlagen —, ändert sich nichts: dort rechnet eedc aus der gemessenen Entladung und liest die Kapazität gar nicht (an der Demo-Anlage gegengeprüft: 446,24 € vorher wie nachher). Die angezeigte Kapazität der Komponente bleibt überall die Typenschild-Zahl — sie beschreibt das Gerät, sie ist keine Rechengröße.
- Die Vollzyklen bleiben ausdrücklich, wie sie sind: sie rechnen weiter gegen die Typenschild-Kapazität. Ihr Nenner darf nicht davon abhängen, ob jemand ein optionales Feld ausgefüllt hat — sonst wäre dieselbe Anlage nicht mehr mit sich selbst vergleichbar. Begründung im Punkt „Speicher-Vollzyklen: eine Zahl statt drei” weiter unten.
Wärmepumpe: eine Ersparnis-Zahl statt zweier. Für dieselbe Wärmepumpe nannte Auswertungen → ROI eine niedrigere jährliche Einsparung als Cockpit → Aussicht, der HA-Sensor und der PDF-Bericht. Grund: die ROI-Seite rechnete, was die alte Heizung gekostet hätte, ohne den Wirkungsgrad des alten Kessels. Ein Gaskessel muss für 15.000 kWh Wärme rund 16.700 kWh Gas verfeuern, nicht 15.000 — die eingesparten Brennstoffkosten waren dadurch zu niedrig angesetzt. Alle Sichten rechnen jetzt gleich.
- Was sich sichtbar ändert: in Auswertungen → ROI steigen bei jeder Wärmepumpe die jährliche Einsparung und die CO₂-Einsparung, die Amortisationszeit sinkt entsprechend. Beispiel mit den Standardwerten (15.000 kWh Wärme, Gas 12 ct): 900 € → 1.100 € pro Jahr. Bei Öl fällt der Unterschied größer aus. Das ist die Korrektur, kein neuer Fehler — die anderen Sichten rechneten schon immer so.
- Wer „Strom (Direktheizung)” als alten Energieträger gewählt hat, sieht die Bewegung in die andere Richtung: eedc rechnete einer Strom-Direktheizung bisher an allen Stellen den Wirkungsgrad eines Gaskessels an, obwohl eine Widerstandsheizung verlustfrei heizt. Ihre WP-Ersparnis war dadurch um gut 11 % zu hoch und sinkt jetzt — in Cockpit, Aussicht, HA-Sensor und PDF. Für Gas und Öl ändert sich an diesen Stellen nichts.
Der Komponenten-Hub zeigt jetzt auch die nur im Detail-Feld gepflegte Nennleistung. Dieselbe Datenlage wie im Punkt darunter, nur eine Schicht später: die Auswertungen im Hintergrund fanden die kWp inzwischen — die Anzeige im Komponenten-Hub bekam vom Server aber weiterhin nur das Feld Leistung (kWp) zu sehen und ließ die Angabe deshalb ganz weg. Wen es betrifft: wieder nur Import- und Altbestand (#229) — wer seine Komponenten im Formular oder im Setup-Assistenten angelegt hat, ist nicht betroffen, denn kein heutiger Eingabeweg erzeugt den Zustand „kWp nur im Detail-Feld”. Was sich dort sichtbar ändert:
- Komponenten → beliebiger Typ → Einstellungen — die Zeile „Leistung … kWp” stand für die betroffene Komponente gar nicht da. Sie erscheint jetzt mit dem gepflegten Wert.
- Komponenten → PV → Struktur — in der Übersicht Wechselrichter → Module stand beim betroffenen Modul nur die Ausrichtung („Süd”), jetzt „8,4 kWp · Süd”.
- Komponenten → PV → Verlauf, und nur dort, wo eedc keine Messwerte je Modul hat und die Gesamterzeugung nach Nennleistung aufteilen muss: das betroffene Modul bekam 0 kWh und die übrigen Module entsprechend zu viel. Die Aufteilung stimmt jetzt. (Wer Pro-String-Sensoren hat, sieht ohnehin die Messwerte — dort ändert sich nichts.)
- Monatswerte erfassen — die Kopfzeile der Balkonkraftwerk-Sektion nennt die Leistung wieder („0,8 kWp”); bei einem Balkonkraftwerk, dessen Leistung als Wattzahl × Modulanzahl hinterlegt ist, fehlte sie. Die Zahl steht jetzt außerdem in deutscher Schreibweise mit Komma.
Diese Änderungen sind die Korrektur, nicht ein Fehler — die Leistung war immer gepflegt, sie kam nur an der Anzeige nicht an. Das Eingabefeld selbst bleibt unverändert: es zeigt weiter genau das, was gespeichert ist, damit Speichern nie einen abgeleiteten Wert festschreibt.
Komponenten → Einstellungen: keine doppelte Nennleistung mehr, und Nachkommastellen bleiben stehen. Unter den benannten Stammdaten-Zeilen listet eedc zusätzlich alle Detail-Felder der Komponente auf. Dabei erschien die Nennleistung bei betroffenen Komponenten zweimal — einmal als „Leistung 8,4 kWp” und darunter noch einmal als rohes Detail-Feld „kwp 8”. Die zweite Zahl war zudem falsch, weil diese Liste jeden Wert auf ganze Zahlen rundete. Die Dublette entfällt, und die Rundung ebenfalls: ein Wirkungsgrad von 20,75 % stand dort bisher als „21”. Das betrifft alle Anlagen, nicht nur Import-Bestände — überall, wo ein Detail-Feld Nachkommastellen hat.
Eine nur im Detail-Feld gepflegte Nennleistung zählt jetzt überall mit. Die Nennleistung einer PV-Komponente kann an zwei Stellen stehen: im Feld Leistung (kWp) der Investition oder — bei importierten und sehr alten Beständen — nur in den Detail-Feldern der Komponente (kwp/leistung_kwp, beim Balkonkraftwerk auch leistung_wp × anzahl). Fast jede Auswertung las bisher nur das Leistungsfeld und sah dort still eine 0. Einzelne Sichten waren schon geheilt, die übrigen nicht — dieselbe Anlage bekam so je nach Seite verschiedene kWp. Wen es betrifft: Wer seine Komponenten im Formular oder im Setup-Assistenten angelegt hat, ist nicht betroffen — beide schreiben die kWp ins Leistungsfeld, und kein heutiger Eingabeweg erzeugt den Zustand „kWp nur im Detail-Feld”. Es geht um Import- und Altbestand (#229). Was sich dort sichtbar ändert:
- PVGIS-Prognose der Anlage — das betroffene Modulfeld fiel bisher komplett aus der Prognose: Jahresertrag, Monatswerte, Gesamt-kWp und die String-Liste waren alle zu klein. Es zählt jetzt mit, die Werte steigen entsprechend.
- PVGIS-Prognose für ein einzelnes Modul — meldete bisher den harten Fehler „PV-Modul hat keine Leistung (kWp) definiert” für ein Modul, dessen Leistung gepflegt ist. Liefert jetzt die Prognose. Ist wirklich nirgends eine Leistung hinterlegt, kommt der Hinweis weiterhin.
- PV-Strings-Vergleich (Jahr und Gesamtlaufzeit) — der betroffene String bekam SOLL 0 und damit −100 % Abweichung, alle anderen Strings entsprechend zu viel, weil die Gesamt-kWp als Nenner zu klein war. SOLL-Werte und Abweichungs-Prozente stimmen jetzt.
- Cockpit-Kachel „Anlagenleistung” und der spezifische Ertrag derselben Seite — beide hingen an derselben Summe. Die Anlagenleistung steigt auf den richtigen Wert, der spezifische Ertrag sinkt entsprechend (sein Nenner war zu klein). Der HA-Sensor spezifischer_ertrag_kwh_kwp ändert sich mit — er ist mit der Kachel gekoppelt.
- ROI und CO₂ je Komponente — das betroffene Modul bekam Anteil 0, also 0 € Einsparung, 0 kg CO₂ und keine Amortisation, während die übrigen Module derselben Anlage zu viel zugerechnet bekamen (gemessen: 0 %/100 % statt 60 %/40 %). Die Verteilung stimmt jetzt.
- CO₂-Amortisation (graue Herstellungs-Last) — meldete für die betroffene Komponente 0 kg mit der Begründung „Größe fehlt”, obwohl sie gepflegt ist. Der Schnittpunkt „ab wann klimapositiv” verschiebt sich dadurch.
- Live-Dashboard — dem PV-Kärtchen fehlte der Auslastungsbalken („Auslastung: X % von Y kWp”) ersatzlos und ohne Hinweis. Er ist wieder da.
- PDF-Anlagendokumentation — die Zeile „Nennleistung” wurde für die betroffene Komponente gar nicht gedruckt. Ein Dokumentations-PDF, das genau das verschweigt.
- PDF-Jahresbericht — die Spalte „Nennleistung” der Komponenten-Tabelle blieb leer.
- Daten-Checker — für PV-Module war die Prüfung schon vorher richtig; neu ist der Balkonkraftwerk-Fall: trägt ein Balkonkraftwerk seine kWp im Detail-Feld kwp (statt als leistung_wp × anzahl), zählte es 0 und der Checker meldete „PV-Module kWp stimmt nicht mit Anlagenleistung überein” bei einer korrekt gepflegten Anlage (gemessen: Summe 10,0 statt 10,8 kWp). Diese Falschmeldung verschwindet; eine echte Abweichung wird weiterhin gemeldet.
- Prognosen-Seite und Aussichten — die Anlagenleistung ist dort der Multiplikator des Ertrags; eine zu kleine Summe zog die ganze Seite nach unten. Zusätzlich kannte die Aussichten-Seite bei Balkonkraftwerken die Rechnung leistung_wp × anzahl nicht. Alle diese Zahlenänderungen sind die Korrektur, nicht ein Fehler — die Leistung war immer gepflegt, sie kam nur nicht überall an. Wer bisher schon überall dieselben Werte sah, sieht keinen Unterschied.
Balkonkraftwerk-Dashboard: Leistung und spezifischer Ertrag waren um den Faktor 2 daneben. Wer bei seinem Balkonkraftwerk die Anzahl der Module nicht gepflegt hat, bekam in diesem Dashboard stillschweigend zwei Module unterstellt — die angezeigte Leistung war doppelt so hoch, der spezifische Ertrag halb so groß. Alle anderen Sichten von eedc rechnen in diesem Fall mit einem Modul. Für betroffene Balkonkraftwerke halbiert sich die angezeigte Leistung und der spezifische Ertrag verdoppelt sich — das ist die Korrektur, nicht ein Fehler. Wer die Anzahl gepflegt hat, sieht keinen Unterschied. Außerdem hatte dieses Dashboard als einziges die Reihenfolge umgedreht und die Detail-Felder vor dem Leistungsfeld gelesen; jetzt gewinnt wie überall sonst der im Formular gepflegte Wert.
PDF-Anlagendokumentation: Speicher und Wechselrichter bekamen die falsche Einheit. Die Zeile hieß für jede Komponente „Nennleistung … kWp” — bei einem Speicher steht dort aber die Kapazität in kWh und bei einem Wechselrichter die AC-Leistung in kW. Beide sind jetzt richtig beschriftet („Kapazität … kWh” bzw. „Nennleistung … kW (AC)”), so wie es der Jahresbericht schon immer getan hat.
ROI-Dashboard: Serverfehler, sobald ein PV-Modul ohne Nennleistung dabei war. Hatte auch nur eines der PV-Module keine Leistung hinterlegt, während ein anderes eine hatte, brach die ganze ROI-Auswertung mit einem Fehler ab — nicht etwa nur die eine Zeile. Betraf besonders die oben beschriebenen Import-Bestände, bei denen die Leistung nur im Detail-Feld stand; die zeigen jetzt ohnehin ihren richtigen Anteil. Aber auch ein Modul, bei dem wirklich keine Leistung gepflegt ist, lässt die Seite jetzt stehen: es bekommt 0 % Anteil, alle anderen ihren korrekten.
Cockpit-Übersicht: 500er bei einem Balkonkraftwerk mit leerem Leistungs-Detailfeld. Stand im Detail-Feld leistung_wp ausdrücklich „nichts” (statt gar nicht dazustehen), brach die Cockpit-Übersicht mit einem Serverfehler ab. Latenter Fehler, jetzt weg.
Ein PV-Modul mit „0” im Leistungsfeld fällt nicht mehr aus der kWp-Verteilung. Steht im Feld Leistung (kWp) eine ausdrückliche 0, die Nennleistung aber im Detail-Feld (kwp bzw. leistung_kwp, typisch bei importierten Bestandsdaten), lasen die beiden internen Lesewege verschiedene Zahlen: die Prognose-Seite fand die gepflegte Leistung, das Aufteilen eines PV-Gesamtwerts auf die einzelnen Strings las 0 — das Modul bekam nichts, die übrigen entsprechend zu viel. Betroffen waren Import-Zuordnung, Connector/MQTT-Verteilung, Monatsdaten und die PV-Strings-Sicht. Beide Wege lesen jetzt gleich. Ein leeres Leistungsfeld verhielt sich schon immer richtig — nur die ausdrückliche 0 nicht.

[4.0.1] - 2026-07-26 — Prognose-Werte vereinheitlicht · PV-Modulwerte gemessen · Tester-Korrekturen

Fixed

Datenquellen: ein Klick auf die aktive Quelle löscht sie nicht mehr. Bisher bedeutete derselbe Knopf zweierlei — bei inaktiver Quelle „auswählen”, bei aktiver „Zuordnung verwerfen”, ohne Rückfrage. Wer nur nachsehen wollte, welcher Sensor hinterlegt ist, verlor ihn. Jetzt öffnet der Klick immer die Zuordnung (Picker mit vorausgewähltem Sensor); entfernt wird ausschließlich über „Keine”. Außerdem zeigt die Zeile wieder den Klarnamen des Sensors neben der Entity-ID.
Investitionen: optionale Felder ließen sich nach dem Setzen nie wieder leeren. Eine einmal gesetzte Wechselrichter-Zuordnung, ein Anschaffungs- oder Stilllegungsdatum, alternative Kosten — das Formular meldete Erfolg, der alte Wert blieb aber stehen. Betraf alle optionalen Felder.
AC-gekoppelte Speicher wurden als Fehler gemeldet. Der Hinweis „Speicher ohne Wechselrichter-Zuordnung” erschien auch dort, wo gar keine Zuordnung nötig ist — und verleitete dazu, eine falsche anzulegen. Speicher ohne Zuordnung heißen jetzt neutral „Eigenständige Speicher”; gewarnt wird nur noch bei PV-Modulen, für die der Wechselrichter Pflicht ist.
„DC-gekoppelt” war geraten. eedc kennt kein Kopplungs-Feld — die Anzeige leitete sich allein daraus ab, ob ein Wechselrichter zugeordnet ist. Ein AC-Speicher am Hybrid-Wechselrichter wurde damit falsch beschriftet. Die Zeile heißt jetzt „Zuordnung”, nennt den Wechselrichter beim Namen und erklärt, was die Zuordnung bewirkt.
Cockpit → Aussicht: „Stunden-Prognose” und „Stundenwerte” rechnen wie die übrigen Prognose-Anzeigen. Beide Blöcke gingen einen eigenen Weg: ein Wetterabruf für die Gesamtleistung der Anlage, mit Neigung und Ausrichtung einer beliebigen PV-Zeile — bei mehreren Dachflächen war es Zufall, welche das war —, dazu ein pauschaler Korrekturfaktor über den ganzen Tag. Der Prognosen-Vergleich und die HA-Sensoren rechnen dagegen jede Ausrichtung getrennt und korrigieren Stunde für Stunde. So standen für denselben Tag zwei Zahlen auf einer Seite (Rainer, PN vom 25.07.: 13 kWh im 14-Tage-Balken, 10,8 kWh in der Summenzeile der Stundenwerte). Stundenkurve und Summenzeile kommen jetzt aus derselben Rechnung wie der Prognosen-Vergleich und der Sensor eedc_prognose_day_plus_1_kwh — Stunde für Stunde deckungsgleich. Bei Anlagen mit mehreren Ausrichtungen ändern sich damit die angezeigten Stundenwerte und die Tagessumme spürbar (Testanlage: −10 % bis +8 %, je nachdem welche Dachfläche bisher zufällig den Ton angab) — das ist die Korrektur, nicht ein Fehler. Weil die Speicher-Vorschau auf derselben Kurve sitzt, kann „Speicher voll um” um eine Stunde springen. (Nicht betroffen: Solcast als Prognosequelle. Der 14-Tage-Balken darüber zeigt weiterhin den unkorrigierten Wetterdienst-Wert und wird getrennt nachgezogen.)
Cockpit → Aussicht: der 14-Tage-Balken zeigt jetzt die eedc-Prognose statt der reinen Wetterdienst-Zahl. Balken, 14-Tage-Tabelle, die Kacheln „Morgen”, „Summe” und „Ø/Tag” sowie die Zeilen Morgen/Übermorgen der Live-Solar-Aussicht zeigten bisher die unkorrigierte Open-Meteo-Prognose — während die Stundenwerte darunter, der Prognosen-Vergleich und die HA-Sensoren die von eedc gelernte Korrektur einrechnen. Auf einer Seite standen so zwei Zahlen für denselben Tag (Rainer, PN vom 25.07.: 13 kWh im Balken, 10,8 kWh in der Summenzeile). Alle diese Anzeigen kommen jetzt aus derselben Rechnung wie der Prognosen-Vergleich und der Sensor eedc_prognose_day_plus_1_kwh. Die Balken und Kacheln sinken dadurch sichtbar (typisch 5–15 %, je nach gelernter Korrektur und Dachausrichtung) — das ist die Korrektur, kein Fehler: die Prognose ist nicht schlechter geworden, sie zeigt jetzt denselben Wert wie Home Assistant und der Prognosen-Vergleich. Wo keine Korrektur vorliegt, bleibt der Wetterdienst-Wert stehen und die Kopfzeile sagt es („Quelle: Open-Meteo (ohne Korrektur)”). Die HA-/MQTT-Sensoren ändern sich nicht — sie rechneten schon vorher so. (Nicht betroffen: die Spalte „OpenMeteo” im Prognosen-Vergleich — sie ist der Rohwert und bleibt es.)
Prognosen-Vergleich: die Kurve „OpenMeteo (roh)” folgt jetzt allen Ausrichtungen der Anlage. Im Tagesverlauf-Diagramm und in der Tabelle „Stundenvergleich heute” (Auswertungen → Prognose-vs-IST) rechnete diese Kurve die gesamte Anlagenleistung so, als hinge sie an einer Dachfläche — genommen wurde die Neigung und Ausrichtung der zufällig ersten PV-Zeile, und wo dort nichts gepflegt war, stillschweigend 35° Süd. Der OpenMeteo-Tageswert in derselben Spalte darüber rechnet dagegen längst jede Ausrichtung getrennt. Bei Anlagen mit Ost/West- oder gemischten Flächen widersprachen sich damit zwei Zahlen derselben Spalte: die Summenzeile unter der Stundentabelle passte nicht zum Tageswert (Rainer, PN 89608 — an einer Ost/West-Testanlage bis zu 8 % Unterschied in der Tagessumme und bis zu 4,7 kW in einzelnen Stunden; der Kurvengipfel lag zwei Stunden zu früh). Kurve, Summenzeile und Tageswert kommen jetzt aus derselben Rechnung — bei Anlagen mit mehreren Ausrichtungen ändern sich die Stundenwerte dieser Kurve und ihre Summe sichtbar. Das ist die Korrektur, kein Fehler. Anlagen mit nur einer Ausrichtung sehen praktisch keinen Unterschied. (Nicht betroffen: die eedc-Spalte — sie rechnete schon so. Ebenso wenig Solcast, SFML und die HA-/MQTT-Sensoren.) Nebenbei: die Legende nennt die korrigierte Kurve jetzt „eedc (kalibriert)” statt „eedc (OpenMeteo ×Faktor)” — korrigiert wird längst Stunde für Stunde, nicht mit einem Tagesfaktor.
14-Tage-Tabelle: die GTI-Spalte war bei gemischten Ausrichtungen bedeutungslos. Die Einstrahlung wurde über die PV-Zeilen ungewichtet gemittelt, der Ertrag daneben aber summiert — ein 0,8-kWp-Balkonmodul zählte damit so viel wie ein 12-kWp-Süddach, und die Spalte passte zu keiner anderen Zahl ihrer Zeile. Jetzt ist es das kWp-gewichtete Mittel, also die Einstrahlung auf die Modulflächen dieser Anlage, konsistent zur Ertragssumme; die Spalte heißt entsprechend „GTI Modulfläche”. Anlagen mit einer Ausrichtung sind nicht betroffen.
PV-Modulwerte im Komponenten-Hub sind jetzt gemessen statt gerechnet. Wer seine Dachflächen einzeln erfasst, sieht im Block „Verlauf” (Komponenten → PV) endlich die eigenen Messwerte je Modul — bisher zerlegte dieser Block die Gesamterzeugung stur nach Nennleistung; ein verschatteter oder abgeschalteter String war dort unsichtbar, und alle Module hatten rechnerisch denselben spezifischen Ertrag (Rainer, PN vom 25.07.). Zwei Änderungen sind sichtbar: (1) Bei Anlagen mit Pro-String-Sensoren ändern sich die Modul-Balken — sie zeigen ab jetzt die Messung statt des kWp-Anteils (Demo-Anlage: Süddach 23.071 → 22.683 kWh, Ostdach 9.613 → 9.462 kWh, Westdach 5.768 → 6.308 kWh; das bisher zu schwach gerechnete Westdach gewinnt damit 9 %). (2) Wer nur einen Gesamt-Sensor für mehrere Strings hat, sieht im Block „Vergleich” und in Auswertungen → PV-Anlage erstmals Werte, wo vorher 0 bzw. eine leere Sicht stand — die Gesamterzeugung anteilig nach kWp auf die Strings verteilt und sichtbar als „geschätzt (kWp-Anteil)” gekennzeichnet. Das ist die Korrektur, nicht ein Fehler: die 0 war die unehrlichere Anzeige, erzeugt wurde ja etwas. Solange die Werte verteilt sind, nennen diese Sichten bewusst keinen besten oder schwächsten String mehr, sondern sagen, dass ein Pro-String-Vergleich mit gerechneten Werten nicht möglich ist — eine Platzierung wäre dort nur die Reihenfolge der Nennleistungen. Wer sie zurückhaben will, gibt jedem Modul einen eigenen Erzeugungs-Sensor (Einstellungen → Datenquellen). (Nicht betroffen: Anlagen mit nur einem Modulfeld, der Live-Bereich — der misst ohnehin je String — und die ROI-/CO₂-Zahlen je Komponente, die weiterhin nach kWp verteilen und separat nachgezogen werden.)
PV-Prognose berücksichtigt geplante Rückbauten und Erweiterungen. Ein PV-String mit Stilllegungsdatum in der Zukunft zählte bis zuletzt über den ganzen 14-Tage-Horizont mit, ein erst später angeschaffter noch gar nicht. Anschaffungs- und Stilllegungsdatum gelten jetzt je Prognosetag. Betrifft nur Anlagen mit einem solchen Datum in der Zukunft; dort ändern sich auch die HA-Sensorwerte ab dem betreffenden Tag.
Cockpit → Aussicht: „Stunden-Prognose” und „Stundenwerte” nennen ihren Tag. Beide Blöcke zeigen standardmäßig morgen, der Datumswähler sitzt aber nur im einen Block — wer den anderen allein aufklappte, konnte den Tag nicht erkennen. Kopfzeile trägt jetzt Datum und Prognosequelle.
Kennzahlen zeigen 0-Werte wieder an — die Kachel „Batterieladung Netz” verschwand bei 0 kWh komplett, sodass man in HA nachsehen musste, ob wirklich nichts geladen wurde. Die Kachel erscheint jetzt, sobald ein Speicher mit Monatsdaten existiert (0 kWh → 0,00 €, Ladepreis „—”); ohne Speicher bleibt sie weg. Gilt für Tag, Monat und Jahr/Gesamt. (Der Tages-Ø-Preis „Ø-Preis Netz” entfällt ohne Netzbezug weiterhin — er wird aus Kosten ÷ Menge abgeleitet und ist bei 0 undefiniert.)
Einspeiseerlös in Auswertungen → Finanzen: §51-EEG-Abzug fehlte. Die Seite rechnete Einspeisung × Vergütung, während das T-Konto darunter (und alle anderen Sichten) die in Negativpreis-Stunden eingespeisten kWh abzieht — derselbe Erlös stand mit zwei Zahlen auf einer Seite. Betroffen sind nur Anlagen mit aktivem §51-Schalter und Negativpreis-Volumen; dort sinken Einspeiseerlös, Netto-Ertrag und die Netto-Bilanz auch in der Werte-Tabelle. Veränderte Summen sind die Korrektur, nicht der Fehler. Für alle anderen Anlagen ändert sich nichts.
§51-Verlust wird wieder ausgewiesen. Das Anlage-Formular verspricht beim §51-Schalter: „der entgangene Erlös wird dann im Cockpit als §51-Verlust ausgewiesen” — seit dem v4-Flip zeigte ihn keine Sicht mehr. Jetzt: neue Kachel „§51-Verlust” (€) im Block „Börsenpreis (§51 EEG)” unter Cockpit → Monat, ein Hinweis an der Einspeise-Zeile des T-Kontos (§51-Verlust: X kWh ohne Vergütung — Y € entgangen) und der Abzug am KPI „Einspeiseerlös” der Finanz-Auswertung. Die Herleitung der T-Konto-Zeile zeigte zudem die volle Einspeisung, obwohl der Erlös bereits gekürzt war — sie rechnet jetzt mit der vergüteten Menge.
T-Konto: nachrichtliche Zusätze waren am Desktop unsichtbar — Hinweise wie „davon Batterieladung Netz” wurden nur in der Mobil-Tabelle gerendert.
PV-Modulwerte: wo nach Nennleistung gerechnet wird, steht es jetzt dran — und der Jahresbericht rechnet je String exakt. Im Komponenten-Hub → PV zeigte der Block „Verlauf” Balken je Modul, die gar nicht gemessen, sondern anteilig nach kWp aus der Gesamterzeugung gerechnet waren — während der Block „Vergleich” derselben Karte dieselben Module mit den gemessenen Werten zeigt (Rainer, PN vom 25.07.: „verschiedene Solar-/Dachsegmente werden in den Sensoren getrennt erfasst, sind aber in keiner Auswertung zu sehen”). Zwei Blöcke, zwei Wahrheiten, keine Kennzeichnung. Das Diagramm und der Balken „Erzeugung nach Modul” tragen jetzt ein Herkunfts-Zeichen und den Satz, dass diese Werte nach kWp verteilt sind und die gemessenen im Block „Vergleich” stehen. An den angezeigten Zahlen im Hub ändert sich durch diese Kennzeichnung nichts — die Umstellung auf die Messwerte steht im folgenden Absatz. Ebenso ehrlich beschriftet ist jetzt der Monatsabschluss: ein Wechselrichter-Connector liefert genau einen Zählerstand; bei mehreren Modulen wurde der daraus zerlegte Vorschlag trotzdem als „Vom Wechselrichter (Zählerstand-Differenz)” angeboten und stand damit auf einer Stufe mit echten Gerätemessungen. Er heißt jetzt „Gesamtwert, anteilig nach kWp auf die Strings verteilt” und wird niedriger gewichtet als jede gemessene Quelle (bei nur einem Modul bleibt alles wie bisher; für Speicher gilt dasselbe mit der Kapazität). Im PDF-Jahresbericht ändern sich dagegen Zahlen: der String-Vergleich verteilte die PVGIS-Prognose immer anteilig nach kWp, obwohl seit v2.3.2 für jedes Modulfeld die exakte Prognose seiner Ausrichtung gespeichert wird — die App nutzt sie längst, das PDF nicht. Bei Ost-West- oder gemischten Dächern lagen die SOLL-Werte je String dadurch um ~20–25 % daneben; sie stimmen jetzt mit dem Cockpit überein. Das ist die Korrektur, nicht ein Fehler. Anlagen mit nur einem Modulfeld und ältere Prognosen ohne Pro-Modul-Werte sehen keine Änderung.
Monatsabschluss: wer seinen Wechselrichter einem PV-Modul zugeordnet hat, bekommt jetzt dessen echten Wert vorgeschlagen. Die Zuordnung eines Connector-Felds zu einer Komponente (Einstellungen → Connector) galt bisher nur in der Connector-Vorschau und für die MQTT-Werte — im Monatsabschluss wurde der Zählerstand trotzdem stur nach Nennleistung auf alle Module zerlegt. Wer also weiß, welches Dach an diesem Wechselrichter hängt, bekam trotzdem einen gerechneten Wert. Jetzt geht der volle Zählerstand an die zugeordnete Komponente, wieder als „Vom Wechselrichter (Zählerstand-Differenz)” — die anderen Module bekommen aus dieser Quelle keinen Vorschlag mehr, denn der Zähler ist ja bereits vollständig zugeordnet. Ohne Zuordnung bleibt alles wie bisher: verteilt, mit dem Hinweis „anteilig nach kWp auf die Strings verteilt” und niedrigerer Gewichtung. Gilt gleichermaßen für Speicher (Zuordnung statt Kapazitäts-Verteilung) und für den Cloud-Import. Vorschlagswerte ändern sich dadurch sichtbar — Vorschläge werden aber wie immer erst durch Bestätigen übernommen, nichts wird automatisch geschrieben.
PDF-Jahresbericht: die Spalte „PVGIS-Prognose” war immer leer. In der Monatstabelle des Jahresberichts stand in dieser Spalte durchgehend 0, und die SOLL-Linie im PV-Diagramm darüber fehlte deshalb ganz — der Bericht suchte den Monatswert unter einem Namen, den die gespeicherte Prognose gar nicht kennt. Die Spalte zeigt jetzt Werte; im Diagramm erscheint die SOLL-Linie. Das ist die Korrektur, nicht ein Fehler — die Zahlen sind nicht neu berechnet, sie waren nur nie angekommen. Zugleich nimmt der Bericht wie alle anderen Sichten (Cockpit, Aussichten, HA-Sensoren) genau die aktive PVGIS-Prognose; wer mehrere Prognosen gespeichert hat, bekam sonst deren Summe. Damit stimmt die Monatstabelle auch mit dem String-Vergleich weiter hinten im selben PDF überein, der schon immer die aktive Prognose las.
Komponenten-Hub → PV: die beiden Stapel im Block „Verlauf” passen wieder zusammen. Links stand die Erzeugung der PV-Module, rechts daneben die Verwendung (Direktverbrauch, Speicherladung, Einspeisung) — aber gerechnet aus der gesamten Erzeugung hinter dem Hauszähler. Wer neben dem Dach noch ein Balkonkraftwerk oder einen sonstigen Erzeuger (z. B. BHKW) hat, sah deshalb zwei unterschiedlich hohe Stapel nebeneinander (Demo-Anlage: 38.452 kWh links, 41.807 kWh rechts). Dass das früher nicht auffiel, lag nur daran, dass die alte Nennleistungs-Rechnung die Balkonkraftwerk-Erzeugung stillschweigend auf die Dachflächen mitverteilt hat. Der Erzeugungs-Stapel zeigt jetzt alle Erzeuger hinter dem Zähler — Module, Balkonkraftwerk, sonstige Erzeuger je als eigenes Segment; beide Stapel und beide Prozent-Balken darunter sind summengleich. Der Balken heißt bei mehreren Quellen „Erzeugung nach Quelle” statt „nach Modul”. Nebenbei behoben: der Direktverbrauch im rechten Stapel enthielt die Entladung eines E-Autos ins Haus (V2H) mit, obwohl sie keine Verwendung der Erzeugung dieses Monats ist. Anlagen mit nur PV-Modulen und ohne V2H sehen keine Änderung.
PV-String-Vergleich im Cockpit hielt sich nicht an die aktivierte PVGIS-Prognose. Wer mehrere Prognosen gespeichert hat und bewusst eine ältere aktiviert (Einstellungen → PVGIS), bekam in den SOLL-Werten je String trotzdem die zuletzt abgerufene zu sehen — betrifft die Jahressicht und die Gesamtlaufzeit-Sicht. Alle anderen Anzeigen (Cockpit-Übersicht, Aussichten, HA-Sensoren, PDF-Berichte) folgen längst der aktiven Prognose; auf einer Seite standen damit zwei verschiedene SOLL-Werte. Jetzt gilt überall dieselbe Auswahl. Wo eine ältere Prognose aktiv ist, ändern sich die SOLL-Werte und die Abweichungs-Prozente dieser Sicht sichtbar — das ist die Korrektur, nicht ein Fehler. Ist gar keine Prognose aktiv, bleibt die SOLL-Seite leer, statt eine beliebige zu zeigen. Wer nur eine Prognose gespeichert hat, sieht keinen Unterschied.
Eine frühere Umstellung hat bei manchen Anlagen den monatlichen PV-Gesamtwert gelöscht. Wer die PV-Erzeugung als einen Gesamtwert pro Monat pflegt und zusätzlich ein Balkonkraftwerk mit eigenem Sensor hat, verlor beim Start von eedc den Gesamtwert für jeden Monat, in dem Balkonkraftwerk-Daten vorliegen — die Dachflächen stehen in diesen Monaten seither ohne Erzeugung da. Ursache war eine Start-Migration, die den Gesamtwert als „automatisch errechnete Summe” einstufte, sobald irgendeine PV-Komponente des Monats einen eigenen Wert hatte. Das war ein Fehler, keine gewollte Bereinigung — die Migration versprach in ihrer eigenen Beschreibung das Gegenteil. Ab jetzt wird der Gesamtwert nur noch entfernt, wenn er exakt der Summe der einzeln erfassten Komponenten entspricht und jede im Monat aktive PV-Quelle einen eigenen Wert hat, das Feld also nichts mehr trägt, was nicht woanders steht. Im Zweifel bleibt der Wert stehen. Bereits gelöschte Werte kann eedc nicht zurückholen — die alte Migration lief ohne Herkunfts-Protokoll, es gibt keinen alten Stand. Der Daten-Checker weist die betroffenen Monate jetzt aus („PV-Erzeugung fehlt in N Monat(en)”) und nennt den Weg: Wo ein PV-Sensor zugeordnet ist, lassen sich diese Monate über Einstellungen → Datenverwaltung → Import aus HA-Statistik oder den Monatsabschluss des betreffenden Monats neu befüllen — beide schreiben die Werte je Modul. Wo die Werte von Hand erfasst wurden, müssen sie von Hand nachgetragen werden.
Berichte und Sichten nehmen jetzt überall die aktivierte PVGIS-Prognose — und mehrere aktive Prognosen brechen nichts mehr. eedc kann beliebig viele PVGIS-Prognosen einer Anlage aufbewahren; genau eine ist die aktive, und wer bewusst eine ältere aktiviert (Einstellungen → PVGIS), soll sie überall sehen. Das war nicht durchgehend so — und schlimmer: es gab keine Sicherung dagegen, dass am Ende mehrere gleichzeitig als aktiv galten. Wer eine Sicherung wiederherstellte, deren Backup-Datei den Aktiv-Zustand nicht mitbrachte, hatte danach alle Prognosen aktiv. Drei Auswirkungen, alle jetzt behoben:
- Der Daten-Checker und die Social-Karte zeigten in diesem Fall eine Fehlerseite statt ihres Inhalts — also genau dort keine Hilfe, wo man Datenprobleme nachsieht.
- Der SOLL-PV-Wert im Monatsbericht war verdoppelt (bei drei aktiven Prognosen verdreifacht), und mit ihm die SOLL/IST-Abweichung und die Grundlast-SOLL-Kachel. Betroffene Anlagen sehen ab jetzt einen deutlich niedrigeren, richtigen SOLL-Wert — das ist die Korrektur, nicht ein Fehler.
- Beim Wiederherstellen einer Sicherung wird jetzt genau eine Prognose aktiviert (die zuletzt abgerufene, wenn das Backup selbst keine oder mehrere nennt), und der Import sagt es in seinen Hinweisen. Keine Prognose wird dabei gelöscht — die übrigen bleiben als Historie und lassen sich jederzeit wieder aktivieren. Nebenbei behält die wiederhergestellte Historie ihre echten Abrufzeitpunkte, statt alle auf den Zeitpunkt der Wiederherstellung zu setzen.
Bestandsanlagen mit mehreren aktiven Prognosen werden beim nächsten Start einmalig bereinigt: die zuletzt abgerufene bleibt aktiv, die übrigen werden deaktiviert, nicht gelöscht. Wer nur eine Prognose gespeichert hat oder nie eine Sicherung eingelesen hat, merkt von der ganzen Änderung nichts.
Unvollständige Wetterabrufe werden ausgewiesen statt stillschweigend als Teilwert geliefert. Bei Anlagen mit mehreren Dachflächen holt eedc die Wetterprognose für jede Ausrichtung getrennt. Fiel einer dieser Abrufe aus (der Wetterdienst bremst zeitweise), enthielten Summe, Ø/Tag und alle Tagesbalken nur die Flächen, die geantwortet hatten — bei vier Flächen und einem Aussetzer fehlte grob ein Viertel, und nichts sagte es. Aus einer 20,8-kWp-Anlage wurden so kommentarlos die 3,0 kWp einer einzigen Fläche; man sah einen schlechten Prognosetag, nicht einen halben Abruf. Die Zahlen bleiben unverändert — sie werden nicht hochgerechnet und nicht gekappt —, aber die 14-Tage-Prognose (Cockpit → Aussicht und Aussichten → Kurzfristig) trägt jetzt einen sichtbaren Hinweis, wie viele Teilanlagen geliefert haben und dass der Wert deshalb zu niedrig ist. Ein Neuladen später holt die Prognose meist vollständig. Dieselbe Ehrlichkeit gilt jetzt für den Stunden-Tagesverlauf: fällt jede Prognosequelle aus, zeigte er 24 Nullen wie eine echte Prognose „0 kWh” — samt Speicher-Vorschau, die daraus „Speicher lädt nicht” ableitete. Auch das steht jetzt dran. Und wer Solcast als Prognosequelle nutzt, erfährt endlich, dass der Stundenverlauf für morgen dort das Profil von heute als Näherung ist — die Tagessumme kann davon abweichen.
Anlagen mit mehreren Dachflächen: die letzten Prognose-Sichten rechnen jede Ausrichtung getrennt — und die Nennleistung wird überall vollständig gelesen. Zwei Ursachen, die dieselbe Anlagen-Aussage aus einer Komponente abgeleitet haben: (1) Fällt der reguläre Prognose-Weg der Tagesprognose aus (Wetterdienst nicht erreichbar, Zieltag außerhalb des Abruf-Horizonts), sprang bisher ein Ersatz-Weg ein, der die Gesamtleistung der Anlage mit Neigung und Ausrichtung einer beliebigen PV-Zeile rechnete. Bei einer ausgeglichenen Ost/West-Anlage (5 + 5 kWp) sind das 14,0 statt 17,0 kWh Tagessumme — oder 20,0, je nachdem welche Zeile die Datenbank zuerst liefert. Der Ersatz-Weg fächert jetzt wie der reguläre auf; liefert eine Dachfläche nichts, sagt die Antwort es (Teilsumme) statt still zu wenig anzuzeigen. (2) Die Nennleistung wurde an mehreren Stellen nur aus dem Stammdaten-Feld der Komponente gelesen. Wer sie beim Anlegen in das Detail-Feld statt in das Hauptfeld eingetragen hat, hatte dieses Dach in der Live-Wetter-Gewichtung, in der Live-Gesamtleistung, in der Anlagenleistung der Aussichten und im spezifischen Ertrag der Social-Karte gar nicht dabei (Beispiel: 14,0 statt 10,0 kWp). Bei Anlagen mit gemischten Ausrichtungen bzw. mit Nennleistung nur im Detail-Feld ändern sich damit Prognose- und SOLL-Werte sichtbar — das ist die Korrektur, nicht ein Fehler. Anlagen mit einer Ausrichtung und gepflegtem Hauptfeld sehen keinen Unterschied. Nebenbei: in der Social-Karte ist die aus dem ersten Modul gezogene Dachneigung entfallen — sie wurde ohnehin in keiner Karten-Variante ausgegeben, war aber eine ungeguardete Aussage aus EINER Komponente; und der Hintergrund-Vorlader des Live-Wetters wärmt wieder genau den Zwischenspeicher, den die Live-Seite auch liest.
Import-Wizard: der Zuordnungs-Schritt verteilt nach Nennleistung statt gleichmäßig. Wer mehrere PV-Modulfelder (oder mehrere Speicher) hat, bekommt beim Portal-/CSV-Import den Schritt „Zuordnung”, in dem die importierten Monatswerte auf die Komponenten aufgeteilt werden. Die Vorauswahl sollte proportional zur Nennleistung sein — sie war es nie: der Wizard suchte die kWp unter einem Namen, den eedc gar nicht kennt, fand deshalb nichts, ließ die kWp-Spalte leer und schlug immer eine gleichmäßige Aufteilung vor. Bei 12 kWp Süddach + 3 kWp Garage also 50/50 statt 80/20. Wer bereits importiert und den Vorschlag übernommen hat, sollte die Aufteilung prüfen (Komponenten → PV-Modul → Monatswerte); ein erneuter Import mit korrigierten Anteilen überschreibt die Werte. Ist die Nennleistung tatsächlich nirgends gepflegt, verteilt der Wizard weiterhin gleichmäßig — sagt aber jetzt dazu, dass das keine proportionale Aufteilung ist. Gleiches gilt für Speicher mit der Kapazität.
PDF-Jahresbericht: Eigenverbrauch und Autarkie kannten „sonstige Erzeuger” nicht. Wer neben der PV einen weiteren Erzeuger hinter dem Hauszähler hat (z. B. ein Mini-BHKW, erfasst als „Sonstiges” mit Kategorie Erzeuger), sah im PDF zu niedrige Werte: der Bericht rechnete Eigenverbrauch, Autarkie und Eigenverbrauchsquote allein aus der PV-Erzeugung, während der Einspeise-Zähler daneben die Summe aller Erzeuger misst. Cockpit, HA-Sensoren und Live-Ansicht rechnen das seit v3.45.4 richtig — dieser Bericht war nicht mit umgestellt. Bei Anlagen mit einem sonstigen Erzeuger steigen Eigenverbrauch, Autarkie und EV-Quote im Jahresbericht-PDF und stimmen jetzt mit dem Cockpit überein (Beispiel-Anlage: Eigenverbrauch 700 → 1.100 kWh, Autarkie 77,8 → 84,6 %). Das ist die Korrektur, nicht ein Fehler. Die PV-eigenen Kennzahlen (spezifischer Ertrag, SOLL/IST, String-Vergleich) bleiben unverändert rein PV — ein Brennstoff-Erzeuger gehört nicht in eine PV-Kennzahl. Anlagen ohne sonstige Erzeuger sehen keinen Unterschied. Nebenbei lesen Jahresbericht und Anlagendokumentation die Nennleistung jetzt auch dort, wo sie nur im Detail-Feld gepflegt ist (betraf die Zeile „PV-Gesamtleistung” und den SOLL-Verteilungs-Nenner).
Komponenten-Hub → PV: ab vier Modulfeldern waren zwei Balken gleich eingefärbt. Die vierte Modul-Farbe war exakt die Farbe des Balkonkraftwerks — im selben Stapel-Diagramm ließen sich beide Reihen nicht mehr auseinanderhalten. Betroffen war genau die Kombination „mehrere Dachsegmente + Balkonkraftwerk”. Die vierte Modul-Farbe ist jetzt ein anderer Amber-Ton; geprüft gegen alle Farben, die in diesem Diagramm vorkommen können. Es ändert sich nur die Farbe, keine Zahl.
PDF-Jahresbericht: der spezifische Ertrag heißt jetzt „Spez. Ertrag (Zeitraum)”. Unter demselben Namen standen zwei verschiedene Größen: das Cockpit (und der HA-Sensor) rechnen den Wert auf ein volles Jahr hoch — saisonal gewichtet, mit der im jeweiligen Monat tatsächlich installierten Leistung —, das PDF teilt schlicht die Erzeugung des Berichtszeitraums durch die Anlagen-Nennleistung. Über den Gesamtzeitraum summiert sich der PDF-Wert dadurch auf (Beispiel: 1.955 statt ~980 kWh/kWp). Die Rechnung ist unverändert, nur die Beschriftung sagt jetzt, welche der beiden Größen dasteht — eine Zeile unter den Kennzahlen erklärt den Unterschied. Die Angleichung der Rechnung folgt separat, weil dieselbe Kennzahl im Community-Vergleich steht.
PV-Prognose „Rest heute” sinkt gleichmäßig (#339) — der Sensor eedc_prognose_rest_today_kwh zählte die laufende Stunde immer voll mit und fiel deshalb nur einmal je Stunde in einem Sprung (bei kleinen Anlagen 5–8 kWh). Die laufende Stunde geht jetzt anteilig nach den verbleibenden Minuten ein. (Die Spalte „Verbleibend” im Prognose-Vergleich bleibt bewusst bei der vollen Stunde — sie ist eine Tagesprojektion, in der das IST die laufende Stunde noch nicht enthält.)
Daten-Checker meldete eine kWp-Abweichung, wo keine war. Betroffen sind Anlagen, deren Nennleistung nur im Detail-Feld einer PV-Modulgruppe gepflegt ist: Der Checker las ausschließlich das Hauptfeld, kam so auf eine Summe von 0 kWp und meldete „PV-Module kWp stimmt nicht mit Anlagenleistung überein” — dazu je Modulgruppe „Leistung (kWp) fehlt”. Beide Prüfungen lesen die Nennleistung jetzt wie der Rest der Anwendung aus Haupt- oder Detail-Feld; eine echte Abweichung wird unverändert gemeldet.

Added

Amortisation mit Kalenderjahr (Forum-Wunsch Radiocarbonat): Unter Auswertungen → ROI steht neben der Dauer jetzt auch das voraussichtliche Break-Even-Jahr — in der Kachel „Amortisation”, unter der Kurve und als Beschriftung der X-Achse (Kalenderjahre statt Jahres-Index). Anker ist das früheste Anschaffungsjahr der Investitionen; ohne gepflegtes Anschaffungsdatum bleibt alles wie bisher beim Jahres-Index.
Sensor-Auswahl optional auf passende Einheiten verengen (Forum-Wunsch fridolin22): Checkbox „Nur passende Einheit” im Sensor-Picker der Datenquellen-Zuordnung, mit Anzahl der abweichenden Sensoren. Standardmäßig aus — wer keinen passenden Sensor besitzt, soll die vorhandenen sehen und daraus in Home Assistant einen Helfer bauen können. Sensoren ohne Einheitsangabe bleiben immer sichtbar.
Warum eedc einen anderen Verbrauch zeigt als das Herstellerportal — jetzt erklärt (#200, #340): Bei Hybrid-Wechselrichtern und Speichern (z. B. E3DC) werden PV-Erzeugung und Speicher oft DC-seitig gemessen, Einspeisung und Netzbezug dagegen am Zähler. Die Wandlungsverluste stecken damit im bilanzierten Gesamtverbrauch, der typischerweise 3–5 % der Erzeugung über dem „Hausverbrauch” des Portals liegt. Keiner der beiden Werte ist falsch — sie beantworten verschiedene Fragen: eedc „was musste die Anlage liefern” (inklusive Verluste, die richtige Basis für Autarkie und Wirtschaftlichkeit), das Portal „was zogen die Verbraucher”. Die Berechnungsreferenz erklärt den Messpunkt jetzt mit Diagnose-Rezept und gemessenem Beispiel; Glossar und Bedienungs-Handbuch verweisen darauf. Ein Mapping für einen fremden Hausverbrauchs-Sensor gibt es bewusst nicht — „Hausverbrauch” ist je Hersteller anders definiert (Verluste drin oder heraus, Wallbox enthalten oder nicht), zwei Definitionen derselben Kennzahl würden Cockpit, Berichte und Community-Vergleich auseinanderlaufen lassen.

Changed

Intern (ohne Nutzer-Wirkung): Das Aggregat /monatsdaten/aggregiert liefert die Erzeugung hinter dem Hauszähler jetzt als eigenes Feld (erzeugung_hinter_zaehler_kwh) statt sie in jeder Sicht neu zu summieren, und das Feld für die Dachflächen heißt nicht mehr „PV-Anlage”, sondern „PV-Module” — „PV-Anlage” ist im Produkt überall die ganze Anlage inklusive Balkonkraftwerk, das Feld meinte aber das Gegenteil. Angezeigte Zahlen ändern sich dadurch nicht.
Anschaffungsdatum ist Pflicht. Es ist die Grenze jeder Auswertung — ohne Datum zählt eine Komponente auch für Zeiträume vor der Anschaffung mit — und der Nullpunkt der Amortisationskurve. Neue Komponenten lassen sich nur noch mit Datum anlegen; für vorhandene meldet es der Daten-Checker als Fehler und springt per Klick direkt in das Formular der betroffenen Komponente. Der Break-Even-Text nennt jetzt das Startjahr und weist darauf hin, dass über mehrere Jahre verteilte Anschaffungen das Amortisationsjahr optimistisch machen.
Zwei Netto-Begriffe auf der Finanz-Seite sind jetzt unterscheidbar: „Netto-Ertrag (PV)” (Einspeiseerlös + EV-Ersparnis + Sonstige − Sonderkosten, ohne Netzbezug-Kosten und ohne Wärmepumpe/E-Mobilität) gegen „Gewinn/Verlust (Haushalt)” in der T-Konto-Ergebniszeile, die beides mitrechnet. Namen in KPI, Charts, Ø-Karte, CSV und Werte-Tabelle wortgleich; die T-Konto-Ergebniszeile hat als letzte Zeile nun ebenfalls eine Herleitung im Tooltip. Beide Begriffe stehen im Glossar. Keine Zahl ändert sich.
Netzbezugspreis bei dynamischem Tarif erklärt: Das Feld bleibt Pflicht — es ist der Referenzwert für Monate ohne Preis-Mitschrift und für ROI-/Investitionsrechnungen —, sagt das jetzt aber im Feld-Hinweis und in den Hinweisen der Strompreis-Sektion. Vorrang hat weiterhin der stündlich mitgeschriebene Preis.
Sensor-Referenz korrigiert: eedc_prognose_heute_kwh wurde dort noch als „IST bisher + Rest” beschrieben; seit dem Prognose-Kanon ist es die volle Tagesprognose (identisch zur App-Anzeige).
Bedienelemente in vier Ansichten auf die geteilten Standard-Komponenten umgestellt — PV-String-Vergleich und Wärmepumpen-Vergleich (jeweils Komponenten → Vergleich), Komponenten-Liste (Einstellungen → Komponenten) und die Korrekturprofil-Heatmap (Auswertungen → Prognose): Umschalter und Inline-Aktionen sehen dort jetzt aus wie im Rest der App. Funktion unverändert.
Hilfe-Dokumentation auf den Stand dieser Runde gebracht (Handbücher Bedienung/Einstellungen/Prognosen/Daten-Checker, Berechnungsreferenz, Glossar, Sensor-Referenz, „Was ist neu”): überholte Aussagen zu Prognose-Herkunft, kWp-Verteilung, aktiver PVGIS-Prognose, Speicher-Zuordnung und Daten-Checker-Befunden ersetzt; die Doppelbedeutungen von „spezifischer Ertrag”, „Amortisation” und pv_erzeugung_kwh sind jetzt benannt. Intern: neue docs/ADR-002-WURZELMUSTER.md schreibt die sechs Daten-/Zugriffs-Invarianten samt ihrer Test-Wächter fest (Pendant zu ADR-001); Style-Guide um zwei Regeln ergänzt (keine Identitätsfarbe in einer Reihen-Palette, geteilte Herkunfts-Zeile für Provenance-Hinweise).

[4.0.0] - 2026-07-25 — Neue Oberfläche (Cockpit · Komponenten · Auswertungen) + Finanz-/CO₂-Korrekturen

Breaking Change (nur Oberfläche, keine Daten): Die Menüstruktur ist neu — sortiert nach Wann? (Cockpit), Was? (Komponenten), Wie ausgewertet? (Auswertungen). Alle Funktionen und Daten bleiben erhalten; alte Links/Lesezeichen werden automatisch umgeleitet. Das HA-Add-on zeigt vor dem Update den Breaking-Hinweis (config.yaml breaking_versions 4.0.0).

Added

Neue Informationsarchitektur (IA V4) — die bisher hinter dem Build-Flag VITE_IA_V4 dormante Oberfläche ist jetzt die ausgelieferte:
- Cockpit (Zeit-Achse): Live · Tag · Monat · Jahr/Gesamt · Aussicht — jede Sicht mit gleichem Aufbau (Kennzahlen · Verlauf/Energiefluss · Komponenten-Sektionen). Neu: die Tag-Sicht (Stundenverlauf + Tagesbilanz je Einzeltag).
- Komponenten (Geräte): PV · Speicher · Wärme/Klima · E-Auto · Wallbox · Balkonkraftwerk · Sonstiges — je feste Struktur Status → Verlauf → Vergleich → Wirtschaftlichkeit (bisherige Geräte-Dashboards + Auswertungs-Tabs zusammengeführt).
- Auswertungen (analytische Schnitte): Finanzen · ROI · Prognose-vs-IST · CO₂ · Tabelle — das Finanz-T-Konto lebt hier mit wählbarem Zeitraum.
- Einstellungen als durchsuchbare Kachel-/Reiter-Übersicht mit Status je Bereich.
Individualisierung je Sicht: Blöcke per ↑/↓ verschieben, per ⤢ auf Vollbild fokussieren, einklappen — Anordnung wird pro Sicht gemerkt. Einzelne Anzeigen lassen sich per Langdruck/Rechtsklick auf einen „Parkplatz” am Seitenende ausblenden (jederzeit zurückholbar).
Monatsabschluss als ein Formular (statt siebenteiligem Wizard): Neuanlage und Korrektur im selben Formular (Einstellungen → Daten → Monatsdaten), Status je Monat, T-Konto als Gegenprobe in den Auswertungen.
Datenquellen als eine Fläche (Einstellungen → Datenquellen): jedem Feld genau eine Quelle (HA-Sensor · MQTT-Topic · Geräte-Connector), mit Sensor-Suche, Themen-Baum, Vorzeichen-Invertierung und Prüfung je Feld. Löst die Alt-Wizards (Sensor-Mapping, MQTT-Inbound) ab; bestehende Zuordnungen werden automatisch übernommen.
Setup-Wizard im neuen Design (Anlage · Tarif · PV-System · HA-Verbindung, inkl. Schnellstart-Karte + Sensor-Vorschlägen aus dem HA-Energie-Dashboard).
Diagramme als Tabelle ablesen + CSV-Export in der Vollbild-Ansicht (zunächst Cockpit-Monat/-Jahr-Verlauf + Live-Tagesverlauf).
Sonstige Erträge & Ausgaben auf Anlage-Ebene (G19-1): Feld Monatsdaten.sonstige_positionen — pro Monat mehrere benannte Positionen (Ertrag oder Ausgabe), wirkt in allen fünf Anlage-Finanz-Lese-Pfaden. Einmalige Migration übernimmt Alt-Sonderkosten; diese Werte rechnen ab jetzt in den Finanz-Summen mit (vorher in KEINER Summe) — veränderte Summen sind die Korrektur, nicht der Fehler. Dazu K3: Zählergebühr als eigenes Tarif-Feld, getrennter Grund-/Zählergebühr-Ausweis (Cockpit Monat/Jahr).
Community — rückwirkend entfernte Monate (N18-2): Client deklariert Voll-Übertragungen (monate_vollstaendig: true); der Server entfernt damit lokal gelöschte Monate (Server-Seite live; ältere Server ignorieren das Feld).
Klickbare Chart-Legenden als Standard (B7): Legenden-Eintrag blendet Serie aus/ein (inkl. Achsen-Reskalierung), über geteilten Hook in den gemeinsamen Chart-Bausteinen.
Speicher: Ø-Netz-Ladepreis-Vorschlag im Investitions-Formular (R15-2) + Netzladung-Kosten-Ausweis im T-Konto (R15-5).

Changed

Netzbezug-Farbe von Signal-Rot auf dunkles Rot (#ef4444 → #b91c1c) umgestellt — Signal-Rot ist jetzt exklusiv für Kosten/Fehler reserviert, einheitlich in allen Charts.
Datenquellen-Backend konsolidiert (jetzt mit sichtbarer V4-Fläche): drei additive/idempotente Start-Migrationen (Materialisierung bestehender Zuordnungen, Invert-Vereinheitlichung, Richtungs-Festschreibung), EIN MQTT-Broker für beide Richtungen mit Import-/Export-Defaults (Bestandsschutz über ENV MQTT_ENABLED), HA-Export nicht mehr HA-only-gated. Zwei bewusste Verhaltensänderungen für Bestand: (1) Export-Default = an, sobald HA-Verbindung + Broker vorhanden (abschaltbar unter Einstellungen → HA-Export → Auto-Publish) — es können neue eedc-Entitäten in HA auftauchen; (2) je Feld strikt EINE Quelle, HA vor MQTT (vorher überschrieb MQTT den HA-Wert; kein stiller Fallback mehr bei Sensor-Ausfall).
HA-Export-Sensoren rechnen vollständiger: CO₂-Ersparnis trägt die volle Bilanz (PV-Eigenverbrauch inkl. Balkonkraftwerk + sonstige Erzeuger + WP + E-Mobilität); Autarkie/Eigenverbrauchsquote enthalten Erzeuger hinter dem Hauszähler — deckungsgleich mit dem Cockpit. Hinweis: der total_increasing-CO₂-Sensor macht dadurch einmalig einen Sprung in der HA-Langzeitstatistik.
Weniger Doppel-Abrufe: App-Start/Setup-Gate teilen den Anlagen-Fetch (useAnlagen-Cache) — /api/anlagen/ pro Seitenaufruf 2→1; weniger Refetch beim Navigieren.
UI-Politur in geteilten Komponenten (T19): „Abbrechen”-Kanon (secondary, rechts) über 15 Stellen, Modal-/Alert-Padding mobil, Dialog-/Werkbank-Feinschliff.

Fixed

Drift-Inventur Tier-1 (Paket DI) — bekannte Kennzahl-Abweichungen vor dem Release bereinigt (Korrektur, kein Kern-Bilanz-Fehler; betroffene Werte ändern sich sichtbar):
- DI-1 — WP-CO₂-Ersparnis im Jahres-/Anlagenbericht (PDF) war zu hoch. Bericht rechnete nur vermiedenes Gas, ohne Gas-Kessel-Wirkungsgrad und ohne WP-Strom-CO₂-Abzug. Alle Sichten nutzen jetzt den Helper co2_wp_ersparnis_kg. Demo 2025: WP-CO₂ 2280,7 → 1567,1 kg, CO₂-Gesamt im Bericht 7062 → 6348 kg. Wächter + Symmetrie-Test sichern die vier Read-Sites.
- DI-2 — HA-Export-Sensor „CO2 Einsparung” umfasst jetzt die volle Bilanz (vorher nur PV × 0,38). Über berechne_co2_bilanz; Demo (Anlage 1, gesamt): 12.538 → 11.226 kg. (total_increasing → einmaliger LTS-Sprung.)
- DI-3 — Dienstwagen zählten im Bericht (PDF) fälschlich als private E-Mobilität. Bericht filtert jetzt per ist_dienstlich wie Cockpit/Export. Betrifft nur Anlagen mit dienstlichem Fahrzeug.
- DI-4 — HA-Export-WP-Kosten bewerten WP-Strom jetzt mit dem WP-Spezialtarif (§14a) via resolve_strompreis_for_komponente. Betrifft nur Anlagen mit eigenem WP-Tarif.
- DI-5 — Vorjahres-Vergleich des Gesamt-Nettoertrags war unvollständig (Vorjahr ohne WP-/E-Mob-Ersparnis). Vorjahrespfad bildet die Kennzahl jetzt gleich zusammengesetzt (Anschaffungsdatum je Komponente respektiert). Demo: Vorjahres-Nettoertrag Juni 253,32 → 324,02 €, Januar −13,38 → 72,97 €.
Drift-Inventur Folge-Paket (DI-2) — die drei beim DI-Bau aufgetauchten Folge-Abweichungen geschlossen:
- DI-2-A — WP-CO₂ im WP-Dashboard war zu niedrig (ohne Gas-Kessel-Wirkungsgrad). Nutzt jetzt co2_wp_ersparnis_kg. Demo (Anlage 1, gesamt): 2303,6 → 2744,3 kg. Zweiter Wächter + erweiterter Symmetrie-Test sichern alle vier Read-Sites.
- DI-2-B — HA-Export: Balkonkraftwerk + sonstige Erzeuger zählen jetzt zum Eigenverbrauch (via erzeugung_hinter_zaehler_kwh). Demo (Anlage 1, gesamt): PV 38.451,8 → 39.692,4 kWh, Eigenverbrauch 14.465,4 → 17.366,0 kWh, Autarkie 79,1 → 82,0 %, EV-Quote 37,6 → 42,0 %, CO₂ 12.800,1 → 13.902,3 kg — deckungsgleich mit Cockpit. Betrifft Anlagen mit BKW/sonstigem Erzeuger.
- DI-2-C — Vorjahres-Energieanzeige zeigte Werte vor dem Anschaffungsdatum. Anschaffungsdatum-Grenze gilt jetzt auch dort. Demo (WP ab 04/2024): im Vorjahres-Januar entfallen 320 kWh WP-Strom / 1400 kWh WP-Wärme.
Anlagenbericht (PDF) + HA-Export bewerteten alle Jahre mit dem aktuellen Tarif (#326): Die Eigenverbrauchs-Ersparnis älterer Jahre wurde mit dem heutigen Strompreis statt mit dem damals gültigen Tarif gerechnet (Beispiel aus dem Issue: ~174 € Abweichung über vier Tarif-Jahre). Beide Pfade rechnen jetzt pro Monat mit dem historisch gültigen Tarif wie das Cockpit — Cockpit, Auswertungen, Bericht und HA-Export zeigen denselben Netto-Ertrag; ein gemeinsamer Zeilen-Builder mit Wächter + Symmetrie-Test sichert das dauerhaft.
E-Auto-Ersparnis bei mehreren Fahrzeugen überschätzt (G20-2): Aggregat rechnete alle km mit dem Vergleichsverbrauch des ersten Autos; jetzt Summe der Einzelfahrzeug-Ersparnisse. Demo: 167,79 → 150,96 € (Gesamt-Nettoertrag sinkt entsprechend). Betrifft Cockpit Monat/Jahr + Übersichts-Kennzahlen.
„Nächster offener Monat” übersah Binnen-Lücken (R20-2): ermittelt jetzt den frühesten offenen Monat wie die Monatsdaten-Tabelle — Fußzeile/Navigation und Tabelle zeigen wieder dasselbe.
Speicher-Dashboard las Netzladung nur unter dem Legacy-Schlüssel (R15-3): kanonischer Schlüssel mit Fallback.
Ladezeiten Live/Aussicht (R18-13): 1–30-s-Zufalls-Jitter aus dem interaktiven Prognose-Pfad entfernt (bleibt für Hintergrund-Jobs).
Diverse Tester-Runde-18/20-Meldungen: schwarzer Ladebildschirm beim ersten Aufruf (Ladezustand statt Leere), Flackern beim Rubrikenwechsel, Tabellen-Scrollverhalten + Sticky-Kopf, abgeschnittene Umschalt-Pillen, KPI-Titel „Durchschnittspreis Netz” → „Ø-Preis Netz”.

Notes

Backend-Substanz fährt mit (ehrlich benannt): Der Großteil dieser Version ist die zuvor flag-dormante IA V4, jetzt sichtbar. Zusätzlich fahren backend-wirksame, additiv/idempotente Änderungen mit (G19-1-Migration, Datenquellen-P1-Migrationen + Broker-Konsolidierung, R15-3 Netzladung-Key, Jitter-Fix, DI/DI-2-Korrekturen) — abgesichert durch ENV-Bestandsschutz und die Backend-Test-Suite. Einziger Rückweg bei Problemen ist v3.45.9.
Kein separates v3.46: Der gesamte Stand seit v3.45.9 fährt unter diesem v4.0.0-Tag (Entscheid 2026-07-20).

[3.45.9] - 2026-06-29 — Speicher-Vorzeichen-Historie: schonende Selbstkorrektur per Daten-Checker (statt Start-Migration)

Added

Daten-Checker erkennt Vergangenheitstage mit vertauschter Speicher-Richtung — und korrigiert sie auf Knopfdruck. Nach dem Vorzeichen-Fix (v3.45.7) tragen Tage, die vor dem Update aggregiert wurden, das Batterie-Tagesnetto noch in der alten (vertauschten) Richtung. Der neue Check „Batterie – Vorzeichen-Historie” findet diese Tage über ein Daten-Signal (gespeichertes Tages-Netto gegen einen frischen HA-Statistics-Read mit aktueller Konvention — gegenläufiges Vorzeichen bei beidseitig nennenswertem Betrag) und bietet zwei manuelle Reparatur-Wege: „Zeitraum neu aggregieren” (Bulk, max. 31 Tage/Lauf) und „Tag reparieren” (einzeln). Pull statt Push, user-getriggert, nie beim Start — die bewusste Lehre aus der v3.45.7-Start-Schleife: keine blockierende Historien-Migration beim Boot. Nur im HA-Add-on-Modus (HA-Statistics als Vergleichsreferenz); reine Betrags-Drift bei gleicher Richtung wird bewusst nicht geflaggt.
Intern (Maintainer-Diagnose, read-only): neuer Endpoint GET /api/energie-profil/{id}/achse2-drift macht die Achse-2-Drift (Zähler- vs. Leistungspfad) pro Tag aus gespeicherten Werten abfragbar — zum Vermessen der noch offenen Magnitude-Drift (#315) über viele Tage, ohne Schreibzugriff und ohne Re-Aggregation.

Notes

Achse-2-Magnitude-Drift bleibt diagnose-only. Die noch offene Betrags-Drift zwischen Leistungs- und Zählerpfad betrifft nur die interne Konsistenz-Diagnose im Log — die angezeigten Werte (Kacheln/Bilanz/Chart) stammen aus dem Zählerpfad und sind korrekt. Eine Berechnungs-Korrektur braucht echte 5-Minuten-Statistikdaten und einen Reproduktions-Test und folgt bewusst separat (kein Schnellschuss).

[3.45.8] - 2026-06-29 — Hotfix: Add-on-Start-Schleife durch v3.45.7-Migration behoben

Fixed

Add-on startete nach Update auf v3.45.7 nicht mehr (Neustart-Schleife). Die in v3.45.7 eingeführte Batterie-Vorzeichen-Migration reaggregierte beim Start alle historischen Tage über externe HTTP-Abrufe (HA-History + Strompreis + Wetter). Bei längerer Historie dauerte das so lange, dass der Supervisor den Add-on-Start als fehlgeschlagen wertete und neu startete — die Migration begann von vorn → Endlosschleife. Die Migration wurde entfernt. Der eigentliche Vorzeichen-Fix aus v3.45.7 (Speicher Laden/Entladen in Auswertung & Tagesverlauf) bleibt aktiv: neue Aggregationen sind korrekt; bereits inkonsistente Alt-Tage korrigieren sich beim nächsten regulären Neuberechnen bzw. gezielt über „Tag neu berechnen”. Eine sichere, nicht-blockierende Historien-Korrektur kann separat nachgezogen werden.

[3.45.7] - 2026-06-29 — Speicher: Lade-/Entlade-Richtung in Auswertung & Tagesverlauf korrigiert

Fixed

Speicher-Laden wurde in mehreren Auswertungs-Sichten falsch herum gewertet (vertauschtes Vorzeichen). Die gespeicherte Tages-Kennzahl batterie_kw wurde als Bilanz-Netto „Ladung − Entladung” (Ladung positiv) geschrieben, während der dokumentierte Feld-Vertrag und faktisch alle Anzeige-/Auswertungs-Stellen „Entladung positiv (Quelle)” erwarten. Auffällig wurde das über eine interne Konsistenz-Diagnose (Achse-2-Drift im Log) und Gertis Speicher-Werte (simon42). Behoben — vereinheitlicht auf eine kanonische Konvention (Entladung positiv) an allen Stellen: Spalte, Per-Komponenten-Aufschlüsselung und alle Leser. Konkret korrigiert:
- Energieprofil-Tagesverlauf: das Laden des Speichers erschien fälschlich auf der Quellen-Seite (▲, als Erzeugung) und floss in die „verfügbare Energie”-Linie; jetzt korrekt als Senke (▼).
- Tageswerte/Bilanz: Speicher-Ladung und -Entladung waren vertauscht (wirkte auf Tages-Tabelle/Auswertung).
- Speicher-Wirtschaftlichkeit: Netz-Ladekosten/Arbitrage wurden auf den falschen Stunden gerechnet.
- Achse-2-Konsistenz-Diagnose: der dauerhafte Vorzeichen-Flip im Log entfällt.
Live-Dashboard / Energiefluss waren NICHT betroffen (eigener Pfad, korrekt) — daher fielen die kWh-Kacheln dort nicht auf.
Einmalige Neuberechnung beim Start: bestehende Verlaufstage werden auf die korrigierte Konvention nachgezogen (Spalte und Komponenten-Aufschlüsselung bleiben dabei im Gleichschritt — keine neuen Drift-Warnungen). Bei viel Historie kann das einige Minuten dauern.

Changed

Intern — IA-v4-Vorbereitung (hinter Build-Flag, für Nutzer nicht aktiv): Referenz-Sicht-Nacharbeiten (Achsen/de-DE-Formatierung, Live-Block-Umbau, Pie-Legende) sowie zusätzliche Drift-CI-Gates. Flag-gesteuert, im ausgelieferten Produkt nicht sichtbar.

[3.45.6] - 2026-06-27 — Prognose-Kanon: „PV-Tagesprognose heute” ist überall derselbe Wert

Fixed

„Solarprognose heute” zeigte je nach Seite einen anderen Wert (Rainer/rapahl, PN simon42). Cockpit/Aussicht, die Kurzfrist-Karte, die Auswertungen/Aussichten-„eedc”-Spalte, der persistierte Tageswert und die MQTT-Sensoren rechneten den „heute”-Wert je eigenständig — eigener OpenMeteo-Abruf, Korrektur mal auf der Strahlung (GTI) mal auf der Energie, unterschiedliche System-Verluste, teils „IST + Rest” statt Tagesprognose. Ergebnis waren bis zu vier verschiedene Werte fast zeitgleich (z. B. 75,3 / 77,0 / 79,5 / MQTT 76,8). Jetzt liefert ein kanonischer Service (prognose_kanon) den Wert für alle Pfade: Multi-String-Fan-out pro Orientierungsgruppe (Ost/West sauber getrennt) → ein roh-OpenMeteo-kWh-Profil → eedc-Korrektur pro Energie-Slot (Tageswert = Σ der Stunden-Slots). Der Wert rollt über den Tag mit OpenMeteo mit — aber synchron in Anzeige, Vergleich, Persistenz und MQTT. Die alternative Quelle (Solcast/SFML) folgt derselben „ein Wert überall”-Regel; nur auf der Prognose-Vergleichs-Seite stehen OpenMeteo/eedc/Solcast bewusst nebeneinander, wobei die eedc-Spalte mit allen anderen Seiten übereinstimmt.

⚠ Nachträglich richtiggestellt (August 2026): Für die alternative Quelle (Solcast/SFML) gilt „ein Wert überall“ nicht — und zwar an einer Stelle, die der Satz oben ausdrücklich mit aufzählt: Die HA-/MQTT-Sensoren trugen schon damals immer die eedc-eigene Prognose, nie Solcast oder SFML. Das ist Absicht — beide liegen über ihre eigene Home-Assistant-Integration ohnehin nativ dort, ein zweiter Export wäre eine zweite Driftstelle —, es stand aber nur in der Sensor-Referenz und nicht hier. Unauffällig war es, weil bis dahin auch auf dem Bildschirm nur ein Teil der Zahlen der gewählten Quelle folgte: Rest und nachgeführter Tageswert kamen ebenfalls aus dem eedc-Kanon. Seit der Live-Block vollständig der gewählten Quelle folgt, gehen Bildschirm und Sensor bei Solcast/SFML sichtbar auseinander, und die Sensor-Referenz sagt es dort jetzt ausdrücklich. Für die eedc-Standardquelle stimmt der Satz oben unverändert.
MQTT „PV-Prognose heute” = Anzeige-Wert. Der MQTT-„heute”-Sensor war zuvor „IST bisher + Rest-Stunden” und damit systematisch anders als die App-Anzeige. Er trägt jetzt denselben kanonischen Tagesprognose-Wert; „PV-Prognose Rest heute” kommt aus demselben Helper (beide rollen synchron, auch bei großer OpenMeteo-Korrektur).
Genauigkeits-Tagesabschluss „benimmt sich nicht mehr merkwürdig” (Rainer). Das Genauigkeits-Ranking vergleicht IST jetzt gegen einen eigenen, konvergenz-gefrorenen Endwert (pv_prognose_final_kwh): er rollt mit, bis OpenMeteo für den Tag nach Sonnenuntergang konvergiert ist, und wird dann eingefroren — kein Mid-Correction-Snapshot mehr. Der Anzeige-Wert bleibt bewusst rollend.

Changed

Mehr-Orientierungs-Anlagen (z. B. Ost/West) bekommen den heute-Wert jetzt überall multi-string-genau — er kann sich daher leicht von früheren Einzel-Orientierungs-Schätzungen unterscheiden (gewollt, genauer). Bei unvollständigem Abruf einer Orientierungsgruppe wird der Tageswert wie bisher nicht eingefroren (#306).

[3.45.5] - 2026-06-22 — Live-Tagesverlauf: keine unmöglichen Leistungs-Nadeln bei groben Zählern

Fixed

Live-Tagesverlauf zeigt keine physikalisch unmöglichen Leistungs-Nadeln mehr (#680, mameier1234). Bei Wechselrichtern/Zählern mit grober kWh-Auflösung oder seltener Cloud-Aktualisierung erschienen im Live-Tagesverlauf vereinzelt Riesen-Spitzen (z. B. 13 kW bei 11 kWp) samt spiegelbildlichem Haushalts-Ausschlag — die Tagessumme stimmte, nur die Kurvenform war verzerrt. Ursache: Die Kurve rekonstruiert die Leistung aus dem kWh-Zähler (P = ΔkWh × 12000) und unterstellt 5-Minuten-Auflösung; meldet der Zähler seltener, bucht Home Assistant den ganzen Zuwachs in einen Slot → Nadel. Jetzt fällt nur die Kurvenform stundenweise auf den Live-Leistungssensor zurück, wenn der Zähler nachweislich zu grob ist (Phantom-Null: Zähler ≈ 0, Live > 50 W); die Stunden-Energie bleibt die Zählersumme und wird auf die Live-Form normiert → Summe exakt erhalten (LTS-treu), Live-Drift kann die Energie nicht verfälschen. Detektor ist in-memory (keine HA-Extra-Abfrage), Entscheidung pro Stunde. Standalone-/MQTT-Installationen sind bereits leistungsbasiert und nicht betroffen.

Changed

Intern — IA-v4-Vorbereitung (hinter Build-Flag, für Nutzer noch nicht aktiv): Referenz-Sicht Cockpit/Live (das reiche IST-Live-Layout in die neue Shell eingepasst, kein Neubau; durchgängiger Fokus/Vollbild-Schalter je Karte als geteilter Baustein) sowie Komponenten-Hub-Feinschliff. Flag-gesteuert, im ausgelieferten Produkt nicht sichtbar (Produktiv-Build bit-identisch ohne v4-Code).

[3.45.4] - 2026-06-22 — Sonstige Erzeuger (BHKW) zählen in die Energiebilanz

Fixed

Sonstige Erzeuger (z. B. Mini-BHKW) zählen jetzt überall in die Energiebilanz. Wer einen Erzeuger unter „Sonstiges” gepflegt hat, sah dessen Erzeugung im Monatsbericht, der Cockpit-Übersicht und den Auswertungen-Finanzen bisher nur isoliert — sie floss dort nicht in Eigenverbrauch/Autarkie ein. Da Einspeise- und Netzbezugs-Zähler aber die Summe aller Erzeuger hinter dem Hausanschluss messen, war die Bilanz dadurch still verfälscht: Der gemessene Einspeise-Wert enthielt den Beitrag des sonstigen Erzeugers, die gezählte Erzeugung jedoch nicht → Direkt-/Eigenverbrauch und Autarkie wurden zu niedrig ausgewiesen. Jetzt geht die Gesamterzeugung (PV + Balkonkraftwerk + sonstige Erzeuger) konsistent in alle Bilanz-Sichten ein — monatlich, im Live-Dashboard (ein sonstiger Erzeuger mit Live-Leistungssensor erscheint als eigene Erzeugungs-Quelle und hebt Live-Autarkie/Eigenverbrauch) und in der Tages-/Energieprofil-Bilanz (dort war er bereits enthalten).
PV-Kennzahlen bleiben rein: spezifischer Ertrag, Performance-Ratio, SOLL/IST und die PV-Leistungs-Anzeige zählen weiterhin ausschließlich die PV-Erzeugung — ein sonstiger Erzeuger ist energetisch Erzeuger, aber kein PV-Modul. (Die Tages-Performance-Ratio enthielt den Anteil bisher fälschlich; jetzt PV-rein.)
CO₂/Wirtschaftlichkeit eines brennstoffbasierten Erzeugers bleiben bewusst „nicht bewertet” (ein BHKW spart kein CO₂ und hat Brennstoffkosten — ein eigenes Modell folgt separat). Inselanlagen sind nicht betroffen (kein Netzbezug/keine Einspeisung).

[3.45.3] - 2026-06-19 — Daten-Checker erkennt vertauschte Leistungs-/Energie-Sensoren

Added

Daten-Checker findet vertauschte Leistungs- und Energie-Sensoren (#674, #200). Wenn ein kWh-Zählerstand versehentlich in einem Live-Leistungs-Slot (W) gemappt ist — oder umgekehrt ein Leistungssensor (W) in einem kWh-Slot — meldet der Daten-Checker das jetzt gezielt: kWh-im-Leistungs-Slot als Fehler, Leistung-im-kWh-Slot als Warnung (die Laufzeit hat dort einen Trapez-Fallback). Solche Verwechslungen waren bisher schwer zu finden — ein kWh-Wert (z. B. 7130) als „7130 W” gelesen ließ den live berechneten Hausverbrauch auf 0 hängen, während die kWh-Monatswerte korrekt blieben. Der Check läuft über alle gemappten Slots (Live + Zähler, Anlage + Investitionen) und ist auf die eindeutige Leistung/Energie-Verwechslung beschränkt (%/°C/Preis/km bleiben bewusst außen vor, kein Fehlalarm). Ohne Home-Assistant-Anbindung (Standalone) wird er still übersprungen.

Changed

Klarere Ursachen-Hinweise in den Monats-Checks: Die Prüfungen „Einspeisung größer als PV-Erzeugung” und „negativer Hausverbrauch” nennen jetzt vertauschte Netz-Sensoren als wahrscheinliche Ursache.
Intern — IA-v4-Vorbereitung (hinter Build-Flag, für Nutzer noch nicht aktiv): Weiterer Aufbau des kommenden Menü-/Sichten-Konzepts (Referenz-Sicht „Cockpit/Monat”) sowie geteilte Anzeige-Bausteine. Diese Arbeit ist flag-gesteuert und im ausgelieferten Produkt nicht sichtbar (Produktiv-Build bit-identisch ohne v4-Code).

[3.45.2] - 2026-06-14 — Hotfix: API-Start (fastapi-0.137.0-Regression)

Fixed

Add-on registrierte nach v3.45.1 nur einen Bruchteil der API-Routen (~42 statt ~226) — große Teile der App waren nicht erreichbar. Ursache: fastapi 0.137.0 (frisch erschienen, über das ungedeckelte fastapi>=0.109.0 gezogen) hat eine Regression in include_router(prefix=…) — unter Python 3.11 (HA-Add-on-Laufzeit python:3.11-slim) werden die Sub-Routen nicht übernommen. fastapi ist jetzt auf <0.137 gedeckelt (0.136.x ist sauber). Reiner Dependency-Pin, kein Code geändert. Verifiziert: voller App-Boot auf 3.11 → 226 Routen.

[3.45.1] - 2026-06-14 — Berechnungs-Kern konsolidiert: weniger Drift, korrektere Detail-Werte

Fixed

E-Auto ohne Kilometer-Daten ließ die Finanz-Prognose (Aussichten) abstürzen (500-Fehler durch fehlenden Schlüssel) — behoben, fehlende km-Basis wird sauber abgefangen.
Eigenverbrauchsquote konnte über 100 % anzeigen. In der Aussichten-Prognose und im PDF-Jahresbericht konnte die Quote bei Quellen-Drift (Eigenverbrauch > Erzeugung) rechnerisch über 100 % springen — jetzt app-weit auf 100 % begrenzt (zentraler Helper).
Monats-Aggregat (/aggregiert) an die übrigen Auswertungen angeglichen: Wärmepumpen-Heizenergie aus Alt-/Importdaten (Legacy-Feld heizung_kwh) wurde teils ignoriert, und dienstliche E-Autos/Wallboxen wurden mitgezählt (fehlender ist_dienstlich-Filter). Beides korrigiert. Cockpit-Übersicht: Sonstiges-Aggregat ist jetzt kategorie-bewusst.

Changed

Speicher-Cockpit lädt schneller (#333): gezielte Spalten-Projektion beim Laden der Speicher-Wirtschaftlichkeit.
Intern — großes verhaltensneutrales Refactoring des Berechnungs-Kerns (Berechnungs-Layer, ADR-001): Die monatliche per-Komponenten-Aggregation, die Netzbezugskosten, die Kennzahlen (Autarkie/Eigenverbrauchsquote/spezifischer Ertrag) und die Speicher-Wirtschaftlichkeit (reine Berechnung vs. DB getrennt) laufen jetzt über einen zentralen Single-Source-of-Truth-Layer statt über verstreute Inline-Kopien. Verhindert künftige Drift zwischen Cockpit, Auswertungen, Monatsbericht, HA-Export und PDF. Keine Funktionsänderung an diesen Stellen; abgesichert durch ~1165 Tests, Char-Netze, Symmetrie- und Konformitäts-Wächter.

[3.45.0] - 2026-06-13 — Design-Fundament: einheitliche Farben, Tooltips, KPI-Karten & verlinkbare Reiter

Changed

Eine Farbe = eine Bedeutung: app-weite Farb-Vereinheitlichung (Design-Fundament für v4.0.0, Paket P1). Alle Chart- und Anzeige-Farben kommen jetzt aus einer zentralen Definition (lib/colors.ts) statt aus über 360 verstreuten Einzelwerten in 40 Dateien — ein Wächter-Check (npm run check:design) verhindert ab sofort neue Streuner. Dabei wurden bewusst sichtbare Inkonsistenzen bereinigt (alle vom Maintainer freigegeben):
- Netzbezug ist überall Dunkelrot (statt Signal-Rot) — das helle Signal-Rot ist jetzt exklusiv für Kosten, negative Werte und Fehler reserviert. Damit sind Netzbezug-Serie und „Achtung”-Rot erstmals unterscheidbar.
- PV/Solar einheitlich in einem Amber-Ton — vorher drei verschiedene Gelbtöne je nach Seite (u. a. Live-Ansichten).
- Speicher überall: Ladung = Grün, Entladung = Blau — inkl. Live-Energiefluss (vorher dort Blau/Cyan).
- Lade-Quellen (E-Auto/Wallbox) überall gleich: PV = Grün, Netz = Dunkelrot (Netz-Ladung ist Netzbezug), Extern = Orange — vorher drei verschiedene Schemata in Cockpit, Auswertungen und Community.
- „Du/deine Anlage” in Community-Vergleichen überall Blau (vorher je nach Tab blau, grün oder violett).
- Wetter-/Energiefluss-Kategorien, SOLL/IST-Farben, Prognose-Quellen-Farben, Jahresvergleichs- und PV-String-Paletten sind jetzt app-weit identisch.
Intern (Fundament): Status-Farbachse (OK/Warnung/Kritisch/Info) und Geld-Farblogik zentral definiert; Tailwind-Theme bezieht die Farben direkt aus der Zentrale (kein Drift möglich); KPI-Karten-Farbklassen auf eine Definition zusammengeführt; Komponenten-KPI-Stile als Kanon für alle 7 Komponententypen (+ 3 Sonstiges-Varianten) hinterlegt, Wärmepumpen-/Speicher-Dashboard konsumieren sie.
Dark-Mode-Lesbarkeit überall verbessert (Design-Fundament Paket P2). Gedämpfter Text und Icons (Captions, Hinweise, Platzhalter) hatten an über 250 Stellen kein Dunkel-Pendant und wirkten im Dunkelmodus zu grell — jetzt durchgängig dezent abgestimmt. Diagramm-Achsen, Gitterlinien und Referenzlinien passen sich jetzt dem Dunkelmodus an (vorher in vielen Charts fest helle Linien). Zwei Lesbarkeits-Fehler behoben, bei denen Hinweistext im Dunkelmodus zu dunkel statt heller wurde.
Einheitliche Tooltips überall (Design-Fundament Paket P3). Alle Tooltips (Diagramm-Werte, Berechnungs-Herleitungen, Kurz-Hinweise) haben jetzt dasselbe dunkle Aussehen mit abgerundeten Ecken — vorher waren die Diagramm-Tooltips hell und brachen optisch aus, und es gab leicht unterschiedliche Eckenrundungen/Schriftgrößen. Tooltips liegen jetzt zuverlässig über Dialogen (vorher konnten sie teilweise dahinter verschwinden).
Komponenten erscheinen überall in derselben Reihenfolge (Design-Fundament Paket P4). Die Reihenfolge der Komponenten-Typen (Wechselrichter → PV-Module → Speicher → Balkonkraftwerk → Wärmepumpe → Wallbox → E-Auto → Sonstiges) ist jetzt app-weit identisch — vorher sortierten mehrere Listen (Investitionsliste, ROI-Übersicht, Sensor-Zuordnung, HA-Import, Daten-Export, Cockpit-Reiter, Monatsbericht- und Auswertungs-Abschnitte, Finanzbericht-PDF) teils alphabetisch (Balkonkraftwerk fälschlich zuerst). Die Reihenfolge kommt jetzt aus einer einzigen Quelle. Datums-sortierte Tabellen/Listen zeigen weiterhin durchgängig neueste zuerst (geprüft, keine Ausreißer); Verlaufs-Diagramme bleiben bewusst chronologisch.
Einheitliche Schreibweisen (Design-Fundament Paket P5). Prozent-Werte stehen jetzt durchgängig mit Leerzeichen vor dem Zeichen („84,2 %” statt „84,2%”) — an knapp 100 Stellen vereinheitlicht (CSS-Balkenbreiten u. ä. bleiben unberührt). Die Eigenschreibweise „eedc” (klein) ist jetzt auch in den PDF-Berichten und auf der Projekt-Website durchgezogen (vorher dort teils „EEDC”). Die Schaltflächen in der Community-Teilen-Ansicht nutzen jetzt die zentrale Button-Komponente (einheitlicher Stil: flache Sekundär-Aktionen, gefüllte Haupt-/Lösch-Aktion, Icon-Buttons mit Tooltip).
Kennzahl-Kacheln (KPI-Karten) überall aus einer Quelle (Design-Fundament für v4.0.0, Paket E1-P2). Die vielen Kennzahl-Kacheln in Cockpit, Auswertungen, Komponenten-Dashboards, ROI- und Energieprofil-Ansichten kamen bisher aus acht leicht voneinander abweichenden Eigenbau-Varianten (unterschiedliche Schriftgrößen, Icon-Positionen, Einheiten-Abstände). Sie laufen jetzt über eine zentrale Komponente mit drei Größenstufen — gleiche Einheiten-Position, gleiche Icon-Position, gleiche Farb-Logik. Die Kachel-Farben kommen ausschließlich aus dem zentralen 8-Farben-Kanon (vereinzelte Streuner wie Amber/Emerald/Teal auf Gelb/Grün/Cyan zusammengeführt). Keine Funktionsänderung; die Community-Vergleichskachel (mit Ø-Abweichung) bleibt eine bewusst getrennte, dokumentierte Spezialvariante auf derselben Farb-/Größenlogik.
Auswertungen, Aussichten und Community haben jetzt eigene Adressen pro Reiter (Design-Fundament für v4.0.0, Paket E1-P3). Die Reiter dieser drei Seiten sind jetzt direkt verlinkbar (z. B. …/#/auswertungen/finanzen, …/#/aussichten/prognosen) und landen aus den Browser-Verlauf/Lesezeichen wieder beim richtigen Reiter; alte Adressen ohne Reiter zeigen weiterhin den ersten Reiter. Die Reiter-Leiste sieht aus und verhält sich wie zuvor (inkl. „Beta”-Markierung und Tooltips). Keine Funktionsänderung.
Intern (Fundament E1-P3): Klickbares Vorschau-Skelett der neuen v4.0.0-Navigationsstruktur unter /dev/design-preview (nur im Entwicklungsmodus sichtbar) — Top-Navigation der drei Achsen, Cockpit-Sub-Tabs, Komponenten-Hub (Variante C) und Einstellungs-Kachelgrid als Klick-Dummy mit der KPICard-SoT. Erstmals eine Frontend-Test-Infrastruktur (Vitest + Testing Library): Auto-Test der Bestands-Redirects (keine 404, keine Ketten), KPICard-Tests und der Inline-Farb-Wächter laufen jetzt in der CI neben den Backend-Tests.
Intern (Fundament E1/E2): Das Vorschau-Skelett ist als guard-freie Komponente (components/preview/IASkeleton.tsx) herausgelöst und kann jetzt öffentlich ohne Backend gehostet werden: eigener Vite-Vorschau-Build (npm run build:preview, eigener Entry preview.html/preview-main.tsx, Pages-Base /eedc-homeassistant/preview/, eigenes Out-Dir preview-dist/) — getrennt vom Produktiv-Build (npm run build unverändert). Der Pages-Workflow baut die Vorschau und schleust sie nach website/dist/preview/ ein; der Vorschau-Output ist gitignored (Wegwerf-Vorschau für das Menüstruktur-Feedback zu #243).

[3.44.0] - 2026-06-12 — Einstellbare Günstig-Schwelle, Mehrtages-Prognose mit Korrekturprofil & Stundenprofile

✨ Minor / Feature + Fixes. Das Abschluss-Release der HA-Export-Runde: Die Günstig-Schwelle der Börsenpreis-Sensoren ist pro Anlage einstellbar, die Mehrtages-Prognose (morgen/übermorgen/Tag+3) korrigiert OpenMeteo jetzt pro Stunde über die gelernte Korrekturprofil-Kaskade — HA-Export und Prognosen-Vergleich zeigen denselben Wert —, alle vier Prognose-Sensoren tragen ihr Stundenprofil als Attribut (Tageswert == Σ Stunden, garantiert), und die Status-Sensoren wandern in den Diagnose-Bereich. Dazu: der Dokumente-ZIP scheitert nicht mehr an einer leeren Infothek (Dirk), und die Export-Sensoren sind erstmals vollständig in der Hilfe dokumentiert. 1030 Backend-Tests grün.

Fixed

Dokumente: leere Infothek lässt den ZIP-Download nicht mehr komplett scheitern (Dirk, PV-Forum). Wer alle Berichte fürs ZIP ankreuzte, aber keine Infothek-Einträge gepflegt hat, bekam einen Komplett-Fehler („Infothek-Dossier: ValueError: Keine Einträge zum Exportieren”) — und gar kein ZIP. Jetzt wird die Infothek-Dossier-Karte bei leerer Infothek deaktiviert angezeigt (mit Hinweis, wo Einträge gepflegt werden) und ist weder einzeln noch fürs ZIP wählbar — die übrigen Berichte laden normal. Direkte API-Aufrufe erhalten statt des rohen Fehlers eine verständliche Meldung; echte Render-Fehler brechen das ZIP weiterhin bewusst komplett ab (kein halbes ZIP).

Added

HA-Export: Stundenprofil-Attribute auch an „PV-Prognose morgen/übermorgen/Tag+3”. Die drei Folgetag-Sensoren tragen jetzt — wie der Heute-Sensor — das komplette korrigierte Stundenprofil als Attribut stundenprofil_kwh (24 kWh-Werte, Slot N = Energie der Stunde N−1 → N). Damit lassen sich Lade-/Verbrauchsplanungen für morgen direkt in HA-Templates bauen (z. B. Vormittags-Summe = [:13] | sum); eigene VM/NM-Sensoren gibt es bewusst nicht, das bleibt Template-Sache. Es gilt garantiert: Sensor-Tageswert == Σ Stundenprofil (Invarianten-Test).
HA-Export: Günstig-Schwelle pro Anlage einstellbar (rapahl-PN-Folge). Der Prozentsatz unter dem Tagesdurchschnitt, ab dem eine Stunde als „günstig” gilt, lässt sich jetzt auf der MQTT-Export-Seite je Anlage festlegen (0–50 %, Standard 10 %) — wer z. B. mit Ø×0,925 plant, trägt 7,5 % ein und steuert damit Anzahl der günstigen Stunden und die eigene Ladeverlust-Abwägung selbst. Wirkt auf Börsenpreis-Rang und alle drei Günstige-Stunden-Sensoren; die Lade-/Entlade-Strategie bleibt bewusst beim Nutzer in HA.

Changed

PV-Prognose morgen/übermorgen/Tag+3: Korrekturprofil-Kaskade statt Pauschal-Lernfaktor. Die Folgetag-Prognosen (HA-Export-Sensoren und Spalte „eedc” im Prognosen-Vergleich) korrigieren OpenMeteo jetzt pro Stunde über die gelernte Korrekturprofil-Kaskade (Sonnenstand × Wetter → Saison-Stunde → Sonnenstand → Skalar) — wie es der Live-Tagesverlauf seit v3.26 tut — statt mit einem pauschalen Tages-Lernfaktor. Saisonale Verschattung oder systematische Vormittags-Abweichungen fließen damit auch in die Mehrtages-Werte ein. Der Tageswert ist die Σ der korrigierten Stunden; HA-Sensor und Prognosen-Vergleich zeigen denselben Wert (Symmetrie-Test). Bei Anlagen ohne gelerntes Profil ändert sich nichts (Lernfaktor-Skalar wie bisher). Hinweis für Beobachter der Day+1/+2-Sensoren: die Werte können sich jetzt zusätzlich zum OpenMeteo-Modelllauf-Takt auch mit dem nächtlichen Korrekturprofil-Update ändern — das ist gewollt.
HA-Export: Status-Sensoren wandern in den Diagnose-Bereich (rapahl-PN-Folge). Die vier Status-Sensoren („Letzter Import — Jahr/Monat/Monatsname” und „Erfasste Monate”) werden per MQTT Discovery jetzt als entity_category: diagnostic angelegt — sie erscheinen in HA im Diagnose-Bereich des eedc-Geräts statt in der normalen Sensor-Liste und entlasten so die Entitäten-Übersicht. Wirkt nur auf neu angelegte Entitäten; bestehende behalten ihre Kategorie (wer umstellen will: Discovery bereinigen und erneut publizieren — oder einfach so lassen).

[3.43.0] - 2026-06-11 — HA-Export-Feinschliff, Cloud-Import ohne Timeout & Anker-SOLIX bestätigt

✨ Minor / Feature + Fixes. Drei Stränge: Der HA-Export wird nach rapahls MQTT-Gegencheck präziser (echter Rest-Prognosewert + neuer rollender Tageswert, „Günstige Stunden” mit echter Preis-Schwelle statt konstant 10, spezifischer Ertrag aufs Jahr normiert). Der Cloud-Import läuft jetzt als Hintergrund-Job und bricht bei langen Zeiträumen nicht mehr mit „Failed to fetch” ab (alle Provider). Und Anker SOLIX ist nach Johnnys Gegentest bestätigt (Netzbezug/Batterie korrekt, robust gegen API-Drosselung, nicht mehr „in Erprobung”). 1017 Backend-Tests grün.

Added

HA-Export: „PV-Prognose heute” + echter Rest-Wert (rapahl-PN). Der Sensor „PV-Prognose Rest heute” enthielt das bisherige IST und war damit faktisch der Tageswert unter irreführendem Namen („Rest 67 kWh um 11 Uhr”). Jetzt liefert er nur noch die Prognose der verbleibenden Stunden (Steuerungswert: wie viel PV kommt noch), und ein neuer Sensor „PV-Prognose heute” zeigt den rollenden Tageswert (IST bisher + Rest — läuft mit dem IST mit, wie seinerzeit besprochen). Das Stundenprofil-Attribut hängt jetzt am Tageswert-Sensor.
HA-Export: „Günstige Stunden” mit echter Preis-Schwelle + Tag/Nacht getrennt (rapahl-PN). Bisher waren die „günstigen” Stunden rein relativ (die 5 billigsten je Tag-/Nacht-Fenster) — die Anzahl stand damit praktisch konstant auf 10, und der Börsenpreis-Rang markierte Stunden als günstig, in denen erzwungener Verbrauch oder Netzladung keinen Sinn ergibt. Günstig ist jetzt nur, was zusätzlich mindestens 10 % unter dem Tagesdurchschnitt ohne die 3 Peak-Stunden liegt (Rainer-Definition). Neue Sensoren „Günstige Stunden Tag” und „Günstige Stunden Nacht” (je max. 5); die Schwelle reist als Attribut guenstig_schwelle_cent am Börsenpreis-Rang mit.

Fixed

HA-Export: „Spezifischer Ertrag” aufs Jahr normiert statt Laufzeit-Summe (rapahl-PN). Der Sensor rechnete Lebenszeit-PV-Erzeugung ÷ heutiges kWp — bei 3 Jahren Historie rund das Dreifache des gewohnten Jahreswerts (Rainer: 1.955 kWh/kWp). Jetzt rechnet er über denselben SoT-Helper wie die Cockpit-Kachel: saisonal gewichtet annualisiert (PVGIS-Monatsverteilung, Fallback 52°N) und mit der pro Monat tatsächlich aktiven PV-Leistung (Erweiterung/Teil-Rückbau). Neuer Berechnungs-Layer-Helper core/berechnungen/spez_ertrag.py (ADR-001), Symmetrie-Test Cockpit == HA-Export.
Cloud-Import: kein „Failed to fetch” mehr bei langen Zeiträumen (#328). Der Datenabruf aus den Hersteller-Clouds lief als ein einziger langer Request — bei vielen Monaten (z. B. Anker SOLIX mit drei Datenbereichen pro Monat) brach der Browser bzw. das HA-Ingress nach einigen Minuten mit „Failed to fetch” ab, obwohl der Import im Hintergrund weiterlief. Der Abruf läuft jetzt als Hintergrund-Job mit Status-Abfrage: der Wizard zeigt „Abruf läuft im Hintergrund … (Xs)” mit Sekunden-Zähler und wartet zuverlässig auf das Ergebnis, egal wie lange es dauert. Gilt für alle Cloud-Provider.
Anker SOLIX: robuster bei API-Drosselung (HTTP 429, #328). Bei längeren Import-Zeiträumen (viele Monate × drei Datenbereiche) drosselt die Anker-Cloud gelegentlich (HTTP 429). Bisher wurde der betroffene Bereich/Monat dann übersprungen — jetzt wartet eedc gestaffelt (30 s, dann 60 s) und versucht es erneut, sodass keine Werte verloren gehen. Bleibt es dauerhaft bei 429, erscheint weiterhin die klare Hinweis-Meldung.

Changed

Anker SOLIX als „getestet” markiert (#328). Nach dem v3.42.1-Mapping-Fix hat Johnny_1993 am echten Gerät bestätigt, dass Login, Datenabruf und die Werte (PV, Einspeisung, Netzbezug, Batterie) stimmen — der Provider ist nicht mehr als „in Erprobung” gekennzeichnet.

[3.42.1] - 2026-06-11 — PDF-Sonstige, Anker-SOLIX-Mapping & Standalone-PDF-Fix

🔧 Patch / Fixes. Mehrere Tester-Befunde aus den v3.42.0-Gegenchecks: Der PDF-Anlagenbericht weist „Sonstige Erträge & Ausgaben” jetzt durchgängig aus (rilmor-mhrs, #326-Folge), der Anker-SOLIX-Import füllt Netzbezug und Batterie korrekt (Johnny_1993, #328), und der Standalone-PDF-Export läuft wieder (SolarKlim2025 — dem Standalone-Image fehlten die WeasyPrint-Systemlibs). Dazu eine klarere Port-Beschriftung (rapahl) und zwei interne Berechnungs-Layer-Slices. 1005 Backend-Tests grün.

Fixed

Anker SOLIX Cloud-Import: Netzbezug & Batterie-Werte korrekt (#328, Gegentest Johnny_1993). Der erste echte Gerätetest zeigte: PV-Ertrag und Einspeisung stimmten, aber der Netzbezug fehlte ganz und die Batterie-Lade/Entlade-Werte waren falsch. Ursache: der energy_analysis-Endpunkt liefert je device_type nur die Felder seines Bereichs — ein einzelner solar_production-Aufruf enthält weder Netzbezug noch die Batterie-Summen. eedc fragt jetzt pro Monat drei Bereiche ab (solar_production, home_usage, solarbank) und setzt sie zusammen: Netzbezug aus grid_to_home_total, Batterie-Ladung aus PV- + Netz-Anteil, Entladung aus battery_to_home_total. Optionale Bereiche dürfen fehlen (Anlage ohne Speicher), ohne den Monat zu verlieren. Feldnamen anhand der Anker-OSS-Referenz (thomluther/anker-solix-api) verdrahtet. Provider bleibt als „ungetestet” markiert, bis der erneute Gegentest grün ist.
Anlagen-/Jahresbericht (PDF): „Sonstige Erträge & Ausgaben” durchgängig (#326-Folge, rilmor-mhrs). Cockpit und Auswertung berücksichtigten die manuell gepflegten sonstigen Positionen bereits, der PDF-Bericht aber nur unvollständig: die Monats-Ertragsspalte rechnete sie nicht ein, weshalb ein per saldo negativer Monat (z. B. größere Sonderausgabe im Dezember) positiv erschien und die Monatszeilen sich nicht auf den ausgewiesenen Jahres-Netto-Ertrag summierten. Jetzt steckt die Sonstige-Position pro Monat in der jeweiligen Ertragszeile (richtige Monatszuordnung, negative Monate werden negativ) und die Finanz-Übersicht weist „Sonstige Erträge/Ausgaben” als eigene Zeile aus, sofern vorhanden. Symmetrie-Test erweitert: Σ Monats-Netto == Summary-Netto inkl. Sonstiger.
Standalone-Docker: PDF-Export reparieren (WeasyPrint-Systemlibs, SolarKlim2025). Das Standalone-Image (ghcr.io/supernova1963/eedc:latest) brachte die nativen WeasyPrint-Bibliotheken nicht mit — seit reportlab raus ist (v3.41.0) schlug jeder PDF-/ZIP-Export mit cannot load library 'libgobject-2.0-0' fehl. Das HA-Add-on-Image hatte diese Libs bei der WeasyPrint-Umstellung (#303) bekommen, der separat gepflegte Standalone-Dockerfile wurde dabei übersehen. Jetzt installiert auch das Standalone-Image libpango-1.0-0, libpangoft2-1.0-0, fontconfig und fonts-dejavu-core. (Betrifft nur Standalone/Docker-Nutzer; HA-Add-on war nie betroffen.)
Add-on: Port 8099 klar beschriftet (ports_description, rapahl). Der Port für den optionalen REST-Export erschien in den Add-on-Netzwerkeinstellungen nur unbeschriftet als „8099/tcp” (und erst nach „Deaktivierte Ports einblenden”). Er trägt jetzt eine Beschreibung, die erklärt, dass er ausschließlich für den REST-Sensor-Export nach HA nötig ist und für die normale Nutzung bzw. den MQTT-Export aus bleiben kann. Default unverändert deaktiviert (sichere Ingress-Nutzung).

Intern (nicht anwender-sichtbar)

Live-Tagesverlauf konsistent mit HA-LTS-SoT (#135-Folge): Im Add-on-Modus speist die Butterfly-Kurve ihre Slots jetzt aus statistics_short_term (5-Min) statt der rohen Power-History — dieselbe SoT-Familie wie die Heute-kWh-Kacheln (safe_get_tages_kwh). Pro Serie: kWh-Zähler → 5-Min-sum-Deltas → Leistung (deckungsgleich mit der Kachel, Σ Slot-Energie == Tages-Zähler-Delta exakt); reine Power-Sensoren → short_term.mean. Daten-getriebener Fallback je Serie auf die rohe History (kein Feature-Flag); Standalone/MQTT-Pfad und Response-Format unverändert (kein Frontend-Touch). Neue Aggregat-Logik im Berechnungs-Layer (core/berechnungen/live_tagesverlauf_5min.py + ha_statistics_service.get_short_term_5min_for_day, ADR-001), Konsistenz-/Reset-/Fallback-Tests. Letzter Slice vor IA-V4 Phase 0.
Pre-IA-V4 Berechnungs-Layer-Sweep (ADR-001): Die vom kommenden Menüstruktur-Umbau (#243) berührten Read-Sites sind vorab auf die zentralen Helper gezogen, damit die UI-Umbauten keine Backend-Strukturmigration mitschleppen. (A) Live-Keyspace-PV-Erkennung nutzt die zentrale PV_KOMPONENTEN_PREFIXE-Liste statt Inline-Literalen (live_history_service, live_komponenten_builder — verhaltensgleich, neuer Konformitäts-Wächter hält die Klasse zu). (B) Die SoC-Tagesvorschau im Energieprofil rechnet über die zentrale Speicher-Simulation simuliere_speicher_tag() statt einer eigenen Schleife (Helper additiv um per-Stunde-Bilanz erweitert, Regressionstest gegen die alte Logik). Audit der vier IA-V4-Module abgeschlossen — übrige Sichten SoT-konform; drei dokumentierte Folge-Kandidaten (monatlicher IMD-Typ-Helper, Autarkie-Nenner-Produktentscheid, Kostenformel-Bündelung) bewusst außerhalb des Sweeps.

✨ Minor / Feature + Fixes. Die Vor-IA-V4-Abräumrunde in einem Release: die Prognose lernt saisonale Verschattung (Monat × Stunde, Dirk), der Anker-SOLIX-Cloud-Import funktioniert wieder (Login + Daten-Endpunkt portiert, #328 — Gegentest Johnny ausstehend), der HA-Export stolpert nicht mehr (REST-YAML mit echter Adresse, MQTT-Start-Publish, Auto-Publish folgt mqtt.enabled — rapahl/Gernot), mehrere PDF-Berichte als ein ZIP (#121-Rest) und die Aussichten rechnen über dasselbe Finanz-Aggregat wie Cockpit/Berichte (#326-Folge). 991 Backend-Tests grün.

Added

Saisonal aufgelöste Prognose-Korrektur (Verschattung). Das Korrekturprofil lernt jetzt zusätzlich einen Faktor pro Monat × Stunde — für saisonale Verschattung (z. B. belaubte Bäume), die das Sonnenstand-Profil prinzipbedingt nicht trennen kann (gleicher Sonnenstand im belaubten Spätsommer und im kahlen Frühjahr wurde gemittelt). Neue Stufe in der Korrektur-Kaskade (Sonnenstand×Wetter → Saison-Stunde → Sonnenstand → Skalar), aktiv ab ≥50 Stunden-Datenpunkten je Monats-Bin; dünn belegte Monate fallen auf Quartal bzw. rollierende 30 Tage zurück (bewusst nicht all-time — sonst würden nie gesehene Monate mit saisonfremden Faktoren gefüllt). Diagnose: neuer Tab „Saison (Monat × Std.)” in der Korrekturprofil-Heatmap. Gilt nur für die eedc-Prognose (Solcast/SFML bleiben pur), Day-Ahead-Linie unverändert, keine DB-Migration. Anlass: Dirk (PN 2026-05-31).
Dokumente: mehrere Berichte als ein ZIP herunterladen (#121-Rest). In Einstellungen → Stammdaten → Anlage → Dokumente lassen sich die PDF-Berichte jetzt per Checkbox auswählen und ab zwei Stück gesammelt als ZIP laden (Dateinamen wie die Einzel-Downloads, inkl. Jahres-Auswahl). Schlägt ein Bericht fehl, gibt es kein halbes ZIP — die Fehlermeldung benennt den betroffenen Bericht.

Changed

MQTT-Auto-Publish läuft automatisch mit, sobald der MQTT-Export aktiviert ist. Bisher brauchte es neben mqtt.enabled: true zusätzlich die separate Add-on-Option mqtt.auto_publish (Standard: aus) — wer sie nicht kannte, bekam Sensor-Updates in HA nur beim manuellen Klick „Sensoren publizieren”. Jetzt registriert mqtt.enabled: true den Auto-Publish-Job direkt; mqtt.auto_publish bleibt als Schalter für Umgebungen ohne MQTT_ENABLED gültig. Verhaltensänderung: Installationen mit aktiviertem Export und bewusst deaktiviertem Auto-Publish publizieren künftig stündlich.
Aussichten rechnen die historischen Erträge über das gemeinsame Finanz-Aggregat (#326-Folge). get_finanz_prognose baut Einspeise-Erlös, EV-/BKW-Ersparnis und Sonstige jetzt über den SoT-Helper berechne_finanz_aggregat auf — inklusive per-Monat-Flexpreis und per-Monat-Tarif über den gueltig_ab-Stichtag, exakt wie das Cockpit; WP-/E-Auto-Alternativkosten und der Prognose-Teil bleiben lokal. Der Dienstwagen-Ladekosten-Abzug rechnet jetzt per-Monat-Flexpreis — gleichzeitig in Aussichten und Cockpit (Einspeisevergütung bleibt Vertragswert). Neuer Symmetrie-Test: Cockpit-Netto == Aussichten-bisherige-Erträge auf gemeinsamem Fixture (Flex + Speicher + Sonstige + Dienstwagen). Verhaltensänderung: BKW-Monate ohne Monatsdaten-Zeile zählen nicht mehr ins Aggregat (entspricht dem Cockpit).

Fixed

Anker SOLIX Cloud-Import: Login auf das aktuelle Anker-Schema portiert (#328). Der Login schlug mit dem veralteten Schema (MD5-Doppelhash, leerer Public-Key) fehl — die aktuelle Anker-API verlangt einen ECDH-Schlüsselaustausch (P-256) mit AES-256-CBC-verschlüsseltem Passwort sowie die Header x-auth-token und gtoken = MD5(user_id). Zusätzlich war der Daten-Endpunkt energy_daily tot — die Tageswerte kommen jetzt über energy_analysis (Abfrage-Fenster beidseitig tag-inklusiv, EcoFlow-Lehre). E-Mail/Passwort werden vor dem API-Call getrimmt, Anker-Fehlercodes (falsches Passwort, Verifizierungs-Pflicht, Rate-Limit) erscheinen als verständliche Meldung in der UI. Neue explizite Dependency cryptography. Der Provider bleibt als „ungetestet” markiert, bis der Gegentest mit echtem Gerät grün ist (Johnny_1993, simon42 #652).
HA-REST-Export: generiertes YAML-Snippet war nicht direkt nutzbar (rapahl). Die resource-Zeile enthielt wörtlich den Platzhalter {{ eedc_addon_host }} — Home Assistant wertet in rest: resource: keine Templates aus, 1:1 eingefügt entstand eine ungültige URL und damit gar keine Entitäten (Fehler nur im HA-Core-Log). Jetzt setzt eedc automatisch die Adresse ein, unter der die Export-Seite aufgerufen wurde (Override per ?host= möglich); nur hinter Ingress bleibt ein klar markierter <EEDC-IP>-Platzhalter mit Anleitung. Der Hinweis, dass im Add-on Port 8099 in den Netzwerk-Einstellungen freigegeben sein muss, steht jetzt im Snippet selbst; leere unit_of_measurement-Zeilen entfallen.
MQTT-Export: Start-Publish nach dem Boot. Der Auto-Publish-Job feuerte erstmals nach einem vollen Intervall (Standard 60 min) — nach einem Add-on-Update waren neue Sensoren (z. B. die v3.40.0-Prognose-Sensoren) bis zu eine Stunde unsichtbar, sofern man nicht manuell „Sensoren publizieren” klickte. Jetzt publiziert eedc ~2 Minuten nach dem Start einmal automatisch (sofern die Add-on-Option mqtt.auto_publish aktiv ist).
Aussichten-Dienstwagen-Abzug: evcc-Importe ohne expliziten Netz-Key wurden als Netz=0 gewertet. Die Aussichten lasen ladung_netz_kwh roh, während das Cockpit seit #262 den SoT-Helper get_emob_pv_netz_kwh (mit evcc-Fallback) nutzt — jetzt beidseitig derselbe Helper.

[3.41.0] - 2026-06-10 — Konsistente Finanzwerte, täglicher Connector-Abruf & Jahresbericht-Abschluss

✨ Minor / Feature + Fixes. Drei Tester-Anliegen in einem Release: durchgängig identische Finanzwerte über Cockpit/PDF/HA-Export bei dynamischen Stromtarifen (#326, rilmor-mhrs), täglicher automatischer Connector-Abruf ohne MQTT-Inbound (#300, Safi105) und der abgeschlossene Jahresbericht mit Speicher-Sektion auf einer einzigen PDF-Engine (#303, kingcap1). 939 Backend-Tests grün.

Added

Geräte-Connector: täglicher automatischer Zählerstand-Abruf (#300). Neuer Scheduler-Job connector_daily_poll (täglich 03:30) liest die kWh-Zählerstände aller Anlagen mit konfiguriertem Connector und speichert sie als Snapshot — unabhängig vom MQTT-Inbound. Bisher pollte nur die Connector-MQTT-Bridge automatisch, und die startet nur mit aktivem MQTT-Inbound; ohne MQTT füllte sich der Monatsabschluss-Vorschlag nur über manuelles „Aktuelle Daten anfordern” (Safi105, Fronius Gen24). Ein Snapshot pro Tag genügt, weil Monatsabschluss und /connectors/monatswerte die Monats-Differenz read-seitig aus den Snapshot-Randwerten berechnen.
Jahresbericht: eigene Batteriespeicher-Sektion (#303). Der Jahres-/Anlagenbericht weist den Speicher jetzt vollständig aus — Kapazität, Ladung/Entladung, Vollzyklen und Wirkungsgrad. Bisher fehlte der Speicher im WeasyPrint-Bericht (kingcap1).

Changed

PDF-Erzeugung: reportlab vollständig entfernt (Phase 5, #303). WeasyPrint ist die einzige PDF-Engine. Der seit v3.37.0 standardmäßig nie mehr erreichte reportlab-Notausgang (Jahresbericht + Infothek-Dossier) ist abgebaut, ebenso die Add-on-Option pdf_engine (bestehende Konfigurationen mit gesetzter Option bleiben gültig, der Wert wird ignoriert). Der alte Notausgang trug noch die #326-Altlast (EV-Ersparnis × statischer Tarifpreis, Eigenverbrauch ohne Speicher/V2H) — die WeasyPrint-Berichte rechnen durchgängig über die SoT-Helper.

Fixed

Durchgängig konsistente Finanzwerte bei dynamischen Stromtarifen (#326). Cockpit, Jahresbericht-PDF und HA-Export rechneten Eigenverbrauchs-Ersparnis, Netto-Ertrag und ROI jeweils selbst — teils Gesamt-Eigenverbrauch × Durchschnittspreis statt Monat für Monat × Monatspreis, teils ohne Speicher-/V2H-Anteil oder ohne „Sonstige Erträge & Ausgaben”. Bei Flex-Tarifen (Tibber/aWATTar/EPEX) liefen die Sichten dadurch auseinander (rilmor-mhrs, #326). Jetzt rechnen alle aggregierenden Read-Sites über den gemeinsamen SoT-Helper core/berechnungen/finanz_aggregat.py (per-Monat-Flexpreis, §51-Einspeise-Erlös, Sonstige Positionen) — identische Werte in allen Sichten; ein Symmetrie-Test sichert Cockpit == PDF == HA-Export ab. Letzter Restposten mitbehoben: die BKW-Ersparnis in den Aussichten rechnete noch Σ(EV) × statischer Tarifpreis statt per-Monat — jetzt dasselbe Muster wie die E-Auto-Zeile (resolve_netzbezug_preis_cent).

Intern (nicht anwender-sichtbar)

Die /connectors/fetch-Logik (Zählerstand lesen → Snapshot + last_fetch speichern → Activity-Log) ist in den gemeinsamen Service services/connectors/fetch_service.py extrahiert; manueller Endpoint und Tages-Job nutzen denselben Pfad (kein Drift zwischen manuell und automatisch). Neue Tests test_connector_daily_poll_300.py.
Jahresbericht-Konsistenz-Regressionstest (kingcap1-Gegencheck #303): Summary-KPIs (Einspeise-Erlös, EV-Ersparnis, Netto-Ertrag) sind exakt die Summe der gedruckten Monats-Zeilen — gesichert am Fixture mit Speicher + Flex-Tarif + Sonstigen Positionen. PDF-Fehlermeldungen nennen jetzt durchgängig den echten Fehlertyp (KlassenName: Detail) statt eines generischen Render-Fehlers.
MQTT-Discovery: sw_version zeigt die echte eedc-Version. Das Device-Info-Payload trug eine hartcodierte, gedriftete Versionsnummer („0.9.2”); jetzt APP_VERSION. Toter Helper _build_device_info (zweite Hartcodierung „1.0.0”, nie aufgerufen) entfernt.

[3.40.0] - 2026-06-09 — eedc-Werte nach HA: PV-Prognose & Börsenpreis-Trigger als Sensoren

✨ Minor / Feature. eedc exportiert jetzt seine eigene Rechenleistung nach Home Assistant — PV-Prognose und einen Börsenpreis-Rang-Trigger, je als HA-Sensor und MQTT-Topic. Erster Slice der HA-Export-Architektur (Leitsatz: exportiere, was HA nicht selbst hat). eedc liefert Werte und Trigger — die Lade-/Entlade-Strategie baust du in HA. 926 Backend-Tests grün.

Added

PV-Prognose als HA-Sensoren (#150 A). Neue anlage-weite Sensoren aus der eedc-eigenen Prognose (OpenMeteo × Lernfaktor — nie Solcast/SFML, die liegen via eigene HA-Integration schon vor):
- eedc_prognose_rest_today_kwh (IST bisher + Σ Reststunden, Stundenprofil als Attribut),
- eedc_prognose_day_plus_1/2/3_kwh (heute+1/2/3),
- eedc_speicher_voll_um — SoC-Simulation ab aktuellem Speicherstand (letzter persistierter soc_prozent), damit automatisierungstauglich.
Börsenpreis-Trigger als HA-Sensoren (#150 B). Für dynamische Tarife: eedc_preis_rang (1–5 = fünf günstigste Stunden je Fenster, 99 = Rest; Tag- und Nacht-Fenster solar-basiert getrennt, Rang-Profil als Attribut) und eedc_preis_guenstige_stunden_anzahl. eedc liefert nur den Trigger, keine Strategie.
Beide Sätze laufen durch den einen Chokepoint calculate_anlage_sensors() → automatisch über MQTT-Discovery (gruppiert unter dem Anlage-Device) und REST/YAML.

Fixed

Geräte-Connector: PV/Speicher/Wallbox-kWh auch bei vor-v3.39.0 angelegten Configs (#300). Boot-Migration _migrate_connector_field_inv_map_backfill leitet die fehlende field_inv_map eindeutig aus den aktiven Investitionen ab, sodass der automatische Energy-Poll auch ältere Connectoren per-Investition publisht (Fall B aus #300).

Intern (nicht anwender-sichtbar)

Neue reine Helper im Berechnungs-Layer (ADR-001): core/berechnungen/speicher_simulation.py (SoC-Tagessimulation) und core/berechnungen/preis_rang.py (Rang je Fenster). Solar-Helfer sonnenauf_unter_stunde() in solar_forecast_service.py (Stundenwinkel, kein externer Abruf). Export koordinaten-/PV-/netzwerk-tolerant: bei fehlenden Daten entfallen einzelne Sensoren lautlos, der übrige Export bleibt grün. Neue Tests test_ha_export_prognose_150.py + test_ha_export_preis_150.py.

[3.39.2] - 2026-06-08 — Interne Aufräum-Runde: Exception-Factory, Provenance-Fix & CI

🔧 Patch / Aufräumen. Überwiegend interne Hygiene vor dem nächsten größeren Umbau: einheitliche Fehler-Antworten (Exception-Factory), eine korrigierte Daten-Herkunfts-Spur (#299) und aktualisierte CI-Actions. Einzige anwender-sichtbare Änderung: leicht vereinheitlichte Wortlaute einiger Fehlermeldungen. 906 Backend-Tests grün.

Changed

Vereinheitlichte Wortlaute einiger 404-/503-Fehlermeldungen. „… mit ID {id} nicht gefunden” → „… {id} nicht gefunden” (Anlage, Investition, Prognose u. a.) sowie eine kürzere, kanonische Meldung bei nicht verfügbarer HA-Statistik. Rein kosmetisch, keine Verhaltensänderung.

Fixed

Daten-Herkunft (Provenance) bei Aggregator-Wiederherstellung korrekt (#299). Beim Neu-Aggregieren eines Tages wurden gerettete extern-befüllte Werte (PV-Prognose, Kraftstoffpreis) zuvor (a) nicht ins Audit-Log geschrieben und (b) fälschlich mit auto:monatsabschluss statt ihrer echten Quelle gestempelt. Jetzt laufen diese Wiederherstellungen über den zentralen Provenance-Pfad — gleiche Werte, korrekte Herkunfts-Spur. Reine Diagnose-Hygiene, kein Wert ändert sich.

Intern (nicht anwender-sichtbar)

Zentrale Exception-Factory core/exceptions.py (4 Return-Pattern-Helfer): 117 byte-identische raise HTTPException-Stellen über 33 Dateien auf die Helfer umgestellt (netto −24 Zeilen); dynamische/Security-Wortlaute bewusst unverändert gelassen. Keine Verhaltensänderung außer der oben genannten Wortlaut-Normalisierung. 12 neue Helper-Tests.
GitHub-Actions auf Node-24-Runtime gebumpt (eedc-homeassistant, eedc-Standalone, eedc-community) — Deprecation-Warnung in den CI-Läufen weg. Neues Provenance-Label auto:preserve_restore (Fallback für Legacy-Rows ohne Herkunfts-Eintrag).

[3.39.1] - 2026-06-07 — §51-Schalter pro Anlage & MQTT-Outbound-Konsolidierung

🔧 Patch. Zwei Korrekturen: Der §51-Negativpreis-Abzug galt bisher automatisch für jede Anlage mit Börsenpreis-Daten — auch für Bestandsanlagen, die §51 EEG gar nicht unterliegen; jetzt ein manueller Schalter pro Anlage, Default aus. Zudem werden MQTT-Sensoren wieder zuverlässig nach Home Assistant geschrieben (ein konsolidierter Outbound-Pfad statt zwei, echte Fehlermeldungen im Log). 893 Backend-Tests grün.

Fixed

§51 EEG wird nicht mehr pauschal auf alle Anlagen angewandt. Der Wegfall der Einspeisevergütung in Stunden mit negativem Börsenpreis (§51 EEG) gilt rechtlich nur für Neuanlagen (Solarpaket I, Inbetriebnahme i. d. R. ab 25.02.2025), gestaffelt nach Datum und Größe. Bisher zog eedc den §51-Verlust aber immer ab, sobald Negativpreis-Einspeisung in den Tagesaggregaten stand — und weil der integrierte aWATTar-Börsenpreis-Fallback (ohne eigenen Tibber-/aWATTar-Sensor) diese Daten für nahezu jede Anlage liefert, traf der Abzug faktisch auch Alt-Anlagen, die volle Vergütung erhalten. Anlass: rapahl + Gernot.
MQTT-Sensoren werden wieder zuverlässig nach Home Assistant geschrieben (#655). Bei JayJayX wurden die MQTT-Sensoren in HA nicht aktualisiert, das Log meldete trotzdem „erfolgreich, keine Fehler”. Ursache waren zwei Bugs: (1) ein Broker-Mismatch — ein leeres Frontend-Config-Objekt zog den Default core-mosquitto statt des MQTT_HOST aus der Umgebung, sodass automatischer und manueller Publish auf verschiedene Broker zielen konnten; (2) Scheduler und Route lasen einen nie existierenden Ergebnis-Schlüssel und meldeten deshalb immer „0 Sensoren, erfolg=True”. Beide behoben: ein konsolidierter Outbound-Pfad (Auto-Publish, manuelle Route und Test nutzen dieselbe Broker-Auflösung Override → ENV → Default), echte success/failed-Zahlen und konkrete Fehlergründe im Activity-Log. Live am Broker verifiziert (Fehlergrund wie „Connection refused” erscheint jetzt sichtbar). Separat noch offen (#329): einzelne mwd_*-Sensoren bleiben „unknown”.

Changed

Neuer Schalter „Anlage unterliegt §51 EEG” in den Anlagen-Stammdaten (unter Steuerliche Behandlung), Default aus. Nur wenn aktiviert, weist eedc den „§51-Verlust” im Cockpit aus und kürzt den Einspeise-Erlös in allen Auswertungen (Cockpit, Aussichten, ROI, PDF, HA-Export). Bestandsanlagen bleiben damit nach dem Update unverändert, bis der Schalter bewusst gesetzt wird. Bewusst manuell statt automatisch aus dem Inbetriebnahmedatum hergeleitet — der gesetzliche Stichtag samt Staffelung ist zu komplex für eine robuste Automatik.

Intern (nicht anwender-sichtbar)

Neues Feld Anlage.unterliegt_eeg_51 (Bool, Default False, Startup-Migration). Der §51-Gate sitzt an genau einer Stelle — dem zentralen Aggregat-Service services/einspeise_erloes_service (get_neg_preis_einspeisung_monat/_jahr liefern bei nicht gesetztem Flag None); alle Read-Sites gehen über diesen Service, daher kein Per-Site-Patch. Regressionstest „Flag aus + Börsenpreis-Daten → kein Abzug” in beiden §51-Testdateien.

[3.39.0] - 2026-06-07 — Connector-kWh-Bridge, Amortisations-Grenze & Daten-Checker-Aufräumung

✨ Minor-Sammelrelease. Der Geräte-Connector liefert jetzt auch die Energiewerte (kWh) automatisch — nicht mehr nur Live-Leistung. Amortisation und ROI rechnen jetzt erst ab dem Anschaffungsdatum (vorher leicht zu günstig). Dazu die Daten-Checker-Aufräumung abgeschlossen (Wizard auf zwei klare Optionen, internes Modul-Refactor). 886 Backend-Tests grün.

Added

Geräte-Connector erfasst Zählerstände (kWh) automatisch über MQTT. Bisher lieferte der Connector nur Live-Leistung (Watt) — „Heute” und Monatswerte blieben leer, obwohl die Kachel „Automatische Zählerstandserfassung” versprach. Jetzt pollt eine zweite Schleife (5 min) die kumulativen Zählerstände und speist sie pro zugeordneter Komponente in dieselbe Pipeline wie Node-RED/ioBroker. Neue Wizard-Karte „Zuordnung zu Investitionen”: pro gemessener Kategorie (PV, Speicher, Wallbox …) die passende Investition wählen — dann landen die Werte im richtigen Komponenten-Slot statt pauschal auf Anlagenebene. Anlass: EcoFlow-+-Node-RED-Setup (Dirk).

Changed

Setup-Wizard: Sensor-Zuordnung auf zwei klare Optionen reduziert (Daten-Checker-Achse A1). Jedes Feld bietet jetzt nur noch „HA-Sensor” oder „Kein Sensor” (manuell im Monatsabschluss erfassen / bewusst leer). Die früheren Auswahlen „kWp-Verteilung”, „EV-Quote berechnen”, „JAZ-/COP-Berechnung” und „Manuell eingeben” waren eine Falle: der Wizard bot sie an, aber nur ein echter HA-Sensor lieferte je Daten — der Rest blieb wirkungslos. Die jeweilige Logik passiert weiterhin automatisch zur Auswertung (z. B. PV-Gesamterzeugung wird anteilig nach kWp auf die Strings verteilt, Heizwärme aus Stromverbrauch × JAZ geschätzt), ohne dass im Wizard eine Strategie gewählt werden muss. Bestehende Zuordnungen mit einer der alten Optionen werden beim Update automatisch auf „Kein Sensor” umgestellt.

Fixed

Amortisation/ROI respektieren das Anschaffungsdatum (#651/#561). Die kumulierte Amortisation (Aussichten) sowie Energiebilanz + ROI (Cockpit) summierten den PV-Ertrag bisher ungefiltert über alle Monate — auch über Zeiträume vor dem Anschaffungsdatum der Anlage, wodurch die Amortisation zu günstig ausfiel. Jetzt zählen Ertrag und Ersparnis nur über Monate, in denen eine PV-Quelle (PV-Module/Balkonkraftwerk) tatsächlich aktiv war (respektiert Anschaffungs- und Stilllegungsdatum). Ohne gesetztes Anschaffungsdatum oder ohne registrierte PV-Quelle bleibt alles unverändert.
Daten-Checker: maskierter Fehler im Datenquelle-Drift-Check. Im except-Zweig von _check_datenquelle_drift zeigte ein fehlgeschlagener HA-LTS-Read auf ein undefiniertes logger → der eigentliche Fehler wurde durch einen NameError verdeckt. Jetzt wird der HA-LTS-Read-Fehler korrekt geloggt (DEBUG) und der Tag übersprungen, statt den echten Fehler zu maskieren. [[feedback_silent_except_logs]]

Intern (nicht anwender-sichtbar)

StrategieTyp-Enum (Backend + Frontend) auf sensor/keine reduziert; idempotente Startup-Migration _migrate_sensor_mapping_strategien_clear schreibt Dead-Strategie-Werte im sensor_mapping-JSON auf keine um (Hard-Precondition vor der Enum-Reduktion, da FeldMapping.strategie Pydantic-validiert ist). 7 Migrations-Tests. [[project_datenchecker_konsistenz]] Achse A.
Daten-Checker in ein Package aufgeteilt (Achse C). Das 2729-Zeilen-Einzelmodul services/daten_checker.py ist jetzt das Package services/daten_checker/ mit thematischen Mixin-Klassen (kategorien, _helpers, stammdaten, monatsdaten, energieprofil, sensoren, emob, datenquelle); DatenChecker komponiert die Mixins, Orchestrator check_anlage + __init__ bleiben in __init__.py. Reiner Move, keine Funktionsänderung — die Checks bleiben self-Methoden mit geteiltem Instanz-State, die Public API (from backend.services.daten_checker import DatenChecker) ist unverändert. Bestehende Tests laufen unverändert grün. [[project_datenchecker_konsistenz]] Achse C.

[3.38.0] - 2026-06-06 — CO₂-Amortisation, kWp-String-Verteilung & §51-Negativpreise

✨ Minor mit drei Features + Daten-Checker-Schliff. Sammelrelease: die CO₂-Amortisation zeigt, ab wann eine Anlage klimapositiv ist; Multi-String-PV-Anlagen mit nur einem Gesamt-Sensor bekommen ihre Erzeugung anteilig nach kWp auf die Strings verteilt; bei negativen Börsenpreisen wird die nicht vergütete Einspeisung korrekt vom Erlös abgezogen. Dazu mehrere Korrekturen am Daten-Checker und an der Finanz-Auswertung bei Flex-Tarifen. 868 Backend-Tests grün.

Added

CO₂-Amortisation: „ab wann klimapositiv” (#284). Der CO2-Tab der Auswertung stellt der kumulierten CO2-Betriebs-Einsparung jetzt die graue Herstellungs-Last der Investitionen gegenüber und zeigt den Schnittpunkt, ab dem die Anlage klimapositiv ist (erreicht oder hochgerechnet). Richtwerte: PV 1000 kg CO₂/kWp, Speicher 85 kg/kWh, Wärmepumpe 1100 kg (Differenz zu Gas/Öl), E-Auto 5000 kg (Differenz zum Verbrenner) — Dienstwagen ausgenommen. Pro Investition über das neue Feld „Graue CO2-Last (kg)” (Herstellerdatenblatt) übersteuerbar; leer = Richtwert nach Typ/Größe. Die Σ wird über den SoT-Helper core/berechnungen/co2_amortisation.py (ADR-001) gerechnet.
PV-Erzeugung anteilig nach kWp auf mehrere Strings verteilt (#289/#651). Multi-String-Anlagen mit nur einem Gesamt-PV-Sensor (kein Sensor je Dachseite) bekommen die Erzeugung jetzt anteilig nach kWp auf die einzelnen Strings/Investitionen aufgeschlüsselt — Voraussetzung dafür, dass Per-String-Auswertungen für diese verbreitete Hardware (Fronius Symo/Primo, SMA Tripower, Kostal, Sungrow/GoodWe/Huawei) überhaupt greifen. Die Verteilung passiert read-time (das Feld wird nur gelesen, nie programmatisch gefüllt) über den SoT-Helper core/berechnungen/pv_verteilung.py (ADR-001, Σ über Strings == Gesamt exakt). Der Daten-Checker meldet jetzt anlagenweit: gemessen = OK · verteilt = Hinweis · Teil-Lücke = Warnung · keine Quelle = Fehler.
§51 EEG: Abzug bei negativen Börsenpreisen. Stunden mit negativem Börsenpreis werden im Einspeise-Erlös nicht mehr vergütet — die nicht vergütete Einspeisung (einspeisung_neg_preis_kwh) wird über alle Auswertungen hinweg (Cockpit, Aussichten, ROI-Dashboard, HA-Export, PDF) zentral abgezogen. Datenbasis war bereits vorhanden, jetzt in der Erlös-Berechnung verwertet.

Fixed

Flex-Tarif: Eigenverbrauchs-Ersparnis in der Auswertung stimmt jetzt mit dem Cockpit überein (#326). Die Finanz-Auswertung nutzt bei dynamischem Stromtarif jetzt denselben aufgezeichneten Monats-Durchschnittspreis (netzbezug_durchschnittspreis_cent) wie das Cockpit, statt nur des statischen Tarifs — vorher klafften bei Flex-Tarif-Anlagen die €-Werte auseinander.
Daten-Checker: Custom-Import/CSV/manuell befüllte Komponenten gelten als gültige Quelle. Eine Komponente ohne Sensor-Mapping, aber mit manuell/per Import gepflegten Daten, wird jetzt als OK mit Quellen-Hinweis gewertet statt fälschlich als „kein Mapping”-Warnung.
Daten-Checker: zwei Wallbox/E-Auto-Fehlalarme beseitigt. (A) Der Pflege-Konflikt feuert nicht mehr fälschlich, wenn ein E-Auto seinen Fahrverbrauch pflegt und eine Wallbox die Heimladung deckt; (B) ein E-Auto-kWh-Zähler wird nicht mehr eingefordert, wenn eine aktive Wallbox die Ladeenergie bereits misst.

Intern (nicht anwender-sichtbar)

Counter-Drift WP-Starts/Betriebsstunden geschlossen (Variante 2-light, ADR-001). Neuer Layer-Helper core/berechnungen/counter.py leitet die Stundenwerte aus dem Tages-Boundary-Diff ab (eine Quelle pro Tag) + Pflicht-Invariante pruefe_counter_konsistent — keine zwei abweichenden „Tages-Starts”-Werte mehr bei Snapshot-Lücken. Verhaltensneutral bei sauberen Daten.
868 Backend-Tests grün; Konformitäts-Test (ADR-001) grün.

[3.37.1] - 2026-06-06 — Prognosen-Seite rundum + WP-Betriebsstunden überall + SFML-Stundenprofil

🩹 Patch mit Funktions-Nachzügen. Sammelrelease über mehrere Bausteine: die Prognosen-Seite (#296) ist komplett überarbeitet, die Wärmepumpen-Betriebsstunden (#238) sind an allen Auswertungs-Oberflächen sichtbar, und wer SFML als Prognosequelle wählt, bekommt jetzt dessen echtes Stundenprofil statt einer angenäherten Kurve. Dazu mehrere Korrekturen (Cockpit „Sonstige”, PDF-Komponentenliste, Eigenverbrauch über alle Sichten). 813 Backend-Tests grün.

Added

SFML-Stundenprofil als gewählte Quelle (#110). Wer „Solar Forecast ML” als Prognosequelle wählt, sieht jetzt dessen eigenes, anlagengelerntes Stundenprofil über drei Tage — statt wie bisher die SFML-Tagessumme über die OpenMeteo-Kurvenform verteilt zu bekommen. Treue Anzeige der gewählten Quelle, inkl. „Speicher voll um”-Vorhersage und Verbleibend-Wert.
WP-Betriebsstunden an allen Sicht-Oberflächen (#238). Die Betriebsstunden (analog zu den Kompressor-Starts) erscheinen jetzt im Monatsbericht (KPI-Kachel), im Energieprofil (Tages- und Stunden-Tabelle als zuschaltbare Spalte), im PDF-Jahresbericht und im HA-Sensor-Export. Glossar um „Kompressor-Starts” (Verschleiß) und „Betriebsstunden” (Auslegung) ergänzt.
Jahresauswahl-Dropdown für den Jahresbericht (#302) im Dokumente-Dialog: ein einzelnes Jahr oder den Gesamtzeitraum wählen.
Prognosen-Tabelle: Heute-Zeile + Wettersymbole für Vergangenheitstage (#296). Der laufende Tag steht jetzt mit in der 7-Tage-Tabelle; vergangene Tage zeigen ihr Wettersymbol.
Genauigkeits-Tracking: Zeitraum-Selektor 7 / 10 / 30 Tage (#296).
Ausreißer-Tage werden markiert statt still weggerechnet (#296) — optional ausblendbar (Standard: sichtbar), damit Schlechtprognose-Tage als Erkenntnis sichtbar bleiben.

Changed

WeasyPrint ist jetzt auch im HA-Add-on die Standard-PDF-Engine (#121/#303); reportlab bleibt nur noch als Notausgang über PDF_ENGINE=reportlab. (Bei Neuinstallationen; bestehende Installationen behalten ihre eingestellte Engine.)
„Verbleibend”-Anzeige einheitlich als IST-bisher + Restprognose und respektiert die gewählte Prognosequelle (#296); Tooltip entsprechend angepasst.
Genauigkeits-Tracking-Überschrift trennt Statistik-Zeitraum von der 7-Tage-Tabelle (#296).

Fixed

Cockpit/Übersicht: „Sonstige Erträge & Ausgaben” fließen in die Netto-Ertrag-Kachel ein (#326).
Finanz-/Statistik-Auswertung /aggregiert: Eigenverbrauch über den zentralen Helper inkl. V2H (Schwester-Fix zu #304).
PDF-Jahresbericht: Komponenten-Auflistung im WeasyPrint-Bericht korrigiert (#303).

Intern (nicht anwender-sichtbar)

SFML-Ingestion: Discovery liest jetzt das Stundenprofil-Attribut (evcc_solar_prognose), neuer Parser (Wh→kWh, Backward-Slot-Konvention #144, mehrtägig), neue Spalte TagesZusammenfassung.sfml_prognose_stundenprofil. WP-Betriebsstunden als Float-Counter (FLOAT_COUNTER_FELDER) konsistent in Tages- und Stunden-Aggregation. 813 Backend-Tests grün.

[3.37.0] - 2026-06-06 — Jahresbericht-PDF neu (WeasyPrint, ohne matplotlib) + einheitlicher Eigenverbrauch

✨ Minor-Release. Der PDF-Jahresbericht ist auf das WeasyPrint-Design der übrigen Berichte umgestellt und kommt komplett ohne matplotlib/numpy aus — damit läuft er auch auf Proxmox-VMs mit CPU-Typ kvm64, auf denen die alte Diagramm-Bibliothek abstürzte. WeasyPrint ist jetzt die Standard-PDF-Engine. Dazu rechnen Eigenverbrauch und Autarkie über alle Auswertungen hinweg einheitlich (inkl. Speicher und V2H) — das behebt mehrere Ungenauigkeiten in Community-Vergleich, Finanz-Prognose und Jahresbericht. 776 Backend-Tests grün.

Added

PV-Jahresbericht im neuen WeasyPrint-Design, einheitlich mit Anlagendokumentation, Finanz- und Infothek-Bericht. Die Diagramme (PV-Erzeugung, Energiefluss, Autarkie) werden jetzt vektorbasiert als SVG gerendert.

Changed

WeasyPrint ist die Standard-PDF-Engine (vorher reportlab). Die bisherige Engine bleibt über PDF_ENGINE=reportlab als Fallback erhalten.
matplotlib/numpy aus dem PDF-Pflichtpfad entfernt (#303). Behebt den Absturz des Jahresberichts auf Proxmox-VMs mit kvm64-CPU (NumPy was built with baseline optimizations (X86_V2)). Der Jahresbericht war der letzte Bericht, der noch matplotlib nutzte — damit ist die PDF-Migration (#121-Folge) abgeschlossen.
Eigenverbrauch/Autarkie einheitlich inkl. V2H über Cockpit, HA-Sensor-Export, Finanz-Prognose und Jahresbericht: Vehicle-to-Home (E-Auto entlädt ins Haus) zählt jetzt überall als Eigenverbrauch — wie die stationäre Speicher-Entladung. Zentrale Berechnung über einen Helper, keine Drift mehr zwischen den Sichten (die zuvor in cockpit/uebersicht.py duplizierte Formel nutzt jetzt denselben Helper, ADR-001).
Jahresbericht-Überschrift zeigt im Gesamtzeitraum „Gesamt-Kennzahlen” statt „Jahres-Kennzahlen” (#302).

Fixed

Community-Vergleich: Autarkie bei Speicher-Anlagen korrekt (#294). Die beim Hochladen berechnete Autarkie ignorierte den Speicher (Eigenverbrauch = PV − Einspeisung) und lag dadurch für Anlagen mit Batterie — besonders mit Netzladung (Arbitrage/Backup) — systematisch zu niedrig. Jetzt deckungsgleich mit der Cockpit-Berechnung (Symmetrie-Test). Historische Übertragungen korrigieren sich mit dem nächsten Monats-Upload; eine separate Server-Korrektur ist nicht möglich (Rohdaten liegen dort nicht). Anlass: kingcap1.
Finanz-Prognose („Aussichten”): Eigenverbrauchsquote bei IMD-basierten Setups korrekt (#304 Teil 2). Bei Anlagen, deren Daten aus den Investitions-Monatsdaten stammen (statt aus dem Alt-Gesamtfeld Monatsdaten.eigenverbrauch_kwh), brach die historische Eigenverbrauchsquote zusammen und die Prognose fiel auf einen 30-%-Standardwert zurück. Jetzt über dieselbe zentrale Verbrauchsformel wie Cockpit/HA-Export (inkl. Speicher + V2H). Damit ist #304 vollständig (Teil 1 HA-Export v3.34.3, Teil 2 Aussichten + PDF jetzt).
PDF-Jahresbericht: Eigenverbrauch rechnet den Speicher mit ein (vorher vereinfachte Formel ohne Batterie-Anteil).

Intern (nicht anwender-sichtbar)

services/pdf/charts.py von matplotlib auf handgefertigtes inline-SVG umgebaut (gleiche Signaturen, Rückgabe weiter als data-URI). Zentraler Verbrauchs-Helper core/berechnungen/verbrauch.py um Parameter v2h_entladung_kwh erweitert (addiert wie Speicher-Entladung in Zähler + Nenner) und in allen vier Read-Sites genutzt. matplotlib aus requirements.txt entfernt. Neue Tests: PDF-Rendering durch WeasyPrint + SVG-Charts, Aussichten-EV-aus-IMD, Community-Autarkie-Speicher-Symmetrie, V2H-Uniform (Helper + Cockpit). 776 Backend-Tests grün.

[3.36.2] - 2026-06-05 — Live-Wetter: vergifteter Zwischenspeicher nach Upgrade

🩹 Patch. Nachzug zu v3.36.1: Der dortige Live-Wetter-Fix korrigierte nur den Schreiber des Wetter-Zwischenspeichers. Ein bereits aus der Vorversion im persistenten Cache (überlebt Neustarts) liegender Eintrag im alten Format wurde dadurch nicht geheilt — und vom Prefetch-Skip-Guard nie überschrieben. Die Live-Wetteransicht blieb deshalb bei betroffenen Anlagen weiter auf „Keine Wetterdaten verfügbar”. Jetzt verwirft der Leser jeden Cache-Eintrag falscher Struktur wie einen Cache-Miss und ruft frisch ab (selbstheilend, robust gegen künftige Format-Wechsel über Updates).

Fixed

Live-Wetter blieb auch nach v3.36.1 auf „Keine Wetterdaten verfügbar” (Anlass: rapahl). Der v3.36.1-Fix setzte nur am Schreib-Pfad des Wetter-Caches an; ein aus der Vorversion bereits persistierter Eintrag im falschen Format überlebte den Neustart (L2-Cache, api_cache), wurde nach dem Warmup wieder in den RAM-Cache geladen und vom stündlichen Prefetch nicht ersetzt (Skip-Guard „nicht überschreiben wenn vorhanden”). Der Live-Abruf entpackte ihn weiter stur und scheiterte → Negativ-Cache. Der Endpoint behandelt einen Cache-Eintrag falscher Arität jetzt wie einen Cache-Miss (verwerfen + Neu-Abruf); der frische Abruf überschreibt den Alt-Eintrag. Regressionstest ergänzt.

[3.36.1] - 2026-06-05 — QS-Nachzug: Finanzen-Sonstige, aktiv-Sichtbarkeit, Live-Wetter, Wizard-Hilfen

🩹 Patch-Sammelrelease nach v3.36.0. Schwerpunkt: Aggregations- und Sichtbarkeits-Korrekturen aus der Tester-Runde (rilmor #310, rapahl Live-Wetter, Sabrina Prognose) plus zwei UX-Verbesserungen (Feld-Hinweise im Wizard, einheitlicher E-Auto-Ø-Verbrauch). 761 Backend-Tests grün.

Fixed

Finanzen-Auswertung: Sonstige Erträge an PV-/Wechselrichter-Komponenten zählen jetzt mit (#310). Der v3.36.0-Fix saß in der KPI-Formel, aber die Datenquelle dahinter (Komponenten-Zeitreihe) ließ Sonstige-Positionen weg, die an einer PV-Modul-/Wechselrichter-Investition gepflegt sind — also genau dort, wo Anwender Einspeise-Erträge eines zweiten Zählers eintragen. Ursache war eine Aggregator-Drift: Sonstige wurden im typ-gefilterten Energie-Loop summiert (ohne PV/WR). Jetzt zentral über einen SoT-Helper, symmetrisch zum Monatsbericht (Pflicht-Symmetrie-Test). Anlass: rilmor.
Live-Wetter blieb bis zu 60 Minuten auf „Keine Wetterdaten verfügbar”. Der stündliche Wetter-Prefetch legte den Cache in einem Format ab, das die Live-Seite nicht lesen konnte → Folgeaufruf scheiterte und „vergiftete” den Cache bis zum Ablauf. Behoben (3er-Tupel-Vertrag, Regressionstest). Anlass: rapahl.
Live-Wetter: ehrliche Meldung bei Abruf-Störung. Bei einem fehlgeschlagenen OpenMeteo-Abruf zeigte die Live-Ansicht fälschlich „Standort-Koordinaten in den Stammdaten hinterlegen” — auch wenn die Koordinaten gesetzt waren. Jetzt unterscheidet eedc: echte Koordinaten-Lücke vs. „Wetterdaten momentan nicht verfügbar — wird automatisch erneut versucht”.
PVGIS-Prognose: Stale-Wächter + Schutz gegen stille 0-Werte in der Hochrechnung (vermeidet driftende SOLL-Werte bei kWp-Änderung). Anlass: Sabrina.
Monatsdaten: freier „Monat einfügen”-Pfad (nicht mehr auf vorhandene Dropdown-Einträge beschränkt) + Dropdown-Bug behoben.

Changed

Auf „inaktiv” gesetzte Komponenten (aktiv=False) werden konsequent in keiner Auswertung mehr angezeigt — auch nicht rückwirkend/historisch —, bis sie wieder aktiviert werden. Bisher blieben sie in historischen Aggregaten sichtbar. Die Daten bleiben erhalten (reversibel); endgültiges Entfernen weiterhin per Löschen. Drei getrennte Begriffe: inaktiv (ausgeblendet, reversibel) ≠ Stilllegungsdatum (Lebensende) ≠ Löschen (endgültig).

Added

Feld-Hinweise im Sensor-Zuordnungs-Wizard. Jedes Feld erklärt jetzt kurz, welcher Wert/Sensortyp erwartet wird — zentral aus dem Backend gepflegt (eine Quelle für Wizard, künftigen MQTT-Inbound-Wizard und Doku).
E-Auto Ø Verbrauch (kWh/100 km) einheitlich über alle Sichten. E-Auto-Dashboard, Monatsbericht und Komponenten-Auswertung zeigen jetzt denselben Wert (gemessener Verbrauch vor Ladungs-Näherung; ehrlich gelabelt; kein irreführendes „0,0” mehr, wenn kein Verbrauchssensor gemappt ist).

Intern (nicht anwender-sichtbar)

Zentraler Sichtbarkeits-Filter (aktiv + Laufzeit-Fenster) in den Investitions-Helfern vereinheitlicht; Sonstige-Read-Site-Aggregation auf einen SoT-Helper konsolidiert; emob-Schwächen (verbrauch_kwh-Überladung, Zähler-Abdeckung) dokumentiert.

[3.36.0] - 2026-06-04 — Heimladung kanonisch an der Wallbox + Stundenversatz-Fix + UX-Bündel

🧱 Minor-Sammelrelease. Kern ist die Wallbox/E-Auto-Phase 2a: die Heimladung (gesamt / aus PV / aus Netz) lebt jetzt kanonisch an der Wallbox statt konkurrierend an Wallbox und E-Auto — inkl. einmaliger Daten-Migration und Daten-Checker-Hinweis für nicht eindeutig zusammenführbare Fälle. Dazu ein zentraler Prognosequellen-Adapter-Layer (intern) und mehrere anwender-sichtbare Korrekturen: HA-LTS-Stundenversatz im Prognosen-Vergleich, Speicher-Bearbeitung/Setup-Wizard (#636), Finanzen-Netto-Ertrag (#310), Monatsbericht-Einspeisung (#325), Energiefluss-Hervorhebung (#314). Tages-/Monatswerte durchgehend unberührt. 737 Backend-Tests grün.

Added

Wallbox/E-Auto Phase 2a — kanonische Heimladungs-Quelle: Die zu Hause geladene Energie wird jetzt eindeutig an der Wallbox geführt; das E-Auto trägt nur noch Fahrzeug-Eigenes (km, Verbrauch, externe Ladung unterwegs, V2H). Beim Update werden bestehende Heimladungs-Werte einmalig vom E-Auto in den Wallbox-Slot migriert (pro Monat gewinnt der vollständigere Wert); nicht eindeutig zusammenführbare Fälle bleiben unverändert stehen und erscheinen im Daten-Checker als Pflege-Hinweis. Ohne Wallbox bleibt die Erfassung am E-Auto. Das E-Auto-Formular blendet die Heim-Felder aus, sobald eine Wallbox vorhanden ist.

⚠ Nachträglich richtiggestellt (September 2026): „Die Heimladung wird eindeutig an der Wallbox geführt, das E-Auto trägt nur noch Fahrzeug-Eigenes“ gilt nicht mehr. Die Wallbox ist seither die Summe aller Ladungen an ihr; ein Auto mit eigener Messung („Heim: PV“, „Heim: Netz“ oder „Heim: gesamt“) trägt diese auch neben der Wallbox, und der Rest der Wallbox geht an die Autos ohne eigene Messung. Das Formular bietet die Heim-Felder wieder an jedem E-Auto an (nur am Dienstwagen neben einer dienstlichen Wallbox nicht). Doppelt gezählt wird dabei nichts.
PV-Solarleistung im Live-Energiefluss hervorgehoben (#314): Bei mehreren PV-Strings wird die Solarleistung im Energiefluss-Diagramm optisch betont (fett, größer, kräftigere Farbe). Anlass: kingcap1.

Fixed

Prognosen-Vergleich: IST-Stundenwerte lagen bei HA-Add-on-Nutzern eine Stunde zu früh: Der HA-LTS-Stundenpfad (get_hourly_kwh_deltas_for_day) sortierte den gemessenen Ist-Ertrag forward ein (Slot h = [h, h+1)), während Prognosen und Snapshot-Pfad backward sind ([h-1, h)) — im „Stundenvergleich heute” begann der IST-Verlauf dadurch eine Stunde vor den Prognosen. Beide IST-Pfade liefern jetzt dasselbe Backward-Raster (empirisch gegen Live-HA verifiziert: state/sum @ start_ts=H = Zähler am Perioden-Ende H+1). Neuer SoT-Helper lts_boundary_index; der #297-Symmetrie-Test deckt jetzt alle vier Reihen ab (vorher nur den Snapshot-Pfad — Parallelpfad-Loch). Tages-/Monatssummen waren nie betroffen; historische Stunden lassen sich über „Mehrere Tage neu aggregieren” nachziehen. Anlass: rapahl/Gernot.
Komponenten-Bearbeitung: Dezimalwerte ließen sich nicht speichern (#636): Zahlenfelder (z. B. Speicher-Kapazität) akzeptierten nur grobe Schrittweiten — ein Wert wie 5,12 kWh wurde vom Browser still als ungültig abgewiesen und „Speichern” tat nichts. Die betroffenen Felder akzeptieren jetzt beliebige Werte (step="any"). Anlass: Sabrina.
Setup-Wizard: kryptische Fehlermeldung beim Leeren des Bezeichnungs-Felds (#636): Beim Leeren eines Pflicht-Namens erschien ein roher Validierungs-Text (JSON) und der alte Wert sprang zurück. Leere Pflichtfelder lösen jetzt keinen vorzeitigen Speicherversuch mehr aus, und Server-Validierungsfehler werden lesbar angezeigt. Anlass: Sabrina.
Finanzen: „Netto-Ertrag” rechnet Sonstige Erträge mit ein (#310): Die KPI zog nur Sonstige Ausgaben ab, addierte Sonstige Erträge aber nicht. Anlass: rilmor.
Monatsbericht: abgeschlossener Monat zeigte Einspeisung 0 (#325): Ein Connector ohne Einspeise-Messung überschrieb rückwirkend gespeicherte Monatswerte mit 0; gespeicherte Werte werden jetzt nicht mehr vom Connector übersteuert (der #118-Schutz galt bisher nur für die HA-Statistik). Die Daten waren korrekt, nur die Anzeige. Anlass: detlefh68.

Intern (nicht anwender-sichtbar)

Zentraler Prognosequellen-Adapter-Layer (Stufe 2+3): OpenMeteo/Solcast/IST werden über eine gemeinsame Adapter-Schicht aufbereitet (Drift-Vorsorge, gemeinsame Slot-Konvention).
emob Phase 2a Read-/Write-Seite + Migration + Daten-Checker: kanonischer Heimladungs-Helper, Read-Sites + Write-Side umgestellt, Magnitude-Heuristik entfernt, Daten-Migration auf die strukturelle Quelle; Hilfe-Texte angepasst.

[3.35.2] - 2026-06-04 — Live-Energiefluss schärfen + Prognose-Slot-Absicherung + Branding

🧱 Sammelrelease. Bündelt mehrere fertige, voneinander unabhängige Arbeiten: Schärfung des Live-Energiefluss-Diagramms (#314), zwei Tooltip-/Detail-Erweiterungen (#260, #301), die Branding-/Landing-Page-Pflege (#320/#321/#323), einen Scheduler-Fix (#322) und die Absicherung der PV-Prognose-Slot-Konvention (#297). Daily-/Monats-Werte sind durchgehend unberührt. 699 Backend-Tests grün (+7 neu: Slot-Konventions-Symmetrie über alle Quellen).

Added

E-Auto-Ersparnis-Tooltip nennt den verwendeten Benzinpreis (#260): Der Tooltip zur Kraftstoff-Ersparnis zeigt jetzt den konkret zugrunde gelegten Ø-Benzinpreis des Zeitraums, statt die Zahl unkommentiert zu lassen. Anlass: NongJoWo.
Daten-Checker: Quellen-Konflikt nennt Feld, Zeitraum und Quellen (#301): Wenn zwei Datenquellen denselben Wert konkurrierend befüllen, nennt die Warnung jetzt das betroffene Feld, den Zeitraum und die beteiligten Quellen — statt nur „Konflikt erkannt”. Anlass: Safi105.

Fixed

Live-Energiefluss: Mitte zeigt das Residual statt der Verbraucher-Summe (#314): Das Energiefluss-Diagramm im Live-Dashboard stellte in der Mitte fälschlich die Summe aller Verbraucher dar; jetzt erscheint dort das tatsächliche Haus-Residual (Gesamtverbrauch minus separat ausgewiesene Verbraucher). Zugehörig: Der Energiefluss-Tooltip überschreibt nicht mehr den „Gesamtverbrauch”-Eintrag, und die E-Auto-Deduplizierung ist deterministisch + parent-bewusst (summe_verbrauch respektiert die Wallbox-Zuordnung).
Daten-Checker warnt bei gleicher Sensor-Entity an Wallbox und E-Auto (#314-Folge): Wird derselbe HA-Sensor sowohl der Wallbox als auch dem E-Auto zugeordnet, weist der Daten-Checker jetzt aktiv darauf hin (häufige Doppelmapping-Quelle).
MQTT-Snapshot-Jobs laufen nur bei aktivem MQTT-Inbound (#322): Der Scheduler legte die :05/:55-Snapshot-Jobs auch dann an, wenn kein MQTT-Inbound konfiguriert ist — unnötige Leerläufe. Jetzt an den aktiven Inbound gekoppelt.

Intern (QS / Doku, nicht anwender-sichtbar)

PV-Prognose-Slot-Konvention zentral abgesichert (#297): Das Audit zur gemeldeten „Stundenversatz”-Vermutung ergab, dass alle Prognosequellen bereits korrekt der Backward-Konvention folgen (Slot h = [h-1, h)). OpenMeteos Strahlung ist ein preceding-hour-Mittel (Wert@h = [h-1, h)) und damit bereits Backward — ein „+1-Shift” hätte den Versatz erst erzeugt (empirisch verifiziert: OpenMeteo-API, v3.20.0-Changelog, Live-HA-Repro mit Solcast/IST/Realerzeugung; alle Quellen für [05:00,06:00) deckungsgleich in Slot 6). Neuer zentraler Helper core/berechnungen/slot_konvention.py kapselt die Konvention (openmeteo_preceding_hour_slot = Identität mit „kein Shift”-Vertrag; Solcasts period_start/period_end-Marker); Solcast-Service nutzt ihn jetzt an einer Stelle. Neuer Symmetrie-/Tagessummen-Test nagelt fest, dass OpenMeteo, Solcast und IST dasselbe Slot-Raster liefern.
Branding-/Landing-Page-Pflege (#320, #321, #323): eedc-Schreibweise und der Hinweis auf die Home-Assistant-App auf der Landing-Page vereinheitlicht; die HA-App rendert die Root-README statt der Standalone-README (separate README.standalone.md mit LAN-Security-Hinweis für den Mirror).

[3.35.1] - 2026-06-03 — QS-Härtung: Abschluss der v3.34/v3.35-Aggregator-Maßnahme

🧱 QS-Sammelrelease. Schließt die sieben deferred Restarbeiten der v3.34/v3.35-Aggregator-Refactor-Gesamtmaßnahme ab (PLAN §8.1, Issues #315–#319 + zwei interne Befunde) — direkte Audit-Befunde derselben Symmetrie-/Drift-Klasse, bewusst nicht in die Phasen A–C gebündelt. Überwiegend latent oder verhaltensneutral; die anwender-sichtbaren Korrekturen unten betreffen Nischen-Setups. Daily-/Monats-Werte waren durchgehend nicht betroffen. 677 Backend-Tests grün (+39 neu: Achse-2-Invariante, netz-Split-Auflösung, MQTT-Either-Or, M1-Serien-Symmetrie, ADR-001-Erlös-Wächter, kraftstoffpreis-Rettung).

Fixed

Energieprofil-Geräteliste: Netz-Zeile auch bei neuer Netz-Konvention sichtbar (#316, Achse 3): Seit v3.34.2 schreibt eedc Netzbezug/Einspeisung getrennt (netzbezug/einspeisung) statt als kombinierten, vorzeichenbehafteten netz-Wert. Die Geräteliste + Diagnose-Serien im Energieprofil kannten nur die alte Schreibweise — für Tage seit Phase B fehlte der „Stromnetz”-Eintrag still (bei gemischten Zeiträumen unvollständig). Beide Konventionen werden jetzt konsistent als Netz aufgelöst. Die KPI-Werte (Autarkie, Einspeisung, Netzbezug, Eigenverbrauch) waren nie betroffen — sie kommen aus den typisierten Stundenspalten, nicht aus diesem JSON-Feld.
MQTT-/Standalone-Betrieb: E-Auto-Doppelmapping in der Stunden-Bilanz behoben (#317): dieselbe Korrektur wie v3.35.0 (#298), jetzt auch für den MQTT-/Docker-Pfad. Ein E-Auto, das über MQTT sowohl ladung_kwh als auch verbrauch_kwh publiziert (evcc-Bridge), wurde in der Stunden-Bilanz doppelt gezählt. Der MQTT-Pfad nutzt jetzt dieselbe Einmal-Auswahl wie der HA-Pfad — inklusive des bisher fehlenden „E-Auto wird von der Wallbox gemessen”-Skips (parent_investition_id). Betrifft nur MQTT-Standalone-Setups mit doppelt publiziertem E-Auto-Zähler; kein Anwenderbericht, vorbeugend.

Intern (QS, nicht anwender-sichtbar)

kraftstoffpreis_euro überlebt die Aggregator-Reaggregation (#319): das extern befüllte Kraftstoffpreis-Feld fiel beim Delete-and-Recreate eines Tages heraus (bis zum nächsten Preis-Lauf). Jetzt über eine eigene Rettungs-Liste geschützt — dieselbe Mechanik wie die Prognose-Felder, bewusst getrennt vom Wetter-Endpoint-Vertrag (K1).
Achse-2-Drift-Invariante (#315): neue Diagnose-Invariante macht eine etwaige Drift zwischen dem Leistungs-JSON (TEP.komponenten) und den Zähler-Spalten (TEP.*_kw) derselben Stunden im HA-LTS-Modus sichtbar (Warning-Level, kein Tag-Verlust). Im Standalone bereits implizit abgedeckt.
Geteilte Tagesverlauf-Serien-Quelle backfill ↔ live (#318, M1): der Serien-Aufbau (inkl. Pool-Dedup #227) lag zweimal parallel vor; der Pool-Dedup lief nur im Live-Pfad. Damit konnte derselbe Tag je nach Trigger (Scheduler vs. Backfill) leicht abweichende Komponenten-/Peak-Werte erzeugen. Beide laufen jetzt über eine gemeinsame Quelle, abgesichert durch Symmetrie-Test + Re-Divergenz-Wächter.
Einspeise-Erlös durchgängig über die Single-Source (M3, ADR-001): fünf Stellen rechneten den Erlös inline (einspeisung × vergütung / 100) und umgingen damit den §51-Negativpreis-Abzug; alle auf einspeise_erloes_euro() migriert (verhaltensneutral — Projektionen ohne Negativpreis-Kontext). Ein Konformitäts-Test blockiert künftige Inline-Duplikate.
Preserve-Logik-Verifikation: geprüft, ob das v3.33.0-Snapshot-Self-Healing den Reaggregations-Schutz im TZ-Aggregator überflüssig macht — Ergebnis nein (Self-Healing braucht HA-Erreichbarkeit, die in der geschützten Konstellation fehlt). Begründung im Code gehärtet, keine Verhaltensänderung.

[3.35.0] - 2026-06-03 — Stunden-Aggregation: E-Auto-Doppelmapping strukturell behoben (Phase C)

🧱 QS-Refactor (Phase C des v3.34-Refactors, Issue #298). Strukturelle Auflösung einer latenten Doppelzählung in der Stunden-Energiebilanz — die letzte offene Achse der in v3.33.0/v3.34.x sanierten Aggregator-Symmetrie. Anwender-sichtbare Korrektur nur für E-Auto-Setups mit doppelt gemapptem Gesamt-Zähler (siehe unten). Daily-/Monats-Werte waren nie betroffen. 639 Backend-Tests grün (+32 neu: S3-Symmetrie, K3-Konformität, Reload-Vorschau).

Fixed

E-Auto-Doppelmapping in der Stunden-Aggregation strukturell behoben (#298, Anlass #262 junky84/evcc): Misst dein E-Auto-Sensor den Gesamtverbrauch über zwei Felder gleichzeitig (verbrauch_kwh und ladung_kwh, typisch bei evcc-Importen), wurden die Stunden-Werte des E-Autos bisher doppelt gezählt — die Stundentab-/Heatmap-Sicht und der daraus abgeleitete Stunden-Eigenverbrauch lagen für diese Anlagen zu hoch. Der Tages-/Monats-Pfad war seit v3.33.0 korrekt (Either-Or-Auswahl), nur die Stunden-Lese-Pfade riefen den Kategorisierer noch roh pro Feld auf. Alle drei Roh-Konsumenten (beide Stunden-Aggregatoren + die Reload-Vorschau „Tag neu berechnen”) konsumieren jetzt dieselbe Normalisierung wie der Tagespfad (komponenten_beitraege) — doppelt gemappte Zähler werden einmalig zentral aufgelöst, inklusive des bisher im Stundenpfad fehlenden „E-Auto wird von der Wallbox gemessen”-Skips (parent_investition_id). Betroffene Anlagen sehen ihre Stunden-Werte beim nächsten Aggregat-Lauf korrigiert (Halbierung der verdoppelten E-Auto-Werte); die Reload-Vorschau zeigt jetzt denselben (korrekten) Wert wie das Reload-Ergebnis.

Intern (QS, nicht anwender-sichtbar)

Eine Either-Or-Auflösung für alle drei Stunden-Counter-Konsumenten: die Tages-Ebenen-Auflösung (pro fallback_gruppe gewinnt der erste Sensor mit Tagesdaten) liegt jetzt in einem geteilten Helfer (resolve_either_or_eintraege) statt dreimal inline — kein Drift-Vektor zwischen den parallelen Pfaden mehr.
Symmetrie-Test S3 + Konformitäts-Test K3 (ADR-001-Pflicht): S3 prüft parametrisiert über alle Per-Typ-Konstellationen, dass die Summe der 24 Stunden-Slots dem Tages-Boundary entspricht (deckt neben dem #298-Doppelmapping auch den parent-Skip und die Sonstiges-Either-Or-Symmetrie ab — alle vier brachen ohne die Migration) plus eine DB-gestützte Reload-Vorschau-Probe. K3 pinnt strukturell, dass die Stunden-Normalisierung eine faithful projection des Tages-SoT ist und kein Sensor zweimal kategorisiert wird. Damit kann der Stundenpfad nicht erneut gegen den Tagespfad driften.
Realdaten-Validierung (Stufe-1-Harness, Winterborn-HA-LTS): synthetisches Doppelmapping auf zwei reale kWh-Counter zeigt im echten Lesepfad Σ Hourly 69 → 39 kWh (== Tages-Boundary) vor/nach der Migration.

[3.34.7] - 2026-06-02 — EcoFlow-Import überlappungsfrei + E-Auto-Monatstabelle mit Wallbox-Pool

🩹 Patch-Release: zwei unabhängige single-purpose Fixes (Read- bzw. Import-Pfad). Kein Fix berührt den v3.34-Aggregator-Schreibpfad (Hourly-_categorize_counter, Phase-C-Counter unberührt). Je Fix Regressionstest grün, Frontend-Typecheck grün.

Fixed

E-Auto-Dashboard: „Monatsdaten anzeigen” poolt die Wallbox-Ladung pro Monat (#262, junky84): Cockpit → E-Auto → „Monatsdaten anzeigen” gab bei evcc-Setups nur die rohen E-Auto-Zeilen (km) zurück, während die Ladung auf der Wallbox-Investition liegt — die Ladespalten blieben leer. Jede Zeile wird jetzt km-anteilig mit dem Wallbox-Pool angereichert (PV/Netz/Total), nach derselben use_wb_pool-Entscheidung wie die KPI-Kacheln. Premium-Setups (E-Auto pflegt eigene Ladung) bleiben roh. Reiner Read-Pfad.
Cloud-Import: EcoFlow-History-Blöcke überlappungsfrei (Dirk-PN): die Summary_Week-API ist an beiden Enden tag-inklusiv — geteilte Block-Grenztage wurden doppelt gezählt und der 1. des Folgemonats leckte in den Monat, wodurch Dirks Mai-Import ~15–22 % über den EcoFlow-Webseiten-Werten lag. Die Block-Iteration erzeugt jetzt überlappungsfreie Blöcke (Block-Letzttag 23:59:59, Monatsende = Monatsletzter, laufender Monat auf heute geklemmt); PowerOcean + PowerStream nutzen denselben Helper. Regressionstest deckt jeden Tag genau einmal ab.

Konzept (intern, nicht anwender-sichtbar)

IA-V4 Werte/Tabelle-SoT parametrisiert: eine Metrik-Registry + granularitäts-agnostische <WerteTabelle>, gestaffelte Konsolidierung der heute drei parallelen Tabellen, read-only Embeds. Konzept-Phase, kein Code-Change.

[3.34.6] - 2026-06-01 — Setup-Startseite auf Handy/Tablet scrollbar

🩹 Patch-Release: ein single-purpose Frontend-Fix (Folge zu #309). Kein Fix berührt den v3.34-Aggregator-Schreibpfad (Phase-C-Counter unberührt). Frontend-Typecheck grün.

Fixed

Setup-Wizard: Startseite ließ sich auf Handy/Tablet nicht scrollen (simon42 #628–632): Der globale Scroll-Owner-Mechanismus (html,body{overflow-hidden}, eingeführt mit #161 gegen iOS-Companion-Overscroll) macht den Dokument-Body bewusst nicht-scrollbar — einziger Scroll-Container ist der h-dvh-Layout-Wrapper. Der Setup-Wizard hielt sich nicht daran (min-h-screen ohne eigenen Scroll-Container) und wird zudem außerhalb des Haupt-Layouts gerendert. Auf kleinen Bildschirmen war der Willkommens-Schritt höher als der Viewport → der „Einrichtung starten”-Button und alles darunter waren unerreichbar; Drehen ins Querformat und App-Neuinstallation halfen nicht. Der Wizard-Root ist jetzt selbst Scroll-Owner (h-dvh overflow-y-auto overscroll-contain). #309 (v3.34.5) hatte nur Paddings verkleinert, dem Wizard aber keinen Scroll-Container gegeben — auf kleinen Handys reichte das nicht. Dank an Sabrina.

[3.34.5] - 2026-05-31 — MQTT-„Heute”-PV-Summierung + Setup-Wizard auf kleinen Monitoren

🩹 Patch-Release: zwei unabhängige single-purpose Fixes. Kein Fix berührt den v3.34-Aggregator-Schreibpfad (Phase-C-Counter unberührt). 592 Backend-Tests grün, Frontend-Typecheck grün.

Fixed

Live-„Heute”: PV-Erzeugung im MQTT-/Standalone-Modus aus mehreren Wechselrichtern (Dirk-PN): die pro-Wechselrichter gelieferten PV-Werte (inv/<id>/pv_erzeugung_kwh) wurden — anders als im HA-Pfad — nicht zur Kategorie-Gesamt-PV summiert → die „Heute”-Kachel zeigte 0,0 kWh trotz ankommender Daten, und der daraus abgeleitete Eigen-/Hausverbrauch blieb ebenfalls leer. Jetzt werden Komponenten-PV (pv_/bkw_) über die SoT-Whitelist summe_pv_bkw_kwh auf die Kategorie aggregiert (anlagenweites pv_gesamt_kwh-Topic behält Vorrang, keine Doppelzählung). Reiner Live-/Lesepfad — der Tages-/Monats-/Korrekturprofil-Pfad war nicht betroffen.
Setup-Wizard auf kleinen Monitoren skalieren (#309, PR stlorenz): auf 1024×600-Netbooks, älteren Laptop-Displays und der HA-Companion-Sidebar lag der „Einrichtung starten”-Button weit unter dem Fold; kompaktere responsive Paddings + Wegfall des sticky-Headers sparen ~240px Vertikalplatz. Desktop-Layout unverändert.

[3.34.4] - 2026-05-30 — Anschaffungsdatum als Grenze konsequent (WP-Counter, Sonstiges, HA-Export)

🩹 Patch-Release: drei single-purpose Read-Pfad-Fixes derselben Bug-Klasse — per-Investition-Aggregationen respektieren jetzt durchgängig das Anschaffungs-/Stilllegungsdatum. Kein Fix berührt den v3.34-Aggregator-Schreibpfad (Phase-C-Counter unberührt). 587 Tests grün, Frontend-Typecheck grün.

Fixed

WP-Dashboard: Kompressor-Starts/Betriebsstunden „seit Anschaffung” respektieren das Anschaffungsdatum (#308): die Counter-Tagessummen wurden über die gesamte erfasste Sensor-Historie summiert (inkl. Tage vor Anschaffung) statt nur ab Anschaffungsdatum — dadurch konnte die „seit Anschaffung”-Summe den Lebensdauer-Zählerstand übersteigen (physikalisch unmöglich), und ein geändertes Anschaffungsdatum wurde von den Counter-Kacheln ignoriert. Jetzt mit ist_aktiv_im_zeitraum-Filter auf die WP-Laufzeit (symmetrisch zum Monatsdaten-Pfad); der LTS-Abruf selbst war korrekt. Der Zusatz „(seit Anschaffung)” im Kachel-Titel entfällt (steht weiter im Tooltip). Dank an detLAN.
Sonstiges-Dashboard: Laufzeit-Filter (#308-Folge): get_sonstiges_dashboard summierte die Monatsdaten als einziges der sechs Investitions-Dashboards ohne ist_aktiv_im_monat — Monate vor Anschaffung / nach Stilllegung flossen in Erzeugung/Verbrauch/Ersparnis/CO₂.
HA-Export: per-Investition-Sensoren respektieren die Laufzeit (#308-Folge): calculate_investition_sensors summierte E-Auto-/Wallbox-/WP-Monatsdaten ohne Anschaffungs-/Stilllegungs-Filter (asymmetrisch zur Schwesterfunktion calculate_anlage_sensors).

Hintergrund

Befund aus einem Backend-weiten Audit aller per-Investition-Aggregationen nach #308: die Abdeckung aus v3.29 (#236/#239) hielt fast überall; nur diese zwei weiteren Read-Pfad-Lücken blieben. Der Aggregator-Schreibpfad (aggregate_day/backfill/rollup) ist durchgängig laufzeit-gefiltert.

[3.34.3] - 2026-05-29 — Sammelrelease: acht Backlog-Fixes (UX, Forecast, Connector, Verbrauchs-/E-Auto-Kennzahlen)

🧰 Gebündeltes Patch-Release mit acht unabhängigen, single-purpose Fixes aus dem aufgelaufenen Issue-Backlog — parallel zum v3.34-Refactor abgearbeitet. Kein Fix berührt den v3.34-Aggregator-Schreibpfad. 584 Tests grün, Frontend-Typecheck grün.

Added

core/berechnungen/verbrauch.py → berechne_verbrauchs_kennzahlen als Single Source of Truth für die Eigenverbrauchs-/Autarkie-Formel (ADR-001-Berechnungs-Layer), deckungsgleich mit cockpit/uebersicht.py + daten_checker.py.

Fixed

Modal-Dialoge scrollen intern; Speichern bei langen Formularen wieder erreichbar (#307): Modal.tsx (app-weit) auf max-h-[90dvh] + interne Scroll-Spalte umgestellt — lange Dialoge (z. B. „Monatsdaten bearbeiten”) bleiben im Viewport, Buttons per Scroll erreichbar; kurze Dialoge unverändert.
Daten-Checker: ehrlicher Quellen-Konflikt-Hinweis + lesbarer PV-Doppelerfassungs-Text (#305): der „Daten-Quellen-Konflikte”-Hinweis verspricht keine nicht-existente „Beheben”-Aktion mehr (WARNING → INFO, Link entfernt, an drei Stellen entschärft); PV-Doppelerfassungs-Detailtext mit Zeilenumbrüchen lesbar (whitespace-pre-line).
Multi-String/BKW-Tagesprognose kollabiert nicht mehr bei OpenMeteo-Aussetzern (#306): gescheiterte Orientierungsgruppen werden nicht mehr still verschluckt; ein unvollständiger Fan-out wird nicht als kollabierter Solo-String-/BKW-Tageswert eingefroren (Prefetch + Live-Endpoint), Solcast bleibt unabhängig. Schützt auch den Lernfaktor.
Fronius-Connector: PV-Erzeugung auf Gen24/neuer Firmware (#300): wenn GetPowerFlowRealtimeData → Site.E_Total leer ist, holt der Connector die PV-Summe als Fallback aus GetInverterRealtimeData (Σ TOTAL_ENERGY über alle Wechselrichter). Noch nicht an echtem Gen24 verifiziert — Gegencheck offen.
HA-Export: Eigenverbrauchsquote bei IMD-Setups korrekt (#304, Teil 1): Eigen-/Direkt-/Gesamtverbrauch + Quoten über den neuen SoT-Helper aus PV(IMD) + Speicher(IMD) + Zählerwerten statt aus leeren Legacy-Monatsdaten-Feldern (2,2 % → ~40 %). #304 bleibt offen: Aussichten + PDF als eigene Etappe nach v3.34.
Cockpit-Übersicht: E-Auto-Ersparnis mit Monats-Benzinpreis (#260): die E-Mobilitäts-/E-Auto-Ersparnis rechnet jetzt km-gewichtet mit dem per-Monat aus dem EU Weekly Oil Bulletin gepflegten Kraftstoffpreis (berechne_eauto_ersparnis_periode) statt mit dem statischen Investitions-Parameter — gleicher Wert wie E-Auto-Dashboard + Monatsberichte. Letzte offene Drift-Quelle aus #260.

Changed

WP-Dashboard: Counter-Kacheln „seit Anschaffung”, Lebensdauer-Zählerstand im Tooltip (#238/#290): Kompressor-Starts, Betriebsstunden + die abgeleiteten KPIs zeigen als Hauptwert das von eedc seit Anschaffung Erfasste (Anzeige ab Anschaffungsdatum limitiert); der rohe Lebensdauer-Zählerstand steht im Tooltip.

[3.34.2] - 2026-05-29 — Vollbackfill als dünne Schleife über den Tag-Aggregator (Phase B v3.34-Refactor)

🔧 Patch-Release, struktureller Schnitt + stille Datenverbesserung. Phase B des Energieprofil-+-Werkbank-Refactors. backfill_from_statistics (Vollbackfill aus HA Long-Term Statistics) ist nicht länger eine eigenständige Code-Kopie der Tag-Aggregation, sondern eine dünne Schleife über aggregate_day — genau ein Top-Level-Schreibpfad auf tages_energie_profil + tages_zusammenfassung (Audit §6.1, Plan E1/E2). Damit fällt die parallele Pipeline weg, die in der Vergangenheit wiederholt Aggregations-Drift erzeugt hat.

📣 Stille Datenverbesserung für per Vollbackfill geschriebene Tage. Bestehende Werte bleiben unverändert (additiv, #190) — erst bei erneuter Aggregation (Werkbank → „Tag(e) neu aggregieren” / „Vollbackfill”) werden die bisher fehlenden Felder befüllt. Phase C (Hourly-Helper-Migration) bleibt v3.35.0.

Changed

backfill_from_statistics ist eine dünne Schleife über aggregate_day (source=Source.VOLLBACKFILL_FROM_LTS). Der Backfill beschafft die historischen Stunden-Leistungen weiterhin gebündelt aus HA-LTS (get_hourly_sensor_data einmal pro Range — get_tagesverlauf reicht nur ~10 Tage zurück) und reicht sie pro fehlendem Tag als prefetched_tagesverlauf durch (Pflicht-Mitigation gegen Per-Tag-Read-Verlust, Plan §3 B.3). Die gesamte Aggregations-Logik (kategorisierte Stunden-kWh, Boundary-kWh, Peaks, Counter, SoC/Vollzyklen, Prognose-Rettung, Provenance, Konsistenz-Invariante) lebt nur noch in aggregate_day. Die Backfill-eigene Komponenten-Aggregation, Boundary-Logik und Prognose-Rettungsliste sind entfallen.
Stille Datenverbesserung: für neu nachgefüllte Tage setzt der Vollbackfill jetzt zusätzlich Tages-Peaks (aus HA-LTS-Min/Max statt nur W-Integration), Strompreis-/Börsenpreis-Stunden (strompreis_cent/boersenpreis_cent je Stunde) und die Börsenpreis-Tagesfelder (boersenpreis_avg_cent, boersenpreis_min_cent, negative_preis_stunden, einspeisung_neg_preis_kwh) — alle bisher beim eigenständigen Backfill leer. Die Tages-Komponenten-kWh kommt aus dem HA-LTS-Pfad (statt der Snapshot-Variante).
Per-Tag-Aktiv-Filter aktiv_am_tag(datum) als dritte Variante in utils/investition_filter (neben aktiv_jetzt/aktiv_im_zeitraum). aggregate_day lädt seine Investitionen jetzt per aktiv_am_tag(datum) statt „alle der Anlage” — für historische Tage mit zwischenzeitlich stillgelegter Investition liefern Scheduler- und Vollbackfill-Pfad damit dasselbe Ergebnis (Audit §6.4). Definiert als Null-Breiten-Range aktiv_im_zeitraum(tag, tag) und damit deckungsgleich mit Investition.ist_aktiv_an am Stilllegungstag. Für den Scheduler (heute/gestern) ein No-Op.
Source-Enum erweitert: Source.VOLLBACKFILL_FROM_LTS = "ha_statistiken". to_db_string() liefert byte-identisch "ha_statistiken" (DB-Spalte datenquelle + UI unverändert). Der Provenance-Writer migriert von ha_statistics_backfill auf das einheitliche energieprofil:ha_statistiken (analog zu den drei in v3.34.0 eingeführten Enum-Schreibern). Reine Audit-Log-Markierung, kein UI- oder Funktions-Effekt — historische Backfill-Einträge bleiben unter dem alten String.

Test

S1 (Symmetrie Scheduler ↔ Vollbackfill, Erfolgskriterium E2): aggregate_day über get_tagesverlauf (Scheduler) vs. über prefetched_tagesverlauf (Vollbackfill) liefert für denselben historischen Tag bei identischer Datenlage identische TZ-Aggregate; einziger Unterschied ist die datenquelle-Spalte. Pflicht-Konstellation: zwischenzeitlich stillgelegte Investition.
S2 (dokumentiertes Delta): der konsolidierte Pfad füllt die zuvor leeren Felder (Peaks, Strompreis-/Börsenpreis-Felder) — als positive Liste verankert.
aktiv_am_tag: Stilllegungs-/Anschaffungs-Grenzen + Deckungsgleichheit mit ist_aktiv_an am Stilllegungstag.
E1-Strukturwächter: backfill.py konstruiert keine TEP/TZ-Rows mehr und ruft keine seed_*_provenance mehr auf.
Werkbank-VOLLBACKFILL-Endpoint-Response-Schema unverändert (Schema-Stabilitäts-Test).
K1 auf zwei Listen reduziert: die Backfill-Rettungsliste entfällt strukturell; K1 schützt nur noch die verbleibende Subsystem-Grenze (Aggregator ↔ Wetter-Endpoint).
Suite: 567 grün (559 v3.34.1 + 8 neu).

Notes

Schatten-Vergleichs-Lauf (alt vs. neu, 30 Tage, synthetisch): zwei strukturelle Diffs für neu geschriebene Tage (bestehende Tage unangetastet) — beide sind die beabsichtigte Angleichung an den täglichen Aggregat-Lauf:
1. komponenten_kwh enthält keinen netz-Schlüssel mehr. Der alte Backfill ließ den Live-Σ-Riemann immer laufen und schleppte das netz-Netto-Artefakt mit; der Scheduler unterdrückt es im HA-LTS-Modus (Live-Σ-Bypass). Der konsolidierte Vollbackfill verhält sich jetzt wie der Scheduler. netz ist kein echter Boundary-Komponenten-Schlüssel (Konsumenten nutzen einspeisung/netzbezug).
2. Provenance-Source external:ha_statistics → external:ha_statistics:daily/:hourly und Writer → energieprofil:ha_statistiken (s. oben). Keiner liest den alten Writer/Source-Prefix-Filter bricht nicht (external:ha_statistics bleibt Prefix).
Performance: synthetischer 30-Tage-Lauf mit gemockter I/O (= Plan-§3-B.4-Sanity „in Test-Umgebung”) zeigt ~1,3–1,5× CPU-Overhead, absolut ~2–3 ms/Tag. Die reale Laufzeit ist von den HA-LTS-Reads dominiert: der konsolidierte Pfad macht pro Tag mehr Reads als der alte Backfill (zusätzlich Peaks/SoC/Strompreise — genau wie der Scheduler), als Preis der Vollständigkeits-Verbesserung. Ein langer Vollbackfill (z. B. 12 Monate) kann dadurch spürbar länger laufen; das ist Laufzeit, keine Korrektheit, und ein seltener additiver Hintergrund-Job. Die Pflicht-Mitigation (großer Roh-Leistungs-Bulk-Read bleibt einmal pro Range) ist umgesetzt. Reales Timing ist erst im Add-on (post-Release) messbar — bei Tester-Meldung über lange Laufzeit ist die Folge-Optimierung (auch LTS-Deltas/Peaks im Bulk vorholen) eine eigene spätere Etappe, kein Phase-B-Blocker.

[3.34.1] - 2026-05-26 — `komponenten_kwh` für laufenden Tag im HA-Add-on heilen (B-clean Hotfix)

🔧 Hotfix. Chirurgischer Single-Purpose-Fix für den Befund von MartyBr (#620 simon42-Forum) — keine Bündelung mit anderen Themen. Phase B des v3.34-Refactors (Backfill-Konsolidierung, vorher für v3.34.1 vorgesehen) rückt durch diesen Hotfix auf v3.34.2; Phase C bleibt v3.35.0.

Fixed

TagesZusammenfassung.komponenten_kwh für datum == today im HA-Add-on (#620 MartyBr simon42-Forum) — im HA-Add-on-Modus war komponenten_kwh für den laufenden Tag strukturell leer (None), weil fünf unabhängig sinnvolle Schutzmaßnahmen dieselbe Schreib-Schicht erreichten und gemeinsam einen Dead-Spot bildeten (BKW-Bug-Fix-Live-Σ-Bypass + #290-Bug-B-Boundary-SKIP + Snapshot-Fallback-Tag-Bedingung + #184-Add-on-Live-Snapshot-Deaktivierung + LTS-Statistics-Lag — vollständige Anatomie in docs/drafts/archive/AUDIT-energieprofil-werkbank.md §5.1.1). Resultat: rund 641 Drift-Warnings im Daten-Checker pro Tag, Cockpit- und Komponenten-Hub-Anzeige für „heute” lückenhaft. Heilung: die datum >= today-Bedingung des Boundary-SKIP wurde auf datum > today gelockert (nur Zukunft bleibt SKIP). Für datum == today läuft jetzt der LTS-Boundary-Pfad get_komponenten_tageskwh_lts, der slot-basiert pro Stunden-Slot boundary[h+1] - boundary[h] aus HA-Statistics summiert (get_hourly_kwh_deltas_for_day-Docstring) und für noch nicht geschriebene Slots None liefert — saubere Teilsumme der schon abgelaufenen Stunden, kein Self-Heal-Inflationsrisiko. Die ursprüngliche Begründung (snap[Folgetag 00:00] self-healt auf aktuellen Counter-Stand) trifft nur die Snapshot-Variante get_komponenten_tageskwh — deren SKIP bleibt über die datum < today-Bedingung des Fallback-Pfads (aggregator.py:531) erhalten. Edge-Case 00:05-Scheduler: noch keine Stunde des neuen Tages → leeres LTS-Dict → komponenten_kwh = None (Sentinel-Verhalten unverändert). Vier andere Schutzmaßnahmen aus §5.1.1 (BKW-Live-Σ-Bypass, Snapshot-Fallback-Tag-Bedingung, #184-Add-on-Live-Snapshot-Deaktivierung, LTS-Statistics-Lag) bleiben unangetastet.

Test

6 neue Tests in test_symmetrie_aggregator_today.py: S0-Symmetrie über die vier Aggregator-Konstellationen aus Audit §3.6 (HA-Add-on historisch / heute / Standalone-MQTT historisch / Zukunfts-SKIP), Edge-Case 00:05-Scheduler (komponenten_kwh bleibt None, kein leeres Dict), BKW-Bug-Regressions-Schutz (Live-Σ-Bypass im LTS-Modus aktiv).
Bestehender Test test_heute_ueberspringt_boundary_diff mit präzisiertem Docstring (Snapshot-Variante bleibt vom SKIP betroffen, LTS-Variante nicht).
Suite: 559 grün (553 v3.34.0 + 6 neu).

Notes

Pattern-Klasse §5.1.1 „Bypass-Kombi auf derselben Schreib-Schicht” ist im Audit dokumentiert und in der Memory feedback_bypass_kombi_schreib_schicht als Reviewer-Disziplin festgehalten: bei jedem Symptompatch auf der komponenten_summen-Schicht muss die Wechselwirkung mit den anderen vier Maßnahmen explizit geprüft werden.
Phase B verschoben: Backfill-Konsolidierung kommt jetzt als v3.34.2 nach einem regulären Tester-Zyklus für v3.34.1.

[3.34.0] - 2026-05-24 — Drift-Erkennung für Aggregat-Felder verschärft (Phase A v3.34-Refactor)

🔧 Patch-Release, Vorarbeit. Phase A des in v3.33.0 angekündigten Energieprofil-+-Werkbank-Refactors. Schärft die Drift-Erkennung auf der Daily-Schreibseite und entkoppelt einen Magic-String, der bisher gleichzeitig DB-Spalten-Wert UND Steuerungs-Trigger war. Keine User-spürbare Funktionsänderung — alle bestehenden DB-Werte (TagesZusammenfassung.datenquelle) und Provenance-Writer-Strings bleiben byte-identisch, keine Migration nötig.

📣 Folge-Etappen angekündigt. Phase B (Backfill-Konsolidierung — backfill_from_statistics wird zur dünnen Schleife über aggregate_day, stille Daten-Verbesserung für historische Tage) folgt als v3.34.1 nach einem normalen Tester-Zyklus. Phase C (Hourly-Helper-Migration analog zur in v3.33.0 sanierten Daily-Symmetrie, strukturelle Auflösung des E-Auto-Doppelmapping-Bugs) folgt als v3.35.0 mit eigenem Sichtungs- und Tester-Zyklus, weil sie anwender-sichtbar sein kann.

Added

Konformitäts-Test K1 — Prognose-Felder-Listen-Sync (test_konformitaet_prognose_felder.py): Koppelt drei real existierende Prognose-Rettungs-Listen über Subsystem-Grenzen hinweg ohne sie zu einer geteilten Konstante zu verschmelzen. Bei Drift in einer der drei Stellen (Aggregator _PROGNOSE_FELDER_RETTEN, Backfill _PROGNOSE_FELDER_RETTEN_BACKFILL, Wetter-Endpoint _TZ_SCHREIBFELDER_PROGNOSE) bricht der Test mit klarer Fehlermeldung. Vorfallsbezug: v3.31.7 (#190) hatte das Korrekturprofil dauerhaft leer gelassen, weil pv_prognose_stundenprofil zum Aggregator hinzugefügt, aber im Backfill vergessen wurde — heute strukturell durch existing_dates-Skip neutralisiert, latente Drift-Stelle ohne akuten Schaden. K1 fängt die nächste Drift-Iteration vorab.
Konformitäts-Test K2 — TZ-Felder-Vollständigkeits-Check (test_konformitaet_tz_felder.py): Jede TagesZusammenfassung-Spalte muss in genau einer von vier Klassifikationen stehen — vom Aggregator gesetzt, auf der Prognose-Rettungs-Liste, ORM/Identifier oder explizit “bleibt NULL” mit Begründung. Bei jeder neuen Spalte wird der Autor durch Test-Bruch zu einer expliziten Entscheidung gezwungen — kein stilles Vergessen mehr durch den Delete-and-Recreate-Pfad.
Source-Marker als typsicheres Enum (backend.services.energie_profil.source.Source): Der bisherige datenquelle-Magic-String hatte drei gleichzeitige Rollen — DB-Spalten-Wert, Provenance-Writer-Suffix und Verzweigungs-Trigger für die Preserve-Logik (Audit §8.12). Ein Tippfehler in einem Aufrufer hätte die Schutzlogik still ausgeschaltet. Das Enum hat drei Werte (SCHEDULER, MONATSABSCHLUSS_BACKFILL, MANUAL_REPAIR) und projiziert via to_db_string()/to_writer()/is_manual_repair() auf die heutigen Magic-Strings — DB- und Provenance-Output bleiben byte-identisch. aggregate_day nimmt das Enum als Pflicht-Keyword-Parameter ohne Default; ein Aufruf ohne source=... bricht zur Aufruf-Zeit mit TypeError. Alle bestehenden Aufrufer (Scheduler, Backfill, Repair-Orchestrator, v3.33.0-Migration und alle Tests) sind auf das Enum umgestellt — Plan §3 Phase A E4 sauber erfüllt, der Magic-String existiert nur noch als Output in DB-Spalte und Provenance-Writer-String, nicht mehr als Eingangs-Trigger im Aggregator.

Test

2 K1-Konformitäts-Tests (Listen-Sync + Modell-Existenz)
3 K2-Konformitäts-Tests (Vollständigkeit + Disjunktheit + Modell-Existenz)
5 Source-Marker-Regressions-Tests (Projektions-Werte byte-identisch, Enum-Vollständigkeit, Signatur-Smoke-Test)
Suite: 553 grün (543 v3.33.0 + 10 neu)

Notes

Asymmetrie-Klärung Scheduler-Preserve vs Manuell-Preserve (Audit §4.2): Die heutige Asymmetrie (is_manual_repair-Trigger nur bei Reparatur-Werkbank, nicht beim Scheduler) ist eine Pattern-Adaption aus dem Monatsdaten-Kontext. Dort schützt das Preserve-Pattern manuell editierte Monatsdaten-Werte vor Überschreibung durch Scheduler-Läufe. In TagesZusammenfassung gibt es keine manuelle Werteingabe; „manuell” bedeutet hier „Werkbank-Trigger” (Source.MANUAL_REPAIR). Die Übertragung in den TZ-Aggregator erfolgte in v3.32.4 (#290) als defensive Maßnahme bei nicht erreichbarem HA-LTS plus inkonsistenten Snapshots. Damit ist die Asymmetrie weder reiner Tradeoff noch dokumentierter TZ-Vorfall — sondern eine vorsichtige Pattern-Adaption aus einem semantisch verwandten Bereich. Der Inline-Kommentar in aggregator.py:582 trägt diese Geschichte. Phase B / spätere Etappe sollte prüfen, ob die Adaption im TZ-Kontext weiterhin gerechtfertigt ist oder ob Snapshot-Self-Healing den Schutz heute überflüssig macht.
Allowlist-Befund kraftstoffpreis_euro (K2 Phase-A-Notiz): Wird heute extern via kraftstoff_preis_service.fill_tagesdaten befüllt und beim Aggregator-Delete-and-Recreate verworfen. Risiko-Klasse identisch zu den Prognose-Feldern, aber heute nicht durch eine Rettungs-Liste geschützt. Kein akuter Anwenderbericht (Symptom selten, weil Kraftstoffpreis-Backfill-Lauf typisch nach Re-Aggregation läuft). Folge-Diskussion offen — wird in einer Phase-B-Sichtung mitgedacht.
Plan-Abweichung: to_provenance_source(hourly_source: …)-Methode nicht implementiert. Der v3.34-Plan §3 Phase A.1 + das Handover-Doc fordern eine vierte Projektions-Methode am Source-Enum, die den TZ/TEP-Provenance-Source-String (external:ha_statistics:hourly|daily vs auto:monatsabschluss) je nach Hourly-Datenpfad zusammensetzt. Im heutigen Code hängt diese Verzweigung (aggregator.py:613-617) ausschließlich vom Daten-Pfad (LTS-Aggregator-Ergebnis vs Snapshot-Fallback) ab, nicht vom Source-Enum. Eine Methode am Enum hätte einen HourlySource-Parameter gebraucht, der das Enum auf eine ihm fremde Konzept-Ebene zieht und zwei orthogonale Achsen kapselt. E4 (kein datenquelle == als Verzweigung im Aggregator) ist trotzdem voll erfüllt, weil keine der drei aktiven Magic-String-Verzweigungen am datenquelle-String hing, die der Plan adressieren wollte. Die Methode lässt sich in Phase B nachrüsten, wenn der Backfill-Konsolidierungs-Schnitt den Source-String-Aufbau ohnehin neu strukturiert.

[3.33.0] - YYYY-MM-DD — LTS-Aggregator-Drift strukturell behoben + Reparatur-Werkbank wirksam + v3.34-Ankündigung

🔧 Patch-Release. Strukturelle Bereinigung der in v3.32.4 angekündigten Aggregator-Drift. Plus: die in v3.32.4 als Übergangsschutz eingebaute Reparatur-Werkbank-Bremse (manueller Skip des Boundary-Diff) wird entfernt — sie war ein Symptompatch, mit dem strukturellen Fix funktioniert die Reparatur-Werkbank wieder für ihren eigentlichen Zweck. Einmalige Historien-Migration korrigiert alle betroffenen TZ-Rows automatisch beim ersten Start.

📣 Angekündigt: v3.34 strukturelle Vereinfachung Energieprofil + Reparatur-Werkbank. Beide Subsysteme sind über mehrere Releases organisch gewachsen mit mehreren parallelen Schreib-/Lese-Pfaden und Übergangs-Patches. Für v3.34 ist eine konsolidierte Architektur mit einem zentralen Schreibpfad und dünnen Quellen-Adaptern geplant, alle Per-Typ-Aggregations-Logik wandert in den Berechnungs-Layer. Während der Konzept- und Audit-Phase werden neue Issues und Beiträge zu diesen Bereichen gesammelt und mit dem Refactor adressiert. Für das laufende v3.33.0 bleibt die Werkbank verfügbar.

Fixed

LTS-Aggregator-Drift in TagesZusammenfassung.komponenten_kwh strukturell behoben (#290): Per-Typ-Logik aus services.snapshot.aggregator.get_komponenten_tageskwh und services.snapshot.lts_aggregator.get_komponenten_tageskwh_lts in einen geteilten Helper services.snapshot.komponenten_beitraege extrahiert. Beide Aggregator-Varianten konsumieren denselben Helper — eine asymmetrische Per-Typ-Implementierung wie zwischen v3.31.0 und v3.32.4 ist damit strukturell ausgeschlossen. Parametrisierter Symmetrie-Test deckt 17 Mapping-Konstellationen ab (PV/BKW/Speicher mit und ohne Arbitrage, WP mit und ohne getrennte Strommessung und mit thermischen Sensoren, Wallbox mit und ohne Split, E-Auto mit Either-Or und mit Wallbox-Parent, Sonstiges Verbraucher und Erzeuger).
Reparatur-Werkbank schreibt wieder komponenten_kwh (#290 Folge): Der in v3.32.4 als Übergangsschutz eingeführte generische Skip bei datenquelle="manuell" ist entfernt. Mit dem korrigierten Helper liefert der Boundary-Diff jetzt korrekte Per-Typ-Werte — die Reparatur-Werkbank kann ihren eigentlichen Zweck erfüllen und Tages-Komponentenwerte korrigieren. Der datum >= today-Skip bleibt (strukturell, nicht symptomatisch). Die Preserve-Logik (alte Werte behalten wenn alle Quellen leer) bleibt als defensiver Schutz.

Added

Erweiterte TEP↔TZ-Invariante (core.berechnungen.invarianten.pruefe_tep_tz_komponenten_konsistenz): Prüft Σ TEP-Stunden gegen Σ komponenten_kwh-Präfix für PV+BKW, Wärmepumpe, Wallbox+E-Auto, Batterie (netto) sowie Einspeisung und Netzbezug. Im aggregate_day aufgerufen — Drift wird im Log sichtbar, bevor ein Anwender sie meldet.
Einmalige Historien-Migration (migrate_v3_33_0_lts_komponenten_kwh): Reaggregiert beim ersten Start nach v3.33.0 alle TagesZusammenfassung-Rows ab dem 16.5.2026 für jede Anlage mit sensor_mapping. Idempotent über migrations-Tabelle. Activity-Log-Eintrag bei Start und Ende. Performance-optimiert: nur Tage mit existierender TZ-Zeile werden angefasst.

Test

17 parametrisierte Symmetrie-Tests (test_aggregator_symmetrie.py)
11 Snapshot-Aggregator-Regression-Tests (test_snapshot_aggregator_regression.py)
18 Helper-Unit-Tests (test_komponenten_beitraege.py)
11 Invariante-Tests (test_invariante_komponenten_konsistenz.py)
3 Reparatur-Werkbank-Korrektur-Tests (test_reparatur_werkbank_komponenten_korrektur.py)
4 Migrations-Tests (test_migrate_v3_33_0_lts_komponenten_kwh.py)
Suite: 543 grün

[3.32.4] - 2026-05-24 — Database-Lock-Fix + Reaggregations-Hardening + Diagnose-Restore

🔧 Patch-Release. Schwerpunkt: drei Tester-Fixes (#291 SQLite-Locks beim Cloud-Reimport, #290 detLAN Reaggregations-Anomalien und „0/24”-Diagnose-Fehlmeldung). Plus ein als Folgefund identifizierter strukturierter LTS-Aggregator-Drift seit v3.31.0, dessen vollständige Bereinigung mit Historien-Reaggregation in v3.33.0 folgen wird (siehe unten).

⚠️ Bekannter Folge-Bug → v3.33.0 angekündigt. Im Zuge der Diagnose von #290 wurde aufgedeckt, dass der seit v3.31.0 aktive HA-LTS-Aggregator-Pfad (get_komponenten_tageskwh_lts) bei Investitionen mit Multi-Sensor-Mappings die typenspezifischen Filter überspringt, die der Snapshot-Aggregator-Pfad anwendet. Folge: in TagesZusammenfassung.komponenten_kwh (sichtbar im Auswertungen→Energieprofil-„Tage”-Tab) sind die Spaltenwerte für Wärmepumpe (thermische Sensoren), Speicher (Arbitrage-Mapping mit ladung_netz_kwh), Wallbox (PV-/Netz-Split-Mapping), E-Auto (Multi-Sensor + Wallbox-misst-EA-Konstellation) und Sonstiges (bidirektionale Mappings) seit dem 16.5.2026 systematisch überhöht. v3.32.4 entschärft die zwei akut sichtbaren Folgen (heute-Spalte driftet gegen TD-Tab, „Tag neu aggregieren” verschlechtert statt verbessert die Werte) als Defense-in-Depth. v3.33.0 bringt die strukturelle Lösung: geteilter Helper für die Per-Typ-Logik (geometrisch garantierte Symmetrie zwischen beiden Aggregator-Varianten), Symmetrie-Tests pro Typ, erweiterte TEP↔TZ-Invariante auf alle Komponenten-Kategorien — plus eine einmalige Historien-Migration, die beim ersten Start nach Update alle TZ-Rows zwischen 16.5. und Release-Datum für jede betroffene Anlage automatisch korrekt reaggregiert. Persistente HA-Notification informiert den Anwender. Tester-Wiedervorlage geplant.

Fixed

Datenbank-Locks beim Cloud-Re-Import (#291 kingcap1): database is locked während Monatsabschluss-Speichern, wenn parallel ein Vollbackfill-/Cloud-Aggregator-Lauf seriell Tag-für-Tag in einer einzigen Schreibtransaktion lief und den SQLite-Writer-Lock über Minuten hielt. Fix: backfill_range, backfill_from_statistics und beide Scheduler-Jobs (aggregate_today_all, aggregate_yesterday_all) committen jetzt pro Tag bzw. pro Anlage — Lock immer nur ~15-20 s belegt. Sicherheitsnetz: busy_timeout von 10 s auf 30 s erhöht. Bei Restkollision sieht der Anwender statt SQL-Dump eine freundliche 503-Meldung „Datenbank gerade belegt, in 10-20 Sekunden erneut speichern”.
Reaggregations-Knopf „Tag neu aggregieren” verschlimmbessert nicht mehr (#290 detLAN Punkt 4): Wenn HA-LTS für den gewählten Tag keine Statistik-Stunden liefert und keine validen Snapshots in der DB existieren, schrieb aggregate_day trotzdem eine neue TZ-Zeile mit (häufig falschen) selbst-geheilten Boundary-Werten und löschte die alte vorher. Fix: bei datenquelle="manuell" mit leerem Σ-Hourly werden komponenten_kwh und komponenten_starts aus der bestehenden TZ bewahrt statt durch Self-Heal-Müll ersetzt. Plus: Boundary-Diff wird bei manueller Reaggregation generell übersprungen — Σ-Hourly aus der Stunden-Schleife ist die verlässlichere Quelle.
Reaggregations-Diagnose „0/24 Stunden mit Messdaten” auch bei Erfolg (#290 detLAN Punkt 4 Folge): Beim Orchestrator-Refactor in Commit 17db2350 (v3.30.x) ging das Response-Feld stunden_mit_messdaten aus dem POST /api/energie-profil/{id}/reaggregate-tag-Endpoint verloren. Das Frontend wertet > 0 aus — undefined > 0 ist false, also wurde immer die Warnung „0/24 — keine Snapshots / HA-Statistics nicht erreichbar” angezeigt, auch bei erfolgreich aggregierten Tagen mit voller Datenlage. Field wiederhergestellt: Counter aller TEP-Stunden des Tages mit mindestens einem nicht-NULL-Leistungswert.
Heute-Spalte im Energieprofil-„Tage”-Tab driftet nicht mehr ~5-10× gegen den „TD”-Tab (#290 Punkt 3, Defense-in-Depth): Für datum == today ist snap[Folgetag 00:00] per Definition Zukunft. Das Self-Healing zog den nächstgelegenen verfügbaren Wert aus HA-history/MQTT — bei großzügigen Toleranzfenstern teils einen Wert nahe „jetzt”, der semantisch nicht „Tagesende” entspricht. Fix: für den laufenden Tag wird die Boundary-Diff übersprungen, komponenten_kwh für heute kommt ausschließlich aus dem Σ-Hourly-Pfad (= gleiche Quelle wie TD-Tab, Live-Dashboard, Cockpit-Übersicht-heute).

Changed

KPI-Karten auf dem Wärmepumpe-Dashboard tragen jetzt „(Lebensdauer)“-Suffix (#290 detLAN Punkt 1+2): Die Karten „Kompressor-Starts” und „Betriebsstunden” zeigen by design die Lebensdauer-Werte aus dem Hersteller-Counter (Tooltip erläutert das). Der Bezug war bei flüchtigem Lesen leicht zu verwechseln mit einem Monatsaggregat, gerade weil andere KPIs der Seite auf das abgeschlossene Monatsfenster bezogen sind. Title-Suffix macht den Bezug auf einen Blick klar — keine Funktionsänderung.
Spalten-Header im Energieprofil-„Tage”-Tab tragen jetzt die Einheit (#290 detLAN Punkt 5): „kWh”, „kW”, „Starts”, „Zyklen” etc. werden grau in Klammern hinter dem Spalten-Label angezeigt, statt nur im Tooltip. Konsistent zur „TD”-Tab-Konvention.
Docstring get_komponenten_tageskwh korrigiert (#290 Punkt B): Der Hinweis „Σ stromverbrauch+heizenergie+warmwasser” im Funktions-Docstring war Wunschdenken — der Code rechnete (korrekterweise) ausschließlich mit stromverbrauch_kwh. Docstring an Code angeglichen, plus expliziter Hinweis warum thermische Felder nicht in die Energie-Bilanz gehören (≈ Strom × COP). Cosmetic + Maintainer-Klarheit (genau dieser falsche Docstring hat zur Asymmetrie zwischen Snapshot- und LTS-Variante beigetragen, die in v3.33.0 strukturell bereinigt wird).

[3.32.3] - 2026-05-23 — Doku-Nachreichung WAS-IST-NEU

📝 Reine Doku-Nachreichung. Bei v3.32.2 war die WAS-IST-NEU-Seite noch auf v3.32.1-Stand — sync-help.sh läuft vor dem Frontend-Build, also wurde der alte Stand ins v3.32.2-Image gebacken. Anwender hätten den v3.32.2-Inhalt erst beim nächsten Release gesehen. Diese Version bringt den WAS-IST-NEU-Block für v3.32.2 in die In-App-Hilfe.

Changed

WAS-IST-NEU.md (In-App-Hilfe „Was ist neu”) für v3.32.2 nachgepflegt: Sungrow-AppKey-Rotation, EcoFlow-indexNames, Victron-Freigabe, WP-Betriebsstunden, evcc-Pool-Mismatch-Warnung, §51 EEG Phase 2, Delete-Button-Hinweis und IA-v4.0.0-Konzept sind jetzt auch in der In-App-Hilfe sichtbar. Keine Code-Änderungen.

[3.32.2] - 2026-05-23 — Cloud-Import-Hardening + WP-Betriebsstunden + IA v4.0.0 Konzept

🔧 Patch-Release. Schwerpunkt: drei Cloud-Import-Tester-Fixes (Sungrow #287, EcoFlow Dirk-PN, Victron-Verifizierung #255), neues WP-Betriebsstunden-Tracking (#238) und das IA v4.0.0 Konzept als gemeinsame Anlaufstelle für den größeren UX-/Menüstruktur-Refactor in der nächsten Major-Welle.

Added

WP-Betriebsstunden-Sensor + KPIs (#238 detLAN): optionaler total_increasing-Sensor pro WP-Investition, integriert in die KUMULATIVE_COUNTER_FELDER-Architektur. Tagesaggregat liefert Starts × Betriebsstunden + Ø Laufzeit pro Start; KPI-Kachel im Monatsbericht und im WP-Dashboard. Architektur analog v3.24.0 Kompressor-Starts.
Daten-Checker: evcc-Pool-Pflege-Mismatch-Warnung (Phase 2a): erkennt, wenn der zentrale evcc-Pool-Sensor nicht (mehr) zur Sensor-Zuordnung passt — z. B. nach Wallbox/E-Auto-Hinzufügen ohne Pool-Update. Diagnostischer Hinweis mit Reparatur-Link, kein Auto-Heal.

Changed

§51 EEG Phase 2 — Erlös-Abzug in weiteren Read-Sites: nach Phase 1 (Aussichten + Monatsabschluss) wird der Abzug bei negativen Börsenpreisen jetzt auch in Cockpit-Übersicht, ROI-Dashboard, PDF-Jahresbericht, HA-Sensor-Export, Auswertungen-Energie und Auswertungen-Finanzen konsistent angewendet. Single Source of Truth: core/berechnungen/eeg.py:erloes_minus_eeg51.
Berechnungs-Layer PRIO-1-Migrationen: prognosen.py und repair.py lesen IST-PV-Ertrag jetzt über den SoT-Helper summe_pv_bkw_kwh aus core/berechnungen/energie.py (Whitelist-konsistent zu Cockpit/Aussichten/HA-Export; ADR-001). Verhindert Drift-Klasse 2026-05-19 (BKW-Bug, Rainer-PN) in Genauigkeits- und Reparatur-Pfaden.

Fixed

Cloud-Import Sungrow iSolarCloud: AppKey-Rotation entschärft (#287 detlefh68): der mitgesendete App-Key war auf einem alten Stand und wurde von Sungrow mit „Illegal c-access-key” abgelehnt. Aktualisiert auf den aktuellen Default-Wert aus dem GoSungrow-Projekt. Plus optionales Feld „App-Key” im Setup, damit bei künftiger Key-Rotation der Anwender einen eigenen Wert eintragen kann, ohne auf ein eedc-Release warten zu müssen.
Cloud-Import EcoFlow PowerOcean: echte indexName-Matrix (Dirk-PN): die in v3.32.0 hinzugefügte Diagnose hat die echten indexNames im API-Response aus Dirks Log offengelegt. Mapping um die tatsächlich gelieferten Namen ergänzt — der Import liefert jetzt Werte statt leer zu bleiben.
Investitionen löschen: stiller Disabled-Button (#288 NongJoWo): der „Endgültig löschen”-Button im Backup-Bestätigungsdialog ist by design disabled, solange weder ein Backup erstellt noch „Ohne Backup fortfahren” geklickt wurde — der Grund war im Dialog nicht sichtbar. Jetzt: dezenter Hilfetext links neben den Aktions-Buttons („Bitte oben eine Backup-Option wählen”) plus Tooltip am disabled Button.

Cloud-Import

Victron VRM: getestet=True (#255 kingcap1): nach erfolgreicher Verifizierung gegen ein echtes Konto wird der getestet=False-Banner entfernt. Der Provider ist damit vollständig produktiv.

Konzept

IA v4.0.0 — Informationsarchitektur-Konzept veröffentlicht (#243): drei orthogonale Achsen (Zeit / Was / Wie) lösen die heutige Vermischung in der Top-Navigation auf. Cockpit wird zur Zeitachse (Live · Heute · Monatsbericht · Jahr · Aussicht), Komponenten bekommen einen eigenen Hub mit Status/Verlauf/Vergleich/Aussicht-Sektionen, Auswertungen wird auf analytische Schnitte konsolidiert. Drei Konzept-Dokumente in docs/: KONZEPT-IA-V4.md, KONZEPT-STYLE-GUIDE.md (mit Hell/Dunkel-Mode + Einstellbarkeits-Cap), KONZEPT-MOBILE.md (Hamburger-Top-Nav, Pflicht-Querschnittsregeln). Feedback und Ideen sind willkommen, zentral im Issue. Code-Umsetzung folgt in v4.0.0.

[3.32.1] - 2026-05-23 — Multi-Geräte-Drift-Hardening + Tester-Fixes

🔧 Patch-Release. Schwerpunkt: Aggregations-Drift bei Anlagen mit mehreren E-Autos oder Wärmepumpen. Eine Schleife schrieb Vergleichsparameter (Vergleichsverbrauch, Vergleichspreis, Wirkungsgrad) last-write-wins in globale Variablen — alle Geräte wurden mit den Werten des LETZTEN gerechnet. Betroffen waren Aussichten, ROI-Dashboard, HA-Sensor-Export und der PDF-Jahresbericht. Plus zwei Folge-Fixes zu #286 (MonatsdatenForm-Pfad + 0-€-Positionen).

Changed

ROI-Dashboard: Benzinpreis-Auflösungs-Kette pro E-Auto (Nebenbefund #260): Der Query-Param benzinpreis_euro ist jetzt optional. Pro E-Auto-Berechnung: Slider-Override → inv.parameter['benzinpreis_euro'] → letzter Monatsdaten.kraftstoffpreis_euro (EU OB) → PARAM_E_AUTO_DEFAULTS['benzinpreis_euro']. Vorher las das ROI-Dashboard im E-Auto-Branch 7 von 8 nötigen Params aus inv.parameter (v3.25.0-Klasse), benzinpreis_euro war vergessen — Query-Default 1,85 €/L überschrieb stillschweigend gepflegte Werte. Frontend-Slider-State von Hardcode 1.85 auf undefined (leer = nicht überschreiben); Placeholder zeigt den aufgelösten Marktpreis aus der Response.
PDF-Jahresbericht: IMD vor Anschaffung / nach Stilllegung gefiltert: all_imd in pdf_operations.py wird jetzt analog aussichten.py:942 (#236, v3.29.0) mit inv.ist_aktiv_im_monat vorgefiltert. Custom-Import-Daten außerhalb der Investitions-Lebenszeit fließen damit nicht mehr in PV-Erzeugung, Speicher-Ladung, WP-Wärme und E-Mob-Aggregate des Jahresberichts ein.
Aussichten: bisherige-Ersparnis-Schleifen mit ist_aktiv_im_monat-Filter in WP, E-Auto, BKW, sonstige Positionen, Dienstlich-Ladekosten. Schließt eine Lücke nach #236 — die Quoten-/PV-Anteilsberechnung filterte bereits, die parallelen Ersparnis-Schleifen nicht. PV/BKW-Erzeugungs-Aggregation bleibt bewusst ungefiltert (Issue #123 — historische Erzeugung darf durch spätere Stilllegung nicht aus der Vergangenheit gelöscht werden).

Fixed

Aussichten: Mehrfach-E-Auto-Drift (Bug A + B + C, drei verkettete Vorkommen einer Wurzel): eauto_benzinpreis und eauto_vergleich_l_100km wurden in einer for ea-Schleife last-write-wins in globale Variablen geschrieben. Bei zwei E-Autos mit unterschiedlichen Parametern (z. B. Klein-EV 6 L/100km und SUV-EV 10 L/100km) wurden beide mit den Werten des letzten gerechnet — bisherige_eauto_ersparnis, jahres_eauto_km_ersparnis und die per-EA-KomponentenBeitragSchema-Beschreibungstexte waren entsprechend falsch. Fix: eauto_aggregate[ea.id] mit per-E-Auto-Werten, km-gewichteter Aggregat für die Saisonalprognose, per-EA-Aufschlüsselung der Komponenten-Beiträge.
HA-Sensor-Export: Mehrfach-E-Auto-Drift + Monatspreis-Fallback (calculate_anlage_sensors): selbe last-write-wins-Klasse wie in Aussichten. Davon abgeleitet: HA-Sensoren jahres_ersparnis_euro, roi_prozent und amortisation_jahre waren bei Multi-EA-Haushalten falsch. Zusätzlich fehlte der Monatsdaten.kraftstoffpreis_euro-Fallback — der Anlage-Sensor driftete dadurch auch gegen den per-Investition-Sensor e_auto_ersparnis_vs_benzin_euro (der den Monatspreis korrekt nutzt). Fix: per-EA-Lookup in der Ersparnis-Schleife + Monats-Preis-Fallback pro Monat.
PDF-Jahresbericht: Mehrfach-E-Auto-Drift + Wallbox-Falle (export_pdf): die Vergleichsparameter wurden aus der ERSTEN passenden e-auto-ODER-wallbox-Investition mit parameter gezogen (for inv … break). Bei zwei E-Autos griff nur der erste; stand zudem eine Wallbox mit irgendwelchen Parametern vor der E-Auto in der Liste, wurde die Wallbox zur Param-Quelle — obwohl vergleich_verbrauch_l_100km ein Vehicle-Attribut ist. Fix: neuer SoT-Helper km_gewichtete_eauto_params in services/eauto_wirtschaftlichkeit.py, iteriert nur über E-Autos, km-gewichtet (bei 1 EA = dessen Wert).
Aussichten + HA-Export + PDF-Jahresbericht: Mehrfach-Wärmepumpe-Drift: gleiche Klasse wie E-Auto, aber für WP-Vergleichsparameter (alter_preis_cent_kwh, alter_energietraeger/Wirkungsgrad). Bei zwei WPs mit unterschiedlichen Energieträgern (Gas + Öl) wurde die Gas-WP mit dem Öl-Wirkungsgrad gerechnet — alte Heizungskosten ~5,5 % zu hoch angesetzt. pdf_operations.py hatte zusätzlich break → wp_alternativ_zusatzkosten_jahr summierte nicht über alle WPs. Fix: wp_aggregate-Dict pro WP, thermisch-gewichtetes Mittel für Aggregat-Werte in der Jahresprognose.
Monatsabschluss: sonstige Positionen über MonatsdatenForm wieder löschbar (#286 rcmcronny): Der v3.32.0-Fix (50706fe7) deckte nur den Wizard ab — MonatsdatenForm (Tabellen-Edit) hatte exakt denselben Bug. Bei leerer Positionen-Liste wurde der Sub-Key nicht ins Payload aufgenommen, der Backend-Helper _save_investitionen_monatsdaten ließ den Sub-Key unangetastet, die alte Liste blieb in der DB. Fix: initialHattePositionen-Spur + Submit schickt sonstige_positionen: [] als explizites Löschsignal; 0-€-Filter raus (rilmor-Klasse). +3 Akzeptanztests für beide Wege.
Monatsabschluss: 0-€-Positionen werden gespeichert (#286 rilmor-mhrs): der betrag > 0-Filter im Frontend (MonatsabschlussWizard.tsx:493) und Backend (monatsabschluss/wizard.py:330) verwarf 0-€-Positionen mit Bezeichnung stillschweigend. Neuer SoT-Helper ist_gueltige_position in utils/sonstige_positionen.py (Kriterium: nur Bezeichnung nicht leer); Backend importiert, Frontend gelockert.
E-Auto-Dashboard: Benzinpreis pro Monat aus EU-OB (#260 NongJoWo): get_eauto_dashboard summierte km gesamt und multiplizierte einmal mit einem Query-Default 1,65 €/L — die Cockpit-Übersicht rechnete dagegen seit v3.17.0 pro Monat mit Monatsdaten.kraftstoffpreis_euro. Resultat: 2696 € vs. 2375 € für dieselbe Anlage. Neuer SoT-Helper berechne_eauto_ersparnis_periode in services/eauto_wirtschaftlichkeit.py (Σ km_monat × verbrauch × preis_monat); Query-Param entfernt (war effektiv tot).
Monatsabschluss-Wizard: doppeltes „Sonstiges” in der Stepper-Leiste (Rainer-PN): bei einer typ='sonstiges'-Investition hieß sowohl der Investitionstyp-Schritt als auch der nachfolgende OPTIONALE_FELDER-Schritt „Sonstiges”. Fix: der hintere Schritt heißt „Allgemein” (typ-übergreifend); bei genau einer sonstiges-Investition wird deren bezeichnung als Stepper-Titel verwendet.

Cloud-Import

Victron VRM gegen die echte API neu gebaut (#255): der v3.32.0-Provider war ein erster Wurf — der neue ruft /users/me+installations für die Discovery, mappt die Energiefluss-Matrix korrekt auf Monatswerte und chunked in 24-Monats-Blöcken. getestet=False-Banner bleibt vorerst; Verifizierung über kingcap1/FrodoVDR-Konten erbeten.
EcoFlow PowerOcean/PowerStream: Diagnose-Log für indexNames: bei leerem Cloud-Import schreibt eedc jetzt die tatsächlichen indexNames pro Block ins INFO-Log und gibt ein WARNING aus, wenn die API zwar antwortet, aber keiner der bekannten Index-Namen zutrifft — vereinfacht künftige Mapping-Erweiterungen.

[3.32.0] - 2026-05-22 — Victron-VRM-Cloud-Import + Fix-Bündel

✨ Feature-Release. Neu: ein Cloud-Import-Provider für das Victron VRM Portal. Dazu ein Bündel Fehlerbehebungen — ROI-Dashboard-Absturz, nächtlicher Scheduler-Crash, EcoFlow-History-Import und zwei Fehlalarme rund um Speicher-Kennzahlen.

Added

Victron VRM Cloud-Import (#255): neuer Cloud-Import-Provider holt historische Monatswerte (PV-Erzeugung, Einspeisung, Netzbezug, Batterie) direkt aus dem Victron VRM Portal — für das Nachholen von Daten aus der Zeit vor der HA-Anbindung. Anmeldung per Access-Token (im VRM-Portal unter Preferences → Integrations erzeugt), kein Passwort, kein Admin-Recht nötig. Der Live-Pfad (HA-Add-on + ha-victron-mqtt) bleibt unberührt. Der Provider ist noch nicht final mit echten Konten getestet (getestet=False).

Changed

Speicher-Effizienz-Chart auf gleitende 12 Monate (rapahl-PN): die Monats-Effizienz Entladung/Ladung konnte über 100 % anzeigen — pro Monat ist das durch den Ladestands-Übertrag legitim, als Kennzahl aber irreführend. Das Chart zeigt jetzt die gleitende 12-Monats-Effizienz (Carry-over-immun); eine neue Berechnungs-Invariante prüft Σ Entladung ≤ Σ Ladung kumulativ.

Fixed

ROI-Dashboard-Absturz (#285): das ROI-Dashboard zeigte „Ein Fehler ist aufgetreten” und ließ sich nicht öffnen — gleiche Fehlerklasse wie der Speicher-Cockpit-Absturz in v3.31.8 (installationsdatum statt anschaffungsdatum), an zwei weiteren Stellen. Behoben + Regressionstests. Mit Dank an Klausnn für die Meldung.
Nächtlicher Scheduler-Crash (#286): ein Hintergrund-Job brach nachts mit einem Fehler ab — Ursache war ein falsch genutzter Datenbank-Kontext an zwei Job-Stellen. Behoben. Mit Dank an rcmcronny für die Meldung.
Monatsabschluss: sonstige Positionen wieder löschbar (#286): sonstige Kostenpositionen ließen sich im Monatsabschluss nicht mehr entfernen. Behoben.
EcoFlow History-Import (Dirk-PN): der Cloud-Import scheiterte mit time must be less than one week. Die EcoFlow-API verlangt ein Abfragefenster von strikt weniger als einer Woche — eedc fragt jetzt in 6-Tage-Blöcken ab. Historische Daten beliebigen Alters lassen sich damit importieren.
Daten-Checker: Netzladung-Fehlalarm (rapahl-PN): der Daten-Checker meldete „Netzladung übersteigt Gesamtladung”, obwohl die Differenz nur ein harmloser Effekt an der Monatsgrenze war (Akku-Nachtladung über Mitternacht). Die Prüfung erfolgt jetzt kumulativ über die gesamte Historie — ein echter Erfassungsfehler wird weiterhin erkannt.

[3.31.8] - 2026-05-22 — Bündel-Release: Speicher-Cockpit-Fix + EcoFlow-Import + WP-Saison-Politur

🔧 Patch-Release. Behebt einen Absturz der Cockpit-Rubrik „Speicher” (Regression aus v3.31.7), repariert den EcoFlow-PowerOcean-Cloud-Import und setzt vier Feedback-Punkte zum WP-Saisonvergleich um (rapahl-PN).

Changed

WP-Saisonvergleich heizungsbereinigt (#195, rapahl-PN): Bei getrennter Strommessung rechnet der Saison-Vergleich (Strom & JAZ) jetzt nur noch die Heizung — Warmwasser läuft ganzjährig ~konstant und verwässerte den Heizperioden-Vergleich. Ohne getrennte Messung unverändert der Gesamtwert. Neue Fußzeile nennt Saison-Fenster, Anzahl der Monate und die verwendete Strom-Basis.
WP-Saisonvergleich — Darstellung: vertikale Hilfslinien im Monats-/Saison-Vergleich entfernt (störten im Dark Mode); Summen-Labels größer und in hellem wie dunklem Theme gut lesbar.

Fixed

Cockpit-Rubrik „Speicher” — Absturz behoben (rapahl-PN): die Speicher-Ansicht im Cockpit zeigte „Ein Fehler ist aufgetreten” und ließ sich nicht öffnen. Regression aus der Etappe-C-UI in v3.31.7 — get_speicher_dashboard griff auf das nicht existierende Feld installationsdatum zu (das Investition-Model hat anschaffungsdatum). Behoben + Regressionstest, der den Endpoint jetzt direkt mit einer echten Investition prüft.
EcoFlow PowerOcean Cloud-Import: Signaturfehler behoben (Dirk-PN): signierte Requests scheiterten mit code=8521 signature is wrong; Ursache war ein fehlerhaft gesetzter Content-Type-Header. Der Cloud-Import funktioniert damit wieder.

[3.31.7] - 2026-05-21 — Bündel-Release: Prognose-Korrektur + Community-Fehlermeldungen + Backup-Abfrage

🔧 Patch-Release. Schwerpunkt: die Prognose-Korrektur (Lernfaktor + wetterabhängiges Korrekturprofil) wurde überprüft und auf den zentralen Berechnungs-Layer (ADR-001) gezogen. Dazu feldgenaue Fehlermeldungen beim Community-Teilen (#282), eine Backup-Abfrage vor dem Löschen (#283) und die Cockpit-Kacheln der Speicher-Wirtschaftlichkeit Etappe C (#264).

Added

Speicher-Wirtschaftlichkeit — Etappe C-UI (#264): die in v3.31.6 (C-Backend) angekündigten Cockpit-Kacheln — dynamischer Ladepreis aus TEP-Stundenwerten, SoC-korrigierter Wirkungsgrad — sind jetzt im Speicher-Dashboard sichtbar.
Backup-Abfrage vor destruktiven Aktionen (#283, PR von stlorenz): Bestätigungsdialog (DestructiveActionDialog) mit Backup-Erinnerung vor dem Löschen von Anlage/Komponente; Lösch-Fehler werden im Dialog sichtbar gemacht.

Changed

Lernfaktor-IST über den Berechnungs-Layer (live_wetter._filtere_tage): die IST-Ermittlung für den Lernfaktor nutzt jetzt den SoT-Helper summe_pv_bkw_kwh (Whitelist pv_/bkw_, core/berechnungen/energie.py) — dieselbe Quelle wie Daten-Checker und Genauigkeits-Tracking. +5 Akzeptanztests.
Investitionen-Dashboards in eigenes Modul (api/routes/investitionen/dashboards.py): verhaltenserhaltender Refactor.

Fixed

Korrekturprofil: Day-Ahead-Stundenprofil bleibt über die Tagesaggregation erhalten (aggregate_day): Das Delete-and-Recreate der TagesZusammenfassung rettete bisher nur die fünf Skalar-Prognosefelder — pv_prognose_stundenprofil / solcast_prognose_stundenprofil fehlten in der Rettungsliste und gingen jede Nacht verloren, die Korrekturprofil-Heatmap blieb dadurch leer. Rettungsliste jetzt als Konstante _PROGNOSE_FELDER_RETTEN (alle 7 Prognosefelder). Wirkt vorwärts. +3 Akzeptanztests.
Community-Server: Fehler 422 mit Feld-Detail (#282, SlapJackNpNp): das feldgenaue Pydantic-Detail wird jetzt lesbar in der UI angezeigt statt einer generischen Meldung.
Daten-Checker: toter „Beheben”-Link + Zukunfts-Stub-Fehlalarm: ein Reparatur-Link zeigte auf eine veraltete Route; Tage in der Zukunft wurden als Datenlücke fehlinterpretiert.
Lösch-Fehler im DestructiveActionDialog werden im Dialog angezeigt statt still verschluckt.

[3.31.6] - 2026-05-20 — Bündel-Release: E-Mobilitäts-Pool-Konsistenz + Saison-Vergleich + Daten-Checker

🔌 E-Mobilitäts-Sichten zeigen wieder dieselben Zahlen. junky84 (#262) meldete nach v3.31.5 vier verschiedene Werte für dieselbe evcc-Ladung: Cockpit-E-Auto 4127 kWh / 48 % PV (korrekt), Wallbox-Dashboard 5278 / 38 %, Auswertungen-Komponenten 4130 mit PV 48 % + Netz 85 % = 133 % (mathematisch unmöglich). Ursache: vier Read-Sites poolten E-Auto- + Wallbox-IMD mit feldweisem max(eauto_X, wb_X) — drei unabhängige max()-Aufrufe für gesamt/pv/netz konnten die Felder aus verschiedenen Quellen mischen, das Tripel war intern inkonsistent. Nur das E-Auto-Dashboard war korrekt (poolt über compute_emob_pool_attribution eine ganze Quelle). Fix: SoT-Helper aggregiere_emob_ladung — die Quelle mit der größeren Heimladung gewinnt die komplette, in sich konsistente Trias (pv + netz == ladung garantiert); alle Sichten rufen ihn auf. Plus #195-Abschluss (Saison-Vergleich), #613-Daten-Checker-Fix und ein PVGIS-Systemverluste-Drift-Refactor.

Added

Wärmepumpe: Saison-Toggle im Monatsvergleich (#195 Punkt 2): Das WP-Cockpit kann den Monatsvergleich auf Saison-Fenster umstellen — neue SAISON_FENSTER-Konstante in lib/constants.ts (Winter Nov–Feb / Heizperiode Okt–Apr / Sommer Jun–Aug). Achsen-Toggle Monate/Saison + Fenster-Selektor, Saison-Instanzen auf der X-Achse, kein Jahresfilter (Cockpit-vs-Auswertung-Grenze).
Auswertung: Vergleichsjahr-Absolutwert in der Tabelle (#195 Punkt 1): Die Auswertungs-Tabelle zeigt das Vergleichsjahr zusätzlich als absoluten kWh-/€-Wert statt nur als Differenz zum aktuellen Jahr.
Energieprofil-Tagestabelle: Komponenten-Spalten: zusätzliche Spalten für die einzelnen Komponenten (Speicher, Wärmepumpe, E-Mobilität) in der Tages-Tabelle.
Speicher-Wirtschaftlichkeit — Etappe C-Backend (#264, PR #278 von stlorenz, maintainer-rebased + reviewt): dynamischer Ladepreis aus den TEP-Stundenwerten + SoC-korrigierter Wirkungsgrad statt Parameter-Durchschnitt. Die Frontend-KPIs (Etappe C-UI) folgen in einem Nachgang-Release. Zwei Review-Nits gefixt (Funktionen aus dem Import-Block geholt, stilles except: pass → logger.warning).

Changed

E-Mobilitäts-Pool zentralisiert (#262): neuer SoT-Helper aggregiere_emob_ladung in services/eauto_wirtschaftlichkeit.py ersetzt feldweises max() in vier Sichten (Wallbox-Dashboard, Komponenten-Zeitreihe, Cockpit-Übersicht, aktueller_monat._collect_saved_data). Die Quelle mit der größeren Heimladung gewinnt die komplette (gesamt, pv, netz)-Trias — pv + netz == ladung ist garantiert. Externe Ladung kommt paarweise (kWh, €) aus der Quelle mit den höheren Extern-Kosten. Das E-Auto-Dashboard bleibt unverändert (compute_emob_pool_attribution, selbe use-wb-pool-Entscheidung → konsistent). Netto −155 Zeilen duplizierte Pool-Logik. Neun neue Tests in test_emob_pool_konsistenz.py.
PVGIS-Systemverluste zentralisiert: DEFAULT_SYSTEM_LOSSES = 0.14 war 5× definiert, die Auflöse-Zeile pvgis.system_losses / 100 if … else … stand 6× parallel. Zentralisiert in services/pv_orientation.py (DEFAULT_SYSTEM_LOSSES + resolve_system_losses(pvgis)). Verhaltenserhaltender Refactor, vier neue Unit-Tests. Memory-Linie feedback_aggregations_drift.
PV-Prefix-Whitelist im Frontend konsolidiert: die PV-Komponenten-Prefix-Liste wird im Frontend jetzt aus einer Stelle gelesen — Analogon zum Backend-Berechnungs-Layer (ADR-001).
docs/KONZEPT-WALLBOX-EAUTO.md aktualisiert: Pool-Konsolidierung dokumentiert; Phase 2 in 2a (Feldzuordnung geradeziehen, schulden-getrieben — Trigger durch das evcc-Import-Churn gefeuert) und 2b (Vehicle-Sensor-Mapping, feature-getrieben) gesplittet; neuer Abschnitt »Phase-2-Trigger«.

Fixed

E-Mobilität: vier Sichten zeigten verschiedene Lade-Zahlen (#262, junky84): siehe Intro — feldweises max() über getrennte E-Auto-/Wallbox-Töpfe erzeugte intern inkonsistente (gesamt, pv, netz)-Tripel, in Extremfällen PV-Anteil > 100 %. Behoben durch den aggregiere_emob_ladung-Gewinner-Pool.
Daten-Checker: stillgelegte Investition im LTS-Check (#613, MartyBr-Forum-Meldung): _check_sensor_mapping_lts flaggte den kWh-Sensor einer stillgelegten Investition weiter als „nicht in HA-LTS”. Der #608-Stilllegungs-Sweep aus v3.31.5 hatte diesen Pfad übersehen, weil die Funktion das sensor_mapping-JSON-Dict iteriert statt anlage.investitionen. Fix + Akzeptanztest.
UI: SOLL/IST → IST/SOLL Label-Korrektur (rapahl-PN): vertauschte Spalten-Beschriftung korrigiert.

[3.31.5] - 2026-05-19 — Bündel-Release: BKW-Doppelzählung weg + Berechnungs-Layer (ADR-001) + Tester-Bündel

🧮 Strukturelle Antwort auf die BKW-Drift-Klasse. Rainer-PN 2026-05-19 zeigte eine systematische IST-Über-Erfassung (~5-8 % Bias gegenüber Solcast) bei einer Anlage mit Balkonkraftwerk. Diagnose: TV_SERIE_CONFIG["balkonkraftwerk"].kategorie = "pv" ließ den Live-Tagesverlauf-Service den BKW-Wert unter pv_<inv_id> akkumulieren, der HA-LTS-Boundary-Aggregator nutzt aber bkw_<inv_id>. Bei Schema-Mismatch blieben beide Keys parallel in komponenten_kwh, alle Konsumenten mit Whitelist ("pv_", "bkw_") zählten BKW doppelt. Strukturelle Lösung statt Pflaster: Live-Σ-Riemann-Akkumulation für komponenten_kwh ist im HA-Add-on-Modus jetzt komplett deaktiviert — boundary_kwh (HA-LTS) ist alleiniger Schreiber. Damit ist die ganze Bug-Klasse strukturell weg, nicht nur das eine Symptom. Plus: neuer Berechnungs-Layer backend/core/berechnungen/ als SoT für Aggregat-Helper, Pytest-Konformitäts-Test blockiert künftige Whitelist-Duplikate, Pflicht-Invariante im Aggregator loggt Schreib-Drift sofort.

Added

Berechnungs-Layer backend/core/berechnungen/ als Single Source of Truth (ADR-001, Konzept): Whitelist-Konstanten, Σ-Helper und Konsistenz-Invarianten leben jetzt in einem eigenen Layer statt verteilt über Domain-Module. Submodule:
- energie.py — PV_KOMPONENTEN_PREFIXE + summe_pv_bkw_kwh (SoT für Aggregat aus TagesZusammenfassung.komponenten_kwh)
- invarianten.py — pruefe_tep_tz_konsistenz / assert_tep_tz_konsistent (Σ Hourly == Daily über pv_kw ↔ komponenten_kwh[pv_*, bkw_*])
- __init__.py mit Re-Exports Erster migrierter Konsument: services/daten_checker.py (_summe_pv_bkw_kwh ist jetzt ein Re-Import statt eigener Definition). Weitere Konsumenten (prognosen.py, repair.py u. a.) werden step-by-step beim nächsten Touch migriert — siehe INLINE_PATTERN_GRANDFATHERED in tests/test_berechnungs_layer_konformitaet.py.
Pytest-Konformitäts-Test (tests/test_berechnungs_layer_konformitaet.py): drei Schichten Pflichten-Test — ("pv_", "bkw_")-Tuple und startswith("pv_") or startswith("bkw_")-Inline-Pattern dürfen nur in core/berechnungen/ stehen (mit Grandfathered-Whitelist für die bekannten Altlasten); zusätzlich „veraltete Grandfathered-Einträge”-Check, der schlägt an, wenn eine Datei das Pattern nach Migration nicht mehr enthält — verhindert Karteileichen.
Pflicht-Invariante im Aggregator (energie_profil/aggregator.py::aggregate_day): nach jedem Schreib-Lauf wird pruefe_tep_tz_konsistenz(tep_rows, zusammenfassung.komponenten_kwh) aufgerufen. Verletzung wird als Warning geloggt — kein Tag wird zurückgehalten, aber Drift ist im Add-on-Log sofort sichtbar (statt erst Wochen später durch Anwender-Meldungen).
Daten-Checker: PR-Plausibilitäts-Check für PV-Doppelerfassung (rapahl-PN, Etappe-6-Erweiterung): neuer Check _check_pv_ueber_erfassung meldet, wenn die Performance Ratio an ≥ 3 von ≥ 20 % der PR-Tage über 1,05 liegt oder der spezifische Tagesertrag > 7 kWh/kWp an ≥ 3 Tagen erreicht. Diagnose-Charakter, keine automatische Reparatur. 10 Akzeptanztests in test_daten_checker_pv_ueber_erfassung.py. Memory-Linie feedback_grenze_externe_daten_diagnose.
Prognose-Vergleichs-Tab: 4 Tage zurück + 3 Tage vorwärts (rapahl-PN): die 7-Tages-Tabelle zeigt jetzt 4 historische Tage (aus genauigkeit.tage mit echtem IST + gespeicherten Prognosen) plus 3 zukünftige Tage. Trennlinie zwischen Vergangenheit und Zukunft; historische Zeilen ohne Wetter-Icon/Solcast-Konfidenzband.
Cloud-Import: Backend-Fehler im Wizard sichtbar: bei fehlgeschlagenem Verbindungstest zeigt der Wizard jetzt den vollen testResult.fehler-Text in einem roten Detail-Block mit Monospace-Schrift — bisher wurde die konkrete API-Antwort verschluckt zugunsten eines generischen „Verbindung fehlgeschlagen”. EcoFlow-PowerOcean-Connector zusätzlich mit ausführlichem Diagnose-Logging vor jedem Return (HTTP-Status, Body-Auszug, Hersteller-code/message). Trigger: Dirk-PN.

Changed

Aggregator-Mode-Switch: Live-Σ-Riemann nur noch im Standalone-Modus (energie_profil/aggregator.py:358-368): die Live-Akkumulation pro Stunde (kW × 1h = kWh über werte-Keys) läuft im HA-Add-on-Modus (kwh_source_label == "external:ha_statistics:hourly") NICHT mehr — boundary_kwh (HA-LTS) ist alleiniger Schreiber für komponenten_kwh. Etappe-4-Komplettierung: der Riemann-Pfad-Rückbau, der im ursprünglichen v3.31.0-Release laut Konzept-Doc geplant war, ist jetzt strukturell vollzogen. Im Standalone-Modus (kein HA-LTS) bleibt der Live-Pfad als Pfad-2-Fallback aktiv.
docs/KONZEPT-DATENPIPELINE.md Abschnitt 3.5 ergänzt um Berechnungs-Layer-Verweis; docs/KONZEPT-COUNTER-DAILY-DRIFT.md als Sub-Konzept des Berechnungs-Layers verankert; docs/KONZEPT-DATENCHECKER-KONSISTENZ.md mit Querverweis, dass Achse-A/B/C-Refactor core/berechnungen benutzen MUSS.

Fixed

Stilllegungs-Filter in kWp-Summe + Sensor-Mapping-Check + Inbetriebnahme-Monat (#608, Steffen2-PN): die stillgelegte Dachanlage trotz Stilllegungs-Datum (a) wurde in der Modul-kWp-Summen-Anzeige des Daten-Checkers mitgezählt → führte zur Warnung „PV-Module kWp stimmt nicht mit Anlagenleistung überein”, obwohl die echte Anlagenleistung korrekt war, (b) wurde im Sensor-Mapping-Vollständigkeits-Check als „fehlt” gemeldet, (c) der Inbetriebnahme-Monat (Monat vor Stilllegung) wurde als Datenlücke fehlinterpretiert. Alle drei behoben durch ist_aktiv_an(heute)-Filter analog zu den Read-Sites in v3.29.x. Acht Akzeptanztests in test_daten_checker_stilllegung.py + test_daten_checker_vorjahr_inbetriebnahme.py.
Daten-Checker: Reparatur-Werkbank-Link im Provenance-Konflikt-Eintrag (Steffen2-PN): das Daten-Checker-Eintrag „14 Felder mit mehreren Quellen in den letzten 30 Tagen — der Resolver hat schon entschieden, die Reparatur-Werkbank kann sie aufdröseln” enthielt bisher keinen link, deshalb keinen „Beheben”-Button. Link auf /einstellungen/energieprofil (Reparatur-Werkbank ganz unten) jetzt im CheckErgebnis.
Daten-Checker: Route-Korrektur /aussichten/energieprofil → /einstellungen/energieprofil an drei Stellen (Reparatur-Werkbank-Link aus dem vorherigen Fix + zwei ältere Counter-Spike-/Drift-Links). Die alte Route gibt’s nicht — die SubTabs-Kategorie ist „Daten” unter Einstellungen.
E-Mobilität: Pool-vs-Komponente-Drift bei evcc-Setups (#260 Folge nach v3.31.3): die Cockpit-Komponenten-Sicht und die Aktueller-Monat-Sicht zeigten unterschiedliche Ersparnisse für dasselbe E-Auto bei mehreren Wallbox-Sessions pro Monat. Ursache: inkonsistente Aggregation über mehrere Komponenten — der Pool-Helper aus #260 wurde nicht überall sauber durchgereicht. Fünf neue Akzeptanztests in test_emob_pool_komponenten.py.
Custom-Import: Einheits-Konvertierung Wh/MWh → kWh + Legacy-Top-Level-Targets (#229 JanKgh-Folge): CSV-Import-Pipeline konvertiert jetzt automatisch von Wh oder MWh nach kWh, falls die Quelldatei nicht-kWh-Einheiten verwendet (typisch z. B. bei Solarmanager-Exporten). Zusätzlich akzeptiert die Mapping-Logik auch ältere Top-Level-Spalten-Namen aus früheren eedc-Versionen, ohne Wizard-Rename. Vier neue Akzeptanztests in test_custom_import_einheit_non_energy.py.

Removed

backend/services/daten_checker.py:_summe_pv_bkw_kwh als eigene Definition: ersetzt durch Re-Import aus backend.core.berechnungen (semantisch identisch, Migration zum SoT-Layer). Externe Aufrufer ändern sich nicht.

Internal

Test-Aufräumen Plan E: zentrale db-Fixture in backend/tests/conftest.py, 18 Test-Dateien migriert, alle _session_ctx-Definitionen + 14 Standalone-__main__-Runner entfernt. Sonderfälle: test_repair_orchestrator.py hat lokale autouse-Fixture für _reset_state_for_tests(), test_lts_aggregator_konsistenz.py nutzt inline db=None (LTS-Pfad braucht keine echte Session). −712 Netto-Zeilen.
Konzept-Pflege: 7 abgeschlossene Konzepte ins docs/archive/ verschoben (KONZEPT-ETAPPE-4-HA-LTS-SOT, KONZEPT-ETAPPE-6-DRIFT-ANZEIGE, KONZEPT-INFOTHEK, KONZEPT-KORREKTURPROFIL, KONZEPT-MQTT-GATEWAY, KONZEPT-PROGNOSEQUELLEN-WAHL, KONZEPT-STROMPREIS-MITSCHRIFT), Forum-Post-Entwurf forum-post-iobroker-mqtt.md ebenfalls archiviert, KONZEPT-ENERGIEPROFIL-3C ins Archiv nach Re-Audit (Drift-Befunde gegen 3d/4/5/6-Stand geprüft). Neu: KONZEPT-DATENCHECKER-KONSISTENZ.md als geparktes Konzept für die Daten-Checker-Aufräumung.
Roadmap (#110) auf v3.31.5-Stand aktualisiert: neuer Geplant-Punkt „Berechnungs-Layer step-by-step Migration”, neuer In-Arbeit-Punkt „Komponenten-Drill-down in der Energieprofil-Tagestabelle” (Rainer-Wunsch).

Tests

256/256 grün (253 Stand vor Session + 3 neue Konformitäts-Tests; die 2 obsoleten BKW-Pflaster-Tests sind im strukturellen Fix gelöscht worden).

Verhalten / Memory

Heute zweimal in die „User verdächtigen statt eigenen Code prüfen”-Falle gelaufen (Steffen2 + Rainer) bevor Code-Audit den BKW-Bug fand. Neue Memory-Linie feedback_eigenen_code_zuerst adressiert das Reflex-Pattern; feedback_aggregations_drift erweitert um Write-Side-Variante (zwei parallele Schreiber auf demselben JSON-Feld); feedback_step_by_step_berechnungs_layer formalisiert die Migrations-Disziplin.

[3.31.4] - 2026-05-18 — Bündel-Release: Security-Hardening + Speicher-Etappe A/B + Tester-Beiträge

🔐 Sicherheits-Härtung als Schwerpunkt. Drei Schichten gegen typische Angriffsvektoren in selbst-gehosteten Apps: Credential-Maskierung deny-by-default, SSRF-Schutz im Connector-Test gegen Loopback/Link-Local/Multicast-Ziele (inkl. DNS-Rebinding), und das curl | bash-Anti-Pattern aus der Setup-Anleitung ersetzt durch curl → less → bash. Plus zwei Etappen aus Stefans Speicher-Konzept (laedt_aus_netz-Schalter + Speicher-Wirtschaftlichkeit mit PV-/Netz-Anteil), klarere README für den Standalone-Modus, und ein Pool-Drift-Fix für die E-Mob-Auswertung beim evcc-Import.

Security

Credential-Maskierung deny-by-default (PR #275): Provider-aware Detection für sensible Eingabefelder — alles mit type="password" plus Substring-Heuristik für ungewöhnlich benannte Token-Felder. Eingaben in Logs, Debug-Outputs und Connector-Test-Antworten werden vor der Weitergabe maskiert. Neun Akzeptanztests, deny-by-default-Linie statt allow-list (sicher ist sicher; lieber ein nicht-sensibles Feld maskieren als ein sensibles übersehen).
SSRF-Schutz im Connector-Test (PR #275): /api/connector/test und /api/connector/setup lösen jetzt vor jedem ausgehenden Request den Ziel-Hostnamen via getaddrinfo auf und prüfen jede IP mit ipaddress.is_loopback / is_link_local / is_multicast / is_unspecified / is_reserved. Loopback-Ziele (127.0.0.0/8, ::1), Link-Local (169.254.0.0/16), Multicast, IPv4/IPv6-Mapped-Adressen und private Bereiche werden geblockt. DNS-Rebinding-Schutz durch Re-Resolve direkt vor dem Connect. 21 Akzeptanztests.
curl | bash aus der Setup-Anleitung entfernt (PR #275): docs/SETUP_DEVMACHINE.md zeigt jetzt explizit das curl -fsSL -o /tmp/eedc-setup.sh … && less /tmp/eedc-setup.sh && bash /tmp/eedc-setup.sh-Pattern mit Sicherheitshinweis zur Begründung. Pipe-to-shell wird in keiner offiziellen Anleitung mehr empfohlen.
Setup-Skript ohne automatische Maintainer-Identität: docs/setup-devmachine.sh setzte bei fehlender Git-Identität automatisch Platzhalter-Werte des Maintainers (git config --global user.name "supernova1963"). Das ist raus — Skript gibt jetzt nur einen Hinweis mit Platzhalter-Anleitung aus, jeder Nutzer trägt seine eigene Identität ein.
Standalone-README: LAN-Only + kein Auth-Layer-Roadmap-Versprechen (PR #276 + #277): README.md macht für den Standalone-Modus explizit klar, dass die App als LAN-Only-Setup konzipiert ist. Für öffentliche Erreichbarkeit verweist sie auf etabliertes Standard-Tooling (nginx + Basic-Auth, OAuth2-Proxy, Cloudflare Access, Tailscale Funnel). Ein eigener Auth-Layer im Container ist bewusst nicht auf der Roadmap — Standard-Werkzeuge lösen das Problem nachweislich besser als eine selbstgebaute In-App-Implementierung. Im HA-Add-on-Modus liegt der Auth-Layer bei Home Assistant. Memory-Linie feedback_externer_druck_reflex.md.

Added

Speicher Etappe A: Erfassungs-Schalter laedt_aus_netz (PR #269 stlorenz, Issue #264): Neuer Boolean pro Speicher-Investition, ob der Speicher überhaupt aus dem Netz lädt (z. B. für Arbitrage bei dynamischen Tarifen) oder rein PV-getrieben. Erfassung im Investitions-Formular, Default false. Vorbereitung für die Wirtschaftlichkeits-Berechnung in Etappe B.
Speicher Etappe B: Wirtschaftlichkeit mit PV-/Netz-Anteil (PR #271 stlorenz, Issue #264): ROI-Berechnung berücksichtigt jetzt den PV- vs. Netz-Anteil der Speicher-Ladung. Bisher wurden alle Ladungen mit Bezugspreis bewertet — bei Speichern mit Netzladung (z. B. Tibber-Optimierung) realistisch, bei rein-PV-Speichern systematisch zu negativ. Drift-Audit-D-Wrapper konsolidiert die Aggregations-Logik mit den anderen Wirtschaftlichkeits-Pfaden. Memory-Linie feedback_aggregations_drift.md. Etappe C (TEP-Lookups + SoC-korrigierter η) folgt mit dem nächsten Release zusammen mit dem Frontend-PR.

Fixed

E-Mobilität: ladung_netz_kwh-Drift bei evcc-Import (#262 junky84-Folge nach v3.31.3): junky84 meldete nach v3.31.3 weiter unstimmige Werte — Wallbox-Dashboard zeigte PV-Anteil 100 %, Netzladung 0 kWh trotz Netzbezug-Werten. Ursache: evcc-CSV liefert nur total + pv-%, das abgeleitete Feld ladung_netz_kwh wurde beim Import nie geschrieben. Acht Read-Sites (Investitionen, Cockpit-Übersicht, Cockpit-Komponenten, aktueller Monat, HA-Export, PDF-Jahresbericht u. a.) lasen das fehlende Feld direkt und kamen auf 0. Fix per zwei Schichten: (1) Import-Site in data_import.py schreibt jetzt ladung_netz_kwh = max(0, total - pv) mit, (2) neuer SoT-Helper get_emob_pv_netz_kwh() in field_definitions.py mit demselben Fallback für Bestandsdaten, alle acht Read-Sites umgestellt. Mathematisch validiert gegen Gernots HA-Template-Helper (evcc_helper_pv_charged_kwh + evcc_helper_net_charged_kwh machen exakt dieselbe Rechnung) und gegen reale evcc-CSV (5 Sessions, 80 kWh total, Σ PV 65,97 kWh, abgeleitet Netz 14,05 kWh). Fünf neue Akzeptanztests in test_dashboards_evcc_pool_fallback.py. Memory-Linie feedback_aggregations_drift.md.
EVCC-Import: DE- und EN-Header-Erkennung + Sprach-Hinweis (PR #268 stlorenz): EVCC-CSV-Export ist je nach Web-UI-Sprache deutsch oder englisch (Sitzungen vs. Sessions, Energie vs. Energy). Der Parser akzeptierte bisher nur die deutsche Variante. Beide Sprachen werden jetzt erkannt; bei dritter Sprache erscheint ein klarer Hinweis im Import-Dialog.
E-Mobilität: ist_dienstlich-Feld String-Drift-tolerant lesen (PR #270 stlorenz): Der Boolean-Schalter „Dienstwagen” wurde teils als String ("true"/"false"), teils als echtes Bool gelesen. Aufrufer in der Ersparnis-Berechnung interpretierten String-Werte teils unterschiedlich. Helper _ist_dienstlich(inv) normalisiert beide Repräsentationen.
Daten-Checker: NameError nach Merge-Konflikt #270 ↔ v3.31.3 (PR #274): Beim Merge des ist_dienstlich-Refactors wurde im neu hinzugefügten WP-Block die param-Variable referenziert, die im selben PR durch den Refactor weggefallen war (NameError, 500 auf /api/check). Drei Akzeptanztests verifizieren, dass der gesamte Check-Pfad durchläuft.
Cockpit: Spezifischer Ertrag bei „alle Jahre” + historischen Größenänderungen (PR #273 stlorenz): KPI „Spezifischer Ertrag” im „alle Jahre”-Filter mittelte über die aktuelle Anlagenleistung — bei nachträglichen Erweiterungen (Modul hinzu) wurde die Anzeige für historische Jahre verzerrt. Mittlung läuft jetzt periodengenau pro Jahr gewichtet über die zum jeweiligen Zeitpunkt installierte Leistung.

Changed

eedc/eedc.db nicht mehr getrackt + DB global gitignoret: Die SQLite-Stub-Datei (0 Bytes, Release-Skript-Artefakt aus v3.19.0) wurde aus dem Repository entfernt und *.db / *.sqlite / *.sqlite3 global in .gitignore ergänzt — verhindert versehentliches Einchecken künftiger DB-Stände. Plus: WAL/SHM-Backup-Begleitdateien (*.db-wal, *.db-shm) ebenfalls ignoriert (PR #272 stlorenz).
SFML-Stats-Plattform-Korrektur im archivierten Konzept (docs/archive/KONZEPT-ML-PROGNOSE.md): In der archivierten Datei stand, SFML Stats laufe nur auf x86_64 und EEDC schließe die Lücke auf ARM/Pi. Beide Aussagen sind falsch — SFML Stats läuft auf beiden Architekturen. Korrektur-Block am Dateianfang mit Datum und Hinweis-Quelle (SFML-Entwickler Tom-HA / Zara-Toorox).

Tests

220/220 grün — Suite wächst von 151 auf 220 (+ 69 neue Akzeptanztests durch die Security-Hardening-Pakete, Etappe A/B-Tests und die evcc-Drift-Akzeptanz).

Hinweis für Anwender

Repo-Klone vor diesem Release: durch History-Rewrites im Laufe des Tages (Bereinigung von Artefakten aus älteren Releases) divergieren bestehende lokale Klone. Wer den Repository-Stand neu pullen will, sollte git fetch && git reset --hard origin/main ausführen. Für HACS-Add-on-Nutzer ohne lokalen Klon ändert sich nichts — das Update zieht den aktuellen Tag-Inhalt.

[3.31.3] - 2026-05-18 — Bündel-Release: Aggregations-Drifts + Forum-Bugfixes + Pfad-Hinweise

🛠 Bündel-Release nach drei Etappen-Tagen. Sieben anwender-relevante Bugfixes aus Forum + Issues, dazu eine konsistente Korrektur veralteter UI-Pfad-Hinweise. Schwerpunkt: drei Aggregations-Drifts in unterschiedlichen Verbrauchsbereichen (E-Mob-Ersparnis, Live-Tagesverlauf-Strompreis, Wallbox+E-Auto-Dashboards), zwei Robustheits-Fixes (Cloud-Import-Whitespace, getrennte WP-Strommessung), zwei stlorenz-Beiträge (Cockpit-Genauigkeit, HA-Backup-Konsistenz).

Fixed

E-Mobilität-Ersparnis: externe Lade-Kosten in Cockpit-Pfaden mitrechnen (#260 NongJoWo): Die Cockpit-Übersicht und der aktuelle Monatsbericht zeigten ~273 € weniger Ersparnis als das E-Auto-Dashboard. Ursache: drei Aufrufer von berechne_eauto_ersparnis hatten ladung_extern_euro=0.0 hartcodiert, das E-Auto-Dashboard zog den Wert korrekt aus den evcc-Portal-Daten. Alle drei Aufrufer ziehen jetzt denselben Wert. Memory-Linie feedback_aggregations_drift.md.
Cloud-Import: Whitespace in Credentials trimmen (#261 FrodoVDR): API-Keys aus Hersteller-Portalen werden oft mit Leerzeichen am Anfang oder Ende kopiert, SolarEdge antwortet darauf mit 403. Frontend und Backend trimmen jetzt User-Eingaben für Cloud-Import-Credentials vor dem API-Call. Memory-Linie feedback_credential_whitespace.md.
Daten-Checker: WP mit getrennter Strommessung nicht als fehlend melden (Forum dietmar1968): Der Daten-Checker prüfte hartcodiert das Legacy-Feld stromverbrauch_kwh und meldete eine fehlende Konfiguration, auch wenn stromverbrauch_heizen_kwh + stromverbrauch_warmwasser_kwh korrekt gemappt waren (getrennte Strommessung seit v3.25.x). Prüfung respektiert jetzt den getrennte_strommessung-Pfad.
Live-Tagesverlauf: Strompreis-Carry-Forward statt EPEX-Sprung (#267 rilmor-mhrs): Bei Tibber liefert HA alle 15 Minuten ein Step-Update — der Live-Tagesverlauf prüfte aber pro 10-Min-Slot, ob ein Update innerhalb des Slots liegt. Jeder zweite oder dritte Slot ohne Update fiel auf den EPEX-Börsenpreis-Fallback (~8-12 ct statt ~35 ct Tibber-Endkundenpreis) — die Strompreis-Linie zeigte hässliche Sprünge. Tibber/aWATTar sind Step-Funktionen: bei leerem Slot wird jetzt zuerst der letzte bekannte Wert weitergeführt, EPEX nur noch als finaler Fallback ohne jeden Tagespunkt. Fünf Akzeptanztests.
Wallbox- und E-Auto-Dashboards: Pool-Fallback bei evcc-Import (#262 junky84): evcc-Portal-Import schreibt Ladedaten architektonisch in die Wallbox-Investition (km gehen zum E-Auto). Die Cockpit-Übersicht griff das korrekt via Pool-Max ab, aber Wallbox- und E-Auto-Dashboards lasen jeweils nur den eigenen Pfad — bei junky84 zeigten beide „Noch keine Ladedaten vorhanden” trotz 4,12 MWh im Pool. Beide Dashboards bekommen jetzt dieselbe Pool-Max-Logik wie Cockpit; E-Auto-Dashboard verteilt Wallbox-Aggregate km-anteilig auf die E-Autos. Premium-Setups mit separat gepflegten E-Auto-Sensoren unverändert.
Cockpit: Spezifischer Ertrag periodengenau & jahresverlauf-gewichtet (PR #265 stlorenz): KPI „Spezifischer Ertrag” bezog sich bisher auf die Anlagenleistung zum Stichtag — bei nachträglichen Erweiterungen (Modul hinzu, Speicher dazu) verzerrte das die Anzeige. Der spezifische Ertrag wird jetzt periodengenau gewichtet pro Monat über den Jahresverlauf bestimmt.
HA-Backup-Konsistenz via WAL-Checkpoint (PR #266 stlorenz): Vor jedem Snapshot-Export wird jetzt ein WAL-Checkpoint geschrieben — verhindert die Race-Condition, in der HA-Backups eine inkonsistente DB-Datei aufnehmen konnten.
Daten-Checker Drift-Knopf: konkrete Vorher/Nachher-Anzeige im Toast (PN dietmar1968): „Tag reparieren” gab bisher pauschal „OK” zurück, auch wenn aggregate_day inhaltlich nichts geändert hatte (z. B. weil HA-LTS für einen der gemappten PV-Sensoren keine sum-Spalte hat — die Riemann-Summe aus dem Live-Tagesverlauf wird dann nicht durch HA-LTS-Boundaries überschrieben, die Drift bleibt). Endpoint liefert jetzt pv_kwh_alt + pv_kwh_neu mit derselben Aggregations-Logik wie der Drift-Check. Frontend zeigt drei Toast-Varianten: tatsächliche Änderung („PV 71,8 → 67,6 kWh”), unveränderter Wert mit Sensor-Mapping-Hinweis, oder Fallback ohne Werte (frische Aggregation ohne vorherige Zusammenfassung). Memory-Linie feedback_daten_checker_kein_akzeptiert.md.

Changed

UI-Pfad-Hinweise konsistent korrigiert: Hinweistexte im Monatsabschluss-Wizard, in der Daten-Checker-Drift-Liste und in den Release-Notes verwiesen auf einen nicht existierenden Menüpunkt „Wartung”. Korrekt: „Einstellungen → Daten → Energieprofil → Reparatur-Werkbank”. Elf Stellen synchron gefixt (Frontend-Wizard, Backend-API-Response, Daten-Checker-Hinweis, CHANGELOG, WAS-IST-NEU, KONZEPT-Doku, In-App-Hilfe via sync-help.sh). Außerdem ein „Aussichten → Energieprofil”-Tippfehler korrigiert (richtig „Auswertungen”).

Tests

151/151 grün — bestehende Suite, keine neuen Tests dazu/entfernt.

[3.31.2] - 2026-05-17 — Hotfix: „Tag reparieren”-Knopf in Daten-Checker

Fixed

Reparatur-Knopf erscheint jetzt wirklich: In v3.31.1 wurde der neue Per-Tag-Reparatur-Knopf in der Drift-Anzeige des Daten-Checkers nicht angezeigt — stattdessen kam der alte „Beheben”-Link, der nur zum Tag im Energieprofil-Tab springt. Ursache: das API-Response-Schema (CheckErgebnisResponse in backend/api/routes/daten_checker.py) wurde nicht um die neuen Felder action_kind/action_params/action_label erweitert, Pydantic filterte sie raus. Mit v3.31.2 kommen die Felder durch — Frontend rendert wie geplant den „Tag reparieren”-Knopf neben jedem Drift-Eintrag.
Schutz gegen Wiederholung: neuer Akzeptanz-Test test_daten_checker_schema_durchreichung.py prüft per Reflection, dass jedes Feld der internen CheckErgebnis-Dataclass auch im Pydantic-Response-Schema existiert. Künftige Felder-Erweiterungen können nicht mehr stillschweigend rausgefiltert werden.

Hinweis für Anwender

Wer v3.31.1 bereits installiert hat: einmal aktualisieren, dann erscheint der Reparatur-Knopf wie versprochen. Wer den Workaround genutzt hat („Beheben”-Klick → Reload-Knopf im Energieprofil): das hat funktional dasselbe erreicht, war nur ein Klick mehr.

[3.31.1] - 2026-05-17 — Etappe 6: Per-Tag-Drift-Anzeige + Reparatur

🔍 Sichtbar machen, was Etappe 4 erst möglich gemacht hat. v3.31.0 hat die Architektur auf HA-Statistics umgestellt — neue Tage werden sauber aus HA-LTS aggregiert, bestehende Tage bleiben aber auf ihren alten Werten (Auto-Vollbackfill ist additiv, schützt manuelle Korrekturen). v3.31.1 zeigt jetzt im Daten-Checker pro Tag, wo dein eedc-Wert vom HA-Statistics-Wert abweicht, und legt einen „Tag reparieren”-Knopf direkt neben jeden Eintrag.

Added

Daten-Checker-Kategorie „Datenquelle – Drift zu HA-Statistics”: vergleicht die PV-Tagessumme der TagesZusammenfassung mit der HA-Statistics-Tagessumme der letzten 90 Tage. Tage mit Drift bekommen pro Tag einen INFO-Eintrag mit eedc-Wert, HA-Wert und Differenz in kWh und Prozent. Direkt daneben ein „Tag reparieren”-Knopf, der den bestehenden /reaggregate-tag-Endpoint aufruft. Schwelle: ≥ 2 kWh UND ≥ 5 % Abweichung gleichzeitig (Boundary-Rauschen wird unterdrückt). Liste auf die 20 Tage mit größtem |Δ| begrenzt. Bewusst kein Sammel-Reparatur-Knopf in der Liste — für mehrere Tage gibt es weiterhin Einstellungen → Daten → Energieprofil → Reparatur-Werkbank → Bereich neu aggregieren.
CheckErgebnis-Felder für Inline-Reparatur-Aktionen: action_kind, action_params, action_label. Rückwärtskompatibel — bestehende Check-Kategorien lassen die Felder leer.

Changed

Daten-Checker-Frontend rendert Reparatur-Knöpfe für action_kind="reaggregate_day"-Einträge. Beim Klick wird der reaggregate-Tag-Endpoint aufgerufen, ein Erfolgs-/Fehler-Toast erscheint, und der Daten-Checker lädt neu. Drift-Einträge verschwinden dadurch automatisch, wenn der Tag jetzt unter der Schwelle liegt.

Hinweis für Anwender

Direkt nach dem Update v3.31.0 (gestern) standen deine bestehenden Tages-Werte noch auf ihren alten Mix-Source-Werten — neue Tage wurden ab sofort sauber aus HA-Statistics aggregiert. v3.31.1 macht jetzt sichtbar, welche bestehenden Tage signifikant abweichen, und bietet pro Tag einen sicheren Reparatur-Pfad ohne Massen-Aktion. Liste leer → alles sauber, kein Handlungsbedarf.

Konzept-Dokumentation

docs/KONZEPT-ETAPPE-6-DRIFT-ANZEIGE.md mit Architektur-Detail, Schwellen-Begründung, vermiedenen Anti-Patterns (kein „Akzeptiert”-Button, kein Sammel-Heiler-Knopf, kein Lösch-Pfad).

Tests

Suite wächst von 125 auf 133 Tests:

8 neue Tests für _check_datenquelle_drift (Schwellen-Logik, Sortierung, Max-20-Cap, Inbetriebnahme-Edge-Case, HA-LTS-Fallback, leere Anlage)

[3.31.0] - 2026-05-17 — Etappe 4+5: HA-Statistics als Source-of-Truth

🎯 Konsistenz der Energie-Aggregate erzwungen. Drei Sichten auf denselben Tag (Genauigkeits-Tracking IST, Tages-Energieprofile PV-Ertrag, Σ Stundenwerte im Monatsbericht) zeigten bei manchen Anlagen voneinander abweichende Werte für die PV-Erzeugung — teils um ~10 %. Ursache: zwei parallel laufende Datenpfade (Riemann-Integration aus dem Live-Tagesverlauf + Counter-Boundary-Diff aus Sensor-Snapshots) mit unterschiedlichen Aggregationsfenstern, plus ein Filter-Bug im Genauigkeits-Tracking. Ab v3.31.0 sind die Aggregat-Tabellen Cache von HA-Statistics-Long-Term — eine einzige Quelle für alle Sichten, Σ Stundenwerte = Tagessumme per Konstruktion. Zusätzlich werden mit Etappe 5 die letzten drei eedc-eigenen Berechnungen (Tages-Peaks, Batterie-SoC-Stundenmittel, Strompreis-Stundenmittel) durch direkten HA-Statistics-Read ersetzt.

Fixed

Genauigkeits-Tracking IST enthält keine Batterie-Netto-Ladung mehr: Der IST-Wert für PV-Erzeugung im Genauigkeits-Tracking summierte bisher komponenten_kwh-Subkeys mit positivem Wert über eine Negativliste hinaus — bei Anlagen, deren Batterie über den Tag netto geladen hatte (z. B. 4–6 kWh Überschuss), wurde diese Ladung als IST-Erzeugung mitgezählt. Der Filter wurde auf eine Prefix-Whitelist pv_* und bkw_* umgestellt, analog zur Frontend-Spalte „PV-Ertrag” in der Tages-Energieprofile-Tabelle. Die Prognose-MAE-Werte werden dadurch realistischer (kein künstlich besserer Wert mehr).

Changed

TagesEnergieProfil + TagesZusammenfassung werden Cache von HA-Statistics-LTS: Die Stunden- und Tageswerte für PV, Einspeisung, Netzbezug, Batterie, Wärmepumpe, Wallbox usw. werden im HA-Add-on-Modus jetzt direkt aus den HA-Long-Term-Statistics gelesen (über die neue Funktion HAStatisticsService.get_hourly_kwh_deltas_for_day). Damit gilt für alle Anlagen mit HA-Integration: Σ TagesEnergieProfil.pv_kw == TagesZusammenfassung.komponenten_kwh["pv_<id>"] (und analog für alle anderen Kategorien). Der bestehende Sensor-Snapshot-Pfad bleibt als Fallback für Standalone-Anlagen ohne HA aktiv.
Schreib-Provenance-Vokabular erweitert: Neue Source-Labels external:ha_statistics:hourly (für Stundenwerte in TagesEnergieProfil) und external:ha_statistics:daily (für TagesZusammenfassung.komponenten_kwh). Die Aufsplittung ermöglicht im Audit-Log die Diagnose, ob Stunden- oder Tagessumme den jeweiligen Wert geschrieben hat. Beide auf Stufe EXTERNAL_AUTHORITATIVE — manuelle Einträge gewinnen weiterhin unbedingt (Schutzrichtung aus v3.30.3 bleibt).
Daten-Checker zeigt aktiven Datenquellen-Pfad: Neue Kategorie „Datenquelle – aktiver Pfad” mit drei möglichen Stati: (1) HA-Statistics als Source-of-Truth aktiv (OK), (2) HA-Statistics verfügbar, Aggregate noch aus älterer Quelle (Info, heilt sich beim nächsten Monatsabschluss), (3) Standalone-Modus ohne HA-LTS (Info, eingeschränkt durch Sub-Stunden-Boundary-Effekte). Transparente Diagnose für Anwender, die wissen wollen, woher ihre Zahlen kommen.
Etappe 5 — Tages-Peak-Werte aus HA-Statistics-Min/Max: peak_pv_kw, peak_netzbezug_kw und peak_einspeisung_kw werden bevorzugt aus den Stunden-Extremwerten gelesen, die HA-Recorder für has_mean=True-Sensoren ohnehin schreibt (statistics.max / statistics.min). Die bisherige Berechnung aus 10-Min-Mittelwerten unterschätzte Peaks systematisch — der HA-Wert entspricht jetzt der physikalisch korrekten Tagesspitze. Mehrere PV-Sensoren werden per Σ max je Stunde aggregiert (obere Schranke, in der Praxis < 5 % Drift). Fallback auf den bisherigen Pfad bleibt für Standalone-Modus ohne HA-LTS.
Etappe 5 — Batterie-SoC- und Strompreis-Stundenmittel aus HA-Statistics: _get_soc_history() und _get_strompreis_stunden() lesen Stundenwerte direkt aus statistics.mean statt sie aus der State-History selbst zu mitteln. Damit sind alle Stundenwerte im TagesEnergieProfil aus derselben HA-Statistics-Quelle wie das HA-Energy-Dashboard, mit gemeinsamer Recompile- und Kompression-Logik. State-History-Mittelung bleibt als Fallback wenn LTS leer.

Migration

Automatischer Vollbackfill bei Upgrade: Beim Update auf v3.31.0 wird für Anlagen mit HA-Integration und bestehenden Aggregat-Daten das vollbackfill_durchgefuehrt-Flag auf False zurückgesetzt. Beim nächsten Monatsabschluss läuft dann der Auto-Vollbackfill aus HA-LTS einmalig durch und füllt fehlende Tage nach (additiv, bestehende Tage bleiben unverändert — Schutz manueller Korrekturen). Anwender müssen für neue Tage nichts aktiv tun; um bestehende Tage gezielt auf die HA-Statistics-Werte umzustellen, stehen Auswertungen → Energieprofil → Tag-Reload (Vorschau) und Einstellungen → Daten → Energieprofil → Reparatur-Werkbank → Bereich neu aggregieren zur Verfügung. Anlagen ohne HA-Integration (Standalone-Docker) bleiben unverändert — ihr Snapshot-basierter Pfad funktioniert weiter wie bisher.

Hinweis für Anwender

Wenn dir nach dem Update auffällt, dass historische Tageswerte sich um wenige Prozent ändern: das ist beabsichtigt. Die Werte wurden von dem rechnerisch nicht ganz sauberen Mix-Pfad auf die HA-Statistics-konformen Werte umgezogen (gleiches Ergebnis wie das HA-Energy-Dashboard). Die neuen Werte sind durchgängig konsistent zwischen allen eedc-Sichten — die Drift, die manche Anwender zuvor zwischen Genauigkeits-Tracking, Tages-Energieprofile und Stunden-Σ gesehen hatten, ist Geschichte.

Konzept-Dokumentation

Vollständige Architektur + Pfad-Inventar + Test-Plan: docs/KONZEPT-ETAPPE-4-HA-LTS-SOT.md (Etappe 5 als Anhang 9a).

Tests

Suite wächst von 96 auf 125 Tests (29 neue, alle grün):

5 Tests für HAStatisticsService.get_hourly_kwh_deltas_for_day (Lückenbehandlung, Einheiten, Mehrfach-Sensoren)
7 Konsistenz-Tests für die LTS-Aggregator-Pfade (Σ Hourly == Daily über alle Investitionstypen)
6 Tests für die Migration (Reset-Verhalten, Idempotenz, Standalone-No-Op)
5 Tests für HAStatisticsService.get_hourly_mean_for_day (Etappe 5: SoC + Strompreis, Roh-Einheit)
5 Tests für HAStatisticsService.get_hourly_minmax_sensor_data (Etappe 5: Stunden-Extrema, Einheiten-Filter, Boundary)
6 Tests für _get_tagespeaks_aus_ha_lts (Etappe 5: Einzel-/Multi-PV, Kombi-Netz, Invert-Flag, Fallback)

[3.30.3] - 2026-05-16 — Split-Klimaanlagen als Luft-Luft-WP (Forum #548)

❄️ Klimaanlagen sind jetzt Wärmepumpen. Eine Split-Klimaanlage ist physikalisch eine Luft-Luft-Wärmepumpe (Reverse-Cycle, Heizen + Kühlen). Bisher wurden sie pragmatisch unter „Sonstiges” geführt — was im Cockpit-Wärmepumpenbereich keinen Eintrag erzeugt und die JAZ-Statistik verfälscht. Ab v3.30.3 steht wp_art = "luft_luft" als gleichwertiger WP-Subtyp zur Verfügung; das System rechnet und meldet entsprechend.

Changed

JAZ/COP-Berechnung tolerant gegen fehlenden Wärmemengenzähler (Forum #548 alex_s9027): Die JAZ wird jetzt nur ausgegeben, wenn beide Seiten gemessen sind — Stromverbrauch UND Heizenergie. Bisher kam bei Klimas (Stromverbrauch ja, Heizenergie nein) ein irreführender Wert „0.0” heraus, jetzt sauber „—” (Lücke). Betroffene Endpunkte: Cockpit-Übersicht, Cockpit-Komponenten, PDF-Jahresbericht, PDF-Operationen, Sozial-Bilanz.
Daten-Checker still bei Klimaanlagen: Bei wp_art = "luft_luft" wird die „Heizwärme fehlt”-INFO nicht mehr gemeldet — bei Klimas ist das normal (Standardausstattung HACS-Integrationen liefert nur Stromzähler), nicht ein Datenloch. Klassische Luft-Wasser-WPs bekommen die Warnung weiterhin (kein Regress).
WP-Wizard: Hinweis-Box bei Wahl „Luft-Luft (Klimaanlage)”: erklärt, dass nur der Stromverbrauchs-Sensor nötig ist, die JAZ-Kachel bleibt leer.

Fixed

Cockpit-Übersicht zeigt jetzt eine Sonstiges-Sektion (Forum #548): Bisher hatten „Sonstiges”-Investitionen (Pool, Sauna, Klima ohne WP-Kategorie, Zweit-Erzeuger) zwar im Detail-Tab und in der Monatsübersicht ihre Werte — die Cockpit-Übersicht (Hauptseite) hat sie aber komplett ignoriert. Backend-Endpoint /api/cockpit/uebersicht liefert jetzt sonstiges_erzeugung_kwh + sonstiges_verbrauch_kwh + hat_sonstiges, das Cockpit-Dashboard rendert eine entsprechende Section mit Erzeugungs- und Verbrauchs-KPI-Kacheln (sichtbar nur wenn die Investition mindestens eine Seite gepflegt hat).
MariaDB-Verbindung mit mysql://-URL funktioniert jetzt (#251 FrodoVDR): Der HA-Recorder-Doku-Standard mysql://user:pass@host/db führte zu ModuleNotFoundError: No module named 'MySQLdb', weil SQLAlchemy bei dieser Schreibweise das C-Modul mysqlclient lädt (im Add-on-Image ist nur pymysql installiert). Auto-Treiber-Mapping in ha_statistics_service.py biegt mysql:// und mariadb:// intern auf mysql+pymysql:// bzw. mariadb+pymysql:// um. Wer den +pymysql-Suffix bereits in der URL stehen hat, ist unverändert.
Plan-Vorschau zeigt korrekte Uhrzeit für die Gültigkeit (#257 detLAN): Der „Plan gültig bis”-Header in der Reparatur-Werkbank zeigte die UTC-Zeit als wäre sie Lokalzeit — in MESZ ergab das eine Differenz von 2 Stunden (z. B. „21:00” statt korrekt „23:00”). Backend liefert die Zeit jetzt als tz-aware UTC mit +00:00-Marker, Frontend interpretiert korrekt + defensive Normalisierung für Übergangs-Cache-Fälle.
Obsolete WP-Stromverbrauchs-Sensoren werden beim Wizard-Speichern automatisch entfernt (rapahl PN 2026-05-16): Wer eine Wärmepumpe von „Gesamt-Strommessung” auf „getrennte Strommessung” (Strom Heizen + Strom Warmwasser) umgestellt hat, hatte den alten stromverbrauch_kwh-Eintrag weiterhin im Sensor-Mapping liegen — die UI blendete das Feld bei aktivierter getrennter Messung aus, der Daten-Checker zeigte daher einen INFO-Hinweis ohne klickbaren Lösch-Pfad. Ab v3.30.3 räumt der Wizard-Save den Eintrag still auf (kein Datenverlust, der Sensor wird in der Aggregation ohnehin ignoriert), der Daten-Checker-Hinweis erklärt das Verhalten und entfällt nach dem nächsten Speichern.

⚠ Nachträglich richtiggestellt (September 2026): Die Klammer „der Sensor wird in der Aggregation ohnehin ignoriert” gilt heute nur, wenn beide getrennten Zähler gepflegt sind. Ohne sie trägt der Gesamtzähler den Verbrauch des Geräts — ihn zu entfernen kostet Zahlen. Das automatische Aufräumen beim Speichern gibt es seit der Datenquellen-Fläche nicht mehr; der Daten-Checker sagt das jetzt so.
Live-Heute: doppelte Skalierung bei MWh/Wh-Sensoren behoben (#242 NongJoWo): Energie-Sensoren mit Einheit Wh oder MWh wurden im Live-Heute-Pfad doppelt skaliert — ha_statistics_service.get_value_at skaliert intern bereits auf kWh, aber live_history_service._energy_delta multiplizierte den Statistics-Pfad-Wert nochmal mit _KWH_SCALE. Folge: MWh-Werte wurden mit Faktor 1000 zu hoch angezeigt (NongJoWo: 8.11 kWh Einspeisung wurden als 8097 kWh dargestellt). Fix: Statistics-Pfad wird unverändert weitergegeben (Werte sind bereits kWh), _KWH_SCALE greift nur noch im state-history-Fallback (rohe state-Werte). Tests entsprechend angepasst — die alte Test-Erwartung mockte das echte Verhalten falsch und ließ den Bug durchrutschen.
WP-Kompressor-Starts werden jetzt auch beim Vollbackfill aus HA-Statistics geschrieben (#259 detLAN): Bisher füllte der Vollbackfill-Pfad (Einstellungen → Daten → Energieprofil → Reparatur-Werkbank → Lücken aus HA-LTS nachfüllen) zwar alle Energiewerte, ließ aber wp_starts_anzahl leer — die Tagesdetail-Tabelle in „Auswertungen → Energieprofil” zeigte leere WP-Starts-Spalten für nachgefüllte Tage. aggregate_day hatte den Pfad bereits korrekt (v3.24.0), Backfill nicht. Jetzt analog implementiert.
Manuelle Eingabe schlägt jetzt jede andere Datenquelle — auch repair (#251 FrodoVDR): Bisher konnte der Provenance-Resolver eine Wizard-Eingabe still verwerfen, wenn das Feld zuvor von einer Reparatur-Operation (Quelle repair) gestempelt war — der User sah „erfolgreich gespeichert”, aber die DB blieb unverändert. Auch der zwischenzeitlich eingebaute Schreib-Reject-Hinweis war Symptombehandlung, nicht der Fix. Jetzt: jede explizite User-Eingabe über Wizard oder Monatsformular gewinnt unbedingt, unabhängig von der existierenden Provenance. Hintergrund-Quellen (Cloud, HA-Stats, Aggregation, Fallback) können den manuell gepflegten Wert weiterhin nicht überschreiben — die Schutzrichtung war schon immer korrekt, jetzt ist sie auch ohne Schlupfloch.

Hinweis für Anwender

Wenn du eine Split-Klimaanlage bisher unter „Sonstiges” hattest: lege sie als neue Investition vom Typ „Wärmepumpe” mit wp_art = "Luft-Luft (Klimaanlage)" an, weise denselben Stromverbrauchs-Sensor zu, lösche die alte „Sonstiges”-Investition. Sie taucht dann im Cockpit-Wärmepumpenbereich auf, in der Komponenten-Auswertung und im Community-Benchmark (gruppiert mit anderen Luft-Luft-Klimas). Wer „Sonstiges” für andere Verbraucher/Erzeuger nutzt (Pool/Sauna/etc.), bekommt sie ab v3.30.3 automatisch im Cockpit angezeigt.

Was Phase 1 nicht enthält (folgt anlassbezogen): eigene Kühlenergie-Erfassung (kuehlenergie_kwh), EER-Effizienz-Metrik für Kühlbetrieb, Modus-Erkennung über Thermostat-Entitäten.

[3.30.2] - 2026-05-15 — PV-Counter-Spike-Cap (Forum #529)

🛡️ Schutz vor Counter-Off-by-ones. HA-Statistics liefert nach manchen Restarts einen falschen Stunden-Sprung im PV-Counter (z. B. +109 kWh in einer Stunde bei einer 11 kWp-Anlage). Der Daten-Checker hat solche Spikes bisher erkannt, aber der Aggregator schrieb sie ungekappt in den Stundenwert — Reaggregation war idempotent und konnte sie nicht heilen. Ab v3.30.2 cappt der Aggregator PV- und Einspeisungs-Stundenwerte präventiv gegen kwp × 1.5.

Fixed

PV-/Einspeisungs-Stundenwerte werden gegen Plausibilität gecappt (Forum #529, dietmar1968): Wenn ein Stunden-kWh-Wert mehr als das 1,5-fache der PV-Anlagenleistung beträgt, wird er in TagesEnergieProfil als Lücke (None) gespeichert statt als Spike. Damit greift „Tag neu aggregieren” in der Reparatur-Werkbank jetzt auch bei klassischen Counter-Off-by-ones, die bei der bisherigen idempotenten Reaggregation unverändert zurückkamen.
SoT-Konvention zwischen Detektor und Cap: Schwelle kwp × 1.5 lebt jetzt zentral in backend/services/snapshot/plausibility.py. Daten-Checker und Aggregator ziehen dieselbe Schwelle aus diesem Helper — kein Drift mehr möglich.

Hinweis für Betroffene

Nach dem Update einmal über Einstellungen → Daten → Energieprofil → Reparatur-Werkbank → Tag neu aggregieren für den betroffenen Tag laufen. Stundenwert mit Spike wird zur Lücke, Tageswerte fallen auf das physikalisch plausible Niveau. Anlagen ohne hinterlegte leistung_kwp werden nicht gecappt (Stammdaten-Check meldet das schon separat).

[3.30.1] - 2026-05-15 — Prognosequellen-Wahl pro Anlage + Strompreis-Vorschlag

☀️ Drei PV-Prognosequellen zur Auswahl. Jede Anlage kann jetzt zwischen eedc-optimiert (Standard), Solcast und Solar Forecast ML wählen. Auto-Discovery erkennt installierte Integrationen in HA automatisch — kein manuelles Sensor-Mapping mehr nötig.

Added

Prognosequelle pro Anlage wählbar: neues Feld prognose_quelle in den Anlagen-Einstellungen mit drei Optionen:
- eedc-optimiert (Standard): OpenMeteo × anlagenspezifischer Lernfaktor — funktioniert überall, auch standalone
- Solcast (pur): Satellitenbasierte Prognose direkt, ohne eedc-Korrektur
- Solar Forecast ML (pur): ML-basierte Prognose direkt aus der HA-Integration, ohne eedc-Korrektur (nur im HA-Add-on)
Auto-Discovery: SFML- und Solcast-Sensoren werden automatisch in HA erkannt — kein manuelles Sensor-Mapping im Wizard mehr nötig. Discovery erkennt die Integration anhand der Entity-ID-Patterns und mappt alle relevanten Sensoren automatisch
Solcast Standalone: API-Token + Resource-IDs können im Sensor-Mapping-Wizard eingegeben werden (für Nutzer ohne HA-Integration)
Quellen-Hinweis: WetterWidget und Live-Dashboard zeigen die aktive Quelle an (nur bei Nicht-Default). Bei Fallback auf eedc erscheint ein Amber-Hinweis mit Erklärung
Resolver-Service (prognose_router.py): zentrale Quellen-Auflösung mit Verfügbarkeits-Check und automatischem Fallback auf eedc
Discovery-Endpoint GET /api/anlagen/prognose-quellen/discover: zeigt dem Frontend die in HA erkannten Integrationen + Sensoren
Verbrauchsgewichteter Ø-Strompreis im Monatsabschluss-Wizard (#250): Bei dynamischen Tarifen (Tibber, aWATTar) berechnet eedc jetzt automatisch den verbrauchsgewichteten Monats-Durchschnittspreis aus den gesammelten Stundendaten — als Vorschlag mit Konfidenz-Staffelung (je nach Stunden-Abdeckung). Der bisherige HA-Sensor-Momentanwert bleibt als Fallback mit reduzierter Konfidenz erhalten

Changed

EEDC-Lernfaktor O12 als Live-Default: Der verbesserte Lernfaktor mit Recency-Boost und Trim-Mean (O1+O2) ist jetzt der aktive Live-Faktor. Legacy-Skalar dient als Fallback und wird im Log als Diagnose-Vergleich ausgegeben
EEDC nutzt immer OpenMeteo als Basis: Die bisherige Option „Solcast als EEDC-Basis” entfällt — Solcast ist jetzt eine eigenständige Quelle (pur, ohne Korrektur). Wer vorher prognose_basis=solcast hatte, wird automatisch auf prognose_quelle=solcast migriert
Solcast im HA-Add-on ohne manuelle Konfiguration: solcast_service.py erkennt die Solcast-Integration automatisch per Auto-Discovery, auch ohne explizite solcast_config im Sensor-Mapping
Prognosen-Tab: reine EEDC-Diagnose-Sicht (OpenMeteo vs. eedc-kalibriert vs. Solcast vs. IST), keine SFML-Vergleichs-Spalte mehr

Fixed

„Database is locked” beim Monatsabschluss: SQLite WAL-Journal + busy_timeout=10000 + synchronous=NORMAL. Parallele Writer (MQTT-Inbound, Background-Aggregator, Wizard) warten jetzt aufeinander statt sofort abzubrechen. (PR #248, @stlorenz)

Removed

SFML-Vergleichs-Card in Aussichten → Prognosen (eedc vs. ML vs. IST Tabelle + Chart) — entfällt zugunsten der Quellenwahl
SFML-Anzeigen im Live-Dashboard: lila ML-Zahl neben Tagesprognose + Tooltip
SFML-Linie im WetterWidget: lila dotted ML-Prognose-Linie + Legende + Gradient
Manuelle SFML-Sensor-Zuordnung im Wizard (3 Felder: sfml_today_kwh, sfml_tomorrow_kwh, sfml_accuracy_pct) — ersetzt durch Auto-Discovery
prognose_basis-Feld: deprecated, wird automatisch zu prognose_quelle migriert

[3.29.2] - 2026-05-14 — Vorab-Fixes vor Menüstruktur-Konzept (#206 #210)

🧹 Stall ausmisten vor dem großen Konzept. Kleine UX-Fehler und Schreibweisen-Drift, die nicht auf das künftige Menüstruktur-Konzept warten sollten. Kein neuer Funktionsumfang.

Fixed

Komponenten-Beiträge zur Finanzierung — Sortierung und Icons (#210 detLAN). In Aussichten → Finanzen wurden die Beiträge in der Reihenfolge Speicher → E-Auto-V2H → E-Auto-Benzin → E-Auto-PV → WP-PV → WP-Ersparnis angezeigt — Wärmepumpe stand also nach E-Auto, inkonsistent zur App-weiten INVESTITION_TYP_ORDER (Wallbox/E-Auto-Cluster nach WP). Zusätzlich fielen drei Beitragstypen (waermepumpe-pv, waermepumpe-ersparnis, e-auto-benzin) auf den Battery-Fallback-Icon durch, weil das Mapping in FinanzenTab.tsx die Suffix-Typen nicht kannte. Beides behoben:
- Neuer komponentenBeitragTypIndex()-Helper mappt Suffix-Typen auf ihren Basis-Typ (z. B. waermepumpe-pv → waermepumpe) und sortiert nach dem Index in INVESTITION_TYP_ORDER.
- KOMPONENTEN_ICONS um die drei Suffix-Typen erweitert: e-auto-benzin → Fuel, waermepumpe-pv und waermepumpe-ersparnis → Flame.
- Die 4-Kacheln-Zusammenfassung unter der Karte (Speicher EV+ / V2H / E-Auto PV-Ladung / WP PV-Direkt) zieht in dieselbe Reihenfolge: Speicher → WP → V2H → E-Auto-PV-Ladung.
Dekoratives Calendar-Icon vor Jahres-Filter in Auswertungen entfernt (#206 P2-Folge detLAN). Das gleiche Phänomen wie im Cockpit (in v3.27.1 schon entfernt) saß noch in der Auswertungen-Top-Bar: nicht-klickbares Calendar-Icon neben klickbarem Year-<select> verwirrt — weniger ist mehr. Beide Selects (Jahr + Anlage) haben jetzt aria-label/title für Bildschirmleser.
Schreibweise „eedc” durchgängig — Code-Sichtbares + Hilfe-Dokumente (#206 P4 detLAN). Bisherige EEDC-Reste in anwender-sichtbaren Stellen auf das lower-case Marken-Token umgestellt:
- Code (8 Bereiche, 19 Stellen): Share-Text-Footer (social.py 2×), HA-Verbindungsfehler-Message (ha_integration.py), HA-Sensor-Export-YAML-Header + Friendly-Name-Präfix + Device-Doc (ha_export.py 3×), MQTT-Device-Name + manufacturer (mqtt_client.py 5×), Restart-Message (system_logs.py), Fallback-API-Antwort (main.py), PDF-Bericht-Titel (pdf_service.py 3×), PVGIS-User-Agent (anlagen.py), Browser-Tab-Titel + meta description (index.html 2×).
- Hilfe-Dokumente (10 Dateien, ~130 Treffer): BENUTZERHANDBUCH, WAS-IST-NEU, HANDBUCH_INSTALLATION/BEDIENUNG/EINSTELLUNGEN/INFOTHEK/DATEN_CHECKER, BERECHNUNGEN, SENSOR-REFERENZ, GLOSSAR — \bEEDC\b mit Wortgrenze ersetzt, schützte Code-Identifier wie EEDC_ENERGIEPROFIL_QUELLE und Formel-Variablen EEDC_Abweichung/EEDC_Prognose/EEDC_Roh_Prognose_kWh automatisch. ReportLab-Style EEDCBody und Doc-Strings/Code-Kommentare im Backend (Dev-Sicht) unverändert.

Hinweis für Bestandsnutzer mit MQTT-Discovery: HA-Devices erscheinen ab diesem Update mit Friendly-Name „eedc - ” statt „EEDC - ”. Entity-IDs (eedc_anlage_*, sensor.eedc_*) bleiben gleich, keine Daten-Migration. Wer im YAML-Sensor-Export-Snippet die Friendly-Names manuell übernommen hat, kann das Snippet aus „Einstellungen → HA-Export” neu kopieren — funktional ändert sich nichts.

Internal

A6 (globaler pt-4-Whitespace zwischen Sub-Tabs und erstem Page-Inhalt) bereits in v3.29.1 via Layout.tsx-Commit 650adb09 (#233 P15) erledigt — detLAN’s #209 P5-Comment lag vor v3.29.1 und ist seitdem implizit gefixt.
Vorbereitung für Konzept-Issue „Durchgängige Menüstruktur + Mobile-Strategie”: bestehende Sub-Tracker #203, #204, #206, #208, #209, #210, #216 werden mit Verweis aufs neue Konzept geschlossen.

[3.29.1] - 2026-05-14 — Anschaffungsdatum-Komplettierung + UX-Cluster (#229 #233 #237 #239 #240 #241)

🪛 Tester-Welle vom 13./14. Mai gebündelt — detLAN-Folge zu #236 mit zwei zusätzlichen Pfaden, JanKgh-Multi-String-Verteilungsbug, fünf UX-Verbesserungen aus detLAN/NongJoWo. Kein neuer Funktionsumfang.

Fixed

Monatsbericht-Sektion vor Anschaffungsdatum ausblenden (#239 detLAN-Folge zu #236). v3.29.0 hatte den Aggregat-Filter ausgerollt, aber die Sektions-Sichtbarkeit im Monatsbericht (Wärmepumpe / Speicher / E-Mobilität / Balkonkraftwerk / Sonstiges) wurde weiter anlagenweit berechnet. Folge: WP-Sektion erschien auch in Monaten vor Anschaffung — alle Werte „—”, aber der Block stand. Fix in aktueller_monat.py:1101+: die hat_*-Flags und die wp_invs-Liste für Kompressor-Starts respektieren jetzt ist_aktiv_im_monat(jahr, monat). Sektion verschwindet komplett, Folgesektionen rücken hoch.
HA-Statistics-/MQTT-Aggregation respektiert Anschaffungsdatum (#239 detLAN-Folge). Zweiter Pfad, der nach dem v3.29.0-Fix immer noch Vor-Anschaffungs-Werte durchließ: aktueller_monat.py aggregierte HA-Sensor-Werte über inv_{id}_*-Keys ohne Anschaffungsdatum-Filter. Sensoren existieren in HA häufig schon vor der EEDC-Registrierung. Beispiel detLAN: WP-Anschaffungsdatum April, im März-Monatsbericht standen trotzdem 145 kWh Strom. Fix: ist_aktiv_im_monat(jahr, monat) als Vor-Filter in beiden Aggregations-Schleifen (typ_aggregation + E-Mob-Pool).
Einheitliches Display-Token ’—’ statt ’---’ für leere Felder (#239 detLAN). An manchen Stellen wurde ’---’ (drei ASCII-Bindestriche), an anderen ’—’ (em-dash) für „kein Wert” gezeigt. Alle 41 Frontend-Vorkommen auf em-dash umgestellt (war ohnehin Mehrheit mit 68 Stellen). Display-Token-Änderung, keine Code-Logik berührt.
Modul-Verteilung primär aus Tabellen-Spalte, parameter als Fallback (#229 JanKgh, SolarEdge-Multi-String). Bei 4 PV-Modul-Investitionen Ost/West × 2 Neigungen wurde die Anlagengesamterzeugung gleichverteilt (1/4 je Modul) statt anteilig nach kWp — der Verteilungs-Helper las leistung_kwp aus parameter-JSON, gepflegt ist aber die Tabellen-Spalte. SoT-Helper backend/utils/investition_value.py:get_inv_value(inv, key) liest primär die Spalte, fällt auf parameter zurück. Beide Verteilungs-Helper umgestellt (import_export/helpers.py:_distribute_legacy_pv_to_modules für CSV-Import, connector.py:_distribute_by_param für HA-Live-Daten). Mapping _COLUMN_FOR_PARAM erweiterbar.
UX-Konsistenz Einstellungen → Allgemein/Protokolle + globaler Page-Whitespace (#233 detLAN P13–P18). Zwei weitere überflüssige Page-Überschriften, die in v3.27.5 übersehen wurden, entfernt: „Einstellungen” (Allgemein-Tab) und „Protokolle” (Protokolle-Tab). „Debug” + „Neustart” rücken in dieselbe Reihe wie die Sub-Sub-Tabs „System-Logs/Aktivitäten” — gemeinsame Toolbar statt zwei getrennter Header-Zeilen. Layout-weit: Main-Container von pt-1 auf pt-4 — zusammen mit SubTabs py-2 ergibt das 24 px Whitespace zwischen Sub-Tabs und erstem Page-Inhalt, konsistent zu space-y-6 zwischen Cards.
kWh-Einheiten an Wärmepumpe-Dashboard ergänzt (#237 detLAN). Drei Stellen ohne Einheitsangabe in „Cockpit → Wärmepumpe”: Monatsdaten-Tabellen-Header (Strom/Heizung/Warmwasser → jeweils „(kWh)”), Wärme-Verteilung Summary „Heizung 1621 kWh · Warmwasser 133 kWh” (vorher fehlte Einheit bei Heizung), Wärmeerzeugung-pro-Monat Chart — Y-Achse beschriftet mit „kWh”, Tooltip mit Einheit.
Daten-Checker: Inbetriebnahme-Monat als Vorjahres-Vergleichsbasis ausgeschlossen (#240 NongJoWo). Anlage seit Ende März 2022 → März-2022-Werte (50 kWh, Bruchteil) im März-2023-Vergleich (261 kWh) als „3× Vorjahr” gemeldet. Fix in _check_monatsdaten_plausibilitaet: Vergleich überspringt Monate, in denen die Anlage im Inbetriebnahme-Monat (oder davor) war — die Werte sind dann strukturell unvollständig. Linie: Daten-Checker-Hinweise bleiben nicht-quittierbar, stattdessen die Heuristik schärfen.
Sparkline-Tooltip zeigt Monatsnamen statt Bar-Index (#241 NongJoWo). Cockpit → Übersicht → Energie-Bilanz → PV-Monatserträge-Sparkline zeigte beim Hover „1” / „2” / „3” als Header. Hidden XAxis mit dataKey="name" ergänzt — Tooltip liest jetzt den Monatsnamen aus den Daten („Mär 22” / „Jan 26”).

Internal

Drei neue/erweiterte Test-Dateien: test_monatsbericht_hat_flags_filtern_vor_anschaffung in test_investition_aktiv_filter.py (für #239), test_inv_value_spalten_fallback.py (6 Tests für #229), test_daten_checker_vorjahr_inbetriebnahme.py (2 Tests für #240). Alle grün, bestehende Suiten weiterhin grün.
SoT-Helper backend/utils/investition_value.py (get_inv_value) mit Mapping _COLUMN_FOR_PARAM für künftige Spalten-vs.-Parameter-Drift.

[3.29.0] - 2026-05-13 — Aggregations-/UX-Bündel (#222 #231 #232 #234 #235 #236)

🪛 Tester-Welle vom 12./13. Mai gebündelt — fünf strukturelle Reparaturen aus detLAN-/NongJoWo-Meldungen plus ein UX-Fix in „Eigene Dateien”-Vorschau. Kein neuer Funktionsumfang.

Fixed

Anschaffungs-/Stilllegungsdatum-Filter über alle Read-Sites (#236 detLAN). detLAN hatte gemeldet, dass eine WP-Investition mit anschaffungsdatum=April Vor-Anschaffungs-Daten (März) weiterhin in Aggregaten zeigt. Drift-Sweep ergab: Helper Investition.ist_aktiv_im_monat existiert (mit stilllegungsdatum), wird aber an 13 Stellen entweder gar nicht oder nur per inline-Check (ohne Stilllegung) angewendet. Backend-SoT-Migration: monatsdaten.py /aggregiert + ha_export.py /api/ha-export (Per-IMD-Filter via ist_aktiv_im_monat, vorher kein Filter); Cockpit-Suite (uebersicht, social, nachhaltigkeit, aktueller_monat, komponenten 2 Stellen), investitionen.py (5 Dashboards + Wallbox-Helper), aussichten.py (zentral beim Laden) — inline-Check durch SoT-Helper ersetzt, bringt Stilllegungs-Korrektheit gratis mit (Memory-Linie feedback_aggregations_drift.md); pdf/jahresbericht.py + cockpit/pv_strings.py beide Endpoints. Schema 0 ≠ None (CLAUDE.md „0-Werte prüfen”): AggregierteMonatsdatenResponse-Komponenten-Felder Optional[float]. None = keine aktive Komponente in dem Monat (vor Anschaffung / nach Stilllegung / Anlage hat den Typ nicht). 0 = Komponente aktiv, IMD vorhanden, Wert echt 0 (z. B. WP-Heizung im Sommer). Frontend AggregierteMonatsdaten + MonatsZeitreihe: nullable Felder durchgereicht, Tabellen-fmtVal rendert null als „—”. JAZ-Kachel zeigte „Jahresarbeitszahl 2023-2026” obwohl WP erst seit 2025: KomponentenTab.tsx berechnet wpZeitraumLabel jetzt aus chartData (Monate mit wp_strom > 0), nicht aus dem Anlagen-weiten zeitraumLabel.
Wh→kWh-Skalierung im Statistics-Pfad von _energy_delta (#232 NongJoWo). Live-Heute zeigte für einen Wh-Sensor Werte mit Faktor 1000 zu hoch (z. B. 87.000 statt 87 kWh). Der _is_energy_sensor-Check, der im Sensor-Mapping-Wizard und im Live-Pfad bereits Wh-Slots in kWh konvertiert, fehlte im Statistics-Fallback der _energy_delta-Helfer. Pfad jetzt konsistent.
Pool-Doppelzählung in Auswertungen → Komponenten (#231 NongJoWo). Wallbox-IMD (Loadpoint-Sicht) und E-Auto-IMD (Vehicle-Sicht) messen oft denselben Stromfluss aus zwei Perspektiven. cockpit/komponenten.py summierte beide → Doppelzählung, PV-Anteil > 100 % möglich. Konsolidierung analog zu aktueller_monat._aggregate: getrennte Akkumulatoren eauto_* + wb_* pro Monat, ist_dienstlich-Filter früh, beim Konsolidieren pro Feld max(eauto, wb). Km/V2H kommen nur vom E-Auto (Wallbox kennt das nicht). Vier neue Akzeptanztests in test_emob_pool_komponenten.py.
Reparatur-Werkbank-UI-State setzt sich nach erfolgreichem Lauf zurück (#234 + #235 detLAN). Nach einem Reaggregations-Lauf (Tag oder Range) blieben Plan-/Execute-Steuerelemente versteckt — Modal-State überlebte zwischen Aufrufen und „Plan erstellen” verschwand nach Execute. RepairWorkbench.tsx setzt jetzt nach Abschluss eines Laufs den vollständigen Editor-State zurück (Form-Felder + Plan-Snapshot + Run-Result).
„Eigene Dateien”-Vorschau zeigt Investitions-Spalten als Tabellen-Spalten (#222 NongJoWo). Wer eine CSV mit ausschließlich auto-erkannten Investitions-Spalten importiert hatte, sah eine Vorschau-Tabelle voller „—” — die Spalten wurden korrekt erkannt, aber die Werte tauchten erst nach dem Apply auf. UX wirkte wie Bug. PreviewMonth.inv_werte: dict[str, float] und PreviewResponse.inv_spalten: list[str] ergänzt; _apply_mapping sammelt manuell inv:-gemappte und auto-erkannte Spalten gleichermaßen ein; bei Doppel-Mapping gewinnt manuell. used_inv_spalten-Set filtert leere Spalten aus der Header-Liste. Frontend rendert dynamische <th>/<td> hinter den fünf Standard-Spalten. Banner-Text „Werte in der Vorschau-Tabelle nicht sichtbar” entfällt. Fünf Akzeptanztests in test_custom_import_preview_inv_werte.py.

Internal

25 neue/erweiterte Akzeptanztests; vier neue Test-Dateien für #231 + #222, je ein Test in test_investition_aktiv_filter.py für #236. Bestehende Regressions-Suiten (emob_pool_komponenten, wp_aggregator_bugs, investition_aktiv_filter, live_history_kwh_scale, repair_orchestrator, provenance, snapshot) bleiben grün.
Frontend TypeScript-Check ohne Fehler nach Schema-Erweiterungen (PreviewMonth.inv_werte, PreviewResult.inv_spalten, AggregierteMonatsdaten nullable Komponenten-Felder).
Memory-Linie feedback_aggregations_drift.md (bereits etabliert, jetzt sechs+ Vorfälle dokumentiert) — bei JSON-Key/Filter/Cap-Drift über mehrere Read-Sites immer SoT-Helper einführen, nie punktuell patchen.

[3.28.0] - 2026-05-13 — Mehrere Tage neu aggregieren in Reparatur-Werkbank (#230)

🪛 Neue Reparatur-Operation REAGGREGATE_RANGE — Schleife über aggregate_day pro Tag, max. 31 Tage pro Lauf, Per-Tag-Commit für Abbruch-Robustheit, Pflicht-Checkbox „ohne Support-Anspruch” im UI. Aus Martins Anregung in #230 zu mehreren Schüben Reaggregation für historische WP-Daten nach Sensor-Wechsel. Bewusst eng dimensioniert (Memory-Linie feedback_kein_grosser_heiler_knopf.md): kein Universal-Reset-Knopf, sondern transparent dimensioniertes Power-User-Werkzeug.

Added

RepairOperationType.REAGGREGATE_RANGE in services/repair_orchestrator.py. Plan validiert von/bis (von ≤ bis, bis < heute, anzahl_tage ≤ REAGGREGATE_RANGE_MAX_DAYS=31), zählt vorhandene Tageszusammenfassungen im Bereich, liefert eine sechspunktige Warnungs-Liste (Per-Feld-Provenance-Überschreibung, MQTT-Only-Verlust-Risiko, Strompreis-Sensor-Verlust-Risiko, Prognose+Korrekturprofil-Erhaltung, Support-Disclaimer). Execute schleift seriell mit aggregate_day(datenquelle="manuell") + optionalem resnap_anlage_range pro Tag, macht Per-Tag-Commit für Abbruch-Robustheit, sammelt Erfolg/keine_daten/Fehlgeschlagen-Counter plus Cap-Detail-Liste (20 Einträge max im Response-Body, vollständig im Backend-Log).
Endpoint POST /api/energie-profil/{anlage_id}/reaggregate-bereich in routes/energie_profil/repair.py. Params von + bis (Pflicht), mit_resnap (Default true). Wrapper über Orchestrator-Plan+Execute.
UI-Operation „Mehrere Tage neu aggregieren” in components/repair/RepairWorkbench.tsx + Metadaten in api/repair.ts. Date-Range-Picker mit 31-Tage-Frontend-Cap (Backend-Cap-Kopie), mit_resnap-Toggle und prominente amber-Pflicht-Bestätigung im Editor-Block. Validierung vor dem Plan-Erstellen (von ≤ bis, bis < heute, anzahl_tage ≤ 31, Checkbox geahkt).

Internal

Drei neue Akzeptanztests in backend/tests/test_repair_orchestrator.py: test_plan_reaggregate_range_rejects_invalid_bounds (drei ValueError-Pfade), test_plan_reaggregate_range_valid_returns_warnings (Warnungs-Liste vollständig), test_execute_reaggregate_range_iterates_and_commits_per_day (Schleife läuft auch nach Tages-Fehler weiter, Summary mit korrekten Zählern, aggregate_day+resnap_anlage_range via AsyncMock). Alle 11 Tests grün.
Memory-Linie feedback_kein_grosser_heiler_knopf.md neu — dokumentiert, warum Massen-Reaggregation kein Default-Vorschlag ist (Reflex zur „pauschalen Heiler-Funktion” kehrt wieder, auch nach Kritik) und unter welchen Bedingungen sie trotzdem verantwortbar gebaut werden kann (explizit, mit Warnung, ohne Support).

[3.27.5] - 2026-05-12 — UX-Cluster detLAN + PV-Ertrag-Spalte (#207 #215 #217 #218 #494)

🪛 detLAN-Cluster aus #203–#218 strukturell abgearbeitet plus eine Spalten-Erweiterung von dietmar1968 (#494). Kein neuer Funktionsumfang — fünf koordinierte Detail-Verbesserungen, die in Summe die UI-Konsistenz spürbar anziehen (Tab-Header vs. Page-Titel, Schaltflächen-Stil, Komponenten-Reihenfolge).

Added

Spalte „PV-Ertrag” in Tages-Energieprofile-Tabelle (#494 dietmar1968). Tagessumme der PV-Erzeugung als neue default-visible Spalte in Gruppe „Tages-Summen”. Wert = Σ über alle komponenten_kwh-Keys mit Prefix pv_ oder bkw_ (snapshot/aggregator.py:get_komponenten_tageskwh). Storage-Migration v1→v2 in localStorage ergänzt die Spalte für existierende User automatisch, ohne deren Spalten-Anpassungen zu überschreiben.

Changed

Live-Header entanimiert (#207 Rainer per PN + dietmar1968 Forum #345 + detLAN). Pulsierender animate-ping-Punkt + animate-spin-Refresh-Spinner produzierten auf schmalen Fenstern Layout-Sprünge ohne UX-Mehrwert (der Update-Timestamp zeigt eh den Stand). Statischer grüner Punkt bleibt als Online-Indikator, von links nach rechts neben Update-Zeile verschoben (detLAN-Vorschlag) — konsolidiert zwei Status-Inseln zu einer. Drei unabhängige User-Meldungen haben den Ausschlag für die Kehrtwende gegeben.
Sechs überflüssige Page-Überschriften entfernt (#218 detLAN). Jeder Sub-Tab benennt seinen Bereich schon — eine darunter wortgleiche h1 frisst nur Platz: Einstellungen → Anlage(n) / Strompreise / Investitionen / Sensor-Zuordnung / Statistik-Import; plus MQTT-Export (#218 P11), wo die Überschrift „HA-Sensor-Export” zudem nicht zum Sub-Tab passte → komplett raus, die Info-Box darunter erklärt schon. Sub-Tab „Anlage” → „Anlagen” umbenannt (Konsistenz zum Plural-Inhalt). Container-Layouts dabei von justify-between auf justify-end umgestellt, wo nur noch eine Action-Bar übrig bleibt.
Vier Refresh-Icons als Schaltfläche statt flach (#217 detLAN, Folgepunkt zu #209 P6). Aktualisieren-Knöpfe in Solarprognose-Setup, Daten-Checker, MQTT-Export und System-Einstellungen waren bisher nackte Icons im text-gray-500-Stil — andere Action-Bars in der App nutzen <Button variant="secondary">. Vier Stellen einheitlich auf Icon + „Aktualisieren”-Label gebracht.
Komponenten-Reihenfolge auf SoT INVESTITION_TYP_ORDER gebracht (#215 detLAN, Folgepunkt zu #211 P4). Vier Stellen im Community-Bereich hatten unterschiedliche Reihenfolgen — Balkonkraftwerk landete oft ans Ende statt zwischen Speicher und WP, E-Auto stand stellenweise vor Wallbox. Statistiken-Tab (Ausstattung + Quoten-Cards), Übersicht-Tab (Komponenten-Benchmarks), Komponenten-Tab (Deep-Dives) auf Speicher → BKW → WP → Wallbox → E-Auto ausgerichtet.

[3.27.4] - 2026-05-12 — Wärmepumpen-Aggregation: Split-Strommessung + Counter-Spike-Cap (#230)

🪛 Zwei strukturelle Lücken im Snapshot-Aggregations-Pfad, beide aus Martins Forum-Befund (#230). Setups mit getrennter Strom-Messung für Heizen/Warmwasser (seit #191 unterstützt) hatten in der Stundenwerte-Tabelle des Energieprofils eine leere Wärmepumpe-Spalte, und WP-Kompressor-Start-Counter-Spikes aus HA-Statistics-sum/state-Mix (siehe #184) standen als 49.000+-Werte in einer einzelnen Stunde, während die Tages-Boundary-Diff sauber bei 0 lag.

Fixed

Wärmepumpe-Spalte in Stundenwerte-Tabelle leer trotz korrekt gemappter Strom-Heizen/-Warmwasser-Sensoren (#230 MartyBr). Wer im Sensor-Mapping getrennte_strommessung=True setzt und die Sensoren strom_heizen_kwh + strom_warmwasser_kwh mappt, hatte zwar im Live-Tagesverlauf eine sichtbare WP-Kurve (Live-Pfad liest HA direkt), aber die Auswertungs-Stundenwerte blieben leer und die Tages-Heatmap zeigte für die WP nichts. Ursache: KUMULATIVE_ZAEHLER_FELDER["waermepumpe"] in keys.py:23 kannte nur den Single-Sensor stromverbrauch_kwh und die thermischen Felder heizenergie_kwh/warmwasser_kwh; die Split-Sensoren wurden vom Snapshot-Writer per _is_kumulativ_feld-Whitelist silently gedroppt, also nie in sensor_snapshots geschrieben. _categorize_counter summierte zudem nur stromverbrauch_kwh als verbrauch_wp, und get_komponenten_tageskwh hatte einen semantisch falschen Fallback heizenergie + warmwasser (thermische Wärmeabgabe, nicht elektrischer Verbrauch — Faktor 4-5× zu hoch). Dreifach-Fix: Whitelist erweitert (Split-Felder mit aufgenommen), _categorize_counter fall-abhängig nach parameter.getrennte_strommessung (analog zur SoT get_wp_strom_kwh() in field_definitions.py), get_komponenten_tageskwh mit korrekter Split-Sensor-Summe statt thermischem Fallback. Anwender mit getrennte_strommessung=True müssen nach dem Update einmal in der Reparatur-Werkbank den betroffenen Zeitraum vollbackfillen, damit fehlende Snapshots aus HA-Statistics nachgezogen werden.
WP-Starts-Spike (49.073) in einzelner Stunde der Stundenwerte-Tabelle, während Tages-Tab denselben Tag mit 0 Starts zeigt (#230 MartyBr). Klassischer Drift zwischen get_daily_counter_deltas_by_inv (Boundary-Diff snap[24:00] − snap[00:00], ignoriert Mitten-Spikes) und get_hourly_counter_sum_by_feld (24× snap[h] − snap[h-1], sieht jeden Snapshot). Wenn HA-Statistics nach Restart sum=NULL liefert und der state-Fallback einen Lifetime-Counter-Wert (Größenordnung 10⁴+) zurückgibt, landet dieser als Snapshot in der DB; der Stunden-Pfad rechnet die nachfolgende negative Differenz korrekt auf 0, aber der Spike-Slot selbst stand ungeklemmt. Plausibilitäts-Cap MAX_PLAUSIBLE_COUNTER_PER_HOUR = 200 ergänzt — WP-Kompressor-Starts sind physikalisch durch Mindeststillstand/-laufzeit auf realistisch < 20/h begrenzt, 200 ist eine 10×-Sicherheitsmarge. Bei Überschreitung Clamp auf 0 + Logwarnung. Nach Reparatur-Werkbank-Reaggregation des Tages bereinigt sich die Anzeige.

Internal

KUMULATIVE_ZAEHLER_FELDER["waermepumpe"] erweitert um strom_heizen_kwh + strom_warmwasser_kwh; _categorize_counter parameter-sensitiv (getrennte_strommessung); get_komponenten_tageskwh analog. Sieben Akzeptanz-Tests in test_wp_aggregator_bugs.py (drei für Kategorisierung, zwei für Tages-Summe, zwei für Counter-Cap). Smoke grün: 217 Routes + 38 Tests.

[3.27.3] - 2026-05-12 — Folge-Päckchen Tester-Bugs (#220 #222 #226 #227 #228)

🪛 Reaktion auf v3.27.2-Tester-Feedback + drei neu gemeldete Bugs. Rainer (#220) und NongJoWo (#222) hatten gemeldet, dass v3.27.2 ihre Probleme nicht gelöst hat — diesmal mit echten Logs/Reproduktionsdaten, sodass die tatsächlichen Bug-Pfade gefunden werden konnten. Plus drei frische Issues von JanKgh und NongJoWo (#226 #227 #228). Alle fünf Fixes lokal reproduziert + verifiziert.

Fixed

CSV-Export “Failed to fetch” trotz HTTP 200 OK (#220 rapahl). Rainers Backend-Logs zu v3.27.2 zeigten: Server antwortet sauber 200 OK, der Browser bricht trotzdem ab. Ursache: Content-Disposition-Header mit filename= enthielt den Anlagenname ungefiltert — bei Sonderzeichen (Umlaute, Leerzeichen, Semikolon, Quotes) wird der Header ungültig und HA-Ingress oder fetch() schließen den Stream als “Failed to fetch”. Frontend (Import.tsx:124) sanitisierte schon — Backend tat es nicht. Fix: _sanitize_column_name() (existierender Helper) auf Anlagenname anwenden + Filename mit doppelten Quotes umschließen. Lokal mit 7 problematischen Namen verifiziert (Leerzeichen, Ä/Ö/Ü/ß, /, ;, ”…”, Newline).
Custom-Import-Vorschau ignorierte auto-erkannte Investitions-Spalten (#222 NongJoWo). NongJos v3.27.2-Fix-Versuch traf den falschen Crash-Pfad. Echtes Problem (mit seiner CSV reproduziert): wenn die Anlage eine passende Investition hat (z. B. “Wollis-ID5”), erkennt der Analyze-Schritt die Spalten via Suffix-Match → Frontend setzt sie auf “Ignorieren”. Beim Apply würden sie automatisch importiert. Preview kannte aber nur das Mapping, nicht die Auto-Erkennung → 29 Zeilen ohne globale Felder gemappt → monate=[] → 400-Fehler. Fix: Preview-Endpoint optional um anlage_id erweitert, ruft dann selbst _detect_investition_spalten() und wertet diese Spalten als gültige Daten-Marker. Frontend reicht selectedAnlageId durch. Lokal mit NongJos CSV verifiziert (29 Monate + Hinweis-Warnung statt 400).
Datenchecker mahnte Batterie-Daten für Monate vor Speicher-Installation (#226 JanKgh). Setup: PV seit 11/2021, Speicher erst ab 11/2022. Datenchecker prüfte nur "speicher" in aktive_typen ohne Datums-Match → warnte für 12 Monate Batterie-Daten an, die per Konstruktion nicht existieren können. Fix: neue Bedingung speicher_aktiv_monate (set), die pro Monat prüft, ob mindestens ein Speicher zu diesem Zeitpunkt aktiv war (Anschaffung erfolgt, kein Stilllegung). Lokal mit verschobenem Anschaffungsdatum verifiziert (0 Vor-Anschaffungs-Warnungen, Folgemonate-Logik unverändert).
Tagesverlauf: Wallbox + E-Auto Pool-Doppelzählung (#227 JanKgh). Wenn beide Investitionen denselben Leistungs-Sensor nutzen (typisch wenn parent_investition_id nicht gesetzt ist) und im Stacking addiert werden, ist Σ Verbrauch um die Fahrzeug-Ladung zu hoch. Bestehender Schutz greift nur bei expliziter parent-Verknüpfung. Defensiver Code-Fix in live_tagesverlauf_service.py: nach Serien-Aufbau Deduplizierung per Leistungs-Entity, Wallbox vor E-Auto priorisiert. Workaround per UI (parent setzen) bleibt der saubere Pfad.
Vollzyklen-Tooltip mit 13 Nachkommastellen (#228 NongJoWo). <ChartTooltip decimals={1} /> im Vollzyklen-pro-Monat-Chart wurde im ELSE-Branch (kein unit, kein formatter) auf String(val) umgeleitet und ignorierte decimals → “10.5252891704708…” statt “10,5”. Fix: decimals wird jetzt unit-unabhängig respektiert, Default zu undefined (statt 0) gesetzt. Bonus: deutsches Komma-Format wird auch ohne unit angewandt.

[3.27.2] - 2026-05-11 — Tester-Bugfix-Päckchen (#220 #222 #223)

🪛 Patch-Päckchen, drei Tester-Bugs hintereinander erledigt: ein CSV-Export-Crash mit Stream-Abbruch („Failed to fetch”), eine unbrauchbare Fehlermeldung in der Custom-Import-Vorschau und eine Doppelzählung im T-Konto der Monatsberichte. Alle drei wurden von Anwendern gemeldet (rapahl, NongJoWo) und ließen sich lokal mit Demo-Daten reproduzieren — kein Hypothesen-Stack, jede Diagnose mit Traceback bzw. Berechnungs-Vergleich bestätigt.

Fixed

CSV-Export brach mit „Failed to fetch” ab, wenn Sonderkosten als String in der DB lagen (#220 rapahl). berechne_sonstige_summen und get_sonstige_positionen in eedc/backend/utils/sonstige_positionen.py crashten mit TypeError, sobald ein sonderkosten_euro- oder sonstige_positionen[*].betrag-Wert als String statt Number gespeichert war (z. B. "150,00" mit deutschem Komma). Das passierte still — der Frontend-Stream brach mittendrin ab und der Browser zeigte nur „Failed to fetch”, ohne Hinweis worauf. Neuer _safe_float()-Helper akzeptiert int/float, "150" und "150,00", alles andere fällt sauber auf 0 zurück statt zu crashen. Profitieren tut nicht nur der CSV-Export — derselbe Helper wird auch von Cockpit-Komponenten, Aktueller-Monat-Aggregaten und dem ROI-Dashboard genutzt; dort hätte der Bug irgendwann denselben Crash ergeben.
Custom-Import-Vorschau warf „Keine gültigen Monatsdaten mit diesem Mapping gefunden”, obwohl die Datei korrekt war (#222 NongJoWo). Wer im Wizard zusätzlich zu den automatisch erkannten eedc-Investitions-Spalten auch noch manuell inv:ID:feld-Slots im Mapping wählte, sah die unhilfreiche Standard-Fehlermeldung. Vorschau erkennt jetzt inv:-Mappings als gültige Daten-Marker und gibt einen erklärenden Hinweis: „X Spalte(n) als Investitions-Daten gemappt — werden beim Import automatisch der zugehörigen Investition zugeordnet”. Plus: bei wirklich leerer Vorschau zeigt die Fehlermeldung jetzt die warnungen-Diagnose (z. B. „247 Zeilen übersprungen — kein gültiges Jahr/Monat”) und nennt konkrete Verdachtsfälle (Datums-Format ISO-Zeitstempel, Dezimalzeichen Punkt vs. Komma) statt nur „prüfe Jahr/Monat”.
PV-Eigenverbrauch-Ersparnis im T-Konto enthielt Wallbox-PV-Ladung doppelt (#223 NongJoWo). Backend berechnet ev_ersparnis = eigenverbrauch_kwh × netzbezug_preis, wobei eigenverbrauch den Direktverbrauch inkl. Wallbox-PV-Ladung umfasst (calculations.py:128–132). Im T-Konto (MonatsabschlussView.tsx:676) wurde von diesem Wert nur BKW + Speicher abgezogen — die Wallbox-PV-Ladung stand parallel als separater „Wallbox — PV-Ladung-Ersparnis”-Posten und damit doppelt in Σ Haben. Filter erweitert um Wallbox-PV-Ladung (Label-spezifisch, damit die nicht doppelt-gezählte „Ersparnis vs. Verbrenner” unangetastet bleibt). Verifiziert mit Demo-Anlage: angereicherte 150 kWh Wallbox-PV-Ladung (= 45 €) ergab Korrektur in exakt dieser Höhe.

[3.27.1] - 2026-05-10 — UX-Sprint A1+A2+A3 & Power-Sensor-Bug (#200)

🪛 Bugfix-Release zwischen den Etappen. Bündelt drei UX-Sprints aus dem detLAN-Cluster (#205/#206/#208/#209/#211/#212/#213/#214) und einen handfesten Datenintegritäts-Bug, den rcmcronny gemeldet hatte (#200): Leistungs-Sensoren (W/kW) ließen sich versehentlich in kWh-Slots des Sensor-Mappings eintragen, der Live-Heute-Pfad rechnete sie dann als kumulative Energie und produzierte Quatsch (mal 0, mal 1000+ kWh). Plus zentrale INVESTITION_TYP_ORDER-Konsolidierung — drei drift-anfällige Reihenfolge-Definitionen wurden auf eine einzige SoT zusammengeführt.

Fixed

Power-Sensor in kWh-Slot rechnete Quatsch (#200 rcmcronny). Wer einen Leistungs-Sensor (unit=kW, device_class=power) in einen kWh-Slot des Sensor-Mappings eingetragen hatte (z. B. „Netzbezug Tageswert”), bekam im Live-Heute-Pfad völlig falsche Tagessummen — meist nahe 0, gelegentlich 1000+ kWh. Drei Schutz-Stellen ergänzt: Live-Pfad (live_history_service:_energy_delta) prüft jetzt vor dem Stats-Lookup, ob der Sensor überhaupt eine Energie-Einheit hat, sonst Trapez-Integration der W-Werte (physikalisch korrekt). Stats-API (ha_statistics_service:get_value_at) gibt bei Sensoren ohne has_sum und Nicht-Energie-Einheit None statt rohen state zurück. Sensor-Mapping-Wizard zeigt eine Warnung „Einheit XXX passt nicht in einen kWh-Slot” mit Wegweiser zum Live-Sensoren-Slot, sobald ein W/kW-Sensor in einen kWh-Slot ausgewählt wird (nicht blockierend, mit Workaround-Hinweis).
Wallbox-Card im Dark Mode war rahmenlos (#211 P1 detLAN). Die Komponenten-Karten in Community → Statistiken → Ausstattung nutzten dynamische Tailwind-Klassen (bg-${color}-50), die der JIT-Compiler beim Build wegpurged hat — bei Wallbox (cyan) war der Dark-Mode-Rahmen daher unsichtbar. Klassen jetzt in einer statischen Map ausgeschrieben; alle fünf Cards rendern zuverlässig.
Performance-Profil Radar-Chart Community-Linie verschmolz mit Gitterlinien (#211 P2 detLAN). Community-Datenreihe war auf #9ca3af (gray-400) gesetzt — identisch zu den Polar-Grid-Linien. Im Dark Mode war die Linie kaum erkennbar. Farbe jetzt amber #f59e0b mit erhöhter Opacity 0.15.
Doppeltes Info-Icon in Aussichten → Prognosen (#212 detLAN, schon in Sprint A1). Eine zweite AlertCircle-Instanz war versehentlich mitgerendert; Imports aufgeräumt.
Plural-Bug „1 Hinweise / 1 Warnungen” im Daten-Checker (#214 detLAN, schon in Sprint A1). Singular/Plural sauber unterschieden.
Übernehmen-Knopf im Monatsabschluss-Wizard verdeckte Number-Input-Spinner-Pfeile (#213 P1 detLAN, schon in Sprint A1). Knopf jetzt neben dem Input statt darüber, Zurück-Button auf <Button variant="secondary"> umgestellt.

Changed

Tab-Navigation in Auswertungen, Aussichten, Community jetzt als Schaltflächen (#208 P1+P4+P5 detLAN). Statt der bisherigen Underline-Tabs jetzt eine einheitliche Pill-Style-Leiste (active = primary-Hintergrund, inaktiv = grau). Neue zentrale <PillTabs>-Komponente in components/ui/ — drift-arme SoT für künftige Tab-Leisten.
Community-Hauptseite ohne Überschrift „Community” (#208 P9 detLAN). Die Seitenüberschrift mit Users-Icon im Hauptmenü-Bereich war redundant zur Hauptnav. Onboarding-Empty-State (wenn noch nicht geteilt) behält die Überschrift als Orientierung.
Daten → Monatsdaten ohne Überschrift, Selektoren in einer Zeile, Anlage-Selektor verschwindet bei einer Anlage (#209 P1+P2+P4 detLAN). Statt <PageHeader title="Monatsdaten"> jetzt nur noch eine rechte Action-Bar mit Anlage-Select (nur sichtbar wenn ≥ 2 Anlagen), „Aus HA laden” und „Neuer Monat” — alles auf einer Zeile.
Cockpit Top-Banner kompakter (#206 P1+P2 detLAN). Großes Home-Icon (h-8 w-8) entfernt, Anlagenname und kWp inline statt zweispaltig. Decoratives Calendar-Icon vor dem Jahres-Filter entfernt — es war nicht klickbar während der Share-Button daneben klickbar war (verwirrend, „weniger ist mehr”).
„Erstellt mit EEDC” jetzt auch in der kompakten Share-Variante (#206 P4 detLAN). Die ausführliche Variante hatte den Hinweis schon, in der kompakten fehlte er — jetzt konsistent in beiden, am Ende des Texts.
Wallbox vor E-Auto in Community Übersicht-Stärken/Schwächen + Komponenten-Tab + Empty-State (#211 P4+P5 detLAN, schon in Sprint A1). Reihenfolge spiegelt Anwender-Workflow: Wallbox als Ladeinfrastruktur vor dem Fahrzeug.
Daten-Checker: Wärmepumpe vor Wallbox (#214 Reihenfolge detLAN). Anomalie-Liste pro Komponente folgt jetzt der zentralen INVESTITION_TYP_ORDER (Wechselrichter → PV-Module → Speicher → Balkonkraftwerk → WP → Wallbox → E-Auto → Sonstiges) statt DB-Insert-Reihenfolge.
Jahresübersicht in Community → PV-Ertrag absteigend (neueste oben) (#211 P3 detLAN).
Auto-Fill Ø-Temperatur im Monatsabschluss-Wizard (#205-Bug Rainer, schon in Sprint A1). WetterDatenResponse und Open-Meteo-Archive ergänzt um temperature_2m_mean; Frontend füllt das Feld pro-Feld auto, wenn es leer ist und die Wetter-Daten verfügbar sind.

Internal

Zentrale INVESTITION_TYP_ORDER-SoT in frontend/src/lib/constants.ts und backend/utils/investition_filter.py (Spiegel). Vorher gab es drei abweichende Reihenfolge-Definitionen: useSetupWizard.ts:INVESTITION_TYP_ORDER, lokale TYP_REIHENFOLGE im PDF-Builder, neuer lib/constants.ts-Versuch. Konsolidiert auf eine SoT, alle Konsumenten umgestellt (5 Frontend-Stellen + Backend Daten-Checker + PDF-Builder). Neue Helper: compareTyp (Frontend) und sort_investitionen_nach_typ (Backend). useSetupWizard.ts:INVESTITION_TYP_LABELS entfernt — alle Konsumenten nutzen jetzt TYP_LABELS aus lib/constants.ts.
<PillTabs>-Komponente als shared Sub-Tab-Primitive in components/ui/. Ersetzt drei nahezu identische, individuelle Tab-Implementationen in Auswertungen/Aussichten/Community. Tooltip-Support via SimpleTooltip, Beta-Badge integriert.
Smoke-Check vor Release (Pre-Check via scripts/smoke.sh) bleibt grün: 217 Routes + 31 Akzeptanz-Tests.

[3.27.0] - 2026-05-10 — Etappe 3d: Daten-Provenance & Reparatur-Werkbank

🧱 Architektur-Etappe — sichtbar als Reparatur-Werkbank im Energieprofil + neue Schutz-Mechanik gegen Daten-Drift. Vier Päckchen aus dem Etappe-3d-Detail-Konzept (docs/KONZEPT-DATENPIPELINE.md): Schema-Fundament für Quellen-Hierarchie pro Feld, Cloud-/CSV-/Backup-Pfade an Provenance angeschlossen, Konflikt-Resolver aktiviert, Reparatur-Orchestrator mit Plan-Vorschau + Apply-Pfad. Plus 3d-Etappenabschluss-Sprint mit drei pragma-verschobenen Refactoring-Tails und einer Pool-Bug-Konsistenz-Fix-Runde. Plus Test-Infrastruktur: pytest-Migration + Pre-Release-Smoke-Skript. Insgesamt 33 Commits seit v3.26.8 + Test-Infra-Commit.

Added

Reparatur-Werkbank im Energieprofil unter „Datenverwaltung” (Etappe 3d Päckchen 4). Operation-Auswahl (REAGGREGATE_TODAY / REAGGREGATE_DAY / VOLLBACKFILL / RESET_CLOUD_IMPORT / KRAFTSTOFFPREIS_BACKFILL_*), Plan-Vorschau zeigt vor dem Apply was sich an welchen Feldern ändert (gruppierte Diff-Tabelle, Sticky-Header, capped 200 Zeilen), Bestätigungs-Knopf „N Änderungen anwenden”, AbortController + Cancel-Knopf nach 30 s, Verlauf-Akkordeon mit Audit-Log-Counter. Die alten Schnellbuttons bleiben als Wrapper bestehen.
Wizard-Hinweis „X Felder durch manuelle Werte geschützt — Reset über Reparatur-Werkbank wenn gewollt” in Cloud-Import-Wizards + CSV-Apply (Etappe 3d Päckchen 2). Manuell gepflegte Werte überleben jetzt Cloud-/Portal-Apply auch bei ueberschreiben=true — die Quellen-Hierarchie blockiert die niedriger-priorisierten Schreiber pro Sub-Key, der Wizard zeigt sichtbar wie viele Felder betroffen waren.
Daten-Checker-Kategorie PROVENANCE_CONFLICT (Etappe 3d Päckchen 3). Macht sichtbar, wenn Cloud-Werte versuchen, manuell gepflegte Werte zu überschreiben — ohne dass eine Reparatur-Werkbank-Aktion läuft.
Plan-API für Reparatur als REST-Layer (POST /api/repair/plan, POST /api/repair/execute/{id}, GET /api/repair/plans, DELETE /api/repair/plans/{id}). Plan-Lookup über In-Memory-Cache mit 1 h Expiry; nach Ablauf liefert Execute 410 Gone.
Test-Infrastruktur: eedc/backend/requirements-dev.txt (pytest + pytest-asyncio, getrennt von Production), eedc/pytest.ini (asyncio_mode=auto), scripts/smoke.sh (Dev-venv + App-Boot mit Routen-Schwelle ≥217 + 31 Akzeptanz-Tests in einem Befehl). scripts/release.sh läuft Smoke-Check als Pre-Check vor dem Version-Bump.

Changed

Quellen-Hierarchie pro Feld aktiv (Etappe 3d Päckchen 1). 22 Source-Labels in fünf Stufen: repair > manual:* > external:cloud_import:* / external:ha_statistics / external:portal_import > auto:monatsabschluss > fallback:*. Höhere Priorität gewinnt; gleicher Rang folgt Last-Writer-Wins. Audit-Log dokumentiert jede Entscheidung (applied / rejected_lower_priority / no_op_same_value).
Manual-Form / Auto-Aggregation / HA-Stats-Import / Custom-Import / Live-Wetter / Kraftstoff-Preis-Service auf write_with_provenance umgestellt (Etappe 3d Päckchen 3). Initial-Migration für Bestandsdaten markiert vorgefundene Werte als legacy:unknown — sie verlieren gegen jeden neuen Schreiber. Akzeptanz: manuelle Korrektur überlebt nächtlichen Auto-Aggregations-Job.
Pool-Doppelzählung E-Auto + Wallbox in Cockpit + Monatsbericht behoben (3d-Etappenabschluss-Sprint, Folge zu Quick-Fix 92d522a8). Bei Setups mit 1 E-Auto + 1 Wallbox produzieren beide Investitionstypen denselben Stromfluss aus zwei Perspektiven (Vehicle vs. Loadpoint) — Aufsummieren ergab z. B. PV-Anteil > 100 %. cockpit/uebersicht.py und aktueller_monat._aggregate (sensor-basierter Pfad ohne InvestitionMonatsdaten) ziehen jetzt das Quick-Fix-Pattern: getrennte Akkumulatoren eauto_* / wb_*, max-Pool pro Feld, PV ≤ Gesamt erzwingen, Dienstwagen-Filter (ist_dienstlich) früh. Saubere Trennung pro Fahrzeug folgt erst in Phase 2 des Wallbox/E-Auto-Konzepts.

Internal

backend/services/provenance.py mit write_with_provenance() + write_json_subkey_with_provenance() (Hierarchie-Check + No-Op-Detection + flag_modified-Pflicht + Append-Only-Audit-Log). 10 Akzeptanz-Tests grün.
backend/services/import_writer.py als gemeinsamer Provenance-Wrapper für Cloud-/CSV-/Portal-Apply-Pfade. Per-Sub-Key-Hierarchie + Full-Payload-No-Op + geschuetzt_count / geschuetzte_felder-Antwort. 7 Akzeptanz-Tests grün.
backend/services/repair_orchestrator.py mit Operation-Enum (7 Werte), FieldDiff / Plan / Result-Models, In-Memory-Cache + Lock + 1 h Expiry, _reset_value_for_field per SQLAlchemy-Reflection für NOT-NULL-Defaults, RESET_CLOUD_IMPORT mit force_override + providers-Filter. 8 Akzeptanz-Tests grün.
Schema-Migration: data_provenance_log-Tabelle + source_provenance-JSON-Spalte in monatsdaten / investition_monatsdaten / tages_zusammenfassung / tages_energie_profil + source_hash-TEXT-Spalte in monatsdaten / investition_monatsdaten. Migrationen idempotent; Initial-Provenance läuft beim ersten App-Start nach Update einmalig.
Refactoring-Tails (3d-P3 + 3d-Etappenabschluss-Sprint): services/energie_profil_service.py von 1224 → 360 → ~46 Zeilen reduziert (rollup / backfill / scheduler_jobs / aggregator / _helpers als Slices); services/monatsabschluss_aggregator.py neu; routes/energie_profil.py (1741 Z) in Paket views.py / repair.py / _shared.py / __init__.py-Fassade zerlegt; routes/monatsabschluss.py (1078 Z) in Paket monatsabschluss/views.py / wizard.py / _shared.py; routes/custom_import.py (1102 Z) in Paket custom_import/analyze.py / preview.py / apply.py / templates.py / _shared.py. App-Boot 217 Routen identisch zum Vor-3d-Stand.
31 Akzeptanz-Tests grün (10 Provenance + 7 ImportWriter + 6 ProvenanceMigrate + 8 RepairOrchestrator). Tests bleiben rückwärtskompatibel als Standalone-Skripte aufrufbar; pytest collected sie ohne Code-Anpassung.

[3.26.8] - 2026-05-09 — Etappe 3c: Energieprofil Read-/Write-Architektur konsolidiert

🧱 Architektur-Etappe — Anwender-sichtbar als Konsistenz-Patch. Vier Päckchen aus dem Etappe-3c-Detail-Konzept (docs/KONZEPT-ENERGIEPROFIL-3C.md): Slot-Konvention zwischen kWh- und Counter-Feldern symmetrisch, Tagesgesamt für Komponenten-Energien strikt aus Boundary-Diff (HA-konform), SensorSnapshots tragen einen Source-Marker als 3d-Schablone, Reaggregate-Modal trennt Resnap+Aggregat klar von „Nur neu rechnen”. Verbessert die Self-Healing-Eigenschaften aus v3.26.6 strukturell — kein neuer Anwender-Knopf, sondern saubere Pfade darunter.

Changed

Counter-Felder folgen jetzt der #144-Backward-Slot-Konvention (Etappe 3c P2, E1). WP-Kompressor-Starts und alle künftigen Counter-Sensoren werden symmetrisch zu kWh-Slots auf das Stunden-Ende ausgerichtet (Slot N = Δ aus [N-1, N)). Vorher trug der Counter-Pfad noch die ursprüngliche Forward-Konvention der Snapshot-Erfassung — bei Re-Aggregation entstand dadurch eine Stunden-Verschiebung gegenüber der kWh-Heatmap. Bestehende Daten werden beim ersten App-Start nach Update einmalig idempotent migriert (migrations-Tabelle, kein User-Eingriff nötig). BoundaryRange-Helper als zentraler Slot-Cutoff für beide Aggregat-Typen.
Tagesgesamt für komponenten-kWh-Felder kommt strikt aus dem Boundary-Diff (Etappe 3c P3, E2). Statt Slot-Σ über 24 Heatmap-Werte wird snap(Folgetag 00:00) − snap(Tag 00:00) als Tagessumme geschrieben — identisch zur Logik des HA Energy Dashboards. Dadurch sind EEDC-Tagessummen ab jetzt strukturell mit HA konsistent, auch wenn ein Slot durch Sensor-Reset/Spike degradiert ist. Slot-Σ bleibt unverändert für die Verteilungs-Heatmap, ist aber jetzt semantisch klar von der „Tagesgesamt”-Sicht (Boundary) getrennt.
Reaggregate-Modal trennt Resnap+Aggregat von „Nur neu rechnen” (Etappe 3c P4, E4). Der Vorschau-Knopf zeigt zwei Aktionsbuttons statt einem: Snapshots neu holen + Tagesaggregat rechnen (langsam, ~275 HA-Stats-Queries) und Nur neu rechnen (sub-sekündlich, wenn Snapshots schon stimmen). Die heuristische Auto-Erkennung aus v3.26.6 setzt den Default, ist aber jetzt User-übersteuerbar — z. B. nach Sensor-Tausch sinnvoll, wenn Snapshots ungeprüft erscheinen. Cancel-Knopf erscheint nach 30 Sekunden Resnap-Laufzeit (bricht nur die Anzeige ab; der Backend-Job läuft idempotent zu Ende).

Added

Source-Marker quelle auf SensorSnapshots (Etappe 3c P1, E3). Jeder geschriebene Snapshot trägt jetzt eine Herkunftsnotiz — ha_statistics, mqtt_inbound, mqtt_live, live_fallback, unknown. Bestehende Snapshots bleiben auf unknown (rückwirkend nicht rekonstruierbar). Schablone für Etappe 3d (Daten-Provenance); wird in der Datenverwaltungs-Seite später sichtbar gemacht. Aktuell Lese-Konsument nur intern im Reaggregate-Pfad (welche Slots dürfen überschrieben werden).

Internal

sensor_snapshot_service.py (1530 Zeilen) in 6 Slices zerlegt als Refactoring-Tail von Päckchen 1. Schnittstelle nach außen unverändert; intern jetzt nach Reader / Writer / Aggregator / Counter-Logik / Migration / Range-Helper getrennt.
aggregate_day in eigenen Slice extrahiert als Refactoring-Tail von Päckchen 3. Tagesaggregations-Logik nicht mehr in Snapshot-Service eingebettet.
Aufräum-Sprint Phase B Konzept-Docs auf v3.26.7-Stand: 9 Konzept-Dokumente (KONZEPT-ENERGIEPROFIL, KONZEPT-INFOTHEK, KONZEPT-KORREKTURPROFIL, KONZEPT-MQTT-GATEWAY, KONZEPT-SPEICHER-AUSWERTUNG, KONZEPT-STROMPREIS-MITSCHRIFT, KONZEPT-UMFRAGE, KONZEPT-WALLBOX-EAUTO, KONZEPT-COCKPIT-LAYOUT) mit aktuellen Status-Headern und Implementierungstabellen. 10 abgeschlossene oder verworfene Docs nach docs/archive/ verschoben (Solcast-Konzept, What’s-new-Banner, Standalone-API-Stub, Drift-Audit-Vorbereitungen, Doku-Sweep-Arbeitsdoku, PN-Drafts). KONZEPT-LIVE-SNAPSHOT-5MIN von drafts/ nach docs/ befördert.
Etappe-3c-Detail-Konzept als docs/KONZEPT-ENERGIEPROFIL-3C.md abgelegt (vier E-Entscheidungen, vier Päckchen P1–P4, Refactoring-Tails). Etappe-3d-Vorbereitungs-Konzept docs/KONZEPT-DATENPIPELINE.md parallel ausgearbeitet (5-Stufen-Hierarchie, Hybrid-Provenance, Konflikt-Resolver, Repair-Orchestrator).

[3.26.7] - 2026-05-09 — UX-Bündel: Pfeile, Schreibweise, Seitentitel

✨ Vier kleine UX-Verbesserungen aus aktivem Tester-Feedback in einem Patch. Live-Heute Batterie-Pfeile alignieren mit dem HA Energy Dashboard, „eedc” und „Home Assistant App” werden durchgängig geschrieben, redundante Seitentitel im Cockpit/Auswertungen/Aussichten/Live-Daten/Community-Vergleich und mehreren Einstellungs-Seiten sind raus.

Changed

Live-Heute Batterie-Pfeile angepasst an HA Energy Dashboard (#201 detLAN). eedc zeigte ▲ Ladung / ▼ Entladung (Tank-Logik), HA zeigt umgekehrt: ▼ Strom in den Speicher rein, ▲ aus dem Speicher raus. eedc folgt jetzt der HA-Konvention. Auch in der Community-Regionen-Tabelle gleichgezogen.
Schreibweise „eedc” durchgängig vereinheitlicht (#199 detLAN). Bisher gemischt EEDC/eedc, ab jetzt überall lowercase wie das Logo und CLAUDE.md-Konvention.
„Home Assistant Add-on” → „Home Assistant App” durchgehend in user-sichtbaren Strings (#199). Die HA-eigenen Menü-Pfade (z. B. „Einstellungen → Add-ons → ⋮”) und Verweise auf andere HACS-Add-ons (Solar Forecast ML) bleiben unverändert.
Redundante Seitentitel entfernt (#196 detLAN). Die <h1>-Doppelung neben dem aktiven Tab/Sub-Tab in 14 Pages ist raus: Dashboard (Übersicht), Aussichten, Auswertung, Live-Daten, Community Vergleich, Daten-Checker, Backup, Solarprognose, Infothek, Einrichtung, Balkonkraftwerk/Speicher/E-Auto/Sonstiges Dashboards. Pages mit dynamischem Untertitel (Anlagenname, Investitions-Bezeichnung) bleiben unverändert — die Top-/Sub-Navigation zeigt die aktive Position bereits sichtbar.

Internal

#200 Folge: Der Code-Fix für die Live-Tageskonsumenten aus v3.26.6 (a435a58f) hatte Ronnys „warte auf Punkt 2”-Comment knapp überholt. Verifikations-Anfrage am Issue gepostet.

[3.26.6] - 2026-05-08 — Reload-Vorschau heilt sich selbst: Counter-Boundary + „Nur neu rechnen”

🩹 Folgehotfix nach v3.26.5 — der Reload-Pfad hatte zwei eng verwandte Lücken, die bei Forum-Tester MartyBr (Sensor-Migration Vicare→Optisplitter, Forum #462ff) sichtbar wurden: erstens überschrieb der Resnap die Folgetag-00:00-Boundary nicht, was den Counter-Tagesdelta auf falscher Skala stehen ließ. Zweitens hing das „Übernehmen” für Tage, deren Snapshots längst aktuell waren, im teuren HA-Stats-Polling fest, statt einfach nur das Aggregat neu zu rechnen. Beides gefixt — die Vorschau erkennt jetzt automatisch, ob Resnap nötig ist, oder ob ein „Nur neu rechnen” reicht.

Fixed

Reload-Range schließt Folgetag 00:00 ein. Bisher resnappte reaggregate-tag nur Vortag 23:00 .. Tag 23:00 — passgenau zur Backward-Konvention der kWh-Slots (#144). Counter-Felder (wp_starts_anzahl, etc.) lesen aber nach Forward (#136) und brauchen snap(Folgetag 00:00) − snap(Tag 00:00) bzw. snap(Folgetag 00:00) − snap(Tag 23:00) für Slot 23. Ohne diesen Boundary blieb ein alter (oft korrupter) Wert stehen und faltete sich beim Reload als Lifetime-Sprung in die Tagessumme. Range jetzt um eine Stunde verlängert; kWh-Konsumenten sind unberührt.
„Nur neu rechnen”-Pfad im Reload-Modal. Wenn die Vorschau zeigt, dass alle Werte alt = neu sind (Snapshots stimmen mit HA-Stats überein, nur das gespeicherte Tages-Aggregat ist veraltet), schaltet der Übernehmen-Knopf automatisch auf mit_resnap=false. Damit entfallen 275 5-Min-HA-Stats-Queries plus die DELETE-Operationen für leere Slots — der Reload geht von „möglicherweise hängend” auf „sub-sekündlich”. Hängt zusätzlich ein blauer Info-Hinweis im Modal („Snapshots sind bereits aktuell”) und ändert das Knopf-Label auf „Nur neu rechnen”.

Internal

Konventionsfalle dokumentiert: ausführlicher Code-Kommentar in reaggregate_tag zur Slot-Konvention (kWh Backward / Counter Forward) und warum die Boundary-Erweiterung NUR den Counter-Pfad heilt, ohne die kWh-Slot-Konvention anzufassen. Verhindert, dass künftige Refactor-Versuche den Konvention-Wechsel von #144 wieder kippen.

[3.26.5] - 2026-05-07 — Setup-Vereinfachung: HA-Energiekonfiguration importieren + Counter im Reload-Vorschau (#197)

✨ Wer schon ein HA-Energy-Dashboard eingerichtet hat, muss seine Sensoren nicht mehr ein zweites Mal von Hand raussuchen. Beim Aufruf des HA-Sensor-Zuordnungs-Wizards liest EEDC /config/.storage/core.energy und befüllt die passenden Felder als Vorschlag vor: Netzbezug, Einspeisung, PV-Erzeugung, Batterie-Ladung/Entladung. Aus der device_consumption-Liste werden zusätzlich Wallbox / Wärmepumpe / E-Auto per Namens-Heuristik (Wallbox/go-eCharger/Keba/Tesla/Daikin/…) den passenden Investitionen zugeordnet. Ein Banner oberhalb des Wizards zeigt, wie viele Sensoren übernommen wurden, plus „HA-Energy-Vorschläge entfernen”-Knopf — der entfernt nur die unveränderten Vorschläge, manuell editierte Sensoren bleiben unangetastet.

Added

Neuer Backend-Service services/ha_energy_service.py liest /config/.storage/core.energy, parst energy_sources (grid/solar/battery) und device_consumption, und liefert Substring-basierte Typ-Erkennung für Wallbox / Wärmepumpe / E-Auto. Add-on-only — auf Standalone-Setups (kein SUPERVISOR_TOKEN) wird available=false zurückgegeben und der Wizard zeigt keinen Banner.
Neuer Endpoint GET /api/sensor-mapping/{anlage_id}/suggest kombiniert die HA-Energy-Vorschläge mit den Investitionen der Anlage und liefert direkt anwendbare Sensor-Mapping-Vorschläge (Speicher → erste Speicher-Investition; device_consumption → erste passende Wallbox/WP/E-Auto-Investition).
Auto-Vorbefüllung im SensorMappingWizard läuft beim ersten Aufruf (= leeres Mapping). Bei späterem Re-Aufruf zeigt der Wizard keinen Banner — manuelle Korrekturen werden nicht überstimmt.
Selektiver Reset-Knopf im Banner: vergleicht den aktuellen Wizard-Zustand mit dem Snapshot der HA-Energy-Vorschläge und entfernt nur die Felder, die unverändert dem Vorschlag entsprechen. User-Anpassungen bleiben erhalten.
Counter-Tagesgesamt im Reload-Vorschau-Modal macht reine Counter-Felder (z. B. WP-Kompressor-Starts) vor dem „Übernehmen” sichtbar — Tageszahl alt → neu, summiert über alle Investitionen pro Feld. Bisher zeigte die Vorschau nur kWh-Energiekategorien; Drift bei Counter-Sensoren nach HA-Restart-Spike fiel erst nach dem Klick auf. Boundary: snap(Tag 00:00) gegen snap(Folgetag 00:00), alt aus DB, neu aus HA-Statistics.

Internal

Heuristik-Reihenfolge im Service: e-auto vor wallbox vor waermepumpe — damit Brand-Tokens wie tesla (= Auto) nicht durch das generischere charger (= Wallbox) überstimmt werden.
Default-Felder pro Investitions-Typ: wallbox→ladung_kwh, waermepumpe→stromverbrauch_kwh, e-auto→verbrauch_kwh. Wenn das Default-Feld in der konkreten Investition nicht existiert (z.B. WP mit getrennte_strommessung=true hat kein stromverbrauch_kwh), wird der Vorschlag stillschweigend verworfen — User mappt manuell.
Field-Definitions sind SoT: get_felder_fuer_investition() filtert die Vorschläge gegen die tatsächlich verfügbaren Felder pro Investition.
Smoketests grün: Heuristik-Suite (12 Cases inkl. Brand-Edge-Cases), End-to-end gegen Winterborn-DB (5 Investitionen, 4 device_consumption-Einträge → 4 Matches inkl. Skip eines WP-Kandidaten ohne passende Investition).

[3.26.4] - 2026-05-06 — Hotfix: Wetter-Backfill schließt jetzt auch die letzten 5 Tage

🩹 Hotfix wenige Stunden nach v3.26.3 — der Wetter-Backfill ließ die letzten 5 Tage strukturell unbefüllt, weil Open-Meteo Archive sie wegen 2-5 Tage Reanalyse-Lag nicht hatte. Per Designkommentar sollten diese Tage über den Live-Forecast-Pfad in aggregate_day mitkommen — aber _get_wetter_ist routete für alle Tage außer heute auf den Archive-Endpoint, also auch für den Vortag, der dort noch fehlt. Resultat: Stratifizierungs-Card zeigte „5 Tage noch nicht geladen” und der Button lieferte „0 Stunden / 0 Tage” — Drift zwischen drei Read-/Write-Sites mit unterschiedlichen Cutoffs.

Fixed

SoT-Helper archive_cutoff() in wetter_backfill_service.py — eine zentrale Stelle definiert die Grenze zwischen Archive- und Forecast-Endpoint (heute - ARCHIVE_LAG_TAGE).
_get_wetter_ist in energie_profil_service.py routet jetzt auf den Forecast-Endpoint für datum >= archive_cutoff(), nicht nur für datum == heute. Damit befüllt aggregate_day für den Vortag (oder rollende Heute-Aggregation) die Wetter-Spalten korrekt aus der Reanalyse-Approximation.
wetter_backfill_anlage holt zwei Range-Calls statt einem: Archive für ältere Tage, Forecast für die jüngsten N Tage. Beide fließen in denselben _fetch_und_update-Helper (Code-Deduplikation). Status ok solange mindestens einer erfolgreich war.
Stratifizierungs-Card-Empty-State löst sich auf, sobald der Backfill-Button geklickt wurde — alle backfill-baren Tage werden tatsächlich geladen, kein “5 Tage noch nicht geladen → 0 geladen”-Geisterbild mehr.

Internal

Drift-Vermeidung (Memory feedback_aggregations_drift.md): ARCHIVE_LAG_TAGE und archive_cutoff() sind die Single-Source-of-Truth, wird von Backfill und aggregate_day gleichermaßen importiert.
Live-Test gegen Open-Meteo (gegen produktive API): Forecast-Endpoint mit start_date/end_date für 5 Tage in der Vergangenheit liefert Stundendaten (cloud_cover/precipitation/weather_code).

[3.26.3] - 2026-05-06 — Hotfix: Aggregator schreibt Skalar auch ohne Day-Ahead-Stundenprofile

🩹 Hotfix wenige Stunden nach v3.26.2 — der Aggregator brach mit status="skipped" / grund="Keine Day-Ahead-Snapshots im Zeitraum" ab, sobald pv_prognose_stundenprofil (seit v3.26.0 mitgeschrieben, vorher leer) im Auswertungszeitraum noch nicht aufgelaufen war. Bestehende Anlagen haben Tages-Prognose pv_prognose_kwh schon seit Monaten, aber das Stundenprofil erst seit Tagen — die Skalar-Stufe war damit auf den meisten Anlagen unerreichbar und der Live-Pfad fiel auf den Legacy-_get_lernfaktor zurück, statt auf den Korrekturprofil-Skalar.

Fixed

Skalar-Stufe wird unabhängig vom Stundenprofil berechnet. _lade_tagesist_skalar zieht die Tages-Aggregation jetzt direkt aus (von, bis) statt aus prog_pro_tag.keys(). Sonnenstand-Bin-Stufen bleiben leer, solange Stundenprofile fehlen — die Skalar-Stufe steht ab Tag 1 zur Verfügung.
Aggregator status="ok" auch bei reiner Skalar-Stufe. Nur bei kompletter Datenleere (weder pv_prognose_kwh noch IST) wird noch geskipped. tage_eingegangen zeigt im UI die Skalar-Tagesanzahl, wenn keine Bin-Tage vorhanden sind.
Heatmap-Card mit Hinweis-Block, wenn nur die Skalar-Stufe vorhanden ist: erklärt, dass Sonnenstand- und Wetter-Bins Day-Ahead-Stundenprofile (pv_prognose_stundenprofil) brauchen und sich über die nächsten Wochen organisch aufbauen.

Internal

Smoketest erweitert um den Fall „30 Tage Tagesprognose + IST, ohne Stundenprofile” → Skalar 0.88 geschrieben, Live-Lookup nutzt Stufe skalar. Empty-Anlage bleibt korrekt skipped.

[3.26.2] - 2026-05-06 — Päckchen 2 Korrekturprofil (Sonnenstand × Wetter live)

✨ Päckchen 2 von zwei — das in v3.26.0 angelegte stündliche Korrekturprofil ist jetzt produktiv. Pro Live-Forecast-Stunde wird die OpenMeteo-Strahlung mit einem Faktor multipliziert, der aus (azimut_bin, elevation_bin, wetterklasse) aus der historischen IST/Day-Ahead-Aufschlüsselung kommt. Fallback-Kaskade hält den Pfad für datenarme Anlagen sanft auf den klassischen Skalar-Lernfaktor.

Added

Korrekturprofil-Tabelle (korrekturprofile) mit (anlage_id, investition_id, quelle, profil_typ) als Scope. JSON-Felder bin_definition, faktoren, datenpunkte_pro_bin tragen alle drei Profil-Stufen ohne Schema-Änderung. Tabelle wird beim Backend-Start via create_all automatisch angelegt; bestehende Installationen brauchen keine manuelle Migration.
Solar-Position-Helper (services/wetter/solar_position.py) — vereinfachter NOAA-Algorithmus, ~0.1° Genauigkeit, keine externe Astro-Dependency. Lokalzeit-Konvertierung über zoneinfo mit Europe/Berlin-Default und Längengrad-basiertem Fallback.
Korrekturprofil-Aggregator (services/korrekturprofil_aggregator.py) — schreibt drei Profil-Stufen pro Anlage:
- sonnenstand_wetter (primär, ~150–200 belegte Bins × 3 Klassen)
- sonnenstand (Fallback ohne Wetter-Achse)
- skalar (O1+O2-Tagesfaktor als letzter Fallback) Idempotent, clamp [0.5; 1.3], Mindest-Summe 1 kWh pro Bin gegen Mini-Quotienten-Verzerrung.
Live-Pfad-Lookup (services/korrekturprofil_lookup.py) mit Fallback-Kaskade und Anlagen-Cache (TTL 1h). Schwellen pro Stufe: ≥10 Datenpunkte (sonnenstand_wetter), ≥15 (sonnenstand), ≥7 Tage (skalar). Aggregator invalidiert Cache nach Re-Build automatisch.
get_live_wetter ersetzt globale Skalar-Multiplikation durch Pro-Stunde-Lookup. Bei fehlendem Profil oder zu wenigen Datenpunkten fällt der Pfad auf den existierenden _get_lernfaktor-Skalar zurück (bewusste Variante 1: Sanftverlauf statt Feature-Flag).
Scheduler-Job korrekturprofil_aggregation täglich um 02:30 (zwischen Energie-Profil-Recovery 02:15 und MQTT-Cleanup 03:00). Iteriert über alle Anlagen mit Koordinaten.
Endpoints POST /api/korrekturprofil/{anlage_id}/aggregate (manueller Re-Build) und GET /api/korrekturprofil/{anlage_id}/profile (Lesen für Frontend).
Heatmap-Card im Prognosen-Vergleich-Tab (KorrekturprofilHeatmapCard.tsx) — Klassen-Tabs (klar / diffus / wechselhaft / Alle), Azimut × Elevation als Farbverlauf, Empty-State mit Aggregator-Trigger, Stats-Zeile mit Tage/Bins/Skalar.

Changed

live_wetter.py — Skalar-Lernfaktor wird zum Fallback hinter dem Pro-Stunde-Korrekturprofil-Lookup. Bestehende _get_lernfaktor_detail-Logik unverändert; nur die Anwendung im Forecast-Loop ersetzt.

Internal

End-to-end-Smoketest (in-memory SQLite, 9 Tests): skipped-Pfade (no geo, no snapshots), ok-Pfad (60 synth Tage → 43 Bins + Skalar 0.8), Lookup-Kaskade über alle drei Stufen, Cache-Invalidation, Idempotenz, fehlende Anlage → None (Caller-Fallback).
profil_typ='stunde' im Schema vorgesehen, vom Aggregator bewusst nicht geschrieben — Sonnenstand-Bins decken denselben Effekt physikalisch sauberer ab; die Saisonbin × Stunde-Stufe ist konzept-doku-konform durch die direkte Skalar-Stufe ersetzt.

[3.26.1] - 2026-05-06 — Hotfix: Backfill-Button auch ohne Day-Ahead-Stundenprofile

🩹 Hotfix wenige Stunden nach v3.26.0 — der “Wetter-Historie nachladen”-Empty-State erschien auf vielen Anlagen gar nicht, weil mein Trigger fälschlich an pv_prognose_stundenprofil hing (Day-Ahead-Snapshot, first-write-wins, auf vielen länger laufenden Anlagen lückenhaft befüllt). Das hat das Hauptfeature von v3.26.0 unsichtbar gemacht.

Fixed

Empty-State-Trigger entkoppelt vom Day-Ahead-Snapshot. Backend-Endpoint /api/korrekturprofil/{id}/stratifizierung liefert jetzt zusätzlich tep_tage_ohne_wetter — Tage im Auswertungszeitraum, an denen mindestens eine TagesEnergieProfil-Zeile noch kein Wetter trägt. Frontend-Empty-State zeigt den Backfill-Button bereits, sobald dieser Wert > 0 ist.
Erklärtext im Empty-State angepasst je nach Datenlage: wenn Day-Ahead-Snapshots existieren → “Card füllt sich danach mit MAE/MBE pro Klasse”; wenn nicht → “Stratifizierungs-Tabelle bleibt vorerst leer, die Wetter-Daten dienen Päckchen 2”.

[3.26.0] - 2026-05-06 — Päckchen 1 Korrekturprofil-Konzept

✨ Daten-Layer + Skalar-Verbesserung für das geplante stündliche Korrekturprofil. Päckchen 1 von zwei: bringt stündliche Wetter-Daten (Bewölkung, Niederschlag, WMO-Code) in TagesEnergieProfil, einen Open-Meteo-Archive-Backfill für 2 Jahre Historie, eine zweite Berechnungsvariante des Lernfaktors (Trim-Mean + Recency-Boost, läuft parallel zum Live-Faktor zu Diagnose-Zwecken) und zwei additive Diagnose-Cards im Prognosen-Vergleich-Tab. Die Solcast-Spalte und die Tab-Struktur bleiben unverändert. Päckchen 2 (Sonnenstand-Bin × Wetterklasse als kombinierter stündlicher Korrekturfaktor) folgt nach Beobachtungs-Phase.

Added

Stündliche Wetter-Spalten in TagesEnergieProfil — bewoelkung_prozent, niederschlag_mm, wetter_code werden bei der täglichen Aggregation automatisch aus dem bereits laufenden Open-Meteo-Fetch mitgeschrieben. DB-Migration läuft beim Backend-Start additiv. Speicheraufwand vernachlässigbar (~3 Floats × 24 h × 365 × 2 Jahre pro Anlage).
Wetter-Backfill-Service + Endpoint (POST /api/korrekturprofil/{anlage_id}/wetter-backfill) — füllt fehlende Wetter-Felder rückwirkend aus Open-Meteo Archive (ERA5-Reanalyse, gratis, 2 Jahre). Strikt additiv: bestehende Werte werden nicht überschrieben. Idempotent. Free-Tier-konform (~30 Calls pro Anlage für 2 Jahre).
Wetter-Klassifikations-Helper (klassifiziere_stunde(), klassifiziere_tag()) in services/wetter/utils.py — drei Klassen (klar / diffus / wechselhaft) mit Schwellen aus Bewölkung, Niederschlag und WMO-Code. Niederschlag-Marker und WMO-Sicht-Beeinträchtigung dominieren.
O1 Recency-Boost + O2 Trim-Mean als Doppel-Variante des Lernfaktors — _aggregiere_o12() läuft parallel zum Legacy-Aggregator auf den gleichen Tagen. Trim-Mean entfernt Sensor-Aussetzer (oberste/unterste 10 % der Tagesquotienten); Recency-Boost gewichtet Tage jünger als 30 Tage mit +30 % stärker. Live-Pfad nutzt weiter den Legacy-Faktor — Aktivierung als Default erst nach mehrwöchiger Beobachtung.
Stratifizierungs-Endpoint (GET /api/korrekturprofil/{anlage_id}/stratifizierung?tage=90) — wetter-stratifizierte Stunden-Genauigkeit (MAE/MBE in % vom IST) der Day-Ahead-Prognose pro Wetter-Klasse, plus Aufschlüsselung pro (Klasse × Stunde) als JSON-Map.
Diagnose-Cards im Prognosen-Vergleich-Tab (additiv, ändert nichts an bestehenden Inhalten) — Lernfaktor-Doppel-Variante (Legacy vs. O1+O2 mit Δ-Anzeige) und Wetter-Stratifizierung (Tabelle MAE/MBE pro Klasse). Beide rendern conditional nur wenn Daten vorhanden sind.
Empty-State-Button „Wetter-Historie nachladen” in der Stratifizierungs-Card. Wenn Day-Ahead-Snapshots vorhanden sind aber Wetter-Historie noch fehlt (typisch direkt nach dem Update), bietet die Card einen Klick-Trigger für den 2-Jahres-Backfill an. Status-Anzeige (lädt / X Stunden geladen / Fehler) inline. Kein automatischer Backfill beim Backend-Start — User behält Kontrolle, kein Quota-Spike beim Add-on-Update.

Changed

prognosen.py Response erweitert um eedc_lernfaktor_o12 und eedc_lernfaktor_o12_delta_pct. Bestehende Felder unverändert, Frontend-Konsumenten ohne O12-Awareness brechen nicht.
_berechne_faktor intern refaktoriert in _filtere_tage + _aggregiere_legacy. Backwards-Compat-Alias bleibt, externe Aufrufe weiter funktionsfähig.
_get_wetter_ist holt zusätzlich cloud_cover, precipitation, weather_code aus Open-Meteo Forecast/Archive (kostet keinen extra Call, die Variablen sind im selben Endpoint).

Documentation

docs/KONZEPT-KORREKTURPROFIL.md v3 verabschiedet — ersetzt v2 vom 2026-05-03. Varianten A/B/C nicht mehr „nur reaktiv”, sondern: eine geplante Ziel-Architektur (Sonnenstand-Bin × Wetterklasse als kombinierte Tabelle, kein multiplikatives Splitting), zwei Päckchen, Variante C bleibt reaktiv. Solcast-Spalte ausdrücklich „bleibt — Tester-Pakt mit Rainer”.

Internal

Konzept-Doku zur multiplikativen Faktoren-Trennung verworfen: Verschattung × Wetter ist eine echte Interaktion, multiplikatives Splitting wäre identifizierungs-bedingt ill-posed. Stattdessen kombinierte Tabelle mit Fallback-Kaskade.
Backfill ist additiv (Marker-Spalte bewoelkung_prozent IS NULL) — feedback_vollbackfill_nur_additiv.md-Linie konsequent fortgesetzt.

[3.25.23] - 2026-05-05

🩹 Tab-Bildlaufleiste auf drei Seiten weg (#193 detLAN) — Patch-Release mit nur einem UI-Fix.

Fixed

Keine permanent sichtbare Scrollbar mehr unter den Tabs auf Auswertung / Aussichten / Community (#193 detLAN) — Die Tab-Header-Zeilen dieser drei Pages tragen jetzt die bereits in SubTabs.tsx und MonatsabschlussView.tsx etablierte scrollbar-none-Utility auf ihrem <nav>-Element. Ursache: das overflow-x-auto für horizontales Tab-Scrolling rendert auf Desktop-Browsern und in der HA Companion-App eine permanente graue Scrollbar-Spur, die wie ein Layout-Bug wirkt. Funktional bleibt alles erhalten — Tabs lassen sich weiter per Touch/Wheel/Drag horizontal wischen.

[3.25.22] - 2026-05-05

🩹 Vollbackfill-Aufräumen + drei Folge-Items aus #190/#191/#182 — Klausnns Hänger im „Lücken überschreiben”-Modus (#190) hat eine Architektur-Frage aufgedeckt: der Overwrite-Modus war ein Recovery-Tool aus Bug-Zeiten und richtet seit den 3.25.x-Counter-Fixes nur noch Schaden an. Er ist deshalb komplett raus. Plus: WP-Strom-Splits im Monatsbericht (#191 rapahl), Scroll-Position beim Monatswechsel (#182 detLAN), Skip-Transparenz im Vollbackfill-Banner (#190 Klausnn).

Changed

Vollbackfill ist nur noch additiv (#190 Klausnn → Architektur) — Der Modus „Bestehende Tage überschreiben” + die zugehörige Pre-Backfill-Resnap-Schleife sind aus dem Code raus. Hintergrund: Der Overwrite-Pfad war ein Recovery-Tool für alte Aggregations-Bugs (Off-by-one in get_value_at v3.25.9, sum/state-Mix #184, Vortag-Boundary, Counter-Doppelzählung). Nach v3.25.20 sind diese Bugs gefixt — der Recovery-Bedarf entfällt. Gleichzeitig hat der Modus dauerhaften Datenverlust verursacht: HA-LTS reicht in vielen Setups (Recorder-Purge, Sensor-Umbau) kürzer zurück als das gepflegte Profil. „Löschen + neu rechnen” als Reflex bei Datenmisstrauen löschte dann Wochen oder Monate Historie unwiederbringlich. Korrekturprofil, saisonale Mustersuche, Speicher-Simulation und Verschleißkurven hängen aber an dieser Tiefe. Konkrete Code-Änderung: backfill_from_statistics und resolve_and_backfill_from_statistics haben den skip_existing/overwrite-Parameter verloren und sind hardcoded additiv. Der Endpoint /vollbackfill?overwrite=... akzeptiert den Param weiter (deprecated), ignoriert ihn aber und schreibt eine Info-Zeile ins Log — schützt alte Frontend-Caches und API-Konsumenten vor Crashes.
UI: „Vollbackfill” → „Energieprofil-Lücken aus HA-Statistik nachfüllen” — Der Knopf in Daten → Energieprofil und die Wizard-Box im Sensor-Mapping heißen jetzt klar nach dem, was sie tun. Die Overwrite-Checkbox ist weg, die rote „Empfohlen nach Updates”-Empfehlungsbox ebenso (sie verwies auf den jetzt obsoleten Overwrite-Modus). Stattdessen ein nüchterner Hinweis auf den Reparatur-Pfad: „Möchtest du einen einzelnen Tag reparieren, der verzerrt aussieht? Nutze den Daten-Checker und den Reload-Knopf in der Tagestabelle (mit Vorschau vor Übernahme).”

Added

Monatsbericht WP: Strom-Splits Heizung/Warmwasser sichtbar (#191 rapahl) — Wer in der Wärmepumpe-Investition getrennte_strommessung=true aktiviert hat (Rainer war Ideengeber dafür), sieht jetzt im Monatsbericht unter „Stromverbrauch” zwei „davon”-Zeilen: Heizung und Warmwasser. Konsistent zur bereits vorhandenen Wärme-Aufteilung darunter. Daten waren in InvestitionMonatsdaten.verbrauch_daten schon vorhanden (strom_heizen_kwh / strom_warmwasser_kwh), wurden aber von der aktueller-monat- und monatsdaten/aggregiert-API nicht herausgereicht. Beide Endpoints + die Pydantic-Response-Models + die TypeScript-Types kennen die Felder jetzt; das Frontend rendert sie nur, wenn das Backend nicht-null schickt — Anlagen ohne getrennte Messung sehen die Zeilen weiter nicht.
Vollbackfill-Banner zeigt Skip-Gründe (#190 Klausnn) — Bisher meldete der Erfolgs-Hinweis nur „X von Y Tagen geschrieben” — der Cap bei z.B. 79,4 % wirkte wie Datenverlust. Tatsächlich werden Tage übersprungen, wenn HA für den Tag keine Statistics-Werte hat (Sensor existierte noch nicht, HA-Recorder war down, …). Das Banner unterscheidet jetzt explizit: „X Tage geschrieben · Y Tage ohne HA-Statistics-Daten übersprungen · Z Tage bereits vorhanden”. Backend-Response (/energie-profil/{id}/vollbackfill) liefert die Werte als uebersprungen_keine_daten und uebersprungen_existiert. BackfillResult-Dataclass entsprechend erweitert.

Fixed

Monatsbericht: Scroll-Position bleibt beim Monatswechsel (#182 detLAN) — Wer im Monatsbericht die Wärmepumpe-Sektion aufgeschlagen hat und auf einen anderen Monat klickt, bleibt jetzt an der Wärmepumpe — die rechte Inhaltsspalte springt nicht mehr ungewollt an den Seitenanfang. Mechanik: vor setSelectedJahr/setSelectedMonat merkt sich MonatsabschlussView die scrollTop des <main>-Containers in einem Ref, ein useLayoutEffect auf monatData stellt sie nach dem Daten-Reload wieder her (vor dem Browser-Paint, kein sichtbares Springen). Der Layout-Reset bei Menüpunkt-Wechsel (Layout.tsx reagiert auf location.pathname) bleibt davon unberührt — innerhalb von Monatsberichten ist der Wechsel ein State-Update, kein Routenwechsel.

Internal

Designprinzip dokumentiert: Vollbackfill ist nur additiv — Neuer Memory-Eintrag feedback_vollbackfill_nur_additiv.md ergänzt feedback_reparatur_statt_loesch_features.md: Aggregations-Bug-Fixes gehören in gezielte Migrations-Skripte im Release, nicht in einen User-Knopf für „alles neu rechnen”. Reparatur einzelner Tage läuft über /reaggregate-tag mit Vorschau (chirurgisch, idempotent). Phase-2-Themen (Lösch-Knopf-Diagnose mit Datenverlust-Vorhersage, Sensor-Mapping-Änderung soll Backfill anbieten, JSON-Restore-Pfad muss vollbackfill_durchgefuehrt-Flag explizit zurücksetzen) sind in einem eigenen GitHub-Issue für späteres Anpacken festgehalten.
resnap_anlage_range bekommt Progress-Logging (alle 5 %) — Die Funktion hat noch zwei legitime Caller (/reaggregate-tag und /diagnostics/...), und der Vollbackfill-Hänger aus #190 hat gezeigt, wie unangenehm sie ohne Log-Output ist. Bei großen Ranges erscheint jetzt regelmäßig „Resnap Anlage X: 240/1440 Stunden (16 %), Y Snapshots geschrieben”.

[3.25.21] - 2026-05-04

🩹 detLAN-Folge zum UX-Bündel: Reihenfolge-Korrektur + Stammdaten-Sortierung + Monatsberichte-Stickybug — Drei Issues aus dem direkten Folge-Tag zu v3.25.19/20: #187 (Reihenfolge falsch interpretiert + Label-Politur), #189 (Stammdaten → Investitionen folgte alter Reihenfolge), #182 (Sticky-Bug in der Monatsberichte-Spalte ließ sich mit overscroll-contain allein nicht beheben).

Fixed

INVESTITION_TYP_ORDER korrigiert auf Cockpit-Banner-Reihenfolge (#187 detLAN) — v3.25.19 hatte Wallbox+E-Auto vor Wärmepumpe gesetzt, weil die #186-Punkte 1/2/5 als „WB/EAuto vorne” gelesen wurden. Das Cockpit-Banner-Bild aus #186 zeigt aber PV-Anlage → Speicher → Wärmepumpe → Wallbox → E-Auto. Korrigiert: wechselrichter, pv-module, balkonkraftwerk, speicher, waermepumpe, wallbox, e-auto, sonstiges. Wirkt zentral aus hooks/useSetupWizard.ts auf alle Konsumenten (SubTabs.tsx, HAStatistikImport.tsx, HAExportSettings.tsx, MappingSummaryStep.tsx, neu auch Investitionen.tsx). Innerhalb des WB/EAuto-Paares bleibt E-Auto unter Wallbox (#186-Detail unverändert).
Stammdaten → Investitionen folgt jetzt der globalen Reihenfolge (#189 detLAN) — pages/Investitionen.tsx hatte eine eigene lokale investitionTypen-Liste mit anderer Reihenfolge (e-auto, waermepumpe, speicher, wallbox, ...), die INVESTITION_TYP_ORDER ignorierte — klassischer SoT-Drift. Die lokale Liste ist entfernt; Reihenfolge + Labels kommen aus INVESTITION_TYP_ORDER + INVESTITION_TYP_LABELS. Innerhalb der Typ-Gruppe wird zusätzlich nach anschaffungsdatum absteigend sortiert (neueste Anschaffung oben, fehlende Datums ans Ende mit Bezeichnungs-Fallback).
Monatsberichte-Sticky-Spalte: Aside selbst zum scrollenden Sticky-Container (#182 detLAN) — v3.25.13 hatte overscroll-contain auf einen inneren Wrapper-Div gelegt; das fing zwar Wheel-Bubble ab, löste aber nicht den eigentlichen Bug, dass die Aside beim Klick auf einen alten Monat (oder beim Mitscrollen der rechten Spalte) verschoben wurde. Ursache: der innere Container hatte max-h-[calc(100vh-6rem)] (viewport-relativ), aber der eigentliche Scroll-Container ist das Layout-<main> (Layout.tsx:99), das ist kleiner als 100vh — TopNav + SubTabs + Footer + Padding ziehen ~10rem ab. Damit war die Aside höher als ihr scroll-Vorfahre, sticky konnte nicht greifen, sie scrollte mit. Fix: Aside selbst trägt sticky top-0 max-h-[calc(100dvh-12rem)] overflow-y-auto overscroll-contain. Reserve 12rem deckt sicher TopNav + SubTabs + Footer + Padding. Plus 100dvh statt 100vh für iOS-Safari (Memory-Pattern).
„km gefahren” → „Gefahrene km” überall (#187 detLAN) — Konsistente Schreibweise in lib/fieldDefinitions.ts (Statistik-Import), pages/EAutoDashboard.tsx (Σ-KPI-Kachel), components/sensor-mapping/MappingSummaryStep.tsx (Mapping-Zusammenfassung), pages/CustomImportWizard.tsx (Spalten-Dropdown), backend/core/field_definitions.py, backend/api/routes/custom_import.py. Ein Label, eine Schreibweise.

Internal

Lesson learned (Drift-Pattern bestätigt) — Drei UI-Stellen mit eigener Sortierung/Reihenfolge sind in den letzten Wochen aufgefallen (SubTabs, HAStatistikImport, Investitionen). Für künftige Reihenfolge-Themen: INVESTITION_TYP_ORDER ist die Single Source of Truth, jede neue UI-Stelle muss sie konsumieren. Der Memory-Eintrag feedback_typ_labels_pattern.md ist um diesen Vorfall ergänzt.

[3.25.20] - 2026-05-04

🩹 Daten-Checker-Fehlalarme: Strompreis-Sensor und Dienstwagen-E-Autos — Joachim-PN-Folge nach v3.25.19. Zwei Warnungen im Daten-Checker, die für ihn (und vermutlich für andere mit gleichem Setup) Fehlalarme waren — beide sind jetzt entfernt.

Fixed

Strompreis-Sensor wird nicht mehr als kWh-Counter geprüft — _check_sensor_mapping_lts listete basis.strompreis zusammen mit Einspeisung, Netzbezug und PV-Gesamt auf und meldete bei fehlendem state_class eine WARNING „kWh-Sensor(en) nicht in HA-Long-Term-Statistics”. Strompreis ist aber ct/kWh oder €/kWh — kein kumulativer kWh-Counter, sondern ein Live-Preis-Sensor. Wir lesen ihn live, nicht aus LTS aggregiert; ein fehlendes state_class ist hier irrelevant. (Joachim-PN: sensor.grid_price_monitor_average_price_today wurde fälschlich angemahnt.) pv_gesamt aus der Liste mit entfernt — wird heute nur als pv_gesamt_w (Live-W) gemappt, ebenfalls kein LTS-Bedarf.
Dienstwagen-E-Autos werden im Energieprofil-Abdeckungs-Check übersprungen — Bei einem als Dienstwagen markierten E-Auto gibt es per Definition keinen PV-Bezug und keine Verbrauchsbilanz; ein kumulativer kWh-Counter wäre ohne Funktion. _check_investitionen (ROI-Check) hatte den Skip schon, _check_energieprofil_abdeckung aber nicht — der hat trotzdem „verbrauch_kwh oder ladung_kwh fehlt” gemeldet. Jetzt konsistent. (Joachim-PN: ID.4 als Dienstwagen meldete trotz korrekt fehlender Zuordnung eine Warnung.)

Internal

Lesson learned: Dienstwagen-Flag muss in ALLEN E-Auto-spezifischen Checks greifen — Bisher war der Skip nur an einer Stelle. Bei zukünftigen E-Auto-Checks daran denken: inv.parameter.get("ist_dienstlich") prüfen, Dienstwagen früh herausfiltern.

[3.25.19] - 2026-05-04

✨ UX-Konsistenz-Bündel — Sammlung von kleinen Schliff-Items aus den Issues #185, #186, #187, #188 + ein Joachim-PN-Befund. Inhaltliche Klammer: Cockpit-Reihenfolge konsistent durchziehen, Statistik-Import lesbar machen, Kraftstoff-Hinweis kontextabhängig, KPI-Kachel-Schreibweise vereinheitlichen, Sensor-Mapping-Badge nur dort wo relevant.

Changed

INVESTITION_TYP_ORDER global auf Wallbox → E-Auto → WP umgestellt (#187/2 detLAN) — Bisher wechselrichter, pv-module, speicher, balkonkraftwerk, waermepumpe, wallbox, e-auto, sonstiges; jetzt ..., wallbox, e-auto, waermepumpe, sonstiges. Wirkt zentral aus hooks/useSetupWizard.ts auf Setup-Wizard, MappingSummaryStep, HAExportSettings und Statistik-Import. components/layout/SubTabs.tsx (Cockpit-Subtab-Reihenfolge) parallel angepasst — Wallbox+E-Auto bilden ein Paar (fest installierte Anschluss-Komponente + mobiler Verbraucher), WP folgt danach.
Statistik-Import (HAStatistikImport.tsx) zeigt deutsche Labels (#187/1 detLAN) — Basis-Felder werden mit FELD_LABELS aufgelöst und im Backend (ha_statistics.py) als Anzeige-Kopie der Werte mit Label-Keys ausgeliefert (einspeisung → "Einspeisung", netzbezug → "Netzbezug", pv_gesamt → "PV Erzeugung Gesamt"). _basis_aktiv-Helper im Import-Endpoint akzeptiert sowohl Raw-Keys als auch Labels für basis_felder (analog zur bestehenden Komponenten-Logik). Investitions-Typ-Badge im Frontend nutzt TYP_LABELS aus lib/constants.ts (waermepumpe → "Wärmepumpe", e-auto → "E-Auto" etc.). wp_starts_anzahl kommt als „Kompressor-Starts” — neuer Eintrag in build_feld_labels() für Counter-Felder, die nicht in INVESTITION_FELDER registriert sind.
Statistik-Import: Komponenten-Reihenfolge nach INVESTITION_TYP_ORDER, Monatsliste chronologisch absteigend (#186/3 detLAN) — Investitionen pro Monat werden jetzt nach INVESTITION_TYP_ORDER sortiert (Wallbox vor E-Auto vor WP, konsistent zum Rest). Monatsliste gespiegelt von aufsteigend zu absteigend (aktuellster Monat oben).
HAExportSettings CATEGORY_ORDER (#186/4 detLAN) — Neue Reihenfolge der „Verfügbare Sensoren”-Kategorien: anlage, energie, speicher, investition, wallbox, e_auto, waermepumpe, finanzen, quote, umwelt, autarkie, performance, sonstige, status. Speicher früh (wichtigste Investition), Komponenten-Detailkategorien direkt hinter investition, Status zuletzt.
Sensor-Mapping-Wizard „Wallbox & E-Auto” (#186/1 detLAN) — Sektions-Titel umbenannt von „E-Auto & Wallbox” → „Wallbox & E-Auto” in SensorMappingWizard.tsx. In EAutoStep.tsx werden Wallbox-Komponenten zuerst gerendert, E-Auto-Komponenten danach (mt-8-Abstand entsprechend verschoben).
Monatsbericht-KPI-Kachel „Kompressor-Starts” (#185 detLAN) — In MonatsabschlussView.tsx werden Σ Monat und Max/Tag getauscht: prominent angezeigt wird jetzt die Monats-Summe (wp_starts_summe_monat), der Verschleiß-Indikator (Tages-Maximum) wandert in den Subtitel. Konsistent zu allen anderen Σ-KPI-Kacheln im Monatsbericht. Title verkürzt von „Kompressor-Starts (Max/Tag)” auf „Kompressor-Starts”.
Kraftstoff-Box nur bei E-Auto-Anlagen (#188 rapahl) — Der Hinweis-Block „Kraftstoffpreise nachpflegen” wird in pages/Monatsdaten.tsx (Monats-Ebene) und pages/Energieprofil.tsx (Tages-Ebene) jetzt zusätzlich gegen investitionen.some(i => i.typ === 'e-auto') geprüft. Ohne E-Auto-Investition ist der Backfill für die Anlage ohne Wert.

Fixed

„keine HA-Statistik”-Badge nur bei kumulativen kWh-Countern (Joachim-PN, Wattpilot) — SensorAutocomplete hat einen neuen Prop requireStatistics (Default true für FeldMappingInput = kWh-Counter, die zwingend Long-Term-Statistics brauchen). Live-Sensor-Aufrufer setzen ihn auf false: LiveSensorSection (alle Live-Felder pro Investitions-Typ — leistung_w, soc, Temperatur, etc.), BasisSensorenStep (pv_gesamt_w, aussentemperatur_c, sfml_*, netz_kombi_w, einspeisung_w, netzbezug_w), PVModuleStep (Live-Leistung pro String). Vorher wirkte der Badge bei W/%/°C-Sensoren wie ein echter Mapping-Fehler, obwohl alles korrekt war — diese Sensoren werden direkt aus dem HA-State gelesen, state_class ist dafür irrelevant.

Internal

INVESTITION_TYP_ORDER-Comment ausführlicher — Begründungs-Kette dokumentiert (Erzeuger/Speicher → Wallbox+E-Auto-Paar → WP → Catch-All) statt nur ein Detail-Hinweis auf detLAN #180. Hilft bei künftigen Reihenfolge-Diskussionen, alle Decisions auf einen Blick.

[3.25.18] - 2026-05-03

🩹 Reload-Knopf heilt jetzt auch den Stunde-0-Spike — mit Vorschau-Tabelle vor Übernahme. Rainer-Befund nach v3.25.17: das Reaggregate-Tool zeigte für 1.5. weiter PV 1.047 / Einspeisung 8.543 / Bezug 2.757 kWh in Stunde 0:00, obwohl 264 Snapshot-Upserts protokolliert wurden. Audit aller Schreib-/Lesepfade hat zwei Bugs aufgedeckt — beide gefixt. Plus: damit das nie wieder „Klick und hoffen” ist, gibt es jetzt eine Übernahmetabelle, die alt vs. neu zeigt, bevor irgendetwas geschrieben wird. Außerdem im Bündel: drei kleine UX-Items aus dem detLAN-Pakt.

Fixed

Reaggregate-Tag deckt jetzt den Vortag-23:00-Boundary ab (Bug A) — Slot 0 = snap(Tag 00:00) − snap(Vortag 23:00), der Reload-Pfad schrieb aber nur Snapshots für Tag 00:00..23:00 (24 Stück). Ein korrupter Vortags-Snapshot — z. B. aus prä-#184-Phase oder einem aussetzenden :05-Job — blieb dadurch in der DB stehen, und Slot 0 zeigte beliebig oft denselben Spike. Der Range erweitert sich jetzt um eine Stunde nach hinten (reaggregate_tag in energie_profil.py:1052). 25 Snapshots werden überschrieben, der Vortags-Boundary wird mit dem aktuellen HA-sum-Wert frisch geschrieben.
live_snapshot_if_missing schreibt keine HA-state-Werte mehr (Bug B, Wurzel von #184) — Der :55-Preview-Job las bisher via ha_state_svc.get_sensor_state() den Sensor-state und schrieb ihn als Snapshot für die anstehende volle Stunde. Bei Tagesreset-Zählern (utility_meter daily) ist state aber etwas anderes als das Statistics-sum: state=Tagesenergie, sum=Lifetime-bereinigt. Wurde der reguläre :05-Hourly-Job danach übersprungen (HA-/Add-on-Restart, Job-Crash), blieb der state-Wert persistent in der Snapshot-Tabelle und produzierte beim nächsten Aggregat einen Lifetime-grossen Stunden-Spike — genau das Symptom aus Issue #184. Der HA-Counter-Pfad ist entfernt; die laufende Stunde im Energieprofil wartet im Add-on-Modus jetzt bis :05 der Folgestunde (wie vor #146). Der MQTT-Pfad bleibt aktiv — MQTT-Topics liefern direkt kumulative Lifetime-Werte ohne state/sum-Split.

Added

Vorschau-Tabelle vor Reload („Übernahmetabelle”) — Statt nach Confirm-Dialog blind zu schreiben, öffnet der Reload-Knopf jetzt ein Modal mit einer Stundentabelle. Pro Kategorie (PV/Einspeisung/Bezug/…) eine Alt-Spalte (DB-Snapshot) und eine Neu-Spalte (Wert aus HA jetzt). Slot 0 ist farblich markiert mit „↤ Vortag”-Hinweis, weil er von der Vortags-23:00-Boundary abhängt. Differenzen über 0.1 kWh sind orange, über 1 kWh fett. Tagesumme alt/neu pro Kategorie obendrauf. Erst nach „Übernehmen” werden die Snapshots geschrieben und der Tag neu aggregiert. „Abbrechen” schreibt nichts. Wenn HA-Statistics nicht erreichbar ist (Neu-Spalte leer), ist der Übernahme-Button gesperrt — verhindert das Heilen mit Null-Werten. Neuer Endpoint GET /api/energie-profil/{anlage}/reaggregate-tag/preview liefert die Tabelle ohne irgendetwas zu schreiben.

Changed

Tagesdetail-Datums-Picker erreicht den heutigen Tag (D#181 detLAN) — Vor/Zurück-Pfeile und der date-Input waren bisher auf gestern gedeckelt mit der Begründung „heute hat noch keinen abgeschlossenen Energieprofil-Tag”. Stimmt nicht: aggregate_today_all schreibt rollierend alle 15 Minuten alle abgeschlossenen Stunden des heutigen Tages. Maximum jetzt heuteISO() in EnergieprofilTab.tsx — der Pfeil zur rechten Seite springt zu heute, sobald gestern der aktuelle Stand ist.
Lade-Indikator mit 250ms-Threshold (D#181 Nachtrag detLAN) — Der Lade…-Span im Tagesdetail-Datum-Picker erschien bei jedem Tag-Wechsel kurz und wurde dann sofort wieder ausgeblendet — auf schnellen Rechnern ein nutzloser Flash, den detLAN als „kann man nicht erkennen, lieber gleich weglassen” beschrieben hat. Statt ihn ersatzlos zu entfernen kommt jetzt ein 250ms-Threshold: ist der Fetch nach 250ms noch nicht fertig, erscheint der Indikator. Schneller Rechner → kein Flash. Langsamer Rechner / Netz → weiterhin sichtbares Feedback.
Wallbox vor E-Auto in INVESTITION_TYP_ORDER (#180 detLAN) — Die Reihenfolge 'e-auto' vor 'wallbox' widersprach dem Cockpit-Subtabs-Pattern (PV → BKW → Speicher → WP → Wallbox → E-Auto → Sonstiges). Inhaltliche Begründung: Wallbox ist eine fest installierte Anlagen-Komponente mit Anschaffungs-/Stilllegungsdatum und JAZ-ähnlicher Effizienz-Auswertung, das E-Auto eher mobiler Verbraucher. Daher Wallbox vor E-Auto. Konstantenfeld in useSetupWizard.ts umsortiert — wirkt auf Setup-Wizard, MappingSummaryStep, HAExportSettings und alle anderen Konsumenten der Konstante in einem Schritt.

Internal

Audit aller Snapshot-Pfade vor dem Fix — :05-Hourly-Job, :55-Preview-Job, Recovery-Job (Startup), vollbackfill (über leistung_w — orthogonal), _fill_gaps_linear (extrapoliert nicht am Rand, ist OK), _upsert_snapshot (UniqueConstraint vorhanden, exakter zeitpunkt-Match), _categorize_counter + Negative-Delta-Schutz, Daten-Checker Spike-Erkennung, alle Resnap-Endpoints, Zeitzonen/DST. Ergebnis: nur die zwei oben gefixten Stellen waren buggy.
Drei Reproduktionstests vor Release (in-memory SQLite, gemockte HA-Statistics): pre-Fix Spike persistent / post-Fix sauber, HA-state-Pfad inaktiv / MQTT-Pfad aktiv, Preview liefert alt/neu ohne zu schreiben. Alle drei grün.

[3.25.17] - 2026-05-03

🩹 Reaggregate-Tag heilt prä-#184-Spikes endlich richtig — Rainer-Befund nach v3.25.16: das Reparatur-Tool unter „Daten → Energieprofil” konzentrierte die Werte am Tagesanfang, statt sie zu reparieren (PV 1047 kW in Stunde 0:00, alle anderen Stunden ~0). Ursache: resnap_anlage_range überschrieb nur Slots, für die HA-Statistics einen Wert lieferte — bei sum=NULL-Slots aus prä-#184-Phase blieb der korrupte alte Snapshot in der DB stehen, und aggregate_day rechnete jedes Mal denselben Spike zurück.

Fixed

resnap löscht Snapshots, wenn HA jetzt None liefert (Rainer-PN 2026-05-03) — Neuer Helper _delete_snapshot_if_exists und ein force_resnap-Parameter in snapshot_anlage / snapshot_anlage_5min. Im Recovery-Pfad (resnap_anlage_range) ist der Modus jetzt aktiv: liefert get_value_at für einen Slot None (typisch für sum=NULL aus prä-#184-Schreibphase), wird der vorhandene Snapshot gelöscht statt belassen. aggregate_day sieht damit eine echte Lücke und überspringt die Slot-Berechnung sauber, anstatt einen falschen Lifetime-Sprung als Stunden-Δ zu interpretieren. Der reguläre stündliche Snapshot-Job (Cron :05) behält das alte Skip-Verhalten — ein temporärer HA-Latenz-Hänger nimmt also keinen frisch geschriebenen Slot weg, nur der explizite Recovery-Aufruf räumt aktiv auf.
Repro-Test (Demo-Daten, in-memory SQLite, gemockte HA-Statistics) — Synthetisches Szenario: korrupter snap(00:00) = 0, sauberes snap(01:00) = 100, HA liefert für 00:00 weiterhin None (sum=NULL). Vor Fix: nach reaggregate bleibt snap(00:00)=0 und Δ Stunde 0 = 100 kWh als Spike (= Rainer’s Symptom). Nach Fix: snap(00:00) wird gelöscht, Δ Stunde 0 = Lücke. Test grün vor Release verifiziert.

Internal

Lesson learned: skip-on-None ≠ idempotenter Recovery — Der :05-hourly-Job will defensiv bleiben (skip statt überschreiben). Der Recovery-Pfad muss aggressiv aufräumen (None → delete). Beides hatte vorher dieselbe Implementierung — force_resnap macht den Unterschied jetzt explizit.

[3.25.16] - 2026-05-03

🧹 Aufräumen statt nachschärfen: WP-Kompressor-Starts ohne Selbstkalibrierung — detLAN-Folge-Beobachtung nach v3.25.14: Cockpit zeigte 146 statt 134 Starts (+12 Drift), Monatsbericht Mai 112. Statt die Eichungs-Logik (baseline = sensor.gesamt − Σ TZ < heute + heute_live-Hochrechnung) noch eine Iteration nachzuschärfen, fliegt sie ganz raus. Σ Lebensdauer im Cockpit kommt direkt aus dem Hersteller-Sensor — Punkt. Drift gegenüber den EEDC-erfassten Tagesinkrementen wird nicht mehr maskiert, sondern bleibt zwischen den Anzeigen sichtbar.

Changed

WP Σ Lebensdauer = Hersteller-Counter direkt (#173 detLAN) — Cockpit-Aggregation get_waermepumpe_dashboard liest den Lebensdauer-Stand jetzt direkt aus dem Hersteller-Sensor (HA-State → HA-Statistics → jüngster Snapshot als Fallback). Keine Wizard-Save-Eichung mehr, keine Live-Hochrechnung, keine Race-Möglichkeit zwischen Save-Zeitpunkt und Aggregations-Job um 00:15. Neuer schlanker Helper get_counter_lifetime in sensor_snapshot_service.py ersetzt compute_counter_baseline + get_counter_today_live. _refresh_counter_baselines aus sensor_mapping.py ebenfalls entfernt — der Wizard-Save schreibt keine Counter-Baselines mehr.
Monatsbericht „Aktueller Monat” zeigt ehrlich was EEDC erfasst hat — wp_starts_summe_monat ist jetzt schlicht Σ TZ Mai, kein Live-Add-on für den heutigen Tag mehr. Wenn diese Summe vom Hersteller-Counter abweicht, ist das in der Anzeige sichtbar (Cockpit zeigt Hersteller-Wahrheit, Monatsbericht zeigt EEDC-Erfassung) — Diagnose ohne Magic.
Tooltip im Cockpit auf eine Zeile geschrumpft — „Aus Hersteller-Sensor (Lebensdauer-Counter)” + Höchste Tagessumme. Drei-Anteile-Aufschlüsselung (Baseline + abgeschlossene Tage + heute live) entfällt, da die zugrundeliegende Berechnung weg ist.

Migration

Alte wp_starts_anzahl_baseline*-Felder in Investition.parameter bleiben in der DB stehen (Deprecated-Regel), werden vom neuen Code nicht mehr gelesen. Keine Migration nötig.
detLAN-Heilung nach Update: Cockpit zeigt sofort Hersteller-Wahrheit (134 statt 146). Falls Mai-Bericht weiter zu hoch erscheint und das nicht der tatsächlichen Schalthäufigkeit entspricht, einzelne Tage in Auswertungen → Energieprofil → Tagesdetail über das Reload-Symbol neu aggregieren.

Internal

Lesson learned: keine Selbstkalibrierung gegen instabile Aggregate — Die compute_counter_baseline-Konstruktion (Eichung an einem Punkt, Aktualisierung der Σ über Zeit) hatte zwischen v3.25.13 und v3.25.15 drei verschiedene Drift-Symptome produziert (Wizard-Save-Persistierung, Tagesverlaufs-Doppelzählung, Aggregations-Drift um 00:15). Der vierte Iterations-Versuch wäre vermutlich auch wieder eine Krücke gewesen. Der direkte Hersteller-Read braucht keine Selbstkorrektur, weil er keine Berechnung kennt — der Sensor selbst ist die Wahrheit. Netto −237 Zeilen Code.

[3.25.15] - 2026-05-03

✨ UX: Vor/Zurück-Pfeile im Tagesdetail-Datum-Picker — Kleinstrelease mit einem detLAN-Item (#181). Die Symmetrie zwischen Monats- und Tagesdetail-Ansicht ist jetzt hergestellt.

Added

Vor/Zurück-Pfeile im Tagesdetail-Datum-Picker (#181 detLAN) — Auswertungen → Energieprofil → Tagesdetail bekommt links und rechts vom Datums-Eingabefeld jeweils einen Chevron-Button (< / >), analog zur bereits bestehenden Monats-Ansicht (EnergieprofilMonat.tsx). Folgetag-Button ist disabled, sobald gestern erreicht ist (heute hat noch keinen abgeschlossenen Energieprofil-Tag). Helper tagVerschieben(iso, n) lokal im Tab. Pattern 1:1 von der Monats-Ansicht übernommen — gleiche Tailwind-Klassen, gleiche Aria-Labels, gleiches Disabled-Verhalten.

[3.25.14] - 2026-05-03

🩹 Forum-Bündel: Counter-Doppelzählung + UI-Polish + WP-Wording — Eine Wert-Korrektur (WP-Kompressor-Starts Σ Lebensdauer wuchs im Tagesverlauf zu hoch, detLAN-Folgebefund aus #173), zwei UI-Bug-Bündel (Großschreibung / Sortierung / Truncation in Sensor-Zuordnung & MQTT-Export, detLAN #180 + #179) und eine seit April fällige Wording-Schärfung (Heizenergie → Heizwärme + Tooltips, rcmcronny #120).

Fixed

Counter-Doppelzählung im Tagesverlauf, Σ vor heute + Live-Hochrechnung (#173 Folge detLAN 2026-05-03) — Nach dem v3.25.13-Fix für die Wizard-Save-Persistierung der Baseline meldete detLAN Folgendes: nach 7 realen Kompressor-Starts heute zeigte das Cockpit Σ Lebensdauer 136 statt 131 — also 5 Starts zu viel. Ursache: TagesZusammenfassung[heute].komponenten_starts wird im Lauf des Tages mehrfach neu berechnet (Snapshot-Job hourly, get_snapshot mit Toleranz-Fenster nimmt jüngsten verfügbaren Snapshot statt morgen 00:00). Sowohl compute_counter_baseline als auch die Cockpit-Aggregation lasen TZ inkl. heute → baseline + Σ_inkl_heute > sensor_gesamt. Fix: heutiger Tag wird konsistent aus TZ-Aggregation ausgeschlossen (datum < today), heutiger Verlauf kommt aus dem Live-Sensor (neuer Helper get_counter_today_live: sensor_live − snapshot(heute 00:00)). Σ Lebensdauer bleibt damit synchron mit dem Hersteller-Counter ohne Doppelzählung. Tooltip im Cockpit zerlegt die drei Anteile getrennt: Hersteller-Baseline + EEDC abgeschlossene Tage + heute live. Gleicher Fix auch im Monatsbericht (Aktueller Monat) — analoger Drift-Mechanismus, gleiche Bug-Klasse zentral konsistent gefixt (Drift-Lesson). Bei MQTT-only-Standalone-Setups ohne Live-State fehlt heute in der Σ bis zum Tagesabschluss — bewusst statt Doppelzählung.
Großschreibung, Sortierung & Sensor-ID-Truncation in Sensor-Zuordnung-Zusammenfassung (#180 detLAN) — Der „Zusammenfassung”-Tab des Sensor-Mapping-Wizards zeigte die Investitions-Typen in Klammern als rohe Enum-Werte ((e-auto), (pv-module), (speicher), (waermepumpe), (wallbox)) statt als deutsche Labels. Feldnamen wurden aus den Backend-Schlüsseln per replace(/_/g, ' ') generiert, ohne Akronym-Behandlung — pv erzeugung (kWh) statt PV-Erzeugung (kWh), wp starts anzahl statt Kompressor-Starts, km gefahren statt Kilometer gefahren. Außerdem schnitt die Sensor-ID rechts auch auf breiten Viewports bei 200 px ab (...sensor.bat...). Fix: Typ-Klammer auf TYP_LABELS-Lookup aus lib/constants.ts, Feld-Labels via FIELD_LABEL_OVERRIDES-Mapping mit Title-Case-Fallback, Investitions-Karten nach INVESTITION_TYP_ORDER sortiert (PV → Wechselrichter → Speicher → BKW → WP → E-Auto → Wallbox → Sonstiges), Sensor-ID-Truncation nur noch auf schmalen Viewports (max-w-[200px] sm:max-w-[300px] md:max-w-[400px] lg:max-w-none).
MQTT-Export: Categories haben deutsche Labels + sprechende Icons + Sortierung + Card-Ecken-Fix (#179 detLAN) — Der „Verfügbare Sensoren”-Block im MQTT-Export-Tab zeigte mehrere Categories (anlage, quote, investition, speicher, status, waermepumpe, e_auto, wallbox) als rohen Enum-Wert mit Pin-Default-Icon, weil deren Mapping in categoryLabels/categoryIcons fehlte. Der Investitions-Sensoren-Block hatte das gleiche Problem in der Klammer ((wechselrichter, (pv-module, (speicher, (wallbox, (waermepumpe, (e-auto). Zusätzlich war die Border-Radius-Ecke des <details>-Wrappers defekt — der Hover-Hintergrund von <summary> schnitt über den Border. Fix: alle Backend-Categories aus SensorCategory-Enum mit deutschen Labels + Icons gemappt, fixe Anzeige-Reihenfolge (Anlage zuerst, dann Auswertungs-Pyramide Energie/Quote/Finanzen/Umwelt, dann Investitions-Aspekte, Status zuletzt), Investitions-Sensoren analog INVESTITION_TYP_ORDER-sortiert, <details> bekommt overflow-hidden.
WP-Wording „Heizenergie” → „Heizwärme” + Tooltips (#120 rcmcronny) — Seit April 2026 versprochen, jetzt nachgereicht. „Heizenergie” wurde in der Eingabemaske mit dem WP-Stromverbrauch verwechselt — COP=1 verrät das, ist aber für Erstnutzer nicht selbsterklärend. Konsistent über alle UI-Stellen umgestellt: Frontend fieldDefinitions.ts (Eingabemaske) und Backend field_definitions.py (HA-Statistik-Wizard / custom_import / Monatsabschluss / FELD_LABELS-Registry), HA-Import-Wizard, Sensor-Mapping-Wizard WaermepumpeStep.tsx, Komponenten-Tab (Formel-Tooltips), WaermepumpeDashboard (JAZ-Heizen-Formel), MappingSummaryStep (FIELD_LABEL_OVERRIDES), Daten-Checker-Meldung. Backend-Schlüssel heizenergie_kwh und CSV-Suffix _Heizung_kWh bleiben unverändert (Backwards-Kompat für bestehende Templates). Neue Hover-Tooltips direkt im Eingabefeld differenzieren elektrisch vs. thermisch:
- Stromverbrauch / Strom Heizen / Strom Warmwasser: „Stromaufnahme … (elektrisch)”
- Heizwärme: „Abgegebene Heizwärme (thermisch) — COP = Heizwärme / Strom”
- Warmwasser: „Abgegebene Warmwasser-Wärme (thermisch)“

Internal

Lesson learned: Aggregations-Drift bestätigte sich erneut — Der #173-Folgebug betraf zwei Read-Sites (Cockpit investitionen.py:get_waermepumpe_dashboard + Monatsbericht aktueller_monat.py). Konsequent zentral statt einzeln gepatcht, neuer Helper get_counter_today_live für die Live-Hochrechnungs-Logik. Memory-Eintrag feedback_aggregations_drift.md um diesen Vorfall erweitert.
Lesson learned: Roh-Enum-Werte in der UI sind Drift-Indikator — Sowohl #180 (Sensor-Zuordnung-Zusammenfassung) als auch #179 (MQTT-Export-Investitions-Sensoren) zeigten Investitions-Typen als rohe inv.typ-Strings statt als deutsche Labels. Wenn ein User-sichtbarer Roh-Enum-Wert auftaucht, gibt es wahrscheinlich noch andere unbemerkte Stellen — TYP_LABELS aus lib/constants.ts ist die Single Source of Truth, sollte überall verwendet werden statt String-Konkatenation.

[3.25.13] - 2026-05-02

🩹 Forum-Bündel: Werte-Bug + Layout-Korrekturen — Ein Werte-Bug in den Investitions-Parametern (Wizard-only-Keys gehen beim Save verloren), drei Layout-Bugs aus detLAN-Reports (Mobile-Sortable-Sections nicht erreichbar, Energiefluss-Eckenfix bei Sunset/Alps, Layout-Lücken bei mittlerer Fensterbreite, iOS-Body-Scroll-Drift) sowie zwei vorgezogene Werte-Fixes aus dem Rainer-Bündel (Counter-Spike sum/state-Vermischung, WP getrennte_strommessung JAZ-Konsistenz).

Fixed

Wizard-only-Parameter beim Investitionen-Speichern erhalten (#173 detLAN) — Beim Speichern eines Investitionen-Form (z. B. „Wärmepumpe → Speichern”) schickte das Frontend ein neu zusammengebautes parameter-JSON ans Backend, das nur die im Form sichtbaren Felder enthielt. Das Backend ersetzte das ganze parameter-Objekt im Replace-Modus — Wizard-only-Felder wie wp_starts_anzahl_baseline (von _refresh_counter_baselines in sensor_mapping.py geschrieben) wurden bei jedem Form-Save gelöscht. Folge: detLAN’s WP-Kompressor-Starts-Baseline wurde beim Schließen des Investitionen-Dialogs (auch ohne Datenänderung) auf None gesetzt, das Cockpit zeigte nur noch die Σ der EEDC-Tagesdifferenzen statt Baseline + Σ Tagesdifferenzen. Frontend mergt jetzt parameter mit dem bestehenden investition.parameter statt es zu ersetzen — Wizard-Keys bleiben erhalten. Nach dem Update einmalig Sensor-Zuordnung → Speichern & Abschließen zur Neusetzung der Baseline.
Counter-Spike durch sum/state-Vermischung in get_value_at (#184 Rainer-PN 2026-05-01) — Reproduziert auf synthetischer HA-DB: sum=NULL/state=5 und sum=2390/state=11 in aufeinanderfolgenden Slots erzeugten Δ=2385 statt der echten Δ=6. Ursache: get_value_at priorisierte sum ohne den vorangegangenen state-Pfad zu berücksichtigen; sobald HA für einen Slot keinen sum lieferte (kurzfristig nach Restart oder Sensor-Lücke), griff der Code auf state zurück, im nächsten Slot wieder auf sum — die Differenz mischte beide Quellen. Jetzt: konsistent eine Quelle pro Range, mit korrekter Behandlung von measurement-only-Sensoren (has_sum=False).
WP getrennte_strommessung JAZ-Konsistenz + obsoleter Sensor (#183 Rainer-PN 2026-05-01) — Drei Schichten: (1) Aggregation: neuer SoT-Helper get_wp_strom_kwh(data, params) in field_definitions.py, an 8 Read-Sites genutzt (Cockpit Komponenten/Übersicht/Social/Nachhaltigkeit, Monatsbericht, Monatsdaten, Aussichten ROI+Finanzen, HA-Export, Community-Service, PDF-Jahresbericht). Bei getrennte_strommessung=True wird Gesamt-Strom aus strom_heizen_kwh + strom_warmwasser_kwh berechnet, der alte Sammel-Sensor wird ignoriert. (2) UI: MappingSummaryStep.tsx rendert den alten Stromverbrauch-Sensor bei aktivierter getrennter Messung mit (obsolet)-Badge + reduzierter Opazität + Tooltip. (3) Daten-Checker: zusätzlicher INFO-Hinweis im _check_wp_monatsdaten-Pfad.

⚠ Nachträglich richtiggestellt (September 2026): Der Satz „der alte Sammel-Sensor wird ignoriert” gilt nur, wenn beide getrennten Zähler gepflegt sind. Fehlt einer, zählt der zugeordnete Gesamtzähler weiter — in jeder Sicht. Das Kennzeichen sagt, wie gezählt wird, nicht ob.
Sortable Sections in Monatsbericht-Mobile-Ansicht erreichbar (#175 detLAN) — Mit aufgeklappter Energie-Bilanz-Sektion konnten die Sektionen darunter (Community-Vergleich, Speicher, Wärmepumpe, E-Mobilität, Balkonkraftwerk, Sonstiges) im Mobile-Viewport nicht erreicht werden — der Scroll-Bereich endete bei Finanzen. Ursache: flex-1 und min-h-0 auf dem inneren <main> und Outer-Flex-Container waren ohne lg:-Prefix gesetzt. Im Mobile-flex-col-Mode mit unbestimmter Container-Höhe ergibt das einen Henne-Ei-Konflikt — der Browser kollabiert die Höhe falsch, Sections darunter liegen außerhalb des Layout-Scroll-Bereichs. flex-1 und min-h-0 jetzt mit lg:-Prefix — auf Desktop unverändert, Mobile-Layout fließt natürlich.
Mobile-Sticky-Scroll-Containment in Monatsberichten (#182 detLAN) — Beim Scrollen in der linken Sticky-Monatsspalte (Desktop) oder am Mobile-Selektor bubbelten Wheel-Events nach Reach-End auf den Hauptseiten-Scroll → die rechte Inhaltsspalte wurde mitgescrollt und der WP-Fokus ging verloren. overscroll-contain Tailwind-Klasse auf den Sticky-Scroll-Container fängt die Events lokal ab.
Sunset/Alps-Eckenfix für Effekt-Layer (#164a detLAN) — In v3.23.7 wurde der Hintergrund-<rect> der Sunset/Alps-Tile auf clipPath="url(#ef-photo-clip)" (mit rx="8") umgestellt. Die Effekt-Layer (Krepuskulare Strahlen, Atmosphären-Bögen, Mondlicht-Strahlen, Sterne, Aurora) blieben aber außen vor — sie nutzen ef-sky-clip / ef-sea-clip / ef-alps-sky-clip, die einfache Rechtecke ohne Border-Radius sind. Die Effekte ragten somit in die abgerundeten Tile-Ecken. Lösung: zusätzlicher <g clipPath="url(#ef-photo-clip)">-Wrapper um die Sunset- und Alps-Effekt-Blöcke zieht den Border-Radius über alle inneren Layer.
Energiefluss-Layout-Lücken bei mittlerer Fensterbreite (#164b detLAN) — Im Bereich 1024–1280 px war die Heute-Box höher als das natürliche Aspect-Ratio des Energiefluss-SVGs zuließ. Das Grid (lg:grid-cols-3) zog den linken Container auf gleiche Zeilenhöhe → SVG mit preserveAspectRatio="xMidYMid meet" zentrierte sich vertikal mit Lücken oben/unten. Side-by-Side-Layout jetzt erst ab xl: (≥1280 px) — im md/lg-Bereich stapelt Heute-Box unter dem Energiefluss, was detLAN’s eigenem Fix-Vorschlag entspricht.
iOS-Body-Scroll-Drift auf kleinen Viewports (#161 detLAN) — Auf iOS Safari/WKWebView (HA Companion) und in Browser-DevTools mit iPhone-SE-Simulation konnte der Document-Root (Body/HTML) unabhängig vom Layout-Wrapper (h-dvh overflow-hidden) scrollen — die App ließ sich so weit nach oben schieben, dass nur noch die HA-Titelleiste sichtbar blieb (auf iPhone SE: schwarze leere Fläche unter dem Footer). Ursache: HTML/Body hatten kein eigenes overflow/height-Constraint. index.css setzt jetzt html, body { @apply h-full overflow-hidden overscroll-none } — Layout-Wrapper bleibt der einzige Scroll-Owner. Auf Desktop und größeren iPhones (11/16 Pro) keine sichtbare Veränderung; iPhone SE und HA-Companion-App profitieren.

Internal

Lesson learned: min-h-0 + flex-1 immer mit Breakpoint-Prefix in Multi-Layout-Containern — Der #175-Bug zeigt einen wiederkehrenden Henne-Ei-Konflikt: flex-Klassen ohne lg:-Prefix wirken auch in flex-col-Mode (Mobile), dort ohne Container-Höhe undefiniert. Wenn ein flex-Container je nach Breakpoint zwischen flex-col und flex-row schaltet, müssen flex-Höhen-Klassen (flex-1, min-h-0) konsistent mit dem Breakpoint des Direction-Switches stehen. Beobachtung in MEMORY festgehalten.

[3.25.12] - 2026-05-02

📝 Doku-Nachreichung zu v3.25.11 — WAS-IST-NEU.md um die drei User-sichtbaren Highlights aus v3.25.11 (Sonstige Erträge im T-Konto, Pool-Doppelzählung Wallbox/E-Auto, Daten-Checker verbrauch_kwh/ladung_kwh) ergänzt sowie um den Self-Heal-Workflow gegen Counter-Spikes. Kein Funktions-Code geändert, nur die In-App-Hilfe.

Changed

WAS-IST-NEU.md aktualisiert — vier neue Einträge oben in der Liste, Stand-Header von v3.25.10 auf v3.25.12 gezogen. Wer in der In-App-Hilfe „Was ist neu” aufruft, sieht die v3.25.11-Wert-Korrekturen jetzt direkt am Anfang. Die ausführliche technische Beschreibung steht weiterhin im v3.25.11-CHANGELOG-Block.

[3.25.11] - 2026-05-02

🩹 Sammelpatch: Counter-Spike Self-Heal + Monatsbericht-Korrekturen — Drei neue Selbstheilungs-Wege für Snapshot-Verzerrungen (Folge des in v3.25.10 behobenen Off-by-one-Bugs) und drei Bug-Fixes aus einer Joachim-Tester-PN (sichtbare Sonstige Erträge, Pool-Doppelzählung E-Auto/Wallbox, Daten-Checker-Drift verbrauch_kwh ↔ ladung_kwh).

Fixed

Sonstige Erträge im T-Konto + Monatsergebnis (Joachim-PN) — Erfasste Erträge mit typ='ertrag' (z. B. AG-Erstattung beim Dienstwagen) waren auf der HABEN-Seite des Monatsbericht-T-Kontos nicht sichtbar und wurden im Monatsergebnis ignoriert; für E-Autos mit Dienstwagen-Flag wurde der ganze Wirtschaftlichkeits-Branch übersprungen. Backend wertet sonstige_positionen jetzt typ-unabhängig pro Investition aus, neue Aggregat-Felder sonstige_ertraege_euro/sonstige_ausgaben_euro/sonstige_netto_euro auf der Response. Frontend rendert pro Investition eigene HABEN- und SOLL-Zeilen und korrigiert das Monatsergebnis auf gesamtnettoertrag − betriebskosten + sonstige_netto. User mit Dienstwagen-AG-Erstattung sehen das Monatsergebnis um den Erstattungsbetrag weniger negativ.
Pool-Doppelzählung E-Auto/Wallbox in der Monatsbericht-Aggregation (Joachim/Gernot-PN) — _collect_saved_data und _load_vorjahr summierten ladung_kwh und ladung_pv_kwh über E-Auto- und Wallbox-Investitionen kommentarlos auf, obwohl beide Typen denselben Stromfluss aus zwei Perspektiven messen (Wallbox = Loadpoint, E-Auto = Vehicle). Folge bei zwei Testern: kWh/100km etwa doppelt so hoch wie real (Smart EQ Februar 61,6 statt ~20), PV-Anteil > 100 % möglich (April 189 %). Quick-Fix: getrennte Akkumulatoren pro Investitionstyp, pro Feld die größere Quelle als Wahrheit, PV ≤ Gesamt als harte Sicherung. Saubere Per-Fahrzeug-Trennung folgt mit Phase 2 des Wallbox/E-Auto-Konzepts. Folge-Pfade cockpit/uebersicht.py und der HA-Stats-/MQTT-Aggregator bleiben bewusst auf der alten Pool-Logik — werden mit Phase 2 mitgezogen.

⚠ Nachträglich richtiggestellt (September 2026): Die Regel „pro Feld die größere Quelle“ ist abgelöst. Seit Juni 2026 bestimmt eine feste Regel die Heimlade-Quelle; die letzte Stelle mit der Größer-Regel, der laufende Monat in Cockpit → Monat, folgt ihr seit September 2026. Seither ist die Wallbox die Summe aller Ladungen an ihr, jedes Auto mit eigener Messung trägt diese, und der Rest der Wallbox geht an die Autos ohne eigene Messung.
Daten-Checker akzeptiert verbrauch_kwh UND ladung_kwh für E-Autos (Joachim-PN) — Schema-Drift: das E-Auto-Field-Schema definiert das Gesamt-Ladung-Feld als verbrauch_kwh (was der Sensor-Mapping-Wizard entsprechend anbietet), der Daten-Checker verlangte aber ladung_kwh. User mit korrekt gemapptem Sensor sahen trotzdem die Warnung „Komponenten ohne kWh-Zähler-Abdeckung”. erwartete_felder-Struktur auf Liste-von-Alternativen umgestellt; für E-Autos zählt jeder der beiden Schlüssel als gemappt. Konsistent mit get_eauto_ladung_kwh-Helper, sensor_snapshot_service und dem Monatsbericht-Pfad.

Added

Counter-Spike Self-Heal — drei zusammengehörige Reparatur-Pfade (Rainer-PN-Spike 2026-05-01) — Hintergrund: das v3.25.3-Cluster (Phase 1 5-Min-Snapshots aktivieren) hat den damals noch vorhandenen get_value_at-Off-by-one (behoben in v3.25.10) erstmals als sichtbaren Counter-Spike sichtbar gemacht (Slot 10:00 mit 2384 kWh statt 5 kWh). Bestehende Snapshot-Werte mussten manuell repariert werden — bisher nur via F12-Console.
- A: Vollbackfill mit overwrite=True zieht Snapshots frisch — Bei aktiviertem Überschreiben ruft backfill_from_statistics jetzt vor der Pro-Tag-Schleife resnap_anlage_range für den gesamten Bereich auf. Das schreibt SensorSnapshots (hourly + 5-Min wo HA-Retention reicht) mit dem korrigierten get_value_at-Pfad neu, danach läuft der Aggregat-Pfad gegen frische Daten. skip_existing=True-Initial-Backfill bleibt unverändert. Frontend-Banner ergänzt um den Reparatur-Aspekt.
- B: „Tag neu aggregieren”-Button mit Resnap-Vorlauf — Endpoint /reaggregate-tag bekommt mit_resnap-Parameter (Default true). Vor dem Aggregat werden die SensorSnapshots des Tages frisch aus HA-Statistics gezogen, dann läuft aggregate_day gegen die korrigierten Werte. Power-User können via ?mit_resnap=false auf das alte Verhalten zurückfallen.
- C: Daten-Checker-Kategorie ENERGIEPROFIL_PLAUSIBILITAET — Macht Counter-Spikes im Tagesprofil sichtbar statt Tester selbst forschen zu lassen. Schwelle: pv_kw oder einspeisung_kw > Anlagen-kWp × 1,5 (eindeutig unphysikalisch). Prüfraum: letzte 30 Tage TagesEnergieProfil. Detail-Meldung pro Tag mit betroffenen Stunden + Werten. Verweist auf den Reparatur-Workflow B. Doku in HANDBUCH_DATEN_CHECKER.md (Kategorie 9, neue §4.7 + §5.6).

Changed

Konzept-Doc KONZEPT-WALLBOX-EAUTO.md Phase 2 ergänzt — Daten-Checker-Warnung bei Pool-Pflege-Mismatch (E-Auto + Wallbox beide gepflegt, Werte erkennbar dieselbe Realität) als zusätzlicher Phase-2-Bestandteil dokumentiert. Hintergrund kommt aus dem Pool-Doppelzählungs-Befund 2026-05-02.

Internal

Resnap-Endpoint v3.25.10 wird produktiv genutzt — Die in v3.25.10 hinzugefügte Resnap-Funktion (POST /api/diagnostics/resnap-snapshots) bleibt als manuelles Diagnostik-Werkzeug; A und B nutzen den darin gekapselten resnap_anlage_range-Helper jetzt im regulären Service-Pfad.

[3.25.10] - 2026-05-01

🐛 Off-by-one-Stunde-Bug in Counter-Snapshots behoben — HAStatisticsService.get_value_at las den state einer Zeile bei start_ts ≈ zeitpunkt, während HA’s Konvention “last value of the period” ist: state(start_ts=11:00) ist der Zählerstand AM ENDE der Stunde, also um 12:00 Uhr. Damit waren alle SensorSnapshot-Werte seit v3.19 (Snapshot-Rework, Issue #135) systematisch um eine Stunde nach hinten verschoben. Tagessummen sind unbeeinflusst (zirkular), aber Stundenwerte im tages_energie_profil sind betroffen.

📦 Bündelt v3.25.9 mit ein — der separat geplante v3.25.9-Release (Drift-Audit-Bündel G) wurde zwischen dem Schreiben des CHANGELOGs und dem eigentlichen Release vom Off-by-one-Fix eingeholt. Statt zwei Releases im Abstand von Minuten zu schießen, sind beide Pakete unter Tag v3.25.10 zusammengefasst. Die [3.25.9]-Sektion unten beschreibt den Bündel-G-Anteil — sie hat kein eigenes Tag, ihr Code (field_definitions.py-Reader-Helper, DB-Migration _migrate_verbrauch_daten_keys_v326) ist Teil von v3.25.10. Tag-Sprung 3.25.8 → 3.25.10 ist beabsichtigt.

Fixed

get_value_at Off-by-one + sum-Bevorzugung — Lookup-Target jetzt zeitpunkt - period_length (1h hourly, 5min short_term), Spalte sum mit Fallback auf state für measurement-Sensoren ohne has_sum. sum ist zusätzlich reset-bereinigt (HA tracked Resets transparent), state springt nach Tagesreset zurück. Befund verifiziert via HA-MCP gegen sensor.sn_3012412676_pv_gen_meter auf Winterborn 2026-05-01: HA Energy Dashboard 11–12 = 8.897 kWh = change(start_ts=11) = sum(start_ts=11) - sum(start_ts=10) ✓. Bug war maskiert durch (a) Tagessummen-Symmetrie und (b) HA-:05-Latenz, die beim Hourly-Job oft den korrekten Vorgänger-Slot lieferte. Mit Phase-1 5-Min-Snapshots wurde die Diskrepanz erstmals systematisch sichtbar.
Konsequenz für Phase 1 Live-Snapshot 5-Min — Vor diesem Fix hätte das Frontend-Wiring auf 5-Min-Counter-Snapshots die Live-Tagesverlauf-Linie um 1 Stunde nach hinten verschoben. Phase-1-Frontend war deshalb zurückgehalten. Nach Resnap der letzten 7 Tage (siehe unten) und positivem Drift-Vergleich gegen HA Energy Dashboard kann das Wiring angegangen werden.

Added

POST /api/diagnostics/resnap-snapshots?days=N&include_5min=true — Schreibt für alle Anlagen die SensorSnapshots der letzten N Tage (1–14, default 7) neu. Sowohl hourly :00 als auch 5-Min Sub-Hour-Slots werden mit dem korrigierten get_value_at-Pfad regeneriert. Gedacht für Validierung nach Service-Bugfixes — der get_value_at-Fix schlägt sonst nicht auf bestehende Snapshot-Werte durch.
snapshot_anlage_5min(force=True)-Parameter — bestehende 5-Min-Slots überschreiben statt überspringen. Wird vom Resnap-Endpoint genutzt, regulärer Scheduler-Job bleibt idempotent (force=False).

Internal

resnap_anlage_range(von, bis, include_5min) — Helper in sensor_snapshot_service.py, iteriert über Stunden (und optional 5-Min-Slots) und ruft snapshot_anlage/snapshot_anlage_5min mit force=True. Wiederverwendbar für künftige Service-Bugfixes oder die “Per-Tag-Reaggregation” UX.

[3.25.9] - 2026-05-01 (kein eigener Tag — mit v3.25.10 ausgeliefert)

🧹 Aufräum-Release ohne User-sichtbare Wirkung — Letzter Bündel der Drift-Audit-Initiative aus v3.25.7/v3.25.8. Schließt 23 verstreute Doppel-Read-Stellen und konsolidiert die Daten in verbrauch_daten-JSONs auf kanonische Schlüssel. Werte-Anzeigen ändern sich nicht.

ℹ️ Tag-Hinweis: Diese Sektion hat kein eigenes Git-Tag. Der Code (Reader-Helper + DB-Migration _migrate_verbrauch_daten_keys_v326) ist Teil von Tag v3.25.10 — siehe v3.25.10-Sektion oben für die Begründung.

Changed

Zentrale Reader-Helper für verbrauch_daten-JSON (Bündel G) — Bisher waren Doppel-Read-Muster der Form data.get("a", 0) or data.get("b", 0) für historisch umbenannte Felder an 23 Stellen über das Repo verstreut. Bei künftigen Schema-Wechseln musste jede einzelne Stelle gefunden und angepasst werden — ein Drift-Risiko, das bei jeder Code-Generation neu auflebt. Fünf Reader-Helper in core/field_definitions.py (get_pv_erzeugung_kwh, get_wp_heizenergie_kwh, get_eauto_ladung_kwh, get_speicher_netzladung_kwh, get_sonstiges_verbrauch_kwh) sind jetzt SoT. Alle 23 Stellen aufgerufen statt direkter .get()-Doppel-Reads. Künftige Schema-Wechsel betreffen nur einen Helper.

Internal

DB-Migration _migrate_verbrauch_daten_keys_v326 — Schreibt Legacy-Keys in InvestitionMonatsdaten.verbrauch_daten auf den kanonischen Key um, sofern der Kanon-Key noch leer ist (wenn beide gesetzt, gewinnt der Kanon-Key). Pro Investitions-Typ unterschiedliches Mapping — verbrauch_kwh bei Sonstiges ist legitim und wird NICHT migriert. Idempotent, mit synthetischer Drift-DB verifiziert. Konsolidierte Pairs:
- erzeugung_kwh → pv_erzeugung_kwh (PV-Modul, BKW)
- heizung_kwh → heizenergie_kwh (WP)
- verbrauch_kwh → ladung_kwh (E-Auto, Wallbox)
- speicher_ladung_netz_kwh → ladung_netz_kwh (Speicher-Arbitrage)
Migration läuft bei jedem Add-on-Start einmalig in database.py:run_migrations(). Bestehende Anlagen profitieren automatisch, kein User-Eingriff nötig.

⚠ Nachträglich richtiggestellt (September 2026): Für das E-Auto war die Umbenennung verbrauch_kwh → ladung_kwh falsch, und „kein User-Eingriff nötig“ traf dort nicht zu: verbrauch_kwh war am E-Auto kein alter Name der Ladung, sondern der Fahrverbrauch. Die Startroutine hat ihn seit 01.05.2026 bei jedem Start in eine Heimladung umgebucht und den Verbrauch gelöscht — die kWh/100 km verloren ihren Messwert. Seit September 2026 geschieht das nicht mehr; Umbuchungen seit dem 09.05.2026 werden beim ersten Start einmalig zurückbenannt. Frühere bleiben stehen, weil sie von echten alten Ladungen nicht zu unterscheiden sind. Unauffällig war es, weil ein Fahrverbrauch als Ladung plausibel aussieht.
Drift-Audit-Initiative abgeschlossen — Mit diesem Release sind alle 16 Drifts aus 6 Domänen (INVENTUR-DRIFT-AUDIT.md) abgearbeitet. Bündel A (WP) in v3.25.7, Bündel B+C+D+E+F (E-Auto, Konstanten, Speicher-Spread, Strompreis-Helper, Filter) in v3.25.8, Bündel G (Field-Reader) in v3.25.9.

[3.25.8] - 2026-05-01

📊 Drift-Audit-Initiative — als Folge des #178-Fixes (siehe v3.25.7) eine systematische Inventur aller Investitions-Berechnungen durchgeführt. 16 Drifts in 6 Domänen identifiziert (INVENTUR-DRIFT-AUDIT.md). Diese Version bündelt die Fixes für 5 davon (Bündel B, C, D, E, F). User-sichtbare Hauptänderung: Speicher- und V2H-Ersparnis im Aussichten-Tab werden jetzt nach demselben Spread-Modell berechnet wie das Investitionen-Detail (~25 % niedriger als vorher) — siehe Erklärung unten.

Changed

Speicher- und V2H-Ersparnis im Aussichten-Tab: Spread-Modell statt Voll-Strompreis (Bündel D) — Bisher rechnete Aussichten entladung × Bezugspreis, das Investitionen-Detail aber entladung × (Bezug − Einspeise). Bei typischem Tarif (30/8 ct) ergab das 36 % Differenz für dieselbe Anlage. Der ökonomisch korrekte Wert ist der Spread, weil die Speicher-Energie ohne Speicher als Einspeisung Vergütung erwirtschaftet hätte — nur die Differenz ist echter Netto-Gewinn. Aussichten ist jetzt auf das Spread-Modell umgestellt → User sehen bei einer Anlage mit z. B. 2000 kWh Durchsatz/Jahr nicht mehr 600 €, sondern 440 € Speicher-Ersparnis. V2H-Berechnung folgt der gleichen Logik. SpeicherDashboard-Label im Frontend korrigiert (vorher: „× Strompreis”, war eine Lüge).
Cockpit-E-Auto-Ersparnis liest jetzt User-Werte (Bündel B) — Bisher waren in den Cockpit-Stellen 7 L/100 km Vergleichsverbrauch und 1,80 €/L Benzinpreis hartcodiert; der gepflegte Pflege-Wert wurde ignoriert. Cockpit zeigte deshalb 7–9 % höhere Ersparnis als Aussichten/PDF (die respektierten den Pflege-Wert schon). Jetzt rufen alle Stellen denselben Helper auf, kanonische Defaults (7,5 L / 1,65 €/L). Folge: Cockpit-Ersparnis sinkt typisch um 3–5 % auf den korrekten Wert.
Hartcodierte Konstanten zentralisiert (Bündel C) — Wirkungsgrade Gas/Öl (0,90 / 0,85 in 13 Stellen), CO2-Faktoren (0,38 / 2,37 in 7 Stellen) und Default-Tarife (8,2 ct Einspeise in 6 Stellen, 30 ct Bezug in 6 Stellen) werden jetzt aus zentralen Modulen gelesen statt überall dupliziert. Keine User-sichtbare Änderung außer minimalem CO2-Drift bei Gas (0,2 → 0,201 kg/kWh, ≈ 0,5 % höher — der korrekte Wert).

Fixed

Cockpit-Wärmepumpe-Detail / KomponentenTab Ersparnis ignorierte User-Pflege (#178 Folge, Bündel A) — Bereits in v3.25.7 released, hier nur als Anker. Vier UI-Stellen rechneten unterschiedliche WP-Ersparnis für dieselbe Anlage (7 € / 61 € / 77 € / 61 €). Helper services/wp_wirtschaftlichkeit.py mit kanonischer Formel + Param-Key-Fix.
Speicher-Dashboard ignorierte Anlagen-Tarife (Bündel E) — Speicher-Endpoint nutzte bisher die hartcodierten Query-Param-Defaults 30 ct/8 ct statt die Anlagen-Tarife aus der DB zu lesen. Jetzt werden Anlage-spezifische Tarife herangezogen (netzbezug_arbeitspreis_cent_kwh, einspeiseverguetung_cent_kwh).
Strompreis-Lookup-Kaskade vereinheitlicht (Bündel E) — Drei verschachtelte Ternäre der Form wallbox_tarif → allgemein_tarif → 30.0 durch zentralen Helper resolve_strompreis_for_komponente(tarife, "allgemein|waermepumpe|wallbox") ersetzt. Künftige Tarif-Änderungen wirken jetzt automatisch in allen Endpoints.
Cockpit-Prognose, HA-Sensor-Export und Community-Server-Submission ignorierten Anschaffungsdatum-Filter (Bündel F) — Drei Endpoints aggregierten InvestitionMonatsdaten ohne den seit v3.23.1 in den anderen Endpoints aktiven Anschaffungsdatum-Check. Folge: Wenn User vor-Anschaffungs-Daten via CSV-Backfill geladen hatte (z. B. WP-Daten ab Januar, obwohl WP erst im April installiert), flossen diese in Cockpit-Prognose, HA-Sensor wp_ersparnis_euro und in den Community-Server-Datensatz ein. Jetzt nutzen alle drei Investition.ist_aktiv_im_monat(jahr, monat). Fix verhindert künftig korrupte Community-Submissions.

Internal

Inventur-Dokument INVENTUR-DRIFT-AUDIT.md — 6 Domänen × 16 Drifts dokumentiert mit Render-Stellen-Matrix, Soll-Formel und Fix-Priorität. Ankerdokument für künftige Drift-Issues — bei neuen Forum-Berichten erst hier prüfen.
Neue Service-Helper als Single Source of Truth: wp_wirtschaftlichkeit.berechne_wp_ersparnis() (Bündel A, schon in v3.25.7), eauto_wirtschaftlichkeit.berechne_eauto_ersparnis() (B), speicher_wirtschaftlichkeit.berechne_speicher_ersparnis() / berechne_v2h_ersparnis() (D). Konstanten-Module core/wirtschaftlichkeit_defaults.py (Backend) + lib/wirtschaftlichkeitDefaults.ts (Frontend).
Bündel G (Field-Reader-Helper für verbrauch_daten-Schema-Drift mit DB-Migration, 27+ Doppel-Read-Stellen) wird in einer separaten Folge-Version umgesetzt — Migration-Risiko, sollte allein laufen.

[3.25.7] - 2026-05-01

⚠ Folge-Patch zum internen Test-Feature — interessiert nur, wer den Diagnose-Endpoint nutzt (siehe v3.25.5).

Fixed

fix(diagnostics): Microsecond-Mismatch im Live-Snapshot-5-Min-Endpoint — In den Checks 4 (Mitternachts-Boundary) und 6 (Verdichtungs-Garantie) verglich der SQL s.zeitpunkt = datetime('YYYY-MM-DD HH:00:00'), die DB speichert die Werte aber als 'YYYY-MM-DD HH:00:00.000000' (mit Microseconds). String-Equality matched nicht → beide Checks lieferten fälschlich skip mit „keine vollständigen Stunden”. Fix: beide Seiten durch datetime() normalisieren, das strippt die Microseconds.

[3.25.6] - 2026-05-01

Changed

chore(addon-config): Add-on-Option live_snapshot_5min_enabled als TEST markieren + WAS-IST-NEU.md aktualisieren — Drei kosmetische Klarstellungen zur Vermeidung versehentlicher Aktivierung des internen Test-Features:
- Add-on-UI Translation: Neue eedc/translations/de.yaml + en.yaml geben der Option im Konfig-UI einen sprechenden Namen („5-Min-Snapshots (TEST — bitte aus lassen)”) + Beschreibung („Internes Test-Feature … Standard-User: aus lassen … wird nach Validierung entfernt”). Andere Optionen ohne Translation bleiben mit YAML-Key-Anzeige (additiv).
- CHANGELOG-Hinweis-Block prefix in v3.25.3 + v3.25.5 Release-Einträgen — die in GitHub Releases sichtbare Notiz „internes Test-Feature, default off, Standard-User brauchen nichts zu tun”.
- WAS-IST-NEU.md auf v3.25.5 hochgezogen + zwei klar User-sichtbare v3.25.3-Features ergänzt (#173 WP-Lebensdauer-Counter im Cockpit, #175 SortableSection in PV/WP/Monatsabschluss-Dashboards). Live-Snapshot 5-Min bewusst NICHT erwähnt — Test-Features gehören nicht in die User-Pflege-Seite.

[3.25.5] - 2026-05-01

⚠ Internes Test-Feature — live_snapshot_5min_enabled ist eine Option für die Phase-1-Validierung der Counter-basierten Live-IST-Linie. Standard-User brauchen nichts zu tun (default off). Wird nach Abschluss der Tests entfernt oder default aktiviert.

Fixed

fix(addon-config): live_snapshot_5min_enabled als Add-on-Option exposen — In v3.25.3 als Env-Var LIVE_SNAPSHOT_5MIN_ENABLED im Backend eingeführt, aber vergessen in eedc/config.yaml (options: + schema:) zu deklarieren und in eedc/run.sh als Env-Var aus /data/options.json zu exportieren. Konsequenz: User sehen die Option im Add-on-Konfig-UI gar nicht und können das Phase-1-Backend nicht aktivieren — die Schnittstelle war bisher nur per Standalone-Docker mit eigenem Env-Var-Setup erreichbar. Fix: Boolean-Option live_snapshot_5min_enabled (default false) im Add-on-UI sichtbar, run.sh mappt sie nach LIVE_SNAPSHOT_5MIN_ENABLED. Dadurch lässt sich Phase 1 jetzt ohne Standalone-Workaround testen.

[3.25.4] - 2026-05-01

Added

feat(diagnostics): Endpoint /api/diagnostics/live-snapshot-5min für Phase-1-Validierung — Wrapper um die sechs Checks aus scripts/check-live-snapshot-5min.sh, gibt JSON statt Terminal-Output zurück. Per curl http://<addon-host>:8099/api/diagnostics/live-snapshot-5min aus dem LAN abrufbar (kein Auth, weil Add-on-API im LAN läuft). Ersetzt das sqlite3-im-Container-Skript für den schnellen Fern-Check; das Skript bleibt als Standalone-Fallback. Gibt zusätzlich Scheduler-Job-Status (sind die neuen 5-Min-Crons registriert?), Feature-Flag-Wert und eine summary-Zeile mit PASS/WARN/FAIL-Tendenz zurück. Wird zur Frontend-Wiring-Entscheidung des Live-Snapshot-Pfads gebraucht (Voraussetzung: Drift gegen HA Energy Dashboard = 0, keine Glitches).

[3.25.3] - 2026-05-01

⚠ Live-Snapshot 5-Min ist ein internes Test-Feature — die in diesem Release eingeführte Add-on-Option (offiziell ab v3.25.5) ist für die Phase-1-Validierung gedacht. Standard-User brauchen nichts zu tun (default off, keine User-sichtbare Wirkung). Wird nach Abschluss der Tests entfernt oder default aktiviert.

Added

feat(live-snapshot-5min): Backend-Infrastruktur für Counter-basierte Live-IST-Linie (Phase 1, Konzept KONZEPT-LIVE-SNAPSHOT-5MIN.md) — Heute lesen die Live-Tagesverlauf-Linie und das Wetter-Widget die IST-Stunden aus dem Power-Sensor (W) per Trapez-Integration über on-change-States. HA Energy Dashboard liest aus dem kWh-Counter (sum-delta). Beide weichen typisch um 1–3 % ab, weil die Trapezregel über ungleichmäßig verteilte Stützstellen systematisch driftet — Anwender sehen das als „die Linien stimmen nie überein, irgendwas an EEDC fabriziert Werte” (Rainer-PN 2026-04-30, hat als Konsequenz seine Energieprofil-Daten gelöscht „weil die eh falsch sind”). Lösung: kaskadierte Counter-Snapshots — wie bisher hourly für historische Tage (sensor_snapshots mit zeitpunkt.minute = 0, dauerhaft), plus 5-Min-Auflösung für den laufenden Tag (zeitpunkt.minute ∈ {5,10,…,55}, Cleanup nach 24h). Schema bleibt unverändert — SensorSnapshot.zeitpunkt: DateTime ist seit v3.19 granularitätsfrei.

Diese Phase implementiert nur die Backend-Infrastruktur:
- Settings.live_snapshot_5min_enabled (Env-Var LIVE_SNAPSHOT_5MIN_ENABLED, default off) — Roll-out per Anlage über Add-on-Config
- HAStatisticsService.get_value_at(short_term=True) — liest aus statistics_short_term statt statistics (HA hält die 5-Min-Slots ~10–14 Tage vor)
- snapshot_anlage_5min() — schreibt 5-Min-Snapshots, idempotent (überspringt belegte Slots, damit der reguläre :05-hourly-Job die :00-Snapshots nicht zerschießt), Toleranz 3 min gegen Latenz-Jitter
- cleanup_5min_snapshots() — löscht Sub-Hour-Slots > 24h via strftime('%M', zeitpunkt) != '00'
- Scheduler-Jobs sensor_snapshot_5min (*/5:30 — 30s nach jeder HA short-term-Boundary) und sensor_snapshot_5min_cleanup (täglich 00:30), beide nur registriert wenn Flag an
- Restart-Recovery in sensor_snapshot_startup_recovery um 5-Min-Slots seit 00:00 heute erweitert (nur wenn Flag an)
Frontend-Wiring (live_tagesverlauf_service) ist bewusst zurückgestellt bis zur empirischen Bestätigung, dass die 5-Min-Snapshots auf einer realen Anlage stabil entstehen und der Drift gegen HA Energy Dashboard wirklich auf 0 fällt — sonst riskieren wir, dass die neue IST-Linie aus zu wenigen oder verglitchten Slots Murks rendert. Roll-out-Reihenfolge: Flag auf Winterborn aktivieren, ein paar Tage Snapshots sammeln (SELECT COUNT(*) FROM sensor_snapshots WHERE strftime('%M', zeitpunkt) != '00' sollte ~288 × Counter-Anzahl/Tag ergeben), dann Tagesverlauf-Linie umstellen und Default-on schalten. Power-Pfad bleibt als Fallback für Anlagen ohne Counter-Sensoren (häufig WP/Wallbox).
feat(wp-starts-baseline): Hersteller-Lebensdauer-Counter integrieren (Issue #173) — Wärmepumpen-Hersteller wie Nibe oder Viessmann haben einen Counter „Kompressor-Starts gesamt” (Lebensdauer ab Werks-Inbetriebnahme, oft 4-stellig im Auslieferungszustand). EEDC zählt erst ab Sensor-Aktivierung über Snapshot-Differenzen — die historische Baseline fehlte, sodass das WP-Cockpit unter „Kompressor-Starts Σ” einen viel zu kleinen Wert zeigte (z.B. 87 statt 5.234). detLAN’s Vorschlag im Issue: Baseline einmalig beim Wizard-Save eichen (baseline = sensor.gesamt − Σ(eedc-Tagesdifferenzen seit Inbetriebnahme)), dann beim Anzeigen Σ_lebensdauer = baseline + Σ(eedc-Tagesdifferenzen) rechnen. Selbstkorrigierend bei Wizard-Rerun.

Implementierung: compute_counter_baseline liest den aktuellen Sensor-Wert (Live-State → HA-Statistics → jüngster Snapshot) und subtrahiert die kumulierten EEDC-Tagesdifferenzen aus TagesZusammenfassung.komponenten_starts ab inv.anschaffungsdatum. Das Ergebnis wird beim Sensor-Mapping-Save automatisch in inv.parameter.{wp_starts_anzahl}_baseline abgelegt (_refresh_counter_baselines) — Fehler beim Baseline-Lookup (z.B. Sensor noch unavailable) brechen das Mapping-Save nicht ab, sondern werden geloggt. WP-Cockpit (WaermepumpeDashboard.tsx:308) zeigt Σ_lebensdauer = baseline + EEDC, mit Tooltip-Zerlegung „Hersteller-Baseline (Wizard-Save) + EEDC seit Aktivierung + höchste Tagessumme”.

Changed

chore(ui): SortableSection als wiederverwendbare Komponente extrahiert + auf 3 Cockpit-Dashboards ausgerollt (Issue #175, detLAN-Vorschlag) — Die seit v3.21.0 im Auswertungs-Tab vorhandene Auf-/Zuklappen-+-Sortierung-Mechanik war an die MonatsabschlussView hartgekoppelt. detLAN hat im Forum vorgeschlagen, dasselbe Verhalten auch in andere Cockpit-Ansichten zu bringen. Refactor:
- Neue UI-Komponente SortableSection (mit OrderedSections-Container) und Hook useSectionOrder extrahiert. Persistiert die User-Reihenfolge per Anlage in localStorage (Schlüssel eedc.section_order.{viewKey}.{anlageId}).
- MonatsabschlussView.tsx auf die neue Komponente migriert (-199 Zeilen — der Großteil war duplizierter Drag-Drop-Boilerplate, jetzt im SortableSection-Modul).
- PVAnlageDashboard.tsx und WaermepumpeDashboard.tsx auf SortableSection umgebaut — die WR-Karten / KPI-Sektionen / Komponenten-Listen lassen sich jetzt einzeln einklappen und neu anordnen, Reihenfolge wird pro Anlage gespeichert.
Verhalten ist 1:1 identisch zur bisherigen Auswertungs-Implementierung, nur eben jetzt überall. Konzept-Skizze in docs/drafts/archive/KONZEPT-COCKPIT-LAYOUT.md.

[3.25.2] - 2026-04-30

Fixed

fix(wp-starts): Slot 23:00 + Tagesaggregat-Lücke bei Kompressor-Starts (Issue #136) — Im stündlichen Snapshot-Pfad (sensor_snapshot_preview_job) crashte der :55-Vorab-Snapshot-Job seit Einführung in v3.21.0 (Issue #146) still mit NameError: timedelta is not defined — der Import in scheduler.py:9 fehlte. Konsequenz: der 00:00-Boundary-Snapshot wurde nicht vorab geschrieben, sondern musste vom regulären :05-Job ab Mitternacht aus HA Statistics gezogen werden. Bei Counter-Sensoren ohne state_class (typisch Nibe/Viessmann WP-Starts) ist die LTS-Tabelle zu :05 oft noch leer → Snapshot fehlt → sowohl Slot 23 im Tagesdetail (get_hourly_counter_sum_by_feld braucht snap[24]) als auch der Tageswert in Monatsbericht/Cockpit-WP (get_daily_counter_deltas_by_inv braucht snap @ 00:00 Folgetag) bleiben leer. Beide Lücken haben dieselbe Wurzelursache. Fix: timedelta zum Import ergänzt — :55-Job läuft wieder und schreibt den 00:00-Snapshot vorab als Live-Approx, der reguläre :05-Job überschreibt ihn später mit dem exakten LTS-Wert. detLAN-Mehrfach-Beobachtung über mehrere Tage.

Changed

chore(pv-cockpit): Module + Speicher nebeneinander in 2-Spalten-Grid (Issue #172) — In PVAnlageDashboard.tsx:273-318 waren die Sub-Sektionen Module und Speicher innerhalb der Wechselrichter-Karte vertikal gestapelt — bei vielen Komponenten wirkte die Karte länglich und unausgewogen. Jetzt nebeneinander in grid-cols-1 md:grid-cols-2 (Desktop zwei Spalten, Smartphone weiterhin gestapelt), gemäß detLAN-Mockup. Innerhalb jeder Sub-Sektion bleiben Werte rechtsbündig (ml-auto), Bezeichnung darf truncaten.

[3.25.1] - 2026-04-29

Fixed

fix(hilfe): Interne Links + Anker im Inhaltsverzeichnis funktionieren wieder — Drei Bugs in der seit v3.24.0 verfügbaren In-App-Hilfe (Hilfe.tsx):
- Anker-Links im Inhaltsverzeichnis zerstörten die Hilfe-Seite. Klick auf TOC-Einträge wie [Installation](#2-installation) setzte window.location.hash auf #2-installation, was den HashRouter-Routen-Hash (#/hilfe?doc=…) überschrieb — die Hilfe-Seite verschwand. Da fast jedes Hilfe-Dokument ein TOC mit Anker-Links hat, war das der dominierende Fail-Modus (Rainer-PN).
- Headings hatten gar keine id. Die Custom-Komponenten für h1/h2/h3 ließen den id-Prop fallen und es war kein Slug-Plugin aktiv — Anker-Targets existierten also nicht.
- Externe …/CHANGELOG.md-URLs wurden zu Doppel-URLs umgeschrieben. Die rewriteLink-Regex matchte ALLE Strings die auf .md enden (auch absolute https://-URLs), und der Fallback-Pfad präfixte dann https://github.com/.../docs/ vor die volle URL.
Fixes:
- rehype-slug (Auto-IDs auf Headings) + rehype-raw (manuelle <a name="…">-Anker im HANDBUCH_DATEN_CHECKER.md bleiben erhalten) eingeführt.
- id-Prop in h1–h4-Komponenten durchgereicht.
- Absolute URLs in rewriteLink erkannt (Protokoll-Regex).
- Anker-Klicks intercepten jetzt preventDefault und scrollen im echten Scroll-Container — <main>, nicht <article> (verschachtelte Overflow-Container, je nach Höhen-Constraint scrollt mal das eine, mal das andere).
- Inter-Doc-Links mit Hash (?doc=bedienung#3-cockpit-dashboards) scrollen nach Doc-Wechsel an die Ziel-Heading.
- Browser-Back funktioniert wieder, weil jede Navigation einen sauberen History-Eintrag setzt statt die Route zu zerstören.
Verifiziert mit Headless-Chrome-Click-Test über vier Szenarien (Inter-Doc / extern / Anker-in-Doc / Inter-Doc-mit-Hash).

[3.25.0] - 2026-04-29

Refactor

refactor(investitions-parameter): Single Source of Truth für parameter-JSON-Keys + 7 Drift-Bugs gefixt — Investitionen tragen ihre typ-spezifischen Detail-Daten in einem unstrukturierten JSON-Feld (parameter). Über mehrere Iterationen waren Schlüsselnamen zwischen Form (InvestitionForm.tsx), Wizard (InvestitionenStep.tsx) und Backend-Lese-Code (ROI, Aussichten, Live, HA-Export, PDF, Cockpit, Community) auseinandergedriftet. Der ursprünglich als Schema gedachte API-Endpoint /investitionen/typen mit parameter_schema war zudem ein Phantom — exportiert und vom Frontend nie aufgerufen, dafür inhaltlich von den echten Form/Wizard-Keys abweichend. Eine Vollinventur (siehe docs/archive/INVENTUR-INVESTITIONS-PARAMETER.md) hat 7 Production-Bugs zutage gefördert, in denen das Backend Schlüssel las, die Form/Wizard nie geschrieben haben — d. h. User-Eingaben wurden im ROI / Aussichten-Tab / Live-Komponenten-Erkennung / Wallbox-Dashboard / Community-Datensatz stillschweigend ignoriert und durch hartkodierte Defaults ersetzt.

Strukturelle Änderungen:
- Single Source of Truth eingeführt: eedc/frontend/src/lib/investitionParameter.ts und eedc/backend/core/investition_parameter.py — pro Investitions-Typ eine Konstanten-Map, ein TS-Interface (Frontend) und eine _DEFAULTS-Map mit zentral verbindlichen Default-Werten (Frontend und Backend importieren denselben Default, damit Default-Drift wie Bug #7 strukturell unmöglich ist).
- Phantom-Endpoint /investitionen/typen entfernt (165 Zeilen parameter_schema-Block in investitionen.py, InvestitionTypInfo API-Type, useInvestitionTypen-Hook, getTypen-API-Methode). Nichts ruft das mehr auf, das Schema war historisch toter Code.
- Frontend-Refactor: Form-Defaults aus den _DEFAULTS-Konstanten geladen (vorher hardcoded Strings); Wizard-getParam('…')/updateParam('…', …)-Calls auf Konstanten-Lookups umgestellt; Render-Stellen (PVAnlageDashboard, Investitionen.tsx) lesen über typed Helper (speicherParameter(inv.parameter).kapazitaet_kwh).
- Backend-Refactor: Alle inv.parameter.get("…") in aussichten.py, investitionen.py, ha_export.py, ha_import.py, sensor_mapping.py, cockpit/uebersicht.py, pdf_operations.py, community_service.py und live_komponenten_builder.py auf PARAM_<TYP>["KEY"]-Konstanten umgestellt; defensive Doppel-Reads (z. B. nutzt_v2h or v2h_faehig in ha_import.py:80) durch den Kanon ersetzt, weil die DB-Migration Drift-Inhalte vereinheitlicht.
- DB-Migration _migrate_investitionen_parameter_keys_v325 in database.py: iteriert beim Start einmalig alle Investitionen, schreibt alte JSON-Keys auf den Kanon um (nutzt_v2h → v2h_faehig, km_jahr → jahresfahrleistung_km, pv_anteil_prozent → pv_ladeanteil_prozent (E-Auto only), benzin_verbrauch_liter_100km → vergleich_verbrauch_l_100km, nutzt_arbitrage → arbitrage_faehig, leistung_kw/ladeleistung_kw → max_ladeleistung_kw (Wallbox), getrennte_strommessung String → Boolean). Idempotent — läuft beim ersten Mal echt, danach No-Op. Smoke-Test mit synthetischer Drift-DB validiert.
Behobene Bugs (User-sichtbar):
- #1 V2H 3-fach kaputt — aussichten.py:1414, live_komponenten_builder.py:130 und investitionen.py:1167 lasen nutzt_v2h ohne Fallback, Form/Wizard schreiben v2h_faehig. Konsequenz: V2H-Aktivierung in der Maske wurde im Aussichten-Tab, in der Live-Komponenten-Erkennung und im E-Auto-ROI ignoriert. Nur ha_import.py:80 hatte einen defensiven Doppel-Read.
- #2 E-Auto Jahresfahrleistung im ROI ignoriert — investitionen.py:1163 las km_jahr mit Default 15000, Form schreibt jahresfahrleistung_km.
- #3 E-Auto PV-Ladeanteil im ROI ignoriert — pv_anteil_prozent (Default 60) statt pv_ladeanteil_prozent.
- #4 E-Auto Vergleichsverbrauch im ROI ignoriert — benzin_verbrauch_liter_100km (Default 7.0) statt vergleich_verbrauch_l_100km. Aussichten + ha_export + pdf nutzten den richtigen Key, ROI weichte ab.
- #5 Speicher-Arbitrage-ROI kaputt — investitionen.py:1018+1140 (DC- und AC-Speicher) lasen nutzt_arbitrage mit Default False. Form/Wizard/Dashboard/ha_import nutzten arbitrage_faehig. Konsequenz: User aktivierte Arbitrage, ROI ignorierte die Aktivierung — Dashboard zeigte Arbitrage-Sektion korrekt.
- #6 Wallbox-Leistung im Dashboard kaputt — investitionen.py:2032 las leistung_kw (toter Schema-Key) mit Default 11. Form/Wizard schreiben max_ladeleistung_kw. Plus 2. Stelle: community_service.py:144 las ladeleistung_kw (auch tot) → Community-Datensatz lieferte stets wallbox_kw=None.
- #7 WP alter_preis_cent_kwh Default-Inkonsistenz — aussichten.py:1091 und ha_export.py:241 defaulteten auf 10.0, alle anderen auf 12.0. Bei leerem Form-Wert sah der User je nach Tab unterschiedliche Ersparnis. Default jetzt zentral aus PARAM_WAERMEPUMPE_DEFAULTS["alter_preis_cent_kwh"] = 12.
- #8 WP getrennte_strommessung String-vs-Boolean — Form speicherte als String 'true'/'false', Dashboard wertete als Boolean aus. 'false' ist JS-truthy → Schalter ging nicht aus. DB-Migration korrigiert auch das.
Auswirkungen für bestehende Anlagen: Tester, die bisher V2H, Arbitrage oder eine von 11 kW abweichende Wallbox-Leistung im Form aktiviert/eingegeben haben, sehen ab v3.25.0 plötzlich neue Werte im ROI, im Aussichten-Tab und im Wallbox-Dashboard. Die alten Werte waren Default-Anzeigen, nicht User-Werte.

[3.24.6] - 2026-04-29

Bugfixes

fix(pv-cockpit): Speicher-Kapazität wird wieder angezeigt — Key-Drift behoben (#172 detLAN, Folgefix zu v3.24.4) — In v3.24.4 sollte die Speicher-Kapazität in „Cockpit → PV-Anlage → PV-Komponenten” zusätzlich zur Bezeichnung erscheinen. Der Render-Code in PVAnlageDashboard.tsx las den Wert aber unter dem falschen Schlüssel batteriekapazitaet_kwh (das ist der E-Auto-Key) — gespeichert wird die Speicher-Kapazität überall im Backend und in InvestitionForm als kapazitaet_kwh. Konsequenz: gepflegte Daten waren da, der Cockpit-Block blieb leer und wirkte „unausgewogen”. Ursache ist die in der Memory-Lesson schon notierte Drei-Sprachen-Drift (Backend / Wizard / Form). Jetzt liest das Cockpit denselben Schlüssel wie das Speicher-Formular.

Verbesserungen

feat(pv-cockpit): WR/Module/Speicher in PV-Komponenten visuell getrennt + Orphan-Speicher-Block (#172 detLAN) — Innerhalb jeder Wechselrichter-Karte werden Module und Speicher jetzt in eigenen, beschrifteten Sub-Sektionen mit hellem Hintergrund-Tint dargestellt — vorher standen sie gemischt in einem 2-Spalten-Grid. Werte (kWp / kWh) richten sich rechtsbündig aus (ml-auto + whitespace-nowrap), die Bezeichnung darf links truncaten. Speicher ohne Wechselrichter-Zuordnung (Parent ist optional) wurden bisher stillschweigend aus dem Cockpit ausgeblendet — sie erscheinen jetzt in einem separaten Block „Speicher ohne Wechselrichter-Zuordnung” am Ende des PV-Komponenten-Blocks, analog zum bestehenden Orphan-Module-Hinweis.
fix(wizard): Kompressor-Starts-Hinweistext gestrafft (#136 detLAN) — Im Sensor-Mapping → Wärmepumpe-Step war der Erklär-Text unter dem Feld „Kompressor-Starts” auf detail-orientierte Tester zugeschnitten („Bei Nibe und Viessmann fehlt der Sensor häufig…, weil ihm state_class nicht gesetzt ist”). detLAN hat die Formulierung als für Einsteiger zu technisch gemeldet und einen klareren Hinweis vorgeschlagen. Jetzt: „Sollte der Sensor das „ohne Statistik”-Badge aufweisen, beachte bitte die Anleitung zum Nachrüsten — siehe Hilfe → Sensor-Referenz → „ohne Statistik”-Badge.” Die referenzierte Stelle in docs/SENSOR-REFERENZ.md enthält jetzt den customize.yaml-Snippet direkt unter §„ohne Statistik”-Badge (statt drei Sektionen weiter unten unter „Plan B außerhalb von EEDC”) und einen klaren Hinweis, dass die Korrektur nur ab Aktivierungs-Zeitpunkt greift, nicht rückwirkend (Lesson aus v3.24.3).

[3.24.5] - 2026-04-29

Dokumentation

feat(hilfe): Was-ist-neu-Seite als Pull-Variante (Discussion #130 Folge-Wunsch von Safi105) — Statt eines What’s-new-Banners nach Update jetzt eine eigene Hilfe-Seite „Was ist neu” in der In-App-Hilfe-Sidebar (Kategorie Einstieg, direkt unter „Übersicht”). Begründung: HA-Add-on-Nutzer sehen den Changelog ohnehin schon im Add-on-Store beim Update, GitHub-Releases haben einen eigenen — ein zusätzlicher Banner wäre die dritte Stimme zur selben Information. Pull statt Push respektiert den Nutzer und spart die ganze localStorage-/Versionsvergleich-/Bestand-vs-Neuinstall-Mechanik des ursprünglichen Banner-Konzepts. Inhalt: ~270 Zeilen, pro Version 3–5 anwender-perspektivisch formulierte Highlights mit Deep-Links in die zuständigen Hilfe-Sektionen, chronologisch absteigend von v3.24 zurück bis v3.16. Footer-Block mit vier weiterführenden Quellen (CHANGELOG, Releases-Übersicht, Repo, Online-Doku). Discussion #130. Konzept-Datei docs/KONZEPT-WHATS-NEW-BANNER.md als „verworfen” markiert, Body bleibt als Entscheidungs-Beleg erhalten.
build(release.sh): Soft-Check für Major.Minor-Sektion in docs/WAS-IST-NEU.md — Prüft beim Release, ob für die neue Version eine ## v3.X.x- oder ## v3.X-Sektion in der „Was ist neu”-Hilfe-Seite vorhanden ist. Bei reinen Bugfix-Patches (Major.Minor existiert schon) → kein Friction. Bei Sprung in eine neue Versionsreihe (z. B. v3.25.0) → Warnung mit Bestätigungs-Prompt, damit der Maintainer bewusst entscheidet zwischen „neuer Highlights-Block” und „diesmal nichts Anwender-Sichtbares”. Volle Auto-Befüllung aus CHANGELOG bewusst nicht — die zwei Stränge bedienen unterschiedliche Zielgruppen (technisch vs. anwender-perspektivisch). scripts/sync-help.sh synchronisiert die Page beim Frontend-Build automatisch.
fix(handbuch): In-App-Hilfe-Einführungsversion v3.24.0 → v3.24.2 — Im Benutzerhandbuch zwei Stellen, die die In-App-Hilfe als „eingeführt in v3.24.0” auswiesen — tatsächlich kam sie in v3.24.2 (Commit 51922da6 liegt zwischen Tag v3.24.1 und v3.24.2). Korrigiert in docs/BENUTZERHANDBUCH.md (Lifecycle-Block + „Was ist neu seit v3.16?”-Tabelle).

[3.24.4] - 2026-04-29

Verbesserungen

feat(cockpit): Kompressor-Starts in Monatsbericht + WP-Dashboard (#169 detLAN) — KPI-Kacheln für die in v3.24.0 erfassten WP-Kompressor-Starts, Quelle ist TagesZusammenfassung.komponenten_starts. MonatsabschlussView (Cockpit → Monatsberichte, WP-Sektion): neuer Tile „Kompressor-Starts (Max/Tag)” — höchste Tagessumme im Monat als Hauptzahl (Verschleiß-Indikator), Σ im Monat als Subtitle. WaermepumpeDashboard (Cockpit → Wärmepumpe): neuer Tile mit Σ über die Lebensdauer ab Anschaffung als Hauptzahl (Auslegungs-Indikator), Max/Tag als Subtitle. Backend-Aggregation in beiden Endpoints (get_aktueller_monat über Monat, get_waermepumpe_dashboard über Lebensdauer) liest TagesZusammenfassung zusätzlich zu InvestitionMonatsdaten — gefiltert pro WP-Investition aus dem JSON wp_starts_anzahl-Subfeld. Live-Dashboard bewusst ausgenommen — WP-Starts heute sind nur in der Trimming-Phase aussagekräftig; nach Einstellungs-Findung wäre das Feld Karteileiche. Auswertung → Energieprofil → Monat-Tabelle bleibt unverändert (WP-Starts-Spalte ist seit v3.24.0 dort einblendbar).
fix(energieprofil-monat): Jahre-Selektor ab Anlagen-Inbetriebnahmejahr (#171 detLAN) — Der Monat-Tab im Energieprofil zeigte fix die letzten 6 Jahre, also auch Jahre vor Inbetriebnahme der Anlage — bei detLANs Anlage (PV seit 2023) erschienen 2021/2022 als wählbare aber inhaltslose Optionen. EnergieprofilMonat lädt jetzt beim Mount die Anlage und nutzt installationsdatum.year als Untergrenze der Optionen-Range. Fallback ohne installationsdatum: weiterhin 6 Jahre rückwärts.
fix(ha-statistik-import): doppeltes Icon entfernt + Navigation in Card-Hülle (#170 detLAN) — Zwei Kosmetik-Punkte aus detLANs Screenshots: (1) Im Datenbank-Status-Alert standen zwei Häkchen-Icons hintereinander — der <Alert type="success"> bringt sein Icon selbst mit, der explizite <CheckCircle> daneben war redundant. Beide entfernt (auch <XCircle> im Error-Branch + ungenutzter Import). (2) Die unteren Navigations-Buttons („Zurück zu Sensor-Zuordnung” / „Zu Monatsdaten”) standen direkt auf dem Page-Hintergrund ohne Card-Hülle, während der gesamte Hauptinhalt in weissen Cards mit Border lebt. Jetzt in derselben bg-white/Border-Card eingebettet, konsistent mit dem Layout-Stil der Seite.
fix(pv-cockpit): Speicher-Kapazität + WR-Eigenleistung in PV-Komponenten anzeigen (#172 detLAN) — Im PV-Anlagen-Cockpit zeigte der „PV-Komponenten”-Block beim Speicher ausschließlich die Bezeichnung — Kapazität (batteriekapazitaet_kwh), nutzbare Kapazität (nutzbare_kapazitaet_kwh) und WR-Eigenleistung (max_leistung_kw) wurden nirgendwo gerendert, obwohl die Stammdaten gepflegt sein können. Beim Wechselrichter stand rechts nur die Σ-Modul-kWp, was bei einer Anlage mit nur einem Modul-Eintrag wie ein Echo der Modul-Zeile darunter wirkte. Speicher-Zeile zeigt jetzt Kapazität (kWh) wenn gepflegt; bei abweichender nutzbarer Kapazität (DOD-Reserve > ~0.05 kWh) zusätzlich „(X nutzbar)” in Klammern. Wechselrichter-Header zeigt jetzt „WR X kW · Module Σ Y kWp” wenn max_leistung_kw gepflegt ist (sonst nur „Module Σ Y kWp”). Lade-/Entladeleistung und Wirkungsgrad bewusst nicht im Cockpit-Kontext — die gehören in die Speicher-Detail-Seite.

[3.24.3] - 2026-04-29

Verbesserungen

fix(sensor-zuordnung + daten-checker): state_class-Hinweise auf den richtigen Hebel umgestellt + Counter-Branch zu WARNING (#136 Folge) — Im Nachgang zu detLANs (#136) und Joachims (Forum #436) Berichten zur 23–24-Uhr-Lücke wurde gemeinsam herausgearbeitet, dass die bisherige Begründung „vergangene Tage bleiben leer” am eigentlichen Problem vorbeigeht: das passiert auch mit customize.yaml-Korrektur, weil HA LTS erst ab dem Aktivierungs-Zeitpunkt persistiert. Der relevante Unterschied im Betrieb: ohne state_class greifen die Korrektur-Werkzeuge in der Datenverwaltung nicht — Vollbackfill, „Verlauf nachrechnen” und Per-Tag-Reaggregation lesen alle aus HA’s LTS. Jeder Aussetzer (HA-/EEDC-Neustart, Polling-Hänger um Mitternacht) ist bei einem Sensor ohne state_class permanent verloren, eine zweite Chance gibt es nicht. Drei Stellen entsprechend nachgezogen: (1) Wizard-Banner SensorMappingWizard.tsx — „Korrektur-Werkzeuge wirken nicht” als zentrale Folge, „Aussetzer permanent verloren” und „23–24 Uhr fehlt häufig” als nachgelagerte Symptome. (2) Daten-Checker SENSOR_MAPPING_LTS daten_checker.py — Counter-Branch von INFO auf WARNING hochgestuft (vorher als „erwartetes Verhalten” beschrieben, was angesichts der fehlenden Reparatur-Werkzeuge zu beruhigend war), kWh- und Counter-Details auf den neuen Hebel umformuliert. (3) Badge-Tooltips in FeldMappingInput.tsx — der irreführende Halbsatz „für Counter unproblematisch” ist raus. (4) WP-Step-Hilfetext WaermepumpeStep.tsx — der ausführliche customize-Snippet-Block ist gekürzt auf einen einzeiligen Verweis auf Hilfe → Sensor-Referenz. Filter-Aufweichung bleibt — Power-User mit nicht-konfigurierbarer HA-Installation behalten die Möglichkeit, einen Sensor ohne state_class zu wählen, sehen aber jetzt klar, was sie damit aufgeben.

[3.24.2] - 2026-04-28

Dokumentation

docs(handbuch): Sweep v3.16–v3.24 — Funktions-Inventur über alle Hilfe-Dokumente — Alle acht in der In-App-Hilfe gerenderten Markdown-Dokumente (BENUTZERHANDBUCH, HANDBUCH_INSTALLATION/BEDIENUNG/EINSTELLUNGEN/INFOTHEK, BERECHNUNGEN, SENSOR-REFERENZ, GLOSSAR) wurden im Bündel auf den Stand von v3.24.1 gehoben. Hintergrund: nach Aktivierung der In-App-Hilfe in v3.24.0 (#130) wurde Veraltung sofort sichtbar — Versions-Stempel waren bereits korrekt, aber viele in v3.16–v3.23 ergänzte Funktionen fehlten in den Detail-Beschreibungen. Bedienung bekommt einen neuen §5.8 Energieprofil-Tab (Beta) und einen kompletten §7.2 Prognosen-Tab (OpenMeteo / EEDC kalibriert / Solcast / IST inkl. MAE/MBE-Trennung, Asymmetrie-Diagnostik aus v3.23.3, Reparatur-Popover bei IST-Lücken, Backward-Slot-Konvention); Cockpit-Reihenfolge auf v3.23.4-Stand, WP-KPI-Reihenfolge JAZ → Wärme → Strom → Ersparnis. Einstellungen bekommt einen neuen §1.6 zur Energieprofil-Seite (Tages-Tabelle mit Pro-Tag-Reaggregation, Datenverwaltung pro Anlage), das Sensor-Mapping mit Solcast-Toggle, Strompreis-Sensor, JAZ-Wording, „ohne Statistik”-Badge und Fallback-Link sowie Daten-Checker auf 8 Kategorien (inkl. MQTT-Topic-Abdeckung #134 und HA-Statistics-Sensor-Mapping). Berechnungen bekommen einen neuen §4.1c zu Lernfaktor / saisonaler MOS-Kaskade / MAE+MBE-Trennung / Asymmetrie-Diagnostik plus überarbeiteten §6b (Snapshot-Architektur, Backward-Slot, GTI-PR, Vollzyklen-Filter auf stationäre Speicher). Sensor-Referenz mit Strompreis-Sensor, WP-Kompressor-Starts-Counter, Solcast-Anbindung (BJReplay + API), Counter-vs-kWh-Trennung und LTS-Verfügbarkeit. Glossar thematisch in 8 Gruppen umgebaut. Installation bekommt den „Empfohlene Nutzung”-Block (datendichte App, Desktop empfohlen — als technische App-Eigenschaft formuliert) und 5 neue Fehlerbehebungs-Einträge. Übersicht bekommt einen Lifecycle-Block der In-App-Hilfe selbst und eine kuratierte „Was ist neu seit v3.16?”-Tabelle mit Deep-Links — als statische Vorlage für einen späteren What’s-new-Banner (Discussion #130 Folge-Wunsch von Safi105).
docs(konzept): What’s-new-Banner nach Update — Konzept-Skizze unter docs/KONZEPT-WHATS-NEW-BANNER.md: versionsbezogener In-App-Banner mit kuratierten Highlights seit der zuletzt vom Nutzer gesehenen Version, Datenquelle initial aus der „Was ist neu seit v3.16?”-Tabelle des Benutzerhandbuchs, Persistenz per localStorage, Re-Open via Hilfe-Sidebar-Eintrag. Bewusst keine automatische CHANGELOG-Extraktion (technisch vs. anwenderzentriert), kein Analytics. Antwort auf Safi105’s Folge-Reply in Discussion #130 nach der Zusage zur In-App-Hilfe; Implementierung offen, Trigger: ruhiges Forum-Bündel oder Major-Sprung.

[3.24.1] - 2026-04-28

Bugfixes

fix(sensor-zuordnung): Nibe-Roh-Counter und sonstige total_increasing-Sensoren ohne Standard-Unit auswählbar (#136 Folge-Fix detLAN) — detLAN testete v3.24.0 mit sensor.compressor_number_of_starts_eb101_ep14_31490 (lokale „Nibe Heat Pump”-Integration) und konnte den Sensor im Wizard nicht finden — und im Frontend gibt es keine Freitext-Eingabe als Notausgang. Ursache: die Nibe-Integration setzt für Coils mit unbekannter Unit weder state_class noch device_class noch unit_of_measurement (Community-Thread) — der bisherige Energy-Filter in sensor_mapping.py ließ nur Sensoren mit state_class in ["measurement", "total_increasing", "total"] and not unit durch, also genau das umgekehrte Profil. Drei Verbesserungen: (1) Filter aufgeweicht: state_class in ["total_increasing", "total"] jetzt immer erlaubt (Unit egal — kumulativer Counter ist per Definition Mapping-Kandidat) plus neuer Pfad „ganzzahliger State ohne jegliche Metadaten” für Roh-Counter wie die Nibe-Integration. (2) Frontend-Fallback im Wizard: kleiner Link „Sensor nicht in der Auswahl? Alle Sensoren ohne Filter anzeigen” über dem Step-Content lädt on-demand mit filter_energy=false nach und merged in die bestehende Liste — wer den gesuchten Sensor weiterhin nicht findet, sieht jetzt alle sensor.*-Entities. (3) Hilfetext im WP-Step: Hinweis auf den Fallback-Link plus customize.yaml-Plan-B (state_class: total_increasing für Nibe-Roh-Counter setzen) als manueller Workaround ohne EEDC-Update.
fix(sensor-zuordnung + daten-checker): Sichtbarkeit für Sensoren ohne HA-Long-Term-Statistics — Folge des aufgeweichten Filters: ab v3.24.1 können auch Sensoren ohne state_class ins Mapping aufgenommen werden — die fehlen aber in HA’s statistics_meta-Tabelle und liefern damit für kWh-Felder (Monatswerte, Vollbackfill) still keine Daten. Counter-Felder (z.B. WP-Kompressor-Starts) sind davon nicht betroffen, weil sie über den Snapshot-Service laufen. Drei Maßnahmen, die das Problem an einer Stelle sichtbar machen statt überall im Code zu prüfen: (1) Backend-Schema: HASensorInfo trägt jetzt das Feld has_statistics: bool (= state_class is not None). (2) Wizard-Dropdown: kleines amber-farbiges Badge „ohne Statistik” neben dem Sensor-Namen — sowohl in der Suchergebnis-Liste als auch in der „bereits gewählt”-Anzeige. Tooltip erklärt: für kWh-Felder ungeeignet, für Counter unproblematisch. (3) Daten-Checker-Kategorie „Sensor-Mapping – HA-Statistics”: prüft beim regulären Daten-Check pro Anlage, ob die im Mapping verwendeten kWh-Sensoren tatsächlich in HA-LTS landen. WARNING wenn ein kWh-Feld auf einen LTS-losen Sensor zeigt (still kritisch — Monatsabschluss bleibt leer), INFO wenn ein Counter-Feld auf einen LTS-losen Sensor zeigt (erwartetes Verhalten — Snapshot-Pfad), OK wenn alle kWh-Sensoren in LTS verfügbar sind. Live-Mappings (leistung_w, soc) werden nicht geprüft — sie lesen state direkt und brauchen kein LTS. Damit sind alle Stellen im Code, an denen LTS-Verfügbarkeit relevant ist, drei (Schema, Wizard-Anzeige, Daten-Checker) — kein „überall in jedem Lese-Pfad prüfen”.

[3.24.0] - 2026-04-27

Neue Features

feat(energieprofil): WP-Kompressor-Starts als Stunden-/Tages-/Monats-KPI (#136) — Optionaler kumulativer Anzahl-Zähler für Wärmepumpen-Kompressor-Starts. Im Sensor-Zuordnungs-Wizard kann pro WP-Investition ein Total-Increasing-Sensor angegeben werden (bei Nibe z.B. aus der lokalen „Nibe Heat Pump”-Integration: sensor.compressor_number_of_starts_…); der stündliche Snapshot-Job erfasst den Counter wie kWh-Zähler in sensor_snapshots, der Tagesabschluss berechnet (a) Stunden-Summen pro Stunde in TagesEnergieProfil.wp_starts_anzahl (Summe aller WP-Investitionen) und (b) Tages-Differenzen pro Investition in TagesZusammenfassung.komponenten_starts ({"wp_starts_anzahl": {"<inv_id>": <int>}}). Vollbackfill aus HA Long-Term Statistics greift für Tages-Summen mit (Counter-Werte werden vom HA-Statistics-Pfad nicht durch 1000 geteilt — Faktor bleibt bei unbekannter Einheit 1.0); Stunden-Detail wird ab Live-Erfassung gefüllt, historische Tage haben dort null. Anzeige-Stellen unter „Auswertung → Energieprofil”: (1) Tab Tagesdetail — neue Spalte „WP-Starts” in der Verbrauchs-Gruppe (default ausgeblendet, im Spalten-Selektor aktivierbar), Stundenwerte + Tagessumme im Footer. (2) Tab Monat — neue Gruppe „Komponenten” mit Spalte „WP-Starts” (default ausgeblendet), Tageswerte je Zeile + Monatssumme im Footer. Zusätzlich im Sensor-Zuordnungs-Wizard im WP-Step: neuer optionaler Eintrag mit Hinweis auf die Nibe-Integration. Bewusst nicht gebaut: Fallback-Heuristik aus leistung_w/Compressor-Binary wäre gerade bei kurzen Takten (wo der KPI sticht) systematisch unterzählen, kein Backfill möglich, Defrost-Verfälschung. Architektur trennt Counter-Felder strikt von kWh-Feldern in KUMULATIVE_COUNTER_FELDER, damit reine Counter nicht versehentlich in die Energie-Bilanz fließen. Issue #136.

[3.23.8] - 2026-04-27

Verbesserungen

fix(daten-checker): MQTT-Topic-Abdeckung präziser + nicht mehr für MQTT-Verweigerer (Forum #404/#405 detLAN/rapahl) — detLAN sah im Daten-Checker eine Warnung „MQTT-Topic erwartet, nie empfangen” mit Beheben-Link auf MQTT-Inbound, obwohl er die Funktion gar nicht nutzen wollte. Ursache: in seinen DB-Settings war MQTT-Inbound aktiviert (Toggle aus dem Wizard), der Subscriber lief, aber keine HA-Publisher-Automation lieferte Topics. Die Warnung war technisch korrekt, im Wording aber unklar — sie listete keine Lösung außer „Publisher einrichten”. Zwei Verbesserungen: (1) Kategorie wird stillschweigend übersprungen, wenn weder Subscriber läuft noch das DB-Setting mqtt_inbound.enabled gesetzt ist — wer MQTT-Inbound nie eingeschaltet hat, sieht die Kategorie gar nicht erst. Bei aktivem DB-Setting aber nicht laufendem Subscriber bleibt eine INFO-Meldung mit Diagnose-Hinweisen (Broker-Adresse / Zugangsdaten / Deaktivierung). (2) WARNING-Meldungen weisen jetzt explizit auf den Deaktivierungs-Pfad hin („Wenn du keine Live-Daten via MQTT brauchst, kannst du MQTT-Inbound unter Daten → Einrichtung → MQTT-Inbound deaktivieren”) — rapahls Tipp aus #405 ist damit Teil der Fehlermeldung selbst.
fix(prognosen-tab): Mobile-Hinweis statt überlappende Tabellen (#165 Safi105) — Safi105 zeigte per iPhone-Screenshot, dass die drei datendichten Tabellen im Prognosen-Tab (KPI-Matrix Heute/Morgen/Übermorgen, 7-Tage-Vergleich, Genauigkeits-Tracking) im Hochformat optisch zusammenbrechen: Header verschmelzen zu „SolcastIST”, Werte und Delta-Annotationen wie „77.3 (0.2 79) kWh” überlappen, VM/NM-Aufteilungen werden zerrissen. Der parallele Stundenvergleich-Tab funktioniert dort, weil er kürzere Spalten-Header nutzt — der v3.23.2-Refactor zur Spalten-Konsistenz hatte die Reihenfolge vereinheitlicht, das Header-Wording aber nicht. Der Prognosen-Tab ist als Solcast-Evaluierungsfläche nicht auf langen Bestand ausgelegt — daher pragmatische Lösung statt Layout-Refactor: ab dem sm-Breakpoint (640 px) werden die drei Tabellen wie bisher gezeigt, darunter eine Hinweis-Box mit zwei Wordings — im Hochformat „Datendichte Tabelle — bitte Gerät ins Querformat drehen oder Desktop verwenden”, im Querformat „Auflösung zu gering für datendichte Anzeige — bitte Desktop verwenden”. Stundenvergleich-Tabelle bleibt unverändert sichtbar, ebenso der Ertrags-Chart und MAE/Bias-KPIs darüber. Konsistent mit der „Empfohlene Nutzung”-Linie aus v3.23.7-README.
fix(ha-statistics): Monatswert nutzt sum-Spalte statt state-Differenz — Tagesreset-Zähler korrekt aggregieren (Discussion #131 rcmcronny) — Ronnys „Aktueller Monat bleibt bei 60 kWh fest”-Bericht: bei Sensoren mit Tagesreset (Zähler springt täglich um 0:00 auf 0) lieferte MAX(state) - MIN(state) über den Monat fälschlich die größte Tagessumme statt der Monatssumme — MIN ≈ 0 (jeden Tag erneut), MAX = bester Tag im Monat, Differenz wächst nach dem Spitzentag nicht weiter. In ha_statistics_service.py jetzt MAX(sum) - MIN(sum) als primärer Pfad: HA’s sum-Spalte ist die reset-bereinigte Kumulation für total_increasing-Sensoren (genau das, was HA’s eigenes Energy-Dashboard intern nutzt — funktioniert auch bei Tagesreset und Mehrfach-Resets). Fallback auf state-Differenz bleibt für measurement-Sensoren ohne has_sum.
fix(energiefluss): Sunset/Alps-Effekt-Layer auf abgerundete Ecken clippen (#164 reopened, detLAN) — Folgefehler des v3.23.7-Eckenfixes: bei aktivierten Effekten zeichneten die Sunset-Animations-Layer (Sonnenstrahlen, Sky-/Reflektions-Partikel, Halo-Ringe) und die Alps-Animations-Layer (Wolken, Schneefunkeln, Sterne) ohne clipPath über die abgerundeten Ecken hinaus — sichtbar als kleine Pixel-Reste an den oberen Ecken bei Sunset. Die statischen Hintergrund-Rects waren in v3.23.7 schon auf clipPath="url(#ef-photo-clip)" umgestellt, die Animations-Blöcke nicht. Jetzt in EnergieFlussBackground.tsx beide Animations-Blöcke in eine <g clipPath="url(#ef-photo-clip)">-Gruppe gewickelt — das rx="8"-clipPath gilt rekursiv für alle Kinder. Issue #164.
fix(live-dashboard): Temperatur-Cards mit Inline-Beschriftung (#166 detLAN, reduzierter Scope) — detLAN bemängelte zwei Punkte am Energiefluss-Tile: (1) den separaten Ladezustand rechts (sei doppelt zum Energiefluss) und (2) die fehlende Temperatur-Überschrift bei den Außen-/Warmwasser-Cards. Zu (1): Ladezustand bleibt — das Tile-Component wird auch für E-Auto verwendet, dort ist die SOC-Anzeige explizite Benutzer-Anforderung; eine Entfernung würde das Component aufspalten oder konditional rendern. Zu (2): keine separate Überschrift (würde eine Zeile vertikal kosten — relevant bei gestapelten Tiles auf dichten Energie-Dashboards), stattdessen die kleinen Card-Labels von „Außen” und „Warmwasser” auf „Außen Temperatur” und „Warmwasser Temperatur” erweitert. Selbsterklärend und ohne zusätzliche Höhe. Issue #166.
fix(setup-wizard + sensor-zuordnung): Wizard-Daten landen wieder im Investment + COP→JAZ-Drift + Icon-Konsistenz + Scroll-to-Top (#167 detLAN) — Vier Punkte aus detLANs Neueinrichtungs-Test gebündelt:
- (1) Wizard ↔ InvestitionForm Key-Drift behoben: Der Setup-Wizard schrieb fünf Parameter unter falschen Keys, sodass die eigentliche InvestitionForm sie nicht fand und das frisch angelegte Investment „leer” wirkte. Korrigiert in InvestitionenStep.tsx: E-Auto-Batteriekapazität (batterie_kwh → batteriekapazitaet_kwh), E-Auto-V2H-Toggle (v2h → v2h_faehig), Wechselrichter-Maximalleistung (leistung_kw → max_leistung_kw), Speicher-Arbitrage (arbitrage → arbitrage_faehig), Wallbox-Ladeleistung (leistung_kw → max_ladeleistung_kw) und Wallbox-Bidirektional (v2h → bidirektional). detLAN hatte drei davon konkret gemeldet, die übrigen sind dasselbe Bug-Muster und wurden im selben Sweep mitgenommen.
- (2) COP/JAZ-Drift in Wizard und Sensor-Zuordnung: Der v3.23.4-Sweep hatte vier Render-Stellen auf JAZ harmonisiert, Setup-Wizard und WP-Sensor-Zuordnung waren nicht in der Liste. Im Wizard heißt das WP-Eingabefeld jetzt „Jahresarbeitszahl (JAZ)” und schreibt unter Key jaz plus implizitem effizienz_modus: 'gesamt_jaz' (das ist semantisch das, was hier erfasst wird — eine Jahresarbeitszahl, nicht ein Betriebspunkt-COP). In WaermepumpeStep.tsx wurde der Card-Untertitel von „JAZ/COP: 3.5” auf „JAZ: 3.5” gekürzt, der Hinweis-Block-Titel von „COP-Berechnung” auf „JAZ-basierte Berechnung” und die Strategie-Labels von „COP-Berechnung” auf „JAZ-Berechnung” umgestellt. Bewusst nicht angefasst: mathematisch-technische Berechnungs-Variablennamen (z.B. cop_default, cop_berechnung-Strategy-Wert für API-Kompatibilität) — dort ist „COP” das mathematisch korrekte Wort.
- (3) Gelbes Icon-Inkonsistenz behoben: Beim WP-Block in der Sensor-Zuordnung saß das gelbe Zap-Icon bei „Stromverbrauch (kWh)” links außerhalb der Card, während „Heizenergie (kWh)” und „Warmwasser (kWh)” gar kein Icon hatten. Der externe Icon-Wrapper bei Stromverbrauch wurde entfernt — alle drei Felder rendern jetzt einheitlich als FeldMappingInput ohne externes Icon-Kästchen.
- (4) Scroll-to-Top im Sensor-Mapping-Wizard (#154-Folgefehler): Die grünen Submit-/Step-Schaltflächen im Sensor-Mapping-Wizard ändern nur den lokalen currentStep-State (kein Route-Wechsel), daher griff der zentrale Layout.tsx-Scroll-Reset aus v3.23.6 nicht. Lokales useEffect auf currentStep in SensorMappingWizard.tsx ergänzt — scrollt den <main>-Container bei jedem Step-Wechsel an den Anfang.

[3.23.7] - 2026-04-27

Neue Features

feat(daten-checker): neue Kategorie MQTT-Topic-Abdeckung (#134) — Schließt die Drift-Lücke zwischen dynamischer Konsumenten-Seite (Erwartungsliste aus field_definitions.py) und statisch hartkodierter Publisher-Seite (HA-Automation-YAML / iobroker / Node-RED): Sobald in EEDC neue Felder dazukommen oder Investitions-IDs nach Re-Import wechseln, driftet Publisher gegen Konsument unbemerkt — diese Daten-Checker-Kategorie macht das sofort sichtbar. Drei Befunde pro Anlage: (WARNING) Topic erwartet, nie empfangen mit Beispielen in den Details (typische Ursachen: Publisher-Automation noch nicht eingerichtet, Investitions-IDs nach Re-Import in der Automation nicht nachgezogen), (WARNING) Topic empfangen, Wert älter als Schwellwert (live ≤ 2 min, energy ≤ 10 min — passt zum sensorgetriebenen Live-Update- und 5-Minuten-Energy-Pattern), (OK) Alle erwarteten Topics aktuell empfangen. Bei nicht-aktivem MQTT-Inbound-Subscriber wird die Kategorie als INFO neutral gemeldet (kein Alarm). Pre-work: Topic-Erwartungsliste aus live_mqtt_inbound.py in eigenen Helfer mqtt_topic_registry.build_expected_topics() extrahiert — Endpoint /api/live/mqtt/topics und der Daten-Checker nutzen jetzt denselben Helfer (eine Quelle, ein Bedeutungsraum für „erwartete Topics”). Issue #134.

Bugfixes

fix(energiefluss): Sunset/Alps-Hintergründe mit Border-Radius clippen (#164 detLAN) — detLAN-Beobachtung beim iPhone-Anzeigezoom-Sweep: bei den Hintergrund-Varianten Sunset und Alps (sowie wahrgenommen bei Alben-Foto-Hintergrund) sind die Ecken nicht abgerundet, im Gegensatz zu den anderen Varianten. Ursache in EnergieFlussBackground.tsx: die Himmel/Meer- bzw. Himmel/Tal-Rects der Sunset- und Alps-Varianten zogen ohne clipPath bis in die Ecken des SVG und überzeichneten damit die abgerundeten Container-Ecken — Foto-Hintergründe nutzen schon clipPath="ef-photo-clip". Jetzt clipPath konsistent auf allen vier Sunset- und vier Alps-Hintergrund-Rects, Ecken sind in allen Varianten gleich abgerundet. Die übrigen Punkte aus #164 (Werte rechts ausbrechend, „Prognose”-Umbruch, Diagramm-Breiten) sind Effekte des aktivierten iOS-Anzeigezooms „Größerer Text” bzw. der HA-Companion-Seitenzoom-Stufe — siehe „Empfohlene Nutzung” im README. Issue #164.

Dokumentation

docs(readme): „Empfohlene Nutzung”-Block — Im Root- und Standalone-README dokumentiert, dass eedc als datendichte Analyse-App primär für Desktop konzipiert ist. Smartphone in Standard-Anzeigegröße deckt Live-Dashboard und einfache Sichten ab, datendichte Auswertungs-Bereiche profitieren von größerem Bildschirm. Bei stark erhöhtem Anzeigezoom (iOS „Größerer Text”, HA-Companion-Seitenzoom) können einzelne Layouts eng werden — bewusste Designentscheidung statt Layout-by-Layout-Patches, die den datendichten Charakter aufweichen würden. Wording als technische App-Eigenschaft formuliert (keine Aussagen zu Barrierefreiheit / Accessibility).

[3.23.6] - 2026-04-26

Bugfixes

fix(layout): h-screen → h-dvh gegen leeren Bereich unter Footer auf iOS (#161 detLAN) — detLAN meldete bei iPhone mit Anzeigezoom „Größerer Text” (und analog HA-Companion-App mit erhöhtem Seitenzoom): in den Monatsberichten ans Ende scrollen, neu absetzen und weiterziehen — und es geht noch weiter, der Footer sitzt mitten im Viewport mit leerem Raum darunter. Ursache: Layout-Wrapper Layout.tsx nutzt h-screen (= 100vh); auf iOS Safari / WKWebView ist 100vh statisch das Viewport ohne UI-Chrome (Adressleiste, Tab-Bar). Mit eingeklappter Adressleiste oder Anzeigezoom wird das echte Viewport größer als 100vh — der äußere Container füllt es nicht aus, das innere <main> mit flex-1 overflow-auto lässt sich nach dem ersten Scroll-Anschlag im Overscroll noch ein Stück weiter ziehen. Fix: h-screen → h-dvh (dynamic viewport height, von Tailwind 3.4+ unterstützt). dvh reagiert dynamisch auf Adressleisten-Animationen und füllt das echte sichtbare Viewport. Eine-Zeilen-Änderung. Issue #161.
fix(layout): Einstellungs-Dropdown scrollbar + SimpleTooltip Viewport-Clamp (#158 detLAN) — Zwei kleine UX-Bugs aus detLAN’s Mobile/Smartfenster-Re-Test. (1) Bei kurzem Browser-Fenster lief das Desktop-Einstellungs-Dropdown unten aus dem Viewport — der letzte Eintrag „Sensor-Zuordnung” war nicht erreichbar. Der äquivalente Container im Mobile-Panel hatte max-h-[calc(100vh-3.5rem)] overflow-y-auto, das Desktop-Dropdown nicht. Jetzt analog ergänzt in TopNavigation.tsx. (2) Tooltips aus SimpleTooltip (z. B. „Strom der aus dem Netz bezogen wird (nicht durch PV gedeckt)” auf der Live-Dashboard-Netzbezug-Kachel) wurden bei langem Text und Trigger nahe am rechten Rand abgeschnitten — die Kombination whitespace-nowrap + transform: translateX(-50%) erzeugte einen einzeiligen Streifen, der über den Viewport-Rand hinausragte. Jetzt in FormelTooltip.tsx: max-w-xs whitespace-normal break-words (mehrzeilig, max ~320 px) plus Edge-Clamp auf coords.left damit die Tooltip-Box auch bei Trigger nahe Viewport-Rand vollständig sichtbar bleibt. Issue #158.
fix(wetter-widget): Stunden-Aggregation IST von „last” auf „mean” (Rainer-PN) — Rainer-PN-Idee zum Versatz im „Wetter heute”-Chart: aus Apex-Charts kennt er Kurven-Versatz durch Aggregations-Methode (group_by/statistics mit avg/last/first). Bei uns trifft das zu, in kleiner Form: das Frontend hat im Live-Heute-Chart pro Stunde den letzten 10-Min-Slot übernommen (result[h] = ... mehrfach überschrieben → last), Open-Meteo dagegen liefert das Stunden-Mittel. Effekt: ~25 Min systematischer Versatz zwischen IST und Prognose im selben Stundenfach. Jetzt in WetterWidget.tsx: Akkumulator pro Stunde + Mittelwert über alle vorhandenen 10-Min-Slots. Konsistent mit der Mean-Konvention der Prognose-Linien. Den anlagenspezifischen 1-Stunden-Versatz, den Rainer beobachtet, erklärt das nicht — der kommt aus dem Stundenprofil seiner Anlage und gehört zum Korrekturprofil-Konzept (siehe docs/KONZEPT-KORREKTURPROFIL.md).
fix(layout): globaler Scroll-to-Top bei jedem Route-Wechsel (#154 reopened, detLAN) — detLAN-Re-Test nach v3.23.5: das Scroll-Problem aus #154 existiert noch unter „Daten” beim Wechsel auf den Tab „Einrichtung” (und implizit überall wo SubTabs route-basiert wechseln — Stammdaten, HA, System). Der v3.23.4-Fix saß nur in Auswertung.tsx mit lokalem activeTab-State; bei NavLink-Wechseln im Layout greift das nicht. Jetzt zentral in Layout.tsx: useEffect auf useLocation().pathname scrollt den <main>-Container per Ref bei jedem Routenwechsel an den Anfang. Damit konsistent für alle SubTab-Gruppen.

[3.23.5] - 2026-04-26

Bugfixes

fix(live-heute): EV-Quote auf 100 % begrenzt + Bilanz-Sortierung (#157 detLAN) — detLAN-Beobachtung: „Wie kann man 195 % Eigenverbr. haben? Meiner Meinung nach kann man maximal 100 % haben.” Sachstand: die 195 % sind mathematisch korrekt (Eigenverbrauch enthält seit #47/b1519cb3 auch Batterieentladung — bei niedriger heutiger PV und Bat-Entladung aus Vortagen kann ev/pv > 100 % rechnen), aber visuell unsinnig. Genau dieses Phänomen war an Periodenwerten schon mit Commit 588a8b07 (25.3.2026) an sieben Backend-Stellen mit min(…, 100) gecappt — der Live-Frontend-Pfad rechnet die Quote allerdings lokal in JS und ist beim 7-Dateien-Patch durchs Raster gefallen. Jetzt nachgezogen: Math.min((ev / pv) * 100, 100) in LiveDashboard.tsx. Plus zwei Folge-Punkte aus #157: (1) Wording-Konsistenz „Eigenverbr.” → „Eigenverbrauch” ausgeschrieben (passt mit dem 100 %-Cap auch in die Pille), (2) Bilanz-Sortierung der Tageswerte-Kacheln nach detLAN’s Energie-Logik PV → Batterie → Eigenverbrauch (Quellen-Σ) → Netzbezug → Hausverbrauch (Verbrauchs-Σ) → Einspeisung (PV-Überschuss). Issue #157.

[3.23.4] - 2026-04-26

Verbesserungen

refactor(komponenten-style): Wärmepumpe-KPIs in 4 Sichten harmonisiert + Speicher-Effizienz vereinheitlicht (#155 reopened, detLAN) — detLAN’s Re-Test nach v3.23.1: Werte stimmen, aber Icons, Farben, Reihenfolge und Wording der Wärmepumpe-KPIs driften zwischen Cockpit-Übersicht, WP-Dashboard, Auswertung→Komponenten und Monatsabschluss noch deutlich auseinander. detLAN’s Bonus-Vorschlag (zentrale Style-Konstanten) übernommen: neues lib/komponentenStyle.ts mit WP_KPI (jaz/waerme/strom/ersparnis: Thermometer-orange / Flame-red / Zap-yellow / TrendingUp-green) und Helper fmtKpi(value, decimals) der bei null/undefined/NaN konsistent '---' zurückgibt — Auswertung→Komponenten ist die Referenz, dort waren Reihenfolge und Style schon richtig. Vier Render-Stellen umgestellt: (1) Cockpit-Übersicht WP-Tile auf JAZ-Wärme-Strom-Ersparnis (vorher Wärme-Strom-JAZ-Ersparnis, Strom-Tile war zudem violett-Zap statt yellow-Zap), (2) WP-Dashboard Header-Tile von „JAZ (gesamt)” auf „JAZ”, Monatsvergleichs-Toggle und Detail-Tabellen-Spalte von „COP” auf „JAZ” (detLAN’s „zweimal COP statt JAZ”), JAZ-Heizen / JAZ-Warmwasser auf einheitliches Thermometer-orange (vorher blue/purple), (3) Monatsabschluss WP-Sektion auf JAZ-Wärme-Strom-Ersparnis mit Thermometer/Flame/Zap/TrendingUp (vorher Stromverbrauch-Wärmeertrag-COP-Ersparnis mit Zap/Flame/Gauge/Euro), Section-Summary-Badge auf „JAZ X.XX” statt „COP X.XX”. Bonus aus detLAN’s Hinweis „Speicher-Effizienz an mehreren Stellen uneinheitlich”: die Speicher-Effizienz-KPI nutzt jetzt durchgängig Activity-Icon + cyan (vorher Battery-cyan in Auswertung→Komponenten, Activity-green im Speicher-Dashboard, Gauge-teal in der Cockpit-Übersicht, Gauge-green im Monatsabschluss). Fehlende Werte (null / 0 / NaN) zeigen einheitlich --- statt „0” oder „—”. Issue #155.
refactor(cockpit): Cockpit-Tabs harmonisiert nach PV-Vorlage (#156 reopened, detLAN) — detLAN’s Korrektur zu v3.23.1: (1) der Tab-Titel sollte bei tatsächlichen Investments (Wärmepumpe / Speicher / Wallbox / E-Auto / Balkonkraftwerk / Sonstiges) nicht der Anlagenname sein, sondern die bezeichnung des konkreten Investments — bei mehreren Investments derselben Art entsteht so automatisch eine Abgrenzung über die jeweiligen Block-Header. PV-Anlage bleibt mit Anlagennamen (kein direktes Investment). (2) Card-Layout vereinheitlicht: die einzelnen Investment-Blöcke werden nicht mehr in eine eigene Card-Box gepackt — bei einem einzigen Investment fällt der Box-Wrapper weg, bei mehreren trennt jetzt eine durchgezogene Linie statt einer Card-Border (analog zur Komponenten-Liste in der Auswertung). (3) Cockpit-Tab-Reihenfolge auf detLAN’s Vorschlag umsortiert: Übersicht → Monatsberichte → PV-Anlage → Balkonkraftwerk → Speicher → Wärmepumpe → Wallbox → E-Auto → Sonstiges (Erzeuger oben, Speicher in der Mitte, Verbraucher unten, „Sonstiges” am Ende). Issue #156.
build(lint): ESLint-Setup für Frontend nachgereicht + 50 Errors aufgeräumt — npm run lint war seit Projektbeginn als npm-Skript hinterlegt, die zugehörige Konfiguration und der TS-Parser fehlten aber, sodass der Befehl nie lief. Jetzt: .eslintrc.cjs mit der Standard-Vite-React-TS-Konfiguration (eslint:recommended + @typescript-eslint/recommended + react-hooks + react-refresh) und @typescript-eslint/parser / @typescript-eslint/eslint-plugin v7 als devDependencies. Beim ersten Lauf 50 Errors aufgedeckt — alle gefixt: ~20× no-explicit-any (catch-Parameter auf instanceof Error-Pattern, drei interne Tooltip-Props strikt typisiert, ein veralteter (anlage as any)-Cast in AnlageForm entfernt nachdem wetter_provider schon im Anlage-Type war), ~20× react-hooks/rules-of-hooks (Hook-Aufrufe nach Early-Returns in EnergieFluss, auswertung/FinanzenTab und allen fünf community/KomponentenTab-Deep-Dives — Hooks vor das return null gezogen, Hook-Bodies um defensive Null-Checks ergänzt), drei no-empty (} catch {}-Stellen in MonatsabschlussView mit Begründungs-Kommentar), zwei no-case-declarations (switch-cases in InvestitionForm und HAStatistikImport in Block-Scopes gewickelt), drei no-unused-vars (durch argsIgnorePattern: '^_' als bewusst-unused erkannt). --max-warnings 0 aus dem Skript entfernt: 22 verbleibende Warnings (exhaustive-deps + react-refresh/only-export-components) sind bekannt-tolerable Style-Hinweise und werden als separate Cleanup-Aufgabe geführt.

Bugfixes

fix(auswertung): Tab-Wechsel scrollt zuverlässig zum Seitenanfang (#154 detLAN, dritter Anlauf) — detLAN-Re-Test: Tabs „CO2” und „Tabelle” übernahmen die Scroll-Position der vorherigen Tab, andere Tabs scrollten korrekt nach oben. Ursache: bisheriges scrollTo lief im onClick-Handler vor dem React-Re-Render und mit behavior:'smooth' — bei Tabs mit langem Inhalt wurde die Animation durch das Re-Render unterbrochen oder gekappt. Lösung: useEffect auf activeTab-Änderung mit behavior:'auto' — scrollt nach dem Re-Render hart auf 0, ohne Smooth-Animation. Entspricht dem Cockpit-Pattern (jeder Sub-Tab beginnt am Seitenanfang) und detLAN’s explizit formuliertem Wunsch.

Internal

internal: Day-Ahead-Stundenprofil-Snapshot in TagesZusammenfassung — Zwei neue JSON-Felder (pv_prognose_stundenprofil, solcast_prognose_stundenprofil) speichern den ersten OpenMeteo-/Solcast-Forecast des Tages als 24-Werte-Liste in kWh (Backward-Slot-Konvention). First-write-wins: spätere Aufrufe am selben Tag überschreiben das Profil nicht, der Day-Ahead-Charakter bleibt erhalten. Schreiben passiert fire-and-forget aus dem bestehenden Live-Wetter-Endpoint, kein neuer Scheduler-Job, kein UI, kein API-Endpunkt — reine Hintergrund-Datensammlung für künftige Diagnostik (siehe docs/KONZEPT-KORREKTURPROFIL.md). Storage ~80 KB/Jahr/Anlage.

[3.23.3] - 2026-04-26

Neue Features

feat(prognose): Diagnostisch-Modus für Genauigkeits-Tracking — Asymmetrie sichtbar machen (#151 Variante B, Rainer-Mockup) — Der MAE/MBE-Modus aus v3.22.0 zeigt Streuung und Bias kompakt, verbirgt aber, ob die Streuung symmetrisch ist (Rauschen ohne Hebel) oder asymmetrisch (z. B. „bei dichten Wolken systematisch zu hoch, bei klarem Himmel zu niedrig” — Lernfaktor lässt sich nur einseitig nutzen). Neuer Toggle „Kompakt / Diagnostisch” im Header der Genauigkeits-Tracking-Card schaltet zwischen den zwei Sichten um. Im Diagnostisch-Modus zeigt jede Quelle (OpenMeteo / EEDC / Solcast) zwei Boxen nebeneinander: darüber = Tage an denen die Prognose über dem IST lag (Ø-Überschätzung in % + Anzahl Tage, amber) und darunter analog für Unterschätzung (sky-blau). Dahinter neues Backend-Schema AsymmetrieEintrag (over_count, over_avg_prozent, under_count, under_avg_prozent) das die signed errors an 0 splittet — GET /aussichten/prognosen/{id}/genauigkeit liefert jetzt zusätzlich openmeteo_asymmetrie / eedc_asymmetrie / solcast_asymmetrie. Default bleibt kompakt; das Asymmetrie-Detail ist optional und stört den Standard-Workflow nicht.

[3.23.2] - 2026-04-26

Bugfixes

fix(downloads): Backup/CSV/PDF-Downloads über Blob-Pattern statt window.open (Joachim-PN) — Joachim meldete „401: unauthorized” beim Tippen auf den Backup-Button in der iOS HA Companion-App. Ursache: window.open(url, '_blank') (in Backup.tsx) öffnet _blank-Links extern in Safari — und Safari hat keine HA-Ingress-Session, daher 401 vom Ingress-Endpoint. Browser klappte das deshalb, App nicht. Fünf Stellen umgestellt auf zentrales downloadFile(url, filename) aus neuem lib/download.ts (fetch + Blob + temporärer <a download>): Backup-Button, JSON-Export-Icon in der Anlagen-Liste, CSV-Template + CSV-Export im Import-Dialog, alle vier PDF-Dokumente im Dokumente-Dialog (lokale Helper-Duplikate konsolidiert). Damit läuft die HTTP-Anfrage in der bestehenden iframe-Session und der Download geht als blob:-URL ins Filesystem — funktioniert in der HA-App + Browser gleichermaßen.
fix(prognosen-tabelle): „Laufbalken” entfernt + Spalten konsistent ausgerichtet (Rainer-PN, Detlef-PN) — Rainer meldete einen sichtbaren Vertikal-Balken am rechten Rand der 24h-Stundenvergleichstabelle nach „Tag neu berechnen”. Es war die Browser-Scrollbar des Tabellen-Containers — max-h-96 (384px) plus die Stunden-Anzahl in den Übergangs-Monaten ließen die Tabelle um wenige Pixel überlaufen → Scrollbar erschien, obwohl optisch alles reinpasste. Höhen-Constraint + sticky-thead/tfoot entfernt. Im selben Zug die Spaltenstruktur aller vier Tabellen auf der Prognosen-Seite vereinheitlicht: KPI-Matrix (Heute/Morgen/Übermorgen), 24h-Stundenvergleich, 7-Tage-Vergleich und Genauigkeits-Tracking nutzen jetzt durchgängig table-fixed + <colgroup> mit konsistenten Title-Spalten und gleichmäßig verteilten Wertspalten. Im 7-Tage-Vergleich wurde die Wetter-Spalte vor das Datum verschoben (zweispaltiger Zeilentitel), im Genauigkeits-Tracking die IST-Spalte ans Ende. Damit stehen OpenMeteo / EEDC / Solcast / IST in allen vier Tabellen in derselben vertikalen Linie übereinander — die Seite scrollt sauber von oben nach unten ohne Auge-Zickzack.

[3.23.1] - 2026-04-26

Bugfixes

fix(cockpit-uebersicht): JAZ/Wärme/Strom ignorieren Daten vor Anschaffungsdatum (#155.1, Folgefix zu #153) — detLAN-Beobachtung: „Die Wärmepumpe im Cockpit-Überblick haben wir übersehen.” Der v3.23.0-Filter aus #153 wurde nur in cockpit/komponenten.py und im WP-Detail-Endpoint (investitionen.py:/dashboard/waermepumpe) eingebaut. Die Cockpit-Hauptseite („Übersicht”) zog ihre WP-Aggregate aus cockpit/uebersicht.py — und summierte dort weiter alle vorhandenen InvestitionMonatsdaten ungefiltert. Dasselbe Problem in vier weiteren Endpunkten (cockpit/social.py, cockpit/nachhaltigkeit.py, aktueller_monat.py, aussichten.py) und in fünf Dashboards (E-Auto, Speicher, Wallbox, Balkonkraftwerk — der WP-Dashboard hatte den Filter bereits). Filter konsistent eingebaut: Monate vor (anschaffung.year, anschaffung.month) werden überall ignoriert. Greift für WP, Speicher, Wallbox/E-Auto und Balkonkraftwerk gleichermaßen; das löst auch #155.4-Beobachtung („Es wird erneut das Anlagendatum für den Zeitraum ausgewählt”), weil der Zeitraum jetzt aus dem gefilterten Datensatz hergeleitet wird.
fix(auswertung): Tab-Wechsel scrollt jetzt wirklich (#154 reopened) — Der v3.23.0-Fix scrollte window per window.scrollTo(...), das eigentlich scrollende Element ist aber das <main> mit overflow-auto aus dem App-Layout — window.scrollTo war damit ein No-Op. Korrigiert auf document.querySelector('main')?.scrollTo({...}).
fix(cockpit): Anlagenname als Titel statt redundanter Typ-Bezeichnung (#156) — detLAN: „Die Art des Investments geht aus dem aktiven Tab hervor — eine Wiederholung als Titel ist nicht erforderlich.” Der <h1> der vier Cockpit-Dashboards (PV-Anlage, Wärmepumpe, Speicher, Wallbox) zeigt jetzt {anlage.anlagenname} statt „PV-Anlage” / „Wärmepumpe” / „Speicher” / „Wallbox” — Investment-Art bleibt nur noch im aktiven grünen Tab sichtbar, der Card-Header bei mehreren Investments derselben Art trägt weiterhin {investition.bezeichnung} zur Unterscheidung.
fix(cockpit): Icon-Overflow bei schmalen Fenstergrößen (#155.4) — In den vier Cockpit-Dashboards rutschten Header-Icon (Sun/Flame/Battery/Plug) und Card-Header-Icon (Flame/Battery/Plug) aus dem Container, sobald der Bezeichnungs-Text zu lang wurde. flex-shrink-0 auf den Icons + min-w-0 + truncate auf den Text-Containern halten das Layout stabil.
fix(navigation): Hamburger-Menü früher aktiv (md → lg, #155.1) — detLAN-Screenshot zeigte bei 1539px die Hauptnavigation und das Settings-Dropdown im Konflikt. Breakpoint in TopNavigation.tsx von md: (768px) auf lg: (1024px) gehoben — Hamburger-Layout ist damit auf typischen Notebook-Viewports und kleineren Browser-Fenstern aktiv.
fix(cockpit): WP-Tile zeigt „JAZ” statt „Ø COP” (#155.3, #155.5) — detLAN: Auswertung→Komponenten→WP nutzt für die Periode JAZ, das Cockpit-Hauptseiten-Tile zeigte demgegenüber „Ø COP”. Cockpit-Tile auf „JAZ” + Formel-Beschriftung „JAZ = Wärme ÷ Strom” harmonisiert; pro-Monat-Werte (Tabelle, Vergleichs-Toggle) bleiben weiter als COP.
fix(monatsabschluss-wp): VM-Vergleich nur wenn Vormonat tatsächlich WP-Daten hat (#155.2) — Bei einer WP, die im aktuellen Monat zum ersten Mal Daten hat, zeigte der Monatsabschluss alle vier KPI-Tiles („Stromverbrauch”, „Wärmeertrag”, „COP”, „Ersparnis vs. Gas”) mit „VM: 0 kWh” oder „VM: NaN kWh” — irreführend, weil der Vormonat keinen WP-Betrieb hatte. Single-Source-Guard hatVmWp = (vm?.wp_strom_kwh ?? 0) > 0 unterdrückt jetzt sowohl die Subtitle-Zeilen als auch die VglZeile-Vergleichsspalten der WP-Sektion.

[3.23.0] - 2026-04-25

Neue Features

feat(prognose): Klickbarer Reparatur-Popover bei IST-Datenlücke (#147 fortlaufend) — Wenn die Prognosen-IST-Anzeige eine Datenlücke hat (⚠ neben dem Tageswert), öffnet ein Klick auf das Symbol jetzt einen kompakten Popover statt des Hover-Tooltips. Inhalt: konkrete Auflistung der fehlenden Stunden, kurzer Erklärungstext (Snapshot-Zyklus, Sensor-Mapping), Button „Tag neu berechnen” (triggert POST /api/energie-profil/{anlage_id}/reaggregate-tag mit Refetch + Status-Banner) und Fallback-Link zum Sensor-Mapping. Layout am ⚠ rechtsbündig verankert (right-0) mit max-w-[calc(100vw-2rem)] — bricht nicht mehr aus dem Viewport.
feat(snapshot): Restart-Recovery für verpasste :05/:55-Jobs — Wird das Add-on zwischen :55 (Live-Snapshot-Preview) und :05 (regulärer HA-Statistics-Snapshot) der Folgestunde neu gestartet, fehlten die Snapshots der laufenden und ggf. der gerade abgeschlossenen Stunde, weil die Cron-Trigger keine Misfire-Recovery hatten. Neue sensor_snapshot_startup_recovery() läuft nach Scheduler-Start im Hintergrund: holt für die letzten 6 Stunden je Anlage snapshot_anlage (HA-Statistics, idempotent dank Upsert) und für die laufende Stunde zusätzlich live_snapshot_if_missing (aus HA-Live-State); anschließend aggregate_today_all für sofortige Sichtbarkeit. Damit ist das Energieprofil nach Add-on-Restarts (Watchdog, Update) ohne Wartezeit wieder vollständig.

Bugfixes

fix(prognose): IST-Slot der gerade abgeschlossenen Stunde nicht mehr als Lücke flaggen — Slot N (= Backward-Slot-Konvention [N-1, N)) hängt von der HA-Hourly-Statistics-Row für start_ts=N, die HA aber erst am Ende der Stunde schreibt. Innerhalb des Zeitfensters zwischen Stundenwechsel und HA-Stats-Write (typisch ~5–60 Min) ist der Slot zwangsläufig None. Die <=-Bedingung in prognosen.py:431 flaggte das fälschlich als „IST-Daten unvollständig”. Geändert zu < — der gerade abgeschlossene Slot wird nicht mehr geflaggt; ältere echte Lücken (>1 h alt) weiter wie bisher.
fix(snapshot): Tagesreset-Heuristik für utility_meter mit daily cycle — Forum-Beobachtung Rainer: HA-utility_meter-Sensoren mit täglichem Reset (z. B. „Erzeugung heute”) werfen um Mitternacht ein stark negatives Delta (Vortag-Endwert → ~0). get_hourly_kwh_by_category hatte das pauschal als „Sensor-Reset” verworfen → Slot 0 dauerhaft None → ist_unvollstaendig=True jeden Tag. Heuristik in sensor_snapshot_service.py:548-559 erkennt Daily-Reset-Muster (s1 < 0.5 ∧ s0 > 0.5) und nimmt max(0, s1) als Slot-0-Wert (Energie seit Reset, typ. ≈ 0 nachts). Bei untypischen negativen Deltas mitten am Tag bleibt die Reset-Warnung wie bisher.
fix(daten-checker): Falscher Beheben-Link bei „X Komponenten ohne kWh-Zähler” — Joachim-PN: Klick auf „Beheben” in dieser Daten-Checker-Kategorie führte auf eine weiße Seite. Der Link verwies auf /einstellungen/sensoren; die Route heißt aber /einstellungen/sensor-mapping. In daten_checker.py zwei Stellen korrigiert.
fix(live-dashboard): Wetter-Timeline-Alignment im Tagesverlauf-Chart (MartyBr) — Hartcodiertes paddingLeft: 40 in der Wetter-Timeline ignorierte die dynamische Recharts-YAxis-Breite. Bei größeren PV-Werten (>10 kW) wurde die YAxis breiter und die Wetter-Icons saßen nicht mehr exakt über den X-Tick-Stunden. Fix: <YAxis width={45}> setzt deterministische Breite, margin.left=0 und paddingLeft: 45 halten die Plot-Area konsistent über den Tag.
fix(card): Border-Radius-Clipping bei Tabellen-/Section-Headern (#149, #152) — detLAN-Bündel: Auf vier Pages (Monatsabschluss-T-Konto Mobile, Monatsdaten-Tabelle, Anlagen-Liste, Strompreise-Liste) ragten farbige <th>-/Section-Bänder über die abgerundeten Card-Ecken hinaus, sodass die Rahmenlinie an den Ecken nicht sauber schloss. overflow-hidden auf der jeweiligen Card behebt das.
fix(legacy): Anlage.ausrichtung / Anlage.neigung_grad aus aktivem Code entfernt (#152) — Die Spalte „Ausrichtung” in der Anlagen-Liste zeigte bei detLAN konsistent -, weil das Feld am Anlage-Modell seit dem Refactoring zu PV-Modul-Investitionen nicht mehr gepflegt wird. Geprüft: weder Berechnungen (Prognose, PVGIS, Solar-Forecast, PR), Community-Submit, Infothek noch JSON-Export greifen darauf zu. Spalte aus der Liste entfernt, Setup-Wizard-Lese-Stellen aufgeräumt, Pydantic-AnlageExport-Schema und TypeScript-Anlage-Interface bereinigt. DB-Spalte bleibt erhalten für Bestandsinstallationen (Pattern wie ha_sensor_*); Kommentar im Modell präzisiert.
fix(pv-cockpit): Modul-Anzahl zählt jetzt parameter.anzahl_module statt nur Investitions-Einträge (#152) — Anzeige „1 WR, 1 Module” trotz 21 gepflegter Module in der PV-Modul-Investition. Subtitle berechnet jetzt anzahl_module pro Modul-Investition (Default 1 falls Parameter leer).
fix(anlage-form): Umlaute „fur”/„wunschen”/„Warmepumpe” (#152) — In AnlageForm (Steuerlicher Hinweis) und Strompreise (Spezialtarif-Hinweis) waren ASCII-Stümpfe statt korrekter Umlaute hinterlegt — ggf. ein altes copy-paste aus einer ASCII-only-Quelle.
fix(input): Date-Inputs in Webkit linksbündig erzwingen (#152) — <input type="date"> rendert in Safari/iOS den Datumstext per Default zentriert, in Anlage-/Investition-/Strompreis-Modals fiel das auf. CSS-Selector [&[type='date']]:text-left und [&::-webkit-datetime-edit]:text-left in der zentralen Input-Komponente erzwingt linksbündig.
fix(auswertung): Tab-Wechsel scrollt zum Seitenanfang (#154) — Bei Tab-Wechseln innerhalb der Auswertung (Energie/PV/Komponenten/Finanzen/CO2/Investitionen/Tabelle/Energieprofil) blieb die Seite auf der vorherigen Scroll-Position — am Tab-Wechselpunkt unsichtbar bis der Nutzer manuell hochscrollte. Smooth-Scroll auf den Page-Top im onClick der Tab-Buttons.
fix(waermepumpe): Konsistente KPI-Anzeige zwischen Cockpit und Auswertung (#153) — Detlef-Bündel: in beiden Dialogen jetzt identische Reihenfolge (JAZ → Wärme → Strom → Ersparnis), Icons (Thermometer / Flame / Zap / TrendingUp) und Farben (orange / red / yellow / green). Zuvor war die Auswertungs-Sicht aus der Reihe (Wärme zuerst, JAZ an Position 3), Strom-Icon und -Farbe (lila vs. gelb) waren divergent.
fix(waermepumpe): JAZ ignoriert Daten vor Anschaffungsdatum (#153) — Wichtigster Punkt aus Detlef-Issue #153: Im Cockpit- und Auswertungs-Dashboard summierten Backend-Aggregatoren alle vorhandenen InvestitionMonatsdaten der Wärmepumpe, ungeachtet des anschaffungsdatum. Das verfälschte JAZ und Ersparnis bei Anlagen, die vor dem Stichtag andere (unvollständige) Erfassungs-Methoden hatten — z. B. Detlef’s Migration zu Shelly-erfasstem WP-Stromverbrauch ab April 2026: das alte JAZ blieb auf dem optimistischen Wert der WP-eigenen Strommessung (5,2) statt auf den realistischen 3,7–4. Filter eingebaut in cockpit/komponenten.py und investitionen.py (/dashboard/waermepumpe): Monate vor (anschaffung.year, anschaffung.month) werden ignoriert.
fix(dashboards): „Dashboard”-Suffix aus Top-Header entfernt + Card-Header bei n=1 versteckt (#153) — Vereinheitlichung mit PV-Anlage-Cockpit, das nur eine Überschrift zeigt. Top-Header der Komponenten-Dashboards (Wärmepumpe / Speicher / Wallbox / E-Auto / Balkonkraftwerk / Sonstiges) heißt jetzt analog „Wärmepumpe” statt „Wärmepumpe Dashboard”. Bei der Wärmepumpe wird zusätzlich der Card-interne Header ausgeblendet, wenn nur eine WP existiert (vorher doppelte „Wärmepumpe”-Überschrift).

[3.22.0] - 2026-04-25

Neue Features

feat(prognose): Genauigkeits-Tracking — MAE + Bias trennen, Spaltenstruktur stabilisieren (#151) — Zwei eng verzahnte Diagnosen aus Rainer-PN gemeinsam aufgelöst. MAE + MBE getrennt ausweisen: Backend GET /aussichten/prognosen/{id}/genauigkeit aggregiert jetzt auf vorzeichenbehafteten relativen Fehlern und liefert zwei Kennzahlen — MAE (abs()) für Streuung, MBE (ohne abs()) für systematischen Bias. Drei Quellen statt zwei: zusätzlich zu OpenMeteo und Solcast wird auch EEDC bewertet (Basis × aktueller Lernfaktor). Neue Response-Felder: openmeteo_mbe_prozent, eedc_mae_prozent, eedc_mbe_prozent, solcast_mbe_prozent, plus eedc_kwh pro Tag. Frontend: MAECard → MaeMbeCard mit zwei KPIs nebeneinander (MAE + Bias) und Tooltips, drei Cards in der Genauigkeits-Sektion. Bias neutral gefärbt — Vorzeichen ist Information, nicht Wertung. Spaltenstruktur stabil: EEDC-Spalte in allen vier Tabellen (KPI-Matrix, 24h-Stundenvergleich, 7-Tage, Genauigkeits-Tracking) immer gerendert. Bei fehlendem Lernfaktor gedämpfter Header (text-gray-400) und — als Platzhalter, Tooltip verweist auf den Status-Banner. Die Genauigkeits-Tracking-Tabelle hatte bisher gar keine EEDC-Spalte; ist jetzt konsistent. Kein Spaltenflattern mehr nach Tag 7.
feat(prognose): Banner zeigt Restzeit bis Lernfaktor-Schwelle — Der Hinweis „EEDC-Prognose nicht verfügbar” erläutert jetzt zusätzlich, wie viele Tage bereits gesammelt sind und wie viele noch bis zur 7-Tage-Schwelle fehlen (z. B. „3 von 7 Tagen, noch 4 Tage”). Die Berechnung filtert Tage mit gültiger OpenMeteo-Prognose UND IST-Ertrag > 0.5 kWh — analog zur Backend-Logik in _berechne_faktor.
feat(prognose): VM/NM-Split an Solar Noon proportional aufteilen — Tageshälften (Vormittag/Nachmittag) wurden bisher hart bei 12:00 Uhr Clockzeit gesplittet. Korrekt ist der Split an der astronomischen Tagesmitte (Solar Noon, via Equation of Time), die je nach Standort und Datum bis ~30 min von 12:00 abweicht. Slots, die Solar Noon enthalten, werden proportional auf VM und NM verteilt. Konsistent zu solar_forecast_service.

Bugfixes

fix(mobile): Mehrere Darstellungsprobleme auf kleinem Bildschirm (#149) — Bündel von 7 Mobile-Layout-Fixes aus detLAN-Bugreport: Cockpit-/Energieprofil-SubTabs scrollen aktiven Tab automatisch in den sichtbaren Bereich (PV-Anlage, Daten-Cleanup nicht mehr abgeschnitten); Info-Icon der KPI-Tiles auf Mobile ausgeblendet (Tap-Tooltip bleibt); Monatsberichte Finanzen-T-Konto auf Mobile als 2-Spalten-Layout (Label | Wert+VJ+Δ gestapelt) statt 4 Spalten — GEWINN/Badges nicht mehr abgeschnitten; Section-Header „Monatsergebnis” + Ø-Cent-Suffix auf Mobile ausgeblendet (sonst mid-word truncated); Page-Sticky-Bars (Auswertung, Aussichten, Community) auf z-30, damit Tabellen-thead (z-10) sie nicht mehr überlagert; Energieprofil-Subtabs in Auswertung als flex-wrap (umbricht statt rechts rauszulaufen); Aussichten Langfristig stapelt Steuerung vertikal auf Mobile; Energieprofil-Seite mit p-3 sm:p-6 und kleineren KPI-Tiles auf Mobile; Tabellen mit vielen Spalten zeigen Querformat-Hinweis nur in Mobile-Portrait.
fix(energieprofil): Batterie-Vollzyklen verwenden nur stationäre Speicher-SoC — _get_soc_history und der Bulk-Fetch in backfill_from_statistics sammelten alle live.soc-Sensoren aus den Investitionen und nahmen den ersten als Batterie-SoC. Bei Anlagen mit E-Auto-Investition landete deren SoC-Sensor zuerst in der Liste — break nach dem ersten Entity sorgte dafür, dass der eigentliche stationäre Speicher nie angefasst wurde. Folge: batterie_vollzyklen in TagesZusammenfassung spiegelten den ΔSoC des Autos wider, nicht des Speichers. Im neuen Tage-Tabellen-Tab (#148, v3.21.0) wurde das offensichtlich (Tage mit - bei abgesteckten Auto, vereinzelt 0.7+ wenn das Auto gefahren+geladen wurde). Beide Selektions-Pfade filtern jetzt auf inv.typ == "speicher". Multi-Speicher-Anlagen behalten das bisherige „erstes Speicher-Entity”-Verhalten (Kapazitäts-Gewichtung wäre eine separate Erweiterung). Nutzer-Schritt nach Update: einmal „Verlauf nachberechnen + überschreiben” auslösen, damit historische batterie_vollzyklen-Werte korrigiert werden.
fix(kraftstoffpreis): Service-Fehler im Backfill durchreichen statt verschlucken — Wenn der EU-Oil-Bulletin-Download oder das XLSX-Parsing fehlschlug, lieferte der Service {"aktualisiert": 0, "fehler": "Keine Kraftstoffpreise verfügbar"} zurück. Der Endpoint las aber nur aktualisiert/land/hinweis — fehler wurde gestrippt und das Frontend zeigte „Keine offenen Tage.” statt eines Error-Alerts. Der Counter „X Tage ohne Kraftstoffpreis” blieb unverändert, der Nutzer hatte keinen Hinweis auf den eigentlichen Fehler (z.B. URL-Wechsel beim Bulletin). Beide Endpoints (/tages und /monats) reichen fehler jetzt durch, das Frontend zeigt es als roten Error-Alert.
fix(energieprofil): Auswertungs-Tabelle Verfeinerungen — Aktualisieren-Button pro Zeile in Auswertung → Energieprofil → Monat ausgeblendet (showReaggregate-Prop) — Reaggregation gehört in die Datenverwaltung (Daten → Energieprofil), nicht in die Auswertungs-Sicht. Stunden-Aggregat im Footer als „Xh YYmin” statt „22.93/24” (Pro-Tag-Werte bleiben unverändert „20/24”). Footer-Hintergrund voll-opak (statt /70-Transparenz im Dark Mode), damit die Summenleiste klar abgesetzt ist.

[3.21.0] - 2026-04-25

Neue Features

enhance(wp/roi): WP-Alternativvergleich präzisieren — Zusatzkosten + Monats-Gaspreis (#141) — Zwei systematische Lücken im Gas-vs-WP-Vergleich geschlossen. Neuer Investitions-Parameter alternativ_zusatzkosten_jahr (€/Jahr) für Schornsteinfeger, Wartung, Gaszähler-Grundpreis — wird in allen 5 Berechnungs-Stellen (Aussichten historisch + Prognose, HA-Export inkl. WP-Sensor, PDF-Jahresbericht, Investitions-Vorschau) zu den Alt-Heizungs-Kosten addiert, in historischen Aggregaten anteilig pro erfasstem Monat. Neue optionale Monatsdaten.gaspreis_cent_kwh-Spalte (analog zu kraftstoffpreis_euro für Benzin): wenn pro Monat gepflegt, wird sie in der historischen Aggregation Monat für Monat verwendet, Fallback bleibt wp.parameter.alter_preis_cent_kwh. Damit ändert ein Tarifwechsel nicht mehr rückwirkend die ganze Historie. Erscheint im Monatsabschluss-Wizard und in MonatsdatenForm automatisch über BEDINGTE_BASIS_FELDER mit bedingung_basis: hat_waermepumpe.
enhance(auswertung/energieprofile): Tage-Tabelle im Monat-Tab + aufklappbare Sektionen (#148) — Rainer’s Wunsch (#148): „Tages-Energieprofile”-Tabelle prominent in den Auswertungen sichtbar machen. Sie bleibt unter Daten → Energieprofil als schmucklose Datenkonsole, im Auswertungs-Tab kommt eine optisch aufgewertete Sicht hinzu. Neue wiederverwendbare <CollapsibleSection>-Komponente in components/ui mit localStorage-Persistenz pro storageKey. EnergieprofilTageTabelle refactored: Body als wiederverwendbare Sub-Komponente EnergieprofilTageTabelleEmbedded({anlageId, jahr, monat}) ohne Card-Wrap und Monatsauswahl, der Auswertungs-Monat-Tab nutzt sie ohne doppelten Selector. UI-Aufwertung der Tabelle (gilt für beide Sichten): Zellfarbe nach Wert (Heatmap-Stil), Negativpreis-Tage mit amber-Streifen + §51-Badge, sticky Σ-Monat-Footer mit Spaltenaggregat (Σ/Ø/max/min je nach Spalte). EnergieprofilMonat umgebaut: alle Sektionen nutzen CollapsibleSection in der Reihenfolge KPI-Strips (fix) → §51 → Kategorien (offen) → Tage des Monats (neu, offen) → Heatmap (offen) → Geräte/Tagesprofil/Peaks (zu).
enhance(auswertung/investitionen, cockpit): ROI-Seite aufräumen + zwei Amortisations-Sichten (#140) — siehe gleichnamiger Commit-Hash 40ab07bd.
feat(energieprofil): Pro-Tag-Reaggregation per Knopf in der Tagestabelle (#146) — Selbsthilfe-Mechanismus für den Fall, dass ein einzelner Tag im Energieprofil offensichtlich falsche Werte hat. Statt manuell die DB zu editieren oder das volle Backfill auszulösen, kann der Nutzer den Tag mit einem Klick neu aggregieren — aggregate_day macht intern delete+insert, ist also idempotent und betrifft nur den gewählten Tag. Refresh-Icon-Button am Ende jeder Tageszeile. Klick → Confirmation → API-Aufruf → Reload der Tabelle. Erfolgsmeldung mit Diagnose: grün bei Messdaten > 0, amber bei 0 Messdaten („keine Snapshots in DB, HA-Statistics nicht erreichbar”). Wirkt sowohl in Daten → Energieprofil als auch in Auswertung → Energieprofile (Beta) → Monat (geteilte Komponente). Neuer Endpoint POST /api/energie-profil/{anlage_id}/reaggregate-tag?datum=YYYY-MM-DD, der zusätzlich zu stunden_verfuegbar (geschriebene Slots) auch stunden_mit_messdaten (Slots mit echten Werten ≠ NULL) zurückgibt — letzteres ist der ehrlichere Erfolgsindikator.

Bugfixes

fix(energieprofil): Snapshot-Job-Toleranz 60→10min + :55-Live-Preview (#146) — Forum-Beobachtung Rainer (#146): Stundenwerte zeigten gelegentlich das Muster „Stunde 0.00 gefolgt von Folge-Stunde mit 2h-Summen-Spike”. Identisches Symptom wie #145, aber in einem anderen Pfad nicht abgedeckt. Root Cause: snapshot_anlage (stündlicher :05-Job) verwendete toleranz_minuten=60 beim HA-Statistics-Lookup. Wenn HA die Zielstunde zur Job-Laufzeit noch nicht finalisiert hatte (Latenz > paar Minuten), griff der 60-Min-Fallback und lieferte den Nachbar-Eintrag der Vorstunde. snap[h:00] wurde dann mit dem Wert von snap[(h-1):00] gespeichert → Slot h = 0 → Slot h+1 = 2-Stunden-Delta als Spike. #145 hatte denselben Mechanismus für get_snapshot (Self-Healing-Pfad) auf 10 Min Toleranz reduziert; der Scheduler-Job blieb dabei übersehen. Fixes: HA-Toleranz 60→10 Min, MQTT-Toleranz 30→10 Min, konsistent zu den anderen Pfaden. Wenn die Stunde zum :05-Zeitpunkt noch nicht in HA ist, schreibt der Job nichts; der nächste aggregate_day-Lauf (15 Min später) holt den Wert via Self-Healing nach. Plus neuer Scheduler-Job sensor_snapshot_preview_job bei :55: Schreibt pro Anlage einen Live-Zählerstand für die anstehende volle Stunde (h+1:00), aber nur wenn dort noch kein Eintrag existiert. Damit ist die laufende Stunde im Energieprofil sofort am Stundenende sichtbar statt erst um (h+1):05.

Cleanup

cleanup(energieprofil): Phase D — W-Fallback + Feature-Flag entfernen (#138) — Folge zu #135. Nach Validation auf Winterborn (v3.19.0+: 538 Tage Backfill, 0.1 % Drift Live↔Prognose-IST) ist der Zähler-Snapshot-Pfad als alleinige kWh-Quelle bestätigt. Phase D entfernt den Rollback-Pfad: Setting energieprofil_quelle und Env-Var EEDC_ENERGIEPROFIL_QUELLE entfernt; in aggregate_day der _val()-Helper raus, Werte direkt aus snap_h; in backfill_from_statistics der else-Branch (W-Pfad als kWh-Quelle) entfernt. Tote batterie_kw_w/waermepumpe_kw_w/wallbox_kw_w/verbrauch_kw_w entfernt — Peaks brauchen nur PV/Bezug/Einspeisung aus W-Integration. Netto −66 Zeilen. Verhalten auf Anlagen mit korrekt gemappten Energiezählern unverändert; auf nicht migrierten Anlagen erscheinen Stunden-kWh-Felder als None statt fehlerhaft hochgerechneter W-Integration.

[3.20.4] - 2026-04-24

Bugfixes

fix(tagesprognose): AttributeError: 'Anlage' object has no attribute 'system_losses' verschluckt — Folgefix zu v3.20.3. Die Tagesprognose lieferte für Anlagen mit PV-Konfiguration weiter 0.0 kWh, obwohl Aussichten-Kurzfrist funktionierte. Log-Beleg: WARNING energie_profil PV-Prognose für Tagesprognose fehlgeschlagen: 'Anlage' object has no attribute 'system_losses'. Ursache: Der Code nutzte anlage.system_losses or 14 — dieses Attribut existiert aber nicht auf dem Anlage-Modell; system_losses liegt historisch auf der letzten aktiven PVGISPrognose (so lesen es auch solar_prognose.py und prefetch_service.py). Der AttributeError wurde im umschließenden try/except als Warning geloggt und die Prognose fiel auf den Null-Initialwert zurück. Jetzt wird system_losses aus PVGISPrognose nachgeladen (gleicher Query wie in den anderen beiden Pfaden) mit Fallback auf DEFAULT_SYSTEM_LOSSES. Damit sind alle drei Prognose-Pfade final konsistent und die Tagesprognose liefert denselben Wertebereich wie Aussichten-Kurzfrist.

[3.20.3] - 2026-04-24

Bugfixes

fix(prognose): kWp/Neigung/Azimut aus Top-Level-Spalten lesen, nicht nur parameter-JSON — Folgefix zu v3.20.2. Aussichten-Kurzfristig zeigte zwar sinnvolle Werte (z.B. 72.4 kWh), aber das lag nur an den zufällig passenden Defaults (Neigung=35°, Azimut=0° ≈ Süd). Im Log (solar_forecast_service) war sichtbar: Open-Meteo Solar: 14 Tage, Neigung=35°, Azimut=0° — also die Werte aus dem Code-Default, nicht aus der Investition. Ursache: InvestitionForm speichert leistung_kwp, neigung_grad und ausrichtung als Top-Level-Spalten auf der Investition-Tabelle, aber nur ausrichtung_grad im parameter-JSON. Die drei Prognose-Pfade (energie_profil.py Tagesprognose, solar_prognose.py Aussichten-Kurzfrist, prefetch_service.py Cache-Warmup) lasen alle ausschließlich aus parameter-JSON — und fielen stumm auf Defaults zurück, wenn die Werte dort nicht waren. Neuer Helper services/pv_orientation.py mit drei Funktionen (get_pv_kwp, get_pv_neigung, get_pv_azimut), die beide Speicher-Orte robust prüfen: erst Top-Level-Spalte, dann parameter.*_grad (Zahl), dann parameter.* (Zahl oder String mit Mapping), dann Default. Alle drei Prognose-Pfade umgestellt — zukünftig liefern sie identische Eingabe-Parameter an Open-Meteo, unabhängig davon, wo die PV-Parameter in der DB stehen.

[3.20.2] - 2026-04-24

Bugfixes

fix(tagesprognose): PV-Prognose fiel auf 0 kWh, wenn PV-Investition Text-Ausrichtung („Süd”) statt numerischem Azimut hatte — Im Energieprofil → Prognose-Tab lieferte die PV-Tagesprognose für Einzel-String-Anlagen teils 0.0 kWh, während Aussichten → Kurzfristig für denselben Tag einen realistischen Wert (z.B. 72.4 kWh) zeigte. Ursache: Der Code in energie_profil.py:1334 las parameter.ausrichtung direkt (z.B. "Süd"), während das Investitionsformular den exakten Azimut parallel in parameter.ausrichtung_grad (int) speichert. Der String ging ungeprüft an get_solar_prognose(), das eine Zahl erwartet — der Open-Meteo-API-Call schlug fehl und die Exception wurde im umschließenden try/except stillschweigend geschluckt, sodass pv_stunden = [0.0] * 24 blieb. Die Kurzfrist-Prognose nutzt dieselbe Logik wie jetzt der Fix: erst ausrichtung_grad (Zahl), dann Fallback auf String-Mapping {"süd": 0, "ost": -90, ...}. Analog für Neigung (neigung_grad → neigung → Default 35°). Beide Prognose-Pfade liefern nun identische Eingabe-Parameter an Open-Meteo.

[3.20.1] - 2026-04-24

Verbessert

enhance(live/energiefluss, auswertung/pv-anlage): Redundante „Stringsumme” bei Einzel-String-Anlagen ausgeblendet (#137, Forum #335 detlan) — An zwei Stellen wurde bei Anlagen mit nur einem PV-String dieselbe Zahl doppelt angezeigt:
- Im Live-Energiefluss stand „Solarleistung X kW” als Summen-Label über dem Haus — identisch mit dem einzigen PV-Knoten-Label daneben. Wird jetzt nur noch bei ≥ 2 PV-Strings angezeigt (Summe über Teilerträge bleibt eine echte Zusatzinformation). Die Y-Position des darüberliegenden „Solar Soll”-Labels folgt dem mit.
- In der Auswertung → PV-Anlage „String-Details”-Tabelle war die „Gesamt”-Fußzeile Duplikat der einzigen Detail-Zeile (kWp, SOLL, IST, Abweichung, kWh/kWp alle identisch, detlan-Kommentar im Issue). Footer wird jetzt nur noch bei data.strings.length > 1 gerendert — die bereits bestehende Konvention im Performance-Chart des gleichen Tabs.
enhance(live/energiefluss): Fließende Strom-Linien im Lite-Modus (Forum dietmar1968) — Nach dem Entfernen der SMIL-Partikel in v3.19.4 (die auf Mobile-Safari die Hauptruckel-Ursache waren) fehlte Dietmar die optische Visualisierung des Stromflusses. Jetzt zeichnet der Lite-Modus auf jeder aktiven Verbindungs-Kern-Linie einen CSS-animierten stroke-dashoffset-Fluss — derselbe Ansatz wie in LuminaCard und Tom’s STATS Card. GPU-beschleunigt, Browser-nativ, kein SMIL-Overhead: Linien fließen deutlich sichtbar zur korrekten Seite (Quellen → Haus, Haus → Senken per animation-direction: reverse), Geschwindigkeit skaliert mit der Leistung (höhere kW = schnellerer Fluss, über CSS-Custom-Property --flow-duration pro Linie). iOS-Nutzer mit „Bewegung reduzieren” erhalten über @media (prefers-reduced-motion: reduce) automatisch statische Linien. Der Effekt-Modus bleibt unverändert — dort liefern die SMIL-Partikel weiterhin den vollen Visual-Wumms.

Bugfixes

fix(tagesverlauf): Börsenpreis-Overlay für die frühen Morgenstunden erschien nicht (#147 Safi105) — Im Live-Dashboard-Tagesverlauf fehlte die gepunktete Börsenpreis-Linie von 00:00 bis zum ersten Datenpunkt des Tages (z.B. 02:00). Zwei Ursachen:
- Der EPEX-Fallback über aWATTar wurde nur geladen, wenn gar kein Strompreis-Sensor im Sensor-Mapping konfiguriert war. Hatten Nutzer einen Tibber/aWATTar-Sensor aktiviert, griff der Fallback nie — und HA-Recorder-Lücken (Sensoren publizieren oft erst nach Mitternacht) fielen heraus. Jetzt wird der Börsenpreis-Fallback immer geladen und pro 10-Minuten-Slot eingefüllt, wenn der Sensor für diesen Slot keine Werte liefert.
- Im Frontend wurden fehlende Overlay-Werte als 0 (statt null) in die Chart-Datenstruktur geschrieben. Recharts zeichnete die Linie dadurch bei Y=0, was außerhalb der automatisch skalierten sekundären Y-Achse (typ. 5–20 ct/kWh) liegt — die Linie war faktisch unsichtbar. Fehlende Overlay-Werte sind jetzt null, connectNulls={false} erzeugt echte Lücken statt unsichtbarer Linien.
- Zusätzlich: TagesverlaufSerie-Pydantic-Model um einheit und max_w erweitert — einheit: "ct/kWh" wurde bisher stillschweigend gestrippt (Legende zeigte „Börsenpreis (EPEX) ()” statt „(ct/kWh)”). Docker-Standalone-Nebenfix: Im MQTT-Pfad war end = now nur im Exception-Branch des EPEX-Loads gesetzt — UnboundLocalError, wenn der Fallback-Load erfolgreich war.
fix(monatsberichte): Kacheln auf Mobile schneiden Text ab (#147 Safi105) — In den Monatsberichten rendete das Grid für Speicher-, Wärmepumpe- und E-Mobilität-KPIs mit grid-cols-2 sm:grid-cols-4, d.h. zwei Spalten bereits unter 640 px. Auf iPhone-Breiten reichte die Spaltenbreite nicht, die KPICard-Titel-/Subtitle-Truncation schlug zu: „Wirkungs…” statt „Wirkungsgrad”, „Kapazität…” statt „Kapazität: 8 kWh”. Jetzt konsistent mit dem Cockpit-Dashboard-Pattern grid-cols-1 sm:grid-cols-2 md:grid-cols-4 — eine Spalte auf Mobile, zwei ab 640 px, vier ab 768 px. Die ausführliche Liste darunter (Ladung/Entladung/Bilanz/Wirkungsverluste) bleibt unverändert.
fix(cockpit): KPICard-Versatz bei klickbaren vs. nicht-klickbaren Karten (#147 Safi105) — In der „Energie-Bilanz”-Sektion fiel die erste Karte (PV-Erzeugung, mit Klick-Navigation) einen Tick kleiner aus als Gesamtverbrauch/Netzbezug/Einspeisung. Ursache: Der Button-Zweig der Dashboard-KPICard setzte className="card p-3", während der nicht-klickbare Zweig <Card className="p-3"> nutzte. Die Card-Komponente injizierte zusätzlich ihr Default-Padding p-6, und mit zwei konkurrierenden Padding-Klassen gewinnt in Tailwind die in der CSS-Reihenfolge spätere — also p-6 statt des gewünschten p-3. Nicht-klickbare Variante nutzt jetzt ebenfalls <div className="card p-3"> direkt, damit beide Varianten pixelgleich sind.
fix(anlagendialog): Löschen von Versorgern/Zählern wurde rückgängig gemacht — Entfernte man im Anlagendialog den letzten Versorger (Strom/Gas/Wasser) und speicherte, erschienen Versorger und Zähler beim nächsten Öffnen wieder („wie von Zauberhand”, Forum-Bericht #376 detlan). Ursache: AnlageForm sendete versorger_daten: undefined, wenn der lokale State leer war — Pydantic exclude_unset=True ließ das Feld im Update dadurch komplett aus, und der Backend-Wert blieb unverändert. Frontend sendet jetzt null, das Feld wird in der DB explizit geleert. Betrifft nur den Fall „letzter Versorger entfernt”; Löschen einzelner Zähler innerhalb eines Versorgers war nie betroffen.
fix(infothek): Vertragsbeginn/Kündigungsfrist erschienen doppelt im Formular — Die Kategorie-Schemas für stromvertrag, gasvertrag, versicherung und wartungsvertrag enthielten eigene vertragsbeginn / kuendigungsfrist_monate / vertragsnummer-Felder, während die übergreifende „Vertragsdaten (optional)“-Sektion darunter dieselben Felder noch einmal rendert (Forum-Bericht #376 detlan). Doppelte Keys aus den Kategorie-Schemas entfernt; die übergreifende Sektion ist jetzt die einzige Stelle für diese drei Felder. JSON-Keys und gespeicherte Parameter bleiben identisch — keine Daten-Migration nötig. Beide PDF-Export-Pfade (reportlab + weasyprint) mergen die übergreifenden Felder beim Rendern, damit Labels wie „Kündigungsfrist (Monate)” korrekt erscheinen statt eines Key-Fallbacks.

Verbessert

enhance(infothek): Zählernummer wird aus Anlagendaten vorbelegt — Beim Anlegen eines neuen Stromvertrag-Eintrags wird die Zählernummer jetzt aus anlage.versorger_daten.strom.zaehler[] vorbelegt (erster Zähler mit gefüllter Nummer). Ergänzt die bereits bestehende Vorbelegung für anbieter, tarif_ct_kwh und kundennummer (Forum-Bericht #376 detlan).

[3.20.0] - 2026-04-23

Bugfixes

fix(kennzahlen): Performance Ratio nutzt jetzt GTI statt horizontaler Einstrahlung (#139) — Die PR-Formel pv_ertrag / (strahlung_summe × kWp) nutzte shortwave_radiation von Open-Meteo — das ist die horizontale Globalstrahlung (GHI). Bei steilen Modulen (typ. 30–40°) und tiefstehender Wintersonne ist die auf die Modul-Fläche projizierte Global Tilted Irradiance (GTI) 2–3× höher. Die theoretische Ertragsreferenz wurde dadurch im Winter systematisch unterschätzt und PR-Werte liefen auf physikalisch unmögliche 1.2–2.8 (Winterborn 2025-12-28: PR=2.807 bei 42.7 kWh Ertrag). Open-Meteo Archive + Forecast liefern jetzt zusätzlich global_tilted_irradiance mit Modul-Tilt und -Azimut; bei Multi-String-Anlagen werden parallele Calls pro Orientierungsgruppe abgesetzt und kWp-gewichtet kombiniert (analog Live-Wetter-Pfad). Ohne gemappte PV-Module bleibt PR bewusst None statt einen verzerrten GHI-Wert zu melden. Validation: Winterborn 2025-12-28 (GHI 1317 Wh/m², GTI Süd35° 3358 Wh/m², Faktor 2.55×) liefert bei 15 kWp Anlagenleistung PR=0.85 (plausibel für einen kalten Wintertag), vorher 2.16. Betrifft historische TagesZusammenfassung.performance_ratio, MonatsAuswertungResponse.performance_ratio_avg und die PR-Spalte im PDF-Jahresbericht — nach Update einmalig „Verlauf nachberechnen + überschreiben” auslösen. PV-kWh-Werte selbst bleiben unverändert.
fix(energieprofil/prognose): Stunden-Slot-Konvention vereinheitlicht auf Backward (#144) — Im Prognosen-Tab (Aussichten → Prognosen → Stundenvergleich) zeigten OpenMeteo, Solcast und IST unter demselben Slot-Label physikalisch unterschiedliche Zeitintervalle: OpenMeteo [N-1, N), Solcast [N-0.5, N+0.5), IST [N, N+1). Forum-Bericht MartyBr (#344) + rapahl (#356): „Um 6:00 Uhr müsste IST noch 0 sein, weil Sonne erst aufgeht”. Jetzt alle drei auf Backward-Konvention Slot N = Energie [N-1, N) — Industriestandard (HA Energy Dashboard, SolarEdge, SMA, Fronius, Tibber). Slot 0 eines Tages enthält jetzt die Energie der letzten Stunde des Vortags (23:00 → 00:00), passend zur Summenbildung.
- sensor_snapshot_service.get_hourly_kwh_by_category: Delta snap[h] − snap[h-1] wird in Slot h eingetragen (vorher: snap[h+1] − snap[h] in Slot h). Snapshot-Range auf h = -1..23 erweitert, damit Slot 0 aus dem Vortag-23:00-Snapshot gefüllt werden kann.
- solcast_service (beide Pfade, API + HA-Sensor): 30-Min-Buckets werden jetzt per Slot-Marker ceil(bucket_ende) dem richtigen Backward-Slot zugeordnet. Ein Bucket am Tagesübergang (z.B. [23:00, 23:30) heute) landet korrekt in Slot 0 des Folgetags, nicht fälschlich in Slot 0 des heutigen Tages.
- Strompreis-Stunden bleiben Forward ([N, N+1)): industrieüblich für aWATTar/Tibber/EPEX („Slot N = Preis ab N Uhr”), semantisch passend für einen Intervallwert „gilt ab jetzt” statt akkumulierter Energie.
- W-Fallback (Anlagen ohne gemappte Zähler) bleibt vorerst Forward — wird mit Issue #138 (W-Fallback-Cleanup) entfernt.
- Nach Update nötig: Einmalig „Verlauf nachberechnen” mit Überschreiben (Energieprofil → Datenverwaltung) auslösen, damit alle historischen Stundenwerte in die Backward-Slots umverteilt werden. Tagessummen und alle abgeleiteten Kennzahlen (Autarkie, PR, Lernfaktor) bleiben konventionsunabhängig korrekt.
fix(energieprofil): Snapshot-Lücken lösen nicht mehr „Stunde-Null + Folge-Spike” aus (#145) — Fehlt ein stündlicher Sensor-Snapshot in sensor_snapshots (Scheduler-Ausfall, HA-Statistics-Timeout, MQTT-Cache leer), erzeugte die kumulative Delta-Bildung in get_hourly_kwh_by_category bisher ein sichtbares Artefakt: eine Stunde mit 0.00 kWh, gefolgt von einer Stunde mit dem aufgestauten 2h-Delta als Spike (Forum-Bericht MartyBr #354). Ursache: Das Self-Healing im get_snapshot-Fallback griff auf HA Long-Term-Statistics mit ±120 min Toleranz zu und lieferte per ORDER BY ABS(...) den zeitlich nächsten Nachbar-Wert zurück — wenn die Stunde in HA ebenfalls fehlte, war das der Wert der Vor- oder Folgestunde, und der nachfolgende Delta snap[h+1] − snap[h] wurde 0. Zwei Änderungen:
- get_snapshot: HA-Statistics-Fallback-Toleranz von 120 min auf 10 min reduziert. Hourly-Statistics speichern auf der Stundengrenze; eine Abweichung > 10 min ist fast immer ein „kein Eintrag zur Zielstunde” — der Fallback liefert dann bewusst None, statt einen falschen Nachbar-Wert. Gleiches Prinzip für den MQTT-Snapshot-Fallback (30 → 10 min), zusätzlich nearest-Sortierung statt timestamp.asc() (der frühere „erster-im-Fenster”-Lookup hätte bei mehreren Publikationen zufällig den ältesten zurückgegeben).
- get_hourly_kwh_by_category: Nach der Snapshot-Collection werden echte Lücken jetzt linear zwischen den Nachbar-Stunden interpoliert. Ein kumulativer Zähler wächst monoton — die Interpolation verteilt das Gesamt-Delta über eine Lücke gleichmäßig auf die betroffenen Stunden, statt es in eine einzige Stunde aufzustauen. Ränder (H0 fehlend am Tagesanfang, H24 am Tagesende) werden nicht extrapoliert — dort bleibt der Wert None und die betroffene Stunde fällt wie bisher aus der Delta-Bildung. Tagessumme bleibt in allen Fällen korrekt (bereits vorher durch snapshot[24] − snapshot[0]).
⚠ Nachträglich richtiggestellt (September 2026): Für Anlagen mit Home-Assistant-Statistik gilt die lineare Auffüllung nicht mehr. Seit eedc Zählerlücken wie das HA-Energie-Dashboard rechnet, steht die Energie einer fehlenden Stunde in der Stunde danach — wie in HA; diese Stunde ist in Stundentabelle und Tagesverlauf beschriftet („enthält n Stunden“) und zählt in Stunden-Auswertungen nicht als Stichprobe. Linear aufgefüllt wird nur noch innerhalb eines Tages im Zählerstands-Pfad ohne HA-Statistik (Standalone, MQTT). Die Tagessumme stimmte in beiden Fällen.

[3.19.4] - 2026-04-23

Performance

perf(live/energiefluss): Lite-Modus jetzt wirklich „lite” — iPad/Mobile-Safari — Drei Änderungen am Energiefluss-Diagramm, die zusammen Ruckler auf iPad und schwächeren Mobile-Geräten beseitigen sollten. Forum-Bericht (#345 + #353, dietmar1968: „ruckelt auch im Lite-Modus”).
- SMIL-Partikel-Animationen werden im Lite-Modus nicht mehr gerendert — Bisher liefen pro aktiver Linie weiterhin ein <animateMotion> + ein <animate> mit repeatCount="indefinite". Bei einer Anlage mit 6 aktiven Knoten waren das ≥12 dauerhafte SMIL-Animationen — auf Mobile-Safari der mit Abstand größte Performance-Faktor (WebKit hat SMIL nie effizient implementiert). Im Effekt-Modus bleiben sie unverändert.
- filter-Attribute der Knoten-Karten werden im Lite-Modus weggelassen — statt sie nur zu No-Op-Filter-Definitionen zu reduzieren. Safari erstellt für jedes Element mit filter="…" einen separaten Compositing-Layer, auch wenn der Filter nichts tut.
- EnergieFlussBackground in React.memo gewrappt — die ~180 SVG-Hintergrund-Elemente (Sterne, Ringe, Strahlen je nach Variante) werden jetzt nicht mehr bei jedem 5-Sekunden-Polling neu durch React diff’d, weil sich keine Background-Props ändern.

[3.19.3] - 2026-04-23

Bugfixes

fix(community): BKW-Leistung jetzt × Anzahl Module aggregiert — community_service.py summierte für Balkonkraftwerk nur das Feld leistung_wp (Watt pro Modul), ohne die Anzahl der Module einzurechnen. 800-W-BKWs mit 2 × 400 W erschienen in der Community-Anzeige daher als 400 W. Forum-Bericht (#342, Radiocarbonat).
fix(community/trends): Tooltip in „Community-Entwicklung” zeigt formatierte Labels — Der Hover-Tooltip im Trends-Tab nutzte die rohen Daten-Keys (speicher, waermepumpe, eauto), während die Legende darunter bereits korrekt formatierte. Tooltip nutzt jetzt denselben nameFormatter wie die Legende (Speicher-Quote, Wärmepumpen-Quote, E-Auto-Quote). Forum-Bericht (#342, Radiocarbonat).
fix(live/tagesverlauf): Legenden-Toggle blendet wieder ein — Klick auf einen Legenden-Eintrag entfernte die Linie/Area komplett aus dem DOM (über hatDaten()-Filter bei 0-Daten), wodurch ein erneuter Klick die Serie nicht zurückbringen konnte. Hide-Steuerung wurde auf das Recharts-eigene hide-Prop umgestellt; Toggle funktioniert jetzt zuverlässig in beide Richtungen — sowohl für Areas (PV/Verbrauch/Speicher) als auch für die Overlay-Linie (Strompreis). Forum-Berichte (#343 detlan, #348 dietmar1968).
fix(waermepumpe): „Wärmepumpe” wird im Kostenvergleichs-Chart nicht mehr abgeschnitten — Y-Achsen-Spalte des horizontalen Bar-Charts war mit width={100} zu schmal für das längste Label (11 Zeichen). Auf 110 erhöht — analog zu bestehenden Charts in der Auswertung. Forum-Bericht (#343, detlan).
fix(live/energiefluss): iPad-Lite-Default robuster — Der Auto-Detect für den Lite-Modus (reduzierte Animationen, kein Blur-Filter — schont schwächere GPUs) griff für iPads bisher nur unter 768 px Viewport-Breite, was iPads üblicherweise nicht erfüllen. Zusätzlich identifiziert sich iPadOS-13+ in Safari als „Macintosh”, weshalb die /iPad/-UA-Prüfung leer lief. Erkennung jetzt zusätzlich über navigator.maxTouchPoints > 1 bei Macintosh-UA. Wirkt nur bei neuen Nutzern — wer den Toggle bereits einmal manuell angefasst hat, behält seine localStorage-Wahl. Forum-Bericht (#345, dietmar1968).

Issues

#143 Wetter-Dashboard: vermutete Zeitverschiebung in Stunden-Prognose (offen, wartet auf Diagnose-Daten von MartyBr — Forum #344)

[3.19.2] - 2026-04-23

Bugfixes

fix(ui/tooltip): Tooltip löst horizontalen Scroll in Tabellen aus — FormelTooltip rendert jetzt mit position: fixed (statt absolute), damit overflow-x:auto-Container (z. B. ROI-Tabelle) den Tooltip nicht clippen und keinen unerwünschten horizontalen Scroll auslösen. Tooltip bleibt zudem zuverlässig im Viewport (Links-/Rechts-Clamp). Forum-Bericht (#340): Scrollbar in der ROI-Tabelle „kurz sichtbar, springt zurück”.
fix(ui/charts): Y-Achse zeigte „0000 kWh” statt „10.000 kWh” — Im Cockpit-PV-Anlage-Diagramm (PVStringVergleich) wurde der Y-Achsen-Tick bei 10.000 kWh wegen zu schmaler Achse abgeschnitten. Formatter nutzt jetzt deutsche Tausenderpunkte (10.000 kWh) und schaltet bereits ab 5.000 kWh auf MWh-Anzeige um (10 MWh).

Verbessert

enhance(ui/charts): SOLL/IST-Farben vereinheitlicht — Neue Konstante SOLL_IST_COLORS (Blau/Amber/Grün) in lib/colors.ts. Beide SOLL-IST-Diagramme im Auswertungen-PV-Tab nutzen sie konsistent (vorher: opacity={0.6} auf SOLL machte das Blau im zweiten Diagramm dunkler als die Legende — Forum-Bericht #340: „Das Blau im zweiten Diagram entspricht nicht dem Blau der Legende”). Cockpit-PV-Vergleich nutzt sie bei Single-String-Anlagen, behält die String-Farben-Differenzierung bei mehreren Strings.

Issues

#136 WP-Taktungs-Anzahl als fortlaufender Zähler in Tages-/Monats-Analytik (offen)
#137 Live-Energiefluss: Stringsumme über dem Haus bei Einzel-PV-Konfiguration ausblenden (offen)
#140 ROI/Amortisations-Anzeige verschlanken: weniger parallele Werte, klarere Hierarchie (offen, Diskussion mit detlan)

[3.19.1] - 2026-04-22

Bugfixes

fix(ha-export/mqtt): WP-/E-Auto-/BKW-Ersparnisse in MQTT-Jahresersparnis — Die MQTT-Sensoren jahres_ersparnis_euro, roi_prozent und amortisation_jahre rechneten bisher nur den PV-Netto-Ertrag (Einspeise-Erlös + Eigenverbrauchs-Ersparnis) und ignorierten die Alternativkosten-Ersparnisse von Wärmepumpe (vs. Gas/Öl), E-Auto (vs. Benzin) und Balkonkraftwerk. Bei Anlagen mit WP/E-Auto führte das zu absurd langer Amortisation (Forum-Bericht: 188,6 Jahre). calculate_anlage_sensors rechnet die historischen Komponenten jetzt analog zu aussichten.py:get_finanz_prognose mit ein. Wirkt automatisch auch im periodischen mqtt_auto_publish_job.
fix(community): JAZ-Kachel nutzt typ-spezifischen Vergleich — Die Wärmepumpen-JAZ in der Komponenten-Kachel der Community-Übersicht verglich gegen den globalen Durchschnitt über alle WP-Arten, während das Verbesserungspotenzial bereits den fairen typ-spezifischen Vergleich (jaz_typ) nutzte. Ergebnis: leicht abweichende Prozentwerte bei identischer Kennzahl (Forum-Rückfrage: -11,1 % vs. -11,9 %). Beide Darstellungen nutzen jetzt konsistent jaz_typ mit Fallback auf jaz.

Verbessert

enhance(ui/roi): „Sicht”-Hinweis in allen ROI-Tooltips — FormelTooltip um optionalen sicht-Block erweitert. Alle ROI-/Amortisations-Anzeigen (Cockpit, Investitionen-Tab inkl. „Tatsächlich realisiert”-Block, ROI-Dashboard inkl. Detail-Tabelle, Aussichten-Finanzen, Amortisations-Bar) zeigen jetzt im Tooltip an, welche Sicht die Zahl darstellt (z. B. „Pro Investition · Jahres-ROI · Mehrkosten-Ansatz · Prognose” vs. „Gesamt-Anlage · IST-Werte · kumuliert”). Adressiert die im Forum berichtete Verwirrung über mehrere unterschiedliche ROI-/Amortisations-Werte nebeneinander.

[3.19.0] - 2026-04-22

Kritischer Bugfix

fix(energieprofil): kWh-Werte aus Zähler-Snapshots statt Leistungs-Integration (#135) — Bisher berechnete aggregate_day Stunden-kWh aus leistung_w-10-Min-Samples (±5-15% Drift), obwohl kumulative Zähler wie pv_erzeugung_kwh im Sensor-Mapping vorhanden waren. Dadurch wichen Prognosen-IST, Lernfaktor, Heatmaps und abgeleitete Monatswerte vom Live Dashboard ab (konkreter Fall: Winterborn 2026-04-22 — Live 28.3 vs Prognosen IST 31.0 kWh, Zähler-Realität 31.25 kWh). Neue Architektur: Scheduler-Job schreibt stündlich kumulative Zählerstände in die sensor_snapshots-Tabelle, alle kWh-Werte werden als Snapshot-Differenz berechnet. Quellen: HA Statistics (Add-on) oder MQTT-Energy-Snapshots (Standalone/Docker). Self-Healing füllt Lücken on-demand.

Features

feat(energieprofil): Strikte NULL-Semantik bei fehlenden Zählern — Wenn keine kumulativen Zähler gemappt sind, bleiben die betroffenen TagesEnergieProfil-Felder NULL statt aus Leistungs-Samples geschätzt zu werden. Prognosen-IST-Response enthält neues ist_unvollstaendig-Flag, Monatsauswertung liefert stunden_fehlend_pv/stunden_fehlend_verbrauch. Frontend zeigt ⚠-Badge neben IST-Werten bei Datenlücken.
feat(datencheck): Neue Kategorie „Energieprofil – Zähler-Abdeckung” — Daten-Checker prüft pro Anlage und Komponente, welche kumulativen kWh-Zähler (pv_erzeugung_kwh, ladung_kwh, entladung_kwh, stromverbrauch_kwh, Einspeisung/Netzbezug) gemappt sind. Warnt mit konkreter Liste fehlender Zähler und verlinkt zum Sensor-Mapping-Wizard.

Verbessert

enhance(energieprofil): Info-Banner auf Datenverwaltungs-Seite — Neuer Hinweis, der Nutzer einmalig nach dem Update zur Ausführung von „Verlauf nachberechnen” mit aktiver „Überschreiben”-Option auffordert, damit historische Daten auch aus Zählern statt aus Leistungs-Schätzung stammen.
enhance(prognosen): StundenProfilEintrag.kw jetzt nullable — Datenlücken im Stundenprofil werden als null übertragen (Recharts zeigt Chart-Unterbrechung statt 0-Linie).

Backend

feat(db): Neue Tabelle sensor_snapshots — Stündliche Snapshots kumulativer kWh-Zählerstände (anlage_id + sensor_key + zeitpunkt). Basis für die neue Energieprofil-Berechnung.
feat(api): HA Statistics Helper get_value_at — Liest kumulativen Zählerstand zu einem bestimmten Zeitpunkt aus HA Statistics (SQLite + MariaDB, Wh→kWh-Konvertierung, ±Toleranzfenster).
feat(scheduler): sensor_snapshot_job — Neuer stündlicher Job (minute=5 Cron) schreibt aktuelle Zählerstände aus HA Statistics + MQTT-Energy-Cache in sensor_snapshots.
feat(standalone): MQTT-Energy-Cache als Zähler-Quelle — Standalone/Docker-Installationen ohne HA Statistics nutzen automatisch mqtt_energy_snapshots als Basis für die Zähler-Berechnung. aggregate_day synthetisiert ein 24h-Stundenraster wenn nur kumulative Zähler ohne leistung_w verfügbar sind.
fix(backfill): sonstige_keys in _sonderschluessel ergänzt — Latenter Bug in backfill_from_statistics: Sonstige-Erzeuger-Investitionen flossen doppelt in pv_kw ein (analog zum bereits gefixten Bug in aggregate_day).
feat(config): Feature-Flag EEDC_ENERGIEPROFIL_QUELLE — Default "zaehler" (neue Architektur), Rollback auf "leistung_w" möglich bei Problemen.

Hinweis

Empfohlene Aktion nach Update: Auf Einstellungen → Energieprofil → Verlauf nachberechnen klicken, Option „Bestehende Tage überschreiben” aktivieren, dann „Verlauf nachberechnen” auslösen. Dadurch werden historische Tagesprofile konsistent aus den kumulativen Zählerständen neu berechnet (einmalig, 1-5 Min Laufzeit). Ohne diesen Schritt bleiben ältere Tage mit der alten Leistungs-Schätzung bestehen.

[3.18.0] - 2026-04-21

Features

feat(energieprofil): Eigener Tab mit Tages-Tabelle + Datenverwaltung (#133) — Neue Seite Einstellungen → Energieprofil bündelt die tagesbezogenen Auswertungen und Datenverwaltungs-Aktionen der gewählten Anlage. Datenbestand-Kacheln (Stundenwerte/Tagessummen/Monatswerte, Abdeckung, Zeitraum) sind jetzt anlage-spezifisch. Tages-Tabelle mit Jahr/Monat-Selektor (zeigt nur Zeiträume mit Daten), Spalten-Selektor mit Gruppen (Peak-Leistungen, Tages-Summen, Performance, Wetter, §51-Börsenpreise), 12-Zeilen-Scrollansicht mit sticky Header. Aktionen: Vollbackfill aus HA-Statistik (mit overwrite-Option), Kraftstoffpreis-Tages-Backfill (nur sichtbar bei offenen Tagen), Energieprofil-Daten löschen (anlage-spezifisch statt global).
feat(monatsdaten): Datenverwaltung auf Monatsdaten-Seite — Neuer Abschnitt für Kraftstoffpreis-Monats-Backfill (nur sichtbar bei offenen Monaten). Tabelle jetzt auf ~12 Zeilen mit eigener vertikaler Scrollbar und sticky Header begrenzt. <select>-Accessibility-Labels verknüpft.

Verbessert

enhance(navigation): Tab-Konsolidierung (#133) — Tab Monatsabschluss in der Einstellungen-Tab-Leiste entfernt (war nur Redirect auf Monatsdaten). Direkt-Einstieg über den Monatsabschluss-Menüpunkt in der Einstellungen-Dropdown bleibt erhalten. Neuer Tab Energieprofil in der Daten-Gruppe ergänzt.
enhance(settings): Allgemein entkernt — Block Datenbestand Energieprofile samt globalem Löschen-Button aus Einstellungen → Allgemein entfernt (wandert zur neuen Energieprofil-Seite). Die Seite zeigt jetzt nur noch Theme, HA-Integration und Datenbank-Info.

Backend

feat(api): Anlage-spezifische Energieprofil-Endpoints — Neu: GET /energie-profil/{id}/stats (Profildaten-Kennzahlen pro Anlage), GET /verfuegbare-monate (Jahr/Monat-Kombinationen mit Einträgen), GET /kraftstoffpreis-status (offene Tages-/Monats-Zeilen), POST /kraftstoffpreis-backfill/tages und /monats als Split des bisherigen kombinierten Endpoints (Alt-Endpoint bleibt als Alias). DELETE /energie-profil/{id}/rohdaten löscht jetzt konsistent auch TagesZusammenfassung (analog zum globalen Alt-Endpoint).

[3.17.1] - 2026-04-21

⚠️ Backup erforderlich — Internes Refactoring der Formulardaten-Verarbeitung. Bitte vor dem Update ein Backup erstellen.

Verbessert

refactor(monatsdaten): Dynamisches Formular aus field_definitions (#132 Phase E) — MonatsdatenForm nutzt jetzt getFelderFuerInvestition() als Single Source of Truth für alle Investitionsfelder. Initialisierung, Submit-Handler und Section-Rendering sind vollständig generisch — keine hardcodierten Typ→Felder-Maps mehr. 4 spezialisierte Section-Komponenten (Speicher, E-Auto, Balkonkraftwerk, Sonstiges) durch die generische InvestitionSection ersetzt. Neue Felder werden automatisch angezeigt wenn sie in field_definitions.py definiert sind.

Bugfixes

fix(monatsdaten): Sonstiges/Speicher sendete falsche Feldnamen — Die Monatsdaten-Erfassung für Sonstiges-Investitionen der Kategorie “Speicher” sendete ladung_kwh/entladung_kwh statt der kanonischen Namen erzeugung_kwh/verbrauch_sonstig_kwh. Die alten Feldnamen wurden vom Cockpit nie gelesen, sodass diese Daten in der Auswertung fehlten. Jetzt werden die korrekten kanonischen Namen verwendet.

[3.17.0] - 2026-04-21

Features

feat(kraftstoffpreis): Dynamische Benzinpreise für E-Auto-ROI — Statt statischem benzinpreis_euro-Parameter werden jetzt echte monatliche Kraftstoffpreise aus dem EU Weekly Oil Bulletin verwendet. Neues Feld Monatsdaten.kraftstoffpreis_euro (€/L) mit automatischem Vorschlagswert im Monatsabschluss-Wizard (Konfidenz 85). ROI-Berechnung (Aussichten), HA-Sensor-Export und PDF-Finanzbericht nutzen pro Monat den echten Preis — Fallback auf statischen Parameter wenn kein Monatswert vorhanden. Backfill-Endpoint befüllt auch Monatsdaten rückwirkend (Oil Bulletin History seit 2005).

Hinweis: Die E-Auto-Ersparnis (Aussichten, HA-Sensor, PDF) wird jetzt mit echten monatlichen Benzinpreisen berechnet statt mit dem statischen Wert aus den Investitions-Parametern. Dadurch können sich angezeigte Ersparnisse gegenüber früheren Versionen verändern — nach oben oder unten, je nachdem ob der reale Preis über oder unter dem konfigurierten Wert lag. Die Berechnung ist damit genauer. Um die Monatsdaten rückwirkend mit Preisen zu befüllen: Einstellungen → Energieprofil → Kraftstoffpreis-Backfill.

Verbessert

enhance(monatsabschluss): Preisfelder im Wizard und Zusammenfassung — Kraftstoffpreis und Strompreis werden jetzt in der Basisdaten-Seite und in der Zusammenfassung des Monatsabschluss-Wizards angezeigt. Monatsdaten-Formular (Erstellen/Bearbeiten) zeigt ebenfalls das Benzinpreis-Feld (bedingt: nur bei E-Auto-Investitionen).

[3.16.16] - 2026-04-21

Features

feat(energieprofil): Verbrauchsprognose (Etappe 3b Phase A) — Neuer Sub-Tab “Prognose” im Energieprofil: Kombinierte Verbrauchs- + PV- + Batterie-Prognose für einen Tag. Verbrauchsprofil aus historischen Stundenmitteln (gewichteter Ø, Wochentag-Kaskade, Halbwertszeit 14 Tage), PV-Stundenprofil aus OpenMeteo GTI (kalibriert mit Lernfaktor) oder Solcast, Batterie-SoC-Simulation mit Speicher-voll/leer-Zeitpunkt. Chart (PV/Verbrauch/Netto + SoC-Overlay), KPI-Cards, Stundentabelle.

Vorbereitung (v3.17.0)

prep(kraftstoff): EU-Kraftstoffpreis-Sammlung — Wöchentliche nationale Durchschnittspreise (Euro-Super 95, inkl. Steuern) aus dem EU Weekly Oil Bulletin der EU-Kommission. Historische Daten seit 2005, alle EU-Länder + CH (via AT). Scheduler-Job (Di 06:00), manueller Backfill-Endpoint, Speicherung in TagesZusammenfassung.kraftstoffpreis_euro. Vorbereitung für dynamische E-Auto-Ersparnisberechnung.

Bugfixes

fix(energieprofil): pv_kw zählte Sonstiges-Erzeuger fälschlich als PV — Sonstige Erzeuger (BHKW etc.) wurden in der TagesEnergieProfil-Aggregation mitgezählt, was PV-spezifische KPIs (Performance Ratio, Lernfaktor) verfälschte.
fix(prognose): Grün-Schwelle bei Prognose-Abweichung auf 10% — Anpassung der farblichen Bewertung der Prognosegenauigkeit.

[3.16.15] - 2026-04-20

Features

feat(prognose): Saisonaler Lernfaktor (MOS-Kaskade) — Der Lernfaktor nutzt jetzt eine saisonale Kaskade: Monatsfaktor (≥15 Tage gleicher Kalendermonat) → Quartalsfaktor (≥15 Tage) → 30-Tage-Fenster (≥7 Tage, bisheriges Verhalten). Bei wachsendem Datenbestand wird die Kalibrierung automatisch präziser. Im Prognosen-Tab wird die aktive Stufe angezeigt.
feat(prognose): Erweiterbare Prognose-Architektur — Prognose-Quellen als Registry (PROGNOSE_QUELLEN) für zukünftige Erweiterungen vorbereitet. Neues Anlage-Feld prognose_basis zur Auswahl der Kalibrierungsquelle in den Anlagenstammdaten. Lernfaktor wird pro Quelle separat berechnet und gecacht.

[3.16.14] - 2026-04-20

Bugfixes

fix(prefetch): Prognose-Persistierung vom Dashboard in den Scheduler verlagert — pv_prognose_kwh und Solcast-Tageswerte werden jetzt alle 45 Min automatisch vom Prefetch-Job in TagesZusammenfassung geschrieben. Vorher war die Persistierung ein Nebeneffekt des Dashboard-Besuchs (fragil), was dazu führte, dass der Lernfaktor bei keinem Nutzer berechnet werden konnte.

[3.16.13] - 2026-04-20

Bugfixes

fix(solcast): DetailedForecast Attribut-Name korrigiert — BJReplay Solcast-Integration liefert das Stundenprofil als DetailedForecast, nicht detailedHourly. Dadurch fehlten bei HA-Sensor-Nutzern das Stundenprofil im Chart und die p10/p90 Konfidenzintervalle in der 7-Tage-Tabelle. Betraf insbesondere Anlagen mit mehreren Dachsegmenten (Danke @rapahl).

[3.16.12] - 2026-04-20

Bugfixes

fix(prognosen): 0.0 kWh ab Tag 3 bei icon_d2 Wettermodell — Modelle mit kurzem Horizont (z.B. icon_d2 = 2 Tage) lieferten ab Tag 3 keine Daten. Neuer Fallback: Primary-Modell + best_match parallel abrufen und Tage mergen (analog zur GTI-Kaskade).
fix(prognosen): Verbleibend-Werte pro Quelle in KPI-Matrix — Die Verbleibend-Zeile zeigt jetzt OM/EEDC/Solcast-Werte (Tagesprognose − bisheriger IST) statt nur den kombinierten IST-Wert.
fix(solcast): Entity-Mapping für “übermorgen” — _ubermorgen und _uebermorgen als Aliase für tag_3 im Suffix-Mapper ergänzt.
fix(prognosen): Solcast p90-Konfidenzband im Stundenprofil entfernt — Der halbtransparente “Schatten” im Chart sorgte für Verwirrung.
fix(prognosen): Σ-Summenzeile im Stundenvergleich sticky — Die Summenzeile ist jetzt am unteren Rand fixiert und bleibt beim Scrollen sichtbar.

[3.16.11] - 2026-04-19

Bugfixes

fix(solcast): Discovery filtert auf kWh + schließt “verbleibend” aus — prognose_verbleibende_leistung_heute konnte statt prognose_heute gematcht werden (beide enden auf _heute). Jetzt: nur Sensoren mit unit_of_measurement=kWh und ohne “verbleibend”/“remaining” im Namen.
fix(prognosen): IST-Berechnung schließt strompreis/netzbezug/einspeisung aus — komponenten_kwh enthält auch strompreis (ct/kWh), netzbezug und einspeisung. Diese verfälschten den IST-Wert im Genauigkeits-Tracking und Lernfaktor massiv (z.B. 244 kWh statt 40 kWh wegen strompreis=202.95 ct).

[3.16.10] - 2026-04-19

Bugfixes

fix(solcast): Discovery via /api/states Suffix-Pattern statt Entity Registry — Die Entity Registry API ist über die HA Supervisor REST API nicht verfügbar (404), und unique_ids können sich bei Integrations-Updates ändern. Neuer Ansatz: /api/states laden und Solcast-Entities per Suffix-Pattern matchen (_heute/_today, _morgen/_tomorrow, _tag_N/_day_N). Robust gegenüber Spracheinstellungen, Umbenennungen und unique_id-Änderungen.
fix(live): Redundanten Momentwerte-Text über Energiefluss entfernt — Refresh-Takt wird bereits oben rechts angezeigt (5s), der separate Text war zudem falsch (~30s).

[3.16.9] - 2026-04-19

Bugfixes

fix(solcast): Auto-Discovery sprachunabhängig via Entity Registry — Solcast-Sensoren werden jetzt über die HA Entity Registry (unique_id) aufgelöst statt über hardcodierte entity_ids. Funktioniert unabhängig von der HA-Spracheinstellung (prognose_heute vs. vorhersage_heute vs. forecast_today).
fix(energieprofil): aggregate_day() überschreibt Prognose-Felder nicht mehr — aggregate_day() löschte die gesamte TagesZusammenfassung und verlor dabei pv_prognose_kwh, sfml_prognose_kwh und solcast_*_kwh. Jetzt werden die Prognose-Felder vor dem DELETE gerettet und nach dem INSERT wiederhergestellt. Dadurch wird der Lernfaktor und das Genauigkeits-Tracking erstmals korrekt befüllt.

Neu

Prognosen-Abweichungen inline mit Farbskala — Stundenvergleich + 7-Tage-Vergleich zeigen die Abweichung direkt neben jedem Prognosewert (OM, EEDC, Solcast) mit Pfeil (↑/↓) und Farbskala (grün <15%, gelb 15–30%, rot >30%). Bei Zukunfts-Tagen ohne IST wird der Mittelwert aller Prognosen als Referenz verwendet.

[3.16.8] - 2026-04-19

Bugfixes (Code-Audit v3.16.3–v3.16.7)

fix(prognosen): bestPrognose-Berechnung lieferte false statt Zahl — Δ-Spalte im Stundenvergleich zeigte falsche Werte wenn Solcast nicht aktiv
fix(prognosen): 0-as-falsy bei eedc_*_kwh und Genauigkeit — 0.0 kWh Prognose wurde als None angezeigt statt als 0
fix(prognosen): asyncio.gather mit Fehler-Isolation — Ein API-Timeout (OpenMeteo/Solcast) crashte den gesamten Prognosen-Tab, jetzt werden verfügbare Daten angezeigt
fix(sensor-mapping): ?force=true DELETE-Parameter implementiert — War nur in Fehlermeldung referenziert, Query-Parameter fehlte

Neu

API: POST /api/energie-profil/reaggregate-heute — Manuelle Neu-Aggregation des heutigen Tages (nach Bugfixes oder Konfigurationsänderungen)

[3.16.7] - 2026-04-19

Bugfix

fix(energieprofil): Börsenpreis-Kontamination in pv_kw behoben — Der strompreis-Schlüssel aus den Tagesverlauf-Daten (ct/kWh) wurde fälschlich als PV-Erzeugung (kW) in pv_kw aufaddiert. Betroffen: IST-Stundenprofil im Prognosen-Tab (falsche Werte nachts), komponenten_kwh in TagesZusammenfassung, Lernfaktor-Berechnung. Fix: strompreis und haushalt aus der generischen Energiefluss-Aggregation ausgeschlossen.

[3.16.6] - 2026-04-19

Solcast PV Forecast — Stabiles Release

Zusammenfassung von v3.16.4 + v3.16.5 (Pre-Releases) als stabile Version.

Neuer Tab „Prognosen” in Aussichten: OpenMeteo / EEDC (kalibriert) / Solcast / IST im Vergleich
Solcast HA-Integration: Ein Toggle im Sensor-Mapping Wizard — automatische Erkennung der Solcast-Sensoren (BJReplay)
Solcast API-Zugang: Für Standalone-Nutzer (Free/Paid Key), L1/L2-Cache überlebt Neustarts
KPI-Matrix: Heute/Morgen/Übermorgen × alle Quellen mit VM/NM-Split
Stundenprofil-Chart: GTI-basiertes OpenMeteo, EEDC (kalibriert), Solcast, IST mit p10/p90-Band
24h + 7-Tage-Vergleichstabelle: Mit Differenzen und Wetter-Symbolen
Genauigkeits-Tracking: MAE-Berechnung über historische IST-Daten
Integrations-Vorschlag: Erläuterung der Nutzung in Live, Kurzfristig, Lernfaktor, Finanzen
Statusmeldungen: Kontextbezogene Hinweise (Tageslimit, Auth, HA nicht erreichbar)
Sicherheit: DELETE-Schutz für sensor_mapping mit aktiven Live-Sensoren
Refactoring: Prognosen-Code in eigene prognosen.py ausgelagert
DB-Migration: 3 neue Spalten in TagesZusammenfassung (solcast_prognose_kwh, p10, p90)

[3.16.5] - 2026-04-19 (Pre-Release)

Solcast PV Forecast — Sensor-Mapping Wizard

Ein-Klick-Aktivierung: Toggle „Solcast PV Forecast” im Sensor-Mapping Wizard — automatische Erkennung der Solcast HA-Integration (BJReplay), kein manueller DB-Eintrag nötig
7-Tage-Prognose aus HA-Sensoren: Heute + Morgen + Tag 3–7 direkt als Sensor-States gelesen (standardisierte Entity-IDs)
Zusammenfassung: Solcast-Sektion im Wizard-Abschluss sichtbar
Status-Hinweise: Kontext-bezogene Meldungen wenn Sensoren noch nicht geladen oder HA nicht erreichbar

[3.16.4] - 2026-04-19

Solcast PV Forecast — Prognosen-Vergleich (Evaluierung)

Neuer Tab „Prognosen” in Aussichten: Evaluierungs-Cockpit für das Zusammenspiel von OpenMeteo und Solcast
Solcast-Service: API-Zugang (Free/Paid) und HA-Sensor-Anbindung mit L1/L2-Cache (überlebt Neustarts)
EEDC-Prognose: Kalibrierter OpenMeteo-Wert (×Lernfaktor) als dritte Vergleichsspalte
KPI-Matrix: OpenMeteo / EEDC / Solcast / IST × Heute / Morgen / Übermorgen mit VM/NM-Split
Stundenprofil-Chart: 4 Linien (IST grün, EEDC orange, Solcast blau, OpenMeteo gelb) + Solcast p10/p90-Band
24h-Vergleichstabelle: Stündliche Werte mit Differenzen (Δ IST–Prognose)
7-Tage-Vergleichstabelle: Alle Quellen mit Solcast-Konfidenzband
Genauigkeits-Tracking: MAE-Berechnung (OpenMeteo vs. Solcast) aus historischen TagesZusammenfassungen
Statusmeldungen: Kontextbezogene Hinweise bei Tageslimit, fehlender Config, HA nicht erreichbar
Integrations-Vorschlag: Erläuterung der geplanten Einbindung in Live, Kurzfristig, Lernfaktor, Finanzen
Refactoring: Prognosen-Code aus aussichten.py in eigene prognosen.py ausgelagert (−360 Zeilen)
DB-Migration: 3 neue Spalten in TagesZusammenfassung (solcast_prognose_kwh, p10, p90)

[3.16.3] - 2026-04-18

Verbesserungen (Community-Feedback)

Sensor-Mapping: Strompreis-Sensoren mit Einheiten wie ct, Cent, EUR/MWh, € werden jetzt akzeptiert (bisher nur EUR/kWh, ct/kWh, €/kWh)
Tagesverlauf: EUR/MWh-Sensoren werden korrekt nach ct/kWh normalisiert (×0.1)
PDF-Deckblatt: MaStR-Feld durch Geo-Koordinaten ersetzt, Schriftgrößen für Adresse und Komponentenliste vergrößert
Energiefluss: Leistungsanzeige bleibt bis 9.999 W in Watt, Umschaltung auf kW erst ab 10 kW

[3.16.2] - 2026-04-18

Infothek — Investitionsformular verschlanken (Etappe 3.6)

Stammdaten-Felder entfernt: Gerätedaten (stamm_*), Ansprechpartner (ansprechpartner_*) und Wartungsvertrag (wartung_*) aus dem Investitionsformular entfernt — alle Daten werden jetzt über die Infothek verwaltet
Infothek-Verknüpfungen im Formular: Beim Bearbeiten einer Investition werden verknüpfte Infothek-Einträge als kompakte Liste mit Kategorie und Direktlink angezeigt
PDF-Jahresbericht bereinigt: Gerätedaten/Ansprechpartner/Wartung-Sektionen entfernt (Anlagendokumentation-PDF nutzt bereits ausschließlich Infothek-Daten)
Migrations-Banner bleibt: Nutzer mit Altdaten sehen weiterhin den Hinweis „Stammdaten in Infothek übernehmen?” in der Investitions-Übersicht
Dokumentation aktualisiert: ARCHITEKTUR.md (Infothek-Datenmodell im ER-Diagramm + Tabellen), HANDBUCH_INFOTHEK.md (Migrations-Hinweis + Formular-Verknüpfungen)

[3.16.1] - 2026-04-18

Bugfix

Wetter-Widget: Strompreis-Sensor (EPEX Börsenpreis, kat=preis) wurde fälschlich als „Sonstige”-Verbrauch interpretiert — ct/kWh-Werte erschienen als ~11 kW graue Fläche ab 02:00 Uhr im Tagesverlauf-Chart

[3.16.0] - 2026-04-18

Feature — Dynamischer Strompreis: Sensor-Mapping + EPEX-Börsenpreis (Joachim-xo)

Sensor-Mapping Wizard: Neues optionales Feld „Strompreis (dynamischer Tarif)” unter Basis-Sensoren — Tibber, aWATTar, EPEX oder eigener Template-Sensor zuordnen
Börsenpreis für alle: EPEX Day-Ahead Preise (DE/AT) werden automatisch via aWATTar API geholt — als Overlay im Tagesverlauf, auch ohne eigenen Sensor
Tagesverlauf-Overlay: Eigener Sensor → „Strompreis”, kein Sensor → „Börsenpreis (EPEX)” — pinke Linie auf sekundärer Y-Achse
MQTT-Support: Topic eedc/{id}/live/strompreis_ct für Standalone-Docker-Nutzer

Feature — Stündliche Strompreis-Mitschrift im Energieprofil (Vorbereitung)

Zwei getrennte Preisfelder im TagesEnergieProfil: strompreis_cent (Endpreis aus HA-Sensor) + boersenpreis_cent (EPEX, immer befüllt)
Tagesaggregation: Börsenpreis Ø/Min, Anzahl negativer Preis-Stunden, Einspeisung bei negativem Börsenpreis (§51 EEG Vorbereitung)
Datensammlung als Grundlage für mögliche spätere Features (Monatsvorschlag, Negativpreis-Analyse)

Fix — Strompreis-Overlay las falsches Feld

Tagesverlauf suchte entity_id statt sensor_id im Sensor-Mapping → Overlay konnte nicht funktionieren

[3.15.8] - 2026-04-17

Feature — Tagesverlauf: Einspeisung + Strompreis-Overlay (Rainer-Feedback)

Einspeisung als eigene Serie: Netz-Serie aufgeteilt in Netzbezug (rot, oben) und Einspeisung (cyan, unten) mit eigenem Legendeneintrag
Strompreis-Overlay: Sekundäre Y-Achse (ct/kWh) mit Step-Linie — zeigt EPEX/Tibber-Preis im Tagesverlauf, wenn ein Strompreis-Sensor im Sensor-Mapping konfiguriert ist
Einheiten-Normalisierung: EUR/kWh-Sensoren werden automatisch in ct/kWh konvertiert
Beide Pfade (HA + MQTT) angepasst

Fix — Lernfaktor robuster bei Wetterwechseln (Rainer-Feedback)

Produktionsgewichtet: Σ(IST) / Σ(Prognose) statt Median der Tages-Ratios — sonnige Tage dominieren automatisch, bewölkte Phasen verzerren den Faktor nicht mehr nach unten

Fix — Backfill: Stillgelegte Investitionen zeitraumgerecht (MartyBr)

Backfill nutzte aktiv_jetzt() statt aktiv_im_zeitraum() — stillgelegte Investitionen wurden komplett ignoriert, auch für historische Tage VOR dem Stilllegungsdatum
Jetzt: Pro Tag wird geprüft ob die Investition an dem konkreten Tag aktiv war

Verbesserung — PDF-Farbstreifen einheitlich

Finanzbericht: Streifen von 6mm auf 1.5mm (wie Anlagendokumentation)
Jahresbericht + Infothek: Farbstreifen über base.html + styles.css ergänzt
Alle 4 Berichte haben jetzt den gleichen subtilen 1.5mm-Streifen

[3.15.7] - 2026-04-17

Fix — Stillgelegte Komponenten in Gesamt-kWp (MartyBr Forum #308)

Cockpit kWp-Summe: Stillgelegte/deaktivierte PV-Module und BKW werden nicht mehr zur Gesamtleistung addiert
Komponenten-Flags: Speicher, Wärmepumpe, E-Mobilität und BKW-Sektionen respektieren jetzt Stilllegungsdatum
Sensor-Mapping gesamt_kwp: Nur noch aktive Module in der kWp-Summe

Tooltip: Verbrauchskategorien (Wallbox, WP, Sonstige) werden nur angezeigt, wenn entsprechende Investitionen existieren
Legende: Verbrauchs-Kategorien als gefüllte Rechtecke statt Linien-Symbole (passend zur Flächendarstellung)

[3.15.6] - 2026-04-17

Verbesserung — PDF-Anlagenbericht nach Rainer-Feedback

EEDC-Vermerk entfernt: Titelseite zeigt nur noch “Stand DD.MM.YYYY” statt redundantem EEDC-Branding
Kompaktere Komponenten: Zeilenabstand in Komponenten-Blöcken reduziert
Hinweis-Box entfernt: “Keine Komponenten-Akte verknüpft” (Beta-Phase vorbei)
Logo-Fallback: EEDC-Logo wird angezeigt wenn kein eigenes Anlagenfoto hochgeladen ist
PV-Komponenten dedupliziert: Bei n:m-Verknüpfung wird jede Komponente nur einmal angezeigt, mit “Gilt für”-Hinweis (z.B. “alle Modulfelder” oder “Süddach”)
Farbstreifen subtiler: Durchgehend dünne 1.5mm-Linie statt dominantem 6mm-Streifen
Logo einzeilig: “ENERGIE EFFIZIENZ DATA CENTER” auf einer Zeile (SVG + PNG aktualisiert)
Duplicate Macro entfernt: komponente_block war im Template doppelt definiert

[3.15.5] - 2026-04-16

Fix — PDF-Download Mobile 401 Unauthorized

PDF-Download auf Mobile (HA Companion App): target="_blank" Links verloren den Ingress-Auth-Token → 401 Unauthorized. PDFs werden jetzt per fetch() im aktuellen Auth-Kontext geladen und als Blob-Download angeboten. Spinner während der PDF-Generierung.

[3.15.4] - 2026-04-16

Fix — Anlagendokumentation PDF + Foto-Upload

PDF Jinja-Fehler behoben: TemplateSyntaxError bei Anlagendokumentation — elif-Block stand nach else im Template (ungültig in Jinja). Reihenfolge korrigiert.
Anlagenfoto verschwindet nach Upload: HEAD-Request feuerte nach jedem Upload erneut und setzte das Foto bei Timing-Problemen zurück. Check läuft jetzt nur noch beim Öffnen des Dialogs.

[3.15.3] - 2026-04-16

Perf — N+1 Queries, Code-Splitting, Konstanten-Bereinigung

Backend: N+1 Queries eliminiert: 6 Dashboard-Endpoints (investitionen.py) von Loop-Queries auf Batch-Queries (WHERE investition_id IN) umgestellt. E-Auto, Wärmepumpe, Speicher, Wallbox (3 Schleifen → 1 Query), BKW und Monatsdaten-by-Month.
Backend: aktueller_monat.py: 5 sequentielle InvestitionMonatsdaten-Queries (Speicher/WP/EMob/BKW/Sonstiges) zu einer Batch-Query zusammengefasst.
Backend: aussichten.py: Shared Helper _lade_anlage_mit_pv() extrahiert — 3 Forecast-Endpoints sparen je 3 duplizierte Queries (Anlage + PV + BKW → 1 kombinierte Query).
Frontend: React.lazy Code-Splitting: 33 Seiten als Lazy-Imports, nur LiveDashboard (Startseite) bleibt eager. Vite erzeugt separate Chunks pro Route — Initial-Bundle deutlich kleiner.
Frontend: Community-Benchmark zentralisiert: getBenchmark() wird einmal im Parent geladen und als Props an alle 6 Tabs weitergereicht. Kein Re-Fetch bei Tab-Wechsel.
Frontend: Duplizierte Konstanten bereinigt: REGION_NAMEN (4×), MONAT_NAMEN/MONAT_KURZ (4×) zentralisiert in lib/constants.ts.

Fix

Daten-Checker: Dienstwagen ausgenommen: E-Autos mit ist_dienstlich-Flag werden im Daten-Checker komplett übersprungen — keine PV-Ladungs-, Alternativkosten- oder Anschaffungskosten-Checks mehr.

[3.15.2] - 2026-04-16

Feat — Infothek N:M Verknüpfung + Komponenten-Akte am Investment (#121)

Mehrfachverknüpfung Infothek ↔ Investitionen (N:M): Ein Datenblatt (z.B. „Trina Vertex S 430Wp”) kann jetzt mit mehreren Investments gleichzeitig verknüpft werden — statt für 6 PV-Strings 6 identische Einträge zu pflegen. Neue Junction Table infothek_investition, bestehende 1:1-Verknüpfungen werden automatisch migriert. Im Formular ersetzt eine Checkbox-Liste das bisherige Single-Select-Dropdown. API bleibt rückwärtskompatibel (investition_id weiterhin akzeptiert).
Komponenten-Akte direkt am Investment: Kontextabhängiger Button in der Investitions-Übersicht: „Komponenten-Akte anlegen” (0 Einträge), „Komponenten-Akte öffnen” (1 Eintrag), Dropdown-Liste mit Direktlinks (N Einträge) + „Weitere verknüpfen”. Quick-Create öffnet ein Modal mit vorausgefüllter Kategorie und Verknüpfung.
„In Anlagendokumentation anzeigen” Flag: Neues Häkchen pro Infothek-Eintrag (Default: an). Steuert, ob der Eintrag in der Anlagendokumentation (PDF) erscheint. Das Infothek-Dossier zeigt weiterhin immer alles, Jahres- und Finanzbericht sind nicht betroffen.
Infrastruktur-Abschnitt in Anlagendokumentation: Infothek-Einträge der Kategorie „Komponente / Datenblatt” ohne Investment-Verknüpfung (z.B. Zähler, Zählerschränke, Verkabelung) bekommen eine eigene Seite im PDF.

Fix

Wallbox-Dashboard: Ladevorgänge immer 0: Sensor-Mapping speichert ladevorgaenge in den Wallbox-Monatsdaten, aber das Dashboard las nur E-Auto-Monatsdaten. Fix: beide Quellen aggregieren (Wallbox primär, E-Auto als Fallback für manuelle Altdaten).
Infothek Datei-Label: Zeigte „max. 3”, tatsächliches Limit ist 15. Dateigröße (bis 10 MB) ergänzt.
Stromzähler-Placeholder erweitert: Strom-Zähler-Bezeichnung zeigt jetzt Beispiele für WP-Strom, Wallbox, Haushalt als Placeholder-Text.

[3.15.1] - 2026-04-16

Feat — Auto-Vollbackfill aus HA Long-Term Statistics

Erster Monatsabschluss nach Upgrade befüllt automatisch die komplette HA-History ins Energieprofil. Bisher wurde nur der Monat des jeweiligen Monatsabschlusses per backfill_range aufgefüllt — die HA Long-Term Statistics (Jahre zurück) wurden nicht angetastet. Wer auf v3.1.x+ upgegradet hatte, blieb folglich ohne Energieprofil-Historie aus der Zeit vor dem Upgrade. Bisher gab es nur den manuellen „Vollständig nachberechnen”-Button im Sensor-Mapping-Wizard (v3.12.1) — wer den nicht aktiv geklickt hat, hatte schlicht nichts. Mit v3.16.0 läuft der Vollbackfill jetzt einmalig pro Anlage automatisch im Hintergrund mit, sobald der erste Monatsabschluss nach dem Upgrade gespeichert wird (manuell ODER per Scheduler — beide Pfade durchlaufen _post_save_hintergrund).
Neues Anlage-Feld vollbackfill_durchgefuehrt: Wird gesetzt, sobald entweder der manuelle Wizard-Button oder der Auto-Lauf durch ist (Erfolg oder Fehler). Damit greift der Auto-Vollbackfill garantiert nur einmal pro Anlage und führt auch bei defekter HA-DB nicht zu Endlos-Retries. Beim Löschen der Energieprofil-Rohdaten (Single-Anlage und Bulk-Endpoint) wird das Flag zurückgesetzt → der nächste Monatsabschluss zieht die History erneut nach. Das Feld ist server-intern, nicht über die Anlage-API editierbar.
Bestandsdaten-Heuristik in der DB-Migration: Anlagen mit mehr als 30 Tagen Energieprofil-Historie werden bei der Migration auf v3.16.0 direkt mit vollbackfill_durchgefuehrt = True markiert. So bekommt z.B. Rainer (578 Tage) keinen überraschenden Multi-Jahres-Backfill beim ersten Scheduler-Lauf — wer das explizit will, kann den Wizard-Button weiter manuell anstoßen.
Verhalten in Edge-Cases: HA Statistics nicht verfügbar → Flag wird trotzdem gesetzt, kein Retry. Keine validen Sensoren konfiguriert → Flag wird trotzdem gesetzt. Frische Installation ohne Profile-Daten → Flag bleibt False, erster Monatsabschluss zieht die komplette History. Wizard-Vollbackfill bereits gelaufen → Flag ist True, kein erneuter Auto-Lauf.

Fix

Infothek-Kategorie „Garantie” → „Komponente / Datenblatt”: Das Label in der Infothek-UI stimmte nicht mit dem Verweis in der Anlagendokumentation überein. Nutzer, die dem Hinweis „Kategorie Komponente / Datenblatt” folgten, fanden die Kategorie nicht, weil sie im Frontend noch „Garantie” hieß. Auslöser: Rainer.

Maintenance

Neue gemeinsame Helper-Funktion resolve_and_backfill_from_statistics() in backend/services/energie_profil_service.py mit BackfillResult-Dataclass. Vereint die zuvor ~50 Zeilen duplizierte Orchestrierungs-Logik (Sensor-Discovery, ungültige Sensoren filtern, frühestes Datum aus HA Statistics ermitteln, Backfill auslösen) zwischen dem manuellen Vollbackfill-Endpoint und dem neuen Auto-Vollbackfill im Background-Task. Beide Call-Sites mappen den BackfillResult.status (“ok”/“ha_unavailable”/“no_sensors”/“no_valid_sensors”/“earliest_unknown”/“empty_range”) auf ihre eigene Fehlerbehandlung (HTTPException vs. Log-Warnung).
_post_save_hintergrund lädt die Anlage jetzt nur noch einmal (vorher: separate Sessions für Rollup und Auto-Vollbackfill, zwei SELECTs auf jedem Save). Closing-Month-Backfill, Rollup und Auto-Vollbackfill teilen sich dieselbe DB-Session.
Konstante VOLLBACKFILL_BESTAND_SCHWELLE_TAGE = 30 in backend/core/database.py.

[3.15.0] - 2026-04-15

Feat — Anlagendokumentation & Finanzbericht (Issue #121 Phase 4, Beta)

Neuer zentraler „Dokumente”-Dialog pro Anlage: Der bisherige Einzel-Button auf der Anlagen-Seite wird abgelöst durch einen Dokumente-Button (orangefarbenes Ordner-Icon), der einen Download-Hub mit allen verfügbaren PDF-Dokumenten öffnet. Aktuell vier Karten: Jahresbericht, Infothek-Dossier, Anlagendokumentation (Beta) und Finanzbericht (Beta). Die beiden neuen Dokumente sind mit einem amber-farbenen „Beta”-Badge gekennzeichnet und verlinken direkt auf Issue #121 für Feedback.
Anlagendokumentation (Beta) — neues PDF im V4-Layout mit Urkunden-Charakter: Titelseite mit Anlagenfoto, gesperrter Headline, großem Anlagennamen, Meta-Zeile (Leistung / Inbetriebnahme / MaStR) und Komponenten-Übersicht. Folgeseiten mit Hybrid-Gruppierung: alle PV-Modulfelder werden gesammelt auf einer Seite gerendert, alle anderen Investitionstypen (Wechselrichter, Speicher, Wärmepumpe, Wallbox, E-Fahrzeug, Balkonkraftwerk, Sonstiges) bekommen eine eigene Folgeseite. Unter der Technik jeder Investition wird der Komponenten-Akte-Block aus verknüpften Infothek-Einträgen der Kategorie „Komponente / Datenblatt” gerendert — mit allen gepflegten Feldern (Hersteller, Seriennummer, Garantie, Prüftermine, Datenblatt-URL), mehrzeiligen Freitext-Blöcken (Technische Daten, Garantie-Bedingungen, Sonstige Verträge) und der Liste angehängter Dateien inkl. Beschreibung. Ist keine Komponenten-Akte verknüpft, zeigt die Seite eine freundliche Hinweis-Box mit dem Pflege-Pfad. Keine Geldbeträge — die Anlagendokumentation ist bewusst für Versicherung, Nachlass und Archiv konzipiert und kann ohne Finanzbedenken weitergegeben werden.
Finanzbericht (Beta) — neues PDF mit allen monetären Kennzahlen zur Anlage: Investitions-Tabelle mit Bezeichnung, Kategorie, Inbetriebnahme, Kosten, Alternativ-Kosten und Jahres-Ersparnis je Investition; Summenzeile; KPI-Block mit Amortisations-Prognose, Differenz zum Alt-Szenario und Netto-Kosten nach Förderung; gruppierte Sektionen Förderungen, Versicherung und Steuerdaten aus den jeweiligen Infothek-Kategorien (foerderung, versicherung, steuerdaten) mit allen Einzel-Einträgen. Abgeschlossen mit einem Vertraulichkeits-Hinweis.
Anlagenfoto am Anlage-Modell: Neuer Upload-Bereich in der Anlage-Stammdaten-Form — Drag & Drop oder Klick, Vorschau als 128 × 128-Thumbnail, Ersetzen und Entfernen. Die bestehende Bildpipeline aus der Infothek wird wiederverwendet (EXIF-Rotation, HEIC→JPEG, Resize auf ~500 kB, 200 × 200-Thumbnail). Gespeichert wird in einer neuen Tabelle anlage_foto (1:1 zu anlagen, Cascade-Delete). Ein Foto pro Anlage — ein neues Foto überschreibt das alte. Genutzt wird es auf der Titelseite der Anlagendokumentation; ohne Foto bleibt die Titelseite aufgeräumt ohne Platzhalter.
Neue API-Routen unter /api/anlagen/{id}/foto (POST/GET/GET/thumb/DELETE) und unter /api/dokumentation/anlagendokumentation/{id} sowie /api/dokumentation/finanzbericht/{id}. Die beiden Dokumentations-Routen sind WeasyPrint-only — bei PDF_ENGINE=reportlab liefern sie HTTP 503 mit klarem Hinweistext („Im HA-Add-on in der Konfiguration umschaltbar, im Standalone-Docker via Umgebungsvariable”). Begründung: Das V4-Layout (mehrseitige Komponenten-Blöcke, seitenübergreifende 3-Farben-Leiste, CSS-Gradients, position: fixed) ist auf WeasyPrint + Pango/Cairo ausgelegt und im reportlab-Builder nicht realistisch abbildbar.

Beta-Hinweis & Feedback-Einladung

Die beiden neuen Dokumente sind bewusst als Beta markiert und werden über Issue #121 iteriert. Die Grundstruktur ist freigegeben (V4-Layout von rapahl approved, Hybrid-Gruppierung und B1-Datenquelle abgestimmt), aber Feld-Auswahl und Layout-Details werden nach Community-Praxis-Tests verfeinert. Feedback bitte konkret: „X fehlt, weil Y beim Ausfüllen/Drucken nicht passt”. Das Fundament (Komponentenakte) aus v3.14.0 bleibt stabil, strukturelle Änderungen sind damit zukünftig reine Builder-/Template-Anpassungen — keine Datenmodell-Brüche.

Maintenance

Neuer PDF-Builder-Modul: backend/services/pdf/builders/anlagendokumentation.py und backend/services/pdf/builders/finanzbericht.py, Templates analog unter backend/services/pdf/templates/.
Seitenübergreifende 3-Farben-Leiste via position: fixed (WeasyPrint repliziert fixed-Elemente auf jeder physischen Seite) und @page { margin: 22mm 22mm 22mm 38mm } — damit starten auch automatisch umgebrochene Überlauf-Seiten auf Höhe des Streifen-Oberrands statt am Papier-Rand.
Neue Frontend-Komponenten: AnlagenfotoSection.tsx, DokumentationsDialog.tsx. Bestehender ApiClient.upload() um optionalen extraFields-Parameter erweitert (wurde für die Datei-Beschreibungen in v3.14.0 bereits vorbereitet).

[3.14.0] - 2026-04-15

Fix

Historische Aggregate blenden deaktivierte Investitionen nicht mehr aus (#123): Bis jetzt haben ~32 Call-Sites im Backend (Monatsdaten-Aggregation, Cockpit-KPIs, PDF-Jahresbericht, Nachhaltigkeit, Social-Text, PV-Strings-Vergleich, Export-Routen) Investitionen strikt mit aktiv == True gefiltert. Folge: Sobald ein Nutzer eine Komponente deaktiviert hat (z.B. nach WR-Upgrade oder Verkauf), sind ihre historischen Werte rückwirkend und stillschweigend aus allen Auswertungen verschwunden — Rohdaten in InvestitionMonatsdaten blieben zwar erhalten, wurden aber nicht mehr summiert. Aufgefallen ist das bei MartyBr (community.simon42.com #297), der seinen zweiten WR in Betrieb genommen hat. Fix in zwei Richtungen: (1) Alle historischen Auswertungen laden Investitionen jetzt ohne aktiv-Filter, sodass vergangene Werte erhalten bleiben. (2) Neues optionales Feld Stilllegungsdatum auf jeder Investition als finaler Endmarker — bis dahin zählt die Komponente für Historie und Live/Prognose, danach nur noch für Historie. Live-/Prognose-Queries (Solar-Forecast, Live-Dashboard, Sensor-Mapping, MQTT-Routing, PVGIS-Refresh) respektieren das neue Feld zusätzlich zum bestehenden aktiv-Flag. Empfehlung für Gerätewechsel: neue Investition anlegen (Anschaffungsdatum = Umbautag) + Stilllegungsdatum auf alter Investition setzen (nicht mehr deaktivieren).

Feat

Infothek-Komponentenakte — Garantie-Kategorie zum vollwertigen Datenblatt ausgebaut (#121): Erste testbare Beta der Komponentenakte für die kommende Anlagendokumentation (Phase 4). Die bestehende Kategorie garantie wird als „Komponente / Datenblatt” umgelabelt und um acht Felder erweitert: Seriennummer, Einbau-Datum, Installations-Firma, Letzte/Nächste Prüfung, Link zum Hersteller-Datenblatt sowie zwei mehrzeilige Freitextfelder „Technische Daten” (typ-spezifisch — von Kabelquerschnitt bis COP) und „Sonstige zugehörige Verträge / Dokumente”. Der interne Key bleibt garantie, bestehende Einträge sind unverändert gültig, keine DB-Migration nötig. Neuer Feld-Typ text wird im Formular-Renderer als <textarea> dargestellt. Datei-Upload: Limit von 3 auf 15 Dateien pro Eintrag erhöht, PDF-Größe von 5 auf 10 MB. Pro Datei kann jetzt eine optionale Beschreibung mitgegeben werden (Staging-Queue im Upload-Widget, Beschreibung später unter dem Thumbnail sichtbar). Damit ist das Fundament gelegt, auf dem der Anlagendokumentations-Builder verknüpfte Komponenten-Daten je Investition rendern wird. Feedback aus der Praxis wird über Issue #121 gesammelt — bitte testen und fehlende/überflüssige Felder melden.
Stilllegungsdatum in der Investitions-Form: Neuer DatePicker unter dem Anschaffungsdatum in allen Investitions-Typen (E-Auto, WP, Speicher, Wallbox, WR, PV-Module, Balkonkraftwerk, Sonstiges). Validierung: nicht vor dem Anschaffungsdatum. In der Investitions-Übersicht zeigt ein neuer amber-farbener Stillgelegt-Badge den Zustand an (mit Tooltip Stillgelegt seit YYYY-MM-DD).
MonatsdatenForm-Editor zeigt historisch aktive Komponenten: Beim Bearbeiten eines Monats sieht man jetzt alle Investitionen, die in diesem Monat (mindestens teilweise) in Betrieb waren — auch inzwischen stillgelegte. Vorher waren die für historische Nachträge unsichtbar.

Maintenance

Neues Helper-Modul backend/utils/investition_filter.py mit wiederverwendbaren Filter-Funktionen aktiv_jetzt(), aktiv_im_zeitraum(), aktiv_im_monat(), aktiv_im_jahr() und Model-Methoden Investition.ist_aktiv_an(), ist_aktiv_im_zeitraum(), ist_aktiv_im_monat() für In-Memory-Checks in Aggregations-Loops.
aussichten.py-Langfristbericht: historische Aggregation vs. Prognose-Basis sauber getrennt — Prognose-kWp kommt nur aus aktuell aktiven PV-Modulen, historische Werte aus allen je vorhandenen.
JSON-Backup-Export/Import persistiert Stilllegungsdatum.
DB-Migration investitionen.stilllegungsdatum DATE (SQLite + MariaDB/MySQL), rückwärtskompatibel — bestehende Installationen behalten ihr Verhalten, solange kein Datum gesetzt ist.

Bekannter Folgepunkt

ROI-Dashboard zeitanteilige Gewichtung: Der eigentliche Bug (stillschweigend falsche historische Zahlen) ist in v3.14.0 behoben. Offene Verfeinerung: Das ROI-Modell geht aktuell von “Investition läuft das ganze Jahr” aus — bei mitten im Jahr stillgelegten Komponenten wäre eine zeitanteilige Gewichtung sauberer. Nicht dringend; wird in einem späteren Release angegangen.

[3.13.5] - 2026-04-15

Fix

Solarprognose PVGIS: Y-Achsen-Clipping + Multi-String-Anzeige: Im PVGIS-Prognose-Chart wurde bei Anlagen mit mehreren Strings der höchste Wert oben am Rand abgeschnitten; zusätzlich fehlte die String-übergreifende Summendarstellung in einigen Ansichten. Y-Achse bekommt jetzt automatischen Headroom, Multi-String-Summe wird konsistent dargestellt.

Maintenance

type="button" auf zwei Icon-Buttons im PVGIS-Dialog ergänzt (verhindert unbeabsichtigtes Form-Submit).

[3.13.4] - 2026-04-14

Vorbereitung

PDF-Engine als HA-Add-on-Option (#121): v3.13.3 hatte die neue WeasyPrint-Engine zwar im Hintergrund installiert, aber nur über die Umgebungsvariable PDF_ENGINE=weasyprint aktivierbar — was im HA-Add-on-Kontext gar nicht möglich war. v3.13.4 ergänzt eine Add-on-Option pdf_engine (Default reportlab), die in der HA-UI direkt umgeschaltet werden kann. Standalone-Docker-User können die ENV-Variable wie bisher in docker-compose.yml setzen — keine Verhaltensänderung. Default bleibt reportlab, am sichtbaren Verhalten ändert sich für niemanden etwas.

[3.13.3] - 2026-04-14

Vorbereitung

PDF-Pipeline-Umstellung (Issue #121) — Substrat-Release: Die neue PDF-Engine (WeasyPrint + Jinja2 + Matplotlib) wird im Hintergrund installiert und ist über die Umgebungsvariable PDF_ENGINE=weasyprint opt-in testbar. Default bleibt reportlab, am sichtbaren Verhalten ändert sich für niemanden etwas. Drin sind die neuen Builder für Jahresbericht und Infothek-Dossier mit einheitlichem Corporate-Design, Matplotlib-Charts (PV-Erzeugung, Energiefluss, Autarkie) und Markdown-Notizen-Rendering. Der bisherige reportlab-Pfad bleibt vollständig erhalten und wird unverändert genutzt. Anlagendokumentation, Finanzbericht und der Dokumenten-Dialog im Frontend folgen in einem späteren Beta-Release, sobald das Layout (V4 — siehe #121) und die Verknüpfung Investition↔Infothek-Eintrag ausreichend mit der Community abgestimmt sind. Native Libs (libpango, fontconfig, fonts-dejavu-core) sind im Dockerfile ergänzt — der HA-Add-on-Build vergrößert sich um wenige MB.

[3.13.2] - 2026-04-13

Fix

MQTT-Export: Icons wurden als Text angezeigt: Im HA-Export-Tab stand bei jedem Sensor der MDI-Name als Text (mdi:solar-power, mdi:lightning-bolt …) statt eines echten Icons. Frontend rendert jetzt die tatsächlichen Material-Design-Icons über @mdi/react + @mdi/js — identisch zur Darstellung in Home Assistant. Auslöser: Rainer.

[3.13.1] - 2026-04-13

Fix

Energieprofil Monat: Zukunftsmonate auch in Selects sperren: Bis jetzt war nur der ▶-Button für Zukunftsmonate deaktiviert, über die Monats-/Jahres-Dropdowns ließen sich trotzdem Monate in der Zukunft (z.B. Juni 2026 am 13.04.2026) auswählen — mit leerer Anzeige als Folge. Im Monats-Select sind Zukunftsmonate jetzt disabled, das Jahres-Select listet nur bis zum aktuellen Jahr, und wer beim Jahreswechsel in einem Zukunftsmonat landet, wird automatisch auf den letzten erlaubten Monat geklemmt. Lücken in der Vergangenheit bleiben sichtbar — die sind Absicht, damit man fehlende Daten überhaupt findet.

[3.13.0] - 2026-04-13

Feat

Energieprofil Etappe 3: Monatsauswertung: Neuer Sub-Tab “Monat” in Auswertung → Energieprofil mit vollständiger monatlicher Analyse der persistierten Stundenwerte.
- Heatmap 24h × N Tage mit umschaltbarer Metrik (PV / Verbrauch / Netzbezug / Einspeisung / Überschuss-divergent), Hover-Tooltip pro Zelle und Skalen-Legende.
- Monats-KPIs (1. Reihe): PV-Erzeugung, Verbrauch, Einspeisung, Netzbezug, Autarkie, Eigenverbrauch, Performance-Ratio Ø, Batterie-Vollzyklen-Summe.
- Analyse-KPIs (2. Reihe): Grundbedarf (Nacht-Ø 0–5 Uhr), Direkt-Eigenverbrauch (PV → Senke ohne Batterie-Umweg), Batterie geladen/entladen/η, PV Best-/Ø-/Schlecht-Tag.
- Kategorien-Leiste: Erzeugung und Verbrauch nach Gruppen — PV-Module, Balkonkraftwerk, Sonstige Erzeuger, Wärmepumpe, Wallbox/E-Auto, Haushalt, Sonstige Verbraucher — mit kWh + Anteil am jeweiligen Gesamt.
- Geräte-Tabelle: Eine Zeile pro Investition (Süddach, Ostdach, WP, Wallbox …) mit Monats-kWh und prozentualem Anteil.
- Typisches Tagesprofil: 24h-Linien-Chart (Ø PV + Ø Verbrauch über den Monat) als Basis für spätere Verbrauchsprognose (Etappe 3b).
- Peak-Tabellen: Top-10 Netzbezug- und Einspeise-Stunden für Tarif-Optimierung und Batterie-Timing.
- Monats-Picker mit Vorher/Nachher-Buttons, Sperre für Zukunftsmonate, Anzeige “X von Y Tagen mit Daten”.
Backend: Neuer Endpoint GET /api/energie-profil/{anlage_id}/monat?jahr=&monat=&top_n= aggregiert TagesEnergieProfil (stündlich) + TagesZusammenfassung (Tages-Rollup inkl. komponenten_kwh) zu einer einzigen kompakten Response — Frontend lädt die komplette Monatsansicht in einem Request.

[3.12.7] - 2026-04-13

Fix

Monatsbericht weicht von Auswertung→Tabelle ab (#118): Für vergangene Monate hat der Monatsbericht-Endpunkt die in Monatsdaten/InvestitionMonatsdaten gespeicherten Werte stillschweigend mit Live-Werten aus der HA Long-Term Statistics-DB überschrieben (höhere Konfidenz). Wenn HA-Sensoren später umbenannt wurden oder die Recorder-DB für vergangene Monate driftete, zeigte der Monatsbericht andere Zahlen als die Auswertungs-Tabelle — selbst nach abgeschlossenem Monat. Fix: HA-Stats werden für vergangene Monate nur noch als Fallback verwendet (setdefault), nicht mehr als Override. Aktueller Monat bleibt unverändert. Auslöser: Safi105.

[3.12.6] - 2026-04-13

Fix

T-Konto Mobile als Gewinn-und-Verlust-Rechnung (#117): Auf Mobile wird das T-Konto zur G+V umgebaut. SOLL/HABEN-Überschriften entfallen (passen ohne nebeneinanderliegende Konten nicht mehr), die Ergebniszeile wandert aus beiden Blöcken in eine eigene “Gewinn”/“Verlust”-Zeile darunter, und die Summen zeigen jetzt die tatsächlichen Kosten- bzw. Ertragsbeträge statt der um den Gewinn korrigierten T-Konto-Ausgleichssummen. Desktop bleibt unverändert. Auslöser: TomHarm.

Feat

WetterWidget Chart-Toggle PV/Verbrauch/Beides (#119): Drei Buttons rechts neben der Chart-Überschrift im “Wetter heute”-Diagramm — “Nur PV / Nur Verbrauch / Beides”, Auswahl pro Anlage in localStorage. Default bleibt “Beides”, die reduzierten Sichten blenden Stack/Legende entsprechend ein und aus. Auslöser: felixlen.
Monatsberichte: Individuelle Sektions-Reihenfolge: Jede Sektion (Energie-Bilanz, Finanzen, Community, Speicher, WP, eMob, BKW, Sonstiges) hat im Header zwei kleine Pfeile zum Verschieben nach oben/unten. Reihenfolge wird in localStorage gespeichert.
Speicher: Wirkungsverluste in Euro: Neue Zeile unter der kWh-Bilanz zeigt die Opportunitätskosten des Roundtrip-Verlusts — anteilig nach Lade-Quelle: PV-Anteil × Einspeisepreis (entgangener Erlös) + Netz-Anteil × Bezugspreis. Tooltip erklärt die Aufschlüsselung. Rein informativ, nicht Teil der T-Konto-Bilanz.

[3.12.5] - 2026-04-12

Fix

Vollbackfill NameError: timedelta fehlte als Import in get_hourly_sensor_data → “Verlauf nachberechnen” schlug mit NameError: name 'timedelta' is not defined fehl.

[3.12.4] - 2026-04-12

Fix

Vollbackfill Fehlerdiagnose: Interne Fehler beim “Verlauf nachberechnen” werden jetzt als lesbare Fehlermeldung zurückgegeben statt als stiller 500er.

[3.12.3] - 2026-04-12

Fix

Vollbackfill 500-Fehler: Fehlende DB-Migration für Spalte komponenten in tages_energie_profil führte zu einem internen Serverfehler beim Ausführen von “Verlauf nachberechnen”. Migration wird jetzt beim Add-on-Start automatisch ergänzt.

[3.12.2] - 2026-04-12

Feat

Post-Save-Dialog im Sensor-Mapping-Wizard: Nach dem Speichern geänderter Sensor-Zuordnungen erscheint ein kontextueller Dialog. Bei geänderten Live-Sensoren kann der Energieprofil-Verlauf direkt neu berechnet werden. Bei geänderten Felder-Sensoren wird zum HA Statistik-Import (mit Überschreiben) navigiert.

Fix

Community: 0-Wert-Einlieferungen (#107): Anlagen mit kaputtem Sensor-Mapping die ertrag_kwh=0 einlieferten, verfälschten den Community-Durchschnitt. Fix: EEDC sendet keine Monate ohne PV-Erzeugung mehr. Community-Server lehnt ertrag_kwh≤0 mit HTTP 400 ab.
Energieprofil-Backfill mit veralteten Sensoren: Wenn im Live-Sensor-Mapping noch alte/umbenannte HA-Sensoren steckten (z.B. nach Sensor-Austausch im Wizard), scheiterte “Verlauf nachberechnen” mit einem Fehler. Veraltete Sensoren werden jetzt automatisch ignoriert.
Sensor-Mapping-Wizard: Beim Speichern werden Live-Sensoren die in HA nicht mehr existieren automatisch aus dem Mapping entfernt.

[3.12.1] - 2026-04-12

Feat

Energieprofil-Vollbackfill: Neuer Button “Verlauf nachberechnen” im Sensor-Mapping-Wizard (letzter Schritt). Berechnet stündliche Energieprofile rückwirkend aus HA Long-Term Statistics — unabhängig von der ~10-Tage-Grenze der Sensor-History. Ermöglicht erstmals die Befüllung der gesamten HA-History auf einen Schlag.

Fix

WetterWidget KPI-Aufräumung (#100): ML/SFML-Tages- und Morgenprognose aus der KPI-Zeile entfernt. PV-Prognose (EEDC GTI) wird jetzt immer angezeigt. ML-Linie bleibt im Chart und in der Legende sichtbar.
Monatsberichte Scroll-Bug: Zeitstrahl-Scrollen beeinflusste fälschlicherweise den Haupt-Viewport — sticky sitzt jetzt korrekt am äußeren Container.
Monatsberichte Sektions-Zustand: Auf-/Zugeklappt-Zustand aller Sektionen (Energie-Bilanz, Finanzen, Community etc.) wird jetzt per localStorage gespeichert — Finanzen öffnet nicht mehr immer aufgeklappt.

Chore

Investitionsformular: Deprecation-Banner für Ansprechpartner- und Wartungsfelder — diese werden in einer der nächsten Versionen entfernt und durch die Infothek ersetzt. Bereits eingetragene Daten bleiben erhalten.

[3.12.0] - 2026-04-11

Feat

Monatsberichte ersetzt “Aktueller Monat”: Laufender Monat erscheint jetzt direkt im Zeitstrahl (grüner Pulse-Dot). Route /cockpit/aktueller-monat redirectet auf Monatsberichte. Refresh-Button und “Abschluss starten”-CTA (nur wenn Vergangenheitsmonate offen) im Titelbereich.
Energie-Bilanz Redesign: Vergleichstabelle mit neuem “Ø [Monatsname]“-Vergleich (z.B. alle März-Monate) statt sinnlosen Gesamt-Ø/Max/Min. SOLL/IST-Block mit großer Prozentanzeige, Fortschrittsbalken und Ampelfarben. PV-Verteilung als kompakte Horizontal-Balken statt großem Donut-Chart.
Community-Vergleich: Neue Sektion zeigt Autarkie, EV-Quote, Einspeisung und Netzbezug gegen den Community-Median des gewählten Monats (▲/▼). Prominente Teilen-Aufforderung wenn Anlage noch nicht geteilt.
Mobile T-Konto: SOLL und HABEN werden auf kleinen Screens untereinander dargestellt.
Mobile Vergleichstabelle: Zahlenwerte ausgeblendet, nur Δ-Badge mit Tooltip sichtbar.

[3.11.19] - 2026-04-10

Fix

Fronius Custom Report — Zwei Wechselrichter: Alle "Energie | [WR-Modell]"-Spalten werden jetzt summiert (statt nur die erste). Betrifft Anlagen mit mehreren Wechselrichtern (z.B. Symo 4.5 + GEN24 10.0). Auslöser: Joachim-xo.
Fronius Custom Report — Wattpilot-Ladedaten: "Energie vom Netz/Batterie/PV an Wattpilot" wird zu wallbox_ladung_kwh aggregiert und der konfigurierten Wallbox-Investition zugeordnet (bei mehreren Wallboxen: manuelle Auswahl im Import-Dialog).
Portal-Import — Dezimaleingabe Prozent-Anteile: Tipp eines Kommas oder Punkts sprang den Wert auf 0. Fix: valueAsNumber statt parseFloat, step={0.01} statt 0.1 für 2-stellige Nachkommastellen.

[3.11.18] - 2026-04-09

Fix

Fronius Custom Report — PV-Spalte 0,00 kWh: "Energie | [Gerätemodell]" wurde von _normalize() zu "energie [modell]" (Pipe entfernt) — Pattern "energie |" traf nie. Stattdessen griff "ertrag" auf "Spezifischer Ertrag [kWh/kWp]" → Werte ~0,38 als Wh ÷ 1000 = 0,00 kWh. Fix: Raw-Header-Suche auf startswith("energie |"), "ertrag" aus Patterns entfernt. Verifiziert mit echter CSV von Joachim-xo (365 Tage, 14 Spalten).

[3.11.17] - 2026-04-09

Fix

Fronius Solar.web Benutzerdefinierter Report: PV-Spalte korrekt erkannt: Spaltenbezeichnung "Energie | [Gerätemodell]" (Pipe-Zeichen + Inverter-Name) wurde nicht als PV-Erzeugung erkannt — Parser griff fälschlich auf "Spezifischer Ertrag" (kWh/kWp) zurück. Auslöser: Joachim-xo.

Feat

Aktueller Monat — Wärmepumpe Heizung/Warmwasser-Split: Label umbenannt in “Wärmepumpe Summe”, Heizung und Warmwasser werden als eingerückte Unterzeilen angezeigt (nur wenn Werte > 0 vorhanden). Auslöser: Issue #113.
Live-Dashboard — Prognoseabweichung mit %-Wert: Anzeige erweitert von +0.7 über Progn. auf +0.7 kWh über Progn. (+1%). Auslöser: Issue #114 (rapahl).

[3.11.16] - 2026-04-09

Fix

Energieprofil löschen: Bestätigungsmeldung bleibt sichtbar: Meldung wird nach dem Seiten-Reload gesetzt und außerhalb des bedingten Datenbestand-Blocks gerendert — war vorher unsichtbar weil der Block nach dem Löschen (0 Einträge) ausgeblendet wird.

[3.11.15] - 2026-04-09

Fix

Energieprofil-Daten löschen: auch Tagessummen bereinigen: Der Lösch-Button entfernt jetzt zusätzlich TagesZusammenfassung — diese enthält aggregierte Werte die den PV-Lernfaktor beeinflussen und bei falsch gemappten Sensoren ebenfalls korrumpiert waren. Monatsdaten bleiben erhalten. Auslöser: Joachim-xo.

[3.11.14] - 2026-04-08

Fix

Energieprofil-Daten löschen: 422-Fehler behoben: DELETE-Endpoint-Pfad von /alle/rohdaten auf /rohdaten geändert — FastAPI hatte alle fälschlich als anlage_id (Integer) interpretiert.

[3.11.13] - 2026-04-08

Feat

Einstellungen → System: Button “Energieprofil-Daten löschen”: Direkt im Datenbestand-Block, mit Bestätigungsdialog. Für Nutzer mit falsch gemappten Sensoren die fehlerhafte Daten in TagesEnergieProfil geschrieben haben. Monatsdaten bleiben erhalten, Scheduler berechnet neu (max. 15 Min). Auslöser: Joachim-xo.

[3.11.12] - 2026-04-08

Fix

WetterWidget: Verbrauchsprognose 1000x zu groß (Regression v3.11.10): Bei unplausiblen DB-Werten (Median verbrauch_kw > 100 kW) wird auf HA-History-Fallback umgeschaltet statt fehlerhafte Werte zu verwenden. Zusätzlich: Debug-Endpoint GET /api/energie-profil/{id}/debug-rohdaten und Lösch-Endpoint DELETE /api/energie-profil/{id}/rohdaten zur Diagnose und Bereinigung. Auslöser: Joachim-xo (#231).

[3.11.11] - 2026-04-08

Fix

WetterWidget: Verbrauchsprognose 1000x zu groß (Regression v3.11.10): Automatische Erkennung und Korrektur von historisch falsch gespeicherten Watt-Werten in TagesEnergieProfil (Median > 100 kW → /1000). Auslöser: Joachim-xo (#231).

[3.11.10] - 2026-04-08

Fix

Live-Dashboard: Verzögerung beim Öffnen nach HA-Neustart behoben: Verbrauchsprofil für das WetterWidget liest jetzt primär aus der EEDC-DB (TagesEnergieProfil) statt über die HA-History-API. Eliminiert den 7-Tage-HA-History-Call der nach jedem Add-on-Neustart bis zu 15s Verzögerung verursachte. HA-History bleibt als Fallback für neue Installationen (< 2 Tage DB-Daten). Auslöser: Joachim-xo (#225).

[3.11.9] - 2026-04-08

Feat

Monat-Selektor in “Aktueller Monat”: Monat und Jahr frei wählbar (bis 6 Jahre zurück). Refresh-Button deaktiviert für Vormonate. Für vergangene Monate werden nur gespeicherte Daten angezeigt (kein MQTT-Inbound). Auslöser: MartyBR (community.simon42.com #216).

[3.11.8] - 2026-04-08

Fix

EnergieFluss Knoten-Tooltips: Desktop-Hover (native <title>-Kindelemente) und Mobile-Touch (data-title via useTouchTitleTooltip) funktionieren jetzt gleichzeitig. Haus-Knoten-Text in Variable hausTip vor return() extrahiert.

[3.11.7] - 2026-04-08

Fix

EnergieFluss Mobile-Tooltips: React rendert title-Props auf SVG-Elementen nicht als DOM-Attribute → getAttribute('title') lieferte immer null. SVG-Knoten nutzen jetzt data-title="...", Hook liest data-title || title. HTML-Elemente (Buttons) behalten title="".

[3.11.6] - 2026-04-08

Fix

Y-Achsenbeschriftung in PV-Anlage Charts: PVAnlageDashboard und PVStringVergleich — unit-Prop entfernt, useMemo-Formatter analog AktuellerMonat (MWh ab >10k kWh), width auf 80 erhöht. Verhindert Abschneiden der führenden Ziffer.
Y-Achsenbeschriftung in Speicher-Charts: Ladung/Entladung (kWh-Einheit), Zyklen (1 Dezimalstelle), Effizienz (domain von [80,100] auf [0,100] + %-Formatter) — verhindert Recharts-Fallback mit rohen Float-Ticks wenn Werte außerhalb des fixen Domains liegen.
Solar-Aussicht Prognose-Quelle: Live-Dashboard Heute-Prognose nutzt wetter.pv_prognose_kwh (GTI + Temperaturkorrektur) statt tag.pv_ertrag_kwh — angezeigte Zahl und Differenzrechnung sind nun konsistent.
EnergieFluss Mobile-Tooltips: SVG <title>-Kindelemente durch title=""-Attribute ersetzt — globaler useTouchTitleTooltip-Hook greift jetzt auch auf Mobile (Tap statt Hover).

[3.11.5] - 2026-04-07

Neu

PV-String Auslastungs-Füllung im Energiefluss: PV-String-Boxen füllen sich analog zur Batterie-SoC-Anzeige von unten proportional zur aktuellen Auslastung (Ist-W / kWp). Farbe: hellgrün (< 40%), gelb (40–80%), amber (> 80%). Tooltip zeigt Auslastung in % und installierte kWp. Auslöser: dietmar1968 (#208).

Fix

Y-Achse abgeschnitten in PV/Auswertungs-Charts: width={60} + k-Notation (≥ 1000 kWh → “x.xk kWh”) in PVAnlageDashboard, PVAnlageTab, EnergieTab, KomponentenTab. Auslöser: dietmar1968 (#208).

[3.11.4] - 2026-04-07

Änderung

Live Dashboard Solar-Aussicht überarbeitet: PV-Prognose-Card entfernt — Solar-Aussicht Heute zeigt den Wert direkt. Verbleibend/Über Prognose klein darunter. Neue kompakte Zeile “Verbrauchsprognose” (Haus + Batterie + WP + Wallbox + Sonstige) mit ⓘ-Tooltip. VM/NM als Spaltenüberschrift. Alle drei Tage einheitlich prominent. Vertikale Ausrichtung der kWh-Werte per Grid. Auslöser: Rainer-Feedback.

[3.11.3] - 2026-04-07

Fix

Plausibilitätsfilter für Sensor-Spikes im Tagesverlauf: Beim HA-Neustart liefern Sensoren kurzzeitig Extremwerte statt unavailable. Diese werden jetzt per Typ-Grenze herausgefiltert (Wallbox/E-Auto/Speicher: 50 kW, WP: 20 kW, BKW: 2 kW, PV: 100 kW). Betrifft HA- und MQTT-Pfad. Auslöser: Fronius Wattpilot HACS-Integration (Joachim-xo).
kWp Nachkommastellen in Investitionen: Im Investitionen-Formular war step="0.1" statt step="0.01" gesetzt. Betrifft besonders 750W-Module (0.75 kWp). (eedc#3)

[3.11.2] - 2026-04-07

Fix

Negative Cache für Open-Meteo API-Fehler: Bei Open-Meteo-Ausfällen (502 Bad Gateway) wurde bisher bei jedem Request sofort wieder angefragt, was zu 429 Rate Limiting führte. Jetzt wird nach einem Fehler der Cache-Key für 1–5 Minuten gesperrt (429→5 Min, 502→2 Min, Timeout→1 Min). Betrifft Live-Wetter, Solar-Prognose, Forecast und Archiv. Auslöser: Open-Meteo Ausfall 2026-04-07.

[3.11.1] - 2026-04-07

Fix

Y-Achse in Aktueller-Monat-Charts abgeschnitten (#112): Dynamischer Formatter für Vorjahresvergleich und SOLL/IST-Vergleich. Werte ≤ 10.000 kWh werden ganzzahlig in kWh angezeigt, darüber in MWh mit einer Nachkommastelle (z.B. 10.5 MWh). YAxis-Breite auf 90 px erhöht.
Backup-Seite — Infothek-Anhänge: Klarstellung dass PDFs und Fotos nicht im JSON-Export enthalten sind — sie werden als BLOB in der eedc.db gespeichert. Hinweis-Block mit Anleitung für HA Add-on (HA-Backup) und Standalone (eedc.db manuell sichern).

[3.11.0] - 2026-04-06

Neu

Energieprofil Etappe 2 — Tagesdetail + Wochenvergleich (Beta): Neuer Tab “Energieprofil” in den Auswertungen. Persistierte Stundenwerte aus TagesEnergieProfil werden als interaktiver Butterfly-Chart (analog Live-Tagesverlauf) und vollständige Tabelle dargestellt.
- Tagesdetail: Datum-Picker, gestapelter AreaChart (Erzeuger oben / Verbraucher unten), gestrichelte Gesamterzeugungslinie. Alle Sonstiges-Investments (Poolpumpe, BHKW, …) erscheinen namentlich als eigene Serien. KPI-Zeile: Gesamterzeugung, Verbrauch, Netzbezug, Einspeisung, Autarkie, Temperatur.
- Wochenvergleich: 9 Gruppen (Mo–Fr, Sa–So, einzelne Wochentage), 4 Zeiträume (30/90/180/365 Tage), 3 Kennzahlen (Verbrauch / PV / Netzbezug).
- Tabellen: Spaltenauswahl mit Gruppen, sortierbare Header, CSV-Export, localStorage-Persistenz — analog Auswertung-Tabelle. Berechnete Spalten Gesamterzeugung und Hausverbrauch.
- Beta-Badge + Sammel-Screen: Tab trägt “Beta”-Kennzeichnung. Solange < 8 Tage Stundenwerte vorhanden sind, erscheint ein Fortschrittsbalken statt leerer Charts.
- Info-Panel: Ausklappbare Erläuterung zu Datenquellen (HA-History / MQTT-Snapshots), Aggregations-Zeitplan und Felddefinitionen.

Fix

Energieprofil — Anlage-Wechsel: key={anlageId} erzwingt vollständigen Remount bei Anlagenwechsel, damit alle internen States (Datum, Daten, extraSerien) korrekt zurückgesetzt werden.

[3.10.6] - 2026-04-06

Fix

MQTT-Standalone: Tagesverlauf-Chart und Energieprofil-Stundenwerte fehlten: Docker-Standalone-Installationen ohne HA-Integration sammelten keine TagesEnergieProfil-Daten, weil get_tagesverlauf() ohne HA sofort leere Serien zurückgab. Neue Tabelle mqtt_live_snapshots speichert alle 5 Min die aktuellen MQTT Live-Watt-Werte (Einspeisung, Netzbezug, Investitionsleistungen). live_tagesverlauf_service nutzt diese als Fallback — damit laufen Tagesverlauf-Chart und Energieprofil-Aggregation auch im reinen MQTT-Modus.

[3.10.5] - 2026-04-06

Neu

MQTT-Gateway: 7 neue Geräte-Presets: Shelly EM (1-phasig), Shelly Plus Plug S / PM Mini, AhoyDTU, Victron Venus OS, sonnenBatterie, Tasmota Steckdose und Zigbee2MQTT Steckdose. Gesamt jetzt 12 Presets in 5 Gruppen (Shelly / Solar+WR / Speicher / Wallbox / Sonstiges).
MQTT-Gateway: Investitions-Kontext für Wallbox und Speicher-Presets: Presets für Geräte die einer konkreten Investition zuzuordnen sind (go-eCharger, sonnenBatterie, Shelly PM, Tasmota Steckdose, Zigbee2MQTT) fragen jetzt die Ziel-Investition ab und mappen auf live/inv/{id}/leistung_w statt auf ein globales Topic. Die Preset-Auswahl zeigt jetzt Gruppen statt einer flachen Liste.

Fix

MQTT-Gateway go-eCharger: Ziel-Topic korrigiert von live/wallbox_w auf live/inv/{id}/leistung_w — Ladeleistung wird jetzt korrekt der Wallbox-Investition zugeordnet.

[3.10.4] - 2026-04-06

Neu

BKW mit integriertem Speicher: Speicher-Investition dem Balkonkraftwerk zuordnen: Für Geräte wie den Anker Solix (BKW + integrierter Akku) kann die Speicher-Investition jetzt direkt dem zugehörigen Balkonkraftwerk zugeordnet werden. Das Dropdown „Gehört zu” im Speicher-Formular zeigt jetzt Wechselrichter und Balkonkraftwerke zur Auswahl. Für die vollständige Live-Dashboard-Anzeige (Batterie-Knoten im Energiefluss) muss die Batterieleistung als separate Speicher-Investition mit eigenem bidirektionalen Sensor erfasst werden.
UX-Hinweis bei BKW „Mit Speicher”: Beim Aktivieren der „Mit Speicher”-Option im Balkonkraftwerk-Formular erscheint ein Hinweis, dass für vollständige Auswertungen eine separate Speicher-Investition erforderlich ist.

Refactoring (intern, kein User-Impact)

Basis-MQTT-Live-Topics aus Registry: Die 8 Basis-Live-Topics (einspeisung_w, netzbezug_w, pv_gesamt_w, sfml_*, aussentemperatur_c) werden jetzt dynamisch aus BASIS_LIVE_FELDER in field_definitions.py generiert. Neues Basis-Live-Feld → nur noch dort eintragen.

[3.10.3] - 2026-04-06

Behoben

Tagesverlauf: Fehlende Investments sichtbar machen (#109): Wenn ein Investment (z.B. Wallbox) keinen HA-Leistungssensor konfiguriert hat, wird es im Tagesverlauf-Chart nicht dargestellt — das war bisher lautlos. Jetzt erscheint ein amber-farbener Hinweis: “Nicht dargestellt (kein HA-Leistungssensor): Wallbox XY”. Hinweis: Der Tagesverlauf benötigt zwingend eine HA-Entity für leistung_w in der Sensor-Zuordnung — MQTT-only Investments können mangels HA-History nicht angezeigt werden.
Live-Dashboard: Datenquellen-Unterschied kennzeichnen (#108): Die beiden Charts zeigen konzeptionell unterschiedliche Daten. Kleine Labels machen das jetzt sichtbar: EnergieFluss zeigt “Momentwerte · aktualisiert alle ~30s”, Tagesverlauf-Chart zeigt “10-Min-Durchschnitte aus HA-History”. (Gemeldet von Joachim-xo)

[3.10.2] - 2026-04-06

Behoben

WP Dashboard: JAZ/Strom Warmwasser zeigt 0.00 statt ”–”: Wenn strom_warmwasser_kwh = 0 (keine Daten eingetragen), zeigen JAZ Warmwasser und Strom Warmwasser jetzt korrekt ”–” statt “0.00” bzw. “0.0 MWh”. (Gemeldet von Rainer)
Monatsabschluss Wechselrichter: PV-Erzeugung-Feld bei getrennten PV-Arrays: Das Eingabefeld “PV-Erzeugung (kWh)” im Wechselrichter-Schritt des Monatsabschlusses wird jetzt automatisch ausgeblendet wenn separate PV-Modul-Investments vorhanden sind — die Erzeugung wird dort bei den einzelnen Segmenten erfasst. (Gemeldet von Rainer)
Monatsabschluss: Tab-Label “wechselrichter” klein geschrieben: Tab und Abschnittsüberschrift zeigen jetzt korrekt “Wechselrichter” (Großschreibung). Gleiches für “Sonstiges”. (Gemeldet von Rainer)

Refactoring (intern, kein User-Impact)

bedingung_anlage in field_definitions.py: Neue Bedingungsebene in der Investitions-Feld-Registry. Bisher gab es nur bedingung (Investment-Parameter, z.B. arbitrage_faehig). Mit bedingung_anlage können Felder jetzt auch abhängig vom Anlage-Kontext (andere Investments) ein-/ausgeblendet werden. Erster Einsatz: Wechselrichter pv_erzeugung_kwh mit bedingung_anlage: "keine_pv_module".
Phase 4a abgeschlossen: Backend-Ableitung von ERWARTETE_FELDER, energy_keys_by_typ, SOC_TYPEN und FELD_LABELS aus Registry (kein hardcodierter Block mehr in sensor_mapping.py, live_mqtt_inbound.py, ha_statistics.py).

[3.10.1] - 2026-04-06

Neu

Portal-Import: Zuordnungs-Wizard: Bei mehreren Investments gleichen Typs (z.B. 2 PV-Strings, 2 Speicher) zeigt der Portal-Import-Wizard jetzt einen optionalen Zuordnungs-Schritt. PV-Erzeugung und Batterie-Werte können prozentual aufgeteilt werden, Wallbox und E-Auto per Auswahl zugeordnet werden. Standard: proportionale Verteilung nach kWp/Kapazität. Bei eindeutiger Zuordnung entfällt der Schritt.

Behoben

Portal-Import: Batterie-Doppelzählung: md.batterie_ladung_kwh / md.batterie_entladung_kwh wurden bisher immer in Monatsdaten gesetzt, auch wenn gleichzeitig _distribute_legacy_battery_to_storages() dieselben Werte in InvestitionMonatsdaten schrieb. Die Legacy-Felder werden jetzt nur noch als Fallback gesetzt (kein Speicher angelegt).
Portal-Import: md.pv_erzeugung_kwh fehlte: Bei vorhandenen PV-Modulen wurde md.pv_erzeugung_kwh nicht gesetzt. Berechnungen die dieses Aggregat-Feld lesen (z.B. Cockpit) sahen 0 statt des tatsächlichen Werts.
Portal-Import: E-Auto-Typ-String: i.typ == "eauto" → "e-auto" — E-Auto-km-Daten wurden nie in InvestitionMonatsdaten geschrieben.

Refactoring (intern, kein User-Impact)

Import-Registry — field_definitions.py als Single Source of Truth: Alle Investitions-Felder sind jetzt mit CSV-Suffix, Aggregat-Zuordnung und Datentyp annotiert. _import_investition_monatsdaten_v09 (helpers.py) und _build_investition_felder / _detect_investition_spalten (custom_import.py) werden vollständig aus der Registry abgeleitet — kein hardcodierter Typ-Check mehr. Neue Felder oder Investitionstypen nur noch in field_definitions.py eintragen.
Lücken L1–L6 geschlossen: Wallbox ladung_pv_kwh (L1), WP Strom_Heizen/Warmwasser_kWh (L2), BKW Eigenverbrauch_kWh (L3), Sonstiges/Erzeuger eigenverbrauch_kwh + einspeisung_kwh (L4), Sonstiges/Verbraucher bezug_pv/netz_kwh (L5), Sonstiges/Speicher Feldnamen-Korrektur (L6 — Daten wurden bisher in Berechnungen ignoriert).

[3.10.0] - 2026-04-06

Neu

Custom-Import-Wizard: Investitions-Spalten (#111): Der Custom-Import-Wizard erkennt und importiert jetzt Investitions-Daten korrekt. Backend: neuer /apply/{anlage_id}-Endpoint ruft _import_investition_monatsdaten_v09 auf und schreibt direkt in InvestitionMonatsdaten pro Modul (PV, Speicher, E-Auto etc.). /analyze erkennt automatisch EEDC-Investitions-Spalten und generiert personalisierte Dropdown-Felder gruppiert nach Investitionstypen. Vorzeichen-Inversion (↕-Toggle) pro Mapping-Zeile. Frontend: Anlage-Auswahl in Schritt 1, erkannte Investitions-Spalten als grüne Read-only-Sektion, Dark-Mode-Fix für select-Elemente.

Geändert

Stepper-Navigation im Monatsabschluss-Wizard: Kreise mit Verbindungslinien statt flacher Buttonreihe. Abgeschlossene Schritte grün mit Haken, aktiver Schritt primary-farbig.
Layout Padding: Hauptbereich-Padding oben reduziert (pt-3 → pt-1) für kompakteres Erscheinungsbild.

Behoben

Fronius CSV-Parser Wh→kWh (#107): Fronius exportiert Energiedaten in Wh, EEDC hat diese als kWh eingelesen. Konvertierungsfaktor 1/1000 ergänzt.
Y-Achse in AktuellerMonat-Charts abgeschnitten (#186): YAxis width={70} auf allen kWh-Achsen — verhindert Abschneiden bei Werten >3.000 kWh.

[3.9.9] - 2026-04-04

Behoben

Monatsabschluss 500-Fehler: NameError: kategorie beim Aufruf des Monatsabschluss-Wizards. Die Variable wurde im Refactoring v3.9.7 entfernt, der Aufruf InvestitionStatus(kategorie=kategorie) blieb aber übrig. Fix: inv_kategorie wird jetzt korrekt aus inv.parameter gelesen (nur für Typ “sonstiges” relevant).

[3.9.8] - 2026-04-04

Behoben

Y-Achse in Vorjahresvergleich abgeschnitten: Beschriftungen wie “300 kWh” wurden links abgeschnitten. margin={{ left: 10 }} im BarChart behebt das. (Gemeldet von MartyBr, community.simon42.com #186)
Touch-Tooltips auf Mobile (#104): Info-Icons und title=""-Attribute funktionierten auf Mobilgeräten nicht (kein Hover). Zweistufige Lösung: FormelTooltip/SimpleTooltip erhalten zentralen useTooltipInteraction-Hook mit onClick-Toggle; globaler useTouchTitleTooltip-Hook in App.tsx aktiviert Touch-Support für alle title=""-Attribute im gesamten Frontend automatisch. (Gemeldet von dietmar1968 + joachim-xo, community.simon42.com #183/#184)

[3.9.7] - 2026-04-04

Behoben

KPI-Zeile: ML aus Verbleibend entfernt: “PV-Prognose” und “Verbleibend” verwenden jetzt ausschließlich EEDC-Werte. ML-Vergleich ist bereits in der Solar-Aussicht-Sektion vorhanden.

[3.9.6] - 2026-04-04

Neu

Seamless-Wettermodelle: Neue Optionen in den Anlage-Stammdaten — ICON Seamless (D2→EU→Global, empfohlen für DE/AT/CH), MeteoSwiss Seamless (Alpenraum) und ECMWF Seamless (Global, 15 Tage). Diese kaskadieren intern bei Open-Meteo automatisch zwischen Hoch- und Grobauflösung.

Behoben

Tageslicht-Zeitschiene ändert sich nicht (#102): Countdown “noch Xh Ym Zs Tageslicht” aktualisiert sich jetzt sekündlich statt alle 30 Sekunden. Progress-Bar-Marker bewegt sich flüssig. Sonnenstunden-Bisher/Rest werden jetzt minuten-präzise berechnet (anteilige aktuelle Stunde) statt nur stündlich zu wechseln.
“Verbleibend”-KPI unklar (#103): Label zeigt jetzt “Verbleibend (EEDC)” bzw. “Verbleibend (ML)” — der User sieht sofort welches Modell verwendet wird. PV-Prognose-Box zeigt zusätzlich den ML-Vergleichswert wenn SFML verfügbar. Tooltip erklärt die Formel: Tagesprognose − bisher erzeugt = verbleibend.
Wettermodell-Einstellung ignoriert in Kurzfrist-Aussichten: anlage.wetter_modell wurde nur in der Solar-Prognose berücksichtigt, nicht in Kurzfrist-Aussichten, Prognose-Service und Prefetch. Alle drei Kanäle verwenden jetzt das konfigurierte Modell.
Prefetch Cache-Key-Mismatch Live-Wetter: Der Prefetch hat den Live-Wetter-Cache unter einem anderen Key gespeichert als der Endpoint gelesen hat (:m= Suffix fehlte). Dadurch wärmte der Prefetch den Cache nutzlos. Jetzt verwenden beide denselben Key.

Refactoring (intern, kein User-Impact)

Wetter-Modul aufgeteilt: wetter_service.py (979 Z.) → services/wetter/ Package (cache, open_meteo, pvgis, orchestrator, models, utils)
Felddefinitions-Schicht: backend/core/field_definitions.py als Single Source of Truth für Monatsdaten-Felder — MonatsabschlussWizard, MonatsdatenForm und CSV-Template nutzen jetzt dieselben kanonischen Feldnamen
Naming-Fixes in verbrauch_daten: speicher_ladung_netz_kwh → ladung_netz_kwh, entladung_v2h_kwh → v2h_entladung_kwh
MonatsdatenForm: 6 Section-Komponenten ausgelagert (1.627 → 970 Zeilen)
Cockpit-Router aufgeteilt: cockpit.py (2.327 Z.) → cockpit/ Package (6 Module)

[3.9.5] - 2026-04-04

Behoben

Außentemperatur im Live-Dashboard: Temperatur-Anzeige fehlte, weil die aktuelle Stunde nur in den Stunden 6–20 gesucht wurde. Jetzt werden alle 24 Stunden berücksichtigt. Zusätzlich wird datetime.now() mit Europe/Berlin-Timezone aufgerufen, damit Docker-Container mit UTC korrekt funktionieren.
Außentemperatur MQTT-Fallback: Wenn der HA-Sensor nicht erreichbar ist (Standalone-Betrieb), wird die Außentemperatur jetzt aus dem MQTT-Inbound-Cache gelesen.
MQTT-Inbound Topic für Außentemperatur: Das Topic aussentemperatur_c fehlte in der generierten Topic-Liste und konnte daher nicht per MQTT-Automation befüllt werden.

[3.9.4] - 2026-04-03

Behoben

Statistik-Import: Verwaiste Sensor-Zuordnungen: Gelöschte Investitionen hinterließen verwaiste Einträge im Sensor-Mapping, die als “Investition X” mit Warndreieck im Import erschienen. Verwaiste Einträge werden jetzt übersprungen. Beim Löschen einer Investition wird der Mapping-Eintrag automatisch mitentfernt.
Fronius CSV-Import: Batterie + Eigenverbrauch: Batterie-Spalten (Ladung/Entladung) werden jetzt erkannt. “Direkt verbraucht” wird korrekt als Eigenverbrauch statt als Verbrauch gemappt. Spalten-Deduplizierung verhindert Doppelzuordnungen bei ähnlichen Spaltennamen.

Verbessert

Live-Dashboard: Prognose-Übererfüllung: Wenn die PV-Erzeugung die Tagesprognose übertrifft, wird jetzt “Über Prognose +X kWh” in Grün angezeigt statt das Feld komplett auszublenden.

[3.9.3] - 2026-04-03

Verbessert

Sonnenstunden im Live-Dashboard (#96): Neue Anzeige über der SunProgressBar — links Ist-Sonnenstunden bis jetzt, rechts prognostizierte Sonnenstunden bis Sonnenuntergang. Nach Sonnenuntergang wird die Tagessumme angezeigt. Werte basieren auf stündlichen Open-Meteo-Daten (Ist für vergangene Stunden, Prognose für zukünftige).
Live-Wetter respektiert Wettermodell: Der Live-Wetter-Endpoint nutzt jetzt das in den Anlage-Stammdaten konfigurierte Wettermodell (ICON-D2, MeteoSwiss, ECMWF etc.) statt immer best_match.
“Sonnenschein” → “Tageslicht”: Die verbleibende Zeit bis Sonnenuntergang wird jetzt als “Tageslicht” bezeichnet (korrekterer Begriff, da auch bei Bewölkung).

[3.9.2] - 2026-04-03

Behoben

Live-Wetter: NameError nach Sonnenstunden-Refactoring: daily-Variable fehlte nach Umbau auf stündliche sunshine_duration — Wetter-Widget zeigte keine Daten (Sunrise, Sunset, Temperatur Min/Max fehlten).

[3.9.1] - 2026-04-03

Verbessert

Monatsabschluss: Anderen Monat bearbeiten (#97): Monat-Picker im Wizard entfernt (war fehleranfällig). Stattdessen neuer Kalender-Button (📅) pro Zeile in der Monatsdaten-Tabelle — navigiert direkt zum Monatsabschluss-Assistenten mit korrekt vorgeladenen Daten. Im Wizard selbst ein dezenter Link zurück zur Monatsdaten-Tabelle.
Sonnenstunden genauer (#96): Stündliche sunshine_duration-Werte summiert statt Tages-Prognosewert. Für bereits vergangene Stunden liefert Open-Meteo Ist-Werte, für zukünftige die Prognose — ein Hybrid aus Messung und Vorhersage. Respektiert das konfigurierte Wettermodell (ICON-D2, MeteoSwiss etc.).

[3.9.0] - 2026-04-03

Refactoring

Live Dashboard Backend komplett neu strukturiert: live_power_service.py von 1830 auf 313 Zeilen aufgeteilt in 6 fokussierte Module (live_sensor_config, live_kwh_cache, live_history_service, live_verbrauchsprofil_service, live_tagesverlauf_service, live_komponenten_builder). live_dashboard.py von 1656 auf 356 Zeilen durch Extraktion von MQTT- und Wetter-Routes in eigene Router-Dateien.
EnergieFluss Frontend: Statischer SVG-Hintergrund (1019 Zeilen) in EnergieFlussBackground.tsx extrahiert — Kernkomponente von 1701 auf 712 Zeilen reduziert.

Verbessert

Performance: HA-Sensor-Einheiten gecacht: get_sensor_units() nutzt jetzt 1 Batch-Call + 1h TTL-Cache statt N sequentieller HTTP-Calls (bei 10 Sensoren bis 50s → jetzt <10ms bei Cache-Hit).
Performance: Wetter HA-Sensoren gebatcht: Außentemperatur + SFML-Sensoren werden in 1 Batch-Call gelesen statt 4 sequentieller Requests (~2s → ~500ms).
Performance: EnergieFluss Layout memoized: useMemo für Layout-Berechnung, maxKw und SVG-Höhe — vermeidet vollständige Neuberechnung bei jedem 5s-Refresh-Cycle.
Fix: Race Condition bei Anlage-Wechsel im Live Dashboard: In-flight API-Responses werden verworfen wenn der Nutzer zwischenzeitlich die Anlage gewechselt hat. Verhindert kurzes Flimmern mit Daten der vorherigen Anlage.

[3.8.21] - 2026-04-02

Behoben

WP getrennte Strommessung: Einstellung ging nach Update verloren (#95 Regression): Wer die Checkbox vor v3.8.19 aktiviert hatte, konnte den Wert als String 'true' in der DB gespeichert haben. Der neue strikte === true-Vergleich erkannte diesen String nicht → Checkbox wurde nach dem Update als deaktiviert angezeigt. Fix: beide Typen (boolean true und String 'true') werden beim Laden akzeptiert. Gemeldet von Rainer.

[3.8.20] - 2026-04-02

Behoben

MQTT Energy Snapshots schlugen für alle Anlagen fehl: Retained MQTT-Topics einer gelöschten Anlage (ID ohne DB-Eintrag) verursachten einen FOREIGN KEY constraint failed-Fehler. Da alle Inserts in einer Transaktion lagen, wurden auch gültige Anlagen nicht gespeichert — über Tage hinweg kein Snapshot → heute_kWh im Live-Dashboard blieb null. Fix: anlage_ids werden vor dem Insert gegen die DB validiert, unbekannte IDs werden übersprungen.
Fronius Solar.web Import: Einspeisung und Netzbezug fehlten bei deutschem Export: Das deutsche Interface liefert Energie ins Netz eingespeist und Energie vom Netz bezogen statt Einspeisung/Netzbezug. Der Parser erkannte diese Varianten nicht → beide Felder wurden als leer importiert. Außerdem wurde das deutsche Format nicht automatisch erkannt. Parser als getestet markiert (verifiziert mit echten Nutzerdaten — Danke Joachim!).

[3.8.19] - 2026-04-02

Behoben

Getrennte Strommessung WP lässt sich nicht abwählen (#95): 'false' (String) ist in JavaScript truthy — die Checkbox blieb nach einmaligem Aktivieren dauerhaft gesetzt. Fix: Laden mit striktem === true-Vergleich, Speichern mit expliziter Boolean-Konvertierung.

Verbessert

Monatsabschluss: Anderen Monat wählen: Kleiner Link unter dem Titel öffnet einen kompakten Monat/Jahr-Picker, um direkt zu vergangenen Monaten zu navigieren (z.B. für einen nachgeholten Abschluss).

[3.8.18] - 2026-04-02

Behoben

Live-Dashboard: heute-kWh Cache (60s TTL): Bei jedem Live-Refresh (alle paar Sekunden) wurde ein voller HA-History-API-Call für alle Sensoren von Mitternacht bis jetzt gemacht. Jetzt wird das Ergebnis 60 Sekunden gecacht — analog zum bestehenden Gestern-Cache.
MQTT Energy: Key-Format-Mismatch HA↔MQTT behoben: MQTT Energy Snapshots lieferten inv/{inv_id}/{field} Keys, das Frontend erwartet aber {typ}_{inv_id} (wie der HA-Pfad). Neues Mapping übersetzt automatisch anhand der Investitionstypen (z.B. inv/15/ladung_kwh → batterie_15_ladung).

[3.8.17] - 2026-04-02

Behoben

HA-Statistik-Import: Komponenten-Felder (PV, Speicher, Wallbox, …) werden nie übernommen: Die Import-Vorschau lieferte Investitions-Felder mit Labels als Schlüssel ("PV Erzeugung", "Ladung" …), der Import-Endpoint verglich diese jedoch gegen interne DB-Feldnamen ("pv_erzeugung_kwh", "ladung_kwh" …) → alle Investitionsfelder wurden als „nicht ausgewählt” übersprungen, inv_importiert blieb immer False. Fix: Der Endpoint akzeptiert jetzt sowohl raw Keys als auch Label-Form in erlaubte_felder.

[3.8.16] - 2026-04-02

Behoben

Daten-Checker: Wallbox und Wechselrichter melden „Leistung fehlt” obwohl eingetragen: Das Formular speichert max_ladeleistung_kw (Wallbox) und max_leistung_kw (Wechselrichter), der Checker suchte aber leistung_kw bzw. leistung_ac_kw → falsche Warnung trotz eingetragener Werte. Beide Schlüssel werden jetzt geprüft.

[3.8.15] - 2026-04-02

Behoben

Daten-Checker: 66 falsche Batterie-Warnungen bei InvestitionMonatsdaten-Speicher: Batterie-Checks in „Monatsdaten – Plausibilität” prüften die Legacy-Felder batterie_ladung_kwh / batterie_entladung_kwh in Monatsdaten, die bei investitionsbasierter Speicher-Erfassung (neuer Weg) bewusst leer sind. Fix: Vor dem Legacy-Check wird geprüft ob der Monat bereits durch Speicher-InvestitionMonatsdaten abgedeckt ist — wenn ja, entfällt die Warnung. Zusätzlich nutzt die Energiebilanz-Prüfung jetzt die IMD-Werte statt der Legacy-Felder, damit kein falscher negativer Hausverbrauch gemeldet wird.

[3.8.14] - 2026-04-02

Behoben

Batterie-Ladung heute falsch bei Huawei (und ähnlichen) Sensoren (#93 #94): Die HA History API liefert als ersten Datenpunkt den letzten bekannten State vor Mitternacht (z.B. 23:59 gestern mit 10,48 kWh) — auch wenn der Sensor kurz danach auf 0 zurückgesetzt wurde. Die bisherige Delta-Berechnung (val_end − pts[0]) erkannte diesen Fall nicht (kein Negativsprung im Gesamtdelta) und lieferte z.B. 0,1 statt 10,6 kWh für Batterie-Ladung heute → dadurch war auch der Hausverbrauch ~10 kWh zu hoch. Fix: pts[0] durch min(pts) ersetzt — der Minimalwert entspricht dem Post-Reset-Wert (≈ 0) und liefert die korrekte Tages-Akkumulation unabhängig davon, ob der Reset-Zeitpunkt im History-Fenster liegt. Betrifft alle kumulativen kWh-Sensoren (Batterie Ladung/Entladung, WP, Wallbox etc.). Zusätzlich: Double-Scale-Bug im Reset-Zweig behoben.

[3.8.13] - 2026-04-02

Verbessert

Daten-Checker: umfassend erweitert — Der Checker prüft jetzt alle Investitionstypen und Monatsdaten deutlich detaillierter:
- Stammdaten: Standort (Ort/PLZ) für Community-Benchmark-Vergleich
- Strompreise: WP- und E-Auto-Spezialtarife auf Existenz geprüft
- Investitionen: Balkonkraftwerk (leistung_wp), Wallbox (leistung_kw), Wechselrichter (leistung_ac_kw) — bisher ohne Checks. Speicher prüft Arbitrage-Preise wenn aktiv, E-Auto prüft V2H-Entladepreis wenn aktiv. WP prüft JAZ/SCOP/COPs je nach gewähltem Effizienz-Modus auf Plausibilität
- Investitions-Monatsdaten: Vollständigkeit wird jetzt gegen die Hauptmonatsdaten als Referenz geprüft (ab anschaffungsdatum der jeweiligen Investition) — fehlende Einträge werden erkannt, nicht nur fehlende Felder in vorhandenen Einträgen. WP berücksichtigt getrennte_strommessung
- Monatsdaten-Plausibilität: Pflichtfelder (einspeisung_kwh, netzbezug_kwh) werden auf None geprüft; Batterie-Felder wenn Speicher vorhanden. Neuer Energiebilanz-Check: negativer Hausverbrauch (PV − Einspeisung + Netzbezug ± Batterie < 0) wird als ERROR mit vollständiger Wert-Aufschlüsselung gemeldet

[3.8.12] - 2026-04-01

Behoben

Wetter-Endpoint: Verbrauchsprofil blockiert bei HA-Timeout nicht mehr dauerhaft: get_verbrauchsprofil() cachte bisher kein None-Ergebnis. Wenn die 14-Tage-HA-History-Anfrage mit ReadTimeout scheiterte (und MQTT-Fallback ebenfalls leer war), wiederholte sich der teure Timeout bei jedem Wetter-Refresh (alle 5 Minuten). Fix: None-Ergebnis wird jetzt ebenfalls gecacht (Sentinel-Pattern) — der Timeout tritt maximal 1× pro Tag auf statt dauerhaft. Zusätzlich: History-Fenster von 14 auf 7 Tage reduziert (ausreichend für Werktag/Wochenende-Profil, halbiert die HA-Datenmenge).

[3.8.11] - 2026-04-01

Intern

Logging-Konfiguration: Root-Logger wird jetzt korrekt mit basicConfig initialisiert. Bisher gingen alle logger.info/debug() Aufrufe der App ins Leere (Uvicorn konfiguriert nur seine eigenen Logger). Diagnose-Logging für get_verbrauchsprofil() jetzt auf INFO-Level sichtbar.

[3.8.10] - 2026-04-01

Intern

Diagnose-Logging Verbrauchsprofil: Debug-Ausgabe in get_verbrauchsprofil() zeigt ob HA-History oder MQTT-Fallback erfolgreich war — hilft Performance-Problem im Wetter-Endpoint zu lokalisieren.

[3.8.9] - 2026-04-01

Hinzugefügt

Live-Dashboard: Sonnentags-Fortschrittsbalken (#89): Visueller Trenner zwischen Ist-Werten und Prognose-Tiles in der Sidebar. Zeigt den Tagesfortschritt von Sonnenauf- bis -untergang mit Solar-Noon-Markierung und verbleibender Sonnenscheindauer.
Energie-Tabelle: Spalten-Reihenfolge konfigurierbar (#88): ↑↓-Buttons im Spalten-Picker erlauben Umsortierung innerhalb jeder Gruppe. Reihenfolge wird persistent gespeichert, CSV-Export folgt der gewählten Reihenfolge. Reset-Link stellt Default-Reihenfolge wieder her.

[3.8.8] - 2026-04-01

Behoben

Monatsabschluss: Speichern dauerte 30–60 Sekunden: MQTT-Publish, Energie-Profil Rollup (inkl. Open-Meteo-Calls für jeden Tag des Monats) und Community Auto-Share blockierten bisher den HTTP-Request. Alle drei laufen jetzt als FastAPI BackgroundTasks nach dem DB-Commit — der Wizard kehrt sofort zurück.

[3.8.7] - 2026-04-01

Hinzugefügt

Wallbox: Ladung PV durchgängig: Das Feld ladung_pv_kwh (PV-Anteil der Wallbox-Ladung) war zwar im Monatsabschluss-Wizard sichtbar, fehlte aber an allen anderen Stellen. Jetzt vollständig: Sensor-Mapping (optional, HA-Sensor oder manuell), Monatsdaten-Formular, HA Bulk-Import, Monatsaggregation und Energie-Explorer-Tabelle (neue Spalte „Wallbox PV-Ladung”).
Monatsabschluss: Wetterdaten automatisch laden: Globalstrahlung und Sonnenstunden werden beim Öffnen des Wizards automatisch im Hintergrund von Open-Meteo geholt — falls die Felder noch leer sind. Kein Button-Klick mehr nötig.

[3.8.6] - 2026-03-31

Behoben

Live-Dashboard: Ladezeit Wetter/Prognose bei Seitennavigation: Die live_wetter-Cache-TTL wurde von 5 auf 60 Minuten erhöht. Open-Meteo aktualisiert Wetterdaten stündlich (ICON-D2 3-stündlich), die 5-Minuten-TTL war unnötig aggressiv. Der Scheduler-Prefetch läuft alle 45 Minuten — dazwischen konnte der Cache ablaufen und jeder Seitenaufruf blockierte bis zu 15 Sekunden auf einen externen API-Call. Betraf alle Seitennavigationen (nicht nur nach Updates).

[3.8.5] - 2026-03-30

Hinzugefügt

Sensor-Zuordnung: Sonstige Investitionen (#85): Investitionen vom Typ „Sonstige” erscheinen jetzt im Sensor-Zuordnungs-Wizard. Felder werden kategorie-abhängig angezeigt: Verbraucher → Verbrauch (kWh), Erzeuger → Erzeugung (kWh), Speicher → beide Felder. Live-Leistungssensor (W) ebenfalls konfigurierbar.
Community: Link zum Community-Server (#85): Kleines ExternalLink-Icon im Community-Header öffnet energy.raunet.eu direkt im Browser.

Behoben

Community: JAZ-Vergleich nach WP-Typ (#85): Die Stärken/Schwächen-Berechnung nutzt jetzt den typ-spezifischen JAZ-Vergleich (jaz_typ) statt dem globalen Schnitt. Das Backend hatte den korrekten Wert seit v3.8.4 bereits geliefert — das Frontend ignorierte ihn jedoch und verwendete weiterhin den globalen jaz.community_avg. Jetzt wird jaz_typ bevorzugt (gleiche WP-Art), mit Fallback auf global wenn zu wenig Vergleichsdaten. Unterstützt alle 4 WP-Arten: Luft/Wasser, Sole/Wasser, Grundwasser, Luft/Luft.

[3.8.3] - 2026-03-30

Behoben

Social-Media-Text: Ausrichtung + Anlagengröße (#84): Balkonkraftwerk-Leistung wird zur Gesamtleistung addiert. Ausrichtung wird nur angezeigt wenn eindeutig (1 String oder alle gleich) — Multi-String-Anlagen mit verschiedenen Ausrichtungen zeigen kein Label. Exakter Azimut-Grad aus den Einstellungen hat Vorrang vor dem Dropdown-Label.

[3.8.2] - 2026-03-30

Verbessert

Aussichten Kurzfristig: 14-Tage-Cache beim Start vorwärmen: Beim Laden des Live-Dashboards wird die 14-Tage-Solarprognose jetzt im Hintergrund vorab gecacht (fire-and-forget). Wenn der User zu Aussichten navigiert, ist der Cache bereits warm — kein Warten mehr auf Open-Meteo (#82).

[3.8.1] - 2026-03-30

Behoben

Monatsabschluss: UNIQUE constraint bei Energieprofil (#80): Seit v3.8.0 liefert get_tagesverlauf() 10-Minuten-Daten (144 Punkte). Der energie_profil_service las diese Punkte direkt ein und versuchte pro Stunde 6× dieselbe stunde-Zeile zu INSERT-en → UNIQUE constraint. Fix: Sub-stündliche Punkte werden vor der Verarbeitung auf Stundenmittelwerte aggregiert.
Sensor-Mapping Dropdown: ESC und Click-outside schließen jetzt (#81): Im FeldMappingInput fehlten ESC-Handler und Click-outside-Handler. Das Dropdown ließ sich nur durch Auswahl eines Eintrags schließen. Beide Handler sind jetzt per useEffect registriert.

[3.8.0] - 2026-03-29

Verbessert

Tagesverlauf-Chart: 10-Minuten-Auflösung (#77): Der Live-Tagesverlauf zeigt jetzt 10-Minuten-Mittelwerte statt Stundenwerte (144 Datenpunkte statt 24). WP-Zyklen, Batterie-Ladekurven und kurzfristige Verbrauchsspitzen werden damit sichtbar. Die “Jetzt”-Referenzlinie wird auf den korrekten 10-Min-Bucket gerundet. Gilt für HA-Nutzer (HA Recorder liefert Sub-Minuten-Rohdaten).
Kurzfristig-Prognose: Immer 14 Tage (#75): Das Tage-Auswahlfeld (7/14/16) wurde entfernt. 14 Tage sind fest eingestellt — Open-Meteo liefert diese Auflösung zuverlässig und schnell. Die 16-Tage-Option entfällt (höhere Ladezeit, kein Mehrwert).
KPI-Kacheln leicht transparent (#78): Hintergrund der Werte-Kacheln auf 90% (Light) bzw. 85% (Dark) Deckkraft reduziert für bessere optische Integration.

Behoben

BKW-Leistung in kWp-Vergleich und Solarprognose (#74): Der Daten-Checker verglich bisher nur PV-Module gegen den manuellen kWp-Wert und ignorierte Balkonkraftwerke. Jetzt fließt BKW-Leistung korrekt in den Checker-Vergleich ein (Meldung: “Summe PV-Module + BKW”). Außerdem berücksichtigt die Solarprognose (prognose_service) die BKW-Leistung beim Gesamt-kWp — BKW ist genauso wetterabhängig wie normale PV.

[3.7.6] - 2026-03-29

Verbessert

Ladezeit Kurzfristig & Live deutlich reduziert: Zwei gezielte Optimierungen für den ersten Seitenaufruf:
1. Jitter bei User-Request deaktiviert: Der zufällige Verzögerung (bisher 1–30 Sekunden) vor Open-Meteo-API-Calls greift jetzt nur noch beim Hintergrund-Prefetch, nicht beim direkten Aufruf durch den User. Cache-Miss-Latenz sinkt um bis zu 30 Sekunden.
2. Sofort-Prefetch nach Kaltstart: Wenn der Container mit leerem L2-Cache startet (z. B. Erstinstallation oder abgelaufene SQLite-Daten), wird der Prefetch sofort im Hintergrund ausgelöst — ohne den Job-Jitter (5–60s). Der Cache ist warm, bevor der erste User die Seite öffnet.

[3.7.5] - 2026-03-29

Behoben

„Noch offen” nach Sonnenuntergang ausgeblendet (#72): Nach Sonnenuntergang wurde fälschlicherweise noch eine verbleibende Solarprognose angezeigt (z.B. >5 kWh um 21:30 Uhr). Ursache: die Berechnung Tagesprognose − bisher erzeugte kWh berücksichtigte nicht, ob die Sonne bereits untergegangen ist. Fix: wetter.sunset wird geprüft — nach Sonnenuntergang wird das KPI ausgeblendet.

[3.7.4] - 2026-03-29

Verbessert

Kostentabelle im Energie-Explorer: Die Finanzspalten (Einspeise-Erlös, EV-Ersparnis, Netzbezug-Kosten) sind jetzt standardmäßig sichtbar. Neue Spalte Netto-Bilanz (Erlös + Ersparnis − Netzbezugskosten) zeigt das monatliche Gesamtergebnis. Vorjahresvergleich mit Δ-Farbkodierung funktioniert wie bei allen anderen Spalten.

[3.7.2] - 2026-03-29

Behoben

Heute-kWh: kumulierte Monatsabschluss-Sensoren korrekt genutzt (#64 Follow-up): Seit v3.6.8 wurden die bereits konfigurierten Energy-Sensoren (Einspeisung, Netzbezug, PV-Erzeugung, Batterie-Ladung/-Entladung) aus dem Monatsabschluss-Mapping für die Live-Dashboard „Heute”-Berechnung nicht genutzt, weil der interne Schlüssel sensors statt des korrekten felder verwendet wurde und die FeldMapping-Struktur ({strategie, sensor_id}) nicht ausgelesen wurde. Folge: nach Container-Neustart am Morgen (vor Sonnenaufgang) fehlten PV, Einspeisung, Eigenverbrauch und Batterie-kWh im „Heute”-Abschnitt.
Prioritätskette jetzt vollständig: Basis Einspeisung/Netzbezug und PV-Investitionen nutzen jetzt ebenfalls kumulative Energy-Sensoren als Priorität 1 — keine Trapez-Abhängigkeit mehr wenn kWh-Sensoren konfiguriert sind.
_trapez_kwh mit 1 Datenpunkt: Gibt jetzt 0.0 zurück statt None (mathematisch korrekt: kein Intervall = 0 kWh). Safety-Net für W-only Setups ohne konfigurierte Energy-Sensoren.

[3.7.3] - 2026-03-29

Behoben

Foto-Hintergründe im HA Add-on: Bilder wurden im HA-Ingress-Kontext nicht gefunden (Fragezeichen-Icon). Ursache: absolute Pfade (/backgrounds/...) funktionieren hinter HA-Ingress nicht — auf relative Pfade (./backgrounds/...) umgestellt.

[3.7.1] - 2026-03-29

Verbessert

Foto-Hintergründe im Energiefluss: 6 neue Foto-Varianten wählbar — Alpenpanorama, Milchstraße, Dolomiten, Nebula, Sternennacht, Exoplanet. Der bisherige Wechsel-Button wurde durch ein Dropdown mit allen 9 Varianten (inkl. Tech, Sunset, Alpen) ersetzt. Bilder liegen als WebP vor (413 KB gesamt). Die Auswahl wird per localStorage gespeichert.

[3.7.0] - 2026-03-28

Verbessert

Batterie Live-kWh: optionale Tages-kWh-Slots (#64): Neue optionale Felder im Live-Sensor-Mapping für Speicher: „Ladung heute (kWh)” und „Entladung heute (kWh)”. Wer separate Tages-kWh-Sensoren hat (die täglich auf 0 zurückgesetzt werden), kann diese direkt eintragen — sie haben Vorrang vor der bisherigen Berechnung. Vollständige Prioritätskette: (1) Live-Tages-kWh-Sensoren, (2) kumulative Monatsabschluss-Sensoren mit Delta ab Mitternacht, (3) W-Sensor mit Trapez-Integration.
WP und Wallbox Live-kWh aus Monatsabschluss-Mapping: Sind stromverbrauch_kwh (WP) bzw. ladung_kwh (Wallbox) im Monatsabschluss-Sensor-Mapping konfiguriert, werden diese jetzt ebenfalls für die Live-Dashboard-Tooltips genutzt statt der Trapez-Integration.

[3.6.9] - 2026-03-28

Verbessert

Energieprofil-Revision (Etappe 1): Vorzeichenbasierte Aggregation ersetzt die fehlerhafte kategorie-basierte Logik. BHKW und Sonstiges-Erzeuger fließen korrekt in pv_kw ein, V2H wird in batterie_kw einbezogen, Wärmepumpe und Wallbox erhalten eigene Spalten (waermepumpe_kw, wallbox_kw) für spätere Effizienz- und Musteranalyse.
Rollierender Energieprofil-Scheduler: Neuer Job alle 15 Minuten schreibt abgeschlossene Stunden des laufenden Tages — heute’s Profil wächst jetzt laufend mit statt erst um 00:15 des Folgetags verfügbar zu sein.
Retention-Cleanup: TagesEnergieProfil-Stundenwerte älter als 2 Jahre werden täglich um 00:15 gelöscht. TagesZusammenfassung bleibt dauerhaft erhalten.

Hinweis

Bestehende Energieprofil-Daten werden bei diesem Update einmalig gelöscht und neu aufgebaut (fehlerhafte Aggregation der Vorgängerversion). Die Neusammlung beginnt automatisch.

[3.6.8] - 2026-03-28

Behoben

Batterie Laden/Entladen kWh im Live-Dashboard zu hoch (#64): Wenn Batterie-Sensoren Leistung (W) mit Rauschen um 0 W meldeten, summierte die Trapez-Integration das Rauschen über den Tag auf → überhöhte Werte. Fix: Sind ladung_kwh/entladung_kwh bereits im Monatsabschluss-Sensor-Mapping konfiguriert, werden diese kumulativen Sensoren direkt via Delta (aktuell − Mitternacht) genutzt — kein Trapez, kein Rauschen. Der W-Sensor-Pfad bleibt als Fallback erhalten.

[3.6.7] - 2026-03-28

Behoben

MQTT Auto-Publish war nicht aktiv: Die Einstellung MQTT_AUTO_PUBLISH=true wurde zwar gespeichert, aber nie ausgewertet — kein Scheduler-Job war verknüpft. Fix: Bei aktiviertem MQTT_AUTO_PUBLISH wird jetzt ein periodischer Job gestartet, der alle MQTT_PUBLISH_INTERVAL Minuten (Default: 60) die KPIs aller Anlagen via MQTT Discovery nach Home Assistant publiziert.

[3.6.6] - 2026-03-28

Behoben

Energie-Explorer Tabelle: Jahresvergleich-Dropdown im Dark Mode unleserlich: Vergleichsjahr-Select hatte semi-transparenten Hintergrund (primary-900/30), der von nativen Dropdowns ignoriert wird. Fix: opaker Dark-Mode-Hintergrund (gray-800).

[3.6.5] - 2026-03-28

Behoben

Cockpit Jahresauswahl: Optionen verschwinden nach Jahreswechsel (#71): Beim Wechsel auf ein konkretes Jahr wurden die anderen Jahre aus dem Dropdown entfernt, weil availableYears aus der gefilterten API-Antwort berechnet wurde. Fix: Jahre werden jetzt aus den ungefilterten Monatsdaten abgeleitet.

[3.6.4] - 2026-03-28

Verbessert

Energie-Explorer Tabelle: Sticky Header: Der Tabellenkopf bleibt beim Scrollen durch lange Datenlisten fixiert (max. 600 px Tabellenhöhe, scrollbar). Wunsch: MartyBr.
Energie-Explorer Tabelle: Freie Jahreswahl im Jahresvergleich: Beim Jahresvergleich kann jetzt ein beliebiges Vergleichsjahr aus einem Dropdown gewählt werden (statt fix Vorjahr). Standard bleibt das Vorjahr, sofern Daten vorhanden. Wunsch: MartyBr.

[3.6.3] - 2026-03-28

Behoben

Cockpit Zeitraum und Jahresauswahl (#71): Bei Anlagen mit Monatsdaten (z.B. Netzbezug) vor der ersten PV-Investition wurde der Zeitraum nur aus InvestitionMonatsdaten berechnet — ältere Monate und Jahre fehlten in der Auswahl. Fix: frühestes und spätestes Datum aus beiden Quellen (Monatsdaten + InvestitionMonatsdaten) kombiniert.
FormelTooltip am linken Rand (#70): Tooltip wurde am linken Viewport-Rand abgeschnitten. Fix: horizontale Position wird jetzt viewport-bewusst berechnet und bei Bedarf nach rechts verschoben.

[3.6.2] - 2026-03-28

Behoben

JAZ Heizen/Warmwasser falsch berechnet (#67): Wärmemenge summierte über alle Monate, Strom nur über Monate mit getrennter Strommessung → absurde Werte (z.B. 89, 297). Fix in WP-Dashboard und Auswertungen → Komponenten.
BKW-Anlagenleistung ignoriert Anzahl Module (#66): Im Cockpit wurde nur die Leistung eines einzelnen Moduls in kWp umgerechnet, die Modulanzahl blieb unberücksichtigt.
Security: Path Traversal in SPA-Serving (#65): .resolve() + Prefix-Check verhindert das Auslesen von Dateien außerhalb des Frontend-Ordners.
Security: CORS allow_credentials (#65): Ungültige Kombination allow_origins=["*"] + allow_credentials=True korrigiert.
Security: Infothek-Upload ohne Größenlimit (#65): 50 MB Limit für Datei-Uploads eingebaut.

Geändert

JAZ statt COP im WP-Dashboard (#67): Labels umbenannt — “Ø COP” → “JAZ (gesamt)”, “COP Heizen” → “JAZ Heizen”, “COP Warmwasser” → “JAZ Warmwasser”.
JAZ in Auswertungen → Komponenten (#67): JAZ, JAZ Heizen und JAZ Warmwasser mit Jahresfilter verfügbar (nur bei getrennter Strommessung).

[3.6.1] - 2026-03-28

Behoben

Browser-Cache nach Updates (#69): Nach einem Add-on-Update zeigte der Browser weiterhin die alte Oberfläche, weil index.html aus dem Browser-Cache geladen wurde. Fix: Cache-Control: no-cache Header für index.html — der Browser prüft nun bei jedem Aufruf ob eine neue Version vorliegt. JS/CSS-Bundles bleiben weiterhin gecacht (kein Performance-Verlust).
Tabellen-Tab: Render-Crash bei Vorjahresvergleich: Fehlende Keys auf React.Fragment in map()-Aufrufen konnten die Auswertungs-Seite zum Absturz bringen sobald der Vorjahresvergleich aktiviert wurde.
Monatsabschluss-Tooltip: Hover über den roten Punkt in der Kopfzeile zeigt jetzt welcher Monat offen ist (z.B. “Monatsabschluss Februar 2026 offen”).

[3.6.0] - 2026-03-28

Neu

Interaktiver Energie-Explorer (Auswertungen → Tabelle): Neuer Tab mit vollständiger Tabellenansicht aller Monatsdaten — als Ergänzung zu den Grafiken für präzise Zahlen und individuelle Auswertungen.
- 22 Spalten in 7 Gruppen: Energie, Quoten, Speicher, Wärmepumpe, E-Auto, Finanzen, CO₂
- Sortierung per Klick auf jeden Spaltenheader (auf-/absteigend)
- Spaltenauswahl via Dropdown mit Gruppen-Gliederung — Konfiguration wird automatisch im Browser gespeichert (localStorage)
- Aggregationszeile am Ende: Summe für kWh/km/€, Durchschnitt (Ø) für Prozentwerte und COP
- Vorjahres-Vergleich: Toggle-Button zeigt Δ-Spalte pro Metrik mit farbiger Bewertung (grün/rot je nach Richtung)
- Finanzen mit historisch korrektem Tarif pro Monat aus der Strompreise-Tabelle
- Deutsches Zahlenformat mit Tausender-Punkt und Komma-Dezimalstelle
- CSV-Export inkl. Δ-Spalten bei aktivem Vorjahresvergleich

[3.5.11] - 2026-03-28

Behoben

JAZ Heizen/Warmwasser in Auswertungen → Komponenten (#67): Gleicher Monate-Bug wie im WP-Dashboard — Heizung/Warmwasser wurde über alle Monate summiert, Strom nur über Monate mit getrennter Messung. Fix: Nur Monate mit vorhandener getrennter Strommessung fließen in JAZ Heizen/Warmwasser ein.

[3.5.10] - 2026-03-28

Behoben

JAZ Heizen/Warmwasser falsch berechnet (#67): Wärmemenge summierte über alle Monate, Strom nur über Monate mit getrennter Strommessung → absurde Werte (z.B. 89, 297). Fix: Wärme und Strom werden jetzt aus denselben Monaten summiert.
BKW-Anlagenleistung ignoriert Anzahl Module (#66): Im Cockpit wurde nur die Leistung eines einzelnen Moduls in kWp umgerechnet, die Modulanzahl blieb unberücksichtigt. 2 × 490 Wp ergab fälschlicherweise 0,49 statt 0,98 kWp.
Security: Path Traversal in SPA-Serving (#65): .resolve() + Prefix-Check verhindert jetzt das Auslesen von Dateien außerhalb des Frontend-Ordners über präparierte URL-Pfade.
Security: CORS allow_credentials (#65): Ungültige Kombination allow_origins=["*"] + allow_credentials=True korrigiert (allow_credentials=False).
Security: Infothek-Upload ohne Größenlimit (#65): 50 MB Limit für Datei-Uploads eingebaut.

Geändert

JAZ statt COP im WP-Dashboard (#67): Labels umbenannt — “Ø COP” → “JAZ (gesamt)”, “COP Heizen” → “JAZ Heizen”, “COP Warmwasser” → “JAZ Warmwasser”. Hinweistext erklärt Gesamtlaufzeit-Bezug.
JAZ in Auswertungen → Komponenten (#67): JAZ, JAZ Heizen und JAZ Warmwasser jetzt auch im Auswertungs-Tab mit Jahresfilter verfügbar (nur wenn getrennte Strommessung vorhanden).

[3.5.9] - 2026-03-27

Neu

Hintergrund-Varianten im Energiefluss-Diagramm: Neuer Toggle-Button (Tech → Sunset → Alpen) mit automatischer Speicherung der Auswahl.
- Sunset: Krepuskulare Sonnenstrahlen im Himmel, elliptische Wellenebenen auf dem Meer, goldene Lichtfunken auf dem Wasser — vollständig in Light und Dark Mode.
- Alpen: Drei Bergketten-Silhouetten mit Schneekuppen. Light Mode mit Sonnenscheibe und goldenen Strahlen. Dark Mode mit Granit-Grau, Nadelwald-Grün, Mondlicht, Sternenhimmel und Aurora-Hauch.

[3.5.8] - 2026-03-27

Behoben

Kurzfrist-Prognose lädt langsam: Cache-Key-Mismatch — Frontend fragt standardmäßig tage=14 an, Prefetch wärmte aber nur days=7 und days=16. Dadurch traf jeder Aufruf der Kurzfrist-Seite einen leeren Cache und wartete 1–30s Jitter + API-Call. Prefetch jetzt für alle drei Werte (7, 14, 16).

[3.5.7] - 2026-03-27

Behoben

Wärmepumpenart im Investitionsformular (#63): Das Dropdown “Wärmepumpenart” (Luft-Wasser, Sole-Wasser, Grundwasser, Luft-Luft) war im Backend bereits definiert, fehlte aber im Frontend-Formular. Jetzt sichtbar unter Investitionen → Wärmepumpe.
Historische Tarife in Finanzauswertung (#63): Tarif-Auflösung komplett ins Frontend verlagert — alle Stromtarife werden geladen und pro Monat der zum 1. des Monats gültige Tarif verwendet. Funktioniert jetzt auch ohne Investitions-Komponenten.

[3.5.6] - 2026-03-27

Behoben

Live Dashboard Batterie kWh zu hoch (#64): Energie-Sensoren (kWh/Wh/MWh) wurden bisher nochmals über Zeit integriert → massiv überhöhte Werte. Automatische Erkennung: wenn ein Sensor kWh meldet, wird heute = aktueller_Wert − Mitternacht berechnet. Keine Mapping-Änderung nötig.

[3.5.5] - 2026-03-27

Behoben

Historische Tarife in Monatsbalken (#63): Finanzauswertung zeigt jetzt pro Monat die Kosten mit dem historisch korrekten Tarif (inkl. Grundpreis). Auch die Balken in “Finanzielle Bilanz pro Monat” nutzen jetzt historische Tarife statt des aktuellen.

[3.5.4] - 2026-03-27

Behoben

Historische Tarife in Finanzauswertung (#63): Netzbezugkosten wurden bisher immer mit dem aktuell gültigen Tarif berechnet. Jetzt wird pro Monat der zum Monatsersten gültige Tarif verwendet — inkl. korrektem Grundpreis. Info-Kasten zeigt jetzt die Summe der monatlichen Kosten statt einer Neuberechnung mit aktuellem Tarif.
Wetter-Symbole aus Bewölkung (#59): Symbol wird jetzt direkt aus der Bewölkung bestimmt (unabhängig vom WMO-Code): <20% → Sonne, <40% → Sonne+Wolke (warm), <70% → Sonne+Wolke, ≥70% → Wolke. Behebt Inkonsistenz bei MeteoSwiss.
Balkonkraftwerk in Live-Dashboard Orientierung (#62): BKW wurde bei der Wetter-Orientierungsgruppe nicht berücksichtigt.

[3.5.3] - 2026-03-27

Behoben

Wetter-Symbole plausibilisiert: WMO weather_code von MeteoSwiss passte nicht zur Bewölkung (z.B. “bewölkt” bei 27%). Symbole werden jetzt anhand der tatsächlichen Bewölkung korrigiert: <20% → Sonne, <40% → Sonne+Wolke, >80% → Wolke.
Migration-Batch Routing-Fehler: “Übernehmen”-Button auf Investitionen-Seite gab int_parsing-Fehler (FastAPI Route-Konflikt).

[3.5.2] - 2026-03-27

Hinzugefügt

Infothek: Kategorie Messstellenbetreiber (#60): Neue Vorlage für Nutzer mit separatem Zähleranbieter. Felder: Zählernummer, Messstellenbetreiber, Zähler-Typ (Konventionell/mME/iMSys), Zähler-Hersteller, Einbau-/Eichdatum, Eichfrist, Vertragsnummer, Jahresgebühr, Kundennummer. Auslöser: Rainer.

[3.5.1] - 2026-03-27

Hinzugefügt

Kaskadierender 2-Stufen-Cache (L1/L2): Persistenter SQLite-Cache unter dem RAM-Cache für Wetter- und Solar-Daten. Erster Seitenaufruf nach Server-Neustart wird sofort aus L2 bedient (~5ms statt 5-30s). Startup-Warmup lädt L2 direkt nach DB-Init in L1. Cleanup-Job täglich um 04:00 + Fallback beim Boot.
Live-Wetter Prefetch: Das WetterWidget auf der Live-Seite wird jetzt proaktiv alle 45 Min vom Prefetch-Service vorgeladen (bisher nur on-demand bei Client-Aufruf).
Wärmepumpenart (wp_art): Neues Dropdown im WP-Investitions-Formular (Luft-Wasser, Sole-Wasser, Grundwasser, Luft-Luft). Wird beim Community-Share mitgesendet für fairen JAZ-Vergleich nach WP-Art. Auslöser: Rainer-Feedback.

Geändert (Community-Server)

JAZ-Benchmark nach WP-Art: Community-Vergleich zeigt zusätzlich den typ-spezifischen Durchschnitt (z.B. Ø Luft-Wasser: 3.0 statt nur Ø Alle: 3.8).
Neuer Endpoint GET /api/components/waermepumpe/by-art: JAZ-Statistiken gruppiert nach Wärmepumpenart.

[3.5.0] - 2026-03-26

Hinzugefügt

Infothek-Modul: Neues optionales Modul zur Verwaltung von Verträgen, Zählern, Kontakten und Dokumentation.
- 14 Kategorien mit dynamischen Vorlagen-Feldern: Stromvertrag, Einspeisevertrag, Gasvertrag, Wasservertrag, Fernwärme, Brennstoff, Versicherung, Vertragspartner, Wartungsvertrag, MaStR, Förderung, Garantie, Steuerdaten, Sonstiges.
- Datei-Upload: Bis zu 3 Dateien pro Eintrag (Fotos + PDFs). Bilder werden serverseitig auf max 500kb resized, Thumbnails generiert, EXIF-Rotation korrigiert, HEIC→JPEG konvertiert. PDFs max 5 MB.
- Lightbox für Bilder, PDF öffnet in neuem Tab.
- Vertragspartner: Eigene Sektion mit separatem Button, Badges mit Telefon/Mail-Links. Zuordnung per Dropdown bei Verträgen — einmal pflegen, mehrfach zuordnen (z.B. Gemeindewerke → Strom, Gas, Wasser).
- Vorbelegung: Felder werden beim Anlegen aus vorhandenen Systemdaten befüllt (Strompreise → Tarif/Anbieter, Anlage → MaStR/Inbetriebnahme).
- Investition-Verknüpfung: Bidirektional — Infothek-Einträge können mit Investitionen verknüpft werden, Investitions-Karten zeigen verknüpfte Einträge.
- Migration: Bestehende Stammdaten (Kontakte, Garantien, Wartungsverträge) aus Investitionen per Klick in die Infothek übernehmen. Button auf der Investitionen-Seite.
- PDF-Export: Alle oder gefilterte Einträge als PDF, nach Kategorie gruppiert.
- Markdown-Notizen: Toolbar (Bold/Italic/Liste/Link) mit Vorschau-Toggle, Rendering in Karten und im PDF.

Dependencies

react-markdown (Frontend)
Pillow, pillow-heif (Backend — Bildverarbeitung)

[3.4.34] - 2026-03-26

Verbessert

Performance: Live-Wetter sofort aus Cache: Open-Meteo Wetter-Response wird 5 Min gecacht — Wetter-Widget lädt sofort statt 5–10s auf API-Antwort zu warten.

[3.4.33] - 2026-03-26

Verbessert

Performance: API-Calls drastisch reduziert: Shared Module-Level Cache für useAnlagen und useInvestitionen — alle Komponenten (TopNavigation, SubTabs, Seiten) teilen einen API-Call statt jeweils eigene zu machen.
Performance: Live-Dashboard Backend: Investitionen-Queries von 3 auf 1 pro 5s-Poll, Gestern-kWh Cache (bis Mitternacht), HA Sensor-Abfragen gebatcht (1 HTTP-Call statt 5–15).
Performance: Lernfaktor Cache: 30-Tage TagesZusammenfassung-Query nur noch 1× pro Tag statt bei jedem Wetter-Abruf.
Live-Dashboard Wetter+Prognose: Parallel via Promise.allSettled statt sequentiell — halbe Wartezeit.

[3.4.32] - 2026-03-26

Behoben

Aussichten-Ladezeit 30s+ (#59): Externe API-Abfragen auf Hintergrund-Caching umgestellt. Prognose-Prefetch läuft alle 45 Min automatisch, Seiten laden sofort aus dem Cache.
Wallbox/E-Auto Doppelzählung: Wenn Wallbox und E-Auto denselben Leistungs-Sensor nutzen, wird die Leistung nur einmal gezählt. SoC (Ladezustand) wird weiterhin separat angezeigt.
Netto-Hausverbrauch im Energiefluss: Kind-Komponenten (E-Auto mit parent_key) werden im Zentrum des Energieflusses nicht mehr doppelt mitgezählt.
Live-Dashboard Mobile (#56): Autarkie/Eigenverbrauch und Prognose-Kacheln einheitlich linksbündig im Grid-Layout. Prognose-Zeile bricht auf schmalen Screens (< 400px) auf 2 Spalten um.
Logo Dark Mode: Halbtransparenter Hintergrund für Full-Logo, “dc” und Subtitel aufgehellt.

Verbessert

Multi-String Solar-Prognose: Parallel statt sequentiell (asyncio.gather) — deutlich schneller bei mehreren PV-Ausrichtungen.

[3.4.31] - 2026-03-26

Behoben

Bezug/Einspeisung in Heute-kWh vertauscht (#58): Die Vorzeichen-Invertierung aus den Basis-Sensoren wurde bei der History-basierten Tages-kWh-Berechnung nicht angewendet. Betrifft Heute/Gestern-Widgets, Tagesverlauf-Chart und Energieprofil. Live-Leistungsanzeige (W) war korrekt.

[3.4.30] - 2026-03-26

Behoben

Leere Exception-Logs: Alle 32 logger.warning/error-Stellen im Backend loggen jetzt den Exception-Typ (ConnectError: ... statt nur :). Betrifft 20 Dateien: HA Statistics, Wetter, Solar Forecast, MQTT, Connector, Monatsabschluss u.a.
Protokolle Limit-Inkonsistenz: Frontend forderte 300 Einträge an, Text sagte “max. 500” — beides auf 500 vereinheitlicht
Offset=0 nicht gesendet: API-Client übersprang offset=0 (JavaScript falsy) — korrigiert auf != null Check

Neu

Aktivitäts-Logging für alle kritischen Operationen: 6 neue Kategorien mit ~20 log_activity()-Aufrufen:
- HA-Statistiken: DB-Abfrage-Fehler, Import-Ergebnisse (Monate importiert/übersprungen/Fehler)
- Scheduler-Jobs: Monatswechsel-Snapshot, Energie-Profil Aggregation, MQTT Energy Snapshot/Cleanup
- MQTT: Inbound/Gateway/Bridge Start + Verbindungsverlust
- Community: Daten teilen/löschen + Timeout/Verbindungsfehler
- Sensor-Mapping: Speichern/Löschen mit Sensor-Anzahl
- HA-Export: MQTT-Sensoren publiziert/entfernt
- Backup-Export/Import: JSON-Export/Import mit Details
Textsuche in Aktivitäten: Suchfeld mit Debounce (400ms), sucht case-insensitive in Aktion und Details (Backend: ILIKE auf aktion + details)
Copy-Button (beide Tabs): Kopiert sichtbare Einträge als Markdown — ideal zum Einfügen in GitHub Issues. Button zeigt grünes Häkchen als Feedback
Download-Button (System-Logs): Exportiert gefilterte Logs als .txt-Datei
Cleanup-Feedback: Nach Bereinigung alter Aktivitäten (>90 Tage) zeigt ein grüner Toast die Anzahl entfernter Einträge
Debug-Modus: Log-Level zur Laufzeit zwischen DEBUG/INFO umschaltbar (kein Restart nötig). Amber-farbiger Button + Warnhinweis bei aktivem Debug
Neustart-Button: EEDC direkt aus den Protokollen neu starten (HA: Supervisor-API, Standalone: Container-Restart)

[3.4.29] - 2026-03-25

Behoben

EV-Quote >100% Cap: Eigenverbrauchsquote wird auf maximal 100% begrenzt
API-Cache Random-Jitter: Cache-Expiry mit zufälligem Offset, verhindert gleichzeitige Cache-Invalidierung aller Clients

Neu

Infothek-Konzept (#57): Konzeptdokumentation für optionales Modul (Verträge, Zähler, Kontakte, Fotos) mit UI-Mockups und 5 neuen Kategorien (Gas, Wasser, Fernwärme, Pellets, Versicherung)

[3.4.28] - 2026-03-25

Behoben

Monatsabschluss TypeError (#54): monatsdaten_id wurde an InvestitionMonatsdaten-Konstruktor übergeben, obwohl das Feld im Model nicht existiert — erster Monatsabschluss schlug fehl
Health-Check Log-Spam (#54): HA Supervisor Health-Checks (/api/health alle paar Sekunden) werden aus den Uvicorn Access-Logs gefiltert

Neu

Dynamische Cockpit-Tabs (#56): Investitions-Tabs (E-Auto, Wallbox, Speicher etc.) werden nur angezeigt wenn eine entsprechende Investition existiert. Basis-Tabs (Übersicht, Aktueller Monat, PV-Anlage) bleiben immer sichtbar
Mobile-Optimierung (#56): Komplette Überarbeitung der Mobile-Ansicht:
- Responsive Padding (Layout, Sticky-Header)
- KPI-Kacheln: responsive Font-Size, kein Text-Overflow, einspaltig auf Phones
- EnergieFluss SVG: ResizeObserver + dynamische viewBox (360/450/600px)
- HeroLeiste + RingGaugeCard: kompakter auf Mobile
- SubTabs: Scroll-Snap + versteckte Scrollbar
- Touch-Feedback (active:scale-95) auf Buttons
- ARIA-Labels und Live-Regions für Screenreader

Verbessert

Anlage-Select vereinheitlicht (#56): Kompakte Breite (compact-Prop) auf allen Cockpit-Seiten, Anlage-Wechsel synchronisiert alle Komponenten via CustomEvent
Header-Layout konsistent (#56): Einheitliches Flex-Layout auf Übersicht, Aktueller Monat und allen Investitions-Dashboards

[3.4.27] - 2026-03-25

Behoben

Fehler „[object Object]” im Monatsabschluss (#54): ApiClient warf Plain Object statt Error-Instanz, dadurch wurden Backend-Fehlermeldungen im gesamten Frontend als „[object Object]” oder generische Texte angezeigt. ApiError ist jetzt eine Error-Subklasse
Update-Hinweis für HA Add-on präzisiert (#55): Statt „Update über Einstellungen → Add-ons” jetzt konkreter Pfad zum manuellen Update-Check mit Hinweis auf automatische Prüfung

Verbessert

Monatsabschluss Save-Logging: Detailliertes Logging der Eingabedaten und DB-Operationen für Fehlerdiagnose

[3.4.26] - 2026-03-25

Neu

MQTT Gateway mit Geräte-Presets: Universelle MQTT-Brücke für beliebige Smarthome-Systeme mit vorgefertigten Geräte-Presets
Dashboard Refactoring: Aufsplitten in wiederverwendbare Komponenten (HeroLeiste, KPICard, RingGaugeCard, EnergyFlowDiagram, etc.)
Frontend-Bibliothek (lib/): Zentrale Utilities für Formatierung, Farben, Berechnungen und Konstanten
Custom Hooks (hooks/): useApiData, useSelectedAnlage, useYearSelection für einheitliche Datenlade-Patterns
Monatsabschluss-Komponenten: Wizard-Steps als eigenständige Komponenten (BasisStep, InvestitionStep, SummaryStep, etc.)
Sensor-Mapping erweitert: Verbesserte BasisSensorenStep mit Live-Sensor-Vorschau und Mapping-Summary

Verbessert

Solar-Prognose: Erweiterte API mit Forecast-Daten
Live Dashboard: Erweiterte Power-Service-Integration und Wetter-Widget
Cockpit: Zusätzliche Analyse-Endpoints (Komponenten, PV-Strings, Prognose-Vergleich)
Connectors: MQTT-Bridge für Connector-Daten, verbesserte Geräte-Adapter
HA Statistics Service: Robustere Monatswert-Berechnung

[3.4.25] - 2026-03-24

Behoben

WP-Wärme Live-Anzeige im laufenden Monat (#53): Heizenergie- und Warmwasser-Sensoren wurden im laufenden Monat nicht angezeigt (“Wärme: — kWh”), obwohl sie korrekt gemappt waren. Die Aggregation fehlte für HA Statistics und MQTT-Inbound. Auch getrennte Strommessung wird jetzt korrekt summiert

[3.4.24] - 2026-03-24

Behoben

Standalone Multi-Arch Manifest fix (#51): docker buildx imagetools create statt docker manifest create für korrekte Multi-Arch-Manifeste

[3.4.23] - 2026-03-24

Behoben

Pre-built Docker Images für HA Add-on (#51): ARM64-Builds hingen wegen QEMU-Emulation. Umstellung auf native ARM64-Runner (ubuntu-24.04-arm) für beide Repos

[3.4.22] - 2026-03-24

Neu

ARM64 Docker-Image für Standalone (#52): Multi-Arch-Build (amd64 + arm64) für das Standalone-Docker-Image. Raspberry Pi und andere ARM-Geräte werden jetzt unterstützt

[3.4.21] - 2026-03-24

Neu

DWD ICON-D2 Wettermodell (#48): Neues hochauflösendes Wettermodell (2.2 km) speziell für deutsche Standorte. Kaskade: 2 Tage ICON-D2, danach Fallback auf best_match
Netto-Hausverbrauch im Energiefluss: Haus zeigt Summe aller Verbraucher (ohne Batterie/Netz) statt Residual-Rest

Behoben

Kurzfrist Heute-Markierung: ring → border für die Tages-Markierung (kein Abschneiden mehr am Kartenrand)

[3.4.20] - 2026-03-24

Neu

Community-Nudge + Auto-Share: Nudge-Banner im Live-Dashboard und Cockpit wenn noch nicht geteilt. Auto-Share Checkbox in Stammdaten, Community-Seite und Monatsabschluss-Hinweis

Behoben

Solarleistung ohne Batterie/Netz (#49): Solarleistung zeigt nur PV-Erzeugung (neues Feld summe_pv_kw), Position oberhalb Haus

[3.4.19] - 2026-03-24

Behoben

Installation schlägt fehl (#51): Pre-built Docker Images auf GitHub Container Registry (GHCR) bereitgestellt. Bisherige Releases enthielten den Build-Workflow noch nicht, sodass keine Images auf GHCR verfügbar waren (403 Denied beim Pull).

[3.4.18] - 2026-03-24

Behoben

Multi-String Wetter-Daten (#48): Kurzfrist-Tabelle zeigte bei Multi-String-Anlagen keine Temperatur, Bewölkung und Niederschlag (Felder wurden bei der String-Aggregation nicht durchgereicht)

Neu

Wettermodell-Kaskade (#48): Neues Dropdown “Prognose-Wettermodell” in Anlage-Stammdaten. Auswahl zwischen Automatisch (best_match), MeteoSwiss Alpen (2.1 km), DWD ICON-EU (7 km) und ECMWF IFS (9 km). Bei spezifischem Modell wird eine Kaskade verwendet: bevorzugtes Modell für die ersten Tage + best_match Fallback für den Rest (parallele API-Calls). Ideal für alpine Standorte (Südtirol, Schweiz, Tirol), die mit dem Standardmodell ungenaue Wetterprognosen erhalten.
Datenquellen-Anzeige: Herkunft der Wetterdaten wird pro Tag in der Kurzfrist-Tabelle als Kürzel (MS/EU/EC/BM) und in der Fußzeile zusammengefasst angezeigt

[3.4.16] - 2026-03-23

Behoben

Hausverbrauch-Berechnung mit Batterie (#47): Live Dashboard Tages-kWh (Eigenverbrauch, Hausverbrauch), Autarkie-/EV-Quote Gauges und Vorjahresvergleich berücksichtigen jetzt Batterie-Ladung/-Entladung. Bisher wurde Eigenverbrauch = PV - Einspeisung gerechnet (ohne Batterie), jetzt korrekt: Direktverbrauch = PV - Einspeisung - Batterieladung, Eigenverbrauch = Direktverbrauch + Batterieentladung, Hausverbrauch = Eigenverbrauch + Netzbezug.

[3.4.14] - 2026-03-23

Behoben

Wetter-Icons in Aussichten: Kurzfrist-Prognose zeigte immer nur Sonne — Regen, Schnee und Gewitter wurden nie als Icon angezeigt. Zwei Ursachen: (1) Solar-Prognose-Backend fragte keinen WMO Weather Code von Open-Meteo ab, (2) Frontend ignorierte das wetter_symbol-Feld und nutzte nur den Bewölkungsgrad.

[3.4.13] - 2026-03-23

Verbessert

Sonnenstunden als Zeitformat: Anzeige 10h 00m statt 10.0h im Wetter-Widget (#46)
SA/SU/SolarNoon im Chart: Sonnenaufgang, Sonnenuntergang und Solar Noon als vertikale Linien im PV-Chart (Noon-KPI oben entfernt) (#46)
Speicher-Farbwechsel: Ladung (blau) und Entladung (cyan) im Energiefluss visuell unterscheidbar (#46)
Speicher-Ladung sichtbarer: Opacity im Wetter-Chart deutlich erhöht (#46)
Energieumsatz-Tooltip: Erklärender Tooltip auf dem Energieumsatz-Label im Energiefluss (#46)
Echte Gerätenamen statt “Sonstige”: Im Wetter-Chart und Tooltip werden die tatsächlichen Investitions-Namen angezeigt (#46)
PV-Prognose KPI: Wird nur noch bei aktivem SFML angezeigt (keine Doppelung) (#46)
Wallbox-Phantom-Fix: Chart-Kategorien werden gegen vorhandene Investitionen validiert (#46)

[3.4.12] - 2026-03-23

Hinzugefügt

Sensor-Vorzeichen invertieren (#44): Neue Checkbox “Vorzeichen invertieren (×−1)” bei allen Live-Leistungssensoren (W) in der Sensor-Zuordnung. Löst das Problem bei Wechselrichtern/BMS die umgekehrte Vorzeichen liefern (z.B. Batterie: negativ = Ladung, positiv = Entladung).

[3.4.10] - 2026-03-23

Geändert

SoC-Anzeige als kompakte Balken: Halbkreis-Gauges durch farbige Fortschrittsbalken ersetzt (rot < 20%, gelb 20-50%, grün > 50%). Spart ~60% Höhe in der Sidebar.

Hinzugefügt

Batterie heute (Ladung/Entladung): Neue Kachel im “Heute”-Bereich zeigt Ladung (▲) und Entladung (▼) getrennt in kWh.

[3.4.9] - 2026-03-23

Behoben

VM/NM-Split an Solar Noon (#42): Vormittag/Nachmittag-Aufteilung nutzt jetzt Solar Noon (Equation of Time) statt hartem 12:00-Split. Behebt die stark verzerrten VM/NM-Verhältnisse (z.B. 15/85 statt ~50/50). Bei Ost/West-Anlagen wird jetzt pro String separat berechnet statt über einen gemittelten Azimut.
PV-Erzeugung Doppelzählung im Aktueller Monat (#43): Wenn ein Top-Level-Aggregat (z.B. aus gespeicherten Daten oder MQTT pv_gesamt) bereits existierte, wurden Einzel-Investitionswerte nochmals aufaddiert. PV-Erzeugung wurde dadurch doppelt angezeigt.
Live-Dashboard: Watt-Auflösung von 10W auf 1W verbessert (round(kw,3) statt round(kw,2)).

Hinzugefugt

Solar Noon im Wetter-Widget: Sonnenhöchststand als KPI in “Wetter heute” (z.B. “Noon 12:27”), mit Tooltip-Erklärung.
Hausverbrauch heute: Neue Kachel im “Heute”-Bereich des Live-Dashboards.
Info-Tooltips: Erklärungen an Eigenverbrauch, Netzbezug, PV-Prognose, Solar-Aussicht und Netz-Symbol-Farbe.

Geändert

Live-Dashboard kompakter: Kleinere Titelzeile, reduzierte Abstände — weniger Scrollbedarf bei maximaler Bildschirmauflösung.

[3.4.8] - 2026-03-22

Behoben

VM/NM-Werte in Solar-Prognose gefixt: Die Vormittag/Nachmittag-Aufteilung wurde im Backend berechnet aber bei der API-Antwort nicht durchgereicht (Pydantic-Konvertierung). Jetzt sichtbar in 3-Tage-Vorschau und Kurzfrist-Aussichten.

Hinzugefügt

SFML in “Noch offen” und 3-Tage-Vorschau: “Noch offen” nutzt jetzt die ML-Prognose wenn verfügbar (genauer als EEDC). 3-Tage-Vorschau zeigt SFML-Wert in lila neben dem EEDC-Wert für Heute und Morgen.

Geändert

Netz-Balken aus Sidebar entfernt: Die dynamische Netz-Farbe im Energiefluss SVG (grün/orange/rot) macht den separaten Netz-Balken überflüssig. Mehr Platz für 3-Tage-Vorschau und Temperaturen.

[3.4.7] - 2026-03-22

Hinzugefügt

3-Tage Solar-Vorschau in der Sidebar (#41): Kompakte Übersicht für Heute, Morgen und Übermorgen mit Vormittag/Nachmittag-Aufteilung — direkt auf der Live-Seite, ideal für die Planung großer Verbraucher (Waschmaschine, Trockner etc.).
“Noch offen” kWh-Kachel (#41): Zeigt das Restpotenzial für heute (Tagesprognose − bisheriger Ertrag) neben der PV-Prognose in der Sidebar. Verschwindet wenn die Prognose erreicht oder übertroffen ist.

Behoben

Netz-Farbe im Energiefluss korrigiert: Die dynamische Einfärbung (grün/orange/rot) hatte die Backend-Semantik vertauscht (erzeugung_kw = Netzbezug, verbrauch_kw = Einspeisung). Jetzt korrekt: orange bei Einspeisung, rot bei Netzbezug, grün bei Balance.

[3.4.6] - 2026-03-22

Hinzugefügt

Netz-Farbe dynamisch im Energiefluss (#40): Die Stromnetz-Linie ändert die Farbe nach Flussrichtung — grün bei Balance (±100W), orange bei Einspeisung, rot bei Netzbezug. Gleiche Logik wie der Netz-Gauge in der Sidebar.
Solar-Soll-Wert im Energiefluss (#40): Zeigt “Solar Soll ~X.X kW” unter dem Energieumsatz — basierend auf der SFML-Prognose der aktuellen Stunde, Fallback auf EEDC-Prognose.
Live als Startseite (#40): EEDC öffnet jetzt direkt mit dem Live-Dashboard statt dem Cockpit.
Außentemperatur in der Sidebar (#40): Aktuelle Temperatur + Min/Max (Tooltip) aus Wetterdaten in der Live-Sidebar.
Warmwasser-Temperatur (#41): Neuer Live-Sensor für Wärmepumpen (Sensor-Zuordnung → Wärmepumpe → Live-Sensoren). Wird in der Sidebar neben der Außentemperatur angezeigt.
Automatische W/kW-Anzeige (#41): Energiefluss zeigt unter 1 kW in Watt (z.B. “850 W”), darüber in kW (z.B. “22.0 kW”). Gilt für alle Knoten, Haushalt und Energieumsatz.
Solar-Prognose Vor-/Nachmittag (#41): Kurzfrist-Aussichten zeigen PV-Ertrag getrennt nach Vormittag (<12h) und Nachmittag (≥12h) — als gestapelte Balken im Chart, in KPI-Cards und Detail-Tabelle. Hilft bei der Planung großer Verbraucher.

Geändert

Demo-Button ausgeblendet (#40): Nur noch sichtbar mit URL-Parameter ?debug — weniger Verwirrung im Normalbetrieb.

[3.4.5] - 2026-03-22

Hinzugefügt

MQTT Gateway (Stufe 1): Topic-Translator für externe MQTT-Geräte (Shelly, Tasmota, OpenDTU, Zigbee2MQTT etc.) — ohne Node-RED oder HA-Automationen. Manuelles Topic-Mapping mit Payload-Transformation (Plain/JSON/Array, Faktor, Offset, Invertierung), Hot-Reload, Topic-Test direkt in der UI. Neuer Bereich auf der MQTT-Inbound-Seite.
Connector → MQTT Bridge (Stufe 0): Konfigurierte Geräte-Connectors publishen automatisch Live-Leistungswerte (Watt) auf MQTT-Inbound-Topics. Connector-Daten fließen jetzt ins Live-Dashboard und den Energiefluss. Unterstützt: Shelly 3EM, OpenDTU, Fronius, sonnenBatterie, go-eCharger.
Energiefluss Lite-Modus: Reduzierte Animationen für HA Companion App (Android WebView). Auto-Detect für Mobile/Companion + manueller Toggle auf der Live-Page. Schaltet Blur-Filter, 3D-Grid, Partikel und Glow-Effekte ab.

Behoben

MQTT-Topics Parität: 7 fehlende MQTT-Live-Topics ergänzt die im HA-Sensor-Pfad bereits funktionierten (pv_gesamt_w, netz_kombi_w, SFML-Sensoren, WP-Heizen/Warmwasser/Temperatur). Wichtig für HA-User mit MariaDB/PostgreSQL die MQTT als Fallback nutzen.

[3.4.2] - 2026-03-22

Behoben

BKW-Erzeugung in Gesamt-PV aufgenommen (#37): Balkonkraftwerk-Erzeugung fließt jetzt in die PV-Gesamterzeugung ein. Autarkie, Eigenverbrauch, Prognose-Vergleich und Community-Benchmark werden für BKW-only Nutzer korrekt berechnet. BKW bleibt zusätzlich als separater Komponenten-Wert sichtbar.
Daten-Checker: BKW-only kein Fehler mehr (#37): Nutzer mit Balkonkraftwerk ohne PV-Module sehen jetzt einen Info-Hinweis statt einer Fehlermeldung.
SFML Genauigkeits-Sensor nicht auswählbar (#38): Sensoren mit Einheit % wurden vom Filter blockiert. Placeholder-Texte auf die realen SFML-Sensornamen aktualisiert.

[3.4.1] - 2026-03-22

Hinzugefügt

Prognose-Vergleich (ML Phase 2): Neuer Vergleichsblock auf der Prognose-vs-IST-Seite — EEDC-Forecast vs. ML-Forecast vs. IST mit Abweichung in %, Balkendiagramm und Detailtabelle mit “Bessere Prognose”-Indikator. Nur sichtbar wenn SFML-Daten vorhanden.
SFML Morgen-Vorschau: Neuer Sensor sfml_tomorrow_kwh in der Sensorzuordnung. Zeigt “Morgen ~XX kWh ML” als KPI im Wetter-Widget.
SFML-Tagesprognosen persistiert: ML-Prognosen werden in TagesZusammenfassung gespeichert für langfristigen Vergleich.

[3.4.0] - 2026-03-22

Hinzugefügt

Solar Forecast ML Integration: Optionale Anbindung von Solar Forecast ML (SFML) im Wetter-Widget. Zeigt ML-basierte PV-Prognose als lila KPI (~XX kWh ML) und gepunktete lila Chart-Linie neben der EEDC-Prognose. Konfiguration über Sensor-Zuordnung → Live-Sensoren → Solar Forecast ML. Rein optional — ohne SFML ändert sich nichts.

Verbessert

Dokumentation aktualisiert: Versionsnummern auf v3.3 in 16 Dokumentationsdateien, Architektur-Doku mit neuen Hooks und Shared Components ergänzt.
docs/ aufgeräumt: Abgeschlossene Pläne archiviert, CSV-Testdaten verschoben, doppelte Screenshots bereinigt.

[3.3.6] - 2026-03-22

Verbessert

Frontend-Refactoring Phase 7 abgeschlossen: Alle 27 Seiten auf gemeinsame Hooks (useSelectedAnlage, useApiData) und Komponenten (DataLoadingState, PageHeader) migriert. Ca. 300 Zeilen dupliziertes Boilerplate entfernt. Konsistente Anlage-Selektion mit localStorage-Persistierung über alle Seiten.

[3.3.5] - 2026-03-22

Hinzugefügt

Community-Reset-Hinweis: Banner auf der Community-Seite informiert Nutzer, dass die Community-Daten durch einen Server-Vorfall am 22.03.2026 verloren gegangen sind und bittet um erneutes Teilen. Der Hinweis kann geschlossen werden und erscheint dann nicht mehr.

Hinweis

Durch eine fehlerhafte Server-Wartung wurden alle Community-Benchmark-Daten gelöscht. Der Community-Server läuft wieder — bitte teile deine Anlagendaten erneut unter Community → Daten teilen, damit der Benchmark wieder aufgebaut werden kann. Wir entschuldigen uns für die Unannehmlichkeiten.

[3.3.1] - 2026-03-20

Behoben

WP-Symbolwechsel im Energiefluss: Das Icon der Wärmepumpe wechselt jetzt korrekt zwischen Heizkörper (Heizmodus) und Tropfen (Warmwasser). Bisher wurde der Symbolwechsel nur bei aktivierter „getrennter Strommessung” geprüft. Jetzt werden die optionalen Felder „Leistung Heizen” und „Leistung Warmwasser” immer im Sensor-Mapping angeboten und der dominante Betriebsmodus (höherer Wert) bestimmt das Icon.

[3.3.0] - 2026-03-20

Hinzugefügt

GTI-basierte PV-Prognose im Live-Dashboard: Die PV-Ertragsprognose im WetterWidget nutzt jetzt Global Tilted Irradiance (GTI) statt horizontaler Globalstrahlung (GHI). Open-Meteo liefert die Strahlung direkt auf der geneigten Modulfläche — Azimut und Neigung aus den PV-Modul-Investitionen fließen automatisch ein.
Multi-String-Prognose: Bei Anlagen mit unterschiedlich ausgerichteten Modulen (z.B. Ost/West) werden separate GTI-Werte parallel abgerufen und kWp-gewichtet kombiniert. Das ergibt eine realistischere, breitere Tageskurve statt einer überhöhten Mittagsspitze.
Lernfaktor: Täglicher IST/Prognose-Vergleich aus den letzten 30 Tagen wird als Korrekturfaktor angewendet. Kompensiert systematische Abweichungen (Verschattung, Modulalterung, lokale Besonderheiten). Median-basiert für Robustheit gegen Ausreißer, aktiviert sich nach 7 Tagen mit Daten.
Temperaturkorrektur: PV-Ertragsprognose berücksichtigt jetzt die Modultemperatur (Lufttemperatur + strahlungsabhängige Aufheizung, -0.4%/°C über 25°C STC).

Behoben

Frontend-Version im HA Add-on: Release-Script führt jetzt npm run build vor dem Commit durch, damit der dist/-Ordner immer die korrekte Version enthält.

[3.2.2] - 2026-03-20

Behoben

Tooltip-Farben im Dark Mode (#31): Chart-Tooltips zeigten seit v3.1.9 keine farbigen Serieneinträge mehr und hatten im Dark Mode teilweise hellen Hintergrund. Neue zentrale ChartTooltip-Komponente mit Tailwind-basiertem Dark Mode ersetzt die fehleranfälligen CSS-Variablen. Alle 35 Recharts-Tooltips (Bar, Line, Area, Pie/Donut) einheitlich formatiert.
Pie/Donut-Labels im Dark Mode: Label-Texte an Pie-Charts, Achsenbeschriftungen und Legenden sind im Dark Mode jetzt lesbar.

Geändert

Benutzerhandbuch aufgeteilt (#32): Monolithisches Handbuch (1.661 Zeilen) in drei Teile gesplittet — Installation, Bedienung, Einstellungen — plus separates Glossar. Website-Navigation angepasst.

[3.2.1] - 2026-03-19

Hinzugefügt

Italien als Standort-Land (#30): IT im Land-Dropdown mit automatischem USt-Satz 22%. Italienische PLZ (CAP) korrekt unterstützt, Community-Vergleich mit Länderkennung IT.
Dynamisches WP-Icon im Live Dashboard: Das Wärmepumpen-Icon wechselt je nach Betriebsmodus (Heizen/Warmwasser/Kühlen).

Behoben

Docker-Build im Standalone-Repo: run.sh fehlte im eedc-Repo, da sie nicht vom Release-Script synchronisiert wurde. Das Release-Script kopiert run.sh jetzt automatisch mit.

[3.2.0] - 2026-03-19

Hinzugefügt

Getrennte WP-Strommessung (#29): Optionale separate Erfassung von Strom-Heizen und Strom-Warmwasser für Wärmepumpen. Ermöglicht getrennte COP-Berechnung pro Komponente (COP Heizung vs. COP Warmwasser). Neue Checkbox “Getrennte Strommessung” in den Investitions-Parametern. Auswirkung auf Monatserfassung, Sensor-Mapping, Monatsabschluss, WP-Dashboard, CSV Import/Export, Live-Dashboard und HA Statistics.
Getrennte Live-Leistungssensoren: Bei aktivierter getrennter Strommessung können separate Leistungssensoren für Heizen und Warmwasser zugeordnet werden. Diese erscheinen als zwei separate Knoten im Energiefluss-Diagramm und als eigene Serien im Tagesverlauf.

Danke an MartyBr für den Vorschlag!

[3.1.9] - 2026-03-18

Hinzugefügt

Per-Komponenten Tages-kWh: Stündliche Leistungswerte pro Komponente (WP, Wallbox, E-Auto, PV-Strings, Speicher) werden jetzt automatisch zu Tages-kWh aufgerollt und in der Tageszusammenfassung persistiert. Grundlage für künftige Tages-/Wochen-Auswertungen pro Komponente.
MQTT Energy History für Investitionen: Investitions-spezifische Energy-Keys (inv/{id}/{key}) werden jetzt in der Delta-Berechnung berücksichtigt — auch im Standalone-MQTT-Modus werden per-Komponenten-Tages-kWh erfasst.
API-Endpoint Tages-Energieprofil: Neuer Endpoint GET /api/energie-profil/{id}/tage?von=...&bis=... liefert Tageszusammenfassungen mit Per-Komponenten-kWh.

Behoben

Tooltip-Lesbarkeit in Dark/Light Mode (#27): Alle Recharts-Tooltips nutzen jetzt einheitlich CSS-Variablen statt hardcodierter Farben. Globale CSS-Fallback-Regeln als Sicherheitsnetz.

[3.1.8] - 2026-03-17

Hinzugefügt

PV Gesamt Live-Sensor (#25): Neues optionales Feld pv_gesamt_w unter Basis → Live im Sensor-Mapping Wizard. Für Wechselrichter die nur einen Gesamt-PV-Sensor liefern (z.B. E3DC) — wird als ein “PV Gesamt”-Knoten im Energiefluss, Tagesverlauf und Heute-kWh angezeigt. Individuelle PV-String-Sensoren werden bevorzugt falls vorhanden.
Datenbestand Energieprofile: Neue Sektion in System → Allgemein zeigt den Bestand der aggregierten Profildaten mit Abdeckungs-Fortschrittsbalken und Wachstumsprognose

[3.1.7] - 2026-03-17

Behoben

Automatische Einheiten-Konvertierung (#25): HA-Sensoren mit suggested_unit_of_measurement (z.B. E3DC: nativ W, angezeigt als kW) werden jetzt automatisch erkannt und korrekt zu W konvertiert. Betrifft Live-Daten, Tagesverlauf, Tages-kWh und Energieprofil. Keine manuellen kW→W Template-Helper mehr nötig.

[3.1.6] - 2026-03-17

Behoben

Sensor-Mapping: Anlage-Auswahl (#26): Bei mehreren Anlagen konnte bisher nur die erste Anlage im Sensor-Mapping Wizard konfiguriert werden. Jetzt erscheint ein Dropdown zur Anlage-Auswahl.
Netz-Anzeige Ampel-Schema: Farbgebung der Netz-Anzeige überarbeitet — Grün = Balance (±100 W), Rot = Netzbezug, Amber = Einspeisung. Kein Balken mehr in der Pufferzone.
Grundlast-Berechnung: Median der Nachtstunden (0–5 Uhr) statt Durchschnitt aller Stunden — robust gegen Ausreißer an der PV-Übergangsstunde.
Energiefluss: „Energieumsatz” statt redundanter Quelle/Senke-Anzeige unter dem Haus-Symbol.
Wetter-Timeline: Stunden-Icons jetzt horizontal mit der Chart-X-Achse ausgerichtet (24h-Grid über dem Chart statt separater Timeline).
Wallbox-Icon: Eigenes Plug-Icon für Wallbox (war identisch mit E-Auto).
Legende ohne Phantome: PV-Chart-Legende zeigt nur Kategorien mit tatsächlichen Werten (keine Wallbox/Sonstige bei 0).

[3.1.4] - 2026-03-17

Hinzugefügt

Gestapelter Verbrauch im PV-Chart: Verbrauch im Wetter-Chart wird nach Kategorien aufgeschlüsselt (Haushalt, Speicher-Ladung, Wallbox, Wärmepumpe, Sonstige) statt einer Gesamtlinie. Chart-Höhe verdoppelt (280px). Legende zeigt nur vorhandene Kategorien.
Netz-Pufferzone: Gelbe ±100 W Zone in der Netz-Anzeige reduziert visuelles Flackern bei Werten nahe 0
Datenbestand Energieprofile: Neue Sektion in System → Allgemein zeigt den Bestand der aggregierten Profildaten

Behoben

Verbrauch-Prognose durchgängig: Gestrichelte Verbrauchs-Prognose-Linie wird jetzt auch für vergangene Stunden angezeigt (IST/Prognose-Vergleich). Kein Sprung mehr an der “Jetzt”-Linie.
Stacking-Fix: 0-Werte in gestapelten Verbrauchskategorien bleiben als 0 statt null — Recharts stackt korrekt
Netz-Pufferzone Vollausschlag: Gelbe Zone war bei kleinem Gauge-Range viel zu breit (Vollausschlag). Jetzt visuell auf max 8% pro Seite begrenzt.
Grundlast 0 W: Stunden ohne HA-History-Daten wurden als 0 kW ins individuelle Verbrauchsprofil geschrieben. Jetzt werden fehlende Stunden übersprungen (BDEW-Fallback greift).
Quellen-Indikatoren: Farbige Punkte an den Balkennamen im Energie-Bilanz-Chart (AktuellerMonat) statt irreführender Pseudo-Legende
MariaDB-Hinweis: Info-Box in Settings warnt dass HA-Statistik nur mit SQLite funktioniert, MQTT-Inbound als Alternative

Dokumentation

Energieprofil-Pipeline in ARCHITEKTUR.md, BERECHNUNGEN.md, BENUTZERHANDBUCH.md, DEVELOPMENT.md dokumentiert
Alle Dokumentationen auf v3.1 aktualisiert, veraltete NEU-Marker entfernt
README.md (Root + Standalone), Flyer auf v3.1 aktualisiert

[3.1.1] - 2026-03-16

Behoben

Verbrauch 0,00 kWh bei hoher PV: Haushalt-Residual im Tagesverlauf wurde aus gerundeten Werten berechnet — akkumulierte Rundungsfehler (±0.005/Serie) konnten den Verbrauch auf 0 drücken. Jetzt aus ungerundeten Rohwerten berechnet.
Verbrauch IST im Wetter-Chart: Berechnung von Butterfly-Senken-Summierung auf Energiebilanz (PV + Netzbezug − Einspeisung) umgestellt — funktioniert unabhängig vom Haushalt-Residual.

[3.1.0] - 2026-03-16

Hinzugefügt

Wetter-Chart IST/Prognose-Split: PV-Ertrag vs. Verbrauch zeigt jetzt IST-Daten (solide Linien) für vergangene Stunden und Prognose (gestrichelt) für die Zukunft. Volle 24h-Achse, PV-Prognose auch rückwirkend sichtbar zum Vergleich mit tatsächlicher Erzeugung.
Energieprofil-Datenbasis: Neue persistente Datensammlung als Grundlage für zukünftige Speicher-Dimensionierungsanalyse:
- Stündliches Energieprofil (24 Werte/Tag) mit Per-Komponenten-Aufschlüsselung, Wetter-IST, Batterie-SoC
- Tägliche Zusammenfassung: Über-/Unterdeckung (kWh), Spitzenleistungen, Batterie-Vollzyklen, Performance Ratio
- Automatische tägliche Aggregation (Scheduler, 00:15)
- Nachberechnung beim Monatsabschluss (Backfill + Rollup)
Monatsdaten erweitert: Neue Felder ueberschuss_kwh, defizit_kwh, batterie_vollzyklen, performance_ratio, peak_netzbezug_kw
Tagesverlauf historisch: tage_zurueck Parameter ermöglicht Abruf vergangener Tage

Behoben

Batterie-Vorzeichen im Tagesverlauf: Bidirektionale Serien (Batterie) hatten invertierte Vorzeichen — Entladung wurde als Senke statt Quelle dargestellt, Haushalt-Residual war dadurch zu hoch
Verbrauch IST im Wetter-Chart: Exkludiert jetzt korrekt Batterie-Ladung und Netz-Einspeisung (keine echten Verbraucher)

[3.0.9] - 2026-03-16

Hinzugefügt

HA Automation Generator: Integrierter Wizard in der MQTT-Inbound-Seite — HA-Sensoren den EEDC-Topics zuordnen und zwei fertige YAML-Automationen (Live + Energy) zum Kopieren erhalten. Anlage-Auswahl, konfigurierbares Intervall (5s/10s/30s/60s), automatische YAML-Generierung.
Andere Systeme: Beispiel-Flows für Node-RED, ioBroker, FHEM, openHAB in eigenem Bereich

Geändert

Beispiel-Flows aufgeteilt: HA-Nutzer nutzen den neuen Generator, andere Systeme haben einen separaten Bereich

[3.0.8] - 2026-03-15

Hinzugefügt

Live Sidebar-Redesign: Zustandswerte-Bereich komplett neu gestaltet
- „Heute”-Karten: PV-Erzeugung, Eigenverbrauch, Einspeisung, Netzbezug (farbcodiert, kWh)
- Autarkie- und Eigenverbrauchsquote als berechnete Prozentwerte
- PV- und Verbrauchs-Prognose direkt in der Sidebar
- SoC-Gauges nur noch für Batterie/E-Auto (statt alle Gauges)
- Netz: horizontaler Balken mit 0-Mitte (grün=Einspeisung, rot=Bezug)
- Gestern-Vergleich als Tooltip auf jeder Karte
MQTT-Beispiel-Flows personalisiert: Topic-Auswahl-Dropdown mit allen konfigurierten Topics, kontextbezogene Sensor-Platzhalter, retain: true in allen Snippets

Verbessert

Energiefluss ~10% kompakter: Alle Skalierungsstufen verkleinert für bessere FHD-Darstellung
Energiefluss dynamische Skalierung: 3 Stufen (≤3, 4, 5+ Komponenten) mit angepassten Boxen/Fonts
Sidebar füllt SVG-Höhe: flex justify-between verteilt Elemente optimal

Behoben

Haushalt-Residual: parent_key statt eauto_ Prefix für korrekte Zuordnung
E-Auto Position: Rechts neben Wallbox im Energiefluss statt separate Zeile
Heute-kWh Tooltips: Pro Komponente im Energiefluss

[3.0.5] - 2026-03-15

Behoben

Energiefluss: Wallbox/E-Auto Key-Kollision: Wallbox und E-Auto hatten beide den Key-Prefix eauto_, wodurch die parent_key-Zuordnung fehlschlug. Wallbox hat jetzt eigenen Prefix wallbox_
Energiefluss: SVG-Höhe dynamisch: ViewBox passt sich an Kind-Knoten an statt fixer Höhe

[3.0.4] - 2026-03-15

Behoben

Energiefluss: E-Auto/Wallbox Doppelzählung: E-Auto-Ladeleistung wurde separat zur Wallbox-Leistung in Σ Verbrauch gezählt, obwohl beides denselben Energiefluss misst
Energiefluss: E-Auto → Wallbox Verbindung: E-Auto verbindet sich jetzt mit der Wallbox statt direkt mit dem Haus (physisch korrekt: Haus → Wallbox → E-Auto)

[3.0.3] - 2026-03-15

Hinzugefügt

Energiefluss-Diagramm: Neues animiertes SVG-Diagramm im Live Dashboard ersetzt die Energiebilanz-Balken
- Alle Investitionen als Knoten um zentrales Haus-Symbol
- Animierte Flusslinien zeigen Energierichtung und -stärke
- SoC-Pegelanzeige für Speicher und E-Auto (farbcodiert: rot/gelb/grün)
- Logarithmische Liniendicke, Tooltips mit Tages-kWh

Behoben

Zeitzone: datetime.utcnow() durch datetime.now() ersetzt — HA Add-on zeigte Uhrzeiten mit 1h Offset

[3.0.2] - 2026-03-15

Behoben

run.sh: Fehlendes Anführungszeichen in Version-Echo repariert (sed-Pattern fraß das ")
Release-Script: sed-Pattern auf [0-9][0-9.]* eingeschränkt, damit nachfolgende Zeichen erhalten bleiben

[3.0.1] - 2026-03-15

Behoben

Release-Infrastruktur: Dockerfile io.hass.version Label wird jetzt automatisch gebumpt (war seit v0.9.0 hartcodiert)
Release-Script: sed-Bug behoben (überflüssiges Anführungszeichen beim run.sh-Bump)
GitHub Release Workflow: eedc-homeassistant erstellt jetzt automatisch ein GitHub Release bei Tag-Push (fehlte komplett)

[3.0.0] - 2026-03-15

Hinzugefügt

Live Dashboard – Neuer Top-Level-Tab mit Echtzeit-Leistungsdaten (kW), 5-Sekunden Auto-Refresh
- Energiebilanz-Tabelle mit gespiegelten Balken (Erzeugung links, Verbrauch rechts)
- Gauge-Charts für SoC (Batterie, E-Auto), Netz-Richtung, Autarkie
- Tagesverlauf-Chart (24h PV/Verbrauch/Netz/Speicher)
- Wetter-Widget mit Stunden-Prognose und PV/Verbrauch-Vorhersage
- Heute/Gestern kWh-Tagessummen (aus HA-History oder MQTT-Snapshots)
- Demo-Modus für Erstnutzer ohne konfigurierte Sensoren
MQTT-Inbound – Universelle Datenbrücke für jedes Smarthome-System
- Vordefinierte MQTT-Topic-Struktur für Live-Daten (W) und Monatswerte (kWh)
- In-Memory-Cache mit Auto-Reconnect und Retained Messages
- Einrichtungs-UI mit Monitor, Topic-Dokumentation und Beispiel-Flows (HA, Node-RED, ioBroker, FHEM, openHAB)
- Copy-to-Clipboard für alle Topics und Code-Snippets
MQTT Energy → Monatsabschluss – MQTT-Daten als 6. Datenquelle im Monatsabschluss-Wizard
- Konfidenz 91% (zwischen Connector 90% und HA Statistics 92%)
- Energy-Topic-Generierung für alle Investitionstypen (PV, Speicher, WP, E-Auto, Wallbox, BKW)
- Status-Chip im Wizard-Header, Datenherkunft-Tracking
MQTT Energy Mini-History – SQLite-basierte Snapshot-Historie für Standalone-MQTT-Nutzer
- Automatische Snapshots alle 5 Minuten via APScheduler
- Tages-Delta-Berechnung (Mitternacht-Differenzen, Monatswechsel-Handling)
- 31 Tage Retention mit täglichem Cleanup
- Fallback-Kette: HA-History → MQTT-Snapshots → leer
Live-Sensor-Zuordnung – Wiederverwendbare Sensor-Konfiguration pro Investitionstyp im Mapping-Wizard
- Vordefinierte Leistungs-Felder (W) pro Typ (PV, Speicher, WP, E-Auto, Wallbox, BKW)
- SensorAutocomplete mit device_class: power Filter
HA Export: Investitions-Sensoren – E-Auto (km, kWh/100km, PV-Anteil, Ersparnis vs. Benzin) und WP (COP, Ersparnis vs. alte Heizung) Sensoren aus InvestitionMonatsdaten

Behoben

PDF-Report: WP-Ersparnis – Berechnet jetzt vs. Gas/Öl aus Investitionsparametern (war 0)
PDF-Report: E-Mob-Ersparnis – Berechnet jetzt vs. Benzin aus Investitionsparametern (war 0)
Live Dashboard: Haushalt-Berechnung – Korrekte Berechnung als Residualwert
Live Dashboard: Wechselrichter-Skip – Investitionen vom Typ „Wechselrichter” werden ausgefiltert
Live Dashboard: Negative Verbraucher-kW – abs() für Sensoren die negative Standby-Werte melden
MQTT Port-Validierung – Nicht-numerischer Port gibt 400 statt 500
Initialer MQTT-Snapshot – Fehlender Logger-Import behoben (NameError wurde still geschluckt)

[2.9.1] - 2026-03-13

Geändert

HA Statistics statt MQTT MWD – Monatsdaten für „Aktueller Monat” und Monatsabschluss werden jetzt direkt aus der HA Recorder-Statistik-DB gelesen (MAX−MIN). Die fehleranfälligen MWD-MQTT-Sensorpaare (number.*_mwd_*_start / sensor.*_mwd_*_monat) wurden komplett entfernt.
MQTT nur noch für Export – MQTT wird nur noch zum Exportieren von EEDC-KPIs nach HA verwendet, nicht mehr zum Lesen von Monatsdaten.
Sensor-Zuordnung vereinfacht – Init-Startwerte-Dialog nach dem Speichern entfällt, mqtt_setup_complete-Flag entfernt.
Scheduler – Monatswechsel-Job ist jetzt nur noch ein Zeitstempel-Marker, kein MQTT-Rollover mehr.

Hinzugefügt

Einrichtung: HA Sensor-Zuordnung – Neue Karte auf der Einrichtungs-Seite verlinkt direkt zur Sensor-Zuordnung.
Typabhängige Aggregation – Investitions-Felder (PV, Speicher, E-Auto, Wallbox, WP, BKW) werden automatisch in die Top-Level-Felder des Aktueller-Monat-Dashboards aggregiert.
HA-Statistik Quellen-Badge – Aktueller Monat und Monatsabschluss zeigen „HA-Statistik” als Datenquelle an.

Behoben

Strompreis-Sensor – get_ha_state_service() wurde im Monatsabschluss nicht instanziiert (AttributeError bei dynamischem Tarif).
Speicher vs. Wallbox – Wallbox-Ladung wurde fälschlich in speicher_ladung_kwh summiert statt in emob_ladung_kwh.

[2.9.0] - 2026-03-12

Hinzugefügt

Aktueller-Monat-Dashboard – Neues Cockpit-Sub-Tab zeigt den laufenden Monat mit Daten aus HA-Sensoren (95%), Connectors (90%) und gespeicherten Monatsdaten (85%). Enthält Energie-Bilanz-Charts, Komponenten-Karten, Finanz-Übersicht, Vorjahresvergleich und SOLL/IST-Vergleich.
Anlage-Selektor – Cockpit-Übersicht und Aktueller Monat zeigen jetzt einen Anlage-Selektor wenn mehrere Anlagen vorhanden sind
Datenquellen-Badges – Farbige Indikatoren zeigen pro Feld die Herkunft (HA-Sensor, Connector, Gespeichert)
Leerer-Zustand-Aktionen – Wenn keine Daten vorliegen, werden konkrete Import-Möglichkeiten (Monatsabschluss, Connector, Cloud-Import, Portal-Import) als Aktionskarten angeboten
Live-Dashboard Plan – Architekturplan für Stufe 2 (Echtzeit-Leistungsdaten kW) dokumentiert

[2.8.5] - 2026-03-11

Behoben

MQTT: object_id Deprecation – object_id im MQTT Discovery Payload durch default_entity_id ersetzt (HA 2026.4 Kompatibilität)

[2.8.4] - 2026-03-10

Behoben

CSV-Export: Fehlende BKW-Erzeugung – Balkonkraftwerk-Erzeugung wurde unter falschem Feldnamen gespeichert, daher im Export leer (Issue #22)
CSV-Export: Dezimaltrennzeichen – Punkt statt Komma für deutsche Locale, jetzt korrekt mit Semikolon-Trennung und Dezimalkomma
CSV-Export: UTF-8 BOM – Für korrekte Zeichenkodierung in Excel/LibreOffice
Monatsdaten-Formular: 0-Werte – Wert 0 wurde als leer interpretiert und nicht gespeichert (betraf alle Investitionstypen)
Aussichten-Finanzen: EV-Quote – Eigenverbrauchsquote wird jetzt direkt aus historischen Daten berechnet statt synthetisch zerlegt (Issue #21)

[2.8.3] - 2026-03-09

Hinzugefügt

Daten-Checker – Neue Datenqualitäts-Prüfung unter Einstellungen → Daten
- 5 Prüfkategorien: Stammdaten, Strompreise, Investitionen, Monatsdaten-Vollständigkeit/-Plausibilität
- PVGIS-basierte PV-Produktionsprüfung mit dynamischer Performance Ratio
- Erkennt zu hohe PVGIS-Systemverluste anhand der tatsächlichen Anlagenperformance
- KPI-Karten, Fortschrittsbalken für Monatsabdeckung, klappbare Kategorien
- „Beheben”-Links verweisen direkt zum betroffenen Monatsabschluss
Protokolle – Aktivitäts-Logging unter Einstellungen → System
- Protokollierung von Monatsabschluss, Connector-Abruf, Cloud-Fetch, Portal-Import
- Live-Filter nach Kategorie und Zeitraum
- In-Memory Log-Buffer + DB-Persistierung

[2.8.1] - 2026-03-07

Behoben

Custom-Import: DATEN-Navigationsleiste fehlte auf der Custom-Import-Seite

[2.8.0] - 2026-03-07

Hinzugefügt

5 neue Cloud-Import-Provider – Historische Monatsdaten direkt aus der Cloud abrufen
- SolarEdge – Monitoring API mit API-Key, monatliche Energiedetails (*)
- Fronius SolarWeb – SolarWeb API mit AccessKey, Monatsaggregation (*)
- Huawei FusionSolar – thirdData API mit XSRF-Token, KPI-Monatswerte (*)
- Growatt – OpenAPI mit MD5-Auth, Monats-Ertragsdaten (*)
- Deye/Solarman – SolarMAN OpenAPI mit OAuth2 + SHA256, historische Monatsdaten (*)
Eigene Datei importieren (Custom-Import) – Neuer Wizard für beliebige CSV/JSON-Dateien
- Automatische Spalten-Erkennung mit Beispielwerten
- Flexibles Feld-Mapping per Dropdown (Spalte → EEDC-Feld)
- Auto-Detect für Spaltenbezeichnungen (deutsch + englisch)
- Einheit wählbar (Wh/kWh/MWh) mit automatischer Umrechnung
- Dezimalzeichen konfigurierbar (Auto/Punkt/Komma)
- Kombinierte Datumsspalte (z.B. “2024-01”) oder separate Jahr/Monat-Spalten
- Mapping als wiederverwendbares Template speichern/laden
- 4-Schritt-Wizard: Upload → Mapping → Vorschau → Import
- Neue Kachel “Eigene Datei importieren” auf der Einrichtung-Seite

Entfernt

Kostal Plenticore und SMA Local Cloud-Import-Provider entfernt (liefern nur aktuelle Zählerstände, keine historischen Monatsdaten – für diese Geräte die Geräte-Connectors verwenden)

(*) Ungetestet – basiert auf Hersteller-API-Dokumentation

[2.7.1] - 2026-03-06

Verbessert

Einstellungen-Menü überarbeitet – Logische Gruppierung mit 5 Kategorien, Solarprognose zu Stammdaten verschoben
Daten-SubTabs vereinfacht – Statt 8 Tabs nur noch 3: Monatsdaten, Monatsabschluss, Einrichtung
Neue Einrichtung-Seite – Hub mit 4 Karten für alle Datenquellen-Setups (Connector, Portal-Import, Cloud-Import, CSV/JSON)
Monatsabschluss Quick-Icon – CalendarCheck-Button mit rotem Badge in der Hauptnavigation (Desktop + Mobile)
Monatsabschluss-Wizard als zentrale Anlaufstelle – Quellen-Status-Chips zeigen konfigurierte Datenquellen, neuer “Cloud-Daten abrufen” Button, Hinweis auf Einrichtung wenn keine Quellen konfiguriert, Datenherkunft-Anzeige bei vorhandenen Import-Daten

Behoben

Investition-Felder im Monatsabschluss zeigen jetzt die tatsächliche Datenquelle statt immer “manuell”
CompleteStep: HashRouter-Navigation korrigiert (window.location.hash statt .href)

Hinzugefügt

Backend-Endpoint POST /monatsabschluss/{id}/{j}/{m}/cloud-fetch für Einzelmonat-Abruf aus Cloud-API

[2.7.0] - 2026-03-06

Hinzugefügt

Cloud-Import – Historische Energiedaten direkt aus Hersteller-Cloud-APIs importieren
- Generische Cloud-Import-Provider-Architektur (ABC + Registry, analog zu Portal-Import)
- EcoFlow PowerOcean als erster Provider (Developer API mit HMAC-SHA256 Auth) (*)
- 4-Schritt-Wizard: Verbinden → Zeitraum → Vorschau → Import
- Credentials pro Anlage speicherbar für wiederholte Imports
- Wiederverwendung des bestehenden Apply-Mechanismus (Portal-Import)
- Datenquelle-Tracking: cloud_import als neue Quelle neben portal_import
Exakte Azimut-Eingabe – PV-Module können jetzt gradgenau ausgerichtet werden (nicht nur 45°-Schritte)
- Neues Eingabefeld “Azimut (°)” synchronisiert mit dem bestehenden Dropdown
- Alle PVGIS-Berechnungen nutzen den exakten Wert

(*) Ungetestet – basiert auf Hersteller-API-Dokumentation, indexName-Mapping muss mit echten Daten verifiziert werden

[2.6.0] - 2026-03-05

Hinzugefügt

Portal-Import (CSV-Upload) – Automatische Erkennung und Import von PV-Portal-Exporten
- SMA Sunny Portal (PV-Ertrag, Netz, Batterie)
- SMA eCharger (Wallbox-Ladevorgänge)
- EVCC (Wallbox-Sessions mit PV-Anteil)
- Fronius Solarweb (PV-Ertrag, Eigenverbrauch)
9 Geräte-Connectors – Direkte Datenabfrage von Wechselrichtern und Smart-Home-Geräten
- SMA ennexOS (Tripower X, Wallbox EVC)
- SMA WebConnect (Sunny Boy, Tripower SE)
- Fronius Solar API (Symo, Primo, Gen24)
- go-eCharger (Gemini/HOME v3+)
- Shelly 3EM (Netz-Monitoring)
- OpenDTU (Hoymiles/TSUN Mikro-Wechselrichter)
- Kostal Plenticore (Plenticore plus, PIKO IQ)
- sonnenBatterie (eco/10 performance)
- Tasmota SML (Smart Meter via IR-Lesekopf)
getestet-Flag – Parser und Connectors zeigen im UI an ob mit echten Geräten verifiziert
Dynamischer Tarif: Monatlicher Durchschnittspreis – Neues optionales Feld netzbezug_durchschnittspreis_cent auf Monatsdaten
- Wird nur bei dynamischen Tarifen (Tibber, aWATTar) abgefragt
- Alle Finanzberechnungen nutzen den Monatsdurchschnitt statt des fixen Stammdatenpreises
- Fallback-Kette: Monats-Durchschnittspreis → Fixer Tarif aus Stammdaten
- Gewichteter Durchschnittspreis (nach kWh) bei Jahresaggregation im Cockpit
Arbitrage-Fallback – speicher_ladepreis_cent → netzbezug_durchschnittspreis_cent → Stammdaten-Tarif
CSV-Template/Export/Import – Bedingte Spalte Durchschnittspreis_Cent bei dynamischem Tarif
JSON-Export/Import – Neues Feld in Export-Schema
MonatsdatenForm – Bedingtes Eingabefeld “Ø Strompreis (dynamisch)” bei dynamischem Tarif
Monatsabschluss-Wizard – Bedingtes Feld mit HA-Sensor-Vorschlag bei dynamischem Tarif
HA-Sensormapping – Neues Basis-Feld strompreis für direktes Sensor-Lesen (kein MWD-Paar)
- Sensor-Filter erweitert um monetary device_class und Preis-Einheiten (EUR/kWh, ct/kWh)

[2.5.5] - 2026-03-03

Hinzugefügt

Hamburger-Menu auf Mobile (#18): Navigation auf schmalen Displays (< 768px) über ausklappbares Menü statt horizontaler Tab-Leiste
Energie-Bilanz Perspektiv-Toggle (#19): Umschaltung zwischen Erzeugungs- und Verbrauchsperspektive im Energie-Chart, optionale Autarkie-Linie

Behoben

Mobile Tab-Overflow: Tab-Navigationen auf Auswertung, Aussichten und HA-Export liefen auf schmalen Displays über den Rand – jetzt horizontal scrollbar

[2.5.4] - 2026-03-03

Hinzugefügt

WP Monatsvergleich – Toggle zwischen Stromverbrauch und COP: Im Wärmepumpe-Dashboard kann jetzt zwischen Stromverbrauch- und COP-Ansicht umgeschaltet werden

Behoben

PVGIS Monatswerte Export: list statt dict erlauben bei der Serialisierung
Bessere Fehlerbehandlung im JSON-Export Endpoint: Robustere Serialisierung
Backup im Einstellungen-Dropdown ergänzt: Menüeintrag war nicht sichtbar

[2.5.3] - 2026-03-02

Hinzugefügt

WP Dashboard – COP Monatsvergleich über Jahre: Vergleich der COP-Werte über mehrere Betriebsjahre

Behoben

Fehlende Felder im Monatsabschluss-Wizard ergänzt
HA-Statistik Feldnamen-Mapping für Monatsabschluss korrigiert
Degradation: Positive Degradationswerte werden gekappt, Warnung bei < 3 Jahren Betriebsdauer

[2.5.2] - 2026-03-01

Hinzugefügt

Backup & Restore Seite im System-Menü: Neue dedizierte Seite für Datensicherung

Behoben

JSON Export/Import auf Vollständigkeit gebracht (v1.2)
Demo-Daten Route scrollt zur Demo-Sektion
HA-Mapping Hinweis nur bei verfügbarem Home Assistant anzeigen
PVGIS Horizont-Abruf: API-Key “horizon” → “horizon_profile”

[2.5.1] - 2026-03-01

Geändert

Dokumentation und Website aktualisiert

[2.5.0] - 2026-03-01

Hinzugefügt

PVGIS Horizontprofil-Support für genauere Ertragsprognosen
- Automatisches Geländeprofil (DEM) bei allen PVGIS-Abfragen aktiv (usehorizon=1)
- Eigenes Horizontprofil hochladen (PVGIS-Textformat) oder automatisch von PVGIS abrufen
- Horizont-Card in PVGIS-Einstellungen mit Status, Statistik und Upload/Abruf
- Badge “Eigenes Profil” / “DEM” bei gespeicherten Prognosen
- Horizontprofil im JSON-Export/Import enthalten
GitHub Releases & Update-Hinweis (Standalone)
- Automatische GitHub Releases mit Docker-Image auf ghcr.io bei Tag-Push
- Update-Banner im Frontend wenn neuere Version verfügbar
- Deployment-spezifische Update-Anleitung (Docker, HA Add-on, Git)
Social-Media-Textvorlage (#16)
- Kopierfertige Monatsübersicht für Social-Media-Posts
- Zwei Varianten: Kompakt (Twitter/X) und Ausführlich (Facebook/Foren)
- Bedingte Blöcke je nach Anlagenkomponenten (Speicher, E-Auto, Wärmepumpe)
- PVGIS-Prognose-Vergleich, CO₂-Einsparung, Netto-Ertrag
- Share-Button im Dashboard-Header mit Modal, Monat/Jahr-Auswahl und Clipboard-Kopie

Behoben

Community-Vorschau zeigte falsche Ausrichtung und Neigung: Werte wurden aus leerem Parameter-JSON gelesen statt aus Modelfeldern

[2.4.1] - 2026-02-26

Technisch

Version-Bump: v2.4.0 wurde force-pushed und war für HA Add-on-Store nicht als Update erkennbar

[2.4.0] - 2026-02-26

Hinzugefügt

Kleinunternehmerregelung / Steuerliche Behandlung (Issue #9)
- Neues Feld steuerliche_behandlung auf der Anlage: „Keine USt-Auswirkung” (Standard) oder „Regelbesteuerung”
- Bei Regelbesteuerung: USt auf Eigenverbrauch (unentgeltliche Wertabgabe §3 Abs. 1b UStG) wird als Kostenfaktor berechnet
- Bemessungsgrundlage: Selbstkosten (Abschreibung/20J + Betriebskosten / Jahresertrag)
- Editierbarer USt-Satz mit länderspezifischen Defaults (DE: 19%, AT: 20%, CH: 8.1%)
- Auto-Vorschlag des USt-Satzes bei Land-Wechsel
- Dashboard: Neue KPI-Karte „USt Eigenverbrauch” (nur bei Regelbesteuerung sichtbar)
- Netto-Ertrag-Berechnung im Cockpit, Aussichten und ROI-Dashboard berücksichtigt USt
- Hinweis im Setup-Wizard: Steuerliche Einstellungen unter Anlage bearbeiten konfigurierbar
Spezialtarife für Wärmepumpe & Wallbox (Issue #8)
- Neues Feld verwendung auf Strompreisen: „Standard”, „Wärmepumpe” oder „Wallbox”
- Neuer API-Endpoint /api/strompreise/aktuell/{anlage_id}/{verwendung} mit Fallback auf Standard-Tarif
- Cockpit-Berechnung nutzt automatisch den günstigsten zutreffenden Tarif pro Komponente
- Strompreise-Seite: Sortierung (aktuell + Standard zuerst), Verwendungs-Badges, Info-Box für aktive Spezialtarife
- Tarif-Formular: Neues Dropdown „Tarif-Verwendung” mit kontextabhängigem Hinweis
Sonstige Positionen bei Investitionen (Issue #7)
- Neuer Investitionstyp „Sonstiges” mit Kategorien: Erzeuger, Verbraucher, Speicher
- Flexible Monatsdaten-Erfassung je nach Kategorie (Erzeugung/Verbrauch/Ladung-Entladung)
- Sonstige Erträge & Ausgaben pro Monat (Versicherung, Wartung, Einspeisebonus, etc.)
- Integration in Dashboard: Finanzen-Tab zeigt sonstige Erträge/Ausgaben
- Demo-Daten: Beispiel „Notstrom-Batterie” als sonstiger Speicher
Firmenwagen & dienstliches Laden – korrekte ROI-Berechnung
- Neues Flag ist_dienstlich an Wallbox und E-Auto (in Investitions-Parametern)
- Wallbox (dienstlich): ROI = AG-Erstattung minus (Netzbezug × Strompreis + PV-Anteil × Einspeisevergütung); kein Benzinvergleich
- E-Auto (dienstlich): Kraftstoffersparnis geht an Arbeitgeber → emob_ersparnis = 0; Ladekosten als Ausgaben; AG-Erstattung als sonstiger Ertrag
- Hinweistext im Investitionsformular bei aktiviertem Flag (Erklärung + Tipp für gemischte Nutzung)
- DatenerfassungGuide: neuer Abschnitt „Firmenwagen & dienstliches Laden” mit Empfehlung separater Zähler
Realisierungsquote KPI in Auswertung → Investitionen
- Neues Panel „Tatsächlich realisiert” vergleicht historische Erträge mit konfigurierter Prognose
- Realisierungsquote in % mit Farbkodierung: ≥ 90 % grün, ≥ 70 % gelb, < 70 % rot
- Zeigt die Diskrepanz zwischen parametriertem Potenzial (z.B. 15.000 km/Jahr E-Auto) und tatsächlicher Nutzung
Methodenhinweise in Dashboard und Komponenten-Dashboards
- Amortisationsbalken im Cockpit: Hinweis „Basis: tatsächlich realisierte Erträge & Kosten (Ø X €/Jahr über N Monate)”
- E-Auto-, Wärmepumpe-, Balkonkraftwerk-Dashboard: Methodennotiz unter den KPIs (Basis: Monatsdaten)
Grundpreis in Netzbezugskosten-Berechnung
- Monatlicher Stromgrundpreis wird zu Netzbezugskosten addiert (calculations.py, Auswertung/Zeitreihen)
Monatsabschluss-Wizard Erweiterungen
- Balkonkraftwerk: Speicher-Ladung/Entladung für BKW-Modelle mit integriertem Speicher erfassbar
- Typ „Sonstiges”: kategorie-spezifische Felder (Erzeuger / Verbraucher / Speicher)
- API-Response liefert sonstige_positionen für alle Investitionstypen (nicht nur „Sonstiges”)
- Neue shared Component SonstigePositionenFields für strukturierte Ertrags-/Ausgaben-Erfassung
SubTabs group-aware Navigation
- Tab-Gruppen mit visueller Trennung für bessere Übersichtlichkeit bei vielen Tabs
DatenerfassungGuide überarbeitet
- Modernere Struktur und Erklärungen; neuer Abschnitt Firmenwagen; Legacy-Guide aufklappbar

Behoben

Leeres Installationsdatum verursachte Setup-Wizard-Fehler (Issue #10): StrompreiseStep akzeptiert jetzt fehlende Installationsdaten und setzt vernünftige Defaults
sonstige_positionen wurde nur für Investitionstyp „Sonstiges” verarbeitet: Jetzt werden Erträge/Ausgaben aus sonstige_positionen für ALLE Investitionstypen in Cockpit und Amortisationsprognose berücksichtigt (z.B. Wartungskosten bei Wärmepumpe, THG-Quote bei E-Auto)
BKW Ersparnis und sonstige Netto-Beträge fehlten in Amortisationsprognose (Aussichten → Finanzen): bisherige_ertraege und jahres_netto_ertrag waren unvollständig

Technisch

DB-Migration: Neue Spalten steuerliche_behandlung, ust_satz_prozent (Anlage), verwendung (Strompreis) – automatisch beim Start
Neue Berechnungsfunktion berechne_ust_eigenverbrauch() in calculations.py
Neue Helper-Funktion berechne_sonstige_summen() für sonstige Erträge/Ausgaben
JSON Export/Import: Steuerliche Felder und Strompreis-Verwendung werden mit exportiert/importiert
CSV Import: Sonstige Positionen werden korrekt verarbeitet
CockpitUebersicht API-Response: neue Felder bkw_ersparnis_euro, sonstige_netto_euro

[2.3.2] - 2026-02-24

Behoben

SOLL-Werte im PV-String-Vergleich waren zu hoch – drei Ursachen behoben:
1. Ost-West-Anlagen: Ausrichtung ost-west wurde bisher als Süd (Azimut 0°) an PVGIS übergeben, was ~20–25 % zu hohe SOLL-Werte lieferte. Jetzt werden zwei separate PVGIS-Abfragen durchgeführt (je 50 % kWp auf Ost −90° und West +90°) und die Ergebnisse summiert.
2. Proportionale kWp-Verteilung: Der gespeicherte PVGIS-Gesamtwert wurde bisher anteilig nach kWp auf die einzelnen Strings verteilt – ohne Rücksicht auf unterschiedliche Ausrichtungen. Jetzt werden pro Modul die exakten PVGIS-Werte gespeichert (module_monatswerte) und direkt genutzt.
3. Teil-Jahre / laufendes Jahr (Auswertungen → PV-Anlage): SOLL enthielt bisher alle 12 Monate eines Jahres, auch wenn IST-Daten nur für einen Teil des Jahres vorlagen (z.B. Anlage ab Mai, oder laufendes Jahr mit Jan–Feb). Jetzt wird SOLL nur für Monate gezählt, für die auch IST-Daten erfasst sind.

Technisch

PVGISPrognose-Modell: Neue Felder gesamt_leistung_kwp und module_monatswerte (JSON)
DB-Migration läuft automatisch beim Start
Wichtig: Nach dem Update einmalig die PVGIS-Prognose unter Einstellungen → PVGIS neu abrufen und speichern, um die korrekten per-Modul-Werte zu erhalten

[2.3.1] - 2026-02-24

Behoben

Docker Build-Fehler behoben: package-lock.json synchronisiert – picomatch Versionskonflikt (2.3.1 → 4.0.3) verhinderte npm ci im HA Add-on Build

[2.3.0] - 2026-02-24

Hinzugefügt

Dashboard-Modernisierung (6 neue Features)
- Hero-Leiste: 3 Top-KPIs (Autarkie, Spez. Ertrag, Netto-Ertrag) mit Jahres-Trend-Pfeilen (▲/▼/—) im Vergleich zum Vorjahr
- Energie-Fluss-Diagramm: Gestapelte Balkendiagramme visualisieren PV-Verteilung (Direktverbrauch, Speicher, Einspeisung) und Haus-Versorgungsquellen (PV direkt, Speicher, Netzbezug)
- Ring-Gauges: SVG-Ringdiagramme für Autarkie- und Eigenverbrauchsquote ersetzen die bisherigen Zahlenkarten
- Sparkline: Monatliche PV-Erträge als kompaktes Balkendiagramm im Energie-Bilanz-Bereich
- Amortisations-Fortschrittsbalken: Zeigt wie viel % der Investition bereits zurückgeflossen sind inkl. geschätztem Amortisationsjahr (nur in Gesamtansicht)
- Community-Teaser: Hinweiskarte mit Link zur Community-Seite (nur sichtbar wenn Daten bereits geteilt wurden)
DACH-Onboarding vorbereitet
- Neues Feld standort_land (DE/AT/CH) im Anlage-Modell
- Land-Dropdown im Anlage-Formular (Deutschland, Österreich, Schweiz)
- Community-Regionszuordnung: AT/CH direkt zugeordnet (keine PLZ-Auflösung nötig)
- JSON-Export/Import berücksichtigt standort_land

Geändert

Sparkline zeigt Gesamtzeitraum: Ohne Jahresfilter werden alle verfügbaren Monate gezeigt (konsistent mit dem Rest des Dashboards), Label zeigt z.B. „2023–2025”

[2.2.0] - 2026-02-22

Hinzugefügt

Choropleth Deutschlandkarte im Regional Tab
- Interaktive Bundesländer-Karte mit Farbverlauf nach spezifischem Ertrag (kWh/kWp)
- Eigenes Bundesland durch blauen Rahmen hervorgehoben
- Hover-Tooltip mit allen Performance-Details je Bundesland
Performance-Metriken im Regionalen Vergleich
- Tabelle und Tooltip zeigen jetzt messbare Leistungsdaten statt Ausstattungsquoten
- 🔋 Speicher: Ø Ladung ↑ / Entladung ↓ kWh pro Monat (getrennt)
- ♨️ Ø berechnete JAZ (Σ Wärme ÷ Σ Strom, saisonaler Wert)
  
  ⚠ Nachträglich richtiggestellt (September 2026): Diese Zahl heißt nicht mehr „JAZ”, sondern „Wärme je kWh Strom”. Sie summiert die Wärme aller Anlagen einer Region und teilt sie durch deren Strom — Zähler und Nenner stammen also aus verschiedenen Geräten, eine Arbeitszahl je Anlage ist das nicht. Damals fiel es nicht auf, weil es die zweite, anlagenbezogene Zahl unter Komponenten → Wärmepumpe noch nicht gab; erst nebeneinander widersprachen sich die beiden sichtbar.
- 🚗 Ø km/Monat + Ø kWh zuhause geladen (gesamt − extern)
- 🔌 Ø kWh/Monat + Ø PV-Anteil in % (wo von Wallbox messbar)
- 🪟 Ø BKW-Ertrag kWh/Monat
Community Server: Regionale Performance-Aggregate
- /api/statistics/regional liefert jetzt Performance-Durchschnitte pro Bundesland
- Alle Metriken nur über Anlagen mit dem jeweiligen Gerät und validen Messwerten

Technisch

TypeScript Import-Casing-Fix (macOS case-insensitive Filesystem)
.nvmrc mit Node 20 (passend zu Docker node:20-alpine)
Lokale Entwicklungsumgebung: Python 3.11 venv, VS Code tasks.json/launch.json
Lokale Testdatenbank unter eedc/data/eedc.db

[2.1.0] - 2026-02-21

Hinzugefügt

Community als eigenständiger Hauptmenüpunkt
- Community jetzt auf Augenhöhe mit Cockpit, Auswertungen und Aussichten
- Eigener Navigationsbereich statt Tab in Auswertungen
- 6-Tab-Struktur: Übersicht, PV-Ertrag, Komponenten, Regional, Trends, Statistiken
Übersicht Tab
- Gamification: 7 Achievements (Autarkiemeister, Effizienzwunder, Solarprofi, Grüner Fahrer, Wärmekönig, Ertragswunder, Speichermeister)
- Fortschrittsanzeige für nicht erreichte Achievements
- Radar-Chart: Eigene Performance vs. Community auf 6 Achsen
- Rang-Badges: Top 10%, Top 25%, Top 50%
- KPI-Tooltips: Erklärungen für Community-Kennzahlen (Spez. Ertrag, JAZ, etc.)
PV-Ertrag Tab
- Perzentil-Anzeige: “Du bist besser als X% der Community”
- Abweichungs-KPIs: vs. Community und vs. Region
- Monatlicher Ertrag Chart: Mit echten monatlichen Community-Durchschnitten (statt Jahresdurchschnitt/12)
- Jahresübersicht: Tabelle mit Abweichungen pro Jahr
- Verteilungs-Histogramm: Eigene Position in der Community-Verteilung
Komponenten Tab
- Speicher Deep-Dive: Wirkungsgrad, Zyklen, PV-Anteil mit Community-Vergleich
- Wärmepumpe Deep-Dive: JAZ-Vergleich nach Region, mit Hinweis bei weniger als 3 Anlagen
- E-Auto Deep-Dive: PV-Anteil, Ladequellen-Chart (PV/Netz/Extern)
- Wallbox Deep-Dive: Ladung und PV-Anteil
- Balkonkraftwerk Deep-Dive: Spezifischer Ertrag und Eigenverbrauchsquote
- Zeitraum-Hinweis: Betrachtungszeitraum wird konsistent angezeigt
Regional Tab
- Regionale Position: Rang im Bundesland
- Vergleichs-Chart: Du / Region / Community als Balken
- Regionale Einordnung: Anlagen-Details im Kontext
Trends Tab
- Ertragsverlauf: Area-Chart über alle Monate
- Saisonale Performance: Frühling/Sommer/Herbst/Winter mit Icons
- Jahresvergleich: Letztes vs. Vorletztes Jahr mit Veränderung
- Typischer Monatsverlauf: Durchschnitt pro Monat über alle Jahre
- Community-Entwicklung: Speicher-/WP-/E-Auto-Quoten über Zeit
- Degradations-Analyse: Ertrag nach Anlagenalter
Statistiken Tab
- Community-Zusammenfassung: Übersicht über alle Teilnehmer
- Position in Community: Rang und Perzentil
- Ausstattungs-Übersicht: Komponenten-Verteilung
Backend-Erweiterungen
- Proxy-Endpoints: Alle Community-Server-Endpoints durchgereicht
- /api/community/statistics/global - Globale Statistiken
- /api/community/statistics/monthly-averages - Monatliche Durchschnitte
- /api/community/statistics/regional - Regionale Statistiken
- /api/community/statistics/distributions/{metric} - Verteilungsdaten
- /api/community/statistics/rankings/{category} - Top-Listen
- /api/community/components/* - Komponenten-Statistiken
- /api/community/trends/* - Trend-Daten und Degradation

Behoben

FastAPI Route-Ordering: /api/community/trends/degradation wurde fälschlich von /api/community/trends/{period} gematcht
TypeScript-Typen: Server-Feldnamen (durchschnitt_zyklen statt avg_zyklen) korrekt gemappt
Chronologische Sortierung: Monatsdaten in PV-Ertrag und Trends Charts werden jetzt korrekt sortiert (älteste links, neueste rechts)
Monatliche Durchschnitte: Community-Vergleich verwendet echte monatliche Werte statt Jahresdurchschnitt/12

Geändert

Auswertungen: Community-Tab entfernt (jetzt eigenständiger Menüpunkt)
Navigation: Hauptmenü erweitert um Community-Eintrag
Tooltips: Aussichten-Tabs und Community-Seite haben jetzt erklärende Tooltips

[2.0.3] - 2026-02-20

Hinzugefügt

Community-Vergleich Tab in Auswertungen
- Neuer “Community” Tab erscheint nach Teilen der Anlagendaten
- Zeitraum-Auswahl: Letzter Monat, Letzte 12 Monate, Letztes vollständiges Jahr, Seit Installation
- PV-Benchmark: Spezifischer Ertrag im Vergleich zu Community und Region
- Rang-Anzeige: Position gesamt und regional
- Komponenten-Benchmarks: Speicher (Zyklen, Wirkungsgrad), Wärmepumpe (JAZ), E-Auto (PV-Anteil)
- Monatlicher Ertrag Chart: Visualisierung der letzten 12 Monate
- Zugangslogik: Tab nur sichtbar wenn community_hash gesetzt (Daten geteilt)
Backend: Community-Benchmark Proxy
- Neuer Endpoint GET /api/community/benchmark/{anlage_id}
- Proxy zum Community-Server (/api/benchmark/anlage/{anlage_hash})
- Gibt 403 zurück wenn Anlage nicht geteilt (Fairness-Prinzip: Erst teilen, dann vergleichen)
- Unterstützt Zeitraum-Filter: letzter_monat, letzte_12_monate, letztes_vollstaendiges_jahr, jahr, seit_installation

Geändert

Community-Seite (energy.raunet.eu) vereinfacht
- Entfernt: Zeitraum-Auswahl (immer Jahresertrag)
- Entfernt: Komponenten-Benchmarks (jetzt im Add-on)
- Hinzugefügt: Hinweis-Box mit Verweis auf EEDC Add-on für Details
- Titel geändert: “Dein Anlagen-Benchmark” (statt “Dein PV-Anlagen Benchmark”)
Frontend-Types erweitert
- community_hash Feld zum Anlage Interface hinzugefügt
- Erweiterte TypeScript-Interfaces für Benchmark-Daten

[2.0.2] - 2026-02-19

Hinzugefügt

CSV-Import: Automatische Legacy-Migration
- Alte CSV-Dateien mit PV_Erzeugung_kWh, Batterie_Ladung_kWh, Batterie_Entladung_kWh werden automatisch migriert
- PV-Erzeugung wird proportional nach kWp auf alle PV-Module verteilt
- Batterie-Werte werden proportional nach Kapazität auf alle Speicher verteilt
- Warnung wird angezeigt, wenn Legacy-Werte migriert wurden
- Behebt Import-Fehler bei älteren Backup-Dateien

Behoben

Auswertung/Energie KPIs zeigten falsche Werte
- Problem: PV-Erzeugung zeigte 0.3 MWh statt tatsächlicher Werte
- Ursache: useMonatsdatenStats verwendete Legacy-Feld Monatsdaten.pv_erzeugung_kwh
- Fix: Neue Hooks useAggregierteDaten und useAggregierteStats nutzen aggregierte Daten aus InvestitionMonatsdaten
- Betroffen: Alle KPIs in Auswertung → Energie Tab
PrognoseVsIst nutzte Legacy-Felder
- Fix: Verwendet jetzt /api/monatsdaten/aggregiert Endpoint
- Korrekte PV-Erzeugungswerte für SOLL-IST Vergleich
Swagger UI “Try it out” funktioniert jetzt im HA Ingress
- Problem: 404-Fehler beim Testen von API-Endpoints in Swagger UI
- Ursache: Swagger verwendete falsche Base-URL im Ingress-Proxy
- Fix: Dynamische Base-URL-Berechnung aus aktueller Browser-URL

[2.0.1] - 2026-02-19

Hinzugefügt

Selektiver Feld-Import im HA-Statistik Wizard
- Import-Modi: Schnellauswahl zwischen “Alles importieren”, “Nur Basis” (Einspeisung/Netzbezug), “Nur Komponenten”
- Granulare Feld-Checkboxen: Jedes Feld kann einzeln an-/abgewählt werden
- Modus wechselt automatisch zu “Manuell” bei individueller Anpassung
- Ermöglicht z.B. manuell korrigierte Einspeisung beizubehalten, aber PV-Werte zu importieren
Komponenten-Vergleich im HA-Statistik Import Wizard
- Zeigt nun alle InvestitionMonatsdaten (PV, Speicher, E-Auto, etc.) im Vergleich
- Vorhanden vs. HA-Statistik mit Differenz-Berechnung
- Gelbe Hervorhebung bei Abweichungen ≥1
- Konflikt-Erkennung berücksichtigt jetzt auch Komponenten-Werte
Erweiterte Sensor-Mapping Felder
- E-Auto: Verbrauch gesamt (kWh), Ladung extern (kWh)
- Wallbox: Ladevorgänge (Anzahl)
- Balkonkraftwerk: Neuer Wizard-Step mit PV-Erzeugung, Eigenverbrauch, Speicher-Ladung/-Entladung

Behoben

Sensor-Filter erlaubt Zähler ohne Einheit - Sensoren wie evcc_charging_sessions mit state_class: measurement aber ohne unit_of_measurement werden jetzt korrekt angezeigt

[2.0.0] - 2026-02-18

⚠️ BREAKING CHANGE - Neuinstallation erforderlich!

Diese Version benötigt Lesezugriff auf /config für die HA-Statistik-Funktion. Das Volume-Mapping wurde geändert - eine einfache Aktualisierung reicht nicht!

Vor dem Update:

JSON-Export aller Anlagen erstellen (Anlagen-Seite → Download-Icon ⬇️ bei jeder Anlage)
Export-Datei sichern!

Update durchführen:

Add-on stoppen
Add-on deinstallieren (⚠️ Daten werden gelöscht!)
Repository aktualisieren (Add-ons → ⋮ → Nach Updates suchen)
Add-on neu installieren
Add-on starten
JSON-Import durchführen

Hinzugefügt

HA-Statistik-Abfrage - Direkte Abfrage der Home Assistant Langzeitstatistiken
- Neuer Service ha_statistics_service.py für SQLite-Zugriff auf /config/home-assistant_v2.db
- API-Endpoints unter /api/ha-statistics/:
  - GET /status - Prüft ob HA-Datenbank verfügbar ist
  - GET /monatswerte/{anlage_id}/{jahr}/{monat} - Monatswerte für einen Monat
  - GET /verfuegbare-monate/{anlage_id} - Alle Monate mit Daten
  - GET /alle-monatswerte/{anlage_id} - Bulk-Abfrage aller historischen Monatswerte
  - GET /monatsanfang/{anlage_id}/{jahr}/{monat} - Zählerstände für MQTT-Startwerte
- Nutzt die sensor_mapping Zuordnungen um HA-Sensoren auf EEDC-Felder zu mappen
- Ermöglicht rückwirkende Befüllung aller Monatsdaten seit Installationsdatum
HA-Statistik Import mit Überschreib-Schutz
- GET /api/ha-statistics/import-vorschau/{anlage_id} - Vorschau mit Konflikt-Erkennung
- POST /api/ha-statistics/import/{anlage_id} - Import mit intelligenter Logik:
  - Neue Monate werden importiert
  - Leere Monatsdaten werden befüllt
  - Vorhandene Daten werden nicht überschrieben (außer explizit gewünscht)
  - Konflikte werden erkannt und angezeigt
Frontend: HA-Statistik Import UI
- Neue Seite: Einstellungen → Home Assistant → Statistik-Import
- Bulk-Import aller historischen Monatswerte
- Vorschau mit farbcodierter Konflikt-Erkennung
- Option zum Überschreiben vorhandener Daten
Monatsabschluss-Wizard: HA-Werte laden
- Neuer Button “Werte aus HA-Statistik laden”
- Lädt Monatswerte direkt aus der HA-Langzeitstatistik
- Nur sichtbar wenn Sensor-Mapping konfiguriert ist
Sensor-Mapping: Startwerte aus HA-DB
- Nach Speichern: Option “Aus HA-Statistik laden (empfohlen)”
- Verwendet gespeicherte Zählerstände vom Monatsanfang
- Fallback: Aktuelle Sensorwerte verwenden

Geändert

Volume-Mapping erweitert: config:ro für Lesezugriff auf HA-Datenbank

Behoben

Sensor-Mapping UI - Importierte Sensoren werden jetzt angezeigt auch wenn HA nicht verfügbar
- Zeigt sensor_id mit Hinweis “(nicht verfügbar)” wenn Sensor nicht in lokaler Liste
PVGIS MultipleResultsFound - 500-Fehler wenn mehrere aktive PVGIS-Prognosen existierten
- Query mit .order_by().limit(1) abgesichert in pvgis.py, cockpit.py, aussichten.py, solar_prognose.py
SensorMappingWizard Startwerte laden - “Cannot convert undefined or null to object” Fehler
- Interface-Feldnamen korrigiert (startwerte statt werte) und Null-Safety hinzugefügt
HAStatistikImport “NaN Monate importieren” - Frontend-Interface an Backend-Feldnamen angepasst
- anzahl_monate, anzahl_importieren, anzahl_konflikte, anzahl_ueberspringen korrekt gemappt
HAStatistikImport: Individuelle Monatsauswahl - Checkbox pro Monat statt globaler Überschreiben-Option
- Benutzer können gezielt einzelne Monate zum Import auswählen
Monatsdaten: “Aus HA laden” Button - Direktes Laden einzelner Monate aus HA-Statistik
- Modal zur Auswahl von Monat/Jahr aus verfügbaren HA-Statistik-Monaten
- Bei existierenden Monaten: Vergleichs-Modal mit Diff-Anzeige vor dem Überschreiben
- Farbcodierte Hervorhebung signifikanter Unterschiede (>10%)
HA-Statistik Investitions-Bezeichnungen - Zeigt nun “BYD HVS 12.8 (speicher)” statt ”()”
- Backend lädt Investitions-Metadaten aus DB für korrektes Label
JSON-Import sensor_mapping - Investitions-Mappings werden beim Import zurückgesetzt
- IDs ändern sich beim Import, daher muss Sensor-Mapping neu konfiguriert werden
- Warnung wird angezeigt mit Hinweis auf Neukonfiguration
Sensor-Mapping Wizard: Löschen-Button - Mapping kann nun über Button im Header gelöscht werden
- Bestätigungsdialog vor dem Löschen
Komponenten-Vergleich in “Aus HA laden” - Zeigt nun Vorhanden vs. HA-Statistik Tabelle für alle Investitionen
- Differenz-Berechnung wie bei Basis-Werten (Einspeisung, Netzbezug)
- Zeigt auch Investitionen die nur in Bestandsdaten existieren (ohne HA-Mapping)

[1.1.0-beta.8] - 2026-02-18

(Übersprungen - direkt zu 2.0.0 wegen Breaking Change)

[1.1.0-beta.7] - 2026-02-18

Behoben

JSON-Export Version 1.1 Bug - Export-Version war fälschlicherweise auf “1.0” hardcoded
- In beta.5 wurde das Pydantic-Model auf 1.1 aktualisiert, aber der Code der das Export-Objekt erstellt übergab explizit “1.0”
- Dadurch wurde beim Import die Warnung “sensor_mapping nicht enthalten” angezeigt, obwohl es vorhanden war
- Export gibt jetzt korrekt export_version: "1.1" aus

[1.1.0-beta.6] - 2026-02-18

Geändert

Cockpit PV-Anlage komplett überarbeitet - zeigt jetzt Gesamtlaufzeit statt einzelne Jahre
- Neuer API-Endpoint /api/cockpit/pv-strings-gesamtlaufzeit für aggregierte Daten
- SOLL vs IST pro Jahr: Balkendiagramm zeigt für jedes Jahr SOLL und IST pro String
- Saisonaler Vergleich: Jan-Dez Durchschnitt vs PVGIS-Prognose als Linien/Flächen-Chart
- Gesamtlaufzeit-Tabelle: Performance-Statistik pro String über alle Jahre
- Keine Jahr-Auswahl mehr nötig - konsistent mit Cockpit-Philosophie “Gesamtlaufzeit”

Behoben

Dashboard Race Condition - “Fehler beim Laden der Daten” erschien manchmal nach F5
- loading State wird jetzt mit true initialisiert
- Cockpit-Tabs sind wieder statisch (dynamische Tabs verursachten Race Conditions)

[1.1.0-beta.5] - 2026-02-18

Hinzugefügt

JSON-Export erweitert für vollständiges Backup/Restore (Export-Version 1.1)
- sensor_mapping - HA Sensor-Zuordnungen werden jetzt exportiert/importiert
- durchschnittstemperatur - Wetterdaten in Monatsdaten
- sonderkosten_euro / sonderkosten_beschreibung - Manuelle Sonderkosten
- Rückwärtskompatibel: Export-Version 1.0 wird weiterhin importiert

Geändert

Monatsdaten-Formular verbessert:
- PV-Erzeugung ist jetzt readonly wenn PV-Module mit Werten vorhanden sind (Summe wird automatisch berechnet)
- Sonnenstunden akzeptiert jetzt Dezimalwerte (step=0.1 statt step=1) - behebt Validierungsfehler bei Auto-Fill

Hinweis

Beim Import von Anlagen mit Sensor-Mapping:

Die Zuordnungen werden übernommen, aber mqtt_setup_complete wird auf false gesetzt
Nach dem Import muss das Sensor-Mapping erneut gespeichert werden, um die MQTT-Entities zu erstellen
Grund: Die Investitions-IDs ändern sich beim Import

[1.1.0-beta.4] - 2026-02-18

Behoben

MQTT Entity-IDs sind jetzt eindeutig durch object_id im Discovery-Payload
- Entity-IDs enthalten jetzt den Key: number.eedc_winterborn_mwd_inv1_ladung_kwh_start
- Vorher wurde die Entity-ID aus dem Namen generiert, was zu _2 Suffixen führte
- Friendly Names bleiben lesbar mit Investitionsnamen

Hinweis

Nach dem Update: MQTT Discovery Topics löschen (homeassistant/number/eedc_* und homeassistant/sensor/eedc_*), dann Sensor-Mapping erneut speichern.

[1.1.0-beta.3] - 2026-02-18

Behoben

MQTT Entity-Namen enthalten jetzt den Investitionsnamen
- Vorher: Doppelte Entities wenn Speicher und Wallbox beide ladung_kwh haben
- Jetzt: “EEDC BYD HVS 12.8 Ladung Monatsanfang” statt “EEDC Speicher Ladung Monatsanfang”
- Eindeutige Namen für jede Investition, keine _2 Suffixe mehr in HA

Hinweis

Nach dem Update: EEDC-Gerät in Home Assistant löschen und Sensor-Mapping erneut speichern, damit die neuen Entity-Namen erstellt werden.

[1.1.0-beta.2] - 2026-02-17

Behoben

Datenbank-Migration für neue Monatsdaten-Felder hinzugefügt
- durchschnittstemperatur (FLOAT)
- sonderkosten_euro (FLOAT)
- sonderkosten_beschreibung (VARCHAR)
- notizen (VARCHAR)
- Behebt SQLite-Fehler “no such column: monatsdaten.durchschnittstemperatur” nach Update

[1.1.0-beta.1] - 2026-02-17

Hinzugefügt

Sensor-Mapping-Wizard - Zuordnung von Home Assistant Sensoren zu EEDC-Feldern
- Intuitive Wizard-Oberfläche mit dynamischen Steps
- Unterstützte Schätzungsstrategien:
  - sensor - Direkter HA-Sensor
  - kwp_verteilung - Anteilig nach kWp (für PV-Module ohne eigenen Sensor)
  - cop_berechnung - COP × Stromverbrauch (für Wärmepumpen)
  - ev_quote - Nach Eigenverbrauchsquote (für E-Auto)
  - manuell - Eingabe im Monatsabschluss-Wizard
- Speicherung in neuem Anlage.sensor_mapping JSON-Feld
- Navigation: Einstellungen → Home Assistant → Sensor-Zuordnung
MQTT Auto-Discovery für Monatswerte
- EEDC erstellt automatisch MQTT-Entities in Home Assistant:
  - number.eedc_{anlage}_mwd_{feld}_start - Zählerstand vom Monatsanfang
  - sensor.eedc_{anlage}_mwd_{feld}_monat - Berechneter Monatswert via value_template
- Keine YAML-Bearbeitung oder HA-Neustart nötig
- Retained Messages für Persistenz
Monatsabschluss-Wizard - Geführte monatliche Dateneingabe
- Intelligente Vorschläge aus verschiedenen Quellen:
  - Vormonat (80% Konfidenz)
  - Vorjahr gleicher Monat (70% Konfidenz)
  - COP-Berechnung für Wärmepumpen (60% Konfidenz)
  - Durchschnitt letzte 12 Monate (50% Konfidenz)
- Plausibilitätsprüfungen mit Warnungen:
  - Negativwerte bei Zählern
  - Große Abweichungen vs. Vorjahr (±50%)
  - Ungewöhnlich niedrige/hohe Werte
- Dynamische Steps basierend auf Investitionstypen
- Navigation: Einstellungen → Daten → Monatsabschluss
Scheduler für Cron-Jobs
- APScheduler-Integration für periodische Tasks
- Monatswechsel-Snapshot: Am 1. jeden Monats um 00:01
- Status-Endpoint: GET /api/scheduler
- Manueller Trigger: POST /api/scheduler/monthly-snapshot
Neue API-Endpoints
- /api/sensor-mapping/{anlage_id} - CRUD für Sensor-Zuordnung
- /api/sensor-mapping/{anlage_id}/available-sensors - Verfügbare HA-Sensoren
- /api/monatsabschluss/{anlage_id}/{jahr}/{monat} - Status und Vorschläge
- /api/monatsabschluss/naechster/{anlage_id} - Nächster offener Monat
- /api/scheduler - Scheduler-Status
Neue Backend-Services
- ha_mqtt_sync.py - MQTT Synchronisations-Service
- scheduler.py - Cron-Job Management
- vorschlag_service.py - Intelligente Vorschläge

Geändert

mqtt_client.py erweitert um:
- publish_number_discovery() - Erstellt number-Entities
- publish_calculated_sensor() - Erstellt Sensoren mit value_template
- update_month_start_value() - Aktualisiert Monatsanfang-Werte
- publish_monatsdaten() - Publiziert finale Monatsdaten
Navigation erweitert:
- “Sensor-Zuordnung” unter Einstellungen → Home Assistant
- “Monatsabschluss” unter Einstellungen → Daten

Technisch

Neue Dependency: apscheduler>=3.10.0 für Cron-Jobs
DB-Migration: Neue Spalte sensor_mapping (JSON) in anlagen Tabelle
Scheduler startet automatisch mit dem Backend

[1.0.0-beta.13] - 2026-02-17

Hinzugefügt

Logo/Icon Integration
- Neues eedc-Logo und Icon durchgängig eingebunden
- HA Add-on: icon.png (512x512) und logo.png für Add-on Store
- Frontend: Neues Favicon, Icon + “eedc” Text in TopNavigation
- Setup-Wizard: eedc-Icon im Header
- PDF-Export: eedc-Icon in der Kopfzeile (ab Seite 2)
- README: Logo zentriert am Anfang
Entwickler-Tools
- scripts/kill-dev.sh: Beendet alle Entwicklungs-Prozesse und gibt Ports frei
- Prüft Ports 8099 (Backend), 5173-5176 (Frontend), 3000-3009 (Tests)

Geändert

HA-Integration Bereinigung (Phase 0)
- ha_integration.py: Von 2037 auf 171 LOC reduziert (-92%)
- Auto-Discovery komplett entfernt (ineffektiv, ~10% Erkennungsrate)
- Discovery-UI Komponenten entfernt
- ha_sensor_* Felder auf Anlage als DEPRECATED markiert
PDF-Export
- HA-Integration Abschnitt wird nur angezeigt wenn Sensoren konfiguriert sind
- Icon statt Text “eedc” in Kopfzeile
Demo-Daten
- ha_sensor_* Beispielwerte entfernt (waren irreführend)

Entfernt

Backend Services
- ha_yaml_generator.py (18 LOC Placeholder)
- ha_websocket.py (261 LOC, unzuverlässig)
Backend Models
- StringMonatsdaten (redundant mit InvestitionMonatsdaten.verbrauch_daten)
Frontend Komponenten
- components/discovery/* (DeviceCard, DiscoveryDialog, SensorMappingPanel, etc.)
- hooks/useDiscovery.ts
- setup-wizard/steps/DiscoveryStep.tsx
- setup-wizard/steps/SensorConfigStep.tsx
API Endpoints (aus ha_integration.py)
- /ha/discover - Auto-Discovery
- /ha/statistics/* - Long-Term Statistics
- /ha/string-monatsdaten/* - StringMonatsdaten CRUD
- Diverse Discovery-bezogene Endpoints

[1.0.0-beta.12] - 2026-02-16

Hinzugefügt

PDF-Export: Vollständige Anlagen-Dokumentation
- Neuer PDF-Export-Button auf der Anlagen-Seite (orangefarbenes Dokument-Icon)
- Gesamtzeitraum als Standard: Ohne Jahr-Parameter werden alle Jahre exportiert
- Vollständige Stammdaten: Alle Komponenten mit Hersteller, Modell, Seriennummer, Garantie
- Ansprechpartner & Wartung: Service-Kontakte und Wartungsverträge pro Komponente
- Versorger-Daten: Stromversorger, Kundennummern, Zähler mit Zählpunkten
- Home Assistant Sensoren: Konfigurierte Sensor-Mappings
PDF-Layout & Design
- Kopfzeile (ab Seite 2): Anlagenname | “EEDC Anlagenbericht [Zeitraum]” | eedc-Logo
- Fußzeile (alle Seiten): Erstellungsdatum | GitHub-Repository | “Seite X von Y”
- Farbschema: Darkblue-Hintergrund für Kapitel, Orangered für Unterüberschriften
- Wiederholende Tabellenköpfe: Bei Seitenumbrüchen werden Spaltenüberschriften wiederholt
PDF-Inhalte
- Jahresübersicht mit allen KPIs (Energie, Autarkie, Finanzen, CO2)
- Drei Diagramme: PV-Erzeugung (Balken + PVGIS-Linie), Energie-Fluss (gestapelt), Autarkie-Verlauf
- Monatstabellen: Energie, Speicher, Wärmepumpe, E-Mobilität, Finanzen
- PV-String Vergleich: SOLL (PVGIS) vs. IST mit Abweichung
- Finanz-Prognose & Amortisations-Fortschritt
Erweiterte Demo-Daten
- Alle Investitionen mit vollständigen Stammdaten (Hersteller, Seriennummer, Garantie)
- Ansprechpartner für Wechselrichter, E-Auto, Wärmepumpe
- Wartungsverträge für Wechselrichter und Wärmepumpe
- Versorger-Daten mit Zählernummern und Zählpunkten
- Home Assistant Sensor-Mappings

Geändert

PDF-Button verschoben: Von Auswertung zu Anlagen-Seite (bei Stammdaten)
API-Endpoint /api/import/pdf/{anlage_id}: jahr-Parameter ist jetzt optional

[1.0.0-beta.11] - 2026-02-16

Hinzugefügt

Setup-Wizard komplett überarbeitet
- Standalone-First: Alle Home Assistant Abhängigkeiten entfernt
- Neuer 4-Schritte-Flow: Anlage → Strompreise → Komponenten → Zusammenfassung
- PVGIS-Integration: Prognose direkt im Wizard abrufbar
- Direkte Navigation: Nach Abschluss zur Monatsdaten-Erfassung statt Cockpit
- Komponenten können nach PV-System-Erstellung weiter hinzugefügt werden
Erweiterte Komponenten-Felder im Wizard
- Speicher: Arbitrage-Checkbox (Netzstrom günstig laden, teuer einspeisen)
- E-Auto: V2H-fähig Checkbox (Vehicle-to-Home)
- Wallbox: V2H-fähig Checkbox (Bidirektionales Laden)
- Balkonkraftwerk: Ausrichtung, Neigung, Mit Speicher (z.B. Anker SOLIX)
- Alle technischen Felder als Pflichtfelder markiert
Schnellstart-Buttons für Komponenten
- Nach PV-System-Erstellung: Speicher, Wallbox, Wärmepumpe, E-Auto, Balkonkraftwerk
- Bereits vorhandene Typen werden grün mit ✓ markiert
- “Investition hinzufügen”-Dropdown für alle Typen weiterhin verfügbar

Geändert

AnlageStep vereinfacht
- Entfernt: “Technische Daten (optional)” mit Ausrichtung/Neigung (jetzt in PV-Modulen)
- Entfernt: “Wechselrichter-Hersteller” mit veraltetem HA-Hinweis
- Fokus auf Grunddaten: Name, Leistung, Datum, Standort
SummaryStep verbessert
- PVGIS-Prognose Card mit Button zum Abrufen
- Zeigt Jahresertrag wenn PVGIS abgerufen
- “Wie geht es weiter?” Sektion mit Monatsdaten-Hinweis
- CTA “Weiter zur Datenerfassung” statt “Einrichtung abschließen”
CompleteStep aktualisiert
- Hauptbutton “Monatsdaten erfassen” → navigiert zu /einstellungen/monatsdaten
- Sekundärbutton “Zum Cockpit” für alternative Navigation

Entfernt

Home Assistant Integration aus Setup-Wizard
- HAConnectionStep entfernt
- DiscoveryStep entfernt
- Automatische Sensor-Erkennung entfernt
- Keine HA-Referenzen mehr in WelcomeStep

[1.0.0-beta.10] - 2026-02-15

Hinzugefügt

Multi-Provider Wetterdienst-Integration
- Bright Sky (DWD): Hochwertige Wetterdaten für Deutschland via DWD Open Data
- Open-Meteo: Historische und Forecast-Daten weltweit
- Open-Meteo Solar: GTI-basierte Berechnung für geneigte PV-Module
- Automatische Provider-Auswahl: Bright Sky für DE, Open-Meteo sonst
- Fallback-Kette bei Nichtverfügbarkeit → PVGIS TMY → Statische Defaults
⚠ Nachträglich richtiggestellt (August 2026): Die beiden Sätze oben beschreiben die Absicht, nicht das, was ausgeliefert war. „Für DE” wurde über ein Koordinaten-Rechteck entschieden, das halb Österreich und die Nordostschweiz einschließt; das Feld Land aus den Stammdaten wurde dabei nie gelesen. Und die Fallback-Kette griff nicht, wenn Bright Sky zwar antwortete, aber keinen einzigen Strahlungswert lieferte — dann stand dort 0,0 kWh/m², statt dass Open-Meteo gefragt wurde. Unauffällig blieb das, weil beides nur außerhalb Deutschlands und an deutschen Standorten ohne Wetterstation in Reichweite auftrat. Behoben mit dem Release, das diesen Vermerk mitbringt (gemeldet von gruaGit).
GTI-basierte Solarprognose
- Global Tilted Irradiance (GTI) statt horizontaler Globalstrahlung
- Berücksichtigt Neigung und Ausrichtung der PV-Module
- Temperaturkorrektur für Wirkungsgradminderung bei Hitze
- 7-Tage Prognose mit stündlichen/täglichen Werten pro PV-String
SCOP-Modus für Wärmepumpe
- Neuer dritter Effizienz-Modus neben JAZ und COP
- EU-Energielabel SCOP-Werte (realistischer als Hersteller-COP)
- Separate Eingabe für Heiz-SCOP und Warmwasser-SCOP
- Vorlauftemperatur-Auswahl (35°C/55°C) passend zum EU-Label
Kurzfrist-Tab erweitert
- Umschalter zwischen Standard-Prognose und GTI-basierter Solarprognose
- Visualisierung der erwarteten PV-Erträge pro String
- Integration mit Open-Meteo Solar Forecast API

Geändert

Einstellungen: PVGIS → Solarprognose
- Menüpunkt umbenannt von “PVGIS” zu “Solarprognose”
- Zeigt verfügbare Wetter-Provider und deren Status
- Kombiniert PVGIS-Langfristprognose mit Wetter-Provider-Info
- Redirect von /einstellungen/pvgis zu /einstellungen/solarprognose
Demo-Daten aktualisiert
- Standort von Wien auf München geändert (für Bright Sky/DWD-Verfügbarkeit)
- PV-Module mit GTI-Parametern (ausrichtung_grad, neigung_grad)
- Balkonkraftwerk mit GTI-kompatiblen Parametern
API: Wetter-Endpoints erweitert
- GET /api/wetter/provider/{anlage_id} - Verfügbare Provider mit Status
- GET /api/wetter/vergleich/{anlage_id}/{jahr}/{monat} - Provider-Vergleich
- GET /api/solar-prognose/{anlage_id} - GTI-basierte PV-Prognose

Bugfixes

GTI-Berechnung korrigiert
- Problem: Unrealistische Werte (z.B. 8845 kWh/Tag für 20 kWp)
- Ursache: Fehlerhafte Einheitenumrechnung Wh→kWh
- Fix: Korrekte Division durch 1000 in allen Berechnungspfaden
wetter_provider in Export/Import
- Feld wird jetzt korrekt im JSON-Export mitgeliefert
- Import setzt Provider-Einstellung der Anlage
Bewölkungswerte in Kurzfrist-Prognose
- Problem: Spalte “Bewölkung” zeigte nur ”- %” statt Werte
- Ursache: Stündliche cloud_cover-Daten wurden nicht aggregiert
- Fix: Tagesdurchschnitt aus stündlichen Werten berechnet
Standort-Info auf Solarprognose-Seite
- Problem: “Standort: Unbekannt” obwohl Koordinaten vorhanden
- Fix: land/in_deutschland Felder zur StandortInfo hinzugefügt
SOLL-IST Vergleich bei mehreren PVGIS-Prognosen
- Problem: 500-Fehler wenn mehrere Prognosen für eine Anlage existieren
- Ursache: scalar_one_or_none() bei mehreren Ergebnissen
- Fix: .limit(1) um nur die neueste Prognose zu verwenden

[1.0.0-beta.9] - 2026-02-14

Hinzugefügt

Icons im Hauptmenü
- Cockpit, Auswertungen und Aussichten zeigen jetzt passende Icons
- LayoutDashboard für Cockpit, BarChart3 für Auswertungen, TrendingUp für Aussichten
JSON-Import-Vorbereitung
- Import-Modul refaktoriert für JSON-Import (lokale Variante)

Geändert

Import/Export-Modul refaktoriert
- Aufgeteilt von einer großen Datei (2500+ Zeilen) in modulares Package
- Neue Struktur: import_export/ mit separaten Dateien für CSV, JSON, Demo-Daten
- Bessere Wartbarkeit und Testbarkeit

Bugfixes

Garantiedatum wurde nicht gespeichert
- Problem: Datumsfelder wie stamm_garantie_bis wurden durch parseFloat() in Zahlen konvertiert
- Lösung: Datumsfelder werden jetzt explizit als Strings behandelt
- Betrifft: stamm_garantie_bis, wartung_gueltig_bis, stamm_erstzulassung, etc.
JSON-Export 404 in Home Assistant
- Problem: Download-Button verwendete absoluten Pfad /api/... statt relativen ./api/...
- Im HA Ingress-Modus führte das zu 404-Fehlern
- Lösung: Verwendung von importApi.getFullExportUrl() mit korrektem relativen Pfad

[1.0.0-beta.8] - 2026-02-13

Hinzugefügt

Vollständiger JSON-Export für Support/Backup
- Neuer Endpoint GET /api/import/export/{anlage_id}/full
- Exportiert komplette Anlage mit allen verknüpften Daten
- Hierarchische Struktur: Anlage → Strompreise → Investitionen (mit Children) → Monatsdaten → PVGIS
- Download-Button in der Anlagen-Übersicht (neben Bearbeiten/Löschen)
CSV-Import: Erweiterte Plausibilitätsprüfungen
- Legacy-Spalten-Validierung:
  - PV_Erzeugung_kWh, Batterie_Ladung_kWh, Batterie_Entladung_kWh sind Legacy
  - Fehler wenn NUR Legacy-Spalte vorhanden UND PV-Module/Speicher als Investitionen existieren
  - Fehler bei Mismatch zwischen Legacy-Wert und Summe der individuellen Komponenten
  - Warnung wenn redundant (gleiche Werte ±0.5 kWh Toleranz)
- Negative Werte blockiert: Alle kWh/km/€-Felder müssen ≥ 0 sein
- Plausibilitätswarnungen: Sonnenstunden > 400h/Monat, Globalstrahlung > 250 kWh/m²
Import-Feedback verbessert
- Warnungen werden jetzt zusätzlich zu Fehlern angezeigt
- Unterschiedliche Farben: Grün (Erfolg), Gelb (mit Hinweisen), Rot (mit Fehlern)
- Hilfetext zu Legacy-Spalten im Import-Bereich

Geändert

ImportResult Schema erweitert um warnungen: list[str]
Frontend Import.tsx zeigt Warnungen in amber/gelber Farbe

[1.0.0-beta.7] - 2026-02-13

Bugfixes

Kritisch: Datenbank-Migration für beta.6 Spalten fehlte
- Problem: Nach Update auf beta.6 fehlte die Migration für mastr_id und versorger_daten
- Fehler: no such column: anlagen.mastr_id - Anlage wurde nicht mehr angezeigt
- Fix: run_migrations() in database.py ergänzt um fehlende Spalten
- Bestehende Daten bleiben erhalten, Spalten werden automatisch hinzugefügt

[1.0.0-beta.6] - 2026-02-13

Hinzugefügt

Erweiterte Stammdaten für Anlagen
- MaStR-ID (Marktstammdatenregister-ID) mit direktem Link zum MaStR
- Versorger & Zähler als JSON-Struktur (Strom, Gas, Wasser)
- Beliebig viele Zähler pro Versorger mit Bezeichnung und Nummer
- Neue Komponente VersorgerSection für dynamische Verwaltung
Erweiterte Stammdaten für Investitionen
- Gerätedaten: Hersteller, Modell, Seriennummer, Garantie, MaStR-ID (nur WR)
- Ansprechpartner: Firma, Name, Telefon, E-Mail, Ticketsystem, Kundennummer, Vertragsnummer
- Wartungsvertrag: Vertragsnummer, Anbieter, Gültig bis, Kündigungsfrist, Leistungsumfang
- Typ-spezifische Zusatzfelder (Garantie-Zyklen für Speicher, Kennzeichen für E-Auto, etc.)
- Neue Komponente InvestitionStammdatenSection mit klappbaren Sektionen
Vererbungslogik für PV-System
- PV-Module und DC-Speicher erben Ansprechpartner/Wartung vom Wechselrichter
- Hinweis “(erbt von Wechselrichter)” bei leeren Feldern
- Nur bei Children mit parent_investition_id aktiv

Geändert

Anlage-Datenmodell erweitert
- mastr_id: Optional[str] - MaStR-ID der Anlage
- versorger_daten: Optional[dict] - JSON mit Versorgern und Zählern
Investition.parameter JSON erweitert
- Neue Felder: stamm_*, ansprechpartner_*, wartung_*
- Alle Stammdaten im bestehenden parameter JSON gespeichert

Dokumentation

CHANGELOG.md: Stammdaten-Erweiterung dokumentiert
README.md: Version aktualisiert
CLAUDE.md: Datenstrukturen für Versorger/Investition-Stammdaten
ARCHITEKTUR.md: JSON-Strukturen dokumentiert
BENUTZERHANDBUCH.md: Neue Formularsektionen erklärt
DEVELOPMENT.md: DB-Migration dokumentiert

[1.0.0-beta.5] - 2026-02-13

Hinzugefügt

Aussichten: 4 neue Prognose-Tabs
- Kurzfristig (7 Tage): Wetterbasierte Ertragsschätzung mit Open-Meteo
- Langfristig (12 Monate): PVGIS-basierte Jahresprognose mit Performance-Ratio
- Trend-Analyse: Jahresvergleich, saisonale Muster, Degradationsberechnung
- Finanzen: Amortisations-Fortschritt, Komponenten-Beiträge, Mehrkosten-Ansatz
Mehrkosten-Ansatz für ROI-Berechnung
- Wärmepumpe: Kosten minus Gasheizung (alternativ_kosten_euro Parameter)
- E-Auto: Kosten minus Verbrenner (alternativ_kosten_euro Parameter)
- PV-System: Volle Kosten (keine Alternative)
- Alternativkosten-Einsparungen als zusätzliche Erträge (WP vs. Gas, E-Auto vs. Benzin)

Geändert

ROI-Metriken klarer benannt
- Cockpit/Auswertung: jahres_rendite_prozent (Jahres-Ertrag / Investition)
- Aussichten/Finanzen: amortisations_fortschritt_prozent (Kum. Erträge / Investition)
- Unterschiedliche Metriken für unterschiedliche Zwecke klar dokumentiert
API-Endpoints für Aussichten
- GET /api/aussichten/kurzfristig/{anlage_id} - 7-Tage Wetterprognose
- GET /api/aussichten/langfristig/{anlage_id} - 12-Monats-Prognose
- GET /api/aussichten/trend/{anlage_id} - Trend-Analyse
- GET /api/aussichten/finanzen/{anlage_id} - Finanz-Prognose

Dokumentation

README.md: Aussichten-Feature dokumentiert
CLAUDE.md: ROI-Metriken erklärt, Aussichten-Endpoints hinzugefügt
ARCHITEKTUR.md: Aussichten-Modul dokumentiert
BENUTZERHANDBUCH.md: Aussichten-Tabs erklärt
DEVELOPMENT.md: Aussichten-API dokumentiert

[1.0.0-beta.4] - 2026-02-12

Hinzugefügt

Monatsdaten-Seite: Aggregierte Darstellung mit allen Komponenten
- Neuer API-Endpoint /api/monatsdaten/aggregiert/{anlage_id}
- Zählerwerte (Einspeisung, Netzbezug) aus Monatsdaten
- Komponenten-Daten (PV, Speicher, WP, E-Auto, Wallbox) aus InvestitionMonatsdaten aggregiert
- Berechnete Felder (Direktverbrauch, Eigenverbrauch, Autarkie, EV-Quote)
- Gruppierte Spaltenauswahl mit Ein-/Ausblenden pro Gruppe
- Farbcodierung: Zählerwerte (blau), Komponenten (amber), Berechnungen (grün)
Balkonkraftwerk: Eigenverbrauch-Erfassung
- Neues Feld eigenverbrauch_kwh in InvestitionMonatsdaten
- CSV-Template erweitert: {BKW}_Eigenverbrauch_kWh
- Einspeisung wird automatisch berechnet (Erzeugung - Eigenverbrauch)
- Dashboard zeigt Einspeisung als “unvergütet”

Geändert

Demo-Daten bereinigt (Architektur-Konsistenz)
- Monatsdaten.pv_erzeugung_kwh entfernt (war Legacy)
- batterie_ladung_kwh, batterie_entladung_kwh entfernt (Legacy)
- Berechnete Felder entfernt (werden dynamisch berechnet)
- Prinzip: Monatsdaten = NUR Zählerwerte; InvestitionMonatsdaten = ALLE Komponenten
BKW-Dashboard: Feldnamen-Kompatibilität
- Akzeptiert sowohl pv_erzeugung_kwh als auch erzeugung_kwh

Dokumentation

BENUTZERHANDBUCH.md: Aggregierte Monatsdaten und BKW-Eigenverbrauch dokumentiert
ARCHITEKTUR.md: Datenstrukturen korrigiert (WP: stromverbrauch_kwh, BKW: pv_erzeugung_kwh)
Alle Dokumente auf Version 1.0.0-beta.4 aktualisiert

[1.0.0-beta.3] - 2026-02-12

Bugfixes

Jahr-Filter in Auswertungen → Komponenten funktioniert jetzt
- Problem: Jahr-Auswahl hatte keine Auswirkung auf angezeigte Daten
- Fix: Jahr-Parameter wird jetzt durch alle Schichten durchgereicht (Backend API → Frontend API → KomponentenTab)
- Betroffen: cockpit.py, cockpit.ts, KomponentenTab.tsx, Auswertung.tsx

[1.0.0-beta.2] - 2026-02-12

Hinzugefügt

Wärmepumpe: Erweiterte Effizienz-Konfiguration
- Modus-Auswahl zwischen JAZ und getrennten COPs für Heizung/Warmwasser
- JAZ (Jahresarbeitszahl): Ein Wert für alles - einfacher (Standard)
- Getrennte COPs: Separate Werte für Heizung (~3,9) und Warmwasser (~3,0) - präziser
- Automatische Migration: Bestehende Anlagen nutzen JAZ-Modus

Geändert

ROI-Berechnung Wärmepumpe berücksichtigt jetzt den gewählten Effizienz-Modus
Demo-Daten zeigen Wärmepumpe mit getrennten COPs als Beispiel

Dokumentation

CLAUDE.md: WP-Datenmodell-Beispiele ergänzt
ARCHITEKTUR.md: WP-Parameter aktualisiert
BENUTZERHANDBUCH.md: WP-Konfiguration und CSV-Spalten dokumentiert

[1.0.0-beta.1] - 2026-02-11

Kritische Bugfixes

Diese Version behebt kritische Bugs im SOLL-IST Vergleich und der Datenpersistenz.

SOLL-IST Vergleich zeigte falsche Werte

Problem: Der SOLL-IST Vergleich im Cockpit → PV-Anlage zeigte falsche IST-Werte (z.B. 0.3 MWh statt ~14 MWh).

Ursachen und Fixes:

Legacy-Feld entfernt - Monatsdaten.pv_erzeugung_kwh wurde noch verwendet statt InvestitionMonatsdaten.verbrauch_daten.pv_erzeugung_kwh
- Betroffen: cockpit.py, investitionen.py, ha_export.py, main.py
SQLAlchemy flag_modified() - JSON-Feld-Updates wurden nicht persistiert
- SQLAlchemy erkennt Änderungen an JSON-Feldern nicht automatisch
- Fix: flag_modified(obj, "verbrauch_daten") nach Änderung
- Betroffen: import_export.py
Jahr-Parameter fehlte - PVStringVergleich erhielt kein jahr und verwendete 2026 statt 2025
- Fix: latestYear aus Monatsdaten berechnen und übergeben
- Betroffen: PVAnlageDashboard.tsx

Geändert

CSV-Template bereinigt
- Entfernt: PV_Erzeugung_kWh (Legacy), Globalstrahlung_kWh_m2, Sonnenstunden (auto-generiert)
- Import akzeptiert Legacy-Spalten weiterhin als Fallback
run.sh Version korrigiert - War hardcoded auf 0.9.3

Dokumentation

Vollständige Dokumentation erstellt
- README.md komplett überarbeitet für v1.0.0
- docs/BENUTZERHANDBUCH.md - Umfassendes Benutzerhandbuch
- docs/ARCHITEKTUR.md - Technische Architektur-Dokumentation
- CHANGELOG.md - Vollständige Versionshistorie
- docs/DEVELOPMENT.md - Entwickler-Setup aktualisiert

Datenarchitektur-Klarstellung

Monatsdaten (Tabelle):
  - einspeisung_kwh      ✓ Primär (Zählerwert)
  - netzbezug_kwh        ✓ Primär (Zählerwert)
  - pv_erzeugung_kwh     ✗ LEGACY - nicht mehr verwenden!
  - batterie_*           ✗ LEGACY - nicht mehr verwenden!

InvestitionMonatsdaten (Tabelle):
  - verbrauch_daten (JSON):
    - pv_erzeugung_kwh   ✓ Primär für PV-Module
    - ladung_kwh         ✓ Primär für Speicher
    - entladung_kwh      ✓ Primär für Speicher

[0.9.9] - 2026-02-10

Architektur-Änderung: Standalone-Fokus

EEDC ist jetzt primär Standalone ohne HA-Abhängigkeit für die Datenerfassung.

Entfernt

Komplexer HA-Import Wizard (YAML-Generator, Template-Sensoren, Utility Meter, Automationen)
HA-Sensor-Auswahl und Mapping-Logik
EVCC-Berechnungen (spezielle Template-Sensoren)
REST Command / Automation für automatischen Import

Beibehalten

CSV-Import (volle Funktionalität)
Manuelles Formular für Monatsdaten
Wetter-API (Open-Meteo/PVGIS - HA-unabhängig!)
HA-Export via MQTT (optional)

Begründung

Die komplexe HA-Integration erwies sich als zu kompliziert:

EVCC liefert andere Datenstrukturen als erwartet
Utility Meter können nicht programmatisch Geräten zugeordnet werden
Jede Haus-Automatisierung ist anders → Kein “One Size Fits All”

[0.9.8] - 2026-02-09

Hinzugefügt

Wetter-API für automatische Globalstrahlung/Sonnenstunden
- GET /api/wetter/monat/{anlage_id}/{jahr}/{monat}
- GET /api/wetter/monat/koordinaten/{lat}/{lon}/{jahr}/{monat}
- Datenquellen: Open-Meteo Archive API (historisch), PVGIS TMY (Fallback)
Auto-Fill Button im Monatsdaten-Formular
- Globalstrahlung und Sonnenstunden werden automatisch gefüllt
- Zeigt Datenquelle an (Open-Meteo oder PVGIS TMY)

[0.9.7] - 2026-02-09

Große Daten-Bereinigung: InvestitionMonatsdaten als primäre Quelle

Diese Version löst ein fundamentales Architekturproblem: Die inkonsistente Mischung von Monatsdaten und InvestitionMonatsdaten in den Cockpit-Endpoints.

Neue Architektur

Monatsdaten = NUR Anlagen-Energiebilanz (Einspeisung, Netzbezug, PV-Erzeugung)
InvestitionMonatsdaten = ALLE Komponenten-Details (Speicher, E-Auto, WP, PV-Module, etc.)

Backend-Änderungen

get_cockpit_uebersicht: Speicher-Daten jetzt aus InvestitionMonatsdaten
get_nachhaltigkeit: Zeitreihe aus InvestitionMonatsdaten
get_komponenten_zeitreihe: Erweiterte Felder für alle Komponenten
get_speicher_dashboard: Arbitrage-Auswertung hinzugefügt

Neue Auswertungsfelder

Komponente	Neue Felder
Speicher	Arbitrage (Netzladung), Ladepreis, Arbitrage-Gewinn
E-Auto	V2H-Entladung, Ladequellen (PV/Netz/Extern), Externe Kosten
Wärmepumpe	Heizung vs. Warmwasser getrennt
Balkonkraftwerk	Speicher-Ladung/Entladung
Alle	Sonderkosten aggregiert

Frontend-Erweiterungen

KomponentenTab (Auswertungen):
- Speicher: Arbitrage-Badge + KPI + gestapeltes Chart
- E-Auto: V2H-Badge, Ladequellen-Breakdown, gestapeltes Chart
- Wärmepumpe: Heizung/Warmwasser getrennt (KPIs + gestapeltes Chart)
- Balkonkraftwerk: “mit Speicher”-Badge + Speicher-KPIs
SpeicherDashboard (Cockpit):
- Arbitrage-Sektion mit KPIs (Netzladung, Ø Ladepreis, Gewinn)
- Gestapeltes Chart zeigt PV-Ladung vs. Netz-Ladung

Migration für bestehende Installationen

Warnung in Monatsdaten-Ansicht wenn Legacy-Daten (Monatsdaten.batterie_*) vorhanden
Auto-Migration beim Bearbeiten: Legacy-Werte werden automatisch in das Formular übernommen
Benutzer muss Monatsdaten einmal öffnen und speichern um Daten zu migrieren

Demo-Daten erweitert

PV-Module mit saisonaler Verteilung pro String (Süd/Ost/West)
Speicher mit Arbitrage-Daten (ab 2025)
Wallbox mit Ladedaten

[0.9.6] - 2026-02-08

Cockpit-Struktur verbessert

Neuer Tab “PV-Anlage” mit detaillierter PV-System-Übersicht
- Wechselrichter mit zugeordneten PV-Modulen und DC-Speichern
- kWp-Gesamtleistung pro Wechselrichter
- Spezifischer Ertrag (kWh/kWp) pro String
- String-Vergleich nach Ausrichtung (Süd, Ost, West)
Tab “Übersicht” zeigt jetzt ALLE Komponenten aggregiert
Komponenten-Kacheln mit Schnellstatus und Klick-Navigation

KPI-Tooltips

Alle Cockpit-Dashboards zeigen Formel, Berechnung, Ergebnis per Hover
SpeicherDashboard, WaermepumpeDashboard, EAutoDashboard
BalkonkraftwerkDashboard, WallboxDashboard, SonstigesDashboard

[0.9.5] - 2026-02-07

PV-System ROI-Aggregation

Wechselrichter + PV-Module + DC-Speicher als “PV-System” aggregiert
ROI auf Systemebene statt pro Einzelkomponente
Aufklappbare Komponenten-Zeilen im Frontend
Einsparung proportional nach kWp auf Module verteilt

Konfigurationswarnungen

Warnsymbol bei PV-Modulen ohne Wechselrichter-Zuordnung
Warnsymbol bei Wechselrichtern ohne zugeordnete PV-Module

Bugfixes

Jahr-Filter für Investitionen ROI-Dashboard funktionsfähig
Investitions-Monatsdaten werden jetzt korrekt gespeichert

[0.9.4] - 2026-02-06

Jahr-Filter für ROI-Dashboard
Unterjährigkeits-Korrektur bei Jahresvergleich
PV_Erzeugung_kWh in CSV-Template

[0.9.3] - 2026-02-05

HA Sensor Export

REST API: /api/ha/export/sensors/{anlage_id} für HA rest platform
MQTT Discovery: Native HA-Entitäten via MQTT Auto-Discovery
YAML-Generator: /api/ha/export/yaml/{anlage_id} für configuration.yaml
Frontend: HAExportSettings.tsx mit MQTT-Config, Test, Publish

Auswertungen Tabs

Übersicht = Jahresvergleich (Monats-Charts, Δ%-Indikatoren, Jahrestabelle)
PV-Anlage = Kombinierte Übersicht + PV-Details
Investitionen = ROI-Dashboard, Amortisationskurve, Kosten nach Kategorie

[0.9.2] - 2026-02-04

Balkonkraftwerk Dashboard (Erzeugung, Eigenverbrauch, opt. Speicher)
Sonstiges Dashboard (Flexible Kategorie: Erzeuger/Verbraucher/Speicher)
Sonderkosten-Felder für alle Investitionstypen
Demo-Daten erweitert (Balkonkraftwerk 800Wp + Speicher, Mini-BHKW)

[0.9.1] - 2026-02-03

Zentrale Versionskonfiguration
Dynamische Formulare (V2H/Arbitrage bedingt)
PV-Module mit Anzahl/Wp
Monatsdaten-Spalten konfigurierbar
Bugfixes: 0-Wert Import, berechnete Felder

[0.9.0] - 2026-02-01

Initiales Beta-Release

FastAPI Backend mit SQLAlchemy 2.0 + SQLite
React 18 Frontend mit Tailwind CSS + Recharts
Home Assistant Add-on Konfiguration
7-Schritt Setup-Wizard
Anlagen-, Strompreis-, Investitions-Verwaltung
Monatsdaten mit CSV-Import/Export
Cockpit mit aggregierten KPIs
Auswertungen (Jahresvergleich, ROI, CO₂)