ich hätte noch eine bitte, natürlich ohne verpflichtung es mit einzubauen. open-meteo gibt leider gar keine guten daten für meinen standort.
wäre es möglich folgenden vorhersage dazuzunehmen sofern das nicht ein riesiger aufwand ist?
Danke @mhl für den Hinweis auf Meteo Euregio! Ich hab mir das angeschaut.
Das Problem ist: EEDC braucht von der Wetterquelle vor allem Strahlungsdaten (Global Tilted Irradiance, Globalstrahlung, direkte/diffuse Strahlung) — daraus wird die stündliche PV-Prognose berechnet. Meteo Euregio liefert Temperatur, Niederschlag, Wind und Sonnenscheindauer, aber keine Strahlungswerte. Damit kann es Open-Meteo leider nicht ersetzen.
Was mich interessieren würde: Was genau passt bei Open-Meteo an deinem Standort nicht? Ist es die PV-Prognose (also die prognostizierten kWh), die Temperatur, oder die Wetterbeschreibung generell?
Falls die PV-Prognose das Thema ist: EEDC hat einen eingebauten Lernfaktor, der die Open-Meteo-Prognose automatisch an deine tatsächliche Erzeugung anpasst (Median aus den letzten 30 Tagen). Nach ca. einer Woche sollte die Prognose deutlich besser zu deiner Anlage passen — auch wenn die Rohdaten von Open-Meteo für deinen Standort nicht perfekt sind.
Falls es dir eher um Temperatur/Wetterbeschreibung geht: Du könntest Meteo Euregio als HA-Integration installieren und den Temperatur-Sensor über das EEDC Sensor-Mapping einbinden — da braucht es keine Änderung an EEDC selbst.
vg
Gernot
alles klar ich verstehe die Gründe warum eine Integration nicht sinnvoll ist.
laut EEDC(open-meteo) scheint die nächsten Tage immer voll die sonne. Euregio Meteo(örtliche und genaueste Wetterprognose bei uns) meldet anständig Niederschlag(Regen und Schnee) für Mi, Do und Freitag.
somit stimmt wohl weder temperatur, bewölkung oder sonnenscheindauer
Hallo @mhl ,
Danke für die Screenshots, das war sehr aufschlussreich! Dabei ist uns ein Bug aufgefallen: Die Wetter-Icons in den Aussichten nutzen aktuell nur den Bewölkungsgrad und können deshalb maximal “bewölkt” anzeigen — Regen und Schnee werden nie als Icon dargestellt, obwohl die Daten von Open-Meteo da wären (WMO Weather Code). Das wird im nächsten Release gefixt.
Was die grundsätzliche Genauigkeit von Open-Meteo für deinen Standort angeht: Könntest du nach dem Fix nochmal schauen, ob die Icons dann besser passen? Falls Open-Meteo trotzdem daneben liegt, wäre es hilfreich zu wissen, welche Koordinaten bei dir in EEDC hinterlegt sind — in den Alpen kann ein paar hundert Meter Unterschied viel ausmachen.
Der Lernfaktor passt übrigens automatisch die PV-Prognose an (Median aus den letzten 30 Tagen IST vs. Prognose) — die kWh-Werte sollten sich also nach ca. einer Woche von selbst kalibrieren. Die Wetter-Icons und Temperaturen werden davon aber nicht beeinflusst.
Das Release v3.4.14 ist übertragen und enthält den Fix, auf den du uns aufmerksam gemacht hast.
vg
Gernot
Nachtrag:
Sorry @mhl,
du musst das gerade hochgeladene Release v3.4.15 nehmen. Wir haben noch etwas gefunden.
Vielen Dank für deinen Hinweis,
Gernot
by HarryP: Zusammenführung Doppelpost (bei Änderungen oder hinzufügen von Inhalten bitte die „Bearbeitungsfunktion“ anstatt „Antworten“ zu nutzen)
1 „Gefällt mir“
Ich finde kein Sensor-Mapping für die Außentemperatur.
Danke, nun siehts “anders” aus.
Open-Meteo zeig bewölkt an, wir haben KEINE einzige Wolke am Himmer 
Open-Meteo zeigt auch keine Temperaturen an. Der Forecast für Morgen, trotz “Gewitter” zeigt denke ich auch zu viel Erzeugung an. Liegt aber wohl am fehlenden Lernfaktor.
Bei den Details von Open-Meteo fehlen auch Bewölkung, Niederschlag und Temperatur.
hier das euregio wetter
hier weather fusion AI(von SFML), vielleicht lässt sich das einfacher einbinden. Die Vorhersage von Weather fusion AI stimmt bei mir ziemlich gut. Immer vorausgesetzt @Tom-HA ist damit einverstanden natürlich.
Hallo mhl,
ich verstehe dein Problem und habe in v3.4.18 einige Verbesserungen und Anpassungen vorgenommen.
Ich hoffe, das passt so besser,
Gernot
1 „Gefällt mir“
top, sieht jetzt sehr gut aus. Vielen Dank
Nachdem die Installation gestern Ewigkeiten dauerte, scheint es jetzt garnicht mehr möglich zu sein:
App konnte nicht installiert werden
An unknown error occurred with addon bc122c22_eedc. Check supervisor logs for details (check with 'ha supervisor logs')
ha supervisory logs im Terminal meldet:
2026-03-24 11:15:34.905 WARNING (MainThread) [supervisor.docker.manifest] Failed to get token from https://ghcr.io/token: 403
2026-03-24 11:15:35.011 WARNING (MainThread) [supervisor.docker.manifest] Failed to fetch manifest for ghcr.io/supernova1963/eedc-homeassistant-aarch64:3.4.18 - 401
2026-03-24 11:15:35.012 INFO (MainThread) [supervisor.docker.interface] Downloading docker image ghcr.io/supernova1963/eedc-homeassistant-aarch64 with tag 3.4.18.
2026-03-24 11:15:35.370 ERROR (MainThread) [supervisor.docker.interface] Can't install ghcr.io/supernova1963/eedc-homeassistant-aarch64:3.4.18: [403] Head "https://ghcr.io/v2/supernova1963/eedc-homeassistant-aarch64/manifests/3.4.18": denied
2026-03-24 11:15:35.371 ERROR (MainThread) [supervisor.addons.addon] Could not pull image to update addon bc122c22_eedc: Can't install ghcr.io/supernova1963/eedc-homeassistant-aarch64:3.4.18: [403] Head "https://ghcr.io/v2/supernova1963/eedc-homeassistant-aarch64/manifests/3.4.18": denied
Irgendwelche Ideen? Mit HACS wird das repo auch nicht (mehr) akzeptiert.
Behoben in v3.4.19.
Das Problem war, dass der Docker-Build-Workflow (der die Images auf GitHub Container Registry pusht) erst nach dem letzten Release v3.4.18 gemergt wurde. Dadurch waren keine vorgebauten Docker-Images auf GHCR verfügbar → 403 beim Pull.
Mit v3.4.19 werden die Images jetzt korrekt gebaut und bereitgestellt:
ghcr.io/supernova1963/eedc-homeassistant-aarch64:3.4.19ghcr.io/supernova1963/eedc-homeassistant-amd64:3.4.19
Lösung: Im HA Supervisor einfach das Add-on neu installieren/aktualisieren — es sollte jetzt v3.4.19 ziehen.
Nein, v3.4.20 
Anschließend musste ich aber wieder zurück auf das Backup von 3.4.15, weil ich natürlich keine Daten als json gesichert hatte. Dann Update auf 3.4.20, und nun sind die händisch eingetragenen Monatswerte wieder da.
Freut mich, dass es geklappt hat! 
Kurz zur Erklärung für die Nachwelt:
- v3.4.18 hatte noch keine vorgebauten Docker-Images auf GHCR → daher der 403-Fehler
- Ab v3.4.19 werden die Images automatisch per GitHub Actions gebaut und gepusht
- Der Weg über Backup → Restore → Update war genau richtig, um die Monatsdaten zu behalten
Tipp für die Zukunft: Unter Einstellungen → Daten-Export kannst du jederzeit ein JSON-Backup deiner Daten erstellen — unabhängig vom HA-Backup. Damit bist du auf der sicheren Seite, falls mal ein Update schiefgeht.
Bei weiteren Problemen gerne wieder melden!
kleiner kosmetischer bug(oder nur bei mir, läuft auf HAOS)…
der grüne Rahmen um den heutigen Tag ist nicht ganz vollständig
und noch ein Frage zur Beschriftung:
habe beim drop-down menü in der anlage Automatisch eingestellt
Hallo Gernot,
ich habe gerade die 3.4.21 installiert. Ich muss dir/euch ein riesen Lob aussprechen. Die Anwendung wird mit jeder Version immer besser.
Es macht Freude damit zu arbeiten. Ich habe nun auch alle Verbrauchswerte ins 09/2021 manuell als Monatsabschlüsse nachgetragen.
Vielen Dank noch einmal für die herausragende Anwendung.
Gruß
Martin
Hallo @mhl,
Linienfehler ist behoben (v3.4.21).
BM = Best Match. Ist Platz genug, wird demnächst ausgeschrieben.
vg
Gernot
1 „Gefällt mir“
Die Freude währte nicht lange:
2026-03-24 18:33:22.467 ERROR (MainThread) [supervisor.docker.interface] Can't install ghcr.io/supernova1963/eedc-homeassistant-aarch64:3.4.21: [404] manifest unknown
2026-03-24 18:33:22.469 ERROR (MainThread) [supervisor.addons.addon] Could not pull image to update addon bc122c22_eedc: Can't install ghcr.io/supernova1963/eedc-homeassistant-aarch64:3.4.21: [404] manifest unknown
2026-03-24 18:33:42.510 INFO (MainThread) [supervisor.api.middleware.security] /supervisor/logs access from a0d7b954_ssh
Ich habe eine Nachfrage:
Im Cockpit - aktueller Monat
fehlt bei der Wärmepumpe die erzeugte Wärme. Ich unterscheide bei der Wärmepumpe die Werte für “Heizung” und “Warmwasser”.
Kann es sein, dass hier die Aggregation der beiden Werte fehlt?
Sorry, ich habe auf Build action von github umgestellt, läuft noch nicht ganz rund.
Und das alles nur dafür, dass beim HA Update der Ladebalken sichtbar wird…
Wenn ich das gewußt hätte, …
Sorry,
ich melde mich, wenn es wieder funktionieren sollte
v3.4.24 — Docker-Builds laufen jetzt zuverlässig.
Das Problem war doppelt:
- ARM64-Builds per QEMU-Emulation hingen sich auf (v3.4.21, v3.4.22)
- Standalone Multi-Arch Manifest brauchte
buildx imagetoolsstattdocker manifest(v3.4.23)
Fix: Native ARM64-Runner (ubuntu-24.04-arm) statt QEMU. Beide Repos (HA + Standalone) bauen jetzt nativ auf der jeweiligen Architektur.
Bitte v3.4.24 testen — sollte jetzt problemlos installierbar sein.
Hallo MartyBr,
danke für die Meldung! Du hast recht — die Aggregation der Wärme-Werte (Heizung + Warmwasser) hat im “Aktueller Monat”-View gefehlt. Die typ_aggregation-Map hatte nur den WP-Stromverbrauch gemappt, aber nicht die Wärmefelder (heizenergie_kwh, warmwasser_kwh).
Der Fix wird in v3.4.25 enthalten sein:
- Heizenergie + Warmwasser werden jetzt korrekt zu
wp_waerme_kwhaggregiert - Auch getrennte Strommessung (Strom Heizen / Strom Warmwasser) wird summiert
- Betrifft alle Datenquellen (HA Statistics, MQTT-Inbound, gespeicherte Daten)
1 „Gefällt mir“