rtrbt
-
Benutzer seit
-
Letzter Besuch
Posts erstellt von rtrbt
-
-
Firmware: WARP1 2.6.6, WARP2 2.6.6, WARP3 2.6.6
- Maximum der Fernzugriffs-Nutzer auf 5 erhöht
- "PV-Überschuss" und "dynamisches Lastmanagement"-Vorlagen zum API-Meter hinzugefügt
- (Nur WARP1) Unterstützung für SDM630MCT-V2 hinzugefügt
- Behoben, dass Lastmanagement die falschen Wallboxen deaktiviert hat um andere wartende Wallboxen zu aktivieren
- Übersetzungen verbessert
Download: WARP1 2.6.6 bzw. WARP2 2.6.6 bzw. WARP3 2.6.6
-
Laut Debug-Report ist unter Energiemanagement -> PV-Überschussladen die "Min + PV: Mindestladeleistung" auf 1,380 kW konfiguriert. Das entspricht 6 Ampere einphasig. Du schreibst auch
On 12/12/2024 at 12:05 PM, BerndR said:Ich habe die Sicherung für Phase 2 und 3 ausgeschaltet damit die Wallbox einphasig lädt.
Das passt also.
Was aber noch fehlt ist, dass du unter Wallbox -> Einstellungen die Zuleitung auf einphasig konfigurieren musst. Danach sollte es funktionieren wie erwartet.
-
On 12/11/2024 at 10:21 PM, rakeller said:
D.h. man kann die externe EVCC Steuerung nicht mehr ausschalten?
Korrekt. Hintergrund ist das 1. jemand der die API aufrufen kann, die z.B. EVCC verwendet um den Strom zu setzen (eine Zahl auf evse/external_current zu schreiben), der kann genauso gut auch evse/external_enabled auf true setzen und damit die externe Steuerung aktivieren und 2. ist die vermutlich mit Abstand häufigste Supportanfrage, warum eine externe Steuerung die Wallbox nicht steuern kann und die Antwort ist in 99,9% der Fälle, dass die externe Steuerung auf der Wallbox nicht aktiviert wurde.
Was ist dein Use-Case, dass du EVCC temporär(?) aussperren möchtest? Ich sehe im Debug-Report, dass du das PV-Überschussladen über die Wallbox machst und nicht über EVCC. D.h. du benutzt EVCC nur für das Auslesen des Batteriestands des Autos?
-
On 12/11/2024 at 12:27 PM, flrnsbch said:
Wo und wie kann ich die 2./3. Phase wegschalten? Ich habe nur eine große Sicherung im Sicherungskasten, die m.W.n. alle drei Phasen schaltet.
Wenn du keine Einzelsicherungen hast wird das kompliziert. Dann lassen wir das.
On 12/11/2024 at 12:27 PM, flrnsbch said:Mein anderes Auto (BMW iX1) lädt wunderbar und durchgängig mit 11kW ohne einen Abbruch. Kann man diesen Fehler damit schonmal ausschließen?
Ja, dann können wir das ausschließen. Ich würde das Problem damit erstmal auf den e-Up scheiben.
-
Hier einmal geplottet: https://vislog.warp-charger.com/9kRSJhsGfAShANGoAsKgu8
Aus Sicht der Wallbox ist alles okay. Kurz wie das Laden funktioniert:
Die Wallbox teilt dem Auto den erlaubten Ladestrom über ein PWM auf der CP-Leitung mit. Der erlaubte Strom sind in deinem Fall konstant 16 Ampere.
Das Auto legt auf der CP-Leitung einen Widerstand an: ~ 2,7 kΩ wenn es nicht laden möchte, ~ 880 Ω wenn es laden möchte. Den kannst du auch plotten, wenn du auf "Widerstand CP/PE (Ohm)" klickst. Rauscht in deinem Fall etwas, ist aber absolut okay: Der e-Up legt permanent ~ 820 Ω an, was wir als "das Auto will laden" interpretieren.
Wenn die Wallbox sieht, dass das Auto laden möchte und der erlaubte Ladestrom >= 6 Ampere ist, dann wird das Schütz geschaltet (kannst du auch zum Plot hinzufügen) und das Auto kann laden.
Wie viel Strom das Auto tatsächlich zieht, hängt absolut vom Auto ab. Die Wallbox kann nur mitteilen "bitte ziehe maximal X Ampere" (das ist der erlaubte Ladestrom).
Wie du im Plot sehen kannst, zieht der e-Up immer ~ 10 bis 20 Sekunden lang 16 A auf beiden Phasen und hört dann plötzlich auf. Das wird aber nicht von der Wallbox verursacht, der erlaubte Ladestrom und auch der Schützzustand bleiben immer gleich.
Folgende Dinge könntest du testen:
- Lädt der e-Up wie erwartet an einer anderen Wallbox? (Falls du z.B. bei deinen Nachbarn oder einer öffentlichen AC-Säule testen kannst)
- Tritt das Problem nur bei zweiphasigem Laden auf? (Wenn deine Wallbox separat abgesichert ist, kannst du die 2. und 3. Phase wegschalten während das Auto nicht angesteckt ist und dann einmal versuchen zu laden)
- Wir hatten schonmal ein ähnliches Verhalten gesehen, wenn sich eine der Anschlussklemmen in der Wallbox gelöst hat. Du könntest die Box einmal stromlos machen und die Klemmen nochmal anziehen
Es gibt im Moment ähnliche Probleme mit dem ID.4 und anderen VWs. Da liegt es wohl an einem Software-Update, das den Batteriecontroller nicht neustartet. Siehe z.B. hier https://github.com/evcc-io/evcc/discussions/17238 oder hier https://www.meinid.com/thread/5372-ac-laden-id4-schaltet-beim-laden-von-3-auf-2-phasen-alfen-eve-single-wallbox/?pageNo=2
-
Im Ladeprotokoll ist der interessante Teil leider nicht enthalten: Es werden maximal ~ 15 Minuten aufgesammelt, danach werden die ältesten Einträge verworfen (was das Webinterface im Moment nicht anzeigt, Issue hier: https://github.com/Tinkerforge/esp32-firmware/issues/386). Du hast das Protokoll aber nach Übergang nach Zustand B noch ~ 20 Minuten laufen lassen, deshalb wurde alles vor ungefähr 09:43 abgeschnitten.
Im Ist-Zustand beim Start des Protokolls (der wird nie weggeworfen) sieht aber alles aus wie erwartet. Kannst du nochmal ein Protokoll ziehen?
-
Firmware: WARP1 2.6.5, WARP2 2.6.5, WARP3 2.6.5
- Behoben, dass externe Steuerung nach einem Firmware-Update blockiert
- Behoben, dass gesteuerte Wallboxen nicht mehr per mDNS gefunden werden konnten
- (Nur WARP3) Unnötige Phasenumschaltungen bei gesteuerten Wallboxen behoben, wenn Fahrzeug voll ist
- (Nur WARP3) Anzeige der Phasenumschaltung auf gesteuerten Wallboxen repariert
- Behoben, dass Nulllinie auf Achsenlabels gezeichnet wurde
Download: WARP1 2.6.5 bzw. WARP2 2.6.5 bzw. WARP3 2.6.5
-
Firmware: WARP1 2.6.4, WARP2 2.6.4, WARP3 2.6.4
- Fehlende Hinweistexte im Webinterface behoben
Download: WARP1 2.6.4 bzw. WARP2 2.6.4 bzw. WARP3 2.6.4
-
Firmware: WARP1 2.6.3, WARP2 2.6.3, WARP3 2.6.3
- Behoben, dass der Lastmanager nie Strom verteilt, wenn nicht alle gesteuerten Wallboxen sofort erreichbar sind
Download: WARP1 2.6.3 bzw. WARP2 2.6.3 bzw. WARP3 2.6.3
-
Firmware: WARP1 2.6.2, WARP2 2.6.2, WARP3 2.6.2
- Passive Unterstützung von Batteriespeichern zum PV-Überschussladen hinzugefügt
- Unterstützung für NFC-Tag-Typ 5 hinzugefügt (Durch Update auf NFC-Bricklet-Firmware 2.1.0
- Einstellung für Systemsprache hinzugefügt. Wird beispielsweise für MQTT-Auto-Discovery verwendet
- Unterstützung für RCT Power Hybrid-Wechselrichter hinzugefügt
- Unterstützung für weitere Modbus-TCP-Geräte hinzugefügt: Hybrid-Wechselrichter: Solax, Hailei, Fox ESS H3; Stromzähler: Siemens PAC, Carlo Gavazzi; Batteriespeicher: Fronius GEN24 Plus
- Unterstützung für ein- und zweiphasiges dynamisches Lastmanagement hinzugefügt
- (Nur WARP2, WARP3) Maximum der (lastgemanagten) Wallboxen auf 64 erhöht
- Modbus-TCP-Server überarbeitet
- NFC-Tag-Vortäuschung zum WARP-Registerset hinzugefügt
- (Nur WARP3) Phasenumschaltung zum WARP-Registerset hinzugefügt
- (Nur WARP3) LED-Farbsteuerung zum WARP-Registerset hinzugefügt
- (Nur WARP2) Steuerung des konfigurierbaren Ein-/Ausgangs zum WARP-Registerset hinzugefügt
- Option zur (de-)aktivierung der externen Steuerung entfernt
- SunSpec: Unterstützung mehrerer Modelle des selben Typs pro Gerät hinzugefügt
- Erzeugung des Ladelog-PDFs beschleunigt
- Mehr Wallboxen das gleichzeitige Laden erlaubt, wenn dynamisches Lastmanagement deaktiviert ist
- Hinzugefügt, dass eine Wallbox erkennt und blockiert, wenn sie von mehreren Lastmanager gleichzeitig gesteuert wird
- Hinzugefügt, dass erst bei bestehender Netzwerkverbindung Verbindungen zu Servern aufgebaut werden
- charge_manager/available_current-API und entsprechende Automatisierungs-Aktion repariert
- Zeitmessung über RTCs, NTP und andere Zeitquellen verbessert
- (Nur WARP3) Uhrenfehler der Echtzeituhr verbessert
- Beschreibungstexte der Energiewerte des 4. Quadranten verbessert
- (Nur WARP2, WARP3) OCPP: Abgeschnittenes gemeldetes Modell der Wallbox repariert
- (Nur WARP2, WARP3) OCPP: Kompatibilität mit SteVe verbessert
- (Nur WARP2, WARP3) OCPP: Wiederaufbau der Verbindung verbessert
- Einphasigen Modus des Shelly Pro (3)EM repariert
- Erlaubt, dass zurücksetzbare Energiewerte für den Ladetracker verwendet werden, falls keine nicht-zurücksetzbaren verfügbar sind (z.B. Shelly Pro (3)EM)
- Lastmanagement: Startphase repariert
- Lastmanagement: Phasenwechsel bei langsam reagierenden Fahrzeugen repariert
- Lastmanagement: Sichergestellt, dass das Aufwecken eines Fahrzeugs keine Phasenumschaltung durchführt, falls globale Hysterese noch nicht abgelaufen ist
- MQTT: Sichergestellt, dass bei einer Verbindung zu einem nicht-standard-konformen MQTT-Broker nicht der Arbeitsspeicher gefüllt wird
- Häufige Modbus-Timeout-Meldungen im Ereignislog behoben
- Mehrere Fernzugriffs-Bugs behoben
- (Nur WARP2, WARP3) Minimalzeit der CP-Trennung auf 5 Sekunden erhöht (Durch Update auf Ladecontroller-Firmware 2.2.7)
- (Nur WARP2, WARP3) Erlaubte Reaktionszeit des Fahrzeugs nach einem Phasenwechsel auf 10 Sekunden erhöht (Durch Update auf Ladecontroller-Firmware 2.2.7)
- (Nur WARP2, WARP3) Sofortigen Phasenwechsel wenn Schütz noch nie geschaltet, oder seit dem CP getrennt war, hinzugefügt (Durch Update auf Ladecontroller-Firmware 2.2.7)
- (Nur WARP2, WARP3) Kurzzeitigen Fehler nach 30-sekündiger CP-Trennung behoben (Durch Update auf Ladecontroller-Firmware 2.2.7)
Download: WARP1 2.6.2 bzw. WARP2 2.6.2 bzw. WARP3 2.6.2
-
Es ist geplant, dass man die Topics filtern kann: https://github.com/Tinkerforge/esp32-firmware/issues/36 wie du siehst besteht der Plan aber schon länger.
-
Die EVCC-Anbindung gab es schon, als wir Modbus TCP noch nicht implementiert hatten, das konnten die EVCC-Entwickler also noch nicht benutzen. Eventuell hackt man irgendwann mal einen Pull-Request zusammen, um auf die HTTP-API oder Modbus TCP zu wechseln.
-
1
-
-
Unter der Prämisse, dass EVCC nicht direkt mit dem Auto redet (dann müsstest du https://docs.evcc.io/docs/devices/vehicles#volkswagen-we-connect-id eingerichtet haben), sollte EVCC keinen Einfluss gehabt haben. CP-Trennungen sind auch in beiden Fällen nicht passiert. Ich fürchte, dass ist wirklich die Software des Autos. Habe spontan https://www.goingelectric.de/forum/viewtopic.php?f=100&t=14508 und https://www.goingelectric.de/forum/viewtopic.php?f=101&t=8525 gefunden. Bei manchen Leuten hilft wohl ein Software-Update, bei anderen macht es das schlimmer. Außerdem habe ich noch https://www.goingelectric.de/forum/viewtopic.php?t=31028&start=10 gefunden. Hast du nur eine Abfahrtszeit oder auch einen Mindestladestand konfiguriert?
-
Ich glaube Matze meinte, dass im Event-Log-Teil viele Ladevorgänge sind. Protokolliert ist in der Tat nur ein Ladevorgang. In dem sieht man folgendes:
- Aus Sicht der Wallbox verbietet nur EVCC den Ladestart
- 15 Sekunden nach Start des Protokolls hast du das Auto angesteckt
- Nochmal 10 Sekunden später erlaubt EVCC den Ladevorgang
- Ungefähr 0,4 Sekunden später fordert das Auto Strom an und beginnt zu laden.
- Nach ~ 47 Sekunden fordert das Auto keinen Strom mehr anOn 11/13/2024 at 8:56 PM, Kaffeetasse said:Bin eigentlich geneigt zu sagen, dass sowohl evcc (hier kommt ja nur die Freigabe und Stromvorgabe für die Wallbox) als auch die Wallbox selbst (sind ja "nur" ein paar Schütze inkl. Weitergabe der erlaubten Stromhöhe) bei diesem Problem keine Rolle spielen und der Fehler im Lader/SW des Auto zu suchen ist.
Prinzipiell hast du damit Recht. EVCC und Wallbox kommunizieren nur an das Auto ob und wenn ja wie viel Strom verfügbar ist. Wenn Strom verfügbar ist, dann muss das Auto signalisieren, dass es laden möchte und wenn es das tut, wird das Schütz geschaltet. D.h. in letzter Instanz entscheidet das Auto, wann es lädt.
Eine Idee hätte ich noch: Die Wallbox hat eine CP-Trennung eingebaut. Damit können wir dem Auto vortäuschen, dass man das Kabel auf Wallboxseite abgezogen hat (Das Auto weiß nicht, ob die Wallbox eine Dose oder ein fest angebrachtes Kabel hat). Die CP-Trennung ist nützlich, weil damit manche Autos aufgeweckt werden können, falls deren Ladeelektronik im Stand-By ist. Wir versuchen das Auto aufzuwecken, wenn 30 Sekunden lang Strom verfügbar ist und das Auto keinen anfordert.
Es kann jetzt sein, dass dein Auto "vergisst", dass es zeitversetzt laden soll, wenn die CP-Trennung passiert. Du kannst deshalb unter Wallbox -> Einstellungen den Fahrzeug-Weckruf deaktivieren. Dann wird eine CP-Trennung nur noch durchgeführt, wenn die Wallbox eine Phasenumschaltung durchführt.
-
Noch ein Punkt: Abhängig von deinen Großverbrauchern kann es sinnvoll sein, die WARP phasenrotiert anzuschließen. Damit einphasiges Laden nicht auf der gleichen Phase läuft wie die anderen Verbraucher.
-
Das sollte mit dem dynamischen Lastmanagement funktionieren: https://docs.warp-charger.com/docs/warp_charger/chargemanagement#funktionsweise
Kurzer Überblick was dafür zu tun ist:
- Strom pro Phase am Hausanschluss messen (Wenn du schon die Leistung pro Phase misst, kannst du einfach durch 230V teilen, das ist gut genug, besser wäre natürlich die Phasenspannung zu benutzen)
-
Auf der WARP einen API-Zähler einrichten (Tutorial hier: https://docs.warp-charger.com/docs/mqtt_http/examples/#api-zähler-für-pv-überschuss), der mindestens die drei Phasenströme als Werte hat:
- Per MQTT die Werte von deinem Hausanschlusszähler auf die WARP-API schieben: https://docs.warp-charger.com/docs/mqtt_http/api_reference/meters/#meters_X_update_any
- Dynamisches Lastmanagement einrichten, dabei musst du etwas an den Werten "Maximaler Strom am Netzanschluss", "Strombedarf des größten Einzelverbrauchers" und "Zusätzliche Sicherheitsmarge" spielen. Wenn du darunter "Debug" aufklappst, siehst du drei weitere Werte, vorallem wichtig ist "Zielstrom". Das ist der Strom, den die WARP am Hausanschluss versucht zu erreichen. Wenn dein Großverbraucher z.B. gerade 10 A zieht und der Zielstrom sind 18 A, dann versucht die WARP langfristig 8 A für das Auto zu erreichen.
On 11/12/2024 at 1:16 PM, Johan said:1. Mein Strom Tarif niedriger is (von 22:00 bis 07:00, Nachttarif)
Das kannst du über Automatisierungs-Regeln bauen, z.B. so:
On 11/12/2024 at 1:16 PM, Johan said:Oder soll Ich mich einen einfachen 11kW lader kaufen bei dem Ich nur die Ladeleistung dynamisch kan ändern zwischen 1,4kW und 11kW. (Vorschlage willkommen!)
Damit du auf 1,4 kW herunterkommst brauchst du zwingend eine Wallbox, die eine Phasenumschaltung hat (z.B. eine WARP3)! Mit drei Phasen kommst du nur auf 4,2 kW.
On 11/12/2024 at 1:16 PM, Johan said:Meine Elektrowerte gehen jetzt richting iobroker uber MQTT (nicht alle)
Im Idealfall benutzt du Mosquitto o.Ä. als MQTT-Broker. Das MQTT-Plugin von ioBroker ist auf mehrere Weisen kaputt.
-
Hm, das ist hier:
schonmal aufgekommen, aber war untergegangen. Ich habe gerade die Konfiguration der Suche repariert, jetzt wird die Ladecontroller (EVSE)-Unterseite auch indiziert:
-
Spezifisch: Wenn der Ladevorgang einmal vom Auto unterbrochen wurde (z.b. weil es voll ist, oder bei manchen Autos auch wenn die Zentralverriegelung geöffnet wird), dann wird ein Ladevorgang erst gestartet, wenn min. 9 A zur Verfügung stehen. Min+PV meldet in der Standardeinstellung aber nur 6 A.
-
Benutzt du yay nur zum Herunterladen aus dem AUR? Eigentlich sollte das Paket auch gebaut werden und der PKGBUILD führt build_src.py aus: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=brickv (Zeile 21)
Wenn du das Paket von Hand bauen willst, kannst du makepkg (ohne Parameter oder mit -si wenn du brickv auch installieren möchtest) benutzen: https://wiki.archlinux.org/title/Makepkg#Usage
-
On 10/30/2024 at 4:43 PM, Eugenius said:
Die WARPs können doch untereinander Lastmanagement. Wäre es als möglich, dass eine Wallbox auf 0 und die andere 8.4kW gedrosselt wird? Von der Gesamtleistung her wäre es ja erlaubt...
Du kannst prinzipiell mit den Automatisierungsregeln den verfügbaren Strom des Lastmanagements setzen. Also kannst du z.b zwei Regeln wie folgt konfigurieren "Wenn Abschalteingang geöffnet, setze Lastmanagementstrom auf 32 A" und "Wenn Abschalteingang geschlossen, setze Lastmanagementstrom auf 12 A". (Disclaimer: Ob das mit der erlaubten Gesamtleistung so funktioniert weiß ich ad-hoc nicht, aber rein technisch ist das möglich)
-
Wenn du ein Originalgehäuse ohne Löcher möchtest, schreib eine Mail an info@tinkerforge.com und verweise auf den Thread hier. Wir haben noch ein paar ohne Bohrungen.
-
1
-
-
-
On 10/21/2024 at 8:10 PM, rakeller said:
Ich habe die Wallbox schon seit Stunden am Auto angeschlossen, Charging Mode ist "Min+PV" aber das Auto (BMW iX) laedt immer noch nicht, irgendetwas hat sich aufgehaengt.
Ist dein Auto einfach voll? Ich sehe im Log folgende Ausgaben:
2024-10-21 17:16:32,499 | users | Charger state changed from 0 to 1 2024-10-21 17:16:40,499 | users | Charger state changed from 1 to 3 2024-10-21 17:16:40,583 | charge_tracker | Tracked start of charge. 2024-10-21 17:17:29,634 | users | Charger state changed from 3 to 2 2024-10-21 17:17:40,678 | users | Charger state changed from 2 to 10->1 heißt das Auto wurde angesteckt.
1->3 heißt der Lastmanager hat Strom freigegeben und das Auto hat sofort Strom angefordert, also wurde das Schütz geschaltet. (2 wurde übersprungen, weil das Auto sofort reagiert hat)
3->2 heißt, dass das Auto keinen Strom mehr anfordert. Typischerweise, weil es voll ist.
2->1 ist dann, dass der Lastmanager den Strom weggenommen hat, weil das Auto keinen wollte.Trotzdem hätte es so sein sollen, dass der Lastmanager wieder Strom zuteilt, das ist bei dir nicht passiert, weil Min+PV nie auf über 9 Ampere gegangen ist. Mit der Firmware im Anhang sollte das Problem weg sein. Dann sollte, wenn das Auto abschaltet und zwischen 6 und 9 Ampere verfügbar sind oder Min+PV aktiv ist, trotzdem Strom zugeteilt werden.
Edit: Veraltete Firmware entfernt.
-
1
-
-
Versuch mal dein Glück mit dieser Firmware. Du triffst vermutlich eine ganze Kette von Bugs u.A. folgende:
1. Das MQTT-Plugin von ioBroker hält sich auf mehrere Arten nicht an die MQTT-Spezifikation, siehe auch:
(ich unterstelle dir mal, dass du ioBroker benutzt, sonst kann ich mir folgende Meldungen nicht erklären)
2024-10-21 13:47:18,257 | mqtt | Received message on unknown topic 'rtc/identity' (data_len=4) 2024-10-21 13:47:18,311 | mqtt | Received message on unknown topic 'charge_manager/available_phases' (data_len=12) 2024-10-21 13:47:18,619 | mqtt | Received message on unknown topic 'automation/timed_config_modified' (data_len=14) 2024-10-21 13:47:18,625 | mqtt | Received message on unknown topic 'automation/timed_config' (data_len=17)2. Wir haben falsche Annahmen bezüglich der MQTT-Implementierung des Microcontrollers in der Wallbox getroffen
3. Die MQTT-Implementierung verkraftet nicht den ioBroker-Traffic und unsere falsche Annahme in Kombination.
In Summe wird der RAM zugemüllt und nach kurzer Zeit können keine WLAN-Pakete mehr verschickt werden. Das dauert anscheinend ~ 80 Sekunden nachdem eine Verbindung aufgebaut wurde und der Microcontroller braucht bis zu 10 Minuten um sich davon zu erholen (also bis wieder eine WLAN-Verbindung aufgebaut werden kann). Wenn wieder eine Verbindung besteht, verbindet sich MQTT sofort neu und ioBroker bringt uns direkt wieder in den kaputten Zustand.
Ich habe jetzt Punkt 2 gefixt, weshalb der RAM nicht mehr zugemüllt wird, sodass dein direktes Problem erstmal gelöst sein sollte.
Prinzipiell solltest du entweder vom ioBroker-MQTT-Plugin auf einen echten MQTT-Broker (z.B. mosquitto) wechseln. (Das ist nicht nur meine Ansicht, dass das kein echter Broker ist, Zitat aus deren README:
QuoteThe ioBroker MQTT-Broker in server mode only simulates the behavior of real MQTT-Broker (like Mosquitto), but it is not the same. Real MQTT-Broker normally does not save the values of the topics and just forwards the message to other subscribed clients.
https://github.com/ioBroker/ioBroker.mqtt
Alternativ solltest du zumindest "Publish own states on connect" in den Einstellungen des MQTT-Plugins deaktivieren. Dann sollten die Logmeldungen von oben auch verschwinden.
Edit: Veraltete Firmware entfernt.
-
1
-
Warp3 upgraded to 2.6.5+6751bc2b: kann nicht mehr laden in "Fast"
in WARP Charger / Energy Manager
Geschrieben
Hast du dazu im EVCC-Log mehr Details? Ich wüsste ad-hoc nicht unter welchen Umständen die Wallbox einen 403 schickt.
Wenn du EVCC nicht erlauben möchtest, dass es den Ladestrom kontrolliert, würde ich auch erwarten, dass es die Phasenumschaltung nicht kontrolliert.