Zugangsdaten mehrerer Wlans speichern

  1. Hast du die statische IP-Konfiguration ausgebaut oder übersehe ich die?
  2. 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.
  1. Ich hab möglichst alles kopiert, aber das ist wohl wirklich unter den Tisch gefallen
  2. 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 ::frowning:
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 :wink:

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“ :wink:

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“

Ja, ich hab das schon verstanden, dass man den WiFi-Start im Normalfall kurz halten möchte.

Was mich nur etwas stört, ist dass ich mit dem zweiten Verbindungsversuch und einem Timeout von 3s mindestens 7.5s Verzögerung habe (+ neue Verbindung), sollte das alte WiFi ausfallen.
Aber vermutlich kann man das verkraften, wenn der Wechsel eigentlich selten stattfindet.

1 „Gefällt mir“

So ist es! Geräte sollten hier definitiv nie versuchen irgendwelche potentiell fehlerhaften Benutzereingaben zu korrigieren.

In dicht besiedelten Gebieten kann es schon mal passieren, dass es eine SSID „MeinWLAN“ und eine SSID „MeinWLan“ parallel gibt.

Die Software muss daher die SSID case-sensitive behandeln. Ich denke bisher hat sie das auch gemacht und es gibt m. E. keinen Grund das hier zu ändern.

2 „Gefällt mir“

Danke erstmal für’s Testen @tueddy.
Das deckt sich methodisch letztlich mit dem, was ich vorher (vor der Entwicklung) schon geschrieben hatte: Man sollte einfach das letzte WLAN als Default annehmen und versuchen, sich bevorzugt mit diesem zu befinden.

Auch oder genau weil…

Genau. Das finde ich in Kombination mit dem WLAN-Scan dann wirklich perfekt gelöst:
a) Zuerst annehmen, dass sich nichts geändert hat.
b) Schlägt a fehl, dann geht man in den Scan über.

Falls man jedoch tatsächlich mein, dass Leute ständig hin und herwechseln, könnte man in die settings.h auch noch ein Flag aufnehmen, mit dem man Schritt a direkt überspringen kann. Aber vielleicht ist das dann auch einfach „overdone“.

2 „Gefällt mir“

Ihr seid herzlich dazu eingeladen, die neuste Version zu testen.
Ich habe es jetzt so implementiert, dass zunächst das letzte verbundene Netzwerk versucht wird. Ist das (zwei mal) fehlgeschlagen, wird der Scan gestartet und alle bekannten Netzwerke werden durchprobiert.

Weiterhin hab ich eine grundlegende Weboberfläche implementiert: WiFis anzeigen, löschen und hinzufügen geht. Der hostname muss noch anders geregelt werden, da es nur einen hostname für alle Netzwerke gibt.

Die Web-API habe ich im Gegensatz zur bisherigen Websocket-API an Standard REST orientert:
GET /savedSSIDs: Liste aller gespeicherten Netzwerke abfragen
POST /savedSSIDs + JSON-Body: Neues Netzwerk hinzufügen
DELETE /savedSSIDs/{ssid}: Das angegebene Netzwerk löschen

Ein Problem für das mich noch eure Meinung interessieren würde:
Im Hotspot kann man aktuell nur neue Netzwerke hinzufügen. Sind aber schon 10 gespeichert, schlägt das fehl.
Man könnte dem Nutzer ermöglichen, alte zu löschen indem man das gleiche Interface wie im management anzeigt. Da man bei aktivem AP ohnehin recht einfach den ESPuino übernehmen kann, halte ich das für unproblematisch.
Alternativ kann man auch überlegen, einfach das letzte hinzugefügte pauschal zu löschen.

4 „Gefällt mir“

@SZenglein das sieht gut aus! Hab’s mal rauf & runter getestet & die verschiedenen WLAN’s klappen einwandfrei. Auch die Verbindungsgeschwindigkeit bei bestehenden WLAN ist jetzt einwandfrei.
Daumen hoch :+1:Aus meiner Sicht steht einem Merge in den DEV-Branch nichts im Wege. Kann das noch jemand bestätigen?

Eine Kritik & die ist jetzt wirklich nicht bös gemeint: Die Frontend Umsetzung ist nicht so geil:
Evt. als Aiufklappliste?

Egal, ready to merge

3 „Gefällt mir“

Danke für das Feedback. Freut mich, dass es gefällt.

Der PR ist noch als Draft markiert, und das ist auch so gewollt. Ich will noch etwas aufräumen (z.B. logging) und die UI anpassen, das sind aber Kleinigkeiten.

3 „Gefällt mir“

Ich muss mal ketzerisch fragen: Gehen wir dann jetzt den Weg, dass wir von Websocket nach REST umstellen? Weil das gemischt zu haben ist ja dauerhaft (temp. ok) kein wünschenswerter Zustand.

1 „Gefällt mir“

Gut, dass du es ansprichst. Ich finde, mit HTTP calls kann man vieles sehr viel unkomplizierter und ordentlicher machen, gerade das ändern von Einstellungen etc.

Websocket ist aber wesentlich besser geeignet, wenn es um Heartbeats oder live-Updates wie die Lautstärke geht.

Eine Mischung von Websockets und REST ist alles andere als unüblich. In der Regel werden Websockets verwendet um REST-APIs zu erweitern.
Es gab und gibt ja auch die Endpunkte für restart und info.

3 „Gefällt mir“

@SZenglein Danke für deinen Commit von gestern, jedoch ist mir ehrlich gesagt unklar, warum du jetzt anfängst, einen anderen Code-Style einzuführen.

Ich erwarte mind., dass…
…defines eingerückt werden. Warum das die halbe Welt anders macht als ich ist mir unklar - nicht eingerückt ist das sau unübersichtlich.
…öffnende geschweifte Klammern am Ende der Zeile mit dem Ausdruck, den man klammern will
…zB else if werden in einer Zeile geklammert ( } else if { )
…Leerzeichen zwischen if und runde Klammer gesetzt wird
…ein Leerzeichen vor einer geschweiften Klammer gesetzt wird

Ich habe hier in letzter Zeit einiges an Umbauten akzeptiert und mich offen gezeigt. Aber wir fangen keinen neuen Code-Style an.

1 „Gefällt mir“

Ich bin jetzt durch die ganzen cpp-Files gepfügt und habe die Sachen, die mir aufgefallen sind, angepasst, so dass das einheitlich ist in Sachen Codestyle.

Vor einiger Zeit wurde die .editorconfig ins Projekt eingecheckt.
Da ich am liebsten den auto-formatter anschmeiße, anstatt selbst zu formatieren, hab ich das alles von VS-Code formatieren lasen.

Wenn der style nicht passt, sollte eventuell die editorconfig angepasst werden bzw. generelle Richtlinien für den Style genannt werden. Die editorconfig ist dafur schon eine gute Lösung, finde ich.

Es gibt auch noch ein paar Stellen (spontan fällt mir html ein) wo sich nicht an den Stil gehalten wurde (Leerzeichen statt Tabs).

@bliepp Du hattest das glaube ich eingeführt. Bitte anpassen, was nicht übereinstimmt.

Ja, das ist korrekt.
Ich habe mir das jetzt auch eine Weile angesehen, aber musste jetzt mal intervenieren :slight_smile:

1 „Gefällt mir“