poohnet

Kurzer Zwischenstand: Das Problem scheint nichts mit den letzten Commits im Modul "meters_sma_speedwire" zu tun zu haben, denn mit bdb94657f bekomme ich noch Werte, mit upstream/master nicht mehr. Sehr mysteriös...

Nach der Übernahme in euren master und dem ersten Refactoring hat das Modul auf jeden Fall noch korrekt funktioniert, ich kann jetzt aber leider nicht mit Gewissheit sagen, ab wann es kaputt gegangen ist. Wenn ihr das Problem aber nicht nachvollziehen könnt, dann kann ich gerne mal ein „bisect“ probieren und den Commit identifizieren. Ja, definitiv. Es gibt noch einen zweiten Zähler, der weiterhin per Node-RED ausgelesen wird - und dann ist da noch der SMA Data Manager, der ebenfalls beide Zähler per Modbus-TCP abfragt (wobei der WARP-Zähler ggf. ja auch nicht direkt sondern über WARP ausgelesen werden könnte). Blöde Frage, liest das Template alle Werte einzeln oder blockweise? In Node-RED habe ich nämlich immer 20 Register auf einmal gelesen, in einen Puffer geschrieben und die Leistungswerte sekündlich, den Rest alle zehn Sekunden an den API-Zähler geschickt. Schon passiert 😂 Das steht noch auf meiner TODO-Liste.

Hallo zusammen, nach knapp fünf Monaten habe ich meinem "WARP-on-Steroids" nun nochmal einen aktuelle Firmwarestand verpasst und die gute Nachricht ist, dass beide Autos weiterhin richtig laden und auch meine Anpassungen noch funktionieren. 🙂 Ein paar kleinere Probleme sind mir allerdings aufgefallen: Mein SMA Sunny Home Manager 2.0 liefert nun keine Werte mehr, im Debug-Trace stehen unter "__begin_meters_swire__" aber zumindest die Abfragen drin; hier habe ich die Vermutung, dass dies mit den jüngsten Anpassungen im Modul "meters_sma_speedwire" zu tun hat, denn mit meinem ursprünglichen Modul auf einem zweiten ESP32-Brick erhalte ich alle Werte. Weiterhin gibt es ja jetzt ein Template für den SDM630 TCP und erfreut habe ich festgestellt, dass dies mit meinem (von einer auf einem Raspberry Pi laufenden Modbus-TCP/IP-Bridge angebundenen) SM630v2 funktioniert. Allerdings scheint das Abfrageintervall etwas zu groß zu sein, denn der Leistungsgraph wird gestrichelt gezeichnet. Bislang habe ich die Daten per Node-RED ausgelesen, gepuffert und sekündlich über die API bereitgestellt, da wurde der Graph durchgängig gezeichnet. Last but not least: Gibt es einen Grund dafür, dass man beim Solar Forecast mit einer unsignierten Firmware nur eure Demodaten bekommt? #if !BUILD_IS_SIGNED() #define SOLAR_FORECAST_USE_TEST_DATA #endif Wie immer besten Dank und viele Grüße Thomas warp2-XSS-Debug-Report-2025-04-12T14-07-43-914.txt

n‘ Abend @MatzeTF, funktioniert das auch für eine selbstgebaute Firmware und - falls ja - welche Version wird wiederhergestellt? Die alte, ebenfalls selbstgebaute? In der Vergangenheit musste ich mich nämlich das ein oder andere Mal mit dem Laptop zur Wallbox begeben… 😂

n‘ Abend @MatzeTF, falls es euch hilft, könnt ihr euch gerne nochmal an meinem Fork bedienen - den Strompreis per MQTT zu setzen und jede Ladung mit dem zu Beginn gültigen Preis zu speichern, habe ich vor einiger Zeit mal implementiert 🙃 Gruß Thomas

Ja, das tue ich. Auch wenn ich mich in den letzten Monaten hier im Forum etwas rar gemacht habe, halte ich meinen Fork eigentlich immer relativ aktuell - und meine WARP1 on Steroids funktioniert immer noch 1a 🙂 Also gerne einfach melden, falls Bedarf an einer angepassten Firmware besteht… Gruß Thomas

Schau dir mal das WiCAN-Modul an, das könntest du in deine Automatisierung einbauen. Ich habe mal etwas damit rumgespielt (und wollte eigentlich auch ein Modul für die WARP implementieren), der Nachteil ist aber, dass bei meinem ID.4 die Alarmanlage losgeht, wenn der Wagen ein paar Minuten abgeschlossen ist und auf den CAN-Bus zugegriffen wird. 🚨 SOC-Abfrage an sich (und noch vieles mehr) ist damit aber problemlos möglich… https://www.meatpi.com/products/wican Gruß Thomas

Ausschließen kann ich das sicherlich nicht, aber meine Anpassungen sind eigentlich seit dem Frühjahr unverändert und das Problem tritt erst seit ein paar Wochen auf, d. h. nachdem ich meine Forks rebased habe. Ich werde die Anpassung in der EVSE-Firmware testweise mal reverten und schauen, ob das Problem dann evtl. weg ist. Andere Frage: Ist es richtig, dass beim EVSE 2.0-Bricklet keine fahrzeugspezifische Kalibrierung mehr erforderlich ist? Falls ja, wo sind diesbezüglich die Unterschiede zum ursprünglichen EVSE-Bricklet? Gruß Thomas

Moin @MatzeTF, sorry, ich hatte irgendwie übersehen, dass du schon längst geantwortet hast 🙈 Anbei die beiden Ladeprotokolle von letztem Sonntag... Protokoll 1 1415 Uhr: Auto verbunden 1425 Uhr: Ladung über EVCC gestartet (und Umschaltung auf 3-phasiges Laden) 1432 Uhr: Ladung über das Auto beendet und Stecker gezogen --> Status wechselt von 3 auf 2 und bleibt im Webinterface "Verbunden" 1433 Uhr: Auto wieder verbunden --> Ladung wird direkt wieder gestartet, Status wechselt von 2 auf 3 Protokoll 2 1500 Uhr: Ladung über EVCC beendet --> Status wechselt von 3 auf 1 1500 Uhr: Stecker gezogen --> Status wechselt von 1 auf 0 Gruß Thomas warp2-XSS-EVSE-Ladeprotokoll-2024-10-13T14-33-24-005.txt warp2-XSS-EVSE-Ladeprotokoll-2024-10-13T15-01-02-184.txt

Moin, ich kann da leider nicht weiterhelfen bzw. testen, da ich einen RCD Typ B in der Unterverteilung habe und das Fehlerstromschutzmodul bei der letzten Umbauaktion ausgebaut habe. Anfangs hatte meine WARP1 aber das umgekehrte Problem, d. h. das Modul hat den RCD sporadisch ausgelöst, unabhängig davon, ob gerade geladen wurde oder nicht. Vielleicht ist das Modul bei dir auch defekt? Gruß Thomas

Moin zusammen, vor kurzem habe ich meinen Fork nochmal auf den aktuellen Stand gebracht und jetzt habe ich das Problem, dass meine WARP1 on Steroids auch nach dem Trennen des Autos im Zustand "Verbunden" bleibt, wenn ich die Ladung nicht zuerst in EVCC beende, d. h. Auto verbinden (0 --> 1) Ladung per EVCC starten (1 --> 2 --> 3) Auto entriegeln --> Ladung wird durch Auto pausiert Auto trennen --> Schütze öffnen (3 --> 1), der Status in WARP und EVCC bleibt aber "Verbunden" erst wenn ich die Ladung auch in EVCC beende, erfolgt der Übergang 1 --> 0 2024-10-05 12:03:30,435 | users | Charger state changed from 0 to 1 2024-10-05 12:04:50,460 | users | Charger state changed from 1 to 2 2024-10-05 12:04:50,719 | charge_tracker | Tracked start of charge. 2024-10-05 12:04:52,815 | users | Charger state changed from 2 to 3 2024-10-05 13:18:22,944 | evse_common | 8639 mA is allowed, but actual current is 7951 mA. Setting boost current to 120 mA. 2024-10-05 13:18:52,945 | evse_common | 10000 mA is allowed, but actual current is 9393 mA. Setting boost current to 240 mA. 2024-10-05 13:19:22,958 | evse_common | 10000 mA is allowed, but actual current is 9735 mA. Setting boost current to 360 mA. 2024-10-05 13:19:52,970 | evse_common | 10000 mA is allowed, but actual current is 9824 mA. Setting boost current to 480 mA. 2024-10-05 13:20:22,981 | evse_common | 16000 mA is allowed, but actual current is 15751 mA. Setting boost current to 600 mA. 2024-10-05 13:47:47,447 | users | Charger state changed from 3 to 1 2024-10-05 14:02:03,822 | users | Charger state changed from 1 to 0 2024-10-05 14:02:03,917 | charge_tracker | Tracked end of charge. Beende ich die Ladung zuerst in EVCC, dann gibt es beim beim Trennen direkt den erwarteten Übergang 1 --> 0. Habt ihr evtl. noch eine "jungfräuliche" WARP1 mit Standardfirmware und könnt das Szenario bei Gelegenheit mal durchspielen? Ich will nicht ausschließen, dass das Problem mit einer meiner zahlreichen Änderungen zusammenhängt, allerdings ist es in der Vergangenheit so bislang noch nicht aufgetreten. Bei Bedarf kann ich gerne auch einen Debug-Report erzeugen... Besten Dank und Gruß Thomas

Moin zusammen, in den letzten Monaten habe ich hier im Forum zwar weiterhin viel mitgelesen, mich ansonsten aber eher rar gemacht - einerseits mangels Zeit, andererseits aber auch, weil meine "WARP1 on Steroids" (der Begriff gefällt mir immer noch 😁) einfach funktioniert und unsere E-Autos absolut problemlos lädt! In der Tat ist es so, dass man beim Rebasen alle paar Wochen in (mindestens) einen Mergekonflikt rennt bzw. sich die Firmware nicht mehr bauen lässt, weil man z. B. vergessen hat, eine kleine Anpassung aus der warp2.ini nachzuziehen. Trotzdem möchte auch ich hier nochmals "DANKE" sagen, dass ihr auch das EVSE-Bricklet v1 weiter pflegt und verbessert! Ich bin gespannt, welche weiteren Features demnächst noch kommen werden... Gruß Thomas

Moin Alex, Das habe ich auch nicht selbst gemacht, d. h. ich habe die Platine von JLCPCB fertigen lassen. Da man immer mindestens drei bestellen muss, habe ich noch eine übrig, die ich dir bei Bedarf gerne zum Selbstkostenpreis zuschicken kann… Gruß Thomas

Moin @alestrix, ja, ich habe meine WARP1 tatsächlich bereits mehrfach umgebaut und diverse Erweiterungen vorgenommen: ESP32-Bricklet durch ESP32-Ethernet-Bricklet ersetzt CP-Trennung für die Phasenumschaltung über WARP Energy Manager nachgerüstet (den zugehörigen Thread hat @rtrbt ja schon verlinkt) interne Phasenumschaltung der WARP3 nachgebaut sowie weitere softwareseitige Anpassungen (Ladeprotokoll, dynamischer Boost, ...) Mit etwas technischem Sachverstand sind solche Umbauten mehr oder weniger problemlos möglich, wie zahlreiche andere Projekte hier im Forum ja auch zeigen. Allerdings sollte man schon wissen, was man tut, um nicht versehentlich die Ladeelektronik des Autos (oder schlimmer noch, sich selbst) zu grillen. Zumindest die letzte veröffentliche Version. Intern aktualisiere ich meinen Fork halbwegs regelmäßig mit dem Tinkerforge-Repo und seit Anfang der Woche läuft bei mir die 2.4.0 🙃 Sofern gewünscht kann ich gerne weitere Details nennen... Gruß Thomas

Die einfachste Frage traue ich mich fast nicht zu stellen: Du hast das MQTT-Topic in der EVCC-Config aber schon auf das der WARP3 geändert?! Tritt der Verbindungsabbruch zum Broker sofort auf oder erst später? Im Log liegt zwischen den beiden Meldungen mehr als eine halbe Stunde… Gruß Thomas

Moin @techniker, klar, kein Problem. Ich habe den Code in meinem GitHub-Repo mal in einen eigenen Branch geschoben: https://github.com/poohnet/esp32-firmware/tree/oled Gruß Thomas

Hallo zusammen, zwei Wochen weiter ist aus dem anfänglichen Enthusiasmus leider eine gewisse Ernüchterung geworden. 😢 Mittels pyPLC komme ich (auf dem Notebook) zwar "irgendwie" an den SOC, der gesamte Handshake dauert aber eine gefühlte Ewigkeit und ich habe bislang noch keine Idee, wie man das im ESP32 nachbauen könnte. Darüber hinaus bricht die Kommunikation irgendwann ab (was evtl. aber am Powerline-Adapter liegen kann), d. h. bis zu dem Punkt, an dem ein Ladevorgang gestartet werden könnte, bin ich noch nicht einmal gekommen. Vermutlich würde aber auch das nicht so ohne weiteres funktionieren, da das Auto ja von einer DC-Ladestation ausgeht. Folglich müsste man anschließend wieder auf die klassische Ladestrom-Vorgabe per PWM wechseln und den SOC im weiteren Verlauf rechnerisch ermitteln. Schlimmer ist aber, dass anscheinend nicht jedes Auto mit dem Versuch einer digitalen Kommunikation zurechtkommt. Unsere Zoe z. B. hat nur den 22 kW AC-Lader und wenn ich da einfach nur das 5% PWM-Signal anlege, gibt es merkwürdige Fehler im EVSE-Eventlog und das Auto beginnt irgendwann ohne Freigabe (!) mit einer Ladung, die kurze Zeit später wieder abbricht: 2024-05-29 11:56:26,202 | users | Charger state changed from 0 to 1 2024-05-29 11:59:52,951 | evse | all_data_1 -1 2024-05-29 11:59:53,674 | evse | all_data_1 -1 2024-05-29 11:59:54,778 | users | Charger state changed from 1 to 0 2024-05-29 12:00:06,805 | users | Charger state changed from 0 to 1 2024-05-29 12:01:50,555 | evse | all_data_1 -1 2024-05-29 12:01:51,597 | evse | all_data_1 -1 2024-05-29 12:01:52,496 | users | Charger state changed from 1 to 0 2024-05-29 12:02:04,524 | users | Charger state changed from 0 to 2 2024-05-29 12:02:04,587 | charge_tracker | Tracked start of charge. 2024-05-29 12:02:05,612 | users | Charger state changed from 2 to 3 2024-05-29 12:02:07,630 | users | Charger state changed from 3 to 1 Alles in allem waren die letzten Wochen aber sehr aufschlussreich, was das Grundlagenverständnis angeht - alleine wenn ich mir anschaue, welche Daten nur im ersten Teil der Kommunikation zwischen Auto und Ladestation hin- und herfließen, ist klar, warum der Start eines Ladevorgangs an einem DC-Schnelllader durchaus 40-50 Sekunden dauern kann. Aber nur um (bei manchen Autos) den SOC abfragen zu können, steht der notwendige Aufwand m. E. in keinem sinnvollen Verhältnis zum Nutzen. Anders sieht das vielleicht aus, wenn man ein kommerzielles Modul verwendet, das sowohl die Hardwareseite als auch den Softwarestack bedienen kann. Aber auch hier würde die Kosten-Nutzen-Rechnung wahrscheinlich nicht wirklich besser aussehen - zumindest nicht, wenn die tatsächliche Ladung nicht auch digital gesteuert werden kann. Ich selbst werde daher wohl erstmal den hier genannten WiCAN ausprobieren... Gruß Thomas

Moin zusammen, hier mal ein kurzer Zwischenstand meiner bisherigen Experimente. Aufgrund der (leider recht länglichen) Diskussion hier https://github.com/SmartEVSE/SmartEVSE-3/issues/25 habe ich mal einen alten Powerline-Adapter "geschlachtet" und entsprechend modifiziert: CP und PE habe ich aus der WARP herausgeführt und die EVSE-Firmware so angepasst, dass sie im Status B ein PWM-Signal mit 5% Duty Cycle erzeugt - und siehe da, pyPLC kann eine Verbindung mit meinem ID.4 aufbauen. Leider toggelt der EVSE dann alle paar Sekunden zwischen Status A und B hin und her, sodass die Verbindung wieder abbricht. Lässt man unabhängig vom Status grundsätzlich 5% PWM anliegen, dann wird die gesamte "DC-Precharge"-Kommunikation durchlaufen und in den Logs steht tatsächlich irgendwo der SOC 😀 Allerdings ist das ganze noch weit weg von praxistauglich, denn eine Ladung kann mit den o. g. Anpassungen nicht mehr gestartet werden und wenn ich den Renault Zoe (ohne CCS-Lader) verbinde, dann crashed der EVSE. Grundsätzlich ist es aber schon mal eine schöne Erkenntnis, dass eine rudimentäre digitale Kommunikation möglich ist... Gruß Thomas

