Bei mir sind die Kids auch ab und zu bei Oma+Opa.
Momentan startet die Box dann immer im Accesspoint Modus und gebe die immer wieder die Zugangsdaten im Wechsel ein.
Schön wäre es wenn ich die Daten für mehrere Wlans vorhalten kann. Im Prinzip muss ja aber mehr drum herum. Da theoretisch auch eine Fallentscheidung implementiert werden müsste, was ist, wenn mehrere bekannte Wlans verfügbar sind (das wäre bei nicht problematisch, da 80km entfernt 
)
Also technisch ist das natürlich kein Problem und ich habe die Anfrage auch schon mehrfach bekommen. Die Frage ist allerdings an dieser Stelle, ob der zeitliche Faktor nervig wird. Weil du musst ja dann durch mehrere WLANs iterieren in der Hoffnung, dass du was findest, das funktioniert. Ggf. ist es aber auch gar nicht mehr so wild, da ich den WLAN-Start ja vor einer Weile auf nicht blockierend umgebaut habe (was ich hätte viel früher tun sollen).
Wenn man das angeht, dann sollte man es sicherlich so umsetzen, dass das WLAN, welches zuletzt funktioniert hat, in der Liste ganz oben steht und damit das ist, welches zuerst abgetestet wird.
Fazit: Ich bräuchte es nicht, kann aber den Request total verstehen und würde es unterstützen.
2 „Gefällt mir“
Ich verlink mal eine
Ich finde die Idee auch immer noch gut 
@biologist du siehst das zu umständlich. Man kann doch vorher einen WiFi-Scan machen und das stärkste bekannte Netzwerk auswählen.
Man findet hier auch ein Beispiel dazu: arduino-esp32/WiFiScan.ino at 0d84018d969309addacbcc3e3782c1fadc95fbc8 · espressif/arduino-esp32 · GitHub
@Christian hatte das auch in seinen Fork eingebaut und in der Weboberfläche angezeigt, das war auch ganz nett würde ich sagen.
Ich habe ehrlich gesagt Zweifel daran, dass das im Mittel schneller ist.
Müsste man probieren; ich habe leider gerade keinen ESP zur Hand.
Es gibt aber auch noch eine WifiMulti Klasse, die kann ja nicht so verkehrt sein…
2 „Gefällt mir“
Wie kann man keinen ESP zur Hand haben? 
Ok, das wäre natürlich auch eine Option. Dann speichert man die Liste im NVS, steckt sie in diese Klasse rein und dann überlässt man dem Framework den Rest.
Preisfrage: Was macht die WifiMulti Klasse intern?
Genau, einen Scan und dann noch ein bisschen drumherum.
Laut Doku dauert der Scan für jeden Channel 120ms, also insgesamt ca 1-2 Sekunden. Ich hatte aber den Eindruck dass die bisherige Lösung auch recht lange braucht.
Aber unabhängig davon: Wenn der Wifi-Start asynchron läuft, ist es doch relativ egal wie lange die Verbindung dauert?
Aber nur dann, wenn man von SD abspielt. Das tue ich für meinen Teil, und ich nutze ESPuino ja auch, zu 99% nicht .
Aber gut, man kann’s ja ausprobieren.
Ich hab die letzten Tage mal was gebastelt:
Ich will gar nicht lange beschreiben, das meiste steht auf Github. Jedenfalls klappt das ganze recht gut (save frontend). Ich würde mich freuen, wenn die üblichen Verdächtigen mit Testaufbauten die Version mal ausprobieren würden. Ihr wisst ja wer gemeint ist.
Ich hab versucht möglichst nah am ursprünglichen Verhalten von Wlan.cpp zu bleiben - bis auf ein paar subjektive Verbesserungen und natürlich das Zeugs mit mehreren Wifis:
- Starte alle 60s einen Verbindungsversuch wenn die Verbindung verloren wurde
- Schalte den AP nach 5 Minuten aus
Beides theoretisch konfigurierbar.
3 „Gefällt mir“
Das Dumping der WLANs zeigt nur die SSID und nicht die Passwörter an - das habe ich richtig interpretiert, oder?
Ja, das wär doch ein bisschen arg unsicher.
Ich hab aber in den entwicklungs-prints noch irgendwo das PW drinnen - kommt aber noch raus.
1 „Gefällt mir“
- Hast du die statische IP-Konfiguration ausgebaut oder übersehe ich die?
- Gleiches gilt für den Workaround, falls der Reconnect nicht erfolgreich war. Passt vielleicht methodisch nicht zu deinem Ansatz, aber ohne das sehe ich Probleme kommen.
- Ich hab möglichst alles kopiert, aber das ist wohl wirklich unter den Tisch gefallen
- Der Workaround dass 2 mal versucht wird zu verbinden? Das ist effektiv gleich geblieben. Jedes Netzwerk wird 2 mal probiert bevor das nächste dran ist.
Edit: Hab’s gefixt, über dem Stück code hat auch noch der hostname-teil gefehlt, den hab ich auch nicht kopiert ^^
Bin erst jetzt dazu gekommen das Feature zu testen:
Zunächst finde ich das Speichern mehrerer WLANs super sinnvoll, fast jedes Kid hat Opa/Oma und nimmt die Box auch da mit hin.
@SZenglein Vielen Dank für den Entwurf & Deine Mühe!
Nach dem Umstieg auf den Branch hat sich die Box mit den zuvor gespeicherten Zugangsdaten verbunden. Das ist fein & sollte auch so sein.
Log:
[ 466 ] Neue Lautstärke empfangen via Queue: 3
Wlan scan done; Took 1664 millis
1: Vodafone-407580 (-68)*
2: FRITZ!Box 5530 IG (-69)*
3: MyWLAN (-76)*
4: WLAN-89XPXA (-77)*
5: EasyBox-919850 (-77)*
6: FRITZ!Box 5530 IG (-78)*
7: Trenet (-86)*
8: Luftbruecke (-89)*
9: Vodafone-23C4 (-89)*
[ 2007 ] Hostname aus NVS geladen: Espuino
Trying wifi candidate 0 ...
comparing to MyWLAN
not known
Trying wifi candidate 1 ...
comparing to MyWLAN
not known
Trying wifi candidate 2 ...
comparing to MyWLAN
SSID_0
[ 2090 ] Versuche mit WLAN 'MyWLAN' zu verbinden...
connecting to MyWLAN with pwd xxxx .
[ 2855 ] Aktuelle IP: 192.168.178.86
Als Rückschritt empfinde ich den verzögerten Start +1,5 Sekunden. Vorher hat sich meine Box viel schneller verbunden. Ich denke auch die Webstream Hörer werden meckern…
Vorschlag: Mit den zuletzt erfolgreichen Zugangsdaten verbinden & nur beim Fehlschlagen den Scan durchführen. Der Fall eines WLAN Wechsels kommt ja eher selten vor und sollte nicht zu Lasten der Startgeschwindigkeit gehen. Oder kann man die WLAN-Suche auch asynchron machen?
Einige Kleinigkeiten:
- Ich habe zum Testen bei meinem Telefon „MyiPhone“ einen Hotspot aufgemacht, als Zugangsdaten dann aber „MyIPhone“ eingetragen. Das klappt dann nicht. Vergleich der SSIDs sollte Case-Insensitive sein?
- Log ist jetzt schon sehr ausführlich & hilfreich. Die WLAN Liste ist bereits sortiert nach besten Netz. Die Auflistung beginnt bei 1, „Trying WIFI candidate“ beginnt aber bei 0. Hier auch bei 1 anfangen?
- Kennwörter sollten in keinem Fall im Log oder anderswo erscheinen!
- Für die Web-UI gibt es jetzt „/savedSSIDs“, das ist für die bereits gespeicherten/bekannten Netze? Schön wäre eine Funktion für die Liste der verfügbaren WLANs (evt. mit weiteren Eigenschaften RSSI, un-/gesichert usw.), dann könnten wir eine Aufklappliste für den WLAN-Namen bereitstellen.
4 „Gefällt mir“
Erstmal danke für’s testen und das Feedback. Du hast einige sinnvolle Punkte genannt auf die ich näher eingehen will.
Zur Verzögerung:
In meinen Augen erschien mir der Start schnell genug, vor allem weil er vorher auch teilweise länger gedauert hat. Ich überleg mir aber noch was dazu; das letzte bekannte WiFi sollte machbar sein, auch wenn das dann vielleicht nicht das stärkste ist.
Asynchron:
Die Suche ist asynchron und das Ergebnis (oder ob der scan läuft) wird in der state-machine in wlan_cyclic abgefragt. Von daher sollte ich den Scan „anstoßen“, versuchen zu verbinden und dann auf das Scan-Ergebnis warten können.
Case-Sensitive:
Grundsätzlich sin WiFi-SSIDs schon case-sensitive. Würde das daher auch dabei belassen. Verhält sich die Wifi-lib da anders?
Logging:
Logging ist definitiv noch Entwicklung. Ich hab’s zum einfacheren testen noch drin gelassen, aber da kommt auf jeden Fall noch viel raus. Torsten hat sich auch schon beschwert. Ich verwende auch noch viel Serial.print, hab aber auch nicht wirklich Lust allzu viele Strings mit Übersetzung zu schreiben, daher wird es weniger verbos werden.
Die Netze sind glücklicherweise von der Wifi-lib schon perfekt sortiert. Das könnte sich nur leider irgendwann ändern.
Scan-Ergebnis in Web-Ui:
Das ist schon ein sinnvoller Schritt, aber erstmal komplett unabhängig vom managen mehrere Netzwerke.
Auch hab ich hier noch keine wirklich gute Lösung. Der Scan dauert seine Zeit, und so lang kann ich schlecht im Webserver warten. Wäre dann vermutlich was für Websocket.
Ich habe mich heute ein wenig mit dem Frontend befasst. Dazu gehört auch eine Generierung von List-Items mittels JavaScript. Bis auf den Dateiexplorer ist ja alles ziemlich statisch, daher ist das in der Art neu.
Aber würde in gleicher weise für die Anzeige des Scans benötigt werden.
Mir erscheint gefühlt der Start leider nicht schnell genug :
Warum sollte man versuchen sich mit dem stärksten WLAN verbinden? Normalerweise hat man genau ein WLAN zur Verfügung & mit dem verbindet man sich dann. Wenn man bei Opa ist dann schlägt die Verbindung fehl, der Scan wird ausgeführt und das bereits bekannte Opa-WLAN wird dann genommen. Verzögerung gibt es dann genau einmal beim Ortswechsel. Ich denke eine Änderung der Reihenfolge würde es schon lösen…
Case-Sensitive:
Grundsätzlich sin WiFi-SSIDs schon case-sensitive. Würde das daher auch dabei belassen. Verhält sich die Wifi-lib da anders?
Ich hatte genau diesen Groß-/Kleinschreibungsfehler und habe 15 Minuten nach dem Problem gesucht. Fürchte es geht dann weiteren Anwendern genauso. Oder man macht eine Aufklappliste, dann tritt das Problem nicht auf. Habe noch nie zwei WLAN’s gesehen die sich nur in Groß-/Kleinschreibung unterscheiden.
Logging:
Logging ist definitiv noch Entwicklung.
Ja habe ich auch so herausgelesen. Die Vorschläge sind ja nur kosmetischer Natur 
Scan-Ergebnis in Web-Ui
Das kann mann dann sicher auch im nächsten Schritt machen, da gibt es dann noch feine Möglichkeiten.
P.S.:
Mein WLAN heißt übrigens „MyWLAN“. Letztens hatte ich in der Liste einen Nachbarn „nicht_DEIN_WLAN!“.
Sehr schön ist aber auch „Martin Router King“
4 „Gefällt mir“
Ich freue mich sehr, dass das Thema bearbeitet wird (ich bin ja auch einer der diesen Wunsch geäußert hat). Meine Testumgebung habe ich leider nicht hier. Ich teste das nächste Woche.
Das wäre dann schon der 2. Punkt auf der Featureliste.
Nein, das verstehst du falsch. Er checkt in der Reihenfolge ob er das Netz kennt. Mit unbekannten Netzwerken gibt es nie Verbindungsversuche! Der Scan dauert wirklich mindestens 1.6 Sekunden, und da habe ich die Einstellungen schon bestmöglichst angepasst.
Ich hab die Spezifikation nicht gemacht, aber SSIDs sind eben case-sensitive.
Wenn die Großschreibung so ein Problem ist kann man das ja später noch ändern, aber die elegantere Lösung wäre sicherlich scan+Auswahl.
Ich möchte gar nicht auf den Details rumreiten sondern nur den normalen Start so schnell wie bisher beibehalten. Also zunächst mit den letzten bekannten Ziugangsdaten eine Verbindung herstellen.
Das geht dann schnell (bei mir < 1 Sek.). Wenn die Verbindung dann nicht hergestellt werden kann dann über einen Scan mit weiteren evt. bekannten Netzen.
Das wurde hier Anfangs auch schon eingeworfen:
lso technisch ist das natürlich kein Problem und ich habe die Anfrage auch schon mehrfach bekommen. Die Frage ist allerdings an dieser Stelle, ob der zeitliche Faktor nervig wird. Weil du musst ja dann durch mehrere WLANs iterieren in der Hoffnung, dass du was findest, das funktioniert.
Und ich empfinde jetzt den Zeitfaktor leider als nervig. Case-Insensitive Suche ist da Nebensache.Könnte man auch mit 2 Durchgängen lösen, 1. Case-Sensitive → Nichts gefunden → 2. Case-Insensitive
@SZenglein Trotzdem ist Dein Entwurf ein Gewinn wenn sich das lösen lässt!
1 „Gefällt mir“