Home Assistant · Strompreis und CO2
Zwei gleichwertige Wege zu Strompreis- und CO2-Daten in Home Assistant
Für StrompreisVorhersage gibt es zwei vollständig unterstützte Wege nach Home Assistant: eine native HACS-Integration mit grafischer Einrichtung oder ein klassisches YAML-Paket mit REST-Sensor. Beide nutzen dieselbe API und liefern aktuelle Werte, laufende Zustände und die wichtigsten Zeitfenster.
- HACS-Integration: Einrichtung per UI-Dialog, eigene Entitäten, im HACS-Standard-Store gelistet
- YAML-Paket: REST-Sensor plus Template-Sensoren zum Copy-Paste, funktioniert auch ohne HACS
- ohne API-Key typischer Test mit 48 Stunden, mit API-Key bis 120 Stunden – bei beiden Wegen identisch
Welcher Weg passt zu dir?
Beide Wege greifen auf denselben Summary-Endpunkt zu und liefern inhaltlich dieselben Daten. Der Unterschied liegt in der Einrichtung und Pflege.
packages/ ablegen, fertig. Kein HACS nötig, volle Kontrolle über die YAML-Konfiguration, guter Weg für alle, die ihre Home-Assistant-Config ohnehin per Git verwalten.
Quelloffenes Repository der HACS-Integration: github.com/BackupBaTTerY/energypriceforecast-home-assistant. Beide Wege lassen sich auch parallel betreiben, solange du nicht identische Entity-IDs doppelt anlegst.
Der Home-Assistant-Einstieg bleibt ohne API-Key nutzbar und liefert typischerweise bis zu 48 Stunden. Wenn du größere Verbraucher über mehrere Tage planen möchtest, kannst du Private Pro mit bis zu 120 Stunden 14 Tage kostenlos testen.
Neue Setups sollten https://api.energypriceforecast.eu/api/v1/... verwenden. Die Summary-API liefert keine komplette Preisreihe, sondern einen kompakten Automations-Block mit aktuellem Preis, aktuellem CO2-Wert, bestmöglichem Fenster und Meta-Infos zum Zugriff.
So richtest du die HACS-Integration ein
Die Integration ist im HACS-Standard-Store gelistet – du musst nichts mehr manuell eintragen.
- In HACS nach „Energy Price Forecast EU" suchen und herunterladen, danach Home Assistant neu starten.
- Einstellungen → Geräte & Dienste → Integration hinzufügen, nach „Energy Price Forecast EU" suchen und Markt sowie optionale Einstellungen wählen.
Der Button oben („HACS-Integration hinzufügen") öffnet die Integration direkt in HACS, falls HACS bereits installiert ist.
Prognose und veröffentlichte Preise vergleichen
Die grüne Linie zeigt veröffentlichte Day-Ahead-Preise, Orange die aktuelle Prognose und die blau gestrichelte Linie die zuerst gespeicherte Prognose. Sobald offizielle Preise vorliegen, bleibt die frühere Prognose zum Vergleich sichtbar.
- Aktualisiere Energy Price Forecast EU in HACS auf mindestens 1.12.0 und starte Home Assistant neu. Installiere zusätzlich ApexCharts Card ab 2.1.0 über HACS.
- Ersetze alle drei
sensor.CHANGE_MEdurch dieselbe Preisreihen-Entität aus Entwicklerwerkzeuge → Zustände. Für deinen konfigurierten Gesamtpreis wähle stattdessen die Entität „Aktueller Endkundenpreis“. Füge die YAML unter Dashboard → Bearbeiten → Karte hinzufügen → Manuell ein.
Die Speicherung beginnt erst mit diesem Update und übersteht Neustarts. Werte bleiben bis zum Ende des jeweiligen Markttages erhalten; ältere Prognosen werden nicht rückwirkend hergestellt. captured_at ist der Empfangszeitpunkt in Home Assistant, nicht der Modelllauf. Der Vergleich hat keinen festen Vorhersage-Vorlauf und ist kein unbegrenztes Archiv.
Die Achseneinheit muss zur Sensor-Einheit passen, z. B. EUR/kWh statt ct/kWh. Ein berechneter Endkundenpreis ist keine garantierte Stromrechnung. Ohne Key bleibt der API-Horizont bei bis zu 48 Stunden; für bis zu 120 Stunden nutze die entsprechende Berechtigung und graph_span: 6d. Diese Karte betrifft die HACS-Integration, nicht das REST-Summary-Paket darunter, und verursacht keine zusätzlichen API-Abrufe.
Fertige YAML zum Kopieren
type: custom:apexcharts-card
header:
show: true
title: Energy Price Forecast EU
graph_span: 3d
span:
start: day
now:
show: true
label: Jetzt
yaxis:
- id: price
decimals: 3
apex_config:
title:
text: EUR/kWh
all_series_config:
yaxis_id: price
type: line
curve: stepline
extend_to: false
stroke_width: 2
float_precision: 4
show:
legend_value: false
series:
# Replace ALL three placeholders with the SAME price or retail sensor.
- entity: sensor.CHANGE_ME
name: Offiziell (Day-Ahead)
color: "#43a047"
data_generator: |
const raw = [...(entity.attributes.raw_today ?? []),
...(entity.attributes.raw_tomorrow ?? [])];
const slots = raw.map(e => ({
start: Date.parse(e.start), end: Date.parse(e.end), value: e.value
})).filter(e => Number.isFinite(e.start) && Number.isFinite(e.end)
&& e.end > e.start && typeof e.value === 'number' && Number.isFinite(e.value))
.sort((a, b) => a.start - b.start);
const points = [];
let previousEnd = null;
for (const slot of slots) {
if (previousEnd !== null && slot.start > previousEnd) {
points.push([previousEnd, null], [slot.start - 1, null]);
}
points.push([slot.start, slot.value], [slot.end - 1, slot.value]);
previousEnd = slot.end;
}
return points;
- entity: sensor.CHANGE_ME
name: Aktuelle Prognose
color: "#fb8c00"
data_generator: |
const raw = entity.attributes.raw_forecast ?? [];
const slots = raw.map(e => ({
start: Date.parse(e.start), end: Date.parse(e.end), value: e.value
})).filter(e => Number.isFinite(e.start) && Number.isFinite(e.end)
&& e.end > e.start && typeof e.value === 'number' && Number.isFinite(e.value))
.sort((a, b) => a.start - b.start);
const points = [];
let previousEnd = null;
for (const slot of slots) {
if (previousEnd !== null && slot.start > previousEnd) {
points.push([previousEnd, null], [slot.start - 1, null]);
}
points.push([slot.start, slot.value], [slot.end - 1, slot.value]);
previousEnd = slot.end;
}
return points;
- entity: sensor.CHANGE_ME
name: Gespeicherte Prognose (zuerst empfangen)
color: "#1e88e5"
stroke_dash: 5
data_generator: |
const raw = entity.attributes.raw_forecast_reference ?? [];
const slots = raw.map(e => ({
start: Date.parse(e.start), end: Date.parse(e.end), value: e.value
})).filter(e => Number.isFinite(e.start) && Number.isFinite(e.end)
&& e.end > e.start && typeof e.value === 'number' && Number.isFinite(e.value))
.sort((a, b) => a.start - b.start);
const points = [];
let previousEnd = null;
for (const slot of slots) {
if (previousEnd !== null && slot.start > previousEnd) {
points.push([previousEnd, null], [slot.start - 1, null]);
}
points.push([slot.start, slot.value], [slot.end - 1, slot.value]);
previousEnd = slot.end;
}
return points;
Optional: Karte mit einer KI anpassen
Hilf mir, die ApexCharts-Karte für Energy Price Forecast EU anzupassen. Frage zuerst nach meiner genauen Entity-ID, Sensor-Einheit, HACS-Version, Abrechnungsauflösung (stündlich oder viertelstündlich) und ob ich Basis- oder Endkundenpreise anzeigen will. Fordere keinen API-Key an.
Ab Integration 1.12.0 liefern Preisreihe und Aktueller Endkundenpreis:
- raw_today und raw_tomorrow: veröffentlichte Day-Ahead-Slots.
- raw_forecast: aktuelle Prognose-Slots außerhalb der offiziellen Abdeckung.
Diese drei Listen enthalten {start, end, value}.
- raw_forecast_reference: {start, end, value, captured_at}; zuerst empfangene Prognose für einen damals zukünftigen Slot, lokal gespeichert. Spätere Prognosen oder offizielle Preise überschreiben sie nicht.
Referenzen entstehen erst nach dem Update, überstehen Neustarts und werden nach Ende des jeweiligen Markttages entfernt. captured_at ist der HA-Empfangszeitpunkt, nicht die Modellerstellung.
Zeige offizielle Preise grün, aktuelle Prognosen orange und gespeicherte Prognosen blau gestrichelt auf derselben Achse. Verwende die Einheit des Sensors, ApexCharts Card ab 2.1.0, je Serie data_generator und extend_to: false. Zeichne start bis end, erhalte Datenlücken mit null und behalte echte Null- und Negativpreise. Kopiere keine offiziellen Werte in eine Prognoselinie. Nutze nur die beschriebenen Attribute.
Frage optional nach dem Stunden-/Wochenendplan. Dessen hours-Attribut enthält {start, end, average_value}; markiere diese Zeiten separat, ändere aber keine Ladeplanung. Liefere vollständige YAML für eine manuelle Lovelace-Karte und erkläre, wo sie eingefügt wird. Eine Karte allein schaltet keine Wallbox.
In 5 Minuten zum Ergebnis (YAML-Paket)
Wenn du dich für den YAML-Weg entschieden hast, nimm diese drei Dateien. Die Paketdatei holt die Daten, die Lovelace-Karte zeigt sie an und die Beispiel-Automation demonstriert die eigentliche Nutzung.
is_cheapest_window_now und Restminuten.So sieht das Ergebnis aus
So bindest du das Paket ein
- Lade die Paketdatei herunter und speichere sie als
/config/packages/energypriceforecast.yaml. - Falls Packages noch nicht aktiviert sind, ergänze in
configuration.yamldiesen Block. - Home Assistant neu laden oder einmal neu starten.
- Importiere danach die Lovelace-Karte und optional die Beispiel-Automation.
homeassistant:
packages: !include_dir_named packages
Die Lovelace-Karte kannst du in einem Dashboard über Manuell einfügen. Die Automation kannst du in den Automationen ebenfalls als YAML importieren oder einfach als Vorlage übernehmen.
Welche Entitäten bekommst du danach?
Die Paketdatei legt eine Rohquelle und darauf aufbauend direkt nutzbare Entitäten an. Damit sieht man sofort, ob die API sauber läuft, und kann ohne JSON-Parsing eigene Automationen bauen.
| Entität | Bedeutung | Typischer Einsatz |
|---|---|---|
sensor.energypriceforecast_api | Rohantwort des Summary-Endpunkts inklusive flat, price, co2 und meta. | Debugging und Grundlage für weitere Templates. |
sensor.epf_aktueller_preis | Aktueller Preis im laufenden Slot. Quelle kann Day-Ahead oder Forecast sein. | Preisgesteuerte Wallbox, Wärmepumpe, Boiler. |
sensor.epf_aktuelle_co2_intensitaet | Aktueller CO2-Wert im laufenden Slot. | CO2-orientierte Lastverschiebung. |
binary_sensor.epf_guenstigstes_preisfenster_aktiv | on, wenn das rechnerisch beste Preisfenster bereits läuft. | Direkte Laufentscheidung ohne eigene Zeitvergleiche. |
sensor.epf_restminuten_guenstigstes_preisfenster | Restdauer des aktuell besten Preisfensters. | Schätzen, wie lange ein Verbraucher noch laufen darf. |
sensor.epf_naechstes_volles_preisfenster | Das nächste vollständige Zukunftsfenster für Preis. | Späteres Starten oder Planen. |
sensor.epf_api_key_status | Status des hinterlegten API-Keys. | Schnell sehen, ob 48h oder 120h wirklich greifen. |
sensor.epf_erlaubter_horizont | Serverseitig erlaubter Horizont in Stunden. | Prüfen, ob dein Setup wirklich die gewünschte Länge bekommt. |
Welchen Zeitraum liefert die API genau?
Für Home Assistant ist das Entscheidende nicht nur die URL, sondern auch die fachliche Logik dahinter. Genau das sollte transparent sein.
hours=48. Damit bekommst du den einfachen Testhorizont, der ohne zusätzlichen Schlüssel öffentlich gedacht ist.hours=120 erhöhen, also auf 5 Tage.Wo trägst du den API-Key ein und wie erhöhst du den Horizont?
Beides passiert direkt in der Paketdatei. Du musst keinen zweiten Endpunkt verwenden, sondern nur den Authorization-Header aktivieren und den Stundenwert anpassen.
rest:
- resource: "https://api.energypriceforecast.eu/api/v1/home-assistant/summary?country=at&hours=120&window_hours=4"
scan_interval: 1800
headers:
Accept: "application/json"
Authorization: "Bearer DEIN_API_KEY"
Danach siehst du in sensor.epf_api_key_status, sensor.epf_erlaubter_horizont und sensor.epf_genutzter_horizont, ob dein Key wirklich verwendet wird.
Was bringt der Summary-Endpunkt konkret?
Der Summary-Pfad ist absichtlich für Automationen gebaut. Er spart dir viel eigene Logik, weil du nicht erst stundenlange Reihen parsen musst, um einfache Entscheidungen zu treffen.
| Feld | Bedeutung | Warum es nützlich ist |
|---|---|---|
flat.current_price | Aktueller Preiswert im laufenden Slot. | Direkter Ist-Zustand für Preislogik. |
flat.current_co2_g_kwh | Aktueller CO2-Wert im laufenden Slot. | Direkter Ist-Zustand für CO2-Logik. |
flat.is_cheapest_window_now | Zeigt, ob das beste Preisfenster bereits aktiv ist. | Wichtiger als nur ein Startzeitpunkt. |
flat.cheapest_window_remaining_minutes | Restdauer des laufenden besten Preisfensters. | Nützlich für Laufzeitentscheidungen. |
price.next_full_window.start | Nächstes vollständiges Zukunftsfenster für Preis. | Planung, wenn du bewusst später starten willst. |
meta.api_key_state | Status des hinterlegten Schlüssels. | Fehlersuche und Testphase. |
meta.allowed_horizon_hours | Was serverseitig für diesen Zugriff erlaubt ist. | Saubere Transparenz bei Limits. |
meta.used_horizon_hours | Was die API tatsächlich geliefert hat. | Landingpage und Backend bleiben damit ehrlich synchron. |
Offizielle Feldreferenz für home-assistant/summary
Der Summary-Endpunkt ist bewusst kompakt aufgebaut. Für viele Automationen reicht schon der Block flat. Wer genauer steuern oder Visualisierungen bauen will, kann zusätzlich die strukturierteren Blöcke price, co2, combined und source nutzen.
| Feld | Bedeutung | Typischer Einsatz |
|---|---|---|
flat.current_price | Aktueller Preis in EUR/kWh. Nutzt für den aktuellen Slot automatisch die beste verfügbare öffentliche Quelle. | Einfacher Preis-Sensor für Automationen. |
flat.current_price_source | Quellenlabel des aktuellen Preiswerts, zum Beispiel day_ahead. | Prüfen, ob der Preis schon offiziell oder noch prognostisch ist. |
flat.current_co2_g_kwh | Aktuelle CO2-Intensität in gCO2/kWh. | CO2-basierte Lastverschiebung. |
flat.cheapest_window_* | Start, Ende und Durchschnitt des günstigsten Zeitfensters im angefragten Horizont. | EV-Laden, Boiler, Wärmepumpe. |
flat.greenest_window_* | Start, Ende und Durchschnitt des CO2-ärmsten Zeitfensters. | Ökologisch optimierte Lastverschiebung. |
flat.combined_window_* | Kompromissfenster zwischen Preis und CO2. | Wenn beides relevant ist und kein harter Vorrang gilt. |
price.current | Objekt mit start, end, value, unit und source für den aktuellen Preis-Slot. | Dashboards und präzisere Zustandslogik. |
price.cheapest_window_next_horizon | Strukturierter Block für das günstigste Fenster mit Dauer und Quellenzählung. | Wenn Start, Ende und Kontext gemeinsam gebraucht werden. |
co2.current | Objekt mit aktuellem CO2-Wert und zugehörigem Zeitfenster. | CO2-Anzeige ohne Parsing aus flat. |
co2.greenest_window_next_horizon | Strukturierter Block für das grünste Fenster. | CO2-optimierte Lade- oder Heizlogik. |
combined.best_window_next_horizon | Kombinierter Empfehlungspfad mit Preis-, CO2- und Score-Werten. | Ein einziger "best now"-Entscheid ohne eigene Gewichtung. |
source.price | Metadaten zur Preisquelle, inklusive Firestore-Dokument, Day-Ahead-Provider und Anzahl verfügbarer Einträge. | Debugging, Monitoring und Qualitätskontrolle. |
source.co2 | Metadaten zur CO2-Quelle. | Debugging und Nachvollziehbarkeit. |
hourly-forecast der passendere Endpunkt.flat.current_price ist der aktuell verwendbare öffentliche Preiswert für den laufenden Slot. Er kann aus dem offiziellen Day-Ahead stammen oder aus einer anderen freigegebenen Quelle, wenn der Markt noch nicht vollständig vorliegt.retail-forecast ist aktuell nur für ausgewählte Märkte öffentlich gedacht. Für andere Märkte bleibt die Summary bewusst auf Markt- bzw. Basiswerten.Beispiel: Auto nur im günstigen Fenster laden
Genau dafür liegt die Beispiel-Automation bei. Sie nutzt bewusst den Boolean binary_sensor.epf_guenstigstes_preisfenster_aktiv statt nur auf eine Uhrzeit zu triggern. Das ist robuster, weil das beste Fenster auch bereits laufen kann.
trigger:
- platform: state
entity_id: binary_sensor.epf_guenstigstes_preisfenster_aktiv
to: "on"
action:
- service: persistent_notification.create
data:
title: "Günstiges Preisfenster aktiv"
Wenn du statt einer Benachrichtigung direkt eine Wallbox oder einen Schalter starten willst, ersetzt du im letzten Schritt nur den Service durch deinen eigenen Ziel-Service wie switch.turn_on.
Mit KI an dein Setup anpassen
Dieser Prompt hilft einer KI, aus dem Summary-Endpunkt eine passende Home-Assistant-Automation zu bauen. Er ersetzt nicht den einfachen Copy-Paste-Einstieg oben, sondern ist für individuelle Verbraucher, Zeitvorgaben und Sicherheitsregeln gedacht.
Gib einer KI niemals deinen echten API-Key. Lass im Ergebnis immer DEIN_API_KEY stehen und trage den Schlüssel erst lokal in Home Assistant ein.
Prompt zum Kopieren anzeigen
Du hilfst mir, eine sichere Home-Assistant-Automation mit der Energy Price Forecast EU API zu bauen.
Lies zuerst den API-Vertrag unter:
https://energypriceforecast.eu/openapi/integration-api.json
Verwende den Endpunkt /api/v1/home-assistant/summary und erfinde keine Felder. Die API nutzt offizielle Day-Ahead-Preise, sobald sie verfügbar sind, und Prognosewerte nur für den danach noch offenen Zeitraum.
Stelle mir vor dem YAML nacheinander höchstens diese Fragen:
1. Land oder Preiszone?
2. Welcher Verbraucher soll gesteuert werden und welche Home-Assistant-Entity schaltet ihn?
3. Leistung, benötigte Laufzeit und spätester Endzeitpunkt?
4. Soll nach Preis, CO2 oder beidem optimiert werden?
5. Free ohne Key und maximal 48 Stunden oder Private Pro mit maximal 120 Stunden?
6. Nutze ich packages oder configuration.yaml?
Regeln für dein Ergebnis:
- Free: hours=48 und kein Authorization-Header.
- Private Pro: hours=120 und Header Authorization: Bearer DEIN_API_KEY.
- Bitte mich niemals, den echten Key in den Chat einzufügen.
- Prüfe HTTP-Fehler sowie meta.api_key_state und meta.allowed_horizon_hours.
- Erkläre jede verwendete API-Eigenschaft kurz.
- Erzeuge vollständiges, gültig eingerücktes YAML und nenne den genauen Ablageort.
- Baue zuerst einen sicheren Testmodus mit Benachrichtigung oder input_boolean. Schalte den echten Verbraucher erst in einem getrennten, klar markierten Schritt.
- Definiere ein sicheres Verhalten bei alten, fehlenden oder unplausiblen Daten. Ein API-Fehler darf den Verbraucher nicht unkontrolliert einschalten.
- Gib zum Schluss eine kurze Prüfliste: API liefert HTTP 200, Sensoren haben Werte, erlaubter Horizont stimmt, Testmodus löst korrekt aus.
Wenn Angaben fehlen, frage nach. Triff keine stillen Annahmen über Entity-Namen, Tarif oder elektrische Grenzen.
Maschinenlesbare Grundlage: OpenAPI-Vertrag der Integrationsendpunkte.
Wenn dir einfache Home-Assistant-Automationen nicht mehr reichen, lohnt sich DAO vor allem dann, wenn du Preis, PV, Speicher und Verbraucher gemeinsam optimieren willst. Home Assistant auf dieser Seite ist bewusst der einfache Einstieg. DAO ist der Fortgeschrittenen-Pfad für Nutzer, die mehr als nur Schalten oder Triggern wollen.
Wann reicht summary und wann brauchst du mehr?
summary reicht für die meisten Home-Assistant-Automationen
Wenn du aktuelle Werte, ein bestes Fenster und einfache Zustände brauchst, ist der Summary-Endpunkt der richtige Weg. Genau dafür ist auch die Paketdatei gebaut.
Für eigene Preisreihen oder Charts ist ein Rohreihen-Endpunkt besser
Wenn du später bewusst eigene Scoring-Logik, Diagramme oder detaillierte Zeitreihen bauen willst, ist der Summary-Endpunkt absichtlich nicht maximal ausführlich. Dann ist ein Forecast-Endpunkt mit Rohserie der passendere Pfad.
Sind das exakte Haushaltsstrompreise?
Nicht automatisch. Die Summary arbeitet primär mit Markt- bzw. Basispreisen. Dein exakter Haushaltsstrompreis hängt zusätzlich von Netz, Steuern, Abgaben und Lieferantenaufschlägen ab.
Was tun, wenn nach dem Einfügen keine Werte erscheinen?
Typische Ursachen sind: Paketordner nicht eingebunden, Einrückungsfehler in YAML, Home Assistant nicht neu geladen oder ein falscher country-Wert. Am schnellsten sieht man das in den HA-Logs und in den Entwicklerwerkzeugen.
Für welche Zonen gibt es veröffentlichte Day-Ahead-Preise?
Veröffentlichte Day-Ahead-Preise geben wir nur weiter, wo die Quelle das erlaubt. Für NO1, NO3, NO4, NO5, SE1, SE2, FI, RO, SK, GR, BG und die italienischen Zonen außer Nord liefern die Endpunkte deshalb seit dem 24. Oktober 2026 für jede Stunde unsere Prognose, und die Sensoren kennzeichnen die Stunden als Prognose. Die veröffentlichten Preise bekommst du dort über die Nord-Pool-Integration von Home Assistant; für SK, GR, BG und Italien über eine ENTSO-E-Integration mit eigenem Token.
Verwandt: evcc mit Strompreis- und CO2-Prognose und Strompreis vs CO2.