mike_79 Geschrieben October 20, 2024 at 12:22 Geschrieben October 20, 2024 at 12:22 (bearbeitet) 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 bearbeitet October 20, 2024 at 12:23 von mike_79 Zitieren
MatzeTF Geschrieben October 20, 2024 at 19:48 Geschrieben October 20, 2024 at 19:48 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? Zitieren
mike_79 Geschrieben October 21, 2024 at 05:26 Autor Geschrieben October 21, 2024 at 05:26 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 Zitieren
mike_79 Geschrieben October 21, 2024 at 06:44 Autor Geschrieben October 21, 2024 at 06:44 Hallo nach Deaktivierung der Einstellung "BSSID-Lock" bei v2.6.1 kommt es weiterhin zu den Verbindungsabbrüchen. Zitieren
rtrbt Geschrieben October 21, 2024 at 10:03 Geschrieben October 21, 2024 at 10:03 Kannst du davon auch nochmal einen Debug-Report ziehen? Ich würde gerne sehen, ob die Verbindungsabbrüche den selben Fehlercode haben. Zitieren
mike_79 Geschrieben October 21, 2024 at 11:52 Autor Geschrieben October 21, 2024 at 11:52 (bearbeitet) 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. bearbeitet October 21, 2024 at 11:57 von mike_79 Zitieren
MatzeTF Geschrieben October 21, 2024 at 16:40 Geschrieben October 21, 2024 at 16:40 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. Zitieren
mike_79 Geschrieben October 21, 2024 at 17:11 Autor Geschrieben October 21, 2024 at 17:11 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. Zitieren
MatzeTF Geschrieben October 21, 2024 at 17:13 Geschrieben October 21, 2024 at 17:13 Hatte gerade nicht mehr an evcc gedacht. Dann hilft dir der Tipp nicht und du musst noch warten, bis wir das hier repariert haben. Zitieren
mike_79 Geschrieben October 21, 2024 at 17:17 Autor Geschrieben October 21, 2024 at 17:17 ?Meinst Du repariert mit neues Release? -> Dann habt ihr eine Vermutung welches Modul betroffen sein kann? Zitieren
MatzeTF Geschrieben October 21, 2024 at 17:19 Geschrieben October 21, 2024 at 17:19 Wir haben eine Vermutung und werden dir eine Beta-Firmware zum Testen bauen, wenn wir soweit sind. 1 Zitieren
mike_79 Geschrieben October 21, 2024 at 17:20 Autor Geschrieben October 21, 2024 at 17:20 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 Zitieren
rtrbt Geschrieben October 22, 2024 at 10:21 Geschrieben October 22, 2024 at 10:21 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. warp2_firmware-NIGHTLY_2_6_1_671778fe_14b645f38e83042_merged.bin 1 Zitieren
mike_79 Geschrieben October 22, 2024 at 12:07 Autor Geschrieben October 22, 2024 at 12:07 (bearbeitet) 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 ! bearbeitet October 22, 2024 at 12:08 von mike_79 Zitieren
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.