Sprache

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.

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.

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.

Kostenlos starten, optional länger planen

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.

Wichtiger API-Hinweis

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.

  1. In HACS nach „Energy Price Forecast EU" suchen und herunterladen, danach Home Assistant neu starten.
  2. 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.

  1. 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.
  2. Ersetze alle drei sensor.CHANGE_ME durch 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.

Absichtlich einfachDie Paketdatei nutzt nur den Summary-Endpunkt. Kein HACS, kein Add-on, kein Python-Skript nötig.
Schon für echte Steuerung gedachtWichtig sind hier nicht nur Startzeiten, sondern auch Zustände wie is_cheapest_window_now und Restminuten.
Serverfreundlicher AbrufDas Beispiel pollt standardmäßig alle 30 Minuten. Für Day-Ahead plus Forecast ist das im Normalfall völlig ausreichend.

So sieht das Ergebnis aus

Vorschau einer Lovelace-Karte mit aktuellem Preis, CO2-Wert und Preisfenstern.
Die Lovelace-Karte zeigt direkt die Entitäten aus der Paketdatei, ohne dass du erst eigene Dashboards bauen musst.
Vorschau einer einfachen Home-Assistant-Automation mit Trigger auf das günstigste Preisfenster.
Die Beispiel-Automation startet absichtlich simpel und lässt sich dann auf Wallbox, Wärmepumpe oder Schalter umbiegen.

So bindest du das Paket ein

  1. Lade die Paketdatei herunter und speichere sie als /config/packages/energypriceforecast.yaml.
  2. Falls Packages noch nicht aktiviert sind, ergänze in configuration.yaml diesen Block.
  3. Home Assistant neu laden oder einmal neu starten.
  4. 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_apiRohantwort des Summary-Endpunkts inklusive flat, price, co2 und meta.Debugging und Grundlage für weitere Templates.
sensor.epf_aktueller_preisAktueller Preis im laufenden Slot. Quelle kann Day-Ahead oder Forecast sein.Preisgesteuerte Wallbox, Wärmepumpe, Boiler.
sensor.epf_aktuelle_co2_intensitaetAktueller CO2-Wert im laufenden Slot.CO2-orientierte Lastverschiebung.
binary_sensor.epf_guenstigstes_preisfenster_aktivon, wenn das rechnerisch beste Preisfenster bereits läuft.Direkte Laufentscheidung ohne eigene Zeitvergleiche.
sensor.epf_restminuten_guenstigstes_preisfensterRestdauer des aktuell besten Preisfensters.Schätzen, wie lange ein Verbraucher noch laufen darf.
sensor.epf_naechstes_volles_preisfensterDas nächste vollständige Zukunftsfenster für Preis.Späteres Starten oder Planen.
sensor.epf_api_key_statusStatus des hinterlegten API-Keys.Schnell sehen, ob 48h oder 120h wirklich greifen.
sensor.epf_erlaubter_horizontServerseitig 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.

Ohne API-KeyDas Beispiel nutzt hours=48. Damit bekommst du den einfachen Testhorizont, der ohne zusätzlichen Schlüssel öffentlich gedacht ist.
Mit API-KeyWenn du den Bearer-Token im Header setzt, kannst du den Horizon im Paket auf bis zu hours=120 erhöhen, also auf 5 Tage.
PreisauflösungDay-Ahead kann in 15-Minuten-Slots vorliegen. Forecast außerhalb davon bleibt stündlich. Die Summary mischt das intern sauber.
Day-Ahead firstSobald offizielle Day-Ahead-Preise vorhanden sind, werden diese bevorzugt. Nur für den restlichen offenen Zeitraum werden Prognosewerte verwendet.
CO2 bleibt stündlichDie CO2-Daten werden nicht künstlich auf Viertelstunden umgerechnet. Für die Summary reicht die stündliche CO2-Sicht in der Regel aus.
Fertig berechnete FensterDie API liefert nicht nur Rohwerte, sondern bereits das günstigste Fenster, das grünste Fenster und das nächste vollständige Zukunftsfenster.

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_priceAktueller Preiswert im laufenden Slot.Direkter Ist-Zustand für Preislogik.
flat.current_co2_g_kwhAktueller CO2-Wert im laufenden Slot.Direkter Ist-Zustand für CO2-Logik.
flat.is_cheapest_window_nowZeigt, ob das beste Preisfenster bereits aktiv ist.Wichtiger als nur ein Startzeitpunkt.
flat.cheapest_window_remaining_minutesRestdauer des laufenden besten Preisfensters.Nützlich für Laufzeitentscheidungen.
price.next_full_window.startNächstes vollständiges Zukunftsfenster für Preis.Planung, wenn du bewusst später starten willst.
meta.api_key_stateStatus des hinterlegten Schlüssels.Fehlersuche und Testphase.
meta.allowed_horizon_hoursWas serverseitig für diesen Zugriff erlaubt ist.Saubere Transparenz bei Limits.
meta.used_horizon_hoursWas 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_priceAktueller 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_sourceQuellenlabel des aktuellen Preiswerts, zum Beispiel day_ahead.Prüfen, ob der Preis schon offiziell oder noch prognostisch ist.
flat.current_co2_g_kwhAktuelle 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.currentObjekt mit start, end, value, unit und source für den aktuellen Preis-Slot.Dashboards und präzisere Zustandslogik.
price.cheapest_window_next_horizonStrukturierter Block für das günstigste Fenster mit Dauer und Quellenzählung.Wenn Start, Ende und Kontext gemeinsam gebraucht werden.
co2.currentObjekt mit aktuellem CO2-Wert und zugehörigem Zeitfenster.CO2-Anzeige ohne Parsing aus flat.
co2.greenest_window_next_horizonStrukturierter Block für das grünste Fenster.CO2-optimierte Lade- oder Heizlogik.
combined.best_window_next_horizonKombinierter Empfehlungspfad mit Preis-, CO2- und Score-Werten.Ein einziger "best now"-Entscheid ohne eigene Gewichtung.
source.priceMetadaten zur Preisquelle, inklusive Firestore-Dokument, Day-Ahead-Provider und Anzahl verfügbarer Einträge.Debugging, Monitoring und Qualitätskontrolle.
source.co2Metadaten zur CO2-Quelle.Debugging und Nachvollziehbarkeit.
Wichtig zu PreisfeldernDie Summary liefert keine komplette Rohserie aller Preisvarianten. Für Home Assistant liefert sie vor allem den aktuellen Zustand und bereits berechnete Fenster. Für volle Zeitreihen ist hourly-forecast der passendere Endpunkt.
Aktuell heißt nicht Istpreisflat.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.
Gesamtpreis nur selektivDer Endpunkt 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.

API-Key schützen

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.

Erweiterte Lösung für komplexere Optimierung

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.

Mehr dazu