Replies: 6 comments 4 replies
|
Hallo, danke für die Meldung — die Meldung war falsch, nicht deine Konfiguration. Sie ist mit v4.0.28 weg. Du hast beides richtig gesehen: Der Daten-Check verlangte „Ladung PV" beim VW ID.3, während dieselbe App für genau diese Monate PV-Anteile deiner Ladung ausgewiesen hat. Beide Aussagen stimmten — sie sprachen nur über verschiedene Stellen. Wer eine Wallbox hat, dessen Heimladung führt eedc dort. Die Aufteilung in Sonne und Netz am Fahrzeug wird deshalb im Monatsabschluss gar nicht mehr angeboten: Sie stünde sonst zweimal in den Daten. Dein go-e Charger meldet ja im selben Bild „Monatsdaten vollständig" — genau deshalb. Der Daten-Check kannte diese Regel als einziger nicht und hat den Wert weiter eingefordert. Damit war die Meldung nicht abstellbar: Ihr „Beheben"-Knopf führte in ein Formular, in dem es dieses Feld gar nicht gibt. Und wer den Wert von Hand beschafft und eingetragen hätte, hätte genau die Doppelzählung erzeugt, die die Regel verhindern soll. Ab v4.0.28 fragt der Daten-Check das Feld nur noch bei Fahrzeugen ohne Wallbox — dort, wo das Formular es auch anbietet. Für Dienstwagen galt diese Ausnahme schon vorher. An deinen Daten ändert sich nichts, und die PV-Anteile deiner evcc-Ladung werden weiterhin so ausgewiesen wie bisher. Nach dem Update verschwindet nur die Meldung. Danke, dass du zwei Aussagen derselben App nebeneinandergelegt hast, statt einer davon zu glauben. Genau daran ist es aufgefallen. |
|
Ist die Meldung hier ganz unten "Offen: go-e Charger, Ladung PV" evtl. auch noch fälschlicherweise vorhanden? |
|
Hier ergänzend noch die Basis-Zähler: |
|
Hallo August, du hattest wieder recht — und diesmal war es mehr als eine falsche Meldung. Deine Frage war ja vorsichtig gestellt („evtl. auch noch fälschlicherweise vorhanden?"). Die Antwort ist: ja, und dein zweites Bild mit den Basis-Zählern hat den Grund gleich mitgeliefert. Danke dafür — ohne das Bild hätte ich weiter beim E-Auto gesucht. Was schiefgingFür eedc hieß „Zähler zugeordnet" bis jetzt „Home-Assistant-Sensor zugeordnet". Du schickst deine Werte per MQTT — da gibt es keinen Sensor zuzuordnen, das Feld steht bewusst gar nicht im Sensor-Mapping. Der Daten-Check hat an dieser Stelle nachgesehen, nichts gefunden und „Ladung PV fehlt" gemeldet, während über genau dieses Feld 1.286 kWh liefen. Und es ließ sich nicht abstellen: Der „Beheben"-Knopf führte in ein Formular, in dem das Feld nicht vorkommt. Genau die Sackgasse wie beim ersten Mal in diesem Faden. Was ich dabei gefunden habe, und wonach du nicht gefragt hastDie Meldung war nicht nur falsch — ein Teil von ihr stimmte, und der war schlimmer als der falsche Teil. Sie behauptet, die Werte blieben „in Cockpit → Tag auf —". Das traf zu, und zwar nicht nur für die PV-Ladung: Auch Wärmemenge, getrennter Heiz- und Warmwasserstrom, die Netzladung des Speichers und die Kompressor-Starts blieben dort leer. Dieselbe Ursache eine Ebene tiefer — die Tages-Erhebung zählte ihre Felder aus derselben Ablage auf und übersprang deshalb alles, was per MQTT kommt. Deine Zählerstände standen in der Datenbank und wurden nie gelesen. Hätte ich nur den Hinweis abgeschaltet, wärst du schlechter dran gewesen als vorher: keine Warnung mehr, und die Ansicht immer noch leer. Was jetzt gilt — mit v4.0.29Ein Feld trägt einen Zähler, wenn ihm ein Home-Assistant-Sensor zugeordnet ist oder wenn dafür Zählerstände per MQTT ankommen. Hast du irgendwo ausdrücklich „Keine" gewählt, bleibt das deine Absage. Entscheidend ist dabei der Messwert, nicht der Eintrag. Das klingt nach Haarspalterei, ist aber der Unterschied zwischen einem Fix und einem Schaden: eedc trägt bei vielen Feldern „MQTT" als Grundeinstellung ein, ohne dass dort je etwas ankommt. Hätte ich diesen Eintrag als Beleg genommen, wäre der Daten-Check bei jeder Anlage verstummt — auch bei der, die wirklich nichts misst. Also sieht eedc nach, ob auf dem Topic tatsächlich etwas angekommen ist. Bei dir solltest du sehen: Die Meldung zu „Ladung PV" ist weg, und Cockpit → Tag füllt sich mit Zahlen, die vorher auf „—" standen. Und falls doch ein solcher Hinweis stehen bleibt, ist er ab jetzt echt — dann kommt auf dem Topic seit über einer Woche nichts mehr an. Das wäre dann einen Blick auf den Publisher wert, nicht auf die Zuordnung. Noch eine Kleinigkeit, die mit drin ist: Wo doch einmal ein „—" steht, sagt eedc jetzt, woran es liegt. Bisher stand dort für jeden derselbe Rat „Sensor zuordnen" — für dich ein Weg ins Leere. Danke fürs Nachfassen. Du hast in diesem Faden jetzt zweimal dieselbe Frage gestellt, und beide Male war die App im Unrecht. Das erste Mal war ein falscher Satz, das zweite Mal eine ganze leere Ansicht. Viele Grüße |
|
Perfekt, die Meldung zu Ladung PV ist verschwunden! Und ja, ich nutze tats. kein HA, sondern Docker Standalone und füttere alles via MQTT. Eine Anmerkung noch: hier erscheinen Meldungen von mir unerklärlichen Sensor Werten. Kommt das vielleicht auch von irgendwelchen (bei mir nicht vorhandenen) HA-Sensoren? |
|
Hallo August, die Sensorwerte, die dir unerklärlich vorkamen, kamen nicht von HA-Sensoren — die hast du ja gar nicht. Sie kamen von deinen eigenen MQTT-Werten, und eedc hat sie falsch gelesen. Dein Bild mit den gefahrenen Kilometern hat es entschieden: 13272 gegen 1001 — das ist ein Tachostand, und keine Monatsdeutung macht diese Zahl sinnvoll. Was schiefging. Ein eedc-MQTT-Topic unter Die zweite Stelle war schlimmer, und die hättest du gar nicht sehen können. In Cockpit → Monat war es kein Vorschlag, sondern die angezeigte Zahl: Im laufenden Monat hat der Zählerstand deinen gespeicherten Monatswert verdrängt. Betroffen war genau deine Aufstellung — Standalone ohne Home Assistant, alles per MQTT. Ab v4.0.30 bildet eedc die Differenz über den Monat, aus den Ständen, die es ohnehin stündlich mitschreibt. Fehlt der Anfangsstand oder ist der Zähler zurückgesprungen, gibt es keinen Vorschlag statt eines falschen, und dein gespeicherter Wert bleibt stehen. Du musst nichts umstellen — dein Zählerstand war und ist das Richtige. Was du merken wirst: Die falschen „weicht ab"-Markierungen sind weg, und wo bisher ein Zählerstand stand, steht die Monatsmenge. Für gefahrene Kilometer und Ladevorgänge gibt es über MQTT künftig keinen Vorschlag mehr — für die schreibt eedc keine Zählerreihe mit, und ohne die lässt sich keine Monatsmenge bilden. Die trägst du wie bisher von Hand ein. Ich habe außerdem die MQTT-Anleitung berichtigt: Dort stand „Monatswerte", und genau das hat die Verwechslung eingeladen. Jetzt steht dort „Zählerstände". Danke fürs Nachhaken — das war das dritte Mal in einer Woche, und jedes Mal hattest du recht. Viele Grüße |
|
Ok, danke! Eins muss ich aber noch nachhaken:
Wäre es nicht möglich auch hier mitzuloggen und Monatsmengen zu erstellen, statt das manuell eintragen zu müssen? Meine Hoffnung war, dass ich nur im Zuge der Ersteinrichtung die historischen Daten ggf. manuell nachtragen muss, anschließend aber alles automatisch läuft. Entsprechende Werte würde ich ja bereits übermitteln, zumindest den km-Stand meines E-Autos, daraus könnte eedc ja die gefahrenen km errechnen, vergleichbar Netzanschlusszähler? eedc schlägt dafür ja bisher auch vor "kumulativer km- 
|
|
Hallo August, ja, das geht — und du hattest den richtigen Riecher, dass es gehen müsste: eedc bietet dir das Feld selbst mit dem Hinweis „kumulativer km-Zähler (Auto-Integration/OBD)" an. Warum es bisher nicht ging. Für einen Monatswert braucht eedc eine Menge, dein Sensor liefert einen Stand. Aus einem Stand wird eine Menge nur über die Differenz zweier Zeitpunkte — und dafür muss eedc die Reihe mitschreiben. Für Strom und kWh tut es das längst, für km und Ladevorgänge nicht. Deshalb kam bei dir gar kein Vorschlag. Das war übrigens die vorsichtige Variante, und zwar wegen deines eigenen Falls: Vorher landete dein Tachostand — 13272 — roh im Monatsfeld, wo 1001 gefahrene Kilometer hingehören. Ein leeres Feld ist ehrlich, ein Stand im Mengenfeld ist ein Datenverlust, der wie eine Messung aussieht. Was gefehlt hat, war nicht die Erlaubnis, sondern die Reihe. Was sich ändert. eedc schreibt deinen km-Zähler jetzt genauso mit wie einen Stromzähler und bildet daraus die Monatsdifferenz. Du bekommst den Vorschlag „1001 km" — nie den Tachostand. Für Ladevorgänge gilt dasselbe, auch wenn danach niemand gefragt hatte: Es ist dieselbe Bauform. Es ist gebaut, aber noch nicht draußen — es kommt mit der nächsten Version. Ich sage dir das lieber jetzt, als dass du nachsiehst und dich wunderst. Eine Grenze bleibt, und die gehört dazu: Bei einem Fahrzeugwechsel springt der Tachostand zurück. Das sieht für eedc aus wie ein Zählertausch, und dann gibt es für diesen Monat keinen Vorschlag statt eines falschen — den einen Monat trägst du von Hand ein. Danke fürs Nachhaken. Deine Frage hat einen Widerspruch aufgedeckt, der unserer war: eedc führte diese beiden Felder längst als Zählerfelder und bewarb den OBD-Zähler als Quelle — eingelöst hatte es das nur für Leute mit Home Assistant. |
|
Hallo August, es ist draußen — eedc 4.0.33. Der km-Zähler und die Ladevorgänge bekommen ihre Reihe: eedc schreibt deine MQTT-Stände jetzt selbst mit und schlägt dir die Differenz vor — die gefahrenen Kilometer des Monats, nie den Tachostand. Und weil du per MQTT lieferst, ein Hinweis aus demselben Release: Springt einer deiner Zähler regelmäßig auf null zurück — ein „…heute"-Helfer zum Beispiel —, bekommst du dafür ab jetzt keinen Monatswert mehr. Vorher stand dort eine Zahl, die aus dem ersten und letzten Stand des Monats gerechnet war und damit nur einen einzigen Tag umfasste; sie sah plausibel aus und kam ungefragt. Der Daten-Check sagt dir jetzt, wenn er so eine Reihe findet, und nennt den Weg: den fortlaufenden Stand schicken. Viele Grüße, Gernot |
|
Top, schönen Sonntag noch! |
Uh oh!
There was an error while loading. Please reload this page.
Verstehe dies Meldung des Daten-Checkers nicht:
Tats. habe ich historische Ladedaten aus evcc importiert, und es werden beim Auto auch PV-Anteile angezeigt:
All reactions