Sensor-Referenz

Sensor-Referenz: Feldnamen, Einheiten, Anforderungen

Referenz für UI-Beschreibungen in der Datenquellen-Zuordnung und im MQTT-Setup.

Siehe auch: Wärme & Klima — welcher der Wärmepumpen-Zähler unten welche Kennzahl möglich macht, und was ohne ihn passiert.

Single Source of Truth: Die Feld-Hilfetexte (Spalte „Beschreibung”) werden im Code als hinweis-Attribut in backend/core/field_definitions.py gepflegt und über GET /api/monatsdaten/feld-hinweise an die Datenquellen-Zuordnung ausgeliefert. Diese Referenz und die hinweis-Texte konsistent halten. Die Export-Sensoren (§8a, §11) spiegeln backend/services/ha_sensors_export.py bzw. GET /api/ha/export/definitions.

Legende

Symbol	Bedeutung
Momentan	Aktueller Messwert zum Zeitpunkt der Abfrage (z.B. aktuelle Leistung in W)
Kumulativ	Zählerstand der stetig steigt (z.B. Stromzähler in kWh). Delta wird berechnet.
Tagessensor	Kumulativer Sensor der täglich um 0:00 auf 0 zurückgesetzt wird (HA Utility Meter). ⛔ Als Zählerquelle nicht geeignet: eedc erkennt den Rücksprung und liefert für Tag wie Monat keinen Wert, statt zwei Stände abzuziehen, die zu verschiedenen Zählerläufen gehören. Hochgerechnet wird bewusst nicht — der Fehlbetrag ginge immer nach unten und sähe im Monatsabschluss aus wie eine Messung. Nimm den fortlaufenden Stand (utility_meter mit Zurücksetzen „nie”). ⚠ Über HA ist das folgenlos, dort kommt der reset-bereinigte sum-Wert; es betrifft rohe MQTT-Stände.
Counter	Kumulativer Anzahl-Zähler (Total-Increasing, kein kWh). Wird strikt von kWh-Feldern getrennt — siehe „Counter vs. kWh” unten.
Bidirektional	Positiv/negativ kodiert die Richtung (z.B. +Ladung/−Entladung)
state_class	HA-Attribut. total_increasing/total markieren kumulative Sensoren — von HA in Long-Term Statistics persistiert. Sensoren ohne state_class haben keine LTS-Einträge → für kWh-Felder ungeeignet (siehe „LTS-Verfügbarkeit”).
*	Pflichtfeld — ohne diesen Wert fehlt eine Kernauswertung. In der Zuordnungs-Fläche mit rotem *; bleibt es ohne Quelle, steht der Hinweis dort rot und aufgeklappt.
Alternativ-Gruppe	Zwei Erfassungswege, von denen einer genügt. Ist ein Weg belegt, gilt der andere als abgedeckt und wird nicht mehr angemahnt.

Wo ordne ich Sensoren zu? In v4 unter Einstellungen → Datenquellen — jedes Feld bekommt genau eine Quelle (HA-Sensor, MQTT-Gateway, MQTT-Inbound oder keine). Details zur Fläche: Handbuch Einstellungen §7. Voraussetzung ist eine stehende Verbindung (Integration).

Pflicht, optional, oder hier gar nicht? Die Fläche stuft jedes Feld ein, damit „keine Quelle” nicht pauschal wie ein Mangel aussieht (SoT: FELD_BEDARF in backend/core/field_definitions.py):

• Pflicht (*) — Anlage: Einspeisung + Netzbezug (Zählerstand) und die PV-Erzeugung. Je Gerät das jeweilige Kernfeld: Speicher Ladung/Entladung, Wärmepumpe Strom + abgegebene Wärme (Heizwärme oder Wärme gesamt — eines von beiden genügt), Wallbox Ladung gesamt, E-Auto gefahrene km, PV-Modul/Balkonkraftwerk Erzeugung.
• Optional — alles Übrige, insbesondere alle Live-Felder (W, %, °C): ohne sie bleibt nur das Live-Dashboard leer, Statistik und Wirtschaftlichkeit laufen über die kWh-Zählerstände weiter.
• Nicht hier zu erfassen — das Feld ist durch einen anderen Weg abgedeckt und wird mit Begründung ausgegraut: die drei Alternativ-Gruppen (unten). Die Heimladung am E-Auto (Heim: PV/Netz/gesamt) wird seit v4.0.51 auch neben einer Wallbox angeboten: eine Messung am Auto zählt für dieses Auto, die Wallbox trägt den Rest — Pflicht ist sie dort nicht; nur einem Dienstwagen neben einer dienstlichen Wallbox fehlen die Felder (siehe §5).

Alternativ-Gruppen:

Gruppe	Weg A	Weg B
PV-Energie	Anlage pv_gesamt_kwh	je PV-Modul/Balkonkraftwerk pv_erzeugung_kwh
PV-Leistung	Anlage pv_gesamt_w	je Modul leistung_w
Netz-Leistung	netz_kombi_w (ein Sensor mit Vorzeichen)	einspeisung_w + netzbezug_w getrennt

PV-Energie ist kein reines Entweder-oder: Einzelwerte haben immer Vorrang, der Gesamtwert füllt nur die Lücken der Module ohne eigenen Wert (anteilig nach kWp, in der Anzeige gekennzeichnet). Beides zusammen ist deshalb der normale Übergangszustand, solange noch nicht jeder String misst. Zielbild: alle Strings erfassen und pv_gesamt_kwh auf „keine” setzen — zusammengefasst höchstens je Ausrichtung/Neigung, sonst kippt die Prognose für Anlagen mit mehreren Ausrichtungen. Bei den beiden Leistungs-Gruppen gilt das Entweder-oder dagegen strikt: ein einziger Einzelsensor macht den Gesamtsensor im Live-Dashboard wirkungslos.

„Keine Quelle” ist kein Fehler: Alle kWh-Felder lassen sich im Monatsabschluss auch manuell erfassen. Rot heißt „hier fehlt noch etwas”, nie „falsch”.

---

1. Basis-Felder (Zähler / Netzübergabe)

Monatserfassung (kWh)

Feld	Label	Einheit	Sensortyp	Beschreibung	Ausgewertet in
einspeisung_kwh	Einspeisung *	kWh	Kumulativ oder Tagessensor	Ins Netz eingespeiste Energie. Muss immer ≥ 0 sein. Bei Zweirichtungszähler: nur der Einspeiseanteil.	Cockpit → Monat · Cockpit → Jahr · Auswertungen → Tabelle · HA-Sensoren
netzbezug_kwh	Netzbezug *	kWh	Kumulativ oder Tagessensor	Aus dem Netz bezogene Energie. Muss immer ≥ 0 sein. Bei Zweirichtungszähler: nur der Bezugsanteil.	Cockpit → Monat · Cockpit → Jahr · Auswertungen → Tabelle · HA-Sensoren
globalstrahlung_kwh_m2	Globalstrahlung	kWh/m²	Kumulativ	Globalstrahlung im Monat. Der Auto-Fill im Monatsabschluss holt sie von Open-Meteo bzw. Bright Sky — nur in ein leeres Feld.	Cockpit → Aussicht · Auswertungen → Tabelle
sonnenstunden	Sonnenstunden	h	Kumulativ	Sonnenstunden im Monat. Der Auto-Fill im Monatsabschluss holt sie von Open-Meteo bzw. Bright Sky — nur in ein leeres Feld.	Cockpit → Aussicht · Auswertungen → Tabelle
durchschnittstemperatur	Ø Temperatur	°C	—	Monatsdurchschnitt. Der Auto-Fill im Monatsabschluss holt ihn zuerst aus den gemessenen Außentemperaturen des Monats (Stundenwerte, sonst Tages-Min/Max), sonst von Open-Meteo — und nur in ein leeres Feld.	Komponenten → Wärmepumpe · Auswertungen → Tabelle

Live-Dashboard (W)

Feld	Label	Einheit	Sensortyp	Beschreibung	Ausgewertet in
einspeisung_w	Einspeisung	W	Momentan	Aktuelle Einspeiseleistung. Muss ≥ 0 sein. Wird alle paar Sekunden abgefragt.	Cockpit → Live · Cockpit → Tag
netzbezug_w	Netzbezug	W	Momentan	Aktuelle Netzbezugsleistung. Muss ≥ 0 sein.	Cockpit → Live · Cockpit → Tag
pv_gesamt_w	PV Gesamt	W	Momentan	Gesamte aktuelle PV-Leistung. Nur nötig wenn keine individuellen PV-Komponenten-Sensoren konfiguriert sind.	Cockpit → Live · Cockpit → Tag
netz_kombi_w	Kombinierter Netz-Sensor	W	Momentan, bidirektional	Alternative zu getrennt einspeisung_w/netzbezug_w. Positiv = Netzbezug, negativ = Einspeisung. Nur verwenden, wenn keine getrennten Leistungssensoren vorhanden sind. Zugeordnete kWh-Zählerstände (einspeisung_kwh/netzbezug_kwh) daneben sind richtig — sie liefern die Tagesmengen, der Kombi-Sensor die Leistung.	Cockpit → Live · Cockpit → Tag
strompreis	Strompreis (dynamischer Tarif)	ct/kWh	Momentan	Optional, ab v3.16.0. Aktueller Strompreis aus Tibber, aWATTar, EPEX oder eigenem Template-Sensor. Akzeptierte Einheiten: ct/kWh, EUR/kWh, EUR/MWh (×0.1 → ct/kWh), Cent, €. Wird im Live-Tagesverlauf als gepunktete Linie auf sekundärer Y-Achse gezeigt. Ohne eigenen Sensor lädt eedc automatisch den EPEX-Börsenpreis (DE/AT) via aWATTar API als Fallback.	Cockpit → Live

MQTT-Topic-Mapping (Basis)

MQTT-Topic	Entspricht	Hinweis
eedc/{id}_{name}/live/einspeisung_w	einspeisung_w
eedc/{id}_{name}/live/netzbezug_w	netzbezug_w
eedc/{id}_{name}/live/pv_gesamt_w	pv_gesamt_w
eedc/{id}_{name}/live/netz_kombi_w	netz_kombi_w
eedc/{id}_{name}/energy/einspeisung_kwh	einspeisung_kwh	Tagessensor (Utility Meter), alle 5 Min publishen
eedc/{id}_{name}/energy/netzbezug_kwh	netzbezug_kwh	Tagessensor (Utility Meter), alle 5 Min publishen
eedc/{id}_{name}/energy/pv_gesamt_kwh	Σ pv_erzeugung_kwh	⚠️ Heißt im Monatsdaten pv_erzeugung_kwh — Namensunterschied!

---

2. PV-Module / Balkonkraftwerk

Monatserfassung

Feld	Label	Einheit	Sensortyp	Beschreibung	Ausgewertet in
pv_erzeugung_kwh	PV-Erzeugung	kWh	Kumulativ oder Tagessensor	Erzeugte Energie dieses PV-Strings/Moduls. Muss ≥ 0 sein. Alternativ: automatische kWp-Verteilung aus dem Gesamt-PV-Sensor.	Komponenten → PV-Module · Cockpit → Monat · HA-Sensoren
eigenverbrauch_kwh	Eigenverbrauch	kWh	Kumulativ oder Tagessensor	Nur BKW: Direkt im Haushalt verbrauchte BKW-Erzeugung. Optional, nur Monatswert, wirkt nur in einem Monat ohne Erzeugung (siehe Kasten).	Komponenten → Balkonkraftwerk · Auswertungen → Finanzen
speicher_ladung_kwh	Speicher Ladung	kWh	kein Sensor — nur manuell/Import	Nur BKW mit Speicher: Ins BKW-Akku geladene Energie. Altbestand, siehe Kasten.	Cockpit → Monat · Komponenten → Balkonkraftwerk
speicher_entladung_kwh	Speicher Entladung	kWh	kein Sensor — nur manuell/Import	Nur BKW mit Speicher: Aus BKW-Akku entladene Energie. Altbestand, siehe Kasten.	Cockpit → Monat · Komponenten → Balkonkraftwerk

Ein Balkonkraftwerk mit Akku: den Akku als eigene Speicher-Investition erfassen. Neu anlegen, Typ Speicher, und unter Gehört zu das Balkonkraftwerk wählen. Nur so hat der Akku Live-Leistung, Ladestand, einen Knoten im Energiefluss und Tages-/ Stundenwerte — er nutzt dann die normalen Speicher-Felder ladung_kwh / entladung_kwh, und deren Sensoren ordnest du bei dieser Speicher-Investition zu.

Die beiden BKW-eigenen Felder speicher_ladung_kwh/speicher_entladung_kwh sind der frühere zweite Weg. Sie bleiben erfassbar — bereits gepflegte Werte bleiben sichtbar und im Monatsabschluss wie im CSV-Import änderbar —, kennen aber nur einen Monatswert und lassen sich deshalb nicht mehr als Sensor- oder MQTT-Quelle zuordnen. Wer sie gepflegt hat, bekommt im Daten-Checker einen Hinweis mit dem Umstellungsweg; es geht dabei nichts verloren.

eigenverbrauch_kwh bleibt zuordenbar, liefert aber ebenfalls nur den Monatswert (HA-Langzeitstatistik oder von Hand/per Import). Es ist kein Bilanz-Zähler und in der Regel leer zu lassen: eedc leitet den BKW-Eigenverbrauch aus der Bilanz am Hauszähler ab (der Anteil des Balkonkraftwerks an der Erzeugung hinter dem Zähler) und nimmt einen eingetragenen Wert nur in einem Monat, in dem die Erzeugung fehlt. Dieselbe Entity wie bei der Erzeugung hier zuzuordnen bringt deshalb nichts. Wer es per MQTT publiziert hat: das Topic wurde bis v4.0.4 fälschlich auf den Erzeugungs-Kanal gelegt und konnte die „Heute”-PV-Kachel überschreiben; das ist behoben.

pv_erzeugung_kwh steht für drei verschiedene Größen — je nachdem, wo es auftaucht. Hier in der Monatserfassung ist es die Erzeugung dieses einen Moduls. Daneben gibt es den monatlichen PV-Gesamtwert der Anlage (gleicher Name, Anlagen-Ebene — Grundlage der kWp-Verteilung, wenn kein Pro-Modul-Wert existiert) und ein Auswertungs-Feld gleichen Namens, das PV-Module + Balkonkraftwerk zusammenfasst. Der Name bleibt bewusst unverändert, weil er zugleich MQTT-Topic, CSV-Spalte und Backup-Feld ist — eine Umbenennung wäre nach außen ein Bruch. Siehe Glossar.

Live-Dashboard

Feld	Label	Einheit	Sensortyp	Beschreibung	Ausgewertet in
leistung_w	Leistung	W	Momentan	Aktuelle PV-Erzeugungsleistung dieses Strings. Muss ≥ 0 sein.	Cockpit → Live

MQTT Energy Topics

MQTT-Topic	Feld
eedc/.../energy/inv/{inv_id}_{name}/pv_erzeugung_kwh	pv_erzeugung_kwh
eedc/.../energy/inv/{inv_id}_{name}/eigenverbrauch_kwh	eigenverbrauch_kwh (nur BKW) — wird für Tages-/Live-Werte nicht ausgewertet, s. Kasten oben

Für den Akku eines Balkonkraftwerks gibt es hier bewusst kein Topic: er wird als eigene Speicher-Investition erfasst und publiziert unter deren ID auf …/energy/inv/{speicher_id}_{name}/ladung_kwh bzw. …/entladung_kwh (siehe Speicher).

---

3. Speicher (Batterie)

Monatserfassung

Feld	Label	Einheit	Sensortyp	Beschreibung	Ausgewertet in
ladung_kwh	Ladung — bei Speichern mit Netzladung: „Ladung (gesamt, inkl. Netz)“	kWh	Kumulativ oder Tagessensor	Gesamte im Monat in den Speicher geladene Energie, Netzladung eingeschlossen. Muss ≥ 0 sein. ladung_netz_kwh ist ein davon-Anteil, kein zweiter Summand — ein Gerät, das PV- und Netzladung getrennt zählt, braucht hier die Summe beider (HA-Helfer). Messstelle: die zur Kopplung passende Seite — bei AC-Kopplung hausseitig hinter dem Batterie-Wechselrichter, bei DC-Kopplung am Batterie-Anschluss.	Komponenten → Speicher · Cockpit → Monat · HA-Sensoren
entladung_kwh	Entladung	kWh	Kumulativ oder Tagessensor	Gesamte im Monat aus dem Speicher entladene Energie. Muss ≥ 0 sein. Dieselbe Messstelle wie die Ladung — kommen die beiden von verschiedenen Seiten (etwa Ladung DC aus der Hersteller-Cloud, Entladung AC aus einem Riemann-Sensor), enthält der Wirkungsgrad die Wandlung nur in eine Richtung.	Komponenten → Speicher · Cockpit → Monat · HA-Sensoren
ladung_netz_kwh	Netzladung	kWh	Kumulativ oder Tagessensor	Anteil der Ladung aus dem Netz (Arbitrage). Optional. Muss ≤ ladung_kwh sein. Kanonischer Schlüssel ladung_netz_kwh (Legacy-Fallback speicher_ladung_netz_kwh wird noch gelesen).	Cockpit → Monat · Komponenten → Speicher
speicher_ladepreis_cent	Ø Ladepreis	ct/kWh	kein Sensor, kein Topic — nur manuell/Import	Ø Preis der Netzladung. Nur bei echter Arbitrage relevant — Backup-/Notladung läuft zum Bezugspreis. Erfassung im Monatsdaten-Formular, per CSV-Import oder über den errechneten Vorschlag bei dynamischem Tarif; auf der Datenquellen-Fläche wird das Feld nicht zur Zuordnung angeboten (seit v4.0.6).	Komponenten → Speicher · Cockpit → Monat

Live-Dashboard

Feld	Label	Einheit	Sensortyp	Beschreibung	Ausgewertet in
leistung_w	Leistung	W	Momentan, bidirektional	Positiv = Ladung (Senke), negativ = Entladung (Quelle). ⚠️ Manche WR liefern umgekehrtes Vorzeichen — dann in der Datenquellen-Zuordnung „±” (Vorzeichen umkehren) aktivieren.	Cockpit → Live
ladung_kwh	Ladung heute	kWh	Tagessensor	Tages-Ladeenergie. Optional — wenn vorhanden, wird für heute-kWh-Anzeige bevorzugt (genauer als Trapez-Integration aus W-Sensor). Wird täglich um 0:00 auf 0 zurückgesetzt.	Komponenten → Speicher · Cockpit → Monat · HA-Sensoren
entladung_kwh	Entladung heute	kWh	Tagessensor	Tages-Entladeenergie. Optional — wie ladung_kwh. Wird täglich auf 0 zurückgesetzt.	Komponenten → Speicher · Cockpit → Monat · HA-Sensoren
soc	Ladezustand	%	Momentan	State of Charge. 0–100%.	Cockpit → Live

MQTT Energy Topics

MQTT-Topic	Feld	Hinweis
eedc/.../energy/inv/{inv_id}_{name}/ladung_kwh	ladung_kwh	Tagessensor empfohlen
eedc/.../energy/inv/{inv_id}_{name}/entladung_kwh	entladung_kwh	Tagessensor empfohlen
⚠️ ladung_netz_kwh	—	Kein MQTT-Topic vorhanden — nur via HA-Sensor oder manuell

---

4. Wärmepumpe

Monatserfassung

Feld	Label	Einheit	Sensortyp	Beschreibung	Ausgewertet in
stromverbrauch_kwh	Stromverbrauch	kWh	Kumulativ oder Tagessensor	Gesamter elektrischer Energieverbrauch der WP im Monat. Bei getrennter Messung zählt er, solange nicht beide getrennten Werte vorliegen — erst dann ist ihre Summe der Verbrauch des Geräts und dieser Zähler wird verworfen (sonst zählte derselbe Strom zweimal).	Komponenten → Wärmepumpe · Cockpit → Monat · HA-Sensoren
strom_heizen_kwh	Strom Heizen	kWh	Kumulativ oder Tagessensor	Nur bei getrennter Strommessung. Elektrische Energie für Heizbetrieb.	Komponenten → Wärmepumpe · Cockpit → Tag · Cockpit → Monat
strom_warmwasser_kwh	Strom Warmwasser	kWh	Kumulativ oder Tagessensor	Nur bei getrennter Strommessung. Elektrische Energie für Warmwasserbereitung.	Komponenten → Wärmepumpe · Cockpit → Tag · Cockpit → Monat
heizenergie_kwh	Heizwärme	kWh	Kumulativ oder Tagessensor	Bereitgestellte Wärmeenergie (thermisch, nicht Strom). Für JAZ-Berechnung: heizenergie / stromverbrauch. Kann alternativ via JAZ-Strategie aus Strom × JAZ berechnet werden.	Komponenten → Wärmepumpe · Cockpit → Monat · Auswertungen → Finanzen
warmwasser_kwh	Warmwasser-Wärme	kWh	Kumulativ oder Tagessensor	Bereitgestellte Warmwasserenergie (thermisch). Optional.	Komponenten → Wärmepumpe · Cockpit → Monat
waerme_kwh	Wärme gesamt	kWh	Kumulativ oder Tagessensor	Seit v4.0.45 (N-391). Abgegebene Wärme gesamt (thermisch) — für EINEN Wärmemengenzähler, der Heizung und Warmwasser zusammen misst (der Regelfall bei Umschaltventil auf den Speicher). Mit getrennten Zählern bleibt das Feld leer. ⚠️ Ein gepflegter Gesamtwert gilt vor den beiden Einzelwerten (heizenergie_kwh + warmwasser_kwh): Er ist die Wärme des Geräts, die Aufteilung steht daneben. Wo er die Wärme trägt, gibt es keine Arbeitszahl je Funktion — die Zeilen Heizen und Warmwasser nennen dann den Grund „Wärme nicht je Funktion gemessen”.	Komponenten → Wärmepumpe · Cockpit → Monat · HA-Sensoren
wp_starts_anzahl	Kompressor-Starts	Anzahl	Counter (Total-Increasing)	Optional, ab v3.24.0 (#136). Kumulativer Anzahl-Zähler für Kompressor-Starts der Wärmepumpe. Z. B. aus der lokalen „Nibe Heat Pump”-Integration: sensor.compressor_number_of_starts_…. Stündlicher Snapshot-Job erfasst den Counter wie kWh-Zähler; Tagesabschluss berechnet Stunden- und Tages-Differenzen. Bewusst kein Fallback aus leistung_w oder Compressor-Binary — würde gerade kurze Takte (wo der KPI sticht) systematisch unterzählen. Anzeige: Cockpit → Tag (Spalte „WP-Starts”, default ausgeblendet) und Wärmepumpe-Komponentensicht (Bedienung §3.4).	Komponenten → Wärmepumpe · Jahresbericht (PDF)
wp_betriebsstunden	Betriebsstunden	h	Counter (Total-Increasing)	Optional, ab v3.34 (#238). Kumulativer Zähler der Gesamt-Betriebsstunden der WP. Kombiniert mit wp_starts_anzahl ergibt sich „Ø Laufzeit pro Start” als Auslegungs-/Verschleiß-Maß. Wird wie ein Counter behandelt — keine Energie-Einheit, keine Aufnahme in die Energie-Bilanz (siehe §9).	Komponenten → Wärmepumpe

Live-Dashboard

Feld	Label	Einheit	Sensortyp	Beschreibung	Ausgewertet in
leistung_w	Leistung	W	Momentan	Aktuelle elektrische Leistungsaufnahme der WP. Muss ≥ 0 sein. Alternativ: getrennte Sensoren (s.u.). ⚠️ Zugeordnet verdrängt es sie — siehe Kasten unter der Tabelle.	Cockpit → Live
leistung_heizen_w	Leistung Heizen	W	Momentan	Nur bei getrennter Messung: Leistungsaufnahme Heizbetrieb. Optional. ⚠️ Wird nicht ausgewertet, solange leistung_w zugeordnet ist — siehe Kasten unter der Tabelle.	Cockpit → Live · Cockpit → Tag
leistung_warmwasser_w	Leistung Warmwasser	W	Momentan	Nur bei getrennter Messung: Leistungsaufnahme Warmwasser. Optional. ⚠️ Wird nicht ausgewertet, solange leistung_w zugeordnet ist — siehe Kasten unter der Tabelle.	Cockpit → Live · Cockpit → Tag
leistung_kuehlen_w	Leistung Kühlen	W	Momentan	Nur bei getrennter Messung: Leistungsaufnahme Kühlbetrieb. Optional, reine Anzeige — die Mengen kommen aus dem kWh-Zähler. ⚠️ Wird nicht ausgewertet, solange leistung_w zugeordnet ist — siehe Kasten unter der Tabelle.	Cockpit → Live · Cockpit → Tag
warmwasser_temperatur_c	Warmwassertemperatur	°C	Momentan	Aktuelle Warmwassertemperatur. Optional, wird als Gauge angezeigt.	Cockpit → Live

⚠️ leistung_w verdrängt leistung_heizen_w, leistung_warmwasser_w und leistung_kuehlen_w. Ist die Gesamtleistung zugeordnet, wertet eedc die drei Funktions-Sensoren im Tagesverlauf nicht aus — die Wärmepumpe erscheint dort als eine Fläche. Bleibt leistung_w leer, bekommt jeder zugeordnete Funktions-Sensor im Tagesverlauf von Cockpit → Live eine eigene Fläche mit eigenem Namen (Heizen, Warmwasser, Kühlen). Der Stundenverlauf des Tages schlüsselt erst ab zwei Funktions-Sensoren auf — ein einzelner wäre dort die Gerätereihe unter anderem Namen. Beides ist richtig, es ist eine Wahl: Die Gesamtleistung ist der vollständige Anlagenwert (und die einzige Quelle des Wärmepumpen-Anteils in der Verbrauchsprognose), die getrennten Felder sind die feinere Auskunft — die Verbrauchsprognose nimmt leistung_warmwasser_w und leistung_kuehlen_w aus den Tagesprofilen, um diese Anteile nicht mit der Außentemperatur zu skalieren. Details und Folgen: Handbuch Wärme & Klima §5, Schritt 6.

⚠️ Kein Ersatz für kWh-Zähler. Diese Felder sind Momentanleistungen und speisen die Mengen nicht — Stromverbrauch, Wärme und alle Arbeitszahlen kommen aus den kWh-Feldern oben.

MQTT Energy Topics

MQTT-Topic	Feld	Hinweis
eedc/.../energy/inv/{inv_id}_{name}/stromverbrauch_kwh	stromverbrauch_kwh
eedc/.../energy/inv/{inv_id}_{name}/heizenergie_kwh	heizenergie_kwh
eedc/.../energy/inv/{inv_id}_{name}/warmwasser_kwh	warmwasser_kwh
⚠️ strom_heizen_kwh / strom_warmwasser_kwh	—	Kein MQTT-Topic — nur via HA-Sensor

4a. Verbrauch je Betriebsart und je Innengerät

Bei einer Klimaanlage stehen diese Felder gleich mit da. An jeder anderen Wärmepumpenart findest du sie unter Einstellungen → Datenquellen beim Gerät hinter „Weitere Größen erfassen” — sie sind dort seltener, aber genauso zuordenbar. Wer einen getrennten Kühlzähler an seiner Luft-Wasser- oder Sole-Wasser-Wärmepumpe hat, trägt ihn dort ein; sobald ein Sensor zugeordnet ist, steht das Feld oben bei den anderen.

Alle Felder sind optional: kein Sensor, keine Anzeige.

Ein Gerät, das heizt, kühlt, lüftet und entfeuchtet, tut das oft über denselben Zähler. Wer die Anteile getrennt messen kann, trägt sie hier ein — sie sind Teilmengen des Gesamtverbrauchs und werden nie dazuaddiert.

⚠️ Kühlen, Lüften und Entfeuchten zählen nicht in die Arbeitszahl. Sie erzeugen keine Wärme, die sich messen ließe; läge ihr Strom im Nenner, sähe eine Anlage, die im Sommer kühlt oder viel lüftet, wie eine schlechte Heizung aus. Für Wirtschaftlichkeit und CO₂ gilt beim Kühlen dasselbe schon länger. Ist der ganze Verbrauch eines Zeitraums Kühlbetrieb, steht statt der Arbeitszahl der Grund dafür.

Lüften und Entfeuchten bekommen eine eigene Zeile in der Aufteilung, sobald du einen Zähler dafür zugeordnet hast — vorher stecken sie in „nicht aufgeteilt”. Eine Kennzahl bekommen sie bewusst nicht: Es gibt keinen Nutzen, gegen den man sie rechnen könnte. Misst du zusätzlich ihre abgegebene Nutzenergie, steht sie seit v4.0.45 als eigene Mengenzeile daneben — im Komponenten-Hub und im Wärme/Klima-Block von Cockpit → Monat/Jahr, und nur dann, wenn ein Zähler etwas gemeldet hat.

Nutzenergie Heizbetrieb ist die Heizwärme deines Geräts. Hast du keinen Wärmemengenzähler am Gerät selbst (Feld Heizwärme bzw. Wärme gesamt), rechnet eedc seit v4.0.45 mit ihr: Sie trägt dann die Wärme-Kachel und die Arbeitszahl. Ist beides gepflegt, gewinnt der Gerätezähler — er misst mehr als eine einzelne Betriebsart. Bei mehreren Innengeräten werden ihre Werte summiert; ein Wert am Gerät schlägt die Summe seiner Innengeräte und wird nie dazuaddiert.

Feld	Label	Einheit	Sensortyp	Ausgewertet in
betriebsart_strom_heizen_kwh	Strom Heizbetrieb	kWh	Kumulativ oder Tagessensor	Komponenten → Wärmepumpe · Cockpit → Tag
betriebsart_strom_kuehlen_kwh	Strom Kühlbetrieb	kWh	Kumulativ oder Tagessensor	Komponenten → Wärmepumpe · Cockpit → Tag
betriebsart_strom_lueften_kwh	Strom Lüftbetrieb	kWh	Kumulativ oder Tagessensor	Komponenten → Wärmepumpe · Cockpit → Tag
betriebsart_strom_entfeuchten_kwh	Strom Entfeuchtungsbetrieb	kWh	Kumulativ oder Tagessensor	Komponenten → Wärmepumpe · Cockpit → Tag
betriebsart_nutzenergie_heizen_kwh	Nutzenergie Heizbetrieb	kWh	Kumulativ, thermisch	Komponenten → Wärmepumpe
betriebsart_nutzenergie_kuehlen_kwh	Nutzenergie Kühlbetrieb	kWh	Kumulativ, thermisch	Komponenten → Wärmepumpe · Cockpit → Monat
betriebsart_nutzenergie_lueften_kwh	Nutzenergie Lüftbetrieb	kWh	Kumulativ, thermisch	Komponenten → Wärmepumpe · Cockpit → Monat
betriebsart_nutzenergie_entfeuchten_kwh	Nutzenergie Entfeuchtungsbetrieb	kWh	Kumulativ, thermisch	Komponenten → Wärmepumpe · Cockpit → Monat
soll_temperatur_c / ist_temperatur_c	Soll-/Raumtemperatur	°C	Momentan, reine Anzeige	Cockpit → Live

betriebsart_nutzenergie_kuehlen_kwh ist die Kältemenge — und der einzige Zähler, der die Arbeitszahl Kühlen möglich macht (Kältemenge ÷ Kühlstrom). Ohne ihn steht dort der Grund statt einer Zahl; geschätzt wird nichts, weil aus einem angenommenen Wirkungsgrad genau der Faktor zurückkäme, mit dem gerechnet wurde. Sie heißt bewusst nicht „SEER” — das ist eine genormte Prüfstandsgröße, dies hier ist der Quotient deiner beiden Zähler. Ausführlich: Wärme & Klima §3.

Mehrere Innengeräte (Multisplit): Trag sie beim Gerät unter Innengeräte ein (Bezeichnung, z. B. „Büro”). Danach gibt es jedes der Felder oben zusätzlich je Innengerät — der Feld-Key trägt dessen Nummer (betriebsart_strom_kuehlen_kwh-3), das Label den Raumnamen („Büro: Strom Kühlbetrieb”).

Vorrang: Liegt ein Betriebsart-Zähler vor, gilt er — und zwar für alle Betriebsarten dieses Geräts. Die Aufteilung, die eedc sonst aus dem betriebsmodus ableitet, tritt dann zurück; eine Betriebsart ohne Zähler erscheint unter „nicht aufgeteilt”. Steht ein Wert am Gerät, schlägt er die Summe der Innengeräte — beide beschreiben dieselbe Menge, sie werden nie addiert.

⚠️ 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. Mitsubishi sagt es selbst: „It is not possible to attribute the output of the outdoor units to specific indoor units.” Die belastbare Menge ist ein eigener Zähler am Außengerät.

So bekommst du die vier Zähler in Home Assistant

Weg 1 — Utility Meter (empfohlen, für die kWh-Felder). Er zählt und übersteht Neustarts; ein Template-Sensor kann das nicht.

1. Einstellungen → Geräte & Dienste → Helfer → Helfer erstellen → Utility Meter.
2. Eingangssensor: der Energie-Sensor deiner Klimaanlage (kWh).
3. Tarife: heizen, kuehlen, lueften, entfeuchten. HA legt daraus je Tarif einen eigenen zählenden Sensor an.
4. Eine Automatisierung schaltet den aktiven Tarif, ausgelöst vom Zustand der climate-Entität — Aktion select.select_option auf die select.…-Entität, die der Utility Meter mit angelegt hat.
5. In eedc unter Einstellungen → Datenquellen die vier Tarif-Sensoren den vier Feldern zuordnen.

Weg 2 — Template-Sensor, für Momentanwerte und Umrechnungen: Leistung je Betriebsart ({{ leistung if modus == 'cool' else 0 }}), Einheiten- und Vorzeichenkorrekturen, oder das Zusammenfassen mehrerer Entitäten zu einer.

---

5. E-Auto

Die Wallbox ist die Summe, ein Auto mit eigener Messung trägt seine eigene Heimladung (seit v4.0.51). Die Heim-Felder ladung_pv_kwh („Heim: PV“), ladung_netz_kwh („Heim: Netz“) und ladung_kwh („Heim: gesamt“) werden jedem E-Auto angeboten, auch neben einer Wallbox. Trägt ein Auto dort einen Wert (auch 0) oder — im laufenden Monat — eine zugeordnete Quelle, zählt dieser Wert für dieses Auto; die Wallbox trägt den Rest, und der Rest geht nach Kilometern an die privaten Autos ohne eigene Messung (Berechnungen, Heimladung je Auto). Nur an einem Dienstwagen neben einer dienstlichen Wallbox fehlen die Felder: dort ist die dienstliche Wallbox die dienstliche Ladung. Km-, Verbrauchs-, Extern- und V2H-Felder bleiben in jedem Fall am E-Auto. Ist die Summe der Autos größer als die Wallbox, meldet der Daten-Checker es.

Monatserfassung

Feld	Label	Einheit	Sensortyp	Beschreibung	Ausgewertet in
ladung_pv_kwh	Heim: PV	kWh	Kumulativ oder Tagessensor	Zu Hause aus PV in dieses Auto geladene Energie. Neben einer Wallbox: zählt für dieses Auto, die Wallbox trägt den Rest. Ohne Wert leitet eedc den PV-Anteil ab.	Komponenten → E-Auto · Cockpit → Monat · Cockpit → Jahr
ladung_netz_kwh	Heim: Netz	kWh	Kumulativ oder Tagessensor	Zu Hause aus dem Netz in dieses Auto geladene Energie. Neben einer Wallbox: zählt für dieses Auto, die Wallbox trägt den Rest.	Komponenten → E-Auto · Cockpit → Monat · Auswertungen → Finanzen
ladung_kwh	Heim: gesamt	kWh	Kumulativ oder Tagessensor	Zu Hause in dieses Auto geladene Energie gesamt — für einen Zähler am Auto, der PV und Netz nicht trennt (z. B. evcc „Ladevorgänge: Energie [Fzg.]“; er springt am Ende jedes Ladevorgangs um dessen Menge). Neben einer Wallbox mit Ladezähler ordnet eedc jeden solchen Sprung den Stunden der Wallbox zu: die Menge bleibt der Sprung, PV-Anteil und Monat kommen aus den Stunden des Vorgangs (Berechnungen, Ladevorgänge je Auto). Ohne diese Zuordnung (Monatswert von Hand, Monat nicht ganz neu gerechnet) wird mit dem PV-Anteil der Wallbox im Monat geteilt, ohne Wallbox wie „Heim: PV“ abgeleitet. Mit „Heim: PV“/„Heim: Netz“ leer lassen. Ein alter Wert in diesem Feld aus der Zeit vor v4.0.51 mit „Herkunft unbekannt“ zählt neben einer Wallbox nicht.	Komponenten → E-Auto · Cockpit → Monat · Auswertungen → Finanzen
ladung_extern_kwh	Externe Ladung	kWh	—	Extern geladene Energie (Autobahn, Arbeit). Manuell erfassen. Optional.	Komponenten → E-Auto · Cockpit → Monat
ladung_extern_euro	Externe Ladekosten	€	—	Kosten der externen Ladung. Manuell. Optional.	Komponenten → E-Auto · Cockpit → Jahr
verbrauch_kwh	Verbrauch gesamt	kWh	Kumulativ oder Tagessensor	Gefahrener Energieverbrauch des E-Autos (reiner Fahrverbrauch), für die kWh/100 km-Effizienz mit km_gefahren verrechnet und beim Plug-in-Hybrid für den elektrischen Anteil. Keine Ladung: Als Heimladung setzt eedc ihn nur als ausdrücklich gekennzeichnete Schätzung ein, wenn für die Heimladung weder ein Wert (auch 0) noch — im laufenden Monat — eine Quelle bekannt ist (Berechnungen, Heimladung und Fahrverbrauch). Hat die Wallbox einen Sensor und im Monat 0 kWh geladen, ist die Heimladung 0. Optional — fehlt der Wert, nähert eedc die kWh/100 km aus der geladenen Energie (Heim + Extern) an (inkl. Ladeverluste).	Komponenten → E-Auto · Cockpit → Monat
km_gefahren	Gefahrene km	km	Kumulativ oder Tagessensor	Gefahrene Kilometer im Monat. Sensor (Auto-Integration, OBD) oder manuell. Ohne Sensor: im Monatsabschluss den Tachostand eintragen — eedc rechnet die Differenz zum Vormonat und schlägt sie hier vor.	Komponenten → E-Auto · Cockpit → Monat · HA-Sensoren
v2h_entladung_kwh	V2H Entladung	kWh	Kumulativ oder Tagessensor	Vehicle-to-Home Entladung. Nur bei V2H-fähigem Fahrzeug. Optional. Am Tag eine Tagesgröße (Eigenverbrauch, Gesamtverbrauch, Autarkie), keine Stunde; im Monat ab dem Abschluss.	Cockpit → Tag · Komponenten → E-Auto · Cockpit → Jahr · HA-Sensoren

Live-Dashboard

Feld	Label	Einheit	Sensortyp	Beschreibung	Ausgewertet in
leistung_w	Ladeleistung	W	Momentan	Aktuelle Ladeleistung. ≥ 0 (Laden) oder bidirektional bei V2H (negativ = Entladung ins Haus). ⚠️ Wenn gleicher Sensor wie Wallbox: wird automatisch dedupliziert.	Cockpit → Live
soc	Ladezustand	%	Momentan	State of Charge des Fahrzeugakkus. 0–100%.	Cockpit → Live

MQTT Energy Topics

MQTT-Topic	Feld	Hinweis
eedc/.../energy/inv/{inv_id}_{name}/ladung_kwh	ladung_kwh („Heim: gesamt“)	Gesamt-Heimladung dieses Autos, nicht PV/Netz-Split — geteilt wird mit dem PV-Anteil der Wallbox.
eedc/.../energy/inv/{inv_id}_{name}/km_gefahren	km_gefahren
eedc/.../energy/inv/{inv_id}_{name}/v2h_entladung_kwh	v2h_entladung_kwh	Seit #110 eingelesen (vorher verworfen): Tageswert in Cockpit → Tag, Vorschlag im Monatsabschluss.
eedc/.../energy/inv/{inv_id}_{name}/ladung_pv_kwh / …/ladung_netz_kwh	ladung_pv_kwh („Heim: PV“) / ladung_netz_kwh („Heim: Netz“)	Gemessene Aufteilung der Heimladung dieses Autos — erwartet und eingelesen wie die anderen Felder.

---

6. Wallbox

Die Wallbox ist die Summe aller Ladungen an ihr — privates Auto, Gast, Dienstwagen. So zählt sie in der Energiebilanz, am Tag, in der Stunde und in ihrer eigenen Anzeige. Mehrere Wallboxen werden summiert (jeder Ladepunkt zählt). Trägt ein Auto eine eigene Heim-Messung (siehe E-Auto), zählt sie für dieses Auto; der Rest der Wallbox geht nach Kilometern an die privaten Autos ohne eigene Messung, ohne solche bleibt er nicht zugeordnet (Gast, Verluste: nur Verbrauch, keine Ersparnis) — außer es ist gar kein Fahrzeug angelegt: dann ist die Wallbox selbst das private Auto. Ohne Messung am Auto ist das die bisherige km-anteilige Aufteilung. Ordne den Loadpoint-/Wallbox-Energiesensor hier zu.

Monatserfassung

Feld	Label	Einheit	Sensortyp	Beschreibung	Ausgewertet in
ladung_kwh	Ladung gesamt	kWh	Kumulativ oder Tagessensor	Gesamte von der Wallbox abgegebene Ladeenergie im Monat.	Komponenten → Wallbox · Cockpit → Monat
ladung_pv_kwh	Ladung PV	kWh	Kumulativ oder Tagessensor	Anteil aus PV. Optional — manche Wallboxen messen das separat.	Komponenten → Wallbox · Cockpit → Monat
ladevorgaenge	Ladevorgänge	Anzahl	Kumulativ oder Tagessensor	Anzahl der Ladevorgänge. Optional.	Komponenten → Wallbox

Live-Dashboard

Feld	Label	Einheit	Sensortyp	Beschreibung	Ausgewertet in
leistung_w	Ladeleistung	W	Momentan	Aktuelle Wallbox-Ladeleistung. Muss ≥ 0 sein.	Cockpit → Live

MQTT Energy Topics

MQTT-Topic	Feld	Hinweis
eedc/.../energy/inv/{inv_id}_{name}/ladung_kwh	ladung_kwh
eedc/.../energy/inv/{inv_id}_{name}/ladevorgaenge	ladevorgaenge
⚠️ ladung_pv_kwh	—	Kein MQTT-Topic — nur via Wallbox-API oder manuell

---

7. Sonstiges (Erzeuger / Verbraucher / Abgabe an Dritte / Speicher / Verbrauchszähler)

Monatserfassung

Feld	Kategorie	Label	Einheit	Beschreibung
erzeugung_kwh	Erzeuger	Erzeugung	kWh	Erzeugte Energie (z.B. BHKW, Windrad). Zählt hinter dem Hauszähler in die Eigenverbrauchs-/Autarkie-Bilanz.
verbrauch_sonstig_kwh	Verbraucher	Verbrauch	kWh	Verbrauchte Energie (z.B. Sauna, Pool).
bezug_pv_kwh	Verbraucher	davon PV	kWh	PV-gedeckter Anteil des Verbrauchs. Optional.
bezug_netz_kwh	Verbraucher	davon Netz	kWh	Netz-gedeckter Anteil des Verbrauchs. Optional.
abgabe_kwh	Abgabe an Dritte	Abgabe	kWh	Seit 05.09.2026. An Dritte abgegebene Energie (Mieterstrom, Allgemeinstrom, Nachbarhaus) — Zähler an der Übergabestelle, kumulativ oder Tagessensor. Weder Eigenverbrauch noch Netz-Einspeisung; eedc zieht sie vom Eigenverbrauch ab (Autarkie und Quote sinken entsprechend). Ohne Zähler gibt es keine Schätzung.
einspeise_erloes_euro	Abgabe an Dritte	Erlös	€	Erlös aus der Abgabe, dein eigener Satz — wie beim Erzeuger (§9 Weg 2).
abgabe_kwh	Abgabe an Dritte	Abgabe	kWh	Seit 05.09.2026. An Dritte abgegebene Energie (Mieterstrom, Allgemeinstrom, Nachbarhaus) — Zähler an der Übergabestelle, kumulativ oder Tagessensor. Weder Eigenverbrauch noch Netz-Einspeisung; eedc zieht sie vom Eigenverbrauch ab (Autarkie und Quote sinken entsprechend). Ohne Zähler gibt es keine Schätzung.
einspeise_erloes_euro	Abgabe an Dritte	Erlös	€	Erlös aus der Abgabe, dein eigener Satz — wie beim Erzeuger (§9 Weg 2).
abgabe_kwh	Abgabe an Dritte	Abgabe	kWh	Seit 05.09.2026. An Dritte abgegebene Energie (Mieterstrom, Allgemeinstrom, Nachbarhaus) — Zähler an der Übergabestelle, kumulativ oder Tagessensor. Weder Eigenverbrauch noch Netz-Einspeisung; eedc zieht sie vom Eigenverbrauch ab (Autarkie und Quote sinken entsprechend). Ohne Zähler gibt es keine Schätzung.
einspeise_erloes_euro	Abgabe an Dritte	Erlös	€	Erlös aus der Abgabe, dein eigener Satz — wie beim Erzeuger (§9 Weg 2).
erzeugung_kwh	Speicher	Erzeugung/Entladung	kWh	Entladene Energie.
verbrauch_sonstig_kwh	Speicher	Verbrauch/Ladung	kWh	Geladene Energie.
zaehlerstand	Verbrauchszähler	Zählerstand	(vom Gerät)	#377 — der abgelesene Stand eines Gas-, Wasser- oder Ölzählers. Erfasst, nicht bewertet: geht in keine Bilanz, keine Quote, keine Wirtschaftlichkeit, kein CO₂ und nicht in die Gemeinschaftsdaten.

⚠ Der Zählerstand ist bewusst einheitenlos gespeichert. Was neben der Zahl steht (m³, l, kg, t, kWh), gehört zum Gerät (zaehler_einheit) und wird nur zur Anzeige geholt — eedc rechnet Zählerstände nie um. Genau diese leere Einheit ist die Sicherung dagegen, dass ein Gasverbrauch in der Strombilanz landet.

Sensor-Anforderung: ein monoton steigender Zählerstand (state_class: total_increasing). Ein Sensor, der den Verbrauch je Tag liefert und nachts zurückspringt, passt hier nicht — eedc bildet die Menge aus der Differenz zweier Stände.

Zählerwechsel: altes Gerät stilllegen (Stilllegungsdatum setzen, aktiv an lassen) und ein neues anlegen. Details: Handbuch Einstellungen §3.4a.

Live-Dashboard

Feld	Label	Einheit	Beschreibung
leistung_w	Leistung	W	Aktuelle Leistung.

Ein Verbrauchszähler hat kein Live-Feld: Er führt keine Leistung, und eine m³-Reihe auf der kW-Achse des Energieflusses wäre eine Einheiten-Verwechslung. Sein aktueller Stand steht stattdessen in Live → Auf einen Blick unter Zählerstände.

---

8. Solcast PV Forecast (optional, ab v3.16.5)

Solcast als dritte Prognose-Quelle wird über die Datenquellen/Anlagenstammdaten angebunden — zwei alternative Pfade. Wie eedc die Solcast-Werte im Vergleich nutzt, steht im Handbuch Prognosen §2.3.

Variante A: HA-Integration (BJReplay)

Setzt die BJReplay Solcast HA-Integration voraus. eedc liest die 7-Tage-Prognose direkt als Sensor-State — kein API-Key in eedc nötig.

Auto-Discovery (v3.16.10): Sensoren werden über /api/states per Suffix-Pattern gematcht:

Suffix-Pattern	Bedeutung
_heute / _today	Tagesprognose Heute
_morgen / _tomorrow	Tagesprognose Morgen
_uebermorgen / _ubermorgen / _tag_3 / _day_3	Übermorgen
_tag_4 … _tag_7 / _day_4 … _day_7	Tag 4–7

Filter (v3.16.11): nur Sensoren mit unit_of_measurement=kWh und ohne „verbleibend”/„remaining” im Namen — sonst würde z. B. prognose_verbleibende_leistung_heute fälschlich als Tagesprognose gematcht.

Stundenprofil: Kommt aus dem DetailedForecast-Attribut der HA-Sensoren (v3.16.13 — vorher fälschlich detailedHourly gesucht, was bei Multi-Dach-Anlagen leer war).

Variante B: Solcast-API (Free/Paid Key)

Direkter API-Aufruf für Standalone-Nutzer ohne HA-Integration. Konfiguration in den Anlagenstammdaten (Einstellungen → Stammdaten → Solarprognose). L1-Cache (in-memory) und L2-Cache (DB) überleben Neustarts.

Slot-Konvention

30-Min-Buckets aus Solcast werden per ceil(bucket_ende) dem Backward-Slot zugeordnet (siehe BERECHNUNGEN §6b). Ein Bucket am Tagesübergang [23:00, 23:30) heute landet damit korrekt in Slot 0 des Folgetags.

---

8a. eedc-PV-Prognose nach HA exportieren (MQTT / HA-Sensoren)

eedc exportiert zusätzlich die eigene PV-Prognose als Sensoren (immer die eedc-Quelle, nie Solcast/SFML — die liegen via eigene HA-Integration bereits in HA). Alle Werte stammen aus dem Prognose-Kanon und sind damit identisch mit der „eedc”-Spalte im Vergleich.

⚠ Hast du Solcast oder SFML als Prognosequelle gewählt, zeigt Cockpit → Live andere Zahlen als diese Sensoren — und das ist Absicht. Der Block auf dem Bildschirm folgt durchgehend deiner gewählten Quelle, damit „bisher erzeugt + verbleibend = heute” wieder aufgeht. Diese Sensoren tragen dagegen weiterhin die eedc-eigene Prognose, denn die Solcast-/SFML-Werte liegen über deren eigene HA-Integration ohnehin schon in Home Assistant — ein zweiter Export derselben Zahl wäre nur eine zweite Stelle, an der sie driften kann. Mit der Standard-Quelle (eedc) zeigen beide dieselbe Zahl.

Einrichtung: Einstellungen → Integration → MQTT-Export.

Sensor / Schlüssel	Bedeutung
eedc_prognose_heute_kwh	PV-Tagesprognose heute — voller Tageswert (kanonisch, rollt mit OpenMeteo, == Anzeige).
eedc_prognose_rest_today_kwh	Rest heute — Prognose der verbleibenden Stunden, laufende Stunde anteilig nach Restminuten (#339); aus demselben Kanon → rollt synchron mit „heute”.
eedc_prognose_heute_rollend_kwh	Heute (nachgeführt) — was heute bereits erzeugt wurde plus die Prognose der Reststunden. Folgt dem IST; …_heute_kwh folgt dagegen OpenMeteo. Beide stehen bewusst nebeneinander (rapahl-PN 2026-08-23).
eedc_prognose_day_plus_1/2/3_kwh	Tagesprognose morgen / übermorgen / in 3 Tagen. Attribut stundenprofil_kwh = 24 Backward-Slots (kWh); Sensor-State == Σ Slots.
eedc_speicher_voll_um	Uhrzeit „Speicher voll” aus der SoC-Simulation ab aktuellem Speicherstand — inkl. Ladeverluste: gerechnet mit dem gepflegten Wirkungsgrad des Speichers. Vorher lief die Rechnung verlustfrei und meldete deshalb zu früh. Die Verbrauchsannahme der Simulation ist das gewichtete 8-Wochen-Profil (jüngere Tage zählen stärker, Halbwertszeit 14 Tage; Kaskade gleicher Wochentag → Werktag/Wochenende → alle Tage). Attribute profil_typ (gewichtet_8_wochen), profil_wochen, profil_halbwertszeit_tage, profil_stufe (welche Kaskadenstufe griff), profil_tage und verbrauch_annahme_kwh (der Tagesverbrauch, mit dem gerechnet wurde) nennen sie. ⚠ Ein anderes Modell als eedc_verbrauchsprognose_heute_kwh (7-Tage-Profil der Live-Kachel) — wer beide in einer Automation verrechnet, sieht das an profil_typ. Ohne brauchbare Historie rechnet die Simulation ohne Verbrauch (profil_typ: kein_profil, verbrauch_annahme_kwh: 0). ⭐ Startannahme (V1, 22.09.2026): Die Simulation beginnt bei der zuletzt von HA verdichteten Stunde — und rechnet von ihr nur die halbe Stunde, weil der Startwert ein Stundenmittel ist und damit die Mitte dieser Stunde beschreibt. Die Attribute sim_start_stunde und sim_start_anteil (0,5 bzw. 1,0) nennen sie. Bis 4.0.50 startete sie bei der laufenden Uhrzeit und rechnete diese Stunde ganz; der gemeldete Zeitpunkt kann sich dadurch um bis zu eine halbe Stunde verschieben. Das Textformat „HH:MM“ bleibt unverändert.
eedc_verbrauchsprognose_morgen_kwh	Verbrauchsprognose für morgen — die Rechnung von eedc_verbrauchsprognose_heute_kwh (Live-Kachel, 7-Tage-Profil) für den nächsten Tag: Profil des Wochentags von morgen, Wärmepumpen-Anteil mit dem Tagesmittel der Temperaturvorhersage von morgen korrigiert. Attribute stundenprofil_kwh, wp_stundenprofil_kwh, profil_typ/profil_tage/profil_slots und datum; ein anderes Modell als die Simulation hinter eedc_speicher_voll_um. Startet nach dem Update abgewählt — unter Einstellungen → Integration → MQTT-Export anhaken. Details in §11.

⚠ Welchen der drei nehme ich? …_heute_kwh beantwortet was sagt die Vorhersage für diesen Tag — er ist die Zahl, die App, MQTT und Persistenz gemeinsam tragen, und er ändert sich nur, wenn OpenMeteo einen neuen Modelllauf liefert. …_heute_rollend_kwh beantwortet worauf läuft der Tag tatsächlich hinaus — er zieht die schon gemessenen Stunden heran und reagiert damit auf einen Tag, der besser oder schlechter läuft als vorhergesagt. …_rest_today_kwh ist der reine Rest. Ihre Differenz ist keine sinnvolle Größe: …_heute_kwh enthält für die vergangenen Stunden die Vorhersage, nicht die Messung.

Warum diese Sensoren kein device_class tragen. Sie liefern kWh, sind aber keine Zähler: eine Tagesprognose springt jeden Tag zurück, und die Summe zweier Prognosen ergibt keine sinnvolle Zahl. Home Assistant verlangt für device_class: energy genau einen Zähler (state_class total/total_increasing) und nimmt Sensoren mit einer anderen Kombination von der Langzeitstatistik aus — sie zeigen dann einen Wert, ohne dass HA ihn mitschreibt. Ohne device_class ist state_class: measurement zulässig, und HA führt min/mean/max je Stunde. Bis v4.0.27 war das falsch gesetzt (gemeldet von rapahl); die Einheit kWh stand und steht unverändert am Sensor.

⚠ Wann diese Sensoren „unbekannt” zeigen — und warum das die richtige Antwort ist. eedc holt die Prognose je Ausrichtung getrennt (Multi-String-Fan-out): eine Ost- und eine Westfläche sind zwei Abrufe, jeder mit eigenem Zwischenspeicher. Fällt einer davon aus — Zeitüberschreitung oder Ratenbegrenzung beim Wetterdienst —, liefern die übrigen weiter, und die Tagessumme wäre dann um die fehlende Fläche zu klein. Statt eine solche Zahl auszugeben, lässt eedc den Sensor für diesen Durchgang leer (in Home Assistant: „unbekannt”, s. § Ein Sensor, der seinen Wert verliert); beim nächsten Durchgang steht der volle Wert wieder da. Betroffen sind …_heute_kwh, …_rest_today_kwh, …_heute_rollend_kwh und die Tage +1/+2/+3 samt Stundenprofilen — jeweils nur der Tag, dessen Abruf unvollständig war.

Für Automationen heisst das: auf unknown/unavailable prüfen, statt einen Zahlenwert vorauszusetzen. Eine Anlage mit nur einer Ausrichtung kennt den Fall nicht — dort gibt es entweder alles oder nichts. Der gemessene Wert „PV heute erzeugt” bleibt in jedem Fall stehen: er hängt an keiner Prognose.

Vor v4.0.44 stand hier die zu kleine Zahl, bis der nächste Durchgang sie ersetzte — bei der Voreinstellung eine volle Stunde.

Hinweis: Bis v3.45.5 war eedc_prognose_heute_kwh „IST bisher + Rest” und wich damit von der App-Anzeige ab. Seit dem Prognose-Kanon trägt der Sensor den vollen kanonischen Tageswert (== Anzeige); „Rest heute” ist der reine Rest. Automationen, die auf den alten „IST+Rest”-Wert gebaut haben, sollten auf …_rest_today_kwh umgestellt werden, wenn sie den Rest brauchen.

---

9. Counter vs. kWh — strikte Trennung

eedc unterscheidet seit v3.24.0 zwei Klassen kumulativer Sensoren:

Klasse	Beispiele	Verarbeitung
kWh-Felder	pv_erzeugung_kwh, ladung_kwh, entladung_kwh, stromverbrauch_kwh, einspeisung_kwh, netzbezug_kwh	Fließen in die Energie-Bilanz, Performance Ratio, Lernfaktor. Wh→kWh, MWh→kWh werden automatisch konvertiert.
Counter-Felder (KUMULATIVE_COUNTER_FELDER)	wp_starts_anzahl, wp_betriebsstunden	Reine Zähler — keine Energie-Einheit, keine Aufnahme in die Energie-Bilanz. Faktor 1.0 statt 0.001 bei unbekannter Einheit im HA-Statistics-Pfad.

Warum getrennt? Würde ein Counter-Sensor versehentlich als kWh-Feld konsumiert (z. B. weil seine Unit fehlt), würde er die Energie-Bilanz mit physikalisch sinnlosen Werten (z. B. 50 000 „kWh”-Kompressor-Starts) verfälschen. Die strikte Klassen-Trennung ist Voraussetzung für die Roh-Counter-Unterstützung der Nibe-Integration in v3.24.1.

---

10. LTS-Verfügbarkeit (HA Long-Term Statistics)

Welche Sensoren landen in HA-LTS?

HA persistiert nur Sensoren mit gesetztem state_class in seiner statistics_meta-Tabelle. Sensoren ohne state_class haben keine LTS-Einträge — sie funktionieren live (/api/states), liefern aber keine historischen Stundenwerte für:

• Bulk-Import historischer Monate
• Vollbackfill der Tageszusammenfassungen
• Snapshot-basierte Stunden-kWh-Berechnung (siehe BERECHNUNGEN §6b)

Filter in der Datenquellen-Zuordnung (HA-Sensor-Picker)

Bei der HA-Sensor-Auswahl zeigt eedc:

• state_class ∈ total_increasing/total → immer zugelassen, Unit egal.
• Sensor mit ganzzahligem State ohne Metadaten → zugelassen für Roh-Counter (z. B. Nibe Coils).
• Fallback-Link „Sensor nicht in der Auswahl? Alle Sensoren ohne Filter anzeigen” lädt on-demand alle sensor.*-Entities mit filter_energy=false.

„ohne Statistik”-Badge

Sensoren ohne state_class tragen ein amber-farbiges Badge „ohne Statistik” im Picker-Dropdown. Tooltip: „Für kWh-Felder ungeeignet, für Counter unproblematisch.” Im Backend trägt HASensorInfo.has_statistics: bool (= state_class is not None) diese Information. Zur Zuordnungszeit meldet die Datenquellen-Fläche das zusätzlich als Feld-Warnung (Einstellungen §7.6).

Anleitung zum Nachrüsten

Trägt ein Sensor das Badge — z. B. der Nibe-Counter sensor.compressor_number_of_starts_… —, ist der empfohlene Weg ein Verbrauchszähler-Helfer über die HA-Oberfläche: Einstellungen → Geräte & Dienste → Helfer → Verbrauchszähler, als Eingang den betroffenen Sensor, Zurücksetzen-Zyklus „nie” (also ohne Zyklus). Der Helfer bringt die Statistik-Attribute mit, sein Name überlebt einen Gerätetausch — in eedc wird anschließend der Helfer zugeordnet. Details und Begründung: Handbuch Daten-Checker §5.1.

Wer die YAML ohnehin pflegt, kann den Sensor stattdessen per customize klassifizieren:

homeassistant:
  customize:
    sensor.compressor_number_of_starts_eb101_ep14_31490:
      state_class: total_increasing

Nach HA-Neustart landet der Sensor in HA-Long-Term-Statistics und steht damit für Backfill, Per-Tag-Reaggregation und Snapshot-Self-Healing zur Verfügung. Beide Wege gelten ab jetzt — ein neu angelegter Helfer beginnt seine Historie bei null.

Wichtig: Die Korrektur wirkt ab dem Zeitpunkt der state_class-Aktivierung. HA legt LTS-Werte erst ab diesem Moment an — vorher existieren keine Werte zum Holen, auch keine rückwirkende Reparatur. Bestehende leere Tage bleiben leer; ab Aktivierung wird lückenfrei erfasst.

Daten-Checker-Kategorie „Sensor-Mapping – HA-Statistics”

Prüft pro Anlage, ob alle in der Datenquellen-Zuordnung verwendeten kWh-Sensoren tatsächlich in HA-LTS landen (siehe Handbuch Daten-Checker §4.9):

Befund	Bedeutung
OK	Alle kWh-Sensoren in LTS verfügbar
WARNING	kWh-Feld zeigt auf LTS-losen Sensor — Monatsabschluss bleibt leer (still kritisch)
WARNING	Counter-Feld zeigt auf LTS-losen Sensor — Snapshot läuft, aber Korrektur-Werkzeuge in der Energieprofil-Pflege wirken nicht

Live-Zuordnungen (leistung_w, soc) werden nicht geprüft — sie lesen state direkt und brauchen kein LTS.

---

11. Export-Sensoren (eedc → HA)

Die bisherigen Abschnitte beschreiben Sensoren, die eedc aus HA liest. Dieser Abschnitt beschreibt die umgekehrte Richtung: berechnete eedc-Werte, die als HA-Entitäten bereitgestellt werden — per MQTT Discovery (empfohlen) oder REST. Einrichtung: Einstellungen → Integration → MQTT-Export.

Nicht alles muss kommen. Jeder Sensor dieser Liste lässt sich in eedc abwählen — Häkchen weg in der Sensorliste unter Einstellungen → Integration → MQTT-Export, einzeln oder kategorieweise. Bei einer Neuinstallation sind alle an; abgewählt wird bewusst, und eedc fragt vorher nach, weil die bisherigen Daten des Sensors in HA und auf dem Broker damit verloren sind. ⭐ Kommen mit einem Update neue Sensoren dazu, starten sie bei einer bestehenden Installation abgewählt — sie tragen in der Liste die Markierung „Neu”, und du hakst an, was du haben willst (ein Knopf nimmt alle auf einmal). Dabei geht nichts verloren: sie waren nie in Home Assistant. Der Grund für diese Voreinstellung: Ein Sensor, den es nicht gibt, zeichnet nichts auf — und Home Assistant kennt keine Zeitmaschine. Wer einen Wert später braucht, bekäme ihn erst ab dem Einschalten.

Zeithorizont: Sofern nicht anders angegeben, beziehen sich die Werte auf die Gesamtlaufzeit (alle erfassten Monate, jeweils ab Anschaffungsdatum der Komponenten). Der laufende Monat fließt erst nach dem Monatsabschluss ein. Einzige Ausnahme: der Spezifische Ertrag ist aufs Jahr normiert (siehe unten).

Nachkommastellen — gleich für MQTT und REST: Wie viele Nachkommastellen ein Export-Wert trägt, hängt an seiner Größenart, nicht am Export-Weg: Energie und Mengen (kWh, kWh/kWp, km, kg) ganzzahlig, Geld auf 2 Stellen, Prozent auf 1, Leistung (kW) auf 2, Stunden/Jahre auf 1, übrige Kennwerte (COP, Zyklen, Rang) auf 2. Eine Ausnahme: die PV-Prognose-Sensoren tragen eine Nachkommastelle — sie nennen eine Tagesmenge (0–60 kWh) und keinen Zählerstand, und ihre Zahlen sollen sich addieren lassen: Rest heute plus das bereits Erzeugte ergibt heute (nachgeführt). Auf ganze Zahlen gerundet ging diese Summe sichtbar nicht mehr auf. Ein kleiner, aber echter Wert wird dabei nie auf 0 gerundet — er bekommt so viele Stellen wie nötig (höchstens 3), damit aus 0,35 kW keine 0 wird. Sensor-Namen, Einheiten und die Anzahl der Entitäten sind unverändert; die HA-Historie zeigt für zurückliegende Zeitpunkte weiter die alten Werte.

Ab v4.0.6 galt diese Regel zunächst nur für MQTT; der REST-Weg lieferte für dieselbe Größe eine andere Zahl (kWh mit einer Nachkommastelle). Seit v4.0.7 sagen beide Wege dasselbe. Wer eedc-Sensoren über die rest-Plattform eingebunden hat, sieht dort einmalig kürzere Werte — 39.692,4 kWh wird zu 39.692 kWh. Der Vollzyklen-Sensor geht den umgekehrten Weg (380 → 380,19): er ist eine dimensionslose Kennzahl und trägt jetzt dieselben zwei Stellen wie die Speicher-Anzeige in eedc.

Anlage-weite Sensoren

Sensor	Einheit	Bedeutung
pv_erzeugung_gesamt_kwh	kWh	Σ PV-Erzeugung aller erfassten Monate
direktverbrauch_gesamt_kwh	kWh	PV direkt verbraucht (ohne Speicherumweg)
eigenverbrauch_gesamt_kwh	kWh	Direktverbrauch + Speicher-Entladung + V2H
einspeisung_gesamt_kwh / netzbezug_gesamt_kwh	kWh	Zählerwerte
gesamtverbrauch_kwh	kWh	Eigenverbrauch + Netzbezug
autarkie_prozent / eigenverbrauch_quote_prozent	%	Quoten über die Gesamtlaufzeit — cockpit-gleich, inkl. Erzeuger hinter dem Zähler (siehe Wertsemantik unten)
spezifischer_ertrag_kwh_kwp	kWh/kWp	Aufs Jahr normiert — siehe Hinweis unten
netto_ertrag_euro	€	Einspeiseerlös + EV-Ersparnis + BKW-Ersparnis + Sonstige (Erträge − Ausgaben) — siehe Wertsemantik unten
einspeise_erloes_euro / eigenverbrauch_ersparnis_euro	€	Finanz-Bausteine (deckungsgleich mit Cockpit/Berichten)
co2_ersparnis_kg	kg	Volle CO₂-Bilanz (PV-Eigenverbrauch inkl. BKW/sonstige Erzeuger + Wärmepumpe + E-Mobilität) — siehe Wertsemantik unten
investition_gesamt_euro, jahres_ersparnis_euro, roi_prozent, amortisation_jahre	€, €/Jahr, %, Jahre	Investitions-KPIs — Nenner ist der Kapitaleinsatz (siehe Hinweis unten)
investition_gesamt_euro je Gerät	€	Anschaffungskosten des Geräts — mit Attributen anschaffungsdatum · stilllegungsdatum · aktiv · betriebsjahre (seit eedc@ha Teil 1). ⚠ Je Gerät exportiert eedc alle Investitionen der Anlage, auch stillgelegte; die anlagenweite Summe zählt nur die heute aktiven — das Attribut aktiv sagt, welche Geräte darin stecken
speicher_zyklen, speicher_effizienz_prozent	—, %	Speicher-KPIs. speicher_zyklen = Entladung ÷ Brutto-Kapazität — seit 2026-07-28 dieselbe Definition wie in Komponenten-Hub, Cockpit und PDF (Berechnungen §3.3). Nicht zu verwechseln mit den „SoC-Hüben” der Energieprofil-Tabelle.
letzter_import_jahr/_monat/_monat_name, anzahl_monate_erfasst	—	Status der Datenbasis (Diagnose-Kategorie — erscheint in HA im Diagnose-Bereich des Geräts)

| eedc_grundlast_kw | kW | Gemessener Nacht-Sockel des laufenden Monats (Median der Stunden 0–5 Uhr aus dem Energieprofil) — dieselbe Zahl wie die Kachel in Cockpit → Monat. ⚠ Nicht zu verwechseln mit „Grundlast (Prognose)” in Cockpit → Live: die stammt aus dem Verbrauchsprofil und ist ohne eigene Historie ein Standard-Lastprofil. Ohne gemessene Nachtstunden entsteht kein Sensor. | | eedc_verbrauchsprognose_heute_kwh | kWh | Verbrauchsprognose für heute — dieselbe Zahl wie die Kachel „Verbrauchsprognose” unter Heute in Cockpit → Live: die Summe des stündlichen Verbrauchsprofils (Werktag oder Wochenende aus der eigenen Historie, Wärmepumpen-Anteil mit dem Tagesmittel der Außentemperatur korrigiert — gemessenes Warmwasser und Kühlen bleiben dabei unverändert). Es ist der Gesamtverbrauch (Haus + Batterie + Wärmepumpe + Wallbox + Sonstige), keine Haushalts-Prognose. Attribute profil_typ, profil_tage, profil_slots nennen die Grundlage; stundenprofil_kwh trägt seit diesem Release die 24 Stundenwerte, aus denen die Summe entsteht, und wp_stundenprofil_kwh den darin enthaltenen Wärmepumpen-Anteil. ⚠ Der WP-Anteil ist eine Teilmenge, kein Summand daneben — wer beide addiert, zählt ihn doppelt. ⚠ Nur aus einem eigenen Profil: Solange eedc noch keine Historie hat und die Anzeige das Standard-Lastprofil zeigt, entsteht kein Sensor — ein Modellwert darf in keine Automation laufen. | | eedc_verbrauchsprognose_morgen_kwh | kWh | Verbrauchsprognose für morgen — dieselbe Rechnung wie eedc_verbrauchsprognose_heute_kwh, nur für den nächsten Tag: das Profil des Wochentags von morgen (am Freitag also das Wochenend-Profil für Samstag) und der Wärmepumpen-Anteil mit dem Tagesmittel der Temperaturvorhersage von morgen korrigiert. Gedacht für die Planung über die Nacht — etwa den Speicher zur günstigsten Stunde so zu laden, dass er bis zum nächsten Morgen reicht. Attribute profil_typ, profil_tage, profil_slots, stundenprofil_kwh (die Stundenwerte von morgen; so viele, wie die Wettervorhersage für morgen liefert), wp_stundenprofil_kwh (der Wärmepumpen-Anteil darin, eine Teilmenge) und datum — der Tag, für den der Wert gilt; nach Mitternacht erkennt eine Automation daran einen noch nicht erneuerten Wert. ⚠ Nur aus einem eigenen Profil für den Tagestyp von morgen — gibt es zum Beispiel noch kein Wochenend-Profil, fehlt der Sensor am Freitagabend. ⭐ Startet nach dem Update abgewählt (neu mit diesem Release): unter Einstellungen → Integration → MQTT-Export anhaken, er trägt dort die Markierung „Neu”. | | eedc_prognose_heute_vormittag_kwh / …_heute_nachmittag_kwh / …_morgen_vormittag_kwh / …_morgen_nachmittag_kwh | kWh | PV-Prognose je Tageshälfte, für heute und morgen (die Abendentscheidung braucht den Folgetag). ⭐ Die Grenze ist der Sonnenhöchststand, nicht 13:00 — dieselbe Aufteilung wie in Cockpit → Aussicht. Sie reist als Attribut solar_noon („13:28”) mit, damit eine Automation sie lesen kann statt sie zu raten. |

Zusätzlich erscheinen pro Komponente (E-Auto, Wärmepumpe, Speicher, Wallbox …) eigene Sensoren (z. B. e_auto_pv_anteil_prozent, wp_cop_durchschnitt, wp_betriebsstunden). Sie hängen — wie alle eedc-Sensoren — unter dem einen Gerät deiner Anlage; der Gerätename steht im Sensornamen („Daikin3 ECH₂O COP Durchschnitt”).

E-Auto: e_auto_verbrauch_kwh_100km und e_auto_pv_anteil_prozent. Der Verbrauch je 100 km folgt derselben Regel wie die App: je Monat der gemessene Fahrverbrauch (Feld „Verbrauch”), sonst die Ladung (Heim + Extern); über den Zeitraum die Summe der Monatswerte geteilt durch die Summe der Kilometer dieser Monate. Das Attribut quelle sagt gemessen (jeder Monat mit Kilometern hat einen Fahrverbrauch) oder ladung (Näherung über die Ladung, inkl. Ladeverluste). Bis v4.0.50 war der Sensor meist leer, weil eedc den erfassten Fahrverbrauch beim Start in eine Ladung umbuchte — er erscheint jetzt neu. Der PV-Anteil bezieht sich auf die Heimladung (PV + Netz), nicht auf „Ladung gesamt” mit Extern.

E-Auto: e_auto_ersparnis_vs_benzin_euro. Die Ersparnis gegenüber dem Verbrenner zieht die externen Ladekosten ab — nach derselben Regel wie der E-Auto-Hub: steht die externe Ladung am Wallbox-Topf und am Auto, zählt das Paar mit den höheren Kosten. Sensor und Hub nennen damit für denselben Zeitraum dieselbe Zahl. ⚠ Bis v4.0.50 blieb das Laden unterwegs im Sensor unberücksichtigt: wer externe Ladung pflegt, sieht ihn — und über den E-Auto-Posten jahres_ersparnis_euro, roi_prozent, amortisation_jahre — einmalig sinken bzw. die Amortisation länger werden; in der Langzeitstatistik ist das ein Sprung an einem Tag, es gehen keine Daten verloren.

⛔ Hier stand bis August 2026 „jeweils unter einem eigenen HA-Gerät”, und genau so war es mit v4.0.30 auch gebaut. Zwei Anwender haben innerhalb von 24 Stunden gemeldet, dass das Ergebnis schlechter ist: Bei einer PV-Anlage mit mehreren Modulflächen, Wechselrichter und Speicher entstehen so etliche HA-Geräte mit je einer einzigen Entität — zusätzlich zum Gerät der Integration. Seit v4.0.32 gibt es wieder ein Gerät je Anlage.

⭐ Für bestehende Installationen ändert sich nichts an den Daten: unique_id und Topic hängen an der Komponente, nicht am Gerät. Home Assistant erkennt dieselben Entitäten wieder und hängt sie lediglich um — entity_id, Langzeitstatistik und Automationen bleiben erhalten, der angezeigte Name ebenfalls (HA setzt ihn aus Gerät + Sensor zusammen). ⚠ Die alten, jetzt leeren Geräte entfernt HA beim nächsten Neustart; sonst lassen sie sich einmalig von Hand löschen.

Steuerungshilfen — die Gruppe für Automationen (neu)

Stufe 1 der Sensorliste sagt, was ist. Diese Gruppe sagt, was jetzt gilt und wann es gilt — die zwei Fragen, die eine Automation stellt. Alle Sensoren hier sind anlagenweit; die Geräte-Stücke stehen weiter unten.

⛔ Sie sind Vorschläge, keine Anweisungen. eedc schaltet nichts, ruft keinen Dienst auf und schreibt nichts nach Home Assistant. Es nennt ein Fenster und einen Betrag; was daraus folgt, entscheidest du.

Sensor	Einheit	Bedeutung
eedc_ueberschuss_heute_kwh	kWh	Σ des heutigen Überschusses bis jetzt (Erzeugung über Verbrauch). Attribute: defizit_heute_kwh, stand (bis zu welcher Stunde gerechnet wurde)
eedc_ueberschuss_jetzt_kw	kW	Überschuss der letzten vollständigen Stunde; negativ = Defizit. Attribute: stunde, defizit_kw. ⚠ Das ist ein Stundenmittel und bis zu 15 Minuten alt — einen Live-Überschuss gibt es in eedc als Größe nicht, und ein „ungefährer Live-Wert” wäre in einer Automation die teuerste Sorte Zahl
eedc_ueberschuss_prognose_heute_kwh	kWh	Σ des für heute erwarteten Überschusses. Attribute: stundenprofil_kwh und defizit_stundenprofil_kwh (je 24 Slots) sowie fenster — alle zusammenhängenden Überschuss-Blöcke mit ab, bis, stunden, min_kw, summe_kwh. ⭐ Das ist die Größe, die sonst niemand hat: eine Wallbox kennt das Auto, eine Wärmepumpe kennt sich selbst — den Verbrauchsgang dieses Hauses mit Wärmepumpen-Korrektur kennt nur eedc
eedc_speicher_soc_prozent	%	Kapazitätsgewichteter Ladestand aller Speicher. Attribut je_speicher schlüsselt nach Gerät auf — nur die heute laufenden: ein stillgelegter Speicher steht weiter in der Historie, aber nicht mehr in dieser Aufschlüsselung. Der Ladestand selbst ist davon unberührt
eedc_speicher_voll_um_ts	Zeitstempel	Derselbe Zeitpunkt wie der Textsensor eedc_speicher_voll_um, nur als ISO-8601-Zeitstempel — damit HA „in 2 h” anzeigen kann. ⚠ Der alte Sensor bleibt unverändert („14:00”): sein Textformat ist seit v4.0.27 Vertrag, und ein Umbau bräche jede Automation, die ihn vergleicht. Attribut quelle nennt den Partner; sim_start_stunde/sim_start_anteil nennen die Startannahme der Simulation (s. eedc_speicher_voll_um)
eedc_netzbezug_spitze_heute_kw	kW	Höchste heute gemessene Netzbezugs-Leistung. ⚠ Die Attribute stunde_max_mittel/max_mittel_kw nennen eine andere Größe: die Stunde mit dem höchsten Stundenmittel. Eine Uhrzeit zum Leistungs-Peak gibt es in eedc nicht, und sie wird hier auch nicht erfunden
eedc_bestes_fenster_ab	Zeitstempel	Beginn des günstigsten 2-Stunden-Fensters ab jetzt. Attribute dauer_1h/_2h/_3h/_4h je mit ab, bis, stunden, kosten_cent_kwh, delta_cent_kwh_vs_jetzt; dazu kosten_profil_cent_kwh und preis_profil_cent_kwh (je Slot) und frist. ⚠ Bei einem Festpreis ohne Überschuss gibt es keine günstigste Stunde — jede kostet gleich viel, und das Fenster beginnt dann schlicht jetzt. Erst der Überschuss macht einen Unterschied; delta_cent_kwh_vs_jetzt steht dort auf 0. ⭐ Warum vier feste Dauern: Ein Sensor kann keinen Parameter entgegennehmen — eine Dashboard-Karte liest Zustände, sie ruft keine Dienste. Das Kostenprofil ist mengenneutral (gilt für eine kWh) und deckt damit „jetzt oder um 14 Uhr” für Waschmaschine, Trockner, Spülmaschine und Auto
eedc_arbitrage_vorschlag_kwh	kWh	Empfohlene Netzladung des Speichers heute — laden in günstigen Stunden, entladen gegen das teuerste Defizit danach. Attribute: stunden, ersparnis_cent, soc_prozent, frei_kwh, wirkungsgrad_prozent, arbitrage_faehig. ⚠ Er entsteht nur, wenn mindestens ein Speicher „lädt aus dem Netz” gesetzt hat und sich etwas lohnt — sonst gibt es ihn nicht (eine 0 hieße „geprüft und lohnt nicht”, und das ist eine andere Aussage)
eedc_prognose_abweichung_heute_prozent	%	(IST bis zur letzten vollen Stunde − Prognose bis dahin) ÷ Prognose × 100; negativ = weniger erzeugt als vorhergesagt. Attribute: ist_kwh, prognose_kwh, bis_stunde, mae_30_tage_prozent
eedc_bezugspreis_jetzt_cent	ct/kWh	Was du in der laufenden Stunde je Kilowattstunde zahlst. Bei Festpreis oder Zeitfenstern exakt der Arbeitspreis deines Tarifs; bei einem dynamischen Tarif (1 + USt) × Börsenpreis + Aufschlag, wobei der Aufschlag abgeleitet wird (s. den Kasten „Woher der Preis je Stunde kommt”). Attribute: preisquelle, aufschlag_cent, aufschlag_quelle, aufschlag_basis, ust_prozent, tarif, gueltig_ab, markt (nur bei Börsenbezug), stundenprofil_cent und stundenprofil_morgen_cent (je 24 Slots), waermepumpe_cent (nur bei eigenem WP-Tarif)
eedc_einspeiseverguetung_cent	ct/kWh	Vergütung je eingespeister Kilowattstunde. Attribute: verguetung_quelle (vertrag · monatswert), einspeisung_variabel. ⚠ Bei variabler Vergütung gibt es den Sensor nur mit gepflegtem Monatswert — der Stammwert beschreibt diesen Monat dann ausdrücklich nicht
eedc_eigenverbrauch_wert_cent	ct/kWh	Was eine selbst verbrauchte Kilowattstunde spart: Bezugspreis − Einspeisevergütung. ⚠ Er entsteht nur mit einem vollständigen Bezugspreis; bei einem dynamischen Tarif ohne ableitbaren Aufschlag wäre „nackter Börsenpreis minus Vertragsvergütung” keine Näherung, sondern eine Differenz aus zwei verschiedenen Preisebenen — dann fehlt er, und eigenverbrauch_wert_grund am Bezugspreis-Sensor sagt warum
eedc_speicher_strom_kosten_cent	ct/kWh	Was eine aus dem Speicher entnommene Kilowattstunde kostet: die entgangene Einspeisevergütung ÷ Wirkungsgrad. Attribute: wirkungsgrad_prozent, wirkungsgrad_quelle (gemessen · parameter), wirkungsgrad_messung, je_speicher, verguetung_cent. ⭐ Nie mit dem Vorgabewert: gibt es weder einen gemessenen noch einen gepflegten Wirkungsgrad, entsteht der Sensor nicht. ⚠ wirkungsgrad_messung sagt immer, was die Messung ergeben hat — und jedes Wort verlangt einen anderen Handgriff: zu-wenig-monate (noch nicht genug erfasste Monate — das wächst von allein) · keine-entladung (Monate genug, aber die Entladung deines Speichers ist nicht erfasst — ordne ihr eine Quelle zu oder pflege den Wert; das geht nie von allein weg) · keine-ladung (im Fenster wurde gar nicht geladen) · fenster-zu-kurz (kurzes Fenster und kein SoC-Sensor) · nicht-ermittelbar (der gemessene Quotient ist unmöglich — der Daten-Checker sagt wo)
eedc_speicher_netzladen_kosten_cent	ct/kWh	Dasselbe für Strom aus dem Netz: Bezugspreis der laufenden Stunde ÷ Wirkungsgrad. Entsteht nur für Speicher mit „lädt aus dem Netz”
eedc_speicher_leer_um_ts	Zeitstempel	Wann der Ladestand nach heutiger Simulation in den Leerstand übergeht — derselbe Lauf wie „Speicher voll um”. Gibt es keinen solchen Übergang, gibt es den Sensor nicht. ⚠ Der Zeitpunkt kann in der Vergangenheit liegen: die Simulation startet bei der zuletzt gemessenen Stunde (sim_start_stunde/sim_start_anteil), nicht bei „jetzt” — hinkt Home Assistant nach, kann der Übergang in diese Lücke fallen, und der Sensor sagt dann, seit wann der Speicher nach dem Modell leer ist
eedc_abregelung_heute_kwh	kWh	Wie viel Erzeugung heute voraussichtlich an der Wechselrichter-Grenze abgeregelt wird. Attribute: skala, stundenprofil_kwh, rest_heute_kwh, grenzen_kw. ⚠ In der Skala der Rohprognose (s. den Hinweis unter der Tabelle). Ohne gepflegte AC-Grenze gibt es ihn nicht — 0 dagegen heißt „heute wird nichts abgeregelt”

Die Schalter (binary_sensor) — an, aus oder nicht verfügbar

Sensor	AN bedeutet	Attribute
eedc_ueberschuss_verfuegbar	Die letzte volle Stunde hatte Überschuss	seit
eedc_guenstige_stunde	Die laufende Stunde liegt unter der Günstig-Schwelle — dieselbe Markierung, die eedc_preis_rang trägt	schwelle_cent, preis_cent
eedc_speicher_voll	Ladestand ≥ 99 %	soc_prozent, schwelle_prozent
eedc_prognose_auffaellig	Die Tagesabweichung liegt über dem Doppelten des mittleren Fehlers der letzten 30 Tage — frühestens nach 3 vollen Sonnenstunden	schwelle_prozent, mae_30_tage_prozent, mae_tage, sonnenstunden_bisher, ggf. grund
eedc_speicher_reicht_bis_mitternacht	Der Ladestand geht bis Mitternacht nicht in den Leerstand über und endet über der Schwelle — dieselbe Regel und derselbe Simulationslauf wie „Speicher leer um”	min_soc_prozent, min_soc_um, end_soc_prozent, Modell-Angaben
eedc_einspeisung_unerwuenscht	Der Börsenpreis der laufenden Stunde ist negativ und für dieselbe Stunde wird PV-Erzeugung erwartet (§51 EEG). ⛔ Das ist ein Marktzustand, kein Urteil — was daraus folgt, entscheidest du	boersenpreis_cent, pv_prognose_kwh, ueberschuss_prognose_kwh, negative_stunden_heute, naechste_negative_ab
wp_warmwasserbetrieb (je Wärmepumpe)	Der mitgeschriebene Betriebsmodus der letzten vollen Stunde war Warmwasser	modus

Warum „Abregelung heute” in der Skala der Rohprognose steht. Der Wert ist die Differenz zwischen dem, was deine Module könnten, und dem, was der Wechselrichter durchlässt — und diese Kappung rechnet eedc auf der ungefilterten OpenMeteo-Prognose, bevor der gelernte Korrekturfaktor deiner Anlage darauf angewendet wird. Das Attribut skala: openmeteo_roh_vor_korrektur sagt es ausdrücklich.

⭐ Den Verlust mitzukorrigieren wäre falsch, nicht nur ungenau. Kappung ist max(0, Leistung − Grenze) — sie skaliert nicht mit einem Faktor. Eine Anlage, deren Rohprognose die Grenze um 1 kW überschreitet, hat bei einem Korrekturfaktor von 0,8 nicht 0,8 kW Verlust, sondern unter Umständen gar keinen: das korrigierte Profil liegt dann komplett unter der Grenze. Eine „korrigierte Abregelung” wäre eine Zahl, die niemand gerechnet hat.

Was du damit anfangen kannst: die Größenordnung und die Uhrzeiten. stundenprofil_kwh zeigt, in welchen Stunden gekappt wird — das sind die Stunden, in denen sich eine verschiebbare Last am meisten lohnt, weil ihr Strom sonst gar nicht erst entsteht. grenzen_kw nennt die Grenzen, an denen gekappt wird, rest_heute_kwh den noch bevorstehenden Teil.

Warum die Ampel „Prognose-Abweichung auffällig” heißt und nicht „Anlage defekt”. eedc sieht Verschattung, Schnee auf den Modulen, einen ausgefallenen Sensor und einen echten Defekt als dieselbe Zahl. Ein Urteil wäre eine Behauptung über eine Ursache, die eedc nicht kennt. Die Schwelle ist außerdem anlagenspezifisch: Sie hängt am mittleren Fehler deiner Anlage der letzten 30 Tage — eine Anlage mit 8 % Streuung schlägt bei 16 % an, eine mit 25 % erst bei 50 %. Ein fester Prozentwert hätte je nach Anlage entweder dauernd oder nie ausgelöst. Ohne Genauigkeits-Tracking gibt es die Ampel nicht.

Was ein binary_sensor in eedc ist — und was er nicht kann

Bis September 2026 hat eedc genau eine Sorte HA-Entität angelegt: sensor. Mit den Steuerungshilfen kommt eine zweite dazu, der binary_sensor — er kennt zwei Zustände, ON und OFF, und keine Einheit, keine Langzeitstatistik über Zahlenwerte.

⚠ Er kennt kein „unbekannt” — deshalb wird er nicht verfügbar. Verliert ein binary_sensor seine Grundlage (der Preis-Abruf fällt aus, das Tagesprofil bricht ab), gibt es keinen dritten Zustand, den eedc schreiben könnte: Home Assistant protokolliert jeden anderen Wert als Fehler. eedc meldet die Entität stattdessen über einen eigenen Verfügbarkeits-Kanal als nicht verfügbar (unavailable in HA) und schreibt keinen Zustand.

⭐ Warum das wichtiger ist, als es klingt. Bliebe stattdessen einfach der letzte Zustand stehen, bekäme eine Automation ihn weiter als Wahrheit geliefert — ein ausgefallener Preisabruf ließe eedc_guenstige_stunde womöglich dauerhaft auf ON stehen, und das Auto lüde zur teuersten Stunde. Ein fehlender Eingang muss sichtbar sein; „nicht verfügbar” ist die einzige Form, die HA dafür kennt.

Was das für Automationen heißt: Eine Bedingung is_state('binary_sensor.eedc_haus_gunstige_stunde', 'on') (Anlage „Haus” — die Entity-ID trägt deinen Anlagennamen, s. die Automations-Beispiele am Ende von §11) ist bei einem Ausfall von selbst false — sie löst nicht mehr fälschlich aus. Wer den Unterschied zwischen „aus” und „keine Daten” ausdrücklich behandeln will, fragt states(...) == 'unavailable' ab. Für einen gewöhnlichen Sensor gilt das nicht: der zeigt bei fehlendem Wert weiterhin „unbekannt” (unknown) und bleibt verfügbar — dort ist der leere Wert selbst die Aussage.

Stufe 3 je Gerät — Fenster mit Betrag

Diese Sensoren entstehen je Gerät und nur, wenn eedc alle drei Fragen aus vorhandenen Daten beantworten kann: wie viel (die Menge des Geräts), wogegen (Preis- bzw. Überschussreihe) und was kommt heraus (ein Fenster mit Betrag). Fehlt eine Antwort, fehlt der Sensor.

Sensor	Einheit	Bedeutung
wp_warmwasser_fenster_ab	Zeitstempel	Beginn des günstigsten 2-Stunden-Fensters heute für den Ø-Warmwasserstrom je Tag (letzte drei abgeschlossene Monate). Attribute: bis, kosten_cent_kwh, kosten_cent, ersparnis_cent_vs_jetzt, menge_kwh, herkunft. ⭐ herkunft sagt, woher die Menge stammt: gemessen (eigener Warmwasser-Zähler) oder abgeleitet (aus dem mitgeschriebenen Betriebsmodus gerechnet). Beides reicht — ohne Warmwasser-Zähler gibt es das Fenster trotzdem. Deckt auch den in der Wärmepumpe verbauten Heizstab: sein Strom läuft über denselben Zähler
wp_heizfenster_stunden	h	Anzahl der Stunden innerhalb der erwarteten Heizzeit, in die sich das Heizprofil günstiger verschieben ließe. Attribute: heizstrom_stundenprofil_kwh (so lang wie die Fenster-Achse, 25 bzw. 48 Slots, aus dem gelernten WP-Profil mit Heizgradtag-Korrektur), guenstige_heizstunden, ersparnis_cent_vs_profil, heizzeit_stunden. ⚠ Was eedc nicht kennt und nicht erfindet: Heizkurve, Vorlauftemperatur, Speichervermögen des Gebäudes. Wie weit eine Anhebung trägt, entscheidet deine Wärmepumpen-Regelung — eedc nennt Fenster und Preisvorteil, nicht die Gradzahl
wp_kuehlfenster_ab	Zeitstempel	Beginn des günstigsten 2-Stunden-Fensters vor der Stunde der Tageshöchsttemperatur (Vorkühlen). Attribute: bis, temperatur_max_um, temperatur_max_c, ueberschuss_kwh_im_fenster, menge_kwh, leistung_kuehlen_zugeordnet. ⚠ Zwei Bedingungen, beide nötig: Der Kühlbetrieb muss einen eigenen Stromzähler haben (eine Kältemenge oder eine gepflegte Kühl-Leistung reicht nicht), und es muss in den letzten drei Monaten Kühlstrom geflossen sein. Kühlen bleibt dabei keine Wärme-Achse — das hier ist Strom-Timing, keine Effizienz-Kennzahl
sonstiges_verbrauch_monat_kwh (je sonstigem Verbraucher)	kWh	Stromverbrauch dieses Geräts im laufenden Monat. Attribute: pv_anteil_prozent, bezug_pv_kwh, bezug_netz_kwh. ⭐ Das ist neu und zugleich Stufe 1: Für Pool, Sauna, Trockner oder einen Heizstab mit eigenem Zähler exportierte eedc bisher keinen einzigen Energiewert
sonstiges_fenster_ab (je sonstigem Verbraucher)	Zeitstempel	Günstigstes 2-Stunden-Fenster für den Ø-Tagesverbrauch dieses Geräts. Attribute: bis, kosten_cent_kwh, menge_kwh, ersparnis_cent_vs_jetzt

Woher der Preis je Stunde kommt. Der Ausgangspunkt ist dein Tarif, nicht die Börse — preisquelle sagt in jedem Fenster-Sensor, welcher der vier Fälle vorliegt:

preisquelle	Was drinsteht
vertrag	Der Arbeitspreis deines Tarifs, exakt. Für einen Festpreis ist das derselbe Wert in jeder Stunde
zeitfenster	Der Preis des Zeitfensters, das die jeweilige Stunde deckt (Hoch-/Niedertarif, §14a)
boerse_plus_aufschlag	Dynamischer Tarif: (1 + USt) × Börsenpreis + Aufschlag. Der Aufschlag ist abgeleitet — s. den nächsten Absatz
boersenpreis	Dynamischer Tarif ohne ableitbaren Aufschlag: der nackte Börsenpreis als ausdrücklich beschriftete Näherung. Netzentgelte und Abgaben fehlen darin

⭐ Wie eedc den Aufschlag eines dynamischen Tarifs findet — ohne dass du ihn pflegst. Die Annahme ist einfach: dein Endpreis ist der Börsenpreis plus ein über den Vertrag gleichbleibender Anteil. Diesen Anteil rechnet eedc aus, was ohnehin da ist, in dieser Reihenfolge:

1. Aus deiner Abrechnung — der letzte abgerechnete Monat innerhalb deines aktuellen Tarifs: dein Monats-Durchschnittspreis minus dem (verbrauchsgewichteten) Börsenmittel desselben Monats. Attribut aufschlag_quelle: abrechnung 2026-08.
2. Aus gemessenen Stunden — wenn du einen Strompreis-Sensor zugeordnet hast (Tibber, aWATTar): der mittlere Abstand zwischen gemessenem Endpreis und Börsenpreis der letzten sieben Tage (mindestens 24 Stunden). Attribut aufschlag_quelle: sensor 7 tage.
3. Gar nicht — dann bleibt der nackte Börsenpreis stehen, und aufschlag_quelle sagt keiner.

Es gibt kein Feld dafür, das du ausfüllen müsstest. Trägt dein Vertrag einen Deckel oder eine Staffel, bekommst du einen Durchschnitt — und aufschlag_basis sagt, worauf er beruht.

⚠ In einer Stunde mit Überschuss sinkt der Preis anteilig: Wer dort zusätzlich verbraucht, verdrängt Einspeisung und keinen Netzbezug — bei 3 kWh Überschuss kostet die erste kWh nichts. Deshalb liegt ein Fenster mittags oft vor dem Preistal in der Nacht. Liegt gar kein Preis vor (kein Tarif hinterlegt), entstehen Fenster nur innerhalb der Überschuss-Stunden, und preisquelle sagt keine.

⛔ Bis v4.0.49 stand hier der Börsenpreis für alle — auch für einen Haushalt mit festem Arbeitspreis, der den Börsenpreis nie zu Gesicht bekommt. Die damalige Begründung („ein fester Aufschlag verschiebt jede Stunde um denselben Betrag und ist deshalb für die Fensterwahl neutral”) hält nicht, sobald Überschuss im Spiel ist: der Überschussanteil mindert den Preis anteilig, ein Aufschlag verschiebt die Überschuss-Stunden also weniger als die übrigen — und die Reihenfolge der Fenster kann kippen.

Wie eedc eine Stunde beschriftet. Jede Stundenangabe in diesen Sensoren sagt, ob sie einen Beginn oder ein Ende meint. Das ist nötig, weil eedc in Stunden-Intervallen rechnet: Der Slot „14” ist die Stunde von 13:00 bis 14:00 (dieselbe Konvention wie im HA-Energie-Dashboard und bei jedem Stromzähler — ein Zählerstand um 14:00 gehört zur Stunde davor).

Art	Attribute
Beginn — ab wann etwas gilt	ab, seit, stunden, stunde_von, naechste_negative_ab, stunde_max_mittel, guenstige_heizstunden
Ende — bis wann gerechnet wurde, wann etwas erreicht ist	bis, stand, frist, stunde_bis, bis_stunde, alles auf _um (speicher_voll_um, min_soc_um)

Ein stundenprofil_*-Attribut trägt 24 Werte je Tag, Index 0 ist die Stunde von 23:00 des Vortags bis 00:00 — genau wie stundenprofil_kwh der Prognose-Sensoren. Jede dieser Reihen nennt das im Attribut slot_konvention: backward.

⛔ Bis v4.0.49 lagen fünf dieser Angaben eine Stunde daneben (vier zu spät, stand eine voraus): die Fenster-Achse folgte der Börse, die stundenweise vorwärts beschriftet ist, während alle anderen Reihen rückwärts liegen. Wer eine Automation auf die alten Zeiten gebaut hat, verschiebt sie um eine Stunde.

Attribute je Verbrauchs-Sensor: profil_typ und profil_tage. eedc führt zwei Verbrauchsmodelle, und das bleibt so: die Stundenreihen für heute stammen aus dem 7-Tage-Profil der Live-Kachel, die Speicher-Simulation hinter „Speicher voll um” und der Arbitrage-Vorschlag aus einem gewichteten 8-Wochen-Profil. Sie beantworten verschiedene Fragen. Jeder Sensor nennt sein Modell — wer zwei Zahlen verrechnet, sieht damit, ob sie aus derselben Annahme stammen.

Wann ein Sensor entity_category: diagnostic trägt

Home Assistant meint damit „schreibgeschützte Systemausgaben über den Zustand der Hardware” (Batteriestand, Signalstärke, Laufzeit, Firmware). eedc hat keine Hardware — das Gegenstück ist der Zustand der eedc-Instanz und ihrer Datenlage, nicht der Zustand deiner Anlage:

Kategorie	Was sie in eedc trägt
ohne Kategorie (Standard)	Alles, was eine Aussage über die Anlage macht: Mengen, Geld, CO₂, Kennzahlen, Prognosen, Preise — und auch Stammdaten wie die Investitionssumme. Diese Sensoren gehören aufs Dashboard.
diagnostic	Aussagen über eedc selbst: Letzter Import (Jahr/Monat/Monatsname) und Erfasste Monate. Sie beantworten „hat eedc aktuelle Daten?”, nicht „wie läuft die Anlage?”.
config / system	eedc exportiert nichts Steuerbares — beide bleiben ungenutzt.

⚠ Die Testfrage vor jeder neuen Definition: Beschreibt der Wert die Anlage oder eedc? Die Investitionssumme etwa ist ein Stammdatum der Anlage und deshalb kein Diagnose-Wert — auch wenn sie sich nie ändert.

Neu je Wärmepumpe/Klimaanlage: wp_betriebsmodus — der aktuelle Betrieb im Klartext (Heizen · Kühlen · Entfeuchten · Lüften · Aus · Unbestimmt), aus der zugeordneten climate-Quelle über den eedc-Kanon normalisiert. Liefert dein Gerät zusätzlich hvac_action (den Ist-Betrieb), verfeinert der den eingestellten Modus: Nennt er eine Richtung, hat er Vorrang — steht dort Leerlauf (idle), bleibt dein eingestellter Modus stehen, denn ein taktendes Gerät verliert seine Betriebsart nicht. Ohne zugeordnete Quelle gibt es den Sensor nicht — eedc behauptet keinen Modus, den es nicht kennt.

wp_ersparnis_euro und wp_cop_durchschnitt je Wärmepumpe (ab 05.09.2026 dieselbe Rechnung wie Hub und Cockpit): Die Ersparnis kommt aus derselben Layer-Formel wie der Komponenten-Hub — je Monat mit dem Tarif seines Stichtags, mit dem Monats-Gaspreis, mit den fixen Zusatzkosten der Altheizung, und ohne den Kühlstrom (Kühlen ersetzt keine Heizung; das Attribut berechnung nennt den herausgehaltenen Betrag). Ist die Wärme geschätzt (Strom × JAZ) oder hängt ein zweiter Erzeuger am Wärmezähler, trägt der Sensor den Vorbehalt als Attribut vorbehalt — dieselben Worte wie unter der Ersparnis im Hub; in Einstellungen → Integration → MQTT-Export steht er unter der Berechnung. Die Arbeitszahl kennt dieselben Sperren wie der Hub (geschätzte Wärme, Heizstab-Fremdanteil, zweiter Erzeuger). Für den Strom je Betriebsart gibt es Sensoren für Heizen, Kühlen und Warmwasser; Lüften und Entfeuchten haben bewusst keinen — sie sind Mengen ohne Kennzahl (Cockpit und Hub zeigen sie), und eine Automation braucht sie nicht.

Monate vor deinem ersten Stromtarif (wp_ersparnis_euro, e_auto_ersparnis_vs_benzin_euro, ab 12.10.2026): Gilt in einem Monat noch kein Tarif, rechnen beide Sensoren mit der Vorbelegung 30 ct/kWh — derselbe Preis wie im Cockpit und in der Meldung des Daten-Checkers, über MQTT und REST gleich. Bis dahin nahm MQTT dafür den jüngsten Tarif-Eintrag (auch einen Wärmepumpen-, Wallbox- oder künftigen Tarif) und REST den heutigen Tarif; wer solche Monate hat, sieht einmalig einen Sprung in der Langzeitstatistik. Der Handgriff steht beim Daten-Checker: beim ältesten Tarif das „Gültig ab” auf den Beginn der Daten setzen.

Derselbe Monatspreis für die Anlagen-Sensoren und den gepflegten Ø (ab 12.10.2026): Auch Jahresersparnis, ROI und Amortisation der Anlage (über die bisherige Wärmepumpen- und E-Auto-Ersparnis) rechnen Monate vor dem ersten Tarif jetzt mit der Vorbelegung 30 ct statt mit dem heutigen Tarif. Und pflegst du im Monatsabschluss einen Ø-Strompreis, aber keinen eigenen Wärmepumpen-Tarif, nimmt wp_ersparnis_euro (und die Wärmepumpen-Ersparnis in ROI und Amortisation) diesen Ø — wie Cockpit und Wärmepumpen-Hub — statt des Tarif-Arbeitspreises; mit eigenem Wärmepumpen-Tarif bleibt es bei dessen Preis. Wer solche Monate oder einen gepflegten Ø ohne eigenen Wärmepumpen-Tarif hat, sieht in diesen Sensoren einmalig einen Sprung in der Langzeitstatistik.

Ein Sensor, der seinen Wert verliert, bleibt nicht stehen (ab 05.09.2026): Kann eedc einen Wert in einem Lauf nicht mehr bilden — die Arbeitszahl nach einem eingetragenen Fremdanteil, die Ersparnis nach „nichts ersetzt”, ein Betriebsart-Sensor nach dem Entfernen seiner Quelle, der Speicher-Wirkungsgrad über 100 % —, setzt eedc den Sensor in Home Assistant auf unbekannt, statt den letzten Wert liegen zu lassen. Eine gesperrte Kennzahl trägt dabei ihren Grund im Attribut grund (dieselben Worte wie im Hub). Die Langzeitstatistik bekommt an dieser Stelle eine Lücke — das ist die richtige Aussage, keine Störung. Bis dahin blieb der letzte publizierte Wert stehen und lief stündlich in die Statistik weiter. Was nie erfasst war, bekommt weiterhin keinen Sensor.

⏱ Aktualisierung im Publish-Takt (Standard 60 Minuten, einstellbar). Für einen Modus, der in der Praxis saisonal gestellt wird, ist das genug; wer sekundengenau steuern will, liest die climate-Entität direkt. Was es nur von eedc gibt, ist die über die Stunde stabilisierte, auf den Kanon gebrachte Aussage — und dieselbe Einteilung, nach der eedc den Strom aufteilt.

Wertsemantik netto_ertrag_euro (ab v4.0): Der Sensor trägt den kanonischen Netto-Ertrag aus dem Finanz-Aggregat-SoT: Einspeiseerlös + EV-Ersparnis + BKW-Ersparnis + Sonstige-Netto (Erträge − Ausgaben aus den Sonstigen Positionen, inklusive der auf Anlage-Ebene erfassten Positionen ab v4.0). Der Sensor-Name und die Einheit sind unverändert; nur der Wert enthält jetzt die Sonstigen Positionen. Achtung: die frühere Kurzformel „Einspeiseerlös + EV-Ersparnis” (noch als statisches formel-Label in der Definition) beschreibt nur zwei der vier Bausteine — maßgeblich ist die Summe in Berechnungen §3.2. Der USt-Eigenverbrauchs-Abzug (nur bei Regelbesteuerung) ist seit der #326-Inventur ebenfalls enthalten — ha_export.py rechnet netto_ertrag -= ust_eigenverbrauch über denselben SoT-Helper wie Cockpit und Aussichten. (Bis dahin stand hier das Gegenteil: „bleibt eine Cockpit-Zusatzlogik und ist im Export-Sensor nicht enthalten.” Das war der Stand vor v4.0; die Zeile ist beim Fix nicht mitgezogen worden.)

Ergänzung 2026-07-31 (N-13): Bei Anlagen mit einem Dienstwagen (E-Auto oder Wallbox mit „ausschließlich dienstliches Laden”) zieht der Sensor jetzt auch die dienstlichen Ladekosten ab — bis dahin tat er das als einzige der drei Sichten nicht und stand damit über der Cockpit-Kachel, auf die er sich bezieht. Für diese Anlagen fällt der Wert einmalig; alle anderen sind unberührt. Formel und Begründung: Berechnungen §3.10.

Damit nennt der Sensor alle vier Abzüge/Bausteine der Cockpit-Kachel — Einspeiseerlös, EV-Ersparnis, BKW-Ersparnis, Sonstige-Netto, abzüglich Netzbezugskosten, USt-Eigenverbrauch und dienstlicher Ladekosten. Er ist mit ihr deckungsgleich.

Wertsemantik amortisation_jahre · roi_prozent · jahres_ersparnis_euro (ab v4.0.12): Nenner aller drei ist der Kapitaleinsatz — relevante Anschaffungskosten plus einmalige Ausgaben aus dem Monatsabschluss minus einmalige Erträge (Förderung, THG-Quote). Vorher wurde eine einmalige Ausgabe wie eine jährlich wiederkehrende Belastung vom Zähler abgezogen (eine Reparatur verlängerte die Amortisation dauerhaft und wurde jedes Folgejahr schlechter), ein einmaliger Ertrag wurde umgekehrt jedes Prognosejahr gutgeschrieben. Zweite Korrektur an derselben Rechnung: jeder Ersparnis-Posten wird mit seiner eigenen Laufzeit hochgerechnet, nicht mit der Monatszahl der Anlage — eine später angeschaffte Komponente wurde im Zähler zeitanteilig verdünnt, während ihre Kosten voll im Nenner standen.

⚠ Die drei Sensoren springen dadurch einmalig (an der Referenzanlage 26,4 → 18,5 Jahre); in der Langzeitstatistik ist das ein Sprung an einem Tag, es gehen keine Daten verloren. netto_ertrag_euro ist unberührt — die Zeitraum-Bilanz rechnet unverändert. Der ausgeschriebene Rechenweg im Attribut nennt seit derselben Version jeden Posten mit seiner Monatszahl und den Betriebskosten-Abzug; vorher wich er um mehrere hundert Euro vom Wert daneben ab. Herleitung: Berechnungen §3.6, Begriffe im Glossar.

Wertsemantik co2_ersparnis_kg (ab v4.0, DI-2/DI-2-B): Der Sensor trägt die volle CO₂-Bilanz aus dem kanonischen Helfer berechne_co2_bilanz — PV-Eigenverbrauch (inkl. der Erzeugung von BKW/sonstigen Erzeugern hinter dem Zähler) + Wärmepumpe (vermiedenes Gas mit η_gas = 0,90 minus WP-Strom-CO₂) + E-Mobilität (vermiedener Benziner minus Netzladung). Damit ist er exakt deckungsgleich mit der Cockpit-CO₂-Kachel (früher rechnete der Sensor nur PV-Eigenverbrauch × Strom-Faktor). Ein sonstiger Erzeuger (z. B. BHKW) zählt in EV/Autarkie, und sein selbst verbrauchter Strom gilt — wie im Geldwert — als vermiedener Netzstrom (0,38 kg/kWh); seine eigene Emission (etwa das Gas eines BHKW) zieht eedc nicht ab, weil es sie nicht kennt. Herleitung: Berechnungen §3.8.

Wertsemantik autarkie_prozent / eigenverbrauch_quote_prozent (ab v4.0, DI-2-B): Beide Quoten werden identisch zum Cockpit gerechnet und beziehen die Erzeugung hinter dem Zähler ein (erzeugung_hinter_zaehler_kwh = PV inkl. Balkonkraftwerk + sonstige Erzeuger, die in denselben Hauszähler speisen). Der Nenner der Eigenverbrauchsquote ist diese Gesamt-Erzeugung, nicht „nur PV”. Der spezifische Ertrag bleibt bewusst eine reine PV-Kennzahl (nur pv_erzeugung).

Spezifischer Ertrag — warum nicht einfach kWh ÷ kWp? Der Sensor ist annualisiert und damit deckungsgleich mit der Cockpit-Kachel: saisonal gewichtet (PVGIS-Monatsverteilung) und mit der pro Monat tatsächlich aktiven PV-Leistung (Erweiterung/Teil-Rückbau wird korrekt gewichtet). Die naive Division Gesamterzeugung ÷ heutiges kWp würde bei 3 Jahren Historie etwa das Dreifache des gewohnten Jahreswerts anzeigen.

Woher die kWp im Nenner kommt (ab v4.0.2): aus dem Feld Leistung (kWp) der jeweiligen Investition; ist es leer, aus den Detail-Feldern der Komponente (kwp/leistung_kwp, bei Balkonkraftwerken auch leistung_wp × anzahl). Vorher zählte nur das Leistungsfeld — bei importierten oder sehr alten Komponenten stand dort nichts, der Nenner war zu klein und der Sensorwert entsprechend zu hoch. Wer das betrifft, sieht nach dem Update einen einmaligen Sprung nach unten auf den richtigen Wert; Cockpit-Kachel und Sensor bleiben dabei deckungsgleich.

PV-Prognose-Sensoren (eedc_prognose_*)

Quelle ist immer die eedc-eigene Prognose (OpenMeteo × Korrekturprofil) — nie Solcast/SFML, denn deren Werte liegen über die jeweilige HA-Integration ohnehin nativ in HA (kein Doppel-Export, keine Drift).

Die Korrektur erfolgt pro Stunde über die Korrekturprofil-Kaskade (Sonnenstand × Wetter → Saison-Stunde → Sonnenstand → Skalar; bei Anlagen ohne gelerntes Profil greift wie bisher der Lernfaktor-Skalar). Der Tagessensor ist dabei stets die Σ seiner korrigierten Stundenwerte — Sensor-State und stundenprofil_kwh-Attribut passen exakt zusammen. Dieselbe Berechnung speist die Spalte „eedc” im Prognosen-Vergleich: App-Ansicht und HA-Sensor zeigen denselben Tageswert.

Sensor	Bedeutung
eedc_prognose_heute_kwh	Kanonische Tagesprognose (== App-Anzeige): die volle Prognose für den ganzen Tag, nicht IST + Rest. Ändert sich, wenn OpenMeteo einen neuen Modelllauf liefert. Trägt das Stundenprofil des Tages als Attribut stundenprofil_kwh (24 Werte; Slot N = Energie der Stunde N−1 → N).
eedc_prognose_rest_today_kwh	Echter Rest: Prognose der verbleibenden Stunden ab jetzt (ohne IST) — die laufende Stunde geht anteilig nach den noch verbleibenden Minuten ein (#339), der Wert sinkt also gleichmäßig statt in Stundensprüngen. Der Steuerungswert für Automationen — „wie viel PV kommt heute noch?”
eedc_prognose_day_plus_1/2/3_kwh	Tagesprognose morgen / übermorgen / in 3 Tagen. Trägt jeweils das korrigierte Stundenprofil des Tages als Attribut stundenprofil_kwh (24 kWh-Werte, Slot-Konvention wie oben) — z. B. für Lade-Planung per Template. Werte ändern sich, wenn OpenMeteo einen neuen Modelllauf liefert (alle paar Stunden) oder das gelernte Korrekturprofil aktualisiert wird (nächtlich) — stundenlang unveränderte Werte sind normal.
eedc_speicher_voll_um	Uhrzeit, zu der der Speicher voraussichtlich voll ist (Simulation ab aktuellem Ladestand, mit dem gepflegten Wirkungsgrad — bei mehreren Speichern dem niedrigsten). Rechnet mit dem gewichteten 8-Wochen-Verbrauchsprofil — nicht mit dem 7-Tage-Profil von eedc_verbrauchsprognose_heute_kwh; die Attribute profil_typ (gewichtet_8_wochen), profil_wochen, profil_halbwertszeit_tage, profil_stufe, profil_tage und verbrauch_annahme_kwh nennen die Annahme (Details in §8a). Ohne brauchbare Historie: profil_typ: kein_profil, verbrauch_annahme_kwh: 0. ⭐ Startannahme (V1, 22.09.2026): Die Simulation beginnt bei der zuletzt von HA verdichteten Stunde — und rechnet von ihr nur die halbe Stunde, weil der Startwert ein Stundenmittel ist und damit die Mitte dieser Stunde beschreibt. Die Attribute sim_start_stunde und sim_start_anteil (0,5 bzw. 1,0) nennen sie. Bis 4.0.50 startete sie bei der laufenden Uhrzeit und rechnete diese Stunde ganz; der gemeldete Zeitpunkt kann sich dadurch um bis zu eine halbe Stunde verschieben. Das Textformat „HH:MM“ bleibt unverändert.

Vormittag/Nachmittag: eigene VM/NM-Sensoren gibt es bewusst nicht — beides ist per HA-Template direkt aus stundenprofil_kwh ableitbar (z. B. {{ state_attr('sensor.…_day_plus_1_kwh', 'stundenprofil_kwh')[:13] | sum }} für die Stunden bis 12 Uhr).

Börsenpreis-Trigger (eedc_preis_*)

Grundlage ist der Day-Ahead-Börsenpreis (nicht der Anbieter-Endpreis — der variiert je Vertrag/Region, die Kurvenform ist dieselbe). Tag- und Nacht-Fenster werden solar-basiert getrennt bewertet (Sonnenauf-/-untergang, wandert saisonal).

Welcher Tag gemeint ist: der Kalendertag der Strommarkt-Zeitzone (CET/CEST für DE und AT) — Stunde 0 ist die Stunde nach Mitternacht deiner Uhr, unabhängig davon, in welcher Zeitzone der eedc-Container läuft. Bis v4.0 wurde stattdessen ein UTC-Tag abgefragt: Die Stunden 0 und 1 trugen dadurch die Preise des Folgetages (in der Winterzeit die Stunde 0), und in einem Container ohne gesetzte Zeitzone lagen alle Stunden um denselben Betrag daneben. An den beiden Umstellungstagen hat das Rang-Profil folgerichtig 23 bzw. 24 Einträge — im Oktober zählt die erste der beiden Zwei-Uhr-Stunden.

Wann der Wert wechselt: mit dem MQTT-Versand, und der läuft an der Uhr — bei der Voreinstellung (alle 60 Minuten) also zur vollen Stunde, bei kürzeren Abständen im passenden Raster (:00, :15, :30, :45). Bis dahin lief der Versand ab dem Startzeitpunkt des Add-ons durch; der neue Preis kam damit um einen Versatz zu spät an, den allein der letzte Neustart bestimmte (gemeldet: 09:12:56 und, nach einem Update, 11:08:02). Ein Intervall, das nicht auf die Uhr passt (z. B. 90 Minuten), behält seinen freien Takt — dort würde jede Ausrichtung den eingestellten Abstand verändern.

Günstig-Definition: Eine Stunde gilt als günstig, wenn ihr Preis unter der Günstig-Schwelle liegt — standardmäßig 10 % unter dem Tagesdurchschnitt ohne die 3 teuersten Stunden („optimierter Ø”). Der Prozentsatz ist je Anlage einstellbar (MQTT-Export-Seite). Ohne die Schwelle wären die „günstigsten” Stunden rein relativ — erzwungener Verbrauch oder Netzladung in einer kaum billigeren Stunde ergibt keinen Sinn.

Rang und „günstig” sind zwei verschiedene Aussagen (ab v4.0.10). Der Rang beantwortet „gehört diese Stunde zu den fünf billigsten ihres Fensters?” und ist deshalb bei 5 gedeckelt. Günstig beantwortet „liegt sie unter der Schwelle?” und ist es nicht: liegen sieben Nachtstunden unter der Schwelle, meldet der Zähler auch sieben. Bis v4.0.9 zählte er nur die Ränge und war damit ebenfalls bei 5 gedeckelt — als Anzeige stimmig, als Divisor in einer Automation zu klein.

Was 0 % bedeutet: Der Prozentsatz gibt an, wie weit unter dem optimierten Ø eine Stunde liegen muss. Bei 0 % liegt die Schwelle damit genau auf dem Ø — günstig ist dann alles, was unter dem Tagesdurchschnitt (ohne die 3 Peaks) liegt. Die Schwelle ist also nicht abgeschaltet, sie ist nur nicht zusätzlich abgesenkt. (Bis v4.0 stand hier „0 % deaktiviert die Schwelle, dann zählen wieder die 5 günstigsten”. Das hat der Code nie getan; der Top-5-Deckel hat den Unterschied verdeckt.)

Sensor	Bedeutung
eedc_preis_rang	Rang der aktuellen Stunde: 1–5 = eine der fünf billigsten ihres Fensters und unter der Schwelle, 99 = teuer/Rest. Attribute: rang_profil (alle 24 Stunden, s. u.), guenstig_schwelle_cent und optimierter_durchschnitt_cent (beide ct/kWh), datum (Kalendertag des Profils) sowie der Morgen-Satz morgen_verfuegbar · datum_morgen · rang_profil_morgen · guenstig_schwelle_cent_morgen · optimierter_durchschnitt_cent_morgen (s. u.).
eedc_preis_guenstige_stunden_anzahl	Anzahl Stunden heute unter der Schwelle (Tag + Nacht) — ungedeckelt
eedc_preis_guenstige_stunden_tag / _nacht	dieselbe Zahl je Fenster
eedc_preis_aktuell_cent	Day-Ahead-Börsenpreis der laufenden Stunde
eedc_preis_tages_durchschnitt_cent	Ø aller heutigen Preis-Stunden, ohne jeden Ausschluss — was der Strom heute im Mittel kostet. Nicht die Bezugsgröße der Günstig-Schwelle
eedc_preis_optimierter_durchschnitt_cent	Ø der heutigen Preise ohne die 3 teuersten Stunden — die Bezugsgröße der Schwelle
eedc_preis_abstand_prozent	Abstand des aktuellen Preises zu diesem Ø. Negativ = billiger als der Ø, positiv = teurer. Bezugsgröße ist der Betrag des Ø, damit das Vorzeichen auch bei negativen Börsenpreisen stimmt.
eedc_preis_abstand_cent	Derselbe Abstand in ct/kWh — die Größe, die sich auf den eigenen Endpreis übertragen lässt (s. u.). Negativ = billiger.

⚠ Zwei Durchschnitte, zwei Fragen — nicht verwechseln. eedc_preis_tages_durchschnitt_cent sagt, was der Strom heute im Mittel kostet; eedc_preis_optimierter_durchschnitt_cent sagt, ab wann sich das Laden lohnt. Die Günstig-Schwelle und beide Abstands-Größen beziehen sich auf den zweiten, nie auf den ersten. Wer in einer Automation den Tagesschnitt meint, nimmt den ersten (rapahl-PN 2026-08-23).

Die vier letzten sind für eigene Preis-Regeln da (v4.0.10, Wunsch aus der Tester-Runde): „nur entladen, wenn der Strom gerade teurer ist als der Tagesschnitt” ist damit eine Bedingung auf eedc_preis_abstand_prozent > 0 — ohne Template und ohne dass eedc eine Lade-/Entlade-Strategie vorgibt.

Prozent oder Cent? Beide, und sie sagen Verschiedenes

Der Prozentwert misst gegen den Ø dieses Tages: −50 % heißt „halb so teuer wie der Tagesschnitt”. Er ist über Tage hinweg vergleichbar, aber nicht auf deinen Endpreis übertragbar.

Der ct-Wert ist es. Denn du zahlst nicht den Börsenpreis, sondern Börsenpreis plus feste Bestandteile (Netzentgelt, Abgaben, Marge). Dieser Aufschlag verschiebt Stundenpreis und Tagesmittel um denselben Betrag — die Differenz bleibt gleich, der Prozentwert nicht. An einem echten Tag (Ø 9,92 ct): die billigste Stunde liegt −9,93 ct unter dem Mittel, auf der Börsenkurve wie auf dem Endpreis; in Prozent sind das −100,1 % bzw. −33,2 %. Eine Prozentzahl, die für beide Welten dasselbe bedeutet, kann es folglich nicht geben.

⚠ Was −100 % NICHT heißt: nicht „billigste Stunde des Tages”, sondern „Preis = 0 ct”. Der Wert kann unter −100 % fallen — jeder negative Börsenpreis tut das. Wer „ist das eine der besten Stunden?” fragt, nimmt eedc_preis_rang (1–5), nicht den Prozentwert.

Faustregel: Schwellen für Automationen (< -5 ct) und alles, was mit deinem Tarif zu tun hat → ct. Tagesübergreifende Vergleiche → Prozent. „Eine der günstigsten Stunden” → Rang.

Das Rang-Profil als Attribut trägt je Stunde fünf Angaben: stunde, rang, preis_cent, unter_schwelle und abstand_cent. preis_cent/unter_schwelle gibt es ab v4.0.10, abstand_cent seit dem ct-Sensor — vorher stand dort nur der Rang, und damit ließ sich in HA weder eine eigene Schwelle noch ein eigenes Zeitfenster auswerten.

Morgen steht daneben, sobald es ihn gibt

Die Day-Ahead-Auktion veröffentlicht die Preise des Folgetages gegen 13 Uhr. Ab dann tragen die Attribute von eedc_preis_rang einen zweiten Satz für morgen — dieselbe Gestalt wie heute, damit eine Automation beide mit demselben Code liest:

Attribut	Bedeutung
morgen_verfuegbar	true/false — immer vorhanden. Vor der Auktion false; du musst also nicht auf ein fehlendes Attribut prüfen
datum_morgen	Kalendertag, für den der Morgen-Satz gilt
rang_profil_morgen	24 Stunden in derselben Form wie rang_profil
guenstig_schwelle_cent_morgen	die Günstig-Schwelle des Folgetages
optimierter_durchschnitt_cent_morgen	dessen Bezugsgröße

⚠ Jeder Tag hat 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 günstige Stunde ausweisen und am billigen fast alle. Wer das Morgen-Profil auswertet, nimmt deshalb guenstig_schwelle_cent_morgen — nicht die von heute.

Warum datum und datum_morgen dabeistehen: ein Profil ohne seinen Kalendertag ist nach Mitternacht nicht von einem stehengebliebenen zu unterscheiden. Eine Automation, die dann auf „morgen” plant, plant auf gestern.

Vor 13 Uhr fragt eedc gar nicht an. Das ist keine Sparmaßnahme, sondern der Marktrhythmus: vor der Auktion gibt es die Zahlen nicht.

Eigene Kriterien: Wer eine andere Schwelle bevorzugt, stellt den Prozentsatz auf der Export-Seite um — oder rechnet in HA per Template direkt auf den Attributen (rang_profil mit den Stundenpreisen, optimierter_durchschnitt_cent). eedc liefert bewusst nur die Trigger-Werte; die Lade-/Entlade-Strategie baut jeder selbst in seinen Automationen.

Drei Vorlagen für den HA-Template-Editor

Der Absatz darüber sagt, dass sich mit rang_profil eigene Kriterien rechnen lassen — er sagte bisher nicht, wie. Das hat gefehlt: Wer nur die Sensorliste durchsieht, findet neun eedc_preis_*-Sensoren und darunter keinen Höchstpreis und keine Rang-Preise, und schließt daraus, dass eedc sie nicht liefert. Sie sind da — als Attribut, nicht als Sensor.

Die drei Vorlagen lassen sich unverändert in Entwicklerwerkzeuge → Vorlage kopieren. Wer eine davon als Sensor haben will, setzt sie in configuration.yaml unter template: - sensor: mit state: >. Sie nehmen eine Anlage namens „Haus” an: Home Assistant bildet die Entity-ID aus dem Gerätenamen eedc - <Anlage> und dem Anzeigenamen des Sensors („Börsenpreis-Rang”, Umlaut ohne Punkte), also sensor.eedc_haus_borsenpreis_rang — an einer Anlage „Winterborn” heißt er sensor.eedc_winterborn_borsenpreis_rang. Setz deinen Anlagennamen ein; welche ID dein Sensor trägt, zeigt Einstellungen → Geräte & Dienste → MQTT, Gerät „eedc - dein Anlagenname”.

1) Der Tageshöchstpreis

{%- set p = state_attr('sensor.eedc_haus_borsenpreis_rang','rang_profil') or [] -%}
{{ (p | map(attribute='preis_cent') | max | round(2)) if p else 'unbekannt' }}

Für morgen dasselbe mit rang_profil_morgen — aber erst, wenn morgen_verfuegbar true ist.

2) Die Ränge mit ihren Preisen

{%- set p = state_attr('sensor.eedc_haus_borsenpreis_rang','rang_profil') or [] -%}
{%- for s in p | rejectattr('rang','eq',99) | sort(attribute='stunde') %}
{{ '%02d'|format(s.stunde) }}:00 Uhr | Rang {{ s.rang }} | {{ s.preis_cent | round(2) }} ct
{%- endfor -%}

⚠ Es kommen bis zu ZEHN Zeilen, nicht fünf — und „Rang 1” kann zweimal vorkommen. Tag- und Nachtfenster werden getrennt bewertet (Grenze: Sonnenauf-/-untergang), jedes vergibt seine eigenen Ränge 1–5. An einem Tag, an dem die PV-Mittagsdelle die Nachtstunden aus der Rangliste drängt, kommen dagegen nur fünf. Wer auf rang <= 5 filtert, filtert nicht die fünf billigsten Stunden des Tages — dafür sortiert man nach preis_cent.

3) Die beste Lade-/Entladespanne, über die Tagesgrenze hinweg

{%- set eta = 0.90 -%}
{%- set heute  = state_attr('sensor.eedc_haus_borsenpreis_rang','rang_profil') or [] -%}
{%- set morgen = state_attr('sensor.eedc_haus_borsenpreis_rang','rang_profil_morgen') or [] -%}
{%- set r = namespace(reihe=[]) -%}
{%- for s in heute if s.stunde >= now().hour -%}
  {%- set r.reihe = r.reihe + [{'t': s.stunde, 'p': s.preis_cent}] -%}
{%- endfor -%}
{%- for s in morgen -%}
  {%- set r.reihe = r.reihe + [{'t': s.stunde + 24, 'p': s.preis_cent}] -%}
{%- endfor -%}
{%- set b = namespace(spread=0, lade=none, ent=none) -%}
{%- for a in r.reihe -%}
  {%- for z in r.reihe if z.t > a.t -%}
    {%- if (z.p * eta - a.p) > b.spread -%}
      {%- set b.spread = z.p * eta - a.p -%}
      {%- set b.lade = a -%}{%- set b.ent = z -%}
    {%- endif -%}
  {%- endfor -%}
{%- endfor -%}
{%- if b.lade is none -%}
keine lohnende Spanne
{%- else -%}
Laden {{ '%02d'|format(b.lade.t % 24) }}:00{{ ' (morgen)' if b.lade.t >= 24 else '' }} zu {{ b.lade.p | round(2) }} ct | Entladen {{ '%02d'|format(b.ent.t % 24) }}:00{{ ' (morgen)' if b.ent.t >= 24 else '' }} zu {{ b.ent.p | round(2) }} ct | Spanne {{ b.spread | round(2) }} ct/kWh
{%- endif -%}

Sie gibt eine Zeile aus (rund 90 Zeichen) und ist damit ohne Nacharbeit als Template-Sensor verwendbar. eta ist dein Speicher-Wirkungsgrad — trag deinen eigenen Wert ein.

Warum die Spanne gerichtet ist: Entladen kann man nur, was vorher geladen wurde. Ein ungerichtetes Tages-Min/Max nennt bei „billig 13 Uhr, teuer 08 Uhr” eine Spanne, die es an diesem Tag nicht mehr gibt. Die Vorlage sucht deshalb nur Paare, bei denen die teure Stunde nach der billigen liegt — und über die Tagesgrenze hinweg, sobald das Morgen-Profil da ist.

keine lohnende Spanne heißt: Es gibt im bekannten Horizont kein Paar, das nach Abzug der Speicherverluste noch etwas übrig lässt. Das ist eine Aussage, kein Fehler — spät am Abend ohne Morgen-Profil ist es der Normalfall.

⚠ Der Tag hat nicht immer 24 Stunden. Am Ende der Sommerzeit fehlt die zweite Zwei-Uhr- Stunde, im Frühjahr die Stunde 2 ganz; rang_profil hat dann 23 Einträge. Alle drei Vorlagen laufen darüber, weil keine auf eine feste Länge prüft — wer eigene baut, prüft es auch nicht.

Drei Automationen, die auf diesen Sensoren aufsetzen

eedc nennt Fenster, Preise und Mengen — schalten tust du. Die drei Beispiele zeigen, wie eine HA-Automation die Sensoren dieser Gruppe liest. Sie sind vollständig, aber jede enthält eine Zeile, die du ersetzen musst: die Entität deines Geräts (Speicher, Wallbox, Heizstab). Wie dein Speicher „nicht entladen” oder „aus dem Netz laden” heißt, weiß nur seine Integration — eedc kennt kein Schaltelement und erfindet keins.

Die YAML-Blöcke sind so geschrieben, dass sie sich unter Einstellungen → Automationen → Neue Automation → ⋮ → In YAML bearbeiten einfügen lassen. Die Entity-IDs darin gelten für eine Anlage namens „Haus” — Home Assistant bildet die ID aus dem Gerätenamen eedc - <Anlage> und dem Anzeigenamen des Sensors, nicht aus seinem Schlüssel: aus eedc_bezugspreis_jetzt_cent an der Anlage „Winterborn” wird sensor.eedc_winterborn_bezugspreis_jetzt, aus dem Schalter „Speicher voll” binary_sensor.eedc_winterborn_speicher_voll; Umlaute fallen weg (borsenpreis_rang, gunstige_stunde). Welche ID dein Sensor trägt, zeigt Einstellungen → Geräte & Dienste → MQTT, Gerät „eedc - dein Anlagenname”. Alle drei nutzen native Bedingungen (numeric_state, state) statt Vorlagen, wo Home Assistant das kann; nur das dritte Beispiel liest eine Stundenreihe und braucht dafür eine Vorlage.

Zwei Eigenschaften der Sensoren, auf die sich die Beispiele verlassen. Erstens: ein binary_sensor wird bei fehlender Grundlage nicht verfügbar — eine Bedingung auf on ist dann von selbst falsch, die Automation schaltet nichts (s. oben). Zweitens: ein Sensor, den eedc nicht bilden kann, fehlt — eedc_speicher_netzladen_kosten_cent gibt es nur für Speicher mit „lädt aus dem Netz”, eedc_abregelung_heute_kwh nur mit gepflegter Wechselrichter-Grenze. Fehlt der Sensor, läuft die Automation ins Leere, ohne Fehler. Prüfe vor dem Bau in Einstellungen → Integration → MQTT-Export, ob er bei dir entsteht.

1) Speicher schonen, solange Netzstrom billiger ist als Speicherstrom

Strom aus dem Speicher kostet die entgangene Einspeisevergütung geteilt durch den Wirkungsgrad (eedc_speicher_strom_kosten_cent, bei der Demo-Anlage 9,8 ct). In einer Stunde, in der der Bezugspreis darunter liegt — bei einem dynamischen Tarif nachts oder bei negativen Börsenpreisen — ist es günstiger, den Speicher zu halten und den Haushalt aus dem Netz zu versorgen. Die Automation vergleicht die beiden Sensoren bei jedem neuen Preis und stellt den Speicher auf „nicht entladen”, solange das gilt.

alias: "eedc — Speicher schonen bei billigem Netz"
description: >
  Solange der Bezugspreis der laufenden Stunde unter den Kosten einer Speicher-Kilowattstunde
  liegt, wird der Speicher nicht entladen. Beide Zahlen kommen von eedc; die Schalt-Entität
  ist die des Speichers.
mode: single
triggers:
  - trigger: state
    entity_id: sensor.eedc_haus_bezugspreis_jetzt
    note: "eedc publiziert zur vollen Stunde einen neuen Preis — das ist der Takt."
actions:
  - if:
      - condition: numeric_state
        entity_id: sensor.eedc_haus_bezugspreis_jetzt
        below: sensor.eedc_haus_speicherstrom_kostet
        note: "Netz billiger als Speicher: halten."
    then:
      - action: select.select_option
        target:
          entity_id: select.speicher_betriebsmodus   # ← Entität deines Speichers
        data:
          option: "Entladung sperren"                # ← Wortlaut deiner Integration
    else:
      - action: select.select_option
        target:
          entity_id: select.speicher_betriebsmodus   # ← Entität deines Speichers
        data:
          option: "Automatik"                        # ← Wortlaut deiner Integration

