mike_79 Posted October 20, 2024 at 12:22 PM Posted October 20, 2024 at 12:22 PM (edited) Hallo ! Ich besitze 2 WARP2 Wallboxen seit (10/21 - Lieferdatum). Vorab: Mit evcc v0.130.13 und WARP2 FW 2.1.5 (30. Okt. 2023) funktioniert alles wunderbar. Überschussladen und WLAN Verbindung klappt. Wenn ich auf die WAPR2 FW Version >=2.2.0 Update verliert die WARP2-Wallbox immer die WLAN Verbindung. Reproduzieren: Jedes Mal wenn der Betriebsstatus von "AUS" auf "PV" oder "PV" auf "Schnell" wechsle, bricht die WLAN Verbindung ab. Es dauert ein paar Minuten (10..20 Min.) bis diese wiederkommt. Wir der Betriebsstatus gewechselt ist die Verbindung wieder verloren. Das Verhalten ist bei allen Versionen ab >=2.2.0 gleich. Versuche dies seit 01/24 immer wieder mit einer aktuellen FW Version. Auch die aktuelle FW v2.6.1 läuft nicht zuverlässig. Ich habe sogar die Konfiguration gelöscht und alles neu eingerichtet. Es half nichts. Anbei der Debug-Report nach Neustart der Wallbox: warp2-YDw-Debug-Report-2024-10-20T12-22-29-857_Nach_Neustart.txt Direkt Nach dem Verbindungsabbruch konnte ich nur ein Screenshot aufnehmen: Und nach der WLAN Verbindungswiederkehr: warp2-YDw-Debug-Report-2024-10-20T12-50-12-238_Nach_Verbindungswiederkehr.txt Benötige Support Danke Edited October 20, 2024 at 12:23 PM by mike_79 Quote
MatzeTF Posted October 20, 2024 at 07:48 PM Posted October 20, 2024 at 07:48 PM Hast du zufällig mehrere Accesspoints oder benutzt du WLAN-Repeater? In deinen Einstellungen hast du die Wallbox auf einen bestimmten Accesspoint gehängt. Was passiert, wenn du das BSSID-Lock ausschaltest? Quote
mike_79 Posted October 21, 2024 at 05:26 AM Author Posted October 21, 2024 at 05:26 AM Hallo MatzeTF Ich habe tatsächlich sowohl 1xAccesspoint (via Kabel) und ein 1xWLAN-Repeater im Einsatz. In der Vergangenheit hat sich die WARP2 Wallbox immer auf den schwächeren WLAN-Repeater ohne BSSID-Lock gehängt, obwohl die (Main-)Fritzbox 3 Meter daneben stand. Deswegen die Einstellung aus der Vergangenheit im Setup. -> Ich schalte jetzt die "BSSID-Lock raus" und schaue ob die Verbindungsabbrüche mit v2.6.1 weg sind und berichte dann. Mike Quote
mike_79 Posted October 21, 2024 at 06:44 AM Author Posted October 21, 2024 at 06:44 AM Hallo nach Deaktivierung der Einstellung "BSSID-Lock" bei v2.6.1 kommt es weiterhin zu den Verbindungsabbrüchen. Quote
rtrbt Posted October 21, 2024 at 10:03 AM Posted October 21, 2024 at 10:03 AM Kannst du davon auch nochmal einen Debug-Report ziehen? Ich würde gerne sehen, ob die Verbindungsabbrüche den selben Fehlercode haben. Quote
mike_79 Posted October 21, 2024 at 11:52 AM Author Posted October 21, 2024 at 11:52 AM (edited) Hallo, anbei ein neues Debug Report ohne BSSID-Lock. warp2-YDw-Debug-Report-2024-10-21T13-47-54-605_ohneBSSID-Lock.txt P.S. Ich musste diesmal die Verbindung (Ladekabel) zum Auto trennen damit die Webserver-Verbindung aufgebaut werden kann und der Debug Report herunterladen konnte. Edited October 21, 2024 at 11:57 AM by mike_79 Quote
MatzeTF Posted October 21, 2024 at 04:40 PM Posted October 21, 2024 at 04:40 PM Kannst du mal testweise MQTT deaktivieren, wenn die neueste Firmware läuft? Kannst du auch schon vor dem Update deaktivieren. Ansonsten kannst du das BSSID-Lock auf den AP mit bestem Empfang wieder aktivieren und die Empfangsoptimierung deaktivieren. Die haben anscheinend nichts mit dem Problem zu tun und die Empfangsoptimierung ist nur für Geräte gedacht, die sehr weit vom AP entfernt sind. Quote
mike_79 Posted October 21, 2024 at 05:11 PM Author Posted October 21, 2024 at 05:11 PM Aber, wenn ich MQTT deaktiviere, dann kann ich bzw. die WARP2 Wallbox keine commands von evcc empfangen und den FEHLER reproduzieren. Die FW v2.6.1 läuft normal bis zu dem Punkt wenn ich das AUTO anklemme und (evcc) Laden starten möchte. Erst dann dann sendet evcc mittels MQTT das cmd zum starten und die WLAN Verbindung geht flöten. Quote
MatzeTF Posted October 21, 2024 at 05:13 PM Posted October 21, 2024 at 05:13 PM Hatte gerade nicht mehr an evcc gedacht. Dann hilft dir der Tipp nicht und du musst noch warten, bis wir das hier repariert haben. Quote
mike_79 Posted October 21, 2024 at 05:17 PM Author Posted October 21, 2024 at 05:17 PM ?Meinst Du repariert mit neues Release? -> Dann habt ihr eine Vermutung welches Modul betroffen sein kann? Quote
MatzeTF Posted October 21, 2024 at 05:19 PM Posted October 21, 2024 at 05:19 PM Wir haben eine Vermutung und werden dir eine Beta-Firmware zum Testen bauen, wenn wir soweit sind. 1 Quote
mike_79 Posted October 21, 2024 at 05:20 PM Author Posted October 21, 2024 at 05:20 PM Am 21.10.2024 um 19:19 schrieb MatzeTF: Wir haben eine Vermutung und werden dir eine Beta-Firmware zum Testen bauen, wenn wir soweit sind. Gerne, solange fahre ich die V2.1.5 Danke Quote
rtrbt Posted October 22, 2024 at 10:21 AM Posted October 22, 2024 at 10:21 AM 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: Quote The 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 Quote
mike_79 Posted October 22, 2024 at 12:07 PM Author Posted October 22, 2024 at 12:07 PM (edited) Ja, ich nutze ioBrooker. Hat aber andere Gründe. Nicht nur wegen evcc. Ich habe die neue FW Version runter geladen und eingespielt. Die ersten Minuten sehen gut aus. 😀 Ich werde es weiter testen und berichten. Danke für die Tipps und für die sehr sehr schnelle Reaktion ! Edited October 22, 2024 at 12:08 PM by mike_79 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.