@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 
1 „Gefällt mir“
Ja, daher hab ich auch geschrieben „best-effort“. Es ist schwierig, vor allem bei so einem kleinen Projekt, dass jeder gleich formatiert. Um einen einheitlichen Stil zu gewährleisten, muss der Maintainer (du) eigentlich alle PRs ablehnen, bis der Stil passt.
Das ist natürlich ein riesen Aufwand. Daher ist es Sinnvoll, die Formatierung automatisiert zu validieren. Die .editorconfig ist dafür ein erster Schritt, aber auch nicht das Ende.
1 „Gefällt mir“
Ja genau, ich hatte vor einiger Zeit eine .editorconfig eingefügt, aber die sprachspezifischen Anpassungsmöglichkeiten sind recht begrenzt. Man kann so generelle Textverarbeitungsrichtlinien durchsetzen wie z.B. eine Leerzeile am Ende einer Datei, keine Leerzeichen am Ende einer Zeile, ob Tabs oder Leerzeichen verwendet werden sollen, etc. Ich habe die Einstellungen der EditorConfig-Datei auch nicht auf alle Dateien angewendet, sondern nur auf die C++ Dateien.
Dinge, die die Programmiersprache betreffen lassen sich meines Wissens nach nicht mit EditorConfig einstellen (z.B. das Setzen von Klammern, das Einrücken von Makros, etc.). Sowas müsste man einfach in einem Styleguide vorgeben und konsequent bei neuen PRs überprüfen und entsprechend vor dem Mergen durchsetzen (sollte mit entsprechend ausgeklügelten Github Actions automatisierbar sein).
Eigentlich hatte ich geplant die von dir oben genannten Regeln so beim Refactoring nach und nach umzusetzen, aber meine (vllt. etwas großkotzig angekündigten) Refactoringpläne wurden durch Nebenjob, Studium und Familie leider stark ausgebremst.
3 „Gefällt mir“
Hi, melde mich hier auch noch kurz zu Wort mit zwei Punkten. Können wir bei bedarf gene auch in separate Topics verschieben:
- sollen wie die editorconfig entsprechend geradeziehen und gleichzeitig den Auto-Formater genrell aktivieren? Wir könnten den den einmalig über alles laufen lassen und anschließend sollte es dadurch zu keinen weiteren Format-Konflikten und Wildwuchs kommen…
- Vermutlich sinnvoll in einem separaten Thema, da es hier aber auch schon um die Accesspoint-Seite ging: könnten wir im Hotspot-Modus auch über einen Reiter / Link die vollständige WebUI anbieten oder sind hier andere Faktoren limitierend? Könnte für lange Autofahrten oder Urlaub in Hotspot-Netzen sehr praktisch sein…
Aber wirklich cooles Feature mit den mehreren WLANs!
Im Hotspot-Modus ist auf der Website das Einbinden von externen Ressourcen limitierend: Es werden Bootstrap und jQuery nachgeladen.
Meiner Meinung nach ein guter Punkt für die Roadmap, die Web-UI als ein Bundle komplett auf dem ESP abzulegen. Aber das ist viel Arbeit und bisherige Versuche dazu hängen ein bisschen im Limbo.
Darüber bin ich schon gestolpert, als ich die Listenansicht der WiFis im AP implementieren wollte: das ist ohne Bootstrap o.ä. viel umständlicher als die fertigen Elemente zu verwenden.
1 „Gefällt mir“
Hallo @SZenglein , @tueddy , @Joe91 (ich hoffe ich habe keinen vergessen)
Ich habe schon länger die Idee Wlan grundsätzlich nicht zu aktivieren. Das ist bei meinen 3 Boxen in Toronto und Kopenhagen schon so. Wenn es jemand benutzt dann ist es Opa. Die Tastenfunktion für WLAN ist nicht eingerichtet und somit ist es nur per Karte möglich Wlan zu aktivieren. Ich hoffe die Karten sind im „Tresor“, ansonsten habe ich noch fertige für den Notfall hier in Deutschland.
Nun hier mein Anliegen:
Wäre es möglich Wlan während des Reboot , für ca. 5-10 Sekunden, mittels TastenKombi zu aktivieren ( CMD_WIFI_ON) und zusätzlich immer mit jeder Radiokarte? Dann beim nächsten Reboot aber wieder auf aus. Ähnliches gibt es schon mit CMD_ENABLE_FTP_SERVER während der ersten 60 Sekunden
Das würde das Handling deutlich vereinfachen , auch wenn mal eine Karte weg ist.
Damit wäre auch dieser Wunsch erledigt.
Das müsste mittels #define als Leistungsmerkmal einrichtbar sein.
Die Idee habe ich schon länger , kann es aber selbst nicht umsetzen weil meine Kenntnisse dazu nicht reichen. und jetzt habt ihr auch wieder alles umgeändert.
Ich gehe davon aus das dies für euch ein Klacks ist , wenn ich sehe was ihr alles in so kurzer Zeit programmiert habt. Danke dafür und Hut ab.
VG
Hy @compactflash ich hatte da eher andere Karten im Sinn. Stopp nach dem Titel und LEDs dimmen. Ich denke aber über den Acesspoint im Handy ist die Weboberfläche auch erreichbar. Somit gibt es für meinen usecase einen workaround
Das Feature „Zugangsdaten mehrerer Wlans speichern“ ist ab sofort im DEV-Zweig verfügbar.
Vielen Dank an @SZenglein für Deine Arbeit!
4 „Gefällt mir“
Ja, die Funktion schaut sehr gut aus. Muss ich bei Zeiten testen und dann in meine Boxen einbauen. Macht das Leben einfacher wenn wir dann auf Urlaub fahren .
Bei der Durchsicht ist mir aber die Frage mit der Warnung ins Auge gesprungen.
Diese ist wichtig, memmove funktioniert nur mit POD und TriviallyCopyable Objekten. Bei allen anderen darf memmove (und memcpy) nicht verwendet werden. Das kann bei komplexen Klassen (die zB shared_pointer verwenden) zu Fehlern führen!
Komplexe Klassen haben zB dem X operator= (const X&) überschrieben und führen bei der Zuweisung (bzw wenn die zerstört werden) Aktionen durch. Diese werden nicht aufgerufen, wenn die Klasse byteweise durch memmove (oder memcpy) verschoben wird. Damit muss ein „move“ über diesen Operator gehen.
Bei einem C-Array geht es mit einer Schleife:
for(size_t j=knownNetworks+i;j<numKnownNetworks-1;j++) {
knownNetworks[j] = knownNetworks[j+1];
}
oder mit c++ für schreibfaule 
// std::copy(begin, end, dest_begin)
std::copy(&knownNetworks[i+1], &knownNetworks[numKnownNetworks], &knownNetworks[i]);
was überlicherweise dann hierzu führt:
for (; first != last; (void)++first, (void)++d_first)
*d_first = *first;
3 „Gefällt mir“
Du meinst diese (neue) Compiler Warnmeldung?
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 {
^~~~~~~~~~~~
und der eleganteste Fix wäre:
std::copy(&knownNetworks[i+1], &knownNetworks[numKnownNetworks], &knownNetworks[i]);
Die Warnung wäre damit jedenfalls weg. Richtig so?
Ja genau die Warnung.
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)
1 „Gefällt mir“
Der std::copy Codeschnipsel funktioniert bei mir.
Gut, dass du es ansprichst.
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?