src/Wlan.cpp: In function 'bool Wlan_DeleteNetwork(String)':
src/Wlan.cpp:468:91: warning: 'void* memmove(void*, const void*, size_t)' writing to an object of type 'struct WiFiSettings' with no trivial copy-assignment; use copy-assignment or copy-initialization instead [-Wclass-memaccess]
memmove(knownNetworks+i, knownNetworks+i+1, sizeof(WiFiSettings)*(numKnownNetworks-i-1));
^
In file included from src/Wlan.cpp:13:
src/Wlan.h:4:8: note: 'struct WiFiSettings' declared here
struct WiFiSettings {
^~~~~~~~~~~~
Der Code sollte noch getestet werden, das war nur auf dem Papier hingeschrieben worden (ich habe aktuell kein Zugriff auf mein Test-Board, kann ich aber Abend angehen)
std::copy ist eine gute Alternative, das hatte ich nicht auf dem Schirm.
Ich hatte mir die IPAddress Klasse angeschaut und gesehen, dass diese nur aus den 4 byte der ipv4-Addresse besteht (keine internen pointer o.ä.) und bin daher davon ausgegangen, dass das keine Probleme verursacht. Ich bin leider nicht tief genug in C++ drin um das 100% sicher zu sagen.
ABER sollte dem nicht so sein, dann muss eigentlich auch das Laden und Schreiben in den NVS fehlerhaft sein. Dann ist die bessere Möglichkeit eher sicher zu gehen, dass das struct kopierbar ist, also IPAddress durch char[4] zu ersetzen.
Ich habe mir gerade die Doku von Cpp dazu durchgelesen, und es ist wohl deshalb, weil die IPAddress Klasse den assignment Operator (=) überschreibt.
Nach meinem Verständnis also eigentlich kein Problem, obwohl natürlich die Warnung stört.
Ich finde das Thema ist sehr schön in netctl bzw. netctl-auto umgesetzt. Das ist eine kommandozeilen-/konfigurationsdateien-basierte WLAN-Software in Linux.
Hier kann jedem Netzwerk eine Priorität von 1-10 (Priority=n) zugewiesen werden, das Wlan mit der höchsten Priorität (10) wird zuerst gewählt, danach in absteigender Reihenfolge die anderen.
Wenn ich also angenommen die Netzwerke WifiOnICE, Zuhause und Tethering speichern möchte, würde ich Zuhause z.B. die Priorität 6 geben, weil ich damit in der Regel verbunden sein möchte, dem WifiOnICE die Priorität 3, damit ich auch wenn ich an der Bahnlinie wohne, nur mit meinem Heimnetzwerk verbunden werde und nicht mit jedem vorbeifahrenden ICE. Dem Tethering weise ich die Priorität 9 zu, weil ich das explizit an meinem Handy einschalte und daher auch sehr wahrscheinlich damit verbunden sein möchte. So kann ich mich auch im Falle, dass mehrere Netzwerke gleichzeitig verfügbar sind, immer einfach mit dem richtigen Netzwerk verbunden sein. Funktioniert in der Praxis super, wenn man sich über die vergebene Priorität ein paar Gedanken macht.
Das hört sich ja ganz gut an und ließe sich auch implementieren, indem man die Reihenfolge, in der die Netze probiert werden, anpasst.
Ich finde das aus Nutzer-Sicht aber eher umständlich und kompliziert, für jedes Netzwerk eine Priorität zu definieren: gängiges Verhalten so ziemlich aller Geräte ist, dass das stärkste verfügbare Netz präferiert wird!
Dem schließe ich mich vollends an.
Ich habe bei mir allerdings derweil das Problem, dass sich der ESP32 ständig ins „falsche“ WLAN einbucht. Will heißen: Ich habe ein MESH hier und der Fritzbox und zwei AP und offenbar wird immer das Falsche gepickt (sie heißen halt alle gleich).
@biologist
Das Problem ist ein allgemeines WLAN Problem, heißt „sticky client“
Hatte ich bei mir auch mit einem WLAN Radio…
Das einzige was geholfen hat, ist das meine AP alle zusätzlich zum Allgemeinen WLAN noch ein spez. pro AP ausstrahlen (sind halt Unifi AP, die können sogar noch mehr SSIDs ausssenden und verwalten)
Das habe ich auch oft, Espuino ist dann mit meinem Repeater connected, obwohl die Fritz!box deutlich näher ist. Seltsamerweise erhält der Espuino Wlan und Webradio läuft. Es ist in diesem Zustand jedoch mit keinem Gerät möglich auf das Webfrontend des Espuino zuzugreifen. Weder per mDNS noch mit der IP-Adresse, noch Ping.
Machmal steht der richtige Name „Espuino“ in der Fritz!box, manchmal sowas esp32-471134, irgendeine Hex-Zahl.
@tueddy
Bei mir passiert es nicht so oft, also nicht so krass wie bei Torsten , ich hatte es, aber sehr selten, auch mit dem Master.
das Folgende hatte ich im April schon mal Torsten geschrieben:
Was mich wundert warum beim aktuellen MASTER die Verbindung mit dem „richtigen“ WLAN klappt & beim DEV-Branch nicht. Da muss es doch eine Möglichkeit geben.
Es wäre hilfreich mit aktivierten -DCORE_DEBUG_LEVEL=5 das Log hier mal zu posten.
Edit: Es klingt so als ob sich die Box bei gleichen SSID-Namen nicht (immer) mit dem stärkeren WLAN verbindet? Dann kommt die WLAN-Liste nicht sortiert nach Stärke an?
Kann ich so bestätigen. Bin seit mehren Tagen am Testen der Upload-Speeds unter verschiedenen Rahmenbedingungen, das macht die Sache aber extrem schwer. Es scheint manchmal so, als ob der ESPUINO sich bewusst mit dem schlechtesten Signal verbinden würde
@compactflash Sorry, das ich es nicht dazugeschrieben hatte!
In der Platform.ini ist das auskommentiert. Das Semikolon entfernen, so muss das dann aussehen:
build_flags =
-DCORE_DEBUG_LEVEL=5
Dann mit build neu erzeugen. Hier sind die verschiedenen Debug-Level erklärt.
Du hast auch einen Repeater & damit zwei gleiche SSID-Namen?
Im seriellen Monitor werden die verfügbaren WLANs ja in der Reihenfolge angezeigt wie sie gescannt werden & sollten nach Signalstärke absteigend erscheinen.
Auch ein Mesh und zustätzlich ein weiteren Router mit ebenfalls der selben SSID. Die ESPUINOS sind etwa 1 m vom Router entfernt, verbinden sich häuftig aber mit den etwa jeweils 7 m entfernten Routern.
Bei dem bereits bekannten WLAN wird bei mir keine Liste im Log angezeigt. Dort heißt es nur, dass er den Eintrag lädt und sich mit dem WLAN verbindet. Oder muss ich das erst im Code aktivieren, dass er alle WLANs listet?
Ich hatte im Kopf, dass er den Scan nur macht, wenn er sich nicht direkt verbinden kann?
[ 412 ] Hostname aus NVS geladen: ZZZZ
[ 425 ] SSID 0 von NVS geladen: XXXX
[ 429 ] PN5180 firmware version=4.1
[ 433 ] RFID-Tags koennen jetzt gescannt werden...
[ 640 ] Versuche mit WLAN 'XXXX' zu verbinden...
Edit:
von der Statemachine her, wird kein Scan ausgeführt sofern das Verbinden mit der letzten SSID funktioniert. Sehe hier keinen Mechanismus der den besten Empfang sucht. Das war aber glaub auch die Idee um maximal schnell im Netzt zu sein…
Stimmt, bei bekannten WLAN wird kein Scan durchgeführt, damit kommen wir nicht weiter.
Soweit ich sehen kann wird die Verbindungsherstellung sowohl im Master als auch DEV-Branch mit
WiFi.begin(SSID-Name, Password);
durchgeführt. Bei zwei gleichen SSID (Router & Repeater) wäre das dann ein wenig Russisch-Roulette?
Dann schlummert das Problem auch im Master und tritt dort evt. durch anderes Timing nur nicht so oft auf? Hier ein ähnliches Problem
Müssen wir nicht dann auch die BSSD verwenden?
Eine BSSID (Basic Service Set Identifier) dient der eindeutigen Identifizierung eines WLAN-Zugangspunktes, wie z.B. einem Router oder einem Repeater, in einem Funknetz.
Vermutlich wäre das ein guter Punkt. Habe gerade testweise mal den Code so umgebogen, dass er immer mit dem Scan startet. Allerdings tritt dabei trotzdem das Problem auf: Er findet zwar das gute und das schlechte Netzt, verbindet sich aber trotzdem mit dem schlechten:
[ 2250 ] WLAN mit SSID XXXX und Signalstärke -28 auf Kanal 7 gefunden.
[ 2251 ] WLAN mit SSID XXXX und Signalstärke -73 auf Kanal 11 gefunden.
...
[ 60003 ] RSSI: -74 dBm
Da scheint die Bedingung der SSID beim Connect wirklich nicht auszureichen.
Habe hier mal auf die schnelle das reingehackt, dass immer der Scan ausgeführt wird und dann mit dem stärksten bekannten WLAN per BSSID verbunden wird. Das scheint so auch zu klappen… Wlan.zip (4,6 KB)
Um damit auf eine saubere Lösung zu kommen:
Wie wäre es, wenn wir beim „ConnectToLast“ auch einen Scan ausführen, allerdings nur nach der letzten SSID und dann von den Ergebnissen das stärkste nehmen?
Die BSSID zu speichern finde ich nicht zielführend, da wir ja nicht immer mit dem selben Router verbinden wollen, sondern mit dem aktuell besten.
Bin für alle Ideen offen …
