Sumpfdotter
commented
2 months ago evcc-20240801-005317-debug-black.log Full log file
Closed Sumpfdotter closed 2 months ago
Sumpfdotter
commented
2 months ago evcc-20240801-005317-debug-black.log Full log file
Hakr23
commented
2 months ago I have the same issue with the following setup:
Car: Audi Q4 etron Wallbox: ABB Terra AC 22kw, connected via Modbus TCP/IP evcc version: 0.129.0 OS: Ubuntu Server 24.04 LTS
andig
commented
2 months ago Bitte aktuelle Nightly Version verwenden.
Sumpfdotter
commented
2 months ago Okay, sorry. Ich vergaß zu erwähnen: Ich hatte ein halbwegs aktuelles Nightly vorher und bin extra zurück auf Stable um das Verhalten dort zu verifizieren. Hab jetzt aber nochmal das aktuellste nightly genommen (0.129.0+1722479088) statt (0.129.0) und nochmal eine ganze Testreihe gemacht. Ich bekomme jetzt offenbar erfolgreiches Schnellladen bei jedem ersten Laden nach einem evcc Reboot. Also ich muss nicht die Kopplung aufheben.
Also Verhalten mit aktuellem Nightly:
Also muss ich für jede Ladung (außer die erste nach Reboot) manuell den Modus einmal wechseln z.B. PV+min und zurück auf Schnell. Nach dem Wechsel zurück auf SChnell fährt er hoch auf 16A.
Im log bekomme ich als Fehlermeldung zwischen zwei Ladevorängen (?) "Carport: charger out of sync: expected disabled, got enabled". Falls relevant kann ich noch mehr Tests machen und ggf. mehr Logfiles. Würde gerne genauer wissen, worauf ich achten könnte, denn die Tests sind immer ein wenig aufwendig für mich.
andig
commented
2 months ago Bitte noch Logfile fürs nightly.
Sumpfdotter
commented
2 months ago Okay. Kommt. Das kann ich erst morgen mitschneiden, wenn die Autos wieder SoC eingebüßt haben. Beide Autos sind über Default-Target SoC. In dem Zustand tritt der Fähler nicht auf. :-) Ich habe in einer älteren Version mal den Target-SoC der Autos passend eingestellt (80% und 85%) und nun bekomme ich das nicht mehr verändert. Ich finde das Setting nicht mehr um das mal temporär hochzustellen.
Sumpfdotter
commented
2 months ago Anbei das Log mit dem aktuellen Nightly 0.129.0+1722651905
evcc-20240803-072016-debug.log
Zur Info: Nach dem Installieren und Restart zeigte die Wallbox im Webfrontend an, dass evcc noch nicht mit ihr verbunden sei. Um Zeit zu gewinnen habe ich manuell im Wallbox-Webfrontend entkoppelt und neu gekoppelt.
Aber: Mir ist noch was aufgefallen!
Es ist ja so, dass die Elliwallbox über eine HEMS-Lampe am Gerät verfügt. Diese leuchtet grün, wenn das HEMS verbunden ist und kein Auto angeschlossen ist. Wenn ich das Auto anschließe springt sie zunächst auf gelb, was bedeutet, dass der Ladestrom reduziert ist (default-verhalten der Box, sie wartet auf die Ladestromvorgabe vom HEMS).
Beim ersten Ladevorgang stöpsele ich das Auto an, die HEMS-Lampe springt auf gelb, aber schon nach kürzester Zeit springt die Lampe wieder auf grün, und zwar auch, wenn ich den Ladevorgang noch garnicht mit RFID gestartet habe. D.h. evcc scheint beim ersten Ladevorgang der Wallbox aufgrund des Anstöpsel-Ereignisses schon getriggert zu sein, die maximale Ladeleistung aufzurufen. Wenn ich den Ladevorgang dann via RFID-Karte starte, startet dieser auch sofort mit 11kW. Danach kann dann evcc nach einer Weile auch das Auto identifizieren. Dabei bleibt es dann bei 16A. Alles korrekt.
Ab dem zweiten Ladevorgang stöspele ich das Auto an, die HEMS-Lampe bleibt aber auf gelb. Ich habe extra mal länger gewartet. Evcc scheint sich hier nicht getriggert zu fühlen, der Wallbox die maximale Leistung aufzurufen. Nachdem ich das Laden dann starte (RFID-Karte) kann evcc einige Zeit später das Auto identifizieren. Der Ladestrom wird aber auch dann nicht mehr erhöht, sondern das passierte erst, nachdem ich von "Schnell" auf "min+PV" und "Schnell" zurückgewechselt habe.
Der eine Fehlereintrag im Log ist übrigens neu (neues nightly?). Den hatte ich bisher noch nie, AFAIK.
Sumpfdotter
commented
2 months ago Habe den Test wiederholt, habe den Kommentar von vor 12 Minuten entsprechend präzisiert.
andig
commented
2 months ago Textaufgabe. Wo zeigt das Logfile welches Problem?
Sumpfdotter
commented
2 months ago Echt jetzt? Für mich sind das auch mehrere Stunden Test gewesen und ich hab mir anfangs die Logfiles angeschaut. Wenn Du was gefunden hast, sag es bitte.
andig
commented
2 months ago Echt jetzt?
Ja! Bitte konkret: welches Problem? Und bei welchem Timestamp? Du kannst jetzt nicht erwarten, dass ich mir das selbst ausdenke oder dem Logfile raus suche. Es gibt noch mehr Issues als dieses hier, daher braucht es bitte ein bisschen Kontext.
DerAndereAndi
commented
2 months ago Allgemeines: Wichtig ist bei einem Log das Verhalten mit Zeitpunkten zu beschreiben, so dass man das im Log nachvollziehen kann. Und dann auch wo ein nicht erwartetes Verhalten auftritt. Vermutungen helfen überhaupt nicht, sondern machen es noch schwieriger das Problem zu verstehen. Vor allem wenn man gar nicht weiss wie das interne Vorgehen ist.
Ein Intervall von 30s ist in der Konfigurationsdatei hinterlegt, d.h. Änderungen werden auch nur alle 30s gemeldet. Was in der Zwischenzeit passiert, ist meist unbekannt!
Ladevorgang:
Ladevorgang:
Das Problem scheint folgendes zusein:
andig
commented
2 months ago Als das Fahrzeug erkannt wird, und der Lademodus damit auf "now" gestellt wird, wird damit keine Änderung des Ladestrom auf 11kW durchgeführt.
Vmtl. ist evcc der Meinung, dass noch 16A eingestellt sind da es zwischendurch auch nichts anderes gesetzt hat. Aufgrund eines Bugs mit dem Lastmanagement haben wir das in https://github.com/evcc-io/evcc/pull/15218 geändert. Vielleicht hilft das ja auch hier? Ich trigger mal ein nightly...
andig
commented
2 months ago Bitte morgen nochmal testen. Falls Problem noch auftritt bitte Logfile.
Sumpfdotter
commented
2 months ago Echt jetzt?
Ja! Bitte konkret: welches Problem? Und bei welchem Timestamp? Du kannst jetzt nicht erwarten, dass ich mir das selbst ausdenke oder dem Logfile raus suche. Es gibt noch mehr Issues als dieses hier, daher braucht es bitte ein bisschen Kontext.
@andig, bitte nicht ärgern. Ich will doch auch nur helfen so gut es geht. Ich habe ein Issue gemeldet, was bei jeder Sequenz dieser Art unabhängig von den Timings auftritt. Von daher hatte ich erwartet, dass ihr nur auf die Reihenfolge der Events schauen müsst und nicht auf die Timings. Außerdem habe ich mir vor dem Erstellen des Issues Eure Anleitung dazu angeschaut. Dort steht nicht drin, dass ihr immer das tatsächliches und erwartetes Verhalten bezogen auf die Log-Zeit genannt haben wollt. Wenn das wichtig für Euch ist, dann macht es vielleicht Sinn, das dort zu ergänzen. Ich mache das auch gerne, allerdings ist es super schwierig, wenn man draußen im Freien steht, und evcc irgendwo remote werkelt. Ich schlage vor, dass man vielleicht eine Möglichkeit schaffen könnte, die evcc-Zeit im Frontend einzublenden. Dann könnte man mit dem Handy auf die Uhr schauen und die Trigger zu leicht merk-, protokollier- und analysierbaren Zeiten setzen. Das wäre tatsächlich hilfreich (z.B. "Anstecken um xx:xx:00"). Nachdem ich das Issue gefiled hatte, hast Du mich gebeten genau den Test mit den Nightly zu wiederholen. Das habe ich getan und nicht mehr, Du hattest nicht nach mehr gefragt. Woher soll ich also wissen, dass ich Dir das Logfile genauer voranalysieren soll? Deshalb bitte nicht "Textaufgabe" schreiben. Ich glaube wir wollen beide das Gute und das ärgert dann mich, wenn ich keine klare Anweisung bekomme aber trotzdem einen Flame kassiere. :-) Natürlich habt ihr viele Issues und ich will dabei helfen, Euren Aufwand zu minimieren. Aber das Logfile sah jetzt für mich absolut passig aus zu dem, was ich beobachtet und beschrieben hatte. Also müsst ihr glaube ich schon selbst reinschauen, wo genau jetzt der Fehler passiert sein könnte. Also: Nein, ich erwarte nicht, dass Du da selbst im Detail reinschaust, hier ist alles irgendwo freiwillig. Nur wird es auch nicht weitergehen, wenn keiner mal genauer reinschaut. Denn ich habe nix gefunden.
Völlig richtig ist auch: Ich hatte in meiner Beschreibung, dass die Wallbox-Lampe sofort auf grün springt, dann eine falsche Vermutung getroffen, dass dieses Ereignis von evcc getriggert sein müsste. Einfach weil die Anleitung der Wallbox das so vermuten lässt. Ich werde da in Zukunft versuchen präziser sein. Es ist präzise gesprochen so, dass die Wallbox beim ersten Anstecken nach dem evcc-reboot bzw. erneutem Koppeln, aus irgendeinem Trigger heraus (intern oder extern) auf 16A stellt, und zwar noch bevor das Laden gestartet wird, und bei jedem Folge-Ladevorgang stellt sie auf 6A. In jedem Falle verbleibt sie bei diesem Wert, trotz Modus "Schnell".
Danke auch an Dich, @DerAndereAndi, dass Du das Logfile schon durchgegangen bist und die Uhrzeiten herausgeschrieben hast. Aus Zeitgründen konnte ich das nicht vor Dir tun. Ich unterstütze Euch gerne und mache das beim nächsten Mal. Wie gesagt: Ich nehme immer noch an, dass es ein kausales und kein temporales Problem ist, und dass die Timings daher unerheblich sind. Aber das könnt nur ihr wissen.
Den Test mit dem neuen Nightly mache ich schnellstmöglich (hoffentlich morgen). Viele Grüße!
Sumpfdotter
commented
2 months ago Bitte morgen nochmal testen. Falls Problem noch auftritt bitte Logfile.
Test wiederholt mit: evcc 0.129.0+1722738220
Hatte dieses Mal den e!up nehmen müssen, der ist 2-phasig, aber sonst kein Unterschied.
Problem tritt noch auf.
Logfile: evcc-20240804-140701-debug-black.log
Logfile-Analyse und Korrespondenz zu ist/soll-Timestamps plane ich heute abend anzufügen.
DerAndereAndi
commented
2 months ago Das Verhalten ist identisch.
andig
commented
2 months ago Problem tritt noch auf.
Welches Problem? Und v.a. wo? Bitte- aus tiefstem Herzen- Logfile mit konkretem Fehler: was war erwartet, was passiert stattdessen, bei welchem Timestamp? Wieder 10min meiner Zeit weg in der ich mir andere Fehler hätte anschauen können. Es skaliert einfach nicht wenn ich mir die Probleme aus tausenden Zeilen Logfiles selbst raus suchen muss...
Sumpfdotter
commented
2 months ago Problem tritt noch auf.
Welches Problem? Und v.a. wo? Bitte- aus tiefstem Herzen- Logfile mit konkretem Fehler: was war erwartet, was passiert stattdessen, bei welchem Timestamp? Wieder 10min meiner Zeit weg in der ich mir andere Fehler hätte anschauen können. Es skaliert einfach nicht wenn ich mir die Probleme aus tausenden Zeilen Logfiles selbst raus suchen muss...
Nach welches Problem wird es wohl es? Es ist immer noch das Problem, das im Issue beschrieben ist. Die Beschreibung hält sich zu 100% an Euer Template und enthält eine klare Beschreibung welches das Ist-Verhalten ist und welches das erwartete Verhalten ist, und wie man es reproduziert. Zitat:
- Start charging via RFID tag ==> evcc is in "Schnell" mode, BUT charging starts and raises to 6A (4,1kW) only --> expected behavior: charging starts and raises to 16A (11kW)
Außerdem hängt wie gefordert das Logfile anbei, schon im ersten Post. Sorry, mein Leben muss auch skalieren, und aus meiner Sicht lässt Du mich nun zum dritten Mal einen Test mit immer neueren Nightlies wiederholen, und jetzt sagst Du mir, Du hast das Problem nicht verstanden, d.h. ich teste zum dritten Mal obwohl es gar keine relevante Änderung in der Software gab? Das skaliert so auch nicht.
Wer soll denn sonst das Logfile lesen, wenn nicht der Entwickler? Das muss ich bei den Nutzern meiner Software doch auch machen. Der Nutzer weiß doch garnicht die interna, die das System da so loggt. Ich kann und werde wie Dir natürlich gerne wie auch von mir versprochen die Timestamps zum Log liefern, da Du sagst, dass Dir das hilft. Die Hilfe bekommst Du! Nur muss ich dazu eben auf meiner Seite "skalieren", und dann kommt das auch.
Nichtsdestotrotz nahm ich natürlich an, Du hättest irgendeinen Fix committed, sonst hättest Du es mich ja nicht zum dritten Mal testen lassen, oder? Und da wollte ich Dir schnelle Rückmeldung geben, ob der Fix was gebracht hat. Wenn es einen gab: Nein, hat er nicht. Das war die Message. Wenn es keinen gab: Warum muss ich dann den Test wiederholen?
Es gibt jetzt schon drei Tests mit drei verschiedenen Versionen, also immer das gleiche Problem. Auch ein anderer User hat es bestätigt. Es gibt auch dank @DerAndereAndi eines Logfile, das mit den Zeiten korreliert wurde. Und ich kann Dir und werde Dir das auch wie versprochen noch für das dritte Logfile liefern. Nur habe ich auch ein Leben und muss das halt irgendwo zeitlich einbauen. Jetzt zum Beispiel.
Sumpfdotter
commented
2 months ago Bitte morgen nochmal testen. Falls Problem noch auftritt bitte Logfile.
Test wiederholt mit: evcc 0.129.0+1722738220
Hatte dieses Mal den e!up nehmen müssen, der ist 2-phasig, aber sonst kein Unterschied.
Problem tritt noch auf.
Logfile: evcc-20240804-140701-debug-black.log
Logfile-Analyse und Korrespondenz zu ist/soll-Timestamps plane ich heute abend anzufügen.
Vorbedingung: evcc konfiguriert auf Modus "Schnell", evcc läuft nicht
Korrespondenz Logfile-Zeiten zu Ereignissen:
2024/08/04 13:58:04: evcc gestartet, wallbox mit evcc gekoppelt, Energie-Manager-Lampe an Wallbox ist auf grün
2024/08/04 14:02:00: Auto an Wallbox angeschlossen (e!up, 2 Phasig), Energie-Manager-Lampe springt auf gelb
ca. 2024/08/04 14:02:03-14:02:08: Energie-Manager-Lampe an Wallbox springt auf grün
2024/08/04 14:02:15: Laden per RFID-Tag gestartet (Energie-Manager-Lampe an Wallbox bleibt auf grün) --> Auto lädt wie gewünscht im Schnellmodus mit 2x16A (grüne Energie-Manager-Lampe)
2024/08/04 13:03:00: Ladevorgang gestoppt durch Abziehen des Kabels
2024/08/04 14:04:00: Auto erneut an Wallbox angeschlossen, Energie-Manager-Lampe springt auf gelb --> Feststellung: Dieses Mal springt die Energie-Manager-Lampe nicht auf grün
2024/08/04 14:04:15: Laden per RFID-Tag gestartet (Energie-Manager-Lampe an Wallbox bleibt auf gelb) --> TATSÄCHLICHES VERHALTEN: Auto lädt trotz Schnellmodus mit nur 2x6A (gelbe Energie-Manager-Lampe) --> ERWARTETES VERHALTEN: Auto lädt im Schnellmodus mit 2x16A (grüne Energie-Manager-Lampe)
Sumpfdotter
commented
2 months ago Ich habe zur besseren Verdaulichkeit mal die beiden Ladevorgänge aus dem Logfile separiert:
Ladevorgang 1 (direkt nach Reboot, Fehler tritt nicht auf): evcc-20240804-140701-debug-black-Laden1.log
Ladevorgang 2 (Folgevorgang, Fehler tritt auf): evcc-20240804-140701-debug-black-Laden2.log
Das ist das selbe Log, nur freigeschnitten. Wie schon gesagt: Ich erkenne leider keinen wirklichen Unterschied. Vielleicht passt die Vermutung von @andig, dass evcc noch von 16A ausgeht, und daher nichts neues anweist (war nicht meine Vermutung, ich soll ja nichts vermuten ;-)). Will nur sagen: bei älteren Versionen (0.128) war das Fehlverhalten wie gesagt noch nicht aufgetreten, also darf man annehmen, dass evcc was am Verhalten geändert hat.
DerAndereAndi
commented
2 months ago Danke @Sumpfdotter.
Der Unterschied ist wie folgt
Beim 1. Ladevorgang:
[lp-1 ] WARN 2024/08/04 14:02:12 charger out of sync: expected disabled, got enabled
[lp-1 ] DEBUG 2024/08/04 14:02:12 charger enable
[eebus ] DEBUG 2024/08/04 14:02:12 Send: d:_i:47859_Elli-Wallbox-22XXXIF write 50 LoadControlLimitListData
[lp-1 ] DEBUG 2024/08/04 14:02:12 max charge current: 16ABeim 2. Ladevorgang:
[lp-1 ] WARN 2024/08/04 14:04:13 charger out of sync: expected disabled, got enabled
[lp-1 ] DEBUG 2024/08/04 14:04:13 charger enableEs wird beim 2. kein maximaler Ladestrom aktiv gesetzt.
Das Problem bei den Elli Boxen: Sie informieren nicht immer korrekt über den aktuellen Zustand. Normalerweise sollte eine (EEBUS) Wallbox nach der Freigabe den maximalen Ladestrom von sich aus erlauben. Und von außen muss man nur eingreifen wenn man eben diesen nicht haben will.
Was die Box genau meldet, kann ich leider nur mit Logdaten sagen, welche die EEBUS Daten im "trace" level enthalten.
DerAndereAndi
commented
2 months ago Ergänzung: Ein weiteres Log mit trace level für eebus würde sehr helfen. Brauchst es nicht stückeln. Hauptsache es enthält alles ab dem 1. Anstecken. Danke!
Sumpfdotter
commented
2 months ago Danke @Sumpfdotter.
Der Unterschied ist wie folgt
Beim 1. Ladevorgang:
[lp-1 ] WARN 2024/08/04 14:02:12 charger out of sync: expected disabled, got enabled [lp-1 ] DEBUG 2024/08/04 14:02:12 charger enable [eebus ] DEBUG 2024/08/04 14:02:12 Send: d:_i:47859_Elli-Wallbox-22XXXIF write 50 LoadControlLimitListData [lp-1 ] DEBUG 2024/08/04 14:02:12 max charge current: 16ABeim 2. Ladevorgang:
[lp-1 ] WARN 2024/08/04 14:04:13 charger out of sync: expected disabled, got enabled [lp-1 ] DEBUG 2024/08/04 14:04:13 charger enableEs wird beim 2. kein maximaler Ladestrom aktiv gesetzt.
Das Problem bei den Elli Boxen: Sie informieren nicht immer korrekt über den aktuellen Zustand. Normalerweise sollte eine (EEBUS) Wallbox nach der Freigabe den maximalen Ladestrom von sich aus erlauben. Und von außen muss man nur eingreifen wenn man eben diesen nicht haben will.
Was die Box genau meldet, kann ich leider nur mit Logdaten sagen, welche die EEBUS Daten im "trace" level enthalten.
Das Logfile ist kein Problem, danke Euch @DerAndereAndi und @andig.
evcc-20240807-164239-trace-black.log
Verflixt, das Logfile enthält jetzt ja nur noch eebus messages. Ich hoffe, ich bekomme die Zeiten zusammen: 16:36:00 EVCC gestartet 16:37:00 Elli abgekoppelt (Über Elli Webfrontend) 16:37:30 Elli angekoppelt (Über Elli Webfrontend) 16:38:00 Ladestecker angesteckt 16:38:20 1. Laden gestartet mit RFID-Karte (lädt mit 16A --> erwartet sind 16A) 16:39:20 Ladestecker abgesteckt 16:40:00 Ladestecker angesteckt 16:40:20 2. Laden gestartet mit RFID-Karte (lädt nur mit 6A --> erwartet sind 16A) 16:41:20 auf Modus "min+PV" umgestellt 16:41:50 auf Modus "Schnell" umgestellt (lädt nun mit 16A --> erwartet sind 16A) 16:42:20 Ladestecker abgesteckt
Zeiten korrigiert.
DerAndereAndi
commented
2 months ago Die anderen Ausgaben wären auch sehr wichtig. Kommst du da evtl. noch ran? Denn das eine ist was über EEBUS geht/kommt, das andere was evcc damit macht.
Sumpfdotter
commented
2 months ago Die anderen Ausgaben wären auch sehr wichtig. Kommst du da evtl. noch ran? Denn das eine ist was über EEBUS geht/kommt, das andere was evcc damit macht.
Ja, das hab ich befürchtet. Mir fehlt das Bedienwissen. Ich hatte zuerst im yaml auf "trace" gestellt, das hat nichts bewirkt. Wenn in dann in der Webgui auf "Trace" gehe und "eebus" auswähle, kommt nur noch eebus. Also würde ich "Trace - alle" machen, aber das könnte dann sehr viel sein? Oder gibt es eine Möglichkeit alle auf Debuglevel zu haben und nur eebus auf trace?
DerAndereAndi
commented
2 months ago Änderungen an der Konfigurationsdatei erfordern einen Neustart von evcc und das hilft dann auch nur wenn man sich das Log vom Betriebssystem holt.
Daher ist Trace für alle wohl der einfachste Weg.
Sumpfdotter
commented
2 months ago Änderungen an der Konfigurationsdatei erfordern einen Neustart von evcc und das hilft dann auch nur wenn man sich das Log vom Betriebssystem holt.
Daher ist Trace für alle wohl der einfachste Weg.
Ah, das war sehr hilfreich. Weil ich im yaml auf trace umgestellt hatte (und reboot ist klar), konnte ich die Messages jetzt zusammenbauen. Hier sind alle DEBUG-Messages plus "eebus" auf "trace":
evcc-20240807-164239-trace-evcc-black-classified.log
16:36:00 EVCC gestartet 16:37:00 Elli abgekoppelt (Über Elli Webfrontend) 16:37:30 Elli angekoppelt (Über Elli Webfrontend) 16:38:00 Ladestecker angesteckt 16:38:20 1. Laden gestartet mit RFID-Karte (lädt mit 16A --> erwartet sind 16A) 16:39:20 Ladestecker abgesteckt 16:40:00 Ladestecker angesteckt 16:40:20 2. Laden gestartet mit RFID-Karte (lädt nur mit 6A --> erwartet sind 16A) 16:41:20 auf Modus "min+PV" umgestellt 16:41:50 auf Modus "Schnell" umgestellt (lädt nun mit 16A --> erwartet sind 16A) 16:42:20 Ladestecker abgesteckt
Sumpfdotter
commented
2 months ago Hab die Zeiten oben korrigiert. Die waren um 1 Minute verrutscht - sorry.
Sumpfdotter
commented
2 months ago Ich glaube ich hab was. Sehe ich das richtig, dass manchmal "16" Ampere gesendet werden und manchmal "76652" Milliampere? Ich vermute es müssten "16000" (mA) gesendet werden statt 16 "mA"?
Aug 07 16:38:11 kammerpi evcc[26471]: [lp-1 ] DEBUG 2024/08/07 16:38:11 max charge current: 16A Aug 07 16:38:11 kammerpi evcc[26471]: [eebus ] TRACE 2024/08/07 16:38:11 Send: 055_SKI_ELLI_e73 {"data":[{"header":[{"protocolId":"ee1.0"}]},{"payload":{"datagram":[{"header":[{"specificationVersion":"1.3.0"},{"addressSource":[{"device":"d:_n:EVCC_HEMS-evcc-01.saw.snueq"},{"entity":[1]},{"feature":7}]},{"addressDestination":[{"device":"d:_i:47859_Elli-Wallbox-22ELLIF"},{"entity":[1,1]},{"feature":10}]},{"msgCounter":50},{"cmdClassifier":"write"},{"ackRequest":true}]},{"payload":[{"cmd":[[{"function":"loadControlLimitListData"},{"filter":[[{"cmdControl":[{"partial":[]}]}]]},{"loadControlLimitListData":[{"loadControlLimitData":[[{"limitId":0},{"isLimitActive":false},{"value":[{"number":16},{"scale":0}]}],[{"limitId":1},{"isLimitActive":false},{"value":[{"number":16},{"scale":0}]}],[{"limitId":2},{"isLimitActive":false},{"value":[{"number":16},{"scale":0}]}]]}]}]]}]}]}}]} Aug 07 16:38:11 kammerpi evcc[26471]: [eebus ] TRACE 2024/08/07 16:38:11 Recv: 055_SKI_ELLI_e73 {"data":[{"header":[{"protocolId":"ee1.0"}]},{"payload":{"datagram":[{"header":[{"specificationVersion":"1.3.0"},{"addressSource":[{"device":"d:_i:47859_Elli-Wallbox-22ELLIF"},{"entity":[1,1]},{"feature":10}]},{"addressDestination":[{"device":"d:_n:EVCC_HEMS-evcc-01.saw.snueq"},{"entity":[1]},{"feature":7}]},{"msgCounter":135425},{"cmdClassifier":"notify"}]},{"payload":[{"cmd":[[{"function":"loadControlLimitListData"},{"filter":[[{"cmdControl":[{"partial":[]}]}]]},{"loadControlLimitListData":[{"loadControlLimitData":[[{"limitId":0},{"isLimitActive":false},{"value":[{"number":16},{"scale":0}]}],[{"limitId":1},{"isLimitActive":false},{"value":[{"number":16},{"scale":0}]}],[{"limitId":2},{"isLimitActive":false},{"value":[{"number":16},{"scale":0}]}]]}]}]]}]}]}}]}
Aug 07 16:41:20 kammerpi evcc[26471]: [lp-1 ] DEBUG 2024/08/07 16:41:20 max charge current: 7.67A Aug 07 16:41:20 kammerpi evcc[26471]: [eebus ] TRACE 2024/08/07 16:41:20 Send: 055_SKI_ELLI_e73 {"data":[{"header":[{"protocolId":"ee1.0"}]},{"payload":{"datagram":[{"header":[{"specificationVersion":"1.3.0"},{"addressSource":[{"device":"d:_n:EVCC_HEMS-evcc-01.saw.snueq"},{"entity":[1]},{"feature":7}]},{"addressDestination":[{"device":"d:_i:47859_Elli-Wallbox-22ELLIF"},{"entity":[1,1]},{"feature":10}]},{"msgCounter":160},{"cmdClassifier":"write"},{"ackRequest":true}]},{"payload":[{"cmd":[[{"function":"loadControlLimitListData"},{"filter":[[{"cmdControl":[{"partial":[]}]}]]},{"loadControlLimitListData":[{"loadControlLimitData":[[{"limitId":0},{"isLimitActive":true},{"value":[{"number":76652},{"scale":-4}]}],[{"limitId":1},{"isLimitActive":true},{"value":[{"number":76652},{"scale":-4}]}],[{"limitId":2},{"isLimitActive":true},{"value":[{"number":76652},{"scale":-4}]}]]}]}]]}]}]}}]} Aug 07 16:41:20 kammerpi evcc[26471]: [eebus ] TRACE 2024/08/07 16:41:20 Recv: 055_SKI_ELLI_e73 {"data":[{"header":[{"protocolId":"ee1.0"}]},{"payload":{"datagram":[{"header":[{"specificationVersion":"1.3.0"},{"addressSource":[{"device":"d:_i:47859_Elli-Wallbox-22ELLIF"},{"entity":[1,1]},{"feature":10}]},{"addressDestination":[{"device":"d:_n:EVCC_HEMS-evcc-01.saw.snueq"},{"entity":[1]},{"feature":7}]},{"msgCounter":135652},{"cmdClassifier":"notify"}]},{"payload":[{"cmd":[[{"function":"loadControlLimitListData"},{"filter":[[{"cmdControl":[{"partial":[]}]}]]},{"loadControlLimitListData":[{"loadControlLimitData":[[{"limitId":0},{"isLimitActive":true},{"value":[{"number":76652},{"scale":-4}]}],[{"limitId":1},{"isLimitActive":true},{"value":[{"number":76652},{"scale":-4}]}],[{"limitId":2},{"isLimitActive":true},{"value":[{"number":76652},{"scale":-4}]}]]}]}]]}]}]}}]}
Nee, Milliampere haut auch nicht hin. Sorry, das ist ja ne fiese Fließkommadarstellung. scale=0 und scale=-4. Kommando zurück.
Sumpfdotter
commented
2 months ago 16:36:00 EVCC gestartet 16:37:00 Elli abgekoppelt (Über Elli Webfrontend) 16:37:30 Elli angekoppelt (Über Elli Webfrontend) 16:38:00 Ladestecker angesteckt --> Log File 16:38:10 max charge current: 16A 16:38:20 1. Laden gestartet mit RFID-Karte (lädt mit 16A --> erwartet sind 16A) 16:39:20 Ladestecker abgesteckt 16:40:00 Ladestecker angesteckt --> KEIN Log-File Eintrag für "max charge current: 16A" 16:40:20 2. Laden gestartet mit RFID-Karte (lädt nur mit 6A --> erwartet sind 16A) 16:41:20 auf Modus "min+PV" umgestellt --> Log File max charge current: 7.67A & 16:41:40 max charge current: 7.23A 16:41:50 auf Modus "Schnell" umgestellt (lädt nun mit 16A --> erwartet sind 16A) --> Log File max charge current: 16A 16:42:20 Ladestecker abgesteckt
Ich würde mal sagen, die Wallbox setzt das Limit irgendwann zwischen Abstecken und Anstecken selbsttätig auf 6 Ampere, ohne evcc zu informieren. (falls letzeres im Rahmen des Protokolls überhaupt möglich ist).
@DerAndereAndi Schrieb:
Als das Fahrzeug erkannt wird, und der Lademodus damit auf "now" gestellt wird, wird damit keine Änderung des Ladestrom auf 11kW durchgeführt.
@andig schrieb:
Vmtl. ist evcc der Meinung, dass noch 16A eingestellt sind da es zwischendurch auch nichts anderes gesetzt hat. Aufgrund eines Bugs mit dem Lastmanagement haben wir das in #15218 geändert. Vielleicht hilft das ja auch hier? Ich trigger mal ein nightly...
Das Logfile bestätigt das. Es wird nur einmal 16A gesetzt ("max charge current") und gesendet, und zwar nach den ersten Anstecken. Die Box scheint aber irgendwann nach dem Abstecken von alleine auf 6A zurückzugehen. evcc bekommt davon keine Kenntnis.
DerAndereAndi
commented
2 months ago Die Beschreibung ist korrekt. Und evcc hat auch keine Chance von den 6A etwas mitzubekommen, weil die Wallbox dies auch nicht mitteilt. Obwohl sie nach den aktuellen Limits nach dem Anstecken direkt gefragt wird.
@andig Bei EEBUS scheint es daher notwendig zu sein, dass evcc das Ladelimit nach jedem Ansteckvorgang auch durchführt.
Sumpfdotter
commented
2 months ago Die Beschreibung ist korrekt. Und evcc hat auch keine Chance von den 6A etwas mitzubekommen, weil die Wallbox dies auch nicht mitteilt. Obwohl sie nach den aktuellen Limits nach dem Anstecken direkt gefragt wird.
@andig Bei EEBUS scheint es daher notwendig zu sein, dass evcc das Ladelimit nach jedem Ansteckvorgang auch durchführt.
@DerAndereAndi: Beim Write antwortet die Box korrekt mit den Limits: {"loadControlLimitListData":[{"loadControlLimitData":[[{"limitId":0},{"isLimitActive":false},{"value":[{"number":16},{"scale":0}]}],[{"limitId":1},{"isLimitActive":false},{"value":[{"number":16},{"scale":0}]}],[{"limitId":2},{"isLimitActive":false},{"value":[{"number":16},{"scale":0}]}]]}]}]]}]}]}}
Beim den Reads antwortet sie jeweils auch, aber die Limit-Datensätze sind leer: {"loadControlLimitData":[[{"limitId":0}],[{"limitId":1}],[{"limitId":2}],[{"limitId":3}],[{"limitId":4}],[{"limitId":5}]]}]}]]}]}]}
Wir senden das Read immer kurz nach dem Anstecken (1-2 Sekunden später). Ich kenne EEBUS jetzt leider noch nicht. Was bedeutet denn leer? Bedeutet leer "keine Information" oder bedeutet leer Default = kein Limit. Ich frage aus folgenden Grund: Wir müssen annehmen, dass die Elli-Box das Limit von selbst reinhaut. Wir wissen aber nicht, wann sie das tut. Wäre es möglich, dass die Wallbox das erst ein paar Sekunden nach unserer Read-Abfrage tun, und wir deshalb das ganze verpassen.
Es gibt noch einen weiteren Ansatz: Laut Doku haut die Wallbox das Limit rein, wenn sie die Verbindung zum Energiemanagement-System verloren hat. Was auch immer die Elli-Kollegen damit meinen. In dem Falle geht die gelbe Lampe an. Und die gelbe Lampe geht beim Anstecken ja tatsächlich auch an. Senden wir beim Anstecken irgendetwas etwas an die Box, was die Box als eine Art Disconnect/Reconnect auffassen könnte?
Ich werde jetzt mal noch eine Hausaufgabe machen: Wenn die gelbe Lampe wirklich zeitnah und korrekt das Vorhandensein des Limits anzeigt (wie im Handbuch beschrieben), dann kann ich anhand der Lampe zeitlich eingrenzen welches Ereignis das ausgelöst hat.
Sumpfdotter
commented
2 months ago Die Messauflösung ist wegen des evcc-Logs nicht so gut wie ich gehofft hatte. Per Video hab ich auf eine 15tel Sekunde genau die gelbe Lampe gemessen (23:55 Uhr und 25,23 Sekunden gemessen in der Zeit des evcc-Hosts). Ungünstigerweise löst das evcc-Logfile nur auf Sekunden auf.
Die Elliwallbox hat entweder auf eigenen Trigger die gelbe Lampe reingehauen, oder aufgrund eines der EEBUS-Kommunikationsschritte in der fraglichen Sekunde:
Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Recv: d:_i:47859_Elli-Wallbox-22ELLIF:NodeManagement to NodeManagement notify 5505 NodeManagementUseCaseData Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Recv: d:_i:47859_Elli-Wallbox-22ELLIF:NodeManagement to NodeManagement notify 5506 NodeManagementDetailedDiscoveryData Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 ski 055_SKI_ELLI_e73 event cem-evcc-UseCaseSupportUpdate Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Send: d:_i:47859_Elli-Wallbox-22ELLIF call 3932 NodeManagementSubscriptionRequestCall Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 ski 055_SKI_ELLI_e73 event cem-opev-UseCaseSupportUpdate Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Send: d:_i:47859_Elli-Wallbox-22ELLIF call 3933 NodeManagementSubscriptionRequestCall Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 ski 055_SKI_ELLI_e73 event cem-evcem-UseCaseSupportUpdate Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 ski 055_SKI_ELLI_e73 event cem-oscev-UseCaseSupportUpdate Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Send: d:_i:47859_Elli-Wallbox-22ELLIF read 3935 DeviceClassificationManufacturerData Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Send: d:_i:47859_Elli-Wallbox-22ELLIF call 3934 NodeManagementSubscriptionRequestCall Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Send: d:_i:47859_Elli-Wallbox-22ELLIF call 3936 NodeManagementBindingRequestCall Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Send: d:_i:47859_Elli-Wallbox-22ELLIF call 3937 NodeManagementSubscriptionRequestCall Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Send: d:_i:47859_Elli-Wallbox-22ELLIF call 3938 NodeManagementSubscriptionRequestCall Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Send: d:_i:47859_Elli-Wallbox-22ELLIF read 3939 ElectricalConnectionDescriptionListData Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Send: d:_i:47859_Elli-Wallbox-22ELLIF read 3940 LoadControlLimitDescriptionListData Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Send: d:_i:47859_Elli-Wallbox-22ELLIF read 3941 MeasurementDescriptionListData Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Send: d:_i:47859_Elli-Wallbox-22ELLIF read 3942 DeviceConfigurationKeyValueDescriptionListData Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Send: d:_i:47859_Elli-Wallbox-22ELLIF read 3943 MeasurementConstraintsListData Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Send: d:_i:47859_Elli-Wallbox-22ELLIF read 3944 ElectricalConnectionParameterDescriptionListData Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Send: d:_i:47859_Elli-Wallbox-22ELLIF call 3945 NodeManagementSubscriptionRequestCall Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 operation is not supported on function loadControlLimitConstraintsListData Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Send: d:_i:47859_Elli-Wallbox-22ELLIF call 3946 NodeManagementSubscriptionRequestCall Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Send: d:_i:47859_Elli-Wallbox-22ELLIF read 3947 DeviceDiagnosisStateData Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Send: d:_i:47859_Elli-Wallbox-22ELLIF read 3948 MeasurementDescriptionListData Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Send: d:_i:47859_Elli-Wallbox-22ELLIF call 3949 NodeManagementSubscriptionRequestCall Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Send: d:_i:47859_Elli-Wallbox-22ELLIF read 3950 MeasurementConstraintsListData Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Send: d:_i:47859_Elli-Wallbox-22ELLIF read 3951 ElectricalConnectionParameterDescriptionListData Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Send: d:_i:47859_Elli-Wallbox-22ELLIF read 3952 ElectricalConnectionPermittedValueSetListData Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Send: d:_i:47859_Elli-Wallbox-22ELLIF call 3953 NodeManagementSubscriptionRequestCall Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Recv: d:_i:47859_Elli-Wallbox-22ELLIF:NodeManagement to NodeManagement result 5508 3932 ResultData 0 Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Send: d:_i:47859_Elli-Wallbox-22ELLIF read 3954 IdentificationListData Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 ski 055_SKI_ELLI_e73 event cem-evcc-EvConnected Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Recv: d:_i:47859_Elli-Wallbox-22ELLIF:NodeManagement to NodeManagement result 5510 3933 ResultData 0 Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Recv: d:_i:47859_Elli-Wallbox-22ELLIF:DeviceClassification to DeviceClassification reply 5513 3935 DeviceClassificationManufacturerData Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 ski 055_SKI_ELLI_e73 event cem-evcc-DataUpdateManufacturerData Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Recv: d:_i:47859_Elli-Wallbox-22ELLIF:NodeManagement to NodeManagement result 5519 3937 ResultData 0 Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Recv: d:_i:47859_Elli-Wallbox-22ELLIF:Generic to DeviceDiagnosis read 5521 DeviceDiagnosisHeartbeatData Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Send: d:_i:47859_Elli-Wallbox-22ELLIF result 3955 5521 ResultData 7 Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Recv: d:_i:47859_Elli-Wallbox-22ELLIF:Generic to NodeManagement call 5522 NodeManagementSubscriptionRequestCall Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Send: d:_i:47859_Elli-Wallbox-22ELLIF result 3956 5522 ResultData 1 Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Recv: d:_i:47859_Elli-Wallbox-22ELLIF:Generic to DeviceDiagnosis read 5523 DeviceDiagnosisHeartbeatData Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Send: d:_i:47859_Elli-Wallbox-22ELLIF reply 3957 5523 DeviceDiagnosisHeartbeatData Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Recv: d:_i:47859_Elli-Wallbox-22ELLIF:Generic to NodeManagement call 5524 NodeManagementSubscriptionRequestCall Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Send: d:_i:47859_Elli-Wallbox-22ELLIF result 3958 5524 ResultData 0 Aug 07 23:55:25 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 23:55:25 Recv: d:_i:47859_Elli-Wallbox-22ELLIF:NodeManagement to NodeManagement result 5525 3936 ResultData 0
@andig: Das Loging-Flag "Lmicroseconds" klingt vielversprechend ... wäre es einen Request wert, das zu setzen und die Auflösung zu erhöhen/per Schalter erhöhen zu können?
Sparlader
commented
2 months ago Hi zusammen, ein gutes 3/4 Jahr benutze ich evcc mit e-golf und elli connect. Und plötzlich ist der Wurm drin, genau die oben beschrieben Fehler sind bei mir auch, allerdings geht es zwischendurch dann doch mal wieder ohne für mich ersichtlichen Grund. Ich möchte euch nur bitte an dem Thema dranzubleiben, denn bisher war ich begeisterter Nutzer von EVCC und möchte es nartürlich weiterhin sein.
DerAndereAndi
commented
2 months ago Das Problem ist bei genau diesem Problem imho nicht die EEBUS Implementierung. Wie oben geschrieben sollte evcc bei jedem Anstecken das von sich aus erwartete Limit schreiben. Bei den meisten anderen Wallboxen (ohne EEBUS) ist ein Limit global in der Wallbox gesetzt, das ist mit EEBUS eben nicht so. Das gilt für den aktiven Ladevorgang. Und das Problem gibt es erst ab dem zweiten Ladevorgang. Würde mann evcc nach jedem abstecken neu starten, würde es immer funktionieren.
aaggog
commented
2 months ago I have the same issue with Elli Pro.
andig
commented
2 months ago @DerAndereAndi ich beziehe mich auf das Log aus https://github.com/evcc-io/evcc/issues/15174#issuecomment-2273862587.
Ich sehe Fehler, kann aber sicher unrelated sein:
Aug 07 16:40:01 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 16:40:01 Send: d:_i:47859_Elli-Wallbox-22ELLIF result 111 135540 ResultData 7
Aug 07 16:40:01 kammerpi evcc[26471]: [eebus ] TRACE 2024/08/07 16:40:01 Error 7
Aug 07 16:40:01 kammerpi evcc[26471]: [eebus ] TRACE 2024/08/07 16:40:01 Send: 055_SKI_ELLI_e73 {"data":[{"header":[{"protocolId":"ee1.0"}]},{"payload":{"datagram":[{"header":[{"specificationVersion":"1.3.0"},{"addressSource":[{"device":"d:_n:EVCC_HEMS-evcc-01.saw.snueq"},{"entity":[1]},{"feature":2}]},{"addressDestination":[{"device":"d:_i:47859_Elli-Wallbox-22ELLIF"},{"entity":[1,1]},{"feature":1001}]},{"msgCounter":111},{"msgCounterReference":135540},{"cmdClassifier":"result"}]},{"payload":[{"cmd":[[{"resultData":[{"errorNumber":7}]}]]}]}]}}]}
Aug 07 16:40:01 kammerpi evcc[26471]: [eebus ] TRACE 2024/08/07 16:40:01 Recv: 055_SKI_ELLI_e73 {"data":[{"header":[{"protocolId":"ee1.0"}]},{"payload":{"datagram":[{"header":[{"specificationVersion":"1.3.0"},{"addressSource":[{"device":"d:_i:47859_Elli-Wallbox-22ELLIF"},{"entity":[1,1]},{"feature":1001}]},{"addressDestination":[{"device":"d:_n:EVCC_HEMS-evcc-01.saw.snueq"},{"entity":[0]},{"feature":0}]},{"msgCounter":135541},{"cmdClassifier":"call"},{"ackRequest":true}]},{"payload":[{"cmd":[[{"nodeManagementSubscriptionRequestCall":[{"subscriptionRequest":[{"clientAddress":[{"device":"d:_i:47859_Elli-Wallbox-22ELLIF"},{"entity":[1,1]},{"feature":1001}]},{"serverAddress":[{"device":"d:_n:EVCC_HEMS-evcc-01.saw.snueq"},{"entity":[1]},{"feature":2}]},{"serverFeatureType":"DeviceDiagnosis"}]}]}]]}]}]}}]}
Aug 07 16:40:01 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 16:40:01 Recv: d:_i:47859_Elli-Wallbox-22ELLIF:Generic to NodeManagement call 135541 NodeManagementSubscriptionRequestCall
Aug 07 16:40:01 kammerpi evcc[26471]: [eebus ] DEBUG 2024/08/07 16:40:01 Send: d:_i:47859_Elli-Wallbox-22ELLIF result 112 135541 ResultData 1
Aug 07 16:40:01 kammerpi evcc[26471]: [eebus ] TRACE 2024/08/07 16:40:01 Error 1: found feature DeviceDiagnosis is not matching required role server@andig Bei EEBUS scheint es daher notwendig zu sein, dass evcc das Ladelimit nach jedem Ansteckvorgang auch durchführt.
Das können wir machen. Die spannende Frage wäre wo:
GetMaxCurrent von der Wallbox nachlesen und durch den Ladepunkt korrigieren lassen. Das geht aber bei EEbus nicht wenn ich es richtig verstehe?Was ich aber nicht verstehe: warum ging das "früher"? Oder ging das noch nie? Oder hat der alte CEM das mal als hard-kodiertes Verhalten gehabt?
Sumpfdotter
commented
2 months ago Was ich aber nicht verstehe: warum ging das "früher"? Oder ging das noch nie?
Doch es ging vorher. Ich denke mit 1.128.0 ging es noch. Soll ich downgraden und damit ein Log machen? Falls ja: Muss ich dann vorher die Datenbank wegsichern/löschen oder ist das noch kompatibel?
DerAndereAndi
commented
2 months ago @andig diese Fehler sind nicht relevant, die kommen bei jeder Wallbox die mit dem kommerziellen Stack arbeitet.
Es ging früher weil ein Write Befehl immer ausgeführt wurde, und dieser Befehl kommt nicht mehr vom Loadpoint. So ist es in allen meinen Logs die ich hier noch habe. Kann es sein dass es da evtl. eine Änderung mit dem Lastmanagement gab die das verursachen könnte?
andig
commented
2 months ago Es ging früher weil ein Write Befehl immer ausgeführt wurde, und dieser Befehl kommt nicht mehr vom Loadpoint. So ist es in allen meinen Logs die ich hier noch habe. Kann es sein dass es da evtl. eine Änderung mit dem Lastmanagement gab die das verursachen könnte?
Nicht bewusst, aber ausschließen kann ich es natürlich nicht. Eigentlich haben wir immer versucht, Kommunikation nur zu machen wenn sie notwendig war.
andig
commented
2 months ago Neues Nightly in 15min. Danke @DerAndereAndi für die Analyse. Ich hätte es nicht aus den Logs raus lesen können...
Sumpfdotter
commented
2 months ago
- Die Lampe ist immer gelb, wenn nicht der maximal mögliche Ladestrom erlaubt ist. Warum auch immer das der Fall sein mag.
Du hast die Box vermutlich schon genauer analysiert und kennst das daher. Ich beziehe mich auf das Handbuch. Das Leuchtmuster nach dem Anstecken ist "grün/aus/gelb", und laut Handbuch Seite 42 bedeutet das:
Verlust der Kommunikation mit HEMS Laden möglich Die Wallbox kann nicht mit dem HEMS-Netz kommunizieren. — Überprüfen Sie Ihre Netzwerkkonfiguration mit dem Configuration Manager. — Überprüfen Sie Ihre HEMS-Konfiguration mit dem Configuration Manager.
Ich hielt es auch für fast gesichert, dass die Wallbox nicht aufgrund eines EEBUS-Kommandos die gelbe Lampe wirft, aber ich wollte es trotzdem ausschließen. Ich habe mir ein Delay in die EEBUS-Kommunikation eingebaut und kann nun bestätigen: Die Wallbox geht beim Anstecken sofort von sich aus auf gelb, d.h. sie wirft vermutlich sofort das Ladelimit rein noch bevor sie die erste EEBUS-Reaktion auf das Anstecken empfängt. Also wie von Dir vermutet.
- Leer bedeutet: Es gibt keine Infos, selbst wenn es ein tatsächlich von der Wallbox gesetztes Limit gibt sind keine Informationen darüber vorhanden.
Okay. Heißt das also: Wir senden ein read an die Wallbox und sie antwortet mit leerem Datensatz "Ich weiß es zwar, aber sag es Dir nicht."? Aus Neugier: Ist das ein Bug in der Box oder noch spezifikationsgemäß?
- Wenn es aufgrund der Kommunikation mit evcc ein Limit reinhaut, dann ist es ein Bug. Denn es gibt keinen (ersichtlichen) Grund das zu tun.
Sehe ich auch so. Aber s.o.: Das tut sie nicht. Sie macht das bei meinen Tests immer.
Neues Nightly in 15min. Danke @DerAndereAndi für die Analyse. Ich hätte es nicht aus den Logs raus lesen können...
Jepp. Geht wieder. Danke!
DerAndereAndi
commented
2 months ago Wenn die Box ein Limit setzt, muss es dieses auch melden -> Bug. In der Spec steht so ein Satz nicht drin, aber dann kann ich auch wild irgendwas machen und es wird am Ende nichts bringen weil es nicht funktioniert. Wie eben hier.
Sparlader
commented
2 months ago bei mir geht es auch nur wenn EVCC neu gestartet wurde, kann also die Aussage von "der andere Andi" bestätigen. Es wäre schade wenn sich da keine Lösung finden würde das es wieder so geht wie in den "alten" Versionen, die bei mir immer gut funktionierten. Meine Frau muss Auto einstecken können und dann gehts....
DerAndereAndi
commented
2 months ago @Sparlader Mit welcher Version von evcc? Hast du den Nightly schon probiert, damit sollte das gelöst sein.
Sparlader
commented
2 months ago 0.129.0Am 11.08.2024 17:52 schrieb Andreas Linde @.***>: @Sparlader Mit welcher Version von evcc?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>
andig
commented
2 months ago https://github.com/evcc-io/evcc/releases/tag/0.130.0 contains a refactor of the EEbus charger that might or might not help here.
Describe the bug
I am using evcc with one wallbox (Elli Charger Pro), two vehicles in “mode: now” (fast mode) and without PV: My current use case is controlling the target SOC.
evcc should therefore start charging processes immediately with maximum charging current. This worked in older releases, and the procedure when it was still working was that the vehicle started with 6A (min current, default behavior of Elli Charger Pro when being coupled with an energy manager). A few seconds later, when the vehicle was recognized by evcc, evcc increased to 16A (max current).
Since a few weeks, starting with a certain 1.128 nightly build, this increase to 16A does not happen anymore. The charge remains at 6A. Workaround: If I change the mode once manually in the frontend (e.g. to “Off” or “min+PV”), and then back to “now” ("Schnell"), then evcc pulls the current up to 16A (max current) as desired.
But sometimes it still works. I have done various tests and I think I can reproduce it so that, charging works after a fresh coupling of wallbox with evcc (16A). However, in everyday operation (already on the second charge process), charging remains at 6A as described. A reboot of the wallbox and/or evcc usually does not help.
If of interest, I can try to identify the version that introduced this behavoir more exactly. Let me know.
Steps to reproduce
Precondition:
Steps to reproduce (happy path):
Steps to reproduce (bad path, can be repeated multiple times):
--> expected behavior: charging starts and raises to 16A (11kW)
Configuration details
Log details
What type of operating system are you running?
Linux
Version
evcc version 0.129.0