WARP2 Charger Pro Web Interface und MQTT nicht erreichbar bei verbundenem Auto, dadurch keine (externe) Steuerung des Ladens möglich

[flrnsbch]

Hallo zusammen,

erst einmal vielen Dank für ein tolles Produkt.

Leider habe ich in den letzten Wochen ein Problem mit der Verfügbarkeit des Web Interface sowie MQTT meines WARP2 Chargers Pro 22kW. Einen wirklichen Zeitpunkt inkl. einer Änderung in meinem Setup, ab dem das Problem auftrat, kann ich leider nicht wirklich identifizieren. 

Fehlerbild:

• Web-Interface des WARP per Browser unregelmäßig erreichbar
• PING auf statische IP funktioniert
• Mosquitto (MQTT Broker) kriegt keine aktuellen Daten vom WARP, fehlende MQTT Aktualisierung fällt vor allem im Homeassistant und EVCC auf

  homeassistant Status der Entität "WARP2 Charger (warp2-xxxx) Wallbox verfügbar"
  
  Wurde verbunden
  10:18:31 - Vor 6 Minuten
  
  Nicht mehr verfügbar
  10:16:59 - Vor 8 Minuten
  
  Wurde verbunden
  10:15:24 - Vor 9 Minuten
  
  Nicht mehr verfügbar
  10:15:17 - Vor 10 Minuten

• EVCC kann den WARP Charger nicht steuern und wirft Fehlermeldung, dass Daten der Wallbox "outdated" sind (logischerweise, da keine Updates auf MQTT)
• Das WARP Ereignis-Log (wenn ich mal rankomme) zeigt im Grunde nur auf, dass immer wieder eine Disconnect vom MQTT Broker stattfindet und er wieder versucht sich zu verbinden.

  2024-07-09 10:17:02,813 | mqtt             | Disconnected from broker.
  2024-07-09 10:17:02,814 | mqtt             | Was connected for 76 seconds.
  2024-07-09 10:17:18,785 | mqtt             | Failed to connect to broker.

• Der MQTT Broker läuft reibungslos, im Log des MQTT Brokers ist auch nur erkennbar, dass sich der WARP Charger versucht zu verbinden. Alle anderen Use Cases, die über den MQTT Broker laufen, funktionieren einwandfrei. 

Grundlegendes Setup, wie oben sicher schon erkennbar:

• Docker-Umgebung
  • Homeassistant 
  • EVCC 
  • Mosquitto
• Wallbox
  • WARP2 Charger Pro 22kW  (statische IP, MQTT Discovery aktiviert, verbunden via WLAN, FW 2.4.0, Externe Steuerung aktiviert)

Meine erste Vermutung war, dass EVCC hier Fehler verursacht. Jedoch taucht das Fehlerbild auch auf, wenn ich EVCC abschalte. Aber es tritt das Problem meiner Erfahrung nach nur dann auf, wenn ein Auto verbunden ist. 

Habt ihr noch Lösungsideen? Welche Infos bräuchtet ihr noch?

Danke Euch vorab.

[rtrbt]

Zieh bitte einmal einen Debug-Report unter System->Ereignislog und hänge ihn hier an.

[flrnsbch]

Hier ein Debug-Report. Danke Dir. 

debug-report-warp2-292u-2024-07-09T12-53-42-625.txt

[photron]

Das ist eher kein EVCC-Problem, sondern eher ein WLAN-Empfangsproblem.

On 7/9/2024 at 10:26 AM, flrnsbch said:

Das WARP Ereignis-Log (wenn ich mal rankomme) zeigt im Grunde nur auf

Hast du auch Probleme mit der Erreichbarkeit des Webinterfaces der Wallbox?

Teste bitte mal, ob es hilft die WLAN-Empfangs­opti­mierung auf der Wallbox zu aktivieren unter: Netzwerk > WLAN-Verbindung > Empfangs­opti­mierung

Leider geht aus dem Log nicht hervor warum die MQTT-Verbindung verloren geht.

Du kannst für Mosquitto das Logging auf Maximum stellen, dann sollte im Mosquitto Log etwas dazu stehen. Dazu am Ende von /etc/mosquitto/mosquitto.conf diese beiden Zeilen anfügen und Mosquitto neustarten:

log_type all
log_dest syslog

[flrnsbch]

Hi, danke für die Tips. 

Am 9.7.2024 um 14:02 schrieb photron:

Das ist eher kein EVCC-Problem, sondern eher ein WLAN-Empfangsproblem.

Das kann ich mir nicht vorstellen. Der PING auf das Gerät ist immer super (kontrolliere ich auch regelmäßig mit uptime-kuma).

 

Am 9.7.2024 um 14:02 schrieb photron:

Hast du auch Probleme mit der Erreichbarkeit des Webinterfaces der Wallbox?

Ja. absolut. Mal geht's mal geht's nicht. Wenn kein Auto angeschlossen ist, dann funktioniert's eigentlich einwandfrei.

 

Am 9.7.2024 um 14:02 schrieb photron:

Teste bitte mal, ob es hilft die WLAN-Empfangs­opti­mierung auf der Wallbox zu aktivieren unter: Netzwerk > WLAN-Verbindung > Empfangs­opti­mierung

Habe ich jetzt mal eingeschaltet. Mal schauen.

 

Hier ein Auszug aus dem Mosquitto-Log nachdem ich in der Conf die beiden Zeilen angefügt habe (sieht mir irgendwie dennoch nicht so ergiebig aus), die .95 IP ist der WARP-Charger:

1720517062: New client connected from 192.168.178.130:51682 as DVES_17E4A1 (p2, c1, k30, u'DVES_USER').
1720517087: New connection from 192.168.178.56:56328 on port 1883.
1720517087: New client connected from 192.168.178.56:56328 as mqtt-explorer-3fdfb036 (p2, c1, k60).
1720517142: Outgoing messages are being dropped for client mqtt-explorer-3fdfb036.
1720517179: Client mqtt-explorer-3fdfb036 has exceeded timeout, disconnecting.
1720517253: Client warp2-292u closed its connection.
1720517257: Invalid QoS in PUBLISH from DVES_17E4A1, disconnecting.
1720517257: Client DVES_17E4A1 disconnected due to malformed packet.
1720517258: New connection from 192.168.178.130:61730 on port 1883.
1720517258: New client connected from 192.168.178.130:61730 as DVES_17E4A1 (p2, c1, k30, u'DVES_USER').
1720517261: New connection from 192.168.178.95:61126 on port 1883.
1720517261: New client connected from 192.168.178.95:61126 as warp2-292u (p2, c1, k120).
1720517270: Client warp2-292u closed its connection.
1720517284: New connection from 192.168.178.95:61127 on port 1883.
1720517284: New client connected from 192.168.178.95:61127 as warp2-292u (p2, c1, k120).
1720517707: Saving in-memory database to /mosquitto/data//mosquitto.db.
1720518129: Client warp2-292u closed its connection.
1720518143: New connection from 192.168.178.95:61128 on port 1883.
1720518143: New client connected from 192.168.178.95:61128 as warp2-292u (p2, c1, k120).
1720518148: Client warp2-292u closed its connection.
1720518158: New connection from 192.168.178.95:61129 on port 1883.
1720518158: New client connected from 192.168.178.95:61129 as warp2-292u (p2, c1, k120).
1720519508: Saving in-memory database to /mosquitto/data//mosquitto.db.
1720519539: Client DVES_17E4A1 disconnected due to malformed packet.
1720519539: New connection from 192.168.178.130:58087 on port 1883.
1720519539: New client connected from 192.168.178.130:58087 as DVES_17E4A1 (p2, c1, k30, u'DVES_USER').
1720519727: New connection from 192.168.178.56:56573 on port 1883.
1720519727: New client connected from 192.168.178.56:56573 as mqtt-explorer-3fdfb036 (p2, c1, k60).
1720519752: Outgoing messages are being dropped for client mqtt-explorer-3fdfb036.
1720519819: Client mqtt-explorer-3fdfb036 has exceeded timeout, disconnecting.
1720521309: Saving in-memory database to /mosquitto/data//mosquitto.db.
1720522396: Client warp2-292u closed its connection.
1720522410: New connection from 192.168.178.95:61130 on port 1883.
1720522410: New client connected from 192.168.178.95:61130 as warp2-292u (p2, c1, k120).
1720522463: New connection from 192.168.178.56:56842 on port 1883.
1720522463: New client connected from 192.168.178.56:56842 as mqtt-explorer-3fdfb036 (p2, c1, k60).
1720522495: Outgoing messages are being dropped for client mqtt-explorer-3fdfb036.
1720522551: Client warp2-292u closed its connection.
1720522555: Client mqtt-explorer-3fdfb036 has exceeded timeout, disconnecting.
1720522563: New connection from 192.168.178.95:61131 on port 1883.
1720522563: New client connected from 192.168.178.95:61131 as warp2-292u (p2, c1, k120).
1720522578: Client warp2-292u closed its connection.
1720522592: New connection from 192.168.178.95:61132 on port 1883.
1720522592: New client connected from 192.168.178.95:61132 as warp2-292u (p2, c1, k120).
1720523088: Client warp2-292u closed its connection.
1720523110: Saving in-memory database to /mosquitto/data//mosquitto.db.
1720523116: New connection from 192.168.178.95:61134 on port 1883.
1720523116: New client connected from 192.168.178.95:61134 as warp2-292u (p2, c1, k120).
1720524077: New connection from 192.168.178.56:57076 on port 1883.
1720524077: New client connected from 192.168.178.56:57076 as mqtt-explorer-3fdfb036 (p2, c1, k60).
1720524117: Outgoing messages are being dropped for client mqtt-explorer-3fdfb036.
1720524169: Client mqtt-explorer-3fdfb036 has exceeded timeout, disconnecting.
1720524911: Saving in-memory database to /mosquitto/data//mosquitto.db.
1720525534: Invalid QoS in PUBLISH from DVES_17E4A1, disconnecting.
1720525534: Client DVES_17E4A1 disconnected due to malformed packet.
1720525534: New connection from 192.168.178.130:52448 on port 1883.
1720525534: New client connected from 192.168.178.130:52448 as DVES_17E4A1 (p2, c1, k30, u'DVES_USER').
1720525894: Client DVES_17E4A1 disconnected due to malformed packet.
1720525895: New connection from 192.168.178.130:61676 on port 1883.
1720525895: New client connected from 192.168.178.130:61676 as DVES_17E4A1 (p2, c1, k30, u'DVES_USER').
1720526423: New connection from 192.168.178.56:57312 on port 1883.
1720526423: New client connected from 192.168.178.56:57312 as mqtt-explorer-3fdfb036 (p2, c1, k60).
1720526503: Outgoing messages are being dropped for client mqtt-explorer-3fdfb036.
1720526515: Client mqtt-explorer-3fdfb036 has exceeded timeout, disconnecting.
1720526669: Client warp2-292u closed its connection.
1720526682: New connection from 192.168.178.95:61135 on port 1883.
1720526682: New client connected from 192.168.178.95:61135 as warp2-292u (p2, c1, k120).
1720526685: Client warp2-292u closed its connection.
1720526699: New connection from 192.168.178.95:61136 on port 1883.
1720526699: New client connected from 192.168.178.95:61136 as warp2-292u (p2, c1, k120).
1720526712: Saving in-memory database to /mosquitto/data//mosquitto.db.
1720527523: New connection from 192.168.178.56:57557 on port 1883.
1720527523: New client connected from 192.168.178.56:57557 as mqtt-explorer-3fdfb036 (p2, c1, k60).
1720527553: Outgoing messages are being dropped for client mqtt-explorer-3fdfb036.
1720527619: Client mqtt-explorer-3fdfb036 has exceeded timeout, disconnecting.
1720528048: New connection from 192.168.178.56:57587 on port 1883.
1720528048: New client connected from 192.168.178.56:57587 as mqtt-explorer-3fdfb036 (p2, c1, k60).
1720528077: Outgoing messages are being dropped for client mqtt-explorer-3fdfb036.
1720528135: Client warp2-292u closed its connection.
1720528141: Client mqtt-explorer-3fdfb036 has exceeded timeout, disconnecting.
1720528184: New connection from 192.168.178.95:61140 on port 1883.
1720528184: New client connected from 192.168.178.95:61140 as warp2-292u (p2, c1, k120).
1720528254: New connection from 192.168.178.95:61144 on port 1883.
1720528259: Client warp2-292u already connected, closing old connection.
1720528259: New client connected from 192.168.178.95:61144 as warp2-292u (p2, c1, k120).
1720528259: Client warp2-292u closed its connection.
1720528271: New connection from 192.168.178.95:61145 on port 1883.
1720528271: New client connected from 192.168.178.95:61145 as warp2-292u (p2, c1, k120).
1720528324: Client warp2-292u closed its connection.
1720528336: New connection from 192.168.178.95:61149 on port 1883.
1720528336: New client connected from 192.168.178.95:61149 as warp2-292u (p2, c1, k120).
1720528364: New connection from 192.168.178.95:61150 on port 1883.
1720528364: Client warp2-292u already connected, closing old connection.
1720528364: New client connected from 192.168.178.95:61150 as warp2-292u (p2, c1, k120).
1720528373: Client warp2-292u closed its connection.
1720528465: Client DVES_17E4A1 disconnected due to malformed packet.
1720528465: New connection from 192.168.178.130:57430 on port 1883.
1720528465: New client connected from 192.168.178.130:57430 as DVES_17E4A1 (p2, c1, k30, u'DVES_USER').
1720528489: mosquitto version 2.0.18 terminating
1720528489: Saving in-memory database to /mosquitto/data//mosquitto.db.

 

 

Weitere Konkretisierung des Fehler. Gerade habe ich einen Ladevorgang "manuell" gestartet. EVCC während des gesamten Prozesses abgeschaltet:

1. Auto angeschlossen
2. Ladevorgang via homeassistant (MQTT-Anbindung) gestartet
3. Ladevorgang lief
4. Ladevorgang via homeassistant (MQTT-Anbindung) beendet // bis hierhin gute Verbindung zur Wallbox (Webinterface und Homeassistant-Anbindung)
5. Wallbox-Web-Interface nicht mehr erreichbar, homeassistant meldet "Wallbox nicht verfügbar", Debug-Report wieder angehangen. 

Vielleicht helfen diese weiteren Informationen noch?

debug-report-warp2-292u-2024-07-09T15-10-16-659.txt

[flrnsbch]

Hallo zusammen,

jetzt habe ich das richtige Log-File mit allen Logs von mosquitto (reduziert auf einen Zeitraum in dem laut WARP Debug Report MQTT-Verbindungsprobleme bestanden). Ich hänge dieses und einen neuen Debug Report vom WARP an.

Die Zeiten in den beiden Reports unterscheiden sich um 2h. Sprich, 06:00 Uhr im mosquitto entspricht 08:00 im WARP Log.

Danke Euch für die Hilfe.

2024-07-10_mosquitto_reduced.log debug-report-warp2-292u-2024-07-10T09-27-53-321.txt

[photron]

Danke für die Logs.

Wir setzen den Timeout für unseren MQTT Client auf eine Sekunde. Wir vermuten, dass das deinem Setup zu gering ist.

Teste mal bitte die angehängte Firmware mit 10 Sekunden MQTT Timeout.

warp2_firmware_2_4_0_668e5d3f_4c292c70ca8e3ef_merged.bin

[flrnsbch]

Danke Euch.

Firmware habe ich eingespielt. Im Webinterface sehe ich dennoch das MQTT Sendeintervall auf 1s. Ist das der Timeout auf den ihr in Eurer letzten Nachricht verweist? Soll ich diesen auf 10s stellen?

Ansonsten teste ich's gleich mal ein bisschen und schließe das Fahrzeug an, ab und starte ein paar Ladevorgänge. Mal schauen. 

[photron]

Sendeinterval und der Timeout haben nichts mit einander zu tun. Bitte das Sendeintervall auf 1 Sekunde lassen.

[flrnsbch]

Okay, verstanden.

Habe 2x getestet:

• Ladevorgang via homeassistant gestartet
• 3-4 Minuten laufen lassen
• Ladevorgang via homeassistant beendet
• Web Interface weiterhin erreichbar, homeassistant meldet auch Verfügbarkeit der WARP Box, typischerweise kam hier ja der Verbindungsabbruch

Ich werde jetzt auch wieder evcc hochfahren und weiter testen. Das verspricht jedoch schonmal einiges. 

Welche Nachteile haben wir denn durch den 10s Timeout? Könnte/sollte ich was an meinem Setup ändern?

 

Update: Mit evcc traten gerade mehrere kurze Verbindungsabbrüche hintereinander auf. Zeitlich in etwa um das Auslösen eines Ladevorgangs herum. Auch das Webinterface ist dann nicht erreichbar. Mosquitto Log und WARP Debug Report im Anhang (habe aber log_type all wieder ausgeschaltet, da riesiges File). 

_mosquitto_logs (2).txt debug-report-warp2-292u-2024-07-10T15-50-23-154.txt

bearbeitet July 10, 2024 at 13:50 von flrnsbch
Update evcc

[photron]

Ein längerer Timeout bedeutet langsamere Reaktion in Fehlerfall.

Wenn du kein Auto lädst ändern sich die Zählerwerte kaum und die Messwerte werden seltener über MQTT geschickt, da diese nur bei Änderung gesendet werden. Vermutlich schafft dein WLAN gerade so den Durchsatz, dass die Daten im Ruhezustand schnell genug ankommen. Wenn jetzt aber mehr Daten gesendet werden müssen, dann reicht der Durchsatz deines WLANs nicht mehr, um alle Daten schnell genug rauszubekommen und unser MQTT Client läuft in den Timeout.

Das würde auch dazu passen, dass du Probleme beim Laden des Webinterfaces der Wallbox hast. Ich vermute, dass diese Probleme auch jetzt noch da sind, während die MQTT Verbindung der Wallbox bei längerem Timeout jetzt stabil ist.

Ich vermute weiterhin ein Problem mit deinem WLAN, dass dazu führte, dass sich MQTT bei uns nicht gut verhalten hat.

[flrnsbch]

Danke für die Hinweise. Wie gehe ich denn nun mit der "neuen" bzw. individuellen FW um? Einfach installiert lassen? Was passiert beim nächsten Update?

Kann ich irgendwo regeln, dass Daten an den MQTT Broker nur alle x Sekunden gesendet werden, um diese Vielzahl an Datenübertragung zu vermeiden? Das würde dieses "Problem" mit schlechtem WLAN ja möglicherweise auch regeln, oder? 

[photron]

Bis zum nächsten Update haben wir eine dauerhafte Lösung. Bis dahin kannst du diese Firmware installiert lassen.

Das mit dem höheren Datenrate beim Laden ist jetzt eine Idee warum das nur beim Laden passiert.

Du hast im Log auch Fälle wie diesen. Da ist vermutlich die CONNACK-Antwort von Mosquitto für den Verbindungsversuch der Wallbox nicht schnell genug bei der Wallbox angekommen. Darauf hin hat die Wallbox die Verbindung geschlossen, ohne das irgendetwas anderes gesendet würde.

2024-07-09T20:48:38: New client connected from 192.168.178.95:51682 as warp2-292u (p2, c1, k120).
2024-07-09T20:48:38: Sending CONNACK to warp2-292u (0, 0)
2024-07-09T20:48:38: Client warp2-292u closed its connection.

Dann hast du Meldungen wie diese:

2024-07-10 15:06:23,309 | wifi             | Disconnected from SBCH: Reception too poor (200). Was connected for 9335 seconds.

Wobei im Log aber auch steht, dass der RSSI Wert -64 wäre, was nicht super ist, aber ach nicht absolute schlecht. Es scheint mir du hast da irgendwie WLAN Problem, bzw die Wallbox hat WLAN Probleme.

Wie lange hast du die Wallbox schon? Hat die da ohne Probleme zuvor Monate gelaufen und plötzlich treten diese Probleme auf?

Wie ist die Wallbox angebracht? Hängt die draußen im Wetter? Ist der Deckel ordentlich dicht verschraubt? Kannst vielleicht du Fotos machen, damit wir uns eine Bild von der Lange machen können? Worauf ich hinaus will, wenn das vorher Monate lange ohne Probleme gelaufen hat und dein WLAN sonst gut funktioniert, auch an der Stelle an der die Wallbox hängt, dann könnte das vielleicht auch ein Hardware-Schaden sein.

[flrnsbch]

Hallo zusammen, ich möchte in jedem Fall noch einmal antworten. Es war das WLAN.

Ich habe noch einmal mit einem gesonderten Access Point ein neues WLAN aufgebaut und den WARP Charger damit als einziges Gerät verbunden. Seither ist die Verbindung deutlich besser und es gibt kaum noch Abbrüche. Die Abbrüche, die es gibt, sind nur noch 3 bis 5 Sekunden lang und nicht spürbar.

In der Doku konnte ich nicht finden, ob der WARP Charger Wifi 6 unterstützt. Tut er das? Das könnte das Problem ja möglicherweise auch lösen, da hier die Bandbreite größer ist und die das WLAN-Netz mehr Geräte verträgt (so mein Laienverständnis), oder?

[MatzeTF]

Der WARP Charger unterstützt leider nur maximal Wi-Fi 4.

[eweri]

Am 17.7.2024 um 22:28 schrieb flrnsbch:

Hallo zusammen, ich möchte in jedem Fall noch einmal antworten. Es war das WLAN.

Ich habe noch einmal mit einem gesonderten Access Point ein neues WLAN aufgebaut und den WARP Charger damit als einziges Gerät verbunden. Seither ist die Verbindung deutlich besser und es gibt kaum noch Abbrüche. Die Abbrüche, die es gibt, sind nur noch 3 bis 5 Sekunden lang und nicht spürbar.

In der Doku konnte ich nicht finden, ob der WARP Charger Wifi 6 unterstützt. Tut er das? Das könnte das Problem ja möglicherweise auch lösen, da hier die Bandbreite größer ist und die das WLAN-Netz mehr Geräte verträgt (so mein Laienverständnis), oder?

Hallo flrnsbch!

Als alter IT-ler gilt der Spruch „Kabel ist durch nichts zu ersetzen außer durch noch mehr Kabel“ - WLAN ist nett und bequem, aber auch sehr störanfällig und wenn Du an den Empfangsgrenzen bist, passiert das, was Du jetzt erlebst. Wenig Daten zum Übertragen dann ist alles gut, viele Daten und das WLAN bricht zusammen. Das passiert wenn der Empfang nicht wirklich berauschend ist. Außerdem kann WLAN immer auch durch äußere Einflüsse, die man selber nicht beeinflussen kann gestört werden, z.B. stellt dein Nachbar einen neuen Router auf, der auf dem gleichen Kanal sendet wie dein Router. (Vergiss das Versprechen, die würden sich selber einen freien Kanal suchen - habe ich in den letzten 10 Jahren bei keinem Router gesehen).

Hier mal ein paar Tips, die den Empfang verbessern können:

• wenn möglich Abstand zwischen Router und Client verringern - damit verbessert sich die Empfangsstärke
• prüfe mal wie viele WLANs in deiner Nähe sind. Bitte in der Nähe deines Routers und in der Nähe deiner WARP messen. Die senden vermutlich alle auf Kanal 1, 6, 11(oder 13) - es kann schon helfen mal Kanal 3, 8 oder 9 zu verwenden. Das verbessert nicht die Empfangsstärke aber reduziert die Störungen durch benachbarte WLANs.
• WLAN-Repeater sind ein absolutes NO-GO, denn diese werden fast immer falsch platziert und falsch eingesetzt.
• wenn möglich WLAN-Repeater über Ethernet-Kabel (was diese dann zu WLAN-AccessPoints macht) mit dem Haupt-Router verbinden und kontrollieren, das dann auch wirklich die Daten vom WLAN ins Kabel gehen. Ich habe schon WLAN-APs gesehen, die waren per Kabel verbunden, haben die Daten trotzdem per WLAN empfangen und per WLAN weitergeleitet (das halbiert deinen möglichen Datendurchsatz)

 

Ein neuerer WLAN-Standard wird dir kaum helfen, denn diese Standards gehen immer von optimalem Empfang aus und dann wird versucht möglichst noch höhere Übertragungsraten zu standardisieren. Das was Du beschreibst hatte ich auch, das ist an der Empfangsgrenze und das interessiert kein Standartisierungsgremium. streng genommen bewegt man sich da außerhalb des definierten Standards.

Wenn du an der Empfangsgrenze bist, können unterschiedliche WLAN-Clients sich völlig unterschiedlich verhalten: der eine Client hat vielleicht eine bessere Antenne und läuft scheinbar ganz normal (meine alte WARP1), ein andere Client hat hin und wieder Empfang (meine WARP2 und WARP3 am selben Standort der WARP1) und ein anderer sieht zwar das WLAN, aber das Anmelden klappt einfach nicht.
Blöd ist, das die meisten WLAN-Clients es entweder gar nicht oder schlecht mitteilen, wenn der WLAN-Empfang unterirdisch ist.

Also: Kabel legen oder Abstand zum WLAN-Router verringern.

Hoffe das hilft dir.

[MatzeTF]

On 7/20/2024 at 3:19 PM, eweri said:

 

• prüfe mal wie viele WLANs in deiner Nähe sind. Bitte in der Nähe deines Routers und in der Nähe deiner WARP messen. Die senden vermutlich alle auf Kanal 1, 6, 11(oder 13) - es kann schon helfen mal Kanal 3, 8 oder 9 zu verwenden. Das verbessert nicht die Empfangsstärke aber reduziert die Störungen durch benachbarte WLANs.

Ich weiß nicht, wo diese Empfehlung herkommt, aber im Allgemeinen ist es kontraproduktiv, einen der unüblichen Kanäle zu nutzen. Liegen benachbarte WLANs auf 1 und 6 und man versucht 3 zu nutzen, um den Störungen zu entgehen, hat man das Problem, dass man sich stattdessen Störungen von 1 und 6 einfängt. Nutzt man 1, 6 oder 11, muss man sich nur mit Geräten auf dem entsprechenden Kanal rumschlagen, aber alle anderen sind egal. Wenn man Glück hat, sind in der Nachbarschaft die EU-freundlichen Kanäle 1, 5, 9 und 13 verbreitet. Dann sollte man natürlich einen davon nehmen.

Ansonsten stimme ich dir in den anderen Punkten zu.

Wenn wir aber sowieso gerade WLAN-Tipps verteilen, hätte ich da noch zwei:

• Deaktiviere Unterstützung für den B Standard. Nicht nur ältere Accesspoints stehen oftmals noch auf B+G+N und B sollte man wirklich loswerden.
• Hat der Accesspoint mehrere Antennen, sollte man sie nicht hübsch parallel ausrichten, sondern stattdessen alle orthogonal zueinander. Eine Antenne sollte vertikal sein, die andere(n) zur Seite und/oder in den Raum zeigen. Geräte mit schlechtem Empfang sollten möglichst auf die Längsseite einer Antenne schauen, nicht auf deren Spitze.

Zum Thema freien Kanal suchen: Ich habe schon APs gesehen, die das machen. Das Problem ist eher, dass kein Kanal wirklich „frei“ ist. Das WLAN von einem meiner Nachbarn liegt mal auf meinem und mal nicht. Liegt es auf meinem, kann ich schön sehen, dass er anscheinend einen Repeater hat und stundenlang Netflix oder sowas über WLAN schaut und fast den ganzen Kanal blockiert. Zeitweilig habe ich versucht, selbst auf einen anderen Kanal zu wechseln, was aber nicht geholfen hat, weil das andere WLAN mir hinterher gewandert ist.

Der integrierte Accesspoint aller WARP* Charger wählt sich übrigens beim Start auch selbst einen möglichst freien Kanal (funktioniert wirklich), wechselt den aber nie freiwillig sondern behält den gewählten Kanal bis zum nächsten Neustart. Allerdings nur, falls keine WLAN-Verbindung besteht. Besteht eine WLAN-Verbindung, muss der AP leider immer auf dem selben Kanal liegen wie das WLAN, zu dem die Wallbox verbunden ist. Empfehlenswert ist daher, bei der Wallbox den Fallback-Modus des AP zu aktivieren, damit er üblicherweise aus ist und nichts stört.

[eweri]

Am 20.7.2024 um 19:12 schrieb MatzeTF:

Ich weiß nicht, wo diese Empfehlung herkommt, aber im Allgemeinen ist es kontraproduktiv, einen der unüblichen Kanäle zu nutzen. Liegen benachbarte WLANs auf 1 und 6 und man versucht 3 zu nutzen, um den Störungen zu entgehen, hat man das Problem, dass man sich stattdessen Störungen von 1 und 6 einfängt. Nutzt man 1, 6 oder 11, muss man sich nur mit Geräten auf dem entsprechenden Kanal rumschlagen, aber alle anderen sind egal. Wenn man Glück hat, sind in der Nachbarschaft die EU-freundlichen Kanäle 1, 5, 9 und 13 verbreitet. Dann sollte man natürlich einen davon nehmen.

Ansonsten stimme ich dir in den anderen Punkten zu.

Hallo MatzeFT!

Das ist meine Berufserfahrung aus 25 Jahren IT und Netzwerk. Es ist richtig, das neuere WiFi-Standards mehrere benachbarte Kanäle belegen und wenn die Router nebeneinander ständen, würde deine Vermutung mit den Störungen aus dem oberen und unteren Kanälen wohl stimmen. Aber in Stadtwohnungen habe ich schon 20 bis 30 WLANs gezählt und alle waren auf 1, 6 und 11 (bzw. 13 - Hersteller abhängig). Nun sind diese „Störquellen“ aber weiter weg und auch räumlich zufällig verteilt. Ich habe schon öfters in solchen Situationen, in dem sich der Kunde über abreißende Video-Streams beschwerte nur durch ausweichen auf einen unüblichen Kanal das Problem lösen können.

Mittlerweile schaue ich mir immer erst die Geschwindigkeit der WLAN-Verbindung an, zeigt da der Computer weniger als 150Mb/s ist das keine stabile Verbindung - ich empfehle dann grundsätzlich das WLAN zu optimieren.

Beim uralten „B“-Standard sehe ich das genauso, der sollte abgeschaltet sein, falls der Router den noch unterstützt. Davon wären Geräte der ersten WLAN-Generation betroffen.

 

P.S. Ich habe gerade festgestellt, das meine Fritz!Box auch noch „B“ könnte, scheint aber normalerweise abgeschaltet zu sein.

bearbeitet July 20, 2024 at 18:39 von eweri