Closed binderth closed 2 months ago
Bei diesem Status
[main ] DEBUG 2024/06/18 07:37:32 vehicle status: A (Kia EV6)
[main ] DEBUG 2024/06/18 07:37:32 vehicle status: B (Kia EV6 adesso)
kann nur Adesso erkannt werden.
Das stimmt. Aber spätestens mit der neuen MQTT-Nachricht und allerspätestens mit dem nächsten SoC-Poll sollte das Fahrzeug aich ändern können
Die Erkennung passiert bei Verbindung. Danach änder sich das Fahrzeug ja nicht mehr.
Ja - und nein. Du wirst bei keinem custom-Fahrzeug mit egal welcher API die IEC-Statusänderung vor Änderung der (meist lokalen) Wallbox mitbekommen. Dazu sind die vehicle-APIs zu träge.
Das wiederum hat nix mit einem Custom vehicle zu tun. Ich frag mich allerdings warum das sonst so wunderbar funktioniert?
Bei einem custom vehicle läuft der API-Call asynchron zu evcc. Bei einem evcc-vehicle habt ihr im Code sicher einen wait for answer eingebaut. Auch hier habt ihr keine Chance den IEC-Change parallel oder gar vor dem Wallbox change zu bekommen.
@binderth du könntest als workaround mal probieren, beim abstecken den alten Status des angeschlossenen Fahrzeugs zu nullen, also einfach auf A. Solange bis es einen neuen gibt. Das sollte als Workaround schon reichen.
@andig Bin wieder ausm Kurzurlaub zurück. ja, mein Workaround ist, bei jedem Wechsel des Status eines angeschlossenen Fahrzeugs lasse ich per API einen refresh auf den loadpoint machen (PATCH /api/loadpoints/
Wenn es eine evcc-interne Lösung dafür gäbe, kommt das auch weniger versierten Nutzern zugute.
Wie sollte die denn aussehen?
@binderth Ich bin auch gespannt wie das aussehen soll. Wir haben auch 2 Autos zwei Wallboxen und manchmal geht die Erkennung nicht optimal. Hatte aber noch keine Zeit zu forschen. Ich hänge mich hier mal mit rein.
Wie sollte die denn aussehen?
Wenn per MQTT oder API das aktuelle Fahrzeug nicht mehr den IEC-Lade-/Warte-Status hat, sollte eine erneute Abfrage laufen. Wenn "Gastfahrzeug" steht, sollte im eingestellten Rythmus geprüft werden, ob ein anderes Fahrzeug lädt.
Das könnte ja auf "custom"-Fahrzeuge eingeschränkt werden. Auf jeden Fall sollte eben ein anderes gesendeten Fahrzeug erkannt werden, wenn wie bei mir per MQTT eben der IEC-Status nicht zum aktuellen "erkannten" Fahrzeug passt.
Wenn per MQTT oder API das aktuelle Fahrzeug nicht mehr den IEC-Lade-/Warte-Status hat, sollte eine erneute Abfrage laufen.
Was bedeutet das? Der Ladepunkt kennt kein Mqtt.
Das könnte ja auf "custom"-Fahrzeuge eingeschränkt werden
Der Ladepunkt ist agnostisch. Ein Fzg ist ein Fzg.
Auf jeden Fall sollte eben ein anderes gesendeten Fahrzeug erkannt werden, wenn wie bei mir per MQTT eben der IEC-Status nicht zum aktuellen "erkannten" Fahrzeug passt.
Wie?
Wenn der Ladepunkt agnostisch ist, wie erfolgt die Zuordnung eines Fahrzeugs zu diesem? Und wenn eben jenes Fahrzeug nun in "A" landet, warum sollte es weiter stur als ladendes Fahrzeug gelten?
(Wenn ihr kein Bock auf custom-vehicles habt, dann sagt das bitte, kommt mir echt mühsam vor)
Ich meine damit: der Ladepunkt weiss nichts von Mqtt oder custom. Für ihn ist ein Auto ein Auto. Du kannst also nicht sagen „bei Mqtt soll das passieren, bei normalen Autos jenes“.
Die Frage war ernst gemeint: wie soll die Logik aussehen?
Kenne jetzt weder Code, noch Architektur, aber irgendwo muss es ja eine Zuordnung von Fahrzeugen zu Ladepunkten geben.
Wenn sich nun ein Fahrzeug ändert, das an einem Ladepunkt "gemeldet" ist und nun "A" hat, kann doch ein erneuter Ladepunkt-Check gestartet werden? Ich mach das halt per API über mein smarthome (PATCH /api/loadpoints//vehicle
), aber das kann ja nicht jeder.
Dann müssten wir anhaltend die Fahrzeug APIs pollen? Leider keine gute Idee :(
Das ist doch nicht nötig, bzw ist das ja mit dem poll.mode
bzw poll.interval
für jeden steuerbar!
Wenns gepusht wird (durch MQTT oder per (evtl neuer?) API), fragt ja auch keiner, woher das kommt!??
Ist nur ziemlich unlogisch, dass evcc den Fahrzeugstatus kennt - aber null drauf reagiert und stur bei einer veralteten Meinung bleibt.
Die Frage war: nach welchem Algorithmus soll das geschehen? Bisher gibts dazu keine Antwort die umsetzbar wäre. Der Algo muss von custom
oder mqtt
unabhängig sein da der Loadpoint davon nix weiss. Per Default werden die APIs nur 1x je Stunde abgefragt, es sei denn das Auto lädt.
Die Antwort ist: sobald ein Fahrzeug den Status ändert!?
Das kommt ja nicht von alleine. Dazu müsste dann der Status ständig abgefragt werden.
Ich fasse mal zusammen, ggf. prüfe ich auch mal später den Sourcecode.
Wenn sich der State im Auto ändert (wann auch immer), bekommen wir das mindestens per MQTT gepusht!?, wenn dann das Auto den Loadpoint kennt und gerade verbunden ist könnte man da eine fuktion aufrufen, die das gewünsche verhalten ausführt. Also reset des states etc. Dei Frage ist ob das zu 100% das gewünschte verhalten wäre.
Dann wäre es doch auch nicht schlimm, das erstmal für die APIs anzubieten die Push unterstützen oder nicht? Beispiel bei Teslamate wäre es ja über StreamingAPI -> MQTT auch nice.
Die APIs die das nicht können, haben halt das "tolle" verhalten noch nicht.
Der Loadpoint ist führend. Devices können/sollen nichts am State des Loadpoints ändern. Schon gar keine generischen Devices (mqtt), denn das würde wieder neue Device-APIs bedeuten.
Das kommt ja nicht von alleine. Dazu müsste dann der Status ständig abgefragt werden.
Full circle. So ist es und stand schon in https://github.com/evcc-io/evcc/issues/14457#issuecomment-2213362202. Die Soc-Abfragen haben ein eigenes Caching, alle anderen APIs gehen i.A. hart auf das Fahrzeug durch.
Die Frage nach dem Algorithmus kommt nicht von ungefähr ;)
Ok verstanden.
Aus objektorientierter Sicht ist das Auto ja mal ein Objekt mit einem State (Kabel dran) daher könnte das Auto dem bekannten Loadpoint, da es da ja dran hängt, auch dem Loadpoint sagen dürfen, wenn das Kabel aus ihm entfernt wurde. Da wird ja nicht beliebig im Loadpoint rumgefingert, sondern würde ggf. ein ganz definierte Public methode aufgerufen, oder in Go ein API? Also highlevel ist klar wie man es machen müsste / könnte :-)
Wobei mir klar ist, dass das erstmal UML denken ist und ich mir den Source noch nicht angeschaut habe.
Keine neue Erkenntnisse/ kein Algorithmus. Closing.
Describe the bug
Wenn sich der Status von custom-definierten Fahrzeugen ändert, hat das keine Änderungen für die evcc-Logik, welches Fahrzeug am Loadpoint aktuell lädt. Das ist wichtig, bei mehreren custom-definierten Fahrzeugen, dass sich deren aktueller IEC-Status auch auf evcc auswirkt.
Steps to reproduce
In den Logs kann man erkennen, dass
"ev6adesso" um 07:31:32 abgesteckt wurde
der Loadpoint wurde um 07:37:32 auf B gesetzt
im folgenden API-refresh waren die MQTT-messages noch ev6: A, ev6adesso: B
um 07:45:00 kamen per MQTT-messages ev6:B, ev6adesso:A
um 07:48:02 wurde mit dem Ablauf von
soc.poll.mode: always
undsoc.poll.intervall: 5m
erkannt, dass das Fahrzeug auf A gewechselt istaber das Fahrzeug "ev6adesso" bleibt weiterhin aktiv, siehe auch
vehicle.soc: 85
,vehicle.range: 374
, das sind nämlich die Werte von ev6adesso gewesen. ev6 hatte 34%.Configuration details
Log details
What type of operating system are you running?
Docker container
Version
v0.127.2