SOC per MQTT wird nicht zuverlässig aktualisiert #18629
Comments
|
Kann es sein, dass du den poll.mode entsprechend deiner Erwartung konfiguriert hast? https://docs.evcc.io/docs/reference/configuration/loadpoints#poll |
|
Die Daten werden initial von einer HomeAssistant-Integration von Kia abgeholt und dann über eine zeitgesteuerte NodeRed-Automation jede Minute an das Topic aktualisiert. Diese Daten kommen ja auch an. Das habe ich sowohl mit einem MQTT-Listener überprüft als auch wird der Wert von evcc erkannt, wie im Trace zu sehen ist. Ein pull.mode kommt hier gar nicht imho vor. Die Reichweite, die 1:1 genauso konfiguriert ist, wird richtig gelesen und auch aktualisiert. Daher können wir den pull.mode - denke ich - ausschließen. Das Verhalten ist leider auch nicht reproduzierbar, da durch einen Neustart die Werte wieder richtig aktualisiert werden. Wäre es denkbar, die Datenbank-Kommandos zu tracen? Dann müssten wir, was in der Datenbank ankommt. |
|
Hast du eine längeres Logfile, das die Entwicklung zeigt? |
|
Ich habe mal hier einen längeren MQTT-Auszug, der aber immer wieder das gleiche zeigt: [mqtt ] TRACE 2025/02/07 09:00:09 recv evcc/niro/soc: '36' Nach einem Neustart von evcc wird dann der SOC richtig erkannt. (In der Datenbank wird der State vom SOC nicht vorgehalten, soweit ich das gesehen habe.) [mqtt ] INFO 2025/02/07 09:38:14 connecting evcc at tcp://192.168.2.218:1883 |
|
Die Logschnipsel helfen nicht da nirgendwo ersichtlich ist, welcher/ dass ein falscher vehicle soc verwendet würde. Ich mache zu bis es ein passendes Logfile gibt (loadpoint auf debug) |
|
Hier ist das gesamte Logfile auf Trace: [site ] DEBUG 2025/02/07 13:31:17 ---- Und dazu das Resultat des State-Endpoints: { Beim vehicleSoc wird über 90 ausgegeben, wobei 70 auf dem Topic evcc/niro/soc gepublisht wurde. |
|
Ich denke, der Unterschied kommt daher, dass das EstimatedSoc angezeigt wird. Das kommt aus der Zeile soc estimated: 90.09% (vehicle: 70.00%) Vielleicht liegt es ja daran, das die Schätzung herangezogen wird? |
|
Irgendwie ist der Estimator der Meinung, dass die vorhandenen Werte keinen richtigen Sinn mehr ergeben und dann wird der SOC ermittelt, anstatt den vehicleSoc zu verwenden: if s.estimate && s.virtualCapacity > 0 { wenn dies der Fall ist, dann wird der Soc berechnet: } else { Der Wert kommt anscheinend richtig vom MQTT, aber entweder ist socDelta nicht genau 0 oder das energyDelta kleiner als 0. Was könnte das für eine Ursache haben? |
|
Ich glaube, den Grund für das Phänome gefunden zu haben: Das Batterie-Level wird alle 30 Minuten abgefragt. Nun kommt der Code an die Stelle, wo überprüft wird, ob das Auto die geladene Energie berücksichtigt. Das führt dazu, dass das Auto voller geschätzt wird, als es tatsächlich ist. Wenn noch die chargedEnergy und die prevChargedEnergy getraced werden könnte, wären wir schlauer. :-) Vielen Dank im übrigen für das tolle Projekt. |
|
Noch eine Erkenntnis: nach einiger Zeit ist socDiff > 10 und energyDiff > 0 und danach ist die Berechnung wieder intakt, wie man hier sieht: hier geht der Ladestand schlagartig von 95% auf 77% (richtiger Wert) runter: [lp-1 ] DEBUG 2025/02/07 14:03:17 pv disable timer remaining: 1m0s |
|
Mach doch mal den Estimator aus. Der kommt vmtl. nicht mit dem Zeitverhalten der soc-Sprünge klar. |
|
Werde ich machen. Der Estimator ist ja eine prima Sache, wenn er aber 20% zu viel Ladung berechnet wird, führt das im Endeffekt zu einem Aha-Effekt, wenn das Auto doch nicht geladen ist. |
|
Dumme Frage: Wo kann ich in meiner Konfiguration estimate: false setzen? Ich habe es auf SOC-Level, Loadpoint und vehicle probiert. Jeweils wurde mir gemeldet, dass die Konfiguration nicht gültig ist. |
|
loadpoint -> soc https://docs.evcc.io/docs/reference/configuration/loadpoints#soc |
|
Merci. So wird die Konfiguration akzeptiert. |
Unser Kia Niro erhält seinen SOC über ein MQTT Topic. (evcc/niro/soc)
Der SOC wird auch erkannt und im Log festgehalten:
[sma ] TRACE 2025/02/06 15:22:02 recv 10.2.201.120: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma ] TRACE 2025/02/06 15:22:03 recv 10.2.201.120: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma ] TRACE 2025/02/06 15:22:04 recv 10.2.201.120: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[mqtt ] TRACE 2025/02/06 15:22:04 recv evcc/niro/soc: '36'
[mqtt ] TRACE 2025/02/06 15:22:04 recv evcc/superb/soc: '31'
[mqtt ] TRACE 2025/02/06 15:22:04 recv evcc/niro/range: '110'
[mqtt ] TRACE 2025/02/06 15:22:04 recv evcc/superb/range: '10'
[sma ] TRACE 2025/02/06 15:22:05 recv 10.2.201.120: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma ] TRACE 2025/02/06 15:22:06 recv 10.2.201.120: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma ] TRACE 2025/02/06 15:22:07 recv 10.2.201.120: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma ] TRACE 2025/02/06 15:22:08 recv 10.2.201.120: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
Allerdings werden die 36% nicht gespeichert:
Die 110 km Restreichweite werden allerdings empfangen und gespeichert.
Kann bitte jemand überprüfen, warum der SOC nicht zuverlässig gespeichert wird?
Ich kann gerne auch unterstützen.
Vielen Dank!
Steps to reproduce
Nach einem Neustart wird der SOC wieder korrekt angezeigt.
Configuration details
Log details
What type of operating system or environment does evcc run on?
Linux
External automation
Nightly build
Version
v0.133.0
The text was updated successfully, but these errors were encountered: