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

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

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.
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.
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.
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.
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.
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.
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]).

[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)
- 🚗 Ø 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₂)