Ja, diese Ausfälle habe ich auch - leider sehr regelmäßig.

Früher konnte ich das noch an einer Firmwareversion fest machen; mittlerweile kann ich diese Korrelation nicht mehr ziehen. Dennoch, stabil ist etwas ganz anderes. (Die Garagentorsteuerung 1 Meter weiter läuft einwandfrei und das dauerhaft. Der AP ist auf der anderen Seite der Wand.)

Ja, die Abstürze kenne ich auch, wenn ich den AP oder Mesh (einen tatsächliche Funktionalität von Mesh habe ich nicht erkennen können - eine zweite Wallbox hängt 10 cm neben dran, die eine läuft teilweise einige Wochen stabil, während die andere ständig ausfälle hat, dann wechselt sich das mal wieder ab und die andere fällt aus - dennoch, mit Mesh ist da nicht viel.) einschalte. Daher habe ich beides wieder deaktiviert.

Ja, meine Wallbox erhält auch per MQTT Zählerstände gepusht. Ich bin aktuell schon am überlegen, ob ich das Lademanagement komplett herauslösen sollte (aktuell habe ich noch zahlreiche Regel aktiv; auch eine, die bei Ausfwall von WLAN die Box auf Durchzug stellt) und die Wallbox nur noch als Marionette per Home Assistant steuern sollte. So würde ich die CPU entlasten. Ggf. ist auch eine Anbindung per OCPP oder HTTP ressourcenschonender? Aktuell habe ich noch MQTT inkl. SSL-Verschlüsselung aktiv; jedoch ist die CPU eigentlich weitgehend entspannt - auch der RAM-Verbrauch geht gerade noch.

Hmm, irgendwie ziemlich unzufriedenstellend.

Ich fasse hier mal meine Erkenntnisse zu dem Thema zusammen:

1. Die Wallbox wählt sich - was kaum nachvollziehbar ist - nicht konsequent auf dem AP mit dem besten Signal ein, zum Teil sogar und das mit befremdlicher Konsequenz auf dem AP mit einem so schlechten Signal, dass keine Kommunikation mehr stattfinden kann. Bei mir sieht die Fritzbox die cfos dann zwar noch auf dem entferntesten AP, ein Ping dorthin schlägt aber bereits fehl. Ich halte das für das Grundübel der Box. Wenn sie sich mal auf dem besseren AP einwählt, arbeitet sie auch sauber.
2. Die UI der Wallbox erlaubt die Vorgabe der BSSID des AP, auf dem sie sich einwählen soll. Eine Eingabe dort ignoriert sie jedoch und verhält sich wie unter 1. beschrieben.
3. Der AP der Wallbox legt sich mit Vorliebe auf den Kanal, auf welchem auch meine Fritzbox arbeitet,
4. auch wenn man einen anderen Kanal vorgibt, auf dem er arbeiten soll.

Ich habe einen OBD2-Adapter (Wican), mit dem ich den SoC meiner Fahrzeugbatterie an die Wallbox übermittle. Der befindet sich ca. 4m weiter von meinen AP's entfernt und zudem im Fahrzeuginnern, aber er arbeitet stabil.
Auch er hat wie die Wallbox einen AP, den kann man aber optional deaktivieren lassen, sobald und solange das Gerät als WLAN-Station verbunden ist. Das ist eine sehr vernünftige Eigenschaft, die ich mir für die Wallbox auch wünschen würde.

Die Probleme schlagen durch bis auf die Ladevorgänge, sobald man bei Laden Werte verarbeitet, die irgendwie über das WLAN kommen (bei mir z. B. über mqtt). Dann kommt es bei mir zu Restarts des Charging Managers bis zum Totalausfall der Box mit der Meldung, ich solle meine Konfiguration reparieren. Verlege ich meine Eingabedaten für die Ladevorgänge wieder in CM-Variablen, statt sie über mqtt zu übermitteln, arbeitet die Box wieder zufriedenstellend. Aber zu der Aussage von cfos, dass man die Box komplett über mqtt steuern könnte, passt das in keiner Weise.

Ich habe heute die Information vom cfos Service erhalten, dass man die oben unter 2. und 4. beschriebenen „Features“ mal an „die Techniker“ weitergeben müßte. Ich hoffe, es passiert auch.