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, aktuell als Custom Repository (noch nicht 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
Solange die Integration noch nicht im HACS-Standard-Store gelistet ist, trägst du das Repository einmalig manuell ein.
- HACS öffnen, oben rechts die drei Punkte → Benutzerdefinierte Repositories.
- Repository-URL
https://github.com/BackupBaTTerY/energypriceforecast-home-assistanteintragen, Typ Integration wählen, hinzufügen. - 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 Schritt 1 und 2 automatisch, falls HACS bereits installiert ist.
Preis-Chart per KI bauen (HACS-Integration)
Zwei Sensoren tragen die Attribute raw_today/raw_tomorrow – eine Liste aus Preis-Zeitpunkten, gedacht für Charts mit der Community-Karte apexcharts-card (separat über HACS installierbar): der immer aktive Sensor mit Namen auf _price_series (Börsen-/Day-Ahead-Preis) und, falls du beim Setup den Endkundenpreis aktiviert hast, zusätzlich der Sensor auf _retail_current_price (Annahme-basierter All-in-Preis). Beide tragen zusätzlich das Attribut raw_forecast: die Einträge jenseits des veröffentlichten Day-Ahead-Zeitraums – die tatsächliche ML-Prognose. Dieser Prompt baut dir die passende Lovelace-Karte dafür.
Prompt zum Kopieren anzeigen
Hilf mir, eine Home-Assistant-Lovelace-Karte zu bauen, die Strompreise aus der Energy-Price-Forecast-EU-Integration mit der Karte apexcharts-card darstellt.
Die Integration legt einen Sensor an, dessen Entity-ID auf "_price_series" endet (Börsen-/Day-Ahead-Preis, der genaue Name hängt vom gewählten Markt ab, z.B. sensor.energy_price_forecast_eu_de_preisreihe) und, falls ich den Endkundenpreis aktiviert habe, einen zweiten Sensor auf "_retail_current_price" (Annahme-basierter All-in-Preis) mit derselben Attribut-Struktur. Der Zustand jedes Sensors ist der jeweils aktuelle Preis; seine Attribute raw_today, raw_tomorrow und raw_forecast sind jeweils eine Liste von Objekten der Form {"start": ISO8601-Zeitstempel, "end": ISO8601-Zeitstempel, "value": Zahl}. raw_today/raw_tomorrow decken nur den veröffentlichten Day-Ahead-Zeitraum ab (bekannte Preise, keine Schätzung); raw_forecast enthält nur die Einträge danach – die tatsächliche ML-/Wetterprognose. Die Einheit des Werts richtet sich nach der Marktwährung (z.B. EUR/kWh).
Meine tatsächliche Entity-ID lautet: Geräte & Dienste > Energy Price Forecast EU, oder Entwicklerwerkzeuge > Zustände, gefiltert nach "price_series" oder "retail_current_price">
Frag mich vor dem YAML nacheinander:
1. Habe ich HACS und die Karte apexcharts-card schon installiert? Falls nicht, sag mir, dass ich apexcharts-card zuerst über HACS installieren muss (Kategorie: Frontend/Plugin).
2. Möchte ich den Börsen-/Day-Ahead-Preis (_price_series) oder meinen Endkundenpreis (_retail_current_price) darstellen, falls ich den aktiviert habe?
3. Soll die Karte nur heute zeigen, heute und morgen zusammen, oder bekannte Preise plus Prognose (raw_today + raw_tomorrow + raw_forecast) als zwei optisch unterschiedliche Serien (z.B. durchgezogen vs. gestrichelt, unterschiedliche Farben)?
4. Möchte ich zusätzlich das günstigste-Stunden-Fenster hervorheben, falls ich dieses Feature aktiviert habe? (binary_sensor ...günstigste_stunden_aktiv / sensor ...nächste_günstige_stunde)
5. Soll es ein Balkendiagramm pro Stunde oder ein Linien-/Flächendiagramm sein?
Regeln für dein Ergebnis:
- Nutze ausschließlich die beschriebenen Attribute raw_today/raw_tomorrow/raw_forecast. Erfinde keine anderen Attribute oder eine andere Datenstruktur.
- Nutze den data_generator von apexcharts-card, um die Attribut-Liste in eine Chart-Serie umzuwandeln – geh nicht davon aus, dass die Karte das Attribut direkt als Serie akzeptiert.
- Falls ich bekannte Preise und Prognose als getrennte Serien wollte: zwei Serien auf derselben Entity (eine mit raw_today+raw_tomorrow summiert, eine mit raw_forecast), jeweils eigener data_generator, und bei beiden extend_to: false setzen – sonst verlängert apexcharts-card den letzten Wert optisch bis zum Kartenrand, was hier irreführend wäre.
- Setze jeden String-Wert (title, name, tooltip-Format) in Anführungszeichen, der selbst einen Doppelpunkt enthält, z.B. "Bekannt: Prognose" oder "dd.MM. HH:mm" – ein nicht gequoteter Doppelpunkt in einem YAML-Wert bricht das Parsing.
- Erzeuge einen vollständigen, korrekt eingerückten YAML-Block für eine manuelle Lovelace-Karte (type: custom:apexcharts-card).
- Sag mir genau, wo ich das einfügen muss (Dashboard > Bearbeiten > Karte hinzufügen > Manuell).
- Wenn Angaben fehlen, frage nach – rate nicht bei meiner Entity-ID oder meinem Markt. 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 packagesDie 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=de&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. |
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.
Verwandt: evcc mit Strompreis- und CO2-Prognose und Strompreis vs CO2.