Bei einem Festpreis greift der then-Zweig praktisch nie (30 ct gegen 9,8 ct) — die Automation ist dann harmlos, aber nutzlos. Sie ist für dynamische Tarife gedacht; dort trägt eedc_bezugspreis_jetzt_cent den Endpreis inklusive abgeleitetem Aufschlag, nicht den nackten Börsenpreis (Attribut preisquelle).

2) Aus dem Netz laden, wenn die Kilowattstunde unter deiner Grenze bleibt

eedc_speicher_netzladen_kosten_cent ist der Bezugspreis geteilt durch den Wirkungsgrad — also das, was eine später entnommene Netz-Kilowattstunde wirklich kostet. Die Grenze legst du in einem Zahlen-Helfer fest (Einstellungen → Geräte & Dienste → Helfer → Zahl, hier input_number.netzladen_grenze_cent); so änderst du sie, ohne die Automation anzufassen. Geladen wird nur, wenn der Speicher nach heutiger Simulation nicht bis Mitternacht reicht — sonst würdest du Netzstrom einlagern, den die PV am Tag ohnehin liefert.

alias: "eedc — Netzladen unter Preisgrenze"
description: >
  Startet die Netzladung, wenn eine aus dem Speicher entnommene Netz-Kilowattstunde unter der
  eigenen Grenze kostet und der Speicher heute nicht bis Mitternacht reicht; beendet sie, sobald
  eine der Bedingungen fällt oder der Speicher voll ist.
mode: single
triggers:
  - trigger: state
    entity_id:
      - sensor.eedc_haus_netzladen_kostet
      - binary_sensor.eedc_haus_speicher_reicht_bis_mitternacht
      - binary_sensor.eedc_haus_speicher_voll
    note: "Jeder dieser drei Sensoren kann die Entscheidung kippen."
actions:
  - if:
      - condition: numeric_state
        entity_id: sensor.eedc_haus_netzladen_kostet
        below: input_number.netzladen_grenze_cent
      - condition: state
        entity_id: binary_sensor.eedc_haus_speicher_reicht_bis_mitternacht
        state: "off"
        note: "Bei »nicht verfügbar« (keine Simulation möglich) wird nicht geladen."
      - condition: state
        entity_id: binary_sensor.eedc_haus_speicher_voll
        state: "off"
    then:
      - action: switch.turn_on
        target:
          entity_id: switch.speicher_netzladen      # ← Entität deines Speichers
    else:
      - action: switch.turn_off
        target:
          entity_id: switch.speicher_netzladen      # ← Entität deines Speichers

Wer stattdessen der Menge folgen will, nimmt eedc_arbitrage_vorschlag_kwh (empfohlene Netzladung heute, mit stunden als Liste der günstigen Stunden) — er entsteht nur, wenn sich Laden und späteres Entladen nach Abzug der Verluste lohnt.

3) Einen Verbraucher in die Abregelung legen

Was der Wechselrichter an seiner Grenze abregelt, entsteht gar nicht erst. Ein Heizstab, eine Poolpumpe oder ein Warmwasserboiler läuft in diesen Stunden also mit Strom, der sonst verloren wäre — billiger als jedes Überschuss-Fenster. eedc_abregelung_heute_kwh trägt in stundenprofil_kwh je Stunde die erwartete Kappung (24 Werte, Index 0 = 23–00 Uhr des Vortags, Index 15 = 14–15 Uhr) und in rest_heute_kwh, was heute noch bevorsteht. Eine Stundenreihe lässt sich nicht nativ lesen — hier ist die Vorlage die richtige Form.

alias: "eedc — Heizstab in die Abregelung"
description: >
  Schaltet den Heizstab ein, solange eedc für die laufende Stunde eine Abregelung an der
  Wechselrichter-Grenze erwartet, und danach wieder aus. Die Reihe ist eine Prognose auf der
  Rohvorhersage (Attribut skala) — Größenordnung und Uhrzeiten, keine Messung.
mode: single
triggers:
  - trigger: state
    entity_id: sensor.eedc_haus_abregelung_heute
    note: "Feuert bei jedem Publish, auch wenn sich nur die Attribute ändern."
  - trigger: time_pattern
    minutes: 1
    note: "Zusätzlich zur vollen Stunde, falls der Publish später kommt."
variables:
  kappung_jetzt_kwh: >-
    {% set p = state_attr('sensor.eedc_haus_abregelung_heute', 'stundenprofil_kwh') or [] %}
    {% set i = now().hour + 1 %}
    {{ (p[i] | float(0)) if p | length > i else 0 }}
actions:
  - if:
      - condition: numeric_state
        entity_id: sensor.eedc_haus_abregelung_heute
        attribute: rest_heute_kwh
        above: 0.5
        note: "Heute steht überhaupt noch eine nennenswerte Kappung bevor."
      - "{{ kappung_jetzt_kwh > 0.2 }}"
    then:
      - action: switch.turn_on
        target:
          entity_id: switch.heizstab                # ← dein Verbraucher
    else:
      - action: switch.turn_off
        target:
          entity_id: switch.heizstab                # ← dein Verbraucher

now().hour + 1 ist der Index der laufenden Stunde: die Reihe ist rückwärts beschriftet (Index 15 = 14:00–15:00), also liegt 14:37 Uhr in Index 15. Um 23 Uhr gibt es keinen Eintrag (er wäre Index 24 — die Stunde gehört schon zur Reihe von morgen), die Vorlage liefert dann 0; für einen PV-Verbraucher ist das kein Verlust. Die Schwellen (0,5 kWh Rest, 0,2 kWh in der Stunde) sind Beispiele — bei einem 3-kW-Heizstab lohnt eine Stunde mit 0,2 kWh Kappung kaum, bei einer Poolpumpe mit 0,5 kW schon.

⚠ Was keins der drei Beispiele tut: einen Live-Wert lesen. eedc_ueberschuss_jetzt_kw ist ein Stundenmittel und bis zu 15 Minuten alt; wer eine Wallbox nach dem aktuellen Überschuss regeln will, braucht dafür die Leistungssensoren seines Zählers, nicht eedc. eedc liefert die Planung für heute — Fenster, Reihen, Preise —, und die drei Beispiele bleiben in genau diesem Rahmen.

---

Allgemeine Regeln für Sensoren

Tagessensoren (Utility Meter)

HA Utility Meter setzen den Zählerstand täglich um 0:00 auf 0 zurück. eedc unterstützt das — sowohl in der HA-History-Auswertung als auch in MQTT Energy Snapshots. Der Monatswechsel-Reset (negativer Delta) wird automatisch erkannt: end_val wird dann direkt als Tageswert verwendet.

Empfehlung: Für MQTT Energy Topics sind Tagessensoren (HA Utility Meter) ideal — sie liefern direkt den Tageswert ohne Delta-Berechnung.

Vorzeichen-Konvention

Kategorie	Positiv	Negativ
PV-Leistung	Erzeugung	— (immer positiv)
Einspeisung	Ins Netz	— (immer positiv)
Netzbezug	Aus dem Netz	— (immer positiv)
Netz-Kombi	Netzbezug	Einspeisung
Batterie-Leistung	Ladung (Senke)	Entladung (Quelle)
E-Auto V2H	Ladung	Entladung ins Haus

⚠️ Manche Wechselrichter liefern das Vorzeichen umgekehrt. In der Datenquellen-Zuordnung gibt es dafür am signierten Leistungs-Feld das ±-Symbol (Vorzeichen umkehren, live_invert) — quellen-unabhängig direkt am Wert.

Einheiten-Konvertierung

Live-Leistungssensoren werden automatisch konvertiert: kW → W, MW → W. Für kWh-Sensoren wird Wh → kWh und MWh → kWh automatisch skaliert. Counter-Felder (siehe §9) bleiben mit Faktor 1.0 — kein automatisches Wh→kWh, da physikalisch keine Energie.

---

Letzte Aktualisierung: 2026-07-25 (v4.0)