Ich habe gerade zwei Tests gemacht und eine sehr interessante Erkenntnis gewonnen: Ausgehend von 6 A und ohne Boost die Vorgabe jeweils um 120 mA erhöht, dabei gab es keine Probleme. Bei einer Vorgabe von 6 A lag die Stromaufnahme bereits bei 6,1 A, bei 7 A Vorgabe aber nur bei 6,3 A. Somit hat der Boost dann peu à peu jeweils 2 µs draufgeschlagen, bis bei 10 µs (d. h. 600 mA) die Ladung wieder abgebrochen ist. Somit muss das irgendwie doch mit der Implementierung bzw. dem Timing des Duty Cycle zu tun haben... 😟 EDIT: Problem (erstmal) gelöst - anstelle den Duty Cycle in "evse_set_cp_duty_cycle()" zu manipulieren (und dies in "evse_get_cp_duty_cycle()" wieder rückgängig zu machen), wird zum Sollstrom nun einfach der Boost addiert: software/src/iec61851.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/software/src/iec61851.c b/software/src/iec61851.c index 309be35..f4dda42 100644 --- a/software/src/iec61851.c +++ b/software/src/iec61851.c @@ -125,6 +125,10 @@ uint16_t iec61851_get_duty_cycle_for_ma(uint32_t ma) { return 1000; } + if (evse.boost_mode_enabled) { + ma += evse.boost_current; + } + uint32_t duty_cycle; if(ma <= 51000) { duty_cycle = ma/60; // For 6A-51A: xA = %duty*0.6 Damit ist der ID.4 dann happy und im Low-Level-Zustand des EVSE sieht man den tatsächlich anliegenden Wert... evse-debug-protocol-id4-boost.txt evse-debug-protocol-id4-manuell.txt

Bislang habe ich dieses Problem nur beim ID.4 und auch nur bei geringen Ladeströmen gesehen. Ich werde aber später nochmal versuchen, das Problem zu reproduzieren und dabei das Ladeprotokoll erstellen. Am ID.3-Modus habe ich nichts geändert, "lediglich" die hartcodierten +4 µs auf den Duty Cycle durch einen per API ("set_boost_current()") setzbaren Wert im Bereich 0 bis 20 µs ersetzt: software/src/evse.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/software/src/evse.c b/software/src/evse.c index 9739c49..b81cb47 100644 --- a/software/src/evse.c +++ b/software/src/evse.c @@ -388,10 +388,16 @@ void evse_factory_reset(void) { NVIC_SystemReset(); } +static uint16_t evse_get_adc_boost_for_ma(uint16_t ma) +{ + return BETWEEN(0, ma/60, 20); +} + uint16_t evse_get_cp_duty_cycle(void) { + uint16_t adc_boost = evse_get_adc_boost_for_ma(evse.boost_current); uint16_t duty_cycle = (64000 - ccu4_pwm_get_duty_cycle(EVSE_CP_PWM_SLICE_NUMBER))/64; - if((duty_cycle >= 4) && (duty_cycle != 1000) && evse.boost_mode_enabled) { - return duty_cycle - 4; + if((duty_cycle >= adc_boost) && (duty_cycle != 1000) && evse.boost_mode_enabled) { + return duty_cycle - adc_boost; } return duty_cycle; @@ -402,7 +408,7 @@ void evse_set_cp_duty_cycle(const uint16_t duty_cycle) { // If boost mode is enabled we add 4us to the duty cycle. This means that we are still within the standard. uint16_t adc_boost = 0; if((duty_cycle != 0) && (duty_cycle != 1000) && evse.boost_mode_enabled) { - adc_boost = 4; + adc_boost = evse_get_adc_boost_for_ma(evse.boost_current); } const uint16_t current_cp_duty_cycle = evse_get_cp_duty_cycle(); @@ -447,6 +453,7 @@ void evse_init(void) { evse.config_jumper_current_software = 6000; // default software configuration is 6A evse.max_current_configured = 32000; // default user defined current ist 32A evse.boost_mode_enabled = false; + evse.boost_current = 0; evse_load_calibration(); evse_load_user_calibration();

Moin @rtrbt, anbei die Ladeprotokolle für den ID.4 sowie die Zoe (ohne Boost). Wenn ihr da bei Gelegenheit nochmal drüber schauen und eine neue Kalibrierung berechnen könntet... 🙃 Vielen Dank, viele Grüße und einen schönen Feiertag Thomas evse-debug-protocol-id4.txt evse-debug-protocol-zoe.txt

EVCC verwendet die Daten des Zählers, sowohl zur Anzeige der aktuellen Leistung als auch zur Berechnung der geladenen Energiemenge. Eine spezielle Konfiguration ist da eigentlich nicht erforderlich... Warum vermutest du, dass das nur geschätzt ist? Gruß Thomas

So, "Dynamic Boost" mit Überwachung des Stromflusses (I max von L1, L2 u. L3) ist implementiert und funktioniert nach ersten Tests (eigentlich) sehr gut: Und auch nach einer Phasenumschaltung wird der Strom peu à peu erhöht, bis 99% der Vorgabe erreicht sind: Einzig bei einer Vorgabe von 7 A und einem Boost von 600 mA bricht die Ladung reproduzierbar ab und das Schütz spielt Tik-Tok: 😟 2024-04-27 12:09:41,774 | users | Charger state changed from 1 to 2 2024-04-27 12:09:42,796 | users | Charger state changed from 2 to 3 2024-04-27 12:10:13,493 | evse_common | 7000 mA is allowed, but actual current is 6379 mA. Setting boost current to 120 mA. 2024-04-27 12:10:43,497 | evse_common | 7000 mA is allowed, but actual current is 6481 mA. Setting boost current to 240 mA. 2024-04-27 12:11:13,500 | evse_common | 7000 mA is allowed, but actual current is 6662 mA. Setting boost current to 360 mA. 2024-04-27 12:11:43,506 | evse_common | 7000 mA is allowed, but actual current is 6780 mA. Setting boost current to 480 mA. 2024-04-27 12:12:13,511 | evse_common | 7000 mA is allowed, but actual current is 6856 mA. Setting boost current to 600 mA. 2024-04-27 12:12:14,959 | users | Charger state changed from 3 to 2 2024-04-27 12:12:19,981 | users | Charger state changed from 2 to 3 2024-04-27 12:12:21,000 | users | Charger state changed from 3 to 2 2024-04-27 12:12:36,030 | users | Charger state changed from 2 to 3 2024-04-27 12:12:37,048 | users | Charger state changed from 3 to 2 2024-04-27 12:12:42,068 | users | Charger state changed from 2 to 3 2024-04-27 12:12:43,087 | users | Charger state changed from 3 to 2 2024-04-27 12:12:47,108 | users | Charger state changed from 2 to 3 @MatzeTF @rtrbt Kann es sein, dass die Kalibrierung hier evtl. noch etwas angepasst werden muss? Mit den Standardwerten lädt der ID.4 mit 6-7A nämlich überhaupt nicht. Ich werde später auf jeden Fall nochmal schauen, wie sich die Zoe verhält... EDIT: Mittlerweile habe ich auch die Zoe erfolgreich mit verschiedenen Stromstärken geladen (sowohl ein- als auch dreiphasig) und keinerlei Probleme festgestellt. Mit einem Boost von 960 mA komme ich nun bis auf 15,8 A Ladestrom… 😀

Du hast natürlich vollkommen recht, die Leistung zu überwachen ist Quatsch, schließlich gibt die Wallbox ja auch keine Leistung vor sondern Strom. Und eigentlich war das ja auch meine ursprüngliche Idee, den vom Zähler gemeldeten Stromfluss zu überwachen und den Boost dynamisch zu erhöhen, wenn weniger Strom fließt, als vorgegeben (natürlich nur innerhalb des sicheren Bereichs, d. h. max. +1A auf die Vorgabe).

Ja, genau. Ich würde der Einfachheit halber erstmal die Wirkleistung des Zählers prüfen - wohlwissend, dass die Scheinleistung höher sein kann (wobei ich das bei der Zoe eher bei niedriger Ladeleistung beobachtet habe).