Allerdings wurde nicht nach Wallbox oder E‑Auto gefragt, sondern nach der prozentualen String-Aufteilung.
Ich überlege noch, wie ich die Wallbox und das E‑Auto sinnvoll miteinander kombinieren kann.
Bisher sind – bis auf die Kilometer – alle Daten in der Wallbox gelandet. Da wir nur ein E‑Auto haben, wären die Werte ja eigentlich identisch.
Macht es deiner Meinung nach Sinn, zusätzlich den PV- und Netzanteil zu importieren und dem E‑Auto zuzuordnen?
Ein kurzer Tipp zur grundsätzlichen Vorgehensweise wäre super!
Ich habe aber Abbrüche im Verlauf:
Davor waren die Werte absolut stabil (leicht wachsend). Ich habe nun viel am Optisplitter geändert, hoffentlich stabilisiert sich das.
Wie siehst du das? Oder doch besser bei der Vicare bleiben?
Habe deinen Edit gesehen. Vicare-Rückwechsel ist eine vertretbare Entscheidung — Cloud-Sensor mit etabliertem Verlauf ist im Zweifel berechenbarer als ein lokaler, der Abbrüche zeigt. Ein Hinweis zum value_template-Workaround: da mischst du im Sensor-Wert zwei Quellen, das ist sehr clever gemeint, aber genau die Mischung kriegt EEDC später beim Recycle nicht mehr auseinander. Eine Quelle pro Feld ist robuster — also entweder „nur Optisplitter" oder „nur Vicare", nicht beide kombiniert.
Gute Nachricht zum Reload selbst: v3.26.6 ist gerade raus. Zwei Sachen für deinen Fall:
Der Reload-Knopf schließt jetzt die Mitternacht zum Folgetag mit ein. Der Lifetime-Sprung beim 6.5. (= das, was wie Verdopplung aussah) entstand genau dort und ist behoben.
Wenn die Vorschau zeigt, dass alle Werte schon stimmen (alt = neu, wie bei deinem 5.5.), rechnet der Übernehmen-Knopf nur den Tag neu, ohne HA noch mal anzufragen. Dein 5.5.-Hänger ist damit weg. Knopf-Label dann „Nur neu rechnen", blauer Info-Hinweis im Modal.
Sobald das Update im Add-on-Store ist und dein Mapping (Vicare oder Optisplitter — du entscheidest) entschieden steht, kannst du die betroffenen Tage in Ruhe heilen.
Frage am Rand zu deinem „Die Werte kommen hier ab dem 4. Mai!!!" — meinst du, der Vicare-Datenpunkt hat in HA erst ab 4. Mai Werte (kürzere Historie als Optisplitter)? Wäre für den Reparaturpfad relevant.
Ja, es ist genau so. Ich setze aktuell den Vicare Wert ein. Den Optisplitter hatte ich nur einen Tag aktiv. Vicare in Homeassistant habe ich erst seit Mai installiert, daher die Datenwerte erst am 4. Mai.
Ich habe die Sprünge bisher nicht in den Griff bekommen. Bei jedem Neustart springen die Werte auf das Minimum und springen dann zu den echten Werten.
Daher bleibe ich bei den Cloud Werten. Die Werte sind mir nicht wichtig, die können wirklich gelöscht werden.
P.S.
Das Template schaue ich mir noch an und warte dann auf dein Update
Edit:
Das Template ist rein Optisplitter, oder ich verstehe es nicht. Ich vergebe mit &device die Gerätekennung Vitocal…
Vicare vergibt bei “meiner” Heizung korrespondierend mit der Steuerung ein “CU401B_G_xxxx”
Danke, das Update ist da und ich habe es eingespielt. Der Reload für den 5.5. ist erfolgreich durchgelaufen. Der Wert stimmt nun.
Also ich auf den 6.5. klickte, stand der Buttom auf “Übernehmen” mit dem hübschen Kreissymbol. Und da steht das System immer noch.
EDIT:
Ich habe den Vorgang abgebrochen und bin auf die Live-Karte gegangen und dann wieder unter Einstellungen auf Energieprofil. Nun habe ich den 6.5. “Reloaded” und alles ist FEIN!!
Was vermutlich passiert ist: beim ersten 6.5.-Versuch hat das Backend im Hintergrund trotz Frontend-Hänger weitergerechnet und die Snapshots aktualisiert — beim zweiten Aufruf sah die Vorschau daher „alt = neu" überall und nahm den schnellen „Nur neu rechnen"-Pfad. Daher das schmerzlose zweite Mal.
Du hast nebenbei zwei UX-Schönheitsfehler aufgezeigt: das Modal sollte auch im Apply-Zustand schließbar sein (nicht erst per Browser-Reload), und der Spinner sollte einen Timeout haben. Beides kommt auf die Liste, eilt nicht.
Danke fürs Mitdenken bei der Diagnose, das war wirklich hilfreich. Tabelle ist jetzt sauber — Mission erfüllt.
Ich habe mir jetzt eine gefilterte Entität aus dem Optisplitter Kompressor Starts gebaut und würde diese statt der Vicare Entität nutzen. Ziel es es Cloud unabhängig zu werden.
Wie mache ich das am besten? Die alten Werte der Starts müssen nicht aufbewahrt werden.
In jedem Feld die alte Vicare-Entity gegen die neue (gefilterte) Entity tauschen → speichern. Ab dem Zeitpunkt zieht EEDC nur noch die neuen Quellen; historische Tagesdaten bleiben unangetastet (ist Konfiguration, nicht Migration).
Wichtig für die kumulativen Zähler (Stromverbrauch, Wärme, Kompressor-Starts): Die filtered-Entities brauchen in HA das Attribut state_class: total_increasing (Zähler) bzw. measurement (Live-Leistung). EEDC zieht die Werte aus den HA-Long-Term-Statistics — und die baut HA erst ab dem Moment auf, wo state_class gesetzt ist, rückwirkend nicht.
Reihenfolge-Tipp: Erst die filtered-Entities in HA fertig konfigurieren (state_class drin, ein, zwei Tage Datenbasis in HA → Entwicklerwerkzeuge → Statistiken prüfen), dann im Sensor-Mapping austauschen. So hast du keinen „leeren Tag" beim Umschalten.
Hallo Gernot,
so habe ich mir das auch vorgestellt. Danke für die Info.
Es betrifft nur den Sensor für die Kompressor Starts. Den hatte ich gestern angelegt. Heute hat er schon einen Wert generiert. Ich werde das so machen wie du es beschrieben hast.
Eine Anmerkung noch, weil du „Cloud unabhängig" als Ziel genannt hast: Mit dem Tausch der Kompressor-Starts allein bist du erst ein Stück des Wegs gegangen. Die anderen WP-Felder im Sensor-Mapping (Stromverbrauch, Heizwärme, ggf. Warmwasser) hängen vermutlich noch an Vicare. Wenn die API mal hängt, fehlen die drei — die Starts laufen weiter, aber dein Tagesbild hat dann Lücken an drei von vier Stellen.
Wenn dich das stört, lohnt es sich, die anderen Felder gleich mit anzuschauen:
Stromverbrauch lässt sich meist über einen Energiezähler / Shelly EM / Hutschienen-Zähler lokal abgreifen
Heizwärme via externem Wärmemengenzähler (Optolink liefert das in der Regel nicht direkt)
Warmwasser analog, falls separat erfasst
Kein Muss — aber eine konsistente Quelle macht das Tagesprofil robuster, und du erkennst Auffälligkeiten leichter, weil alle Felder in derselben Frische- und Genauigkeits-Liga spielen.
alle anderen Entitäten kommen schon aus dem Optisplitter. Den setze ich schon seit vielen Jahren ein, wenn ich den Vorgänger VControl mitzähle, den ich seit ioBroker Zeiten genutzt habe. Ich habe mich bemüht die Namen der Entitäten beizubehalten und konnte so den Datenbestand seit 2021/2022 aufbauen. Irgendwie war mir bei dem Sensor WP Starts der falschen untergekommen.
Der Rest der Sensoren ist sauber. Ich kämpfe mich aktuell mit dem Thema Heizungssteuerung in HA, speziell die Zeitpläne für Heizung, Warmwasser, Zirkulation und auch den zentralen Lüftungssteuerung der Vitovent 300F:
Das ist zumindest für mich heavy. Ich hatte zwischenzeitlich die App viessmann2mqtt laufen, aber diese lieferte Daten zum Teil erst nach Stunden.
Jetzt versuche ich mit der KI die Steuerung komplett auf dem Optisplitter zu setzen. Ich kann dir sagen, dass ist echt ein mühseliges Geschäft.
eedc v3.27.0 — Reparatur-Werkbank und Schutz manueller Werte
Hi zusammen,
ich habe gerade eedc v3.27.0 ausgeliefert. Das ist eine größere Architektur-Etappe, von der das meiste unter der Haube läuft — aber zwei Dinge bekommt ihr direkt zu sehen:
Reparatur-Werkbank im Energieprofil
Statt verstreuter Knöpfe (Vollbackfill / Tag neu aggregieren / Kraftstoffpreise / …) gibt es jetzt unter „Auswertungen → Energieprofil → Datenverwaltung" eine zentrale Werkbank: Operation auswählen, Plan erstellen klicken, eine Vorschau-Tabelle zeigt euch vor dem Klick auf „Anwenden" was sich konkret an welchen Feldern ändern würde. Erst der Bestätigungs-Knopf schreibt etwas. Dauert eine Operation länger, könnt ihr nach 30 Sekunden abbrechen. Im Verlauf-Akkordeon seht ihr, was ihr bereits angewendet habt.
Die alten Schnellbuttons bleiben übrigens — wer sie gewohnt ist, drückt sie einfach weiter, dahinter läuft jetzt aber dieselbe Mechanik.
Manuelle Werte sind jetzt sicherer
Cloud-Importe respektieren ab v3.27.0 manuell gepflegte Werte automatisch. Beim Apply meldet eedc, wie viele Felder geschützt blieben — bewusst zurücksetzen geht über die Reparatur-Werkbank.
Was sonst noch reinging
Daten-Checker hat eine neue Kategorie „Daten-Quellen – Konflikte"
E-Auto + Wallbox in einer Anlage: Doppelzählung im Cockpit ist weg
Was sich nicht ändert
Tagesgesamt-Werte, Heatmaps, Cockpit-Zahlen — alles bleibt wie ihr es kennt. Bestandsdaten gehen nicht verloren; beim ersten Add-on-Boot nach Update werden sie einmalig automatisch markiert. Manuelle Eingabe geht weiter wie bisher.
Wenn euch beim Update oder im Alltag mit der neuen Version etwas auffällt, gerne als GitHub-Issue (Issues · supernova1963/eedc-homeassistant · GitHub) — wenn das nicht passt, ansonsten wie gewohnt hier oder per PN.
ich habe eben versucht, die Ladedaten meines E-Autos über „Eigene Dateien“ zu importieren. Es wird auch alles sauber erkannt, aber sobald ich auf „Vorschau“ klicke, bekomme ich die Fehlermeldung:
„Keine gültigen Monatsdaten mit diesem Mapping gefunden. Bitte prüfe die Zuordnung von Jahr und Monat.“
das ist auf meiner Seite zu eng formuliert, sorry — die Meldung sagt „prüfe Jahr/Monat", aber in den allermeisten Fällen ist das Datums-Format der Quelldatei der eigentliche Grund (z. B. ISO-Zeitstempel 2026-05-10T14:32:00 aus Wallbox-Exports), seltener das Dezimalzeichen (Punkt vs. Komma).
Magst du mir kurz zeigen:
die ersten 3–5 Zeilen deiner Datei (Header + Werte, gerne anonymisiert),
welches Datums-Format du im Wizard ausgewählt hast?
Parallel mache ich die Fehlermeldung im nächsten Release sprechender, damit du nicht raten musst — und dass sie dir konkret sagt, welche Spalte/Format nicht greift.
Danke fürs Melden!
EDIT: Ich habe gerade dein issue auf github gelesen und bearbeitet. Daraus wir klar, woran es gelegen hat.
) ein Frage:
