Elli: Fahrzeug beginnt immer wieder zu laden und bricht dann wieder ab #14839
Comments
|
Der ID ist aktuell über das UI konfiguriert mit gleichen Einstellungen. Keine Ahnung wie ich das exportieren könnte |
|
Bei meinem Q4 etron und der elli Pro passiert seit 128.2 das Gleiche. Laden beginnt und wird gleich wieder beendet da in PV kein Strom da ist. Auch beim erreichten Zielladen das gleiche. Nur bei Aus erfolgt keine Ladung |
|
Davon ist in deinem Logfile nichts zu sehen- nur "verbunden" ist zu erkennen: Es bräuchte ein Log in dem wir das irgendwie erkennen können. Bitte /cc @DerAndereAndi |
|
Schau mal auf die ganzen log statements. Die Wallbox meldet keinen Verbrauch, bzw. nur 30W. |
|
Ich kann die Probleme bestätigen - E.ON / Vestel Box mit Tesla Y. An der Heidelberg mit Modus Gateway funktioniert alles. |
|
In dem gezeigten Log ist gar keine Laderegelung von evcc zu sehen. Es wäre hilfreich ein TRACE level EEBUS log zu erhalten, welches vor dem Einstecken des Fahrzeugs beginnt. |
|
Sorry, mit dem Trace kann ich nicht dienen. Nach ein bisschen rumprobieren konnte ich aber anscheinend mein Problem lösen. Habe die Fahrzeug Config in der Oberfläche aktualisiert und gespeichert. Dann evcc (läuft im Docker auf meiner Synologie) neu gestartet und das Fahrzeug neu verbunden. Seit dem ist wieder Ruhe. Wenn sich das wieder ändert reiche ich den Trace nach. |
|
Ich lasse den Trace über Nacht mitlaufen und mache den ID jetzt nicht voll. Mal gucken ob das wieder auftritt |
|
In der UI auf das Menü-Icon drücken, dann "Log", dort "Debug" auswählen und auf "Trace" ändern und auf den Download Button drücken. Sollte hoffentlich genügen. Aber nur mal so generell: Wenn es jetzt tut, kann es kein Fehler in evcc sein. Die Elli hat sehr viele Software Bugs und schickt in einigen Szenarien einfach keine korrekten Daten. Und da sind sicher noch ein paar weitere Bugs drin, welche z.b. das gesehen Verhalten erzeugen können. |
|
hi, hier 3 kurze logs in Trace für eebus. Hoffe ihr erkennt was. Q4 Etron knackt kurz, in evcc wird nichts angezeigt, geladen wird auch nichts. Ladekontollleuchte am etron ist grün. evcc steht auf PV. |
Vor dem Release ist der Fehler aber überhaupt nicht aufgetreten... und nen Tesla hab ich im Threat auch gesehen :) |
|
Guten Morgen, hier mal ein log von der Version 0.127.3 (wo das Problem nicht auftritt) und der aktuellen Version : Hier tritt am Ende vom log das Problem auf. evcc-20240713-101136-trace_0.128.2.log |
|
@Ramada2020 zu deinen Logs. Da deine Logs nur EEBUS beinhalten, kann man keine Aussagen zu evcc machen. Also warum ob die Kommandos geschickt werden. 12.07.: In dem neueren Log vom 13.7.: Ich kann hier nichts ungewöhnlich oder falsches von EEBUS Seite erkennen. In allen Fällen soll das Auto nicht laden und genau wird dann geschickt. An keiner Stelle sehe ich eine Ladefreigabe welches dem Auto erlauben sollte zu laden. @winfotiker auch in deinem Log ist weder ein Ladestop noch eine Ladefreigabe zu sehen. Es werden auch nie Messwerte geschickt welche zeigen würden dass das EV lädt. An alle: Was genau soll denn nun der Fehler sein? Ich kann hier keinen erkennen. |
|
Wie immer: bitte vollständige Logs mit Kommentaren, zu welchen Zeitpunkten welches Fehlverhalten gesehen wird. Danke @DerAndereAndi dass Du Dich an dem Suchspiel beteiligst... |
|
Hey, hier das Log |
|
@winfotiker Hast du evtl. auch ein komplettes EVCC Log im Trace modus und nicht nur EEBUS ? Es gibt hier immer wieder Kommandos das Laden zu pausieren. Um zu verstehen ob das korrekt oder evtl. warum auch falsch ist, wäre ein komplettes Log notwendig, welche ALLE Details, nicht nur EEBUS, beinhaltet |
|
Ja, in dem Log wird das Laden gestoppt, genau dann wenn evcc es will: Ich sehe in diesem Log kein Fehlverhalten. |
This comment was marked as outdated.
This comment was marked as outdated.
|
Das nutzt alles nix ohne Logfile. Bitte keine Textaufgaben mit denen wir nichts anfangen können. Danke! |
Was soll ich dazu sagen. Tritt erst seit dem letzten Release auf. Und die Karre erschleicht sich durchaus Strom. Ist jetzt schon auf 78% |
|
@winfotiker in dem letzten Log meldet die Box keinen Stromverbrauch. Das bedeutet evcc hat keine Chance zu erkennen das ein Auto lädt. Das ist auch wieder etwas komplett anders als Thema hier im Ticket. Ich kann nicht beeinflussen was die Box macht, welche Daten sie schickt und welche nicht. Die macht das z.b. wenn das Auto eingesteckt ist aber die Netzwerk-Verbindung unterbrochen wurde. Entweder bei WLAN oder mit einem evcc update, etc. pp Von EEBUS Seite sehe ich hier nichts, wirklich nichts das zu korrigieren wäre. Die Box ist Schrott. Sorry. Und wenn "das" mit der vorherigen Version besser sein soll, ist das nicht nachvollziehbar auf die Code zurückzuführen. Sondern dass z.b. dass die genannten (oder ähnlichen) Umstände IN DER BOX dann nicht auftreten. Hier ist kein kausaler Zusammenhang zu erkennen. Es erscheint eher zufällig so zu sein. |
|
Ich habe das Problem bei mir auch mehrfach mit dem neuen EEEBUS Stack und der Elli Box beobachtet. Ich nutzte alten Stack seit es ihn gibt und habe den Fehler dort nicht einmal gehabt. Ich glaube statistisch gesehen, nes fast ausgeschlossen ist das der Fehler unabhängig von dem neuen Stack ist. Ich befürchte, dass eine Änderung im neuen Stack einen unbekannten Bug in der Box auslöst. |
|
Das kann natürlich sein. Den neuen Stack werden wir aber nicht zurück drehen da uns das von der Weiterentwicklung abkoppelt. Am Ende bleibt die Box ein Problemfall. Tatsächlich verfügt sie nichtmal über ein gültiges Zertifikat. Ohne Patching des Compilers wäre gar keine Kommunikation möglich… Bleibt die Frage, ob es noch lohnt, weitere Logs zu machen und weiter zu suchen? |
|
@StefanSchoof was ist "das Problem" ? Hier wurden im Verlauf verschiedenste "Probleme" genannt. Nur eines war nachvollziehbar: Das Auto lädt und die Wallbox meldet keine Messwerte. Alles andere war bisher nicht nachvollziehbar: evcc sagt das Laden soll beendet werden, das Laden wird beendet, evcc sagt das Laden soll fortgesetzt werden, das Laden wird fortgesetzt. Es gibt bisher kein Log das zeigt, ob bei diesem laden stoppen/starten Szenario wirklich ein Problem gibt. Und weiter ob das wirklich im EEBUS Stack ist. Der Unterschied von 0.127.3 und 0.128.2 sind 69 Commits. Ein paar EEBUS, aber nicht alle. Also nochmal: Bitte stellt ein komplettes Log mit alles Daten im TRACE Log zur Verfügung, welches VOR dem Anstecken des Fahrzeugs beginnt. Die UI hat unter Umständen nicht die ganze benötigte Historie, in der Dokumentation ist beschrieben wir man an das Log kommt. Bis dahin sehe ich hier von EEBUS Seite wirklich wirklich nichts zu tun. |
This comment was marked as outdated.
This comment was marked as outdated.
|
Bitte Keine Diskussion über Screenshots. Das ist Zeitverschwendung. |
Stimme dem zu. Wenn es zu dem Verhalten kommt, meldet die Box das sie nicht mit dem Energiemanagement System verbunden sei. Ein Neustart vom EVCC behebt das Problem dann. (hatte gerade ein wenig Zeit zum rumspielen) Sorry wenn euch das nervt. Aber das ist nun mal die Box welche ich habe. |
|
Guten Morgen,
|
|
Neues Nightly kann in 15min getestet werden.
Als evcc wünschen wir uns natürlich bestmöglichen Support für eine breite Anzahl von Geräten. Man muss aber leider auch sagen, dass es Geräte und Hersteller gibt, die das Leben unglaublich schwer machen. Ihren Anspruch, eine (implizit) nutzbare EEbus Implementierung zu liefern erfüllt die Box leider nicht. Am Ende wäre da der Hersteller in der Pflicht- hier schlägt dann völlig inexistente Support zu. Danke @DerAndereAndi dass Du soviel Zeit investiert hast und investierst... |
|
Hi, habe das Nightly 30 min getestet - Geisterladen tritt nicht mehr auf, Vielen Dank. Beobachte morgen weiter (heute ist die Sonne weg). |
|
Wie Andi schon schrieb- das kurze anladen ist per Design und nicht zu verhindern. Sonst klingt das doch jetzt ganz gut 👍🏻. |
|
I'm still seeing this issue with nightly build (commit dca3612, that should include "Improve EEBUS support for Elli Gen 1" fix). When EV is connected, but not charging (charger status B), evcc log shows that charge power is frequently fluctuating from normal charger self consumption (< 20W) to around 340W or even more. During those higher consumptions, my car's app also briefly shows ongoing charging and then changes back to not charging state. When charge power in the log is over 340W (more close to 1000W), evcc switches to charger status C and logs charger out-of-sync message. Example log messages of charge power fluctuating even though charging shouldn't be happening: When I downgraded to 0.127.3, charge power log messages stay at low figures (< 20W) and no ghost charging or charger out-of-sync is happening. Log file: |
|
Slowly I am out of ideas. The last thing I can do is send the heartbeats quicker than required, maybe they check if the heartbeat arrives within 4s, which would be a wrong interpretation of the specification, and thus put the wallbox in fallback mode and allow minimal 4,2kW charging. All values in measurements are always <6A as far as I can see. The old stack did send the heartbeat every second, which was way over the top, just caused way more unnecessary traffic but according to the spec does not have to be that way. I'll try. |
Update EEBUS spine-go library to send heartbeat messages 1s earlier than needed. Maybe the Elli sofware interprets the heartbeat not according to the spec and wrongly falls back into failsafe mode. Maybe this also helps with Elli Gen 1 issues reported in evcc-io#14839
Update EEBUS spine-go library to send heartbeat messages 1s earlier than needed. Maybe the Elli sofware interprets the heartbeat not according to the spec and wrongly falls back into failsafe mode. Maybe this also helps with Elli Gen 1 issues reported in #14839
|
I have been testing new nightly build (commit 9e75d8c7) for over 3 hours and seems that it fixed the issue! Charge power is back to being very stable and low (9W / 18W) and so far no unexpected charging has happened (two expected charger out of syncs, because of evcc nightly build restart and EV cable reconnect). Here's a new log file just in case you would like to see it: Thank you so much for your hard work regarding EEBUS support for Elli Gen 1 chargers @DerAndereAndi! |
|
Hab jetzt tatsächlich Kontakt zum Support von Elli. Kann mir jemand eine treffende Fehlerbeschreibung für das unklare Verhalten der Wallbox geben? Wie konkret verhält die sich nicht entsprechend ihrer Spezifikationen? |
Das kenne Elli seit 3 Jahren ;) |
|
Werde die trotzdem damit nerven 😌 Auch mit dem neuen tollen Feature. Ich hab zwei von den Boxen. Ganz neu ist: wenn ich ein Fahrzeug abstöpsle, dann fängt das andere Fahrzeuge an zu laden. Evcc zeigt mir dann zwar an dass da eine Ladung mit minimum Strom stattfindet (4,1kw in meinem Fall) aber zeichnet das leider nicht als Ladevorgang auf. Dafür scheint das alte sporadische Geisterladen definitiv erledigt zu sein. |
|
Bin jetzt wieder auf die 0.127.3 zurück. Immer wenn ich ein Fahrzeug von einer Box trenne, fängt das andere Fahrzeug an der zweiten Box an zu laden. Ohne Rücksicht auf die aktuelle Situation und zieht mir dann den Hausakkku leer. Lässt ich dann auch nicht mehr über EVCC steuern. |
|
@winfotiker das wird nichts nutzen. Helfen kann ein Logfile mit aktuellem Stand- soweit ich das sehe gibts das nicht? |
|
ok. Rolle Rückwärts und zweimal um die Autos getanzt |
|
Hier mal eine erste Analyse des Logs: @winfotiker Es wäre sehr hilfreich zu erfahren, ob der Passat an LP-1 am Anfang schon geladen hat, oder wirklich erst ab 19:42:53 ? Das einzige was sein könnte (auch in anderen Bug Reports zu sehen ist): evcc hat eine Änderung im Code wann/wie die Ladelimits geschickt werden, und das hier auch einen Effekt hat. Auf EEBUS Seite ist das Verhalten identisch zu alten Versionen. Die Analyse hat jetzt 1h gedauert, und das ist nicht das erste Mal wegen der miserablen EEBUS Implementierung in dieser Wallbox. Dass die Wallbox keine Messwerte schickt, ist nicht von evcc oder EEBUS beeinflussbar! Die einzige Lösung hierfür ist, wie in der Dokumentation geschrieben, externe Messgeräte für jede Wallbox zu verwenden und in evcc zu konfigurieren. Zu Elli und EEBUS: Der Stack läuft fehlerfrei mit allen anderen Wallboxen, Elli hat in dieser Wallbox eine sehr fehlerhafte EEBUS Implementierung. Es gibt wenige die mehr über EEBUS wissen als ich. Es auch bringt gar nichts Elli zu schreiben was sich in meinem Stack geändert hat, das sind tausende Zeilen Code. Diese Wallbox wird auch kein Software Update mehr bekommen. Vor allem vermute ich hier sehr stark, dass die Verhaltensänderung gar nicht an EEBUS liegt! Bitte bitte bitte, hört auf selbst Ursachen zu definieren, ihr habt doch keine Ahnung was im Code alles geändert wurde. Das macht die Analyse nur noch viel schwieriger und Zeitaufwändiger. |
|
Hi,
ich habe für das Log beide Fahrzeuge Abends angeschlossen als nicht mehr
genug Sonne aufs Dach kam. Beide Fahrzeuge bzw LPs stehen auf PV. Beide
Fahrzeuge haben zunächst nicht geladen. Bis hier ist alles korrekt.
Der Passat (lp1) fing erst an zu laden als ich den ID von der Wallbox (lp2)
getrennt habe.
Das ist ein Fehlverhalten. Es gab nicht genug PV Strom um das Laden zu
starten.
Ich habe dann im Anschluss versucht über evcc das Laden manuell zu stoppen.
Das hat nicht funktioniert. Fehlverhalten.
Auch konnte ich lp1 nicht auf Schnellladen umstellen um wenigstens nicht
den Hausakku zu belasten. Die Box reagiert ab dem Moment gar nicht mehr
auf Änderungen in evcc.
Zum Thema Fehler melden: Hier gilt für mich immer der gleiche Grundsatz.
Wenn die Implementierung vom eebus in der Elli Box fehlerhaft ist, will ich
denen das melden. Dazu wäre eine konkrete Beschreibung, in wie weit die
Implementierung fehlerhaft ist bzw woran ich das festmachen kann sehr
hilfreich. Im schlechtesten Fall könnte das sogar als Grund für eine
Wandlung hinreichend sein. Im besten Fall provoziert es doch nich ein
Update.
Danke und Gruß
Andreas Linde ***@***.***> schrieb am Mo., 5. Aug. 2024,
10:09:
… Hier mal eine erste Analyse des Logs:
19:40:33: LP-1 und LP-2 mit "charge power: 0W", kein EV angeschlossen
19:40:33: LP-1 und LP-2 mit "charger status: A"
19:41:42: LP-1: EV über EEBUS als angeschlossen gemeldet
Intervall LP-1 ist an der Reihe:
19:41:44: LP-1: "charge power: not available", es wurden bisher keine Messwerte von der Wallbox gemeldet
19:41:44: LP-1: "car connected", evcc weiss nun dass ein EV angeschlossen ist
19:41:44: LP-1: "charger status: B"
19:41 <https://www.google.com/maps/search/B%22%0D%0A19:41?entry=gmail&source=g>:47: LP-1: evcc schickt 0A Ladelimit, wird bestätigt
Intervall LP-2 ist an der Reihe:
19:41:54: LP-1: "charge power: not available", die Wallbox meldet weiterhin keine Messwerte
19:41:54: LP-2: "charge power: 4140W"
19:41:54: LP-2: "charger status: B"
Intervall LP-1 ist an der Reihe:
19:42:03: LP-1: "charge power: not available", die Wallbox meldet weiterhin keine Messwerte
19:42:03: LP-2: "charge power: 0W"
19:42:03: LP-1: "charger status: B"
19:42:07 <https://www.google.com/maps/search/B%22%0D%0A19:42:07?entry=gmail&source=g>: LP-2: EV über EEBUS als angeschlossen gemeldet
Intervall LP-2 ist an der Reihe:
19:42:13: LP-2: Messwerte werden gemeldet
19:42:14: LP-1: "charge power: not available", die Wallbox meldet weiterhin keine Messwerte
19:42:14: LP-2: "charge power: 4140W"
19:42:14: LP-2: "charger status: C"
19:42:14: LP-2:"car connected", evcc weiss nun dass ein EV angeschlossen ist
19:42:18: LP-2: ID.5 als angesteckt erkannt
19:42:18: LP-2: evcc schickt 0A Ladelimit, wird bestätigt
Intervall LP-1 ist an der Reihe:
19:42:24: LP-1: "charge power: not available"
19:42:24: LP-2: "charge power: 0W"
19:42:24: LP-1: "charger status: B"
Intervall LP-2 ist an der Reihe:
19:42:34: LP-1: "charge power: not available"
19:42:34: LP-2: "charge power: 0W"
19:42:34: LP-2: "charger status: B"
19:42:39 <https://www.google.com/maps/search/B%22%0D%0A19:42:39?entry=gmail&source=g>: LP-2: EV über EEBUS als nicht mehr angeschlossen gemeldet
Intervall LP-1 ist an der Reihe:
19:42:44: LP-1: "charge power: not available"
19:42:44: LP-2: "charge power: 0W"
Intervall LP-2 ist an der Reihe:
19:42:53: LP-2: EV über EEBUS als angeschlossen gemeldet
19:42:53: LP-1: "charge power: 1382W", zum ersten Mal meldet LP-1 Messwerte
19:42:54: LP-2: "charge power: not available"
19:42:54: LP-2: "charger status: B"
Intervall LP-1 ist an der Reihe:
19:43:03: LP-1: "charge power: 1405W"
19:43:03: LP-2: "charge power: not available"
19:43:03: LP-1: "charger status: C"
19:43:06: LP-1: Passat wird als angesteckt erkannt
19:43:06: LP-1: "set charge mode: pv"
19:43:06: LP-1: evcc schickt 6A Ladelimit, wird bestätigt
Intervall LP-2 ist an der Reihe:
19:43:13: LP-1: "charge power: 1405W"
19:43:13: LP-2: "charge power: 4140W", zum ersten Mal meldet LP-2 Messwerte (seit dem erneuten Anstecken)
19:43:13: LP-2: "charge status: C"
Intervall LP-1 ist an der Reihe:
19:43:23: LP-1: "charge power: 1405W"
19:43:23: LP-2: "charge power: 4140W"
19:43:23: LP-1: "charger status: C"
Intervall LP-2 ist an der Reihe:
19:43:33: LP-1: "charge power: 1405W"
19:43:33: LP-2: "charge power: 4140W"
19:43:33: LP-2: evcc schickt 6A Ladelimit, wird bestätigt
19:43:33: LP-2: "charge status: C"
.....
@winfotiker <https://github.com/winfotiker> Es wäre sehr hilfreich zu
erfahren, ob der Passat an LP-1 am Anfang schon geladen hat, oder wirklich
erst ab 19:42:53 ?
Und was ist ist deiner Meinung nach an dem Verhalten wann genau falsch?
"Rolle Rückwärts und zweimal um die Autos getanzt" ist leider keine
nachvollziehbare Beschreibung eines Fehlverhaltens.
Das einzige was sein könnte (auch in anderen Bug Reports zu sehen ist):
evcc hat eine Änderung im Code wann/wie die Ladelimits geschickt werden,
und das hier auch einen Effekt hat. Auf EEBUS Seite ist das Verhalten
identisch zu alten Versionen.
Die Analyse hat jetzt 1h gedauert, und das ist nicht das erste Mal wegen
der miserablen EEBUS Implementierung in dieser Wallbox. Dass die Wallbox
keine Messwerte schickt, ist nicht von evcc oder EEBUS beeinflussbar! Die
einzige Lösung hierfür ist, wie in der Dokumentation geschrieben, externe
Messgeräte für jede Wallbox zu verwenden und in evcc zu konfigurieren.
Zu Elli und EEBUS: Der Stack läuft fehlerfrei mit allen anderen Wallboxen,
Elli hat in dieser Wallbox eine sehr fehlerhafte EEBUS Implementierung. Es
gibt wenige die mehr über EEBUS wissen als ich. Es auch bringt gar nichts
Elli zu schreiben was sich in meinem Stack geändert hat, das sind tausende
Zeilen Code. Diese Wallbox wird auch kein Software Update mehr bekommen.
Vor allem vermute ich hier sehr stark, dass die Verhaltensänderung gar
nicht an EEBUS liegt!
Bitte bitte bitte, hört auf selbst Ursachen zu definieren, ihr habt doch
keine Ahnung was im Code alles geändert wurde. Das macht die Analyse nur
noch viel schwieriger und Zeitaufwändiger.
—
Reply to this email directly, view it on GitHub
<#14839 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A434VZBCMWW5CEHX5ID45BLZP4XMBAVCNFSM6AAAAABKXOX6Q6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRYGQZTSMZUHE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Elli hat seit 2 Jahren eine genaue Fehlerliste von mir und war mit mir im Austausch. Sehe es mir nach, ich werde mich hier nicht immer wieder mit den Fehlerbeschreibungen wiederholen. Ich verbrenne genug Zeit ohne dass ich diese Box verwende. Verstehe ich das richtig, dass um 19:42:39 das Auto nicht abgesteckt wurde? |
|
Nee. Um 19:42 hab ich den ID abgesteckt.
Der Fehler ist, dass der Passat auf LP1 dann spontan und ohne PV Strom
einfach anfängt zu laden. Das darf nicht sein.
Andreas Linde ***@***.***> schrieb am Mo., 5. Aug. 2024,
21:25:
… Elli hat seit 2 Jahren eine genaue Fehlerliste von mir und war mit mir im
Austausch. Sehe es mir nach, ich werde mich hier nicht immer wieder mit den
Fehlerbeschreibungen wiederholen. Ich verbrenne genug Zeit ohne dass ich
diese Box verwende.
Verstehe ich das richtig, dass um 19:42:39 das Auto nicht abgesteckt wurde?
—
Reply to this email directly, view it on GitHub
<#14839 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A434VZFVNJJCNMYU44CKI43ZP7GRXAVCNFSM6AAAAABKXOX6Q6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRZG42TOMBSGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Die CT-Spulen der Wallboxen sind nicht angeschlossen, korrekt? Update: Ich hab eine Idee woran es liegen könnte, weiss aber noch nicht wieso und wie das passieren kann. |
|
Korrekt
Andreas Linde ***@***.***> schrieb am Mo., 5. Aug. 2024,
21:55:
… Die CT-Spulen der Wallboxen sind nicht angeschlossen, korrekt?
—
Reply to this email directly, view it on GitHub
<#14839 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A434VZGMYCYO77QZY2IJWVLZP7KEJAVCNFSM6AAAAABKXOX6Q6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRZHAYDKNRRG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Danke für die Geduld und Logdaten! Das hat sehr geholfen. Ich konnte das Problem reproduzieren und lösen. Sobald die Änderungen in evcc aufgenommen sind, werden sie im darauf folgenden nightly Build bereitstehen. |
|
Ist drin- danke @DerAndereAndi |
|
Bei mir war auch das Problem elli wallbox und e-golf brachte mich zum verzweifeln: |
|
@Sparlader das konkrete Problem hier trat nur auf wenn 2 EEBUS Wallboxen angebunden waren, und an beiden ein EV hängt, und dann eines davon abgesteckt wurde. |
Describe the bug
Das Fahrzeug (ID5) ist an der Elli Pro Wallbox angestöpselt. Die Sonne scheint nicht (hinreichend). Das Fahrzeug steht auf PV. immer wieder, innerhalb von wenigen Minuten, wird trotzdem ein Ladevorgang getartet und dann mangels Energie gleich wieder beendet.
installiert ist die Latest Verion. Problem tritt erst seit dem letzten Updaten von EVCC auf.
Steps to reproduce
2.Sonne scheint nicht
...
Configuration details
Log details
What type of operating system are you running?
Linux
Version
0.128.2
The text was updated successfully, but these errors were encountered: