Schon vielfach haben wir hier diskutiert, dass es praktisch wäre, wenn man nur noch ein Webinterface hätte (statt access und mgmt) und man die Files (Js, CSS), die man von CDNs holt, lokal ausliefern würde (vom ESP32 selbst).
Die lokale Auslieferung war mit Claude relativ einfach umzusetzen. Die Änderungen sind gar nicht mal groß - das wird alles mit processHtml.py gemacht. Aber ich weiß ehrlich gesagt nicht, ob das Binary dann auch noch für PSRAM mit 4 MB Flash funktioniert - ich meine es hatte so 3,6 MB nach dem ZIPing. Die Auslieferung hat auf jeden Fall funktioniert und entgegen meiner Befürchtung, dass das mit dem ESP32 nicht klappt ist das alles kein Thema. Muss man nochmal gründlich testen, aber das sieht soweit gut aus.
„Wunderbar“, dachte ich mir, „dann können wir jetzt access und mgmt zusammenführen!“. Dabei bin ich jedoch in ein konzeptionelles Problem gelaufen, von dem ich nicht weiß, wie wir das lösen wollen. Und zwar: Kann ESPuino keinem WLAN beitreten, so spannt es selbst einen AP auf. Um die Erstkonfiguration des WLANs für den Benutzer einfacher zu machen, wird ein Captive Portal angezeigt. Das CP ist aber nichts, was der Browser anzeigt, sondern eine Funktion des Betriebssystems! Dort trägt man die WLAN-Zugangsdaten ein und speichert diese ab. Nach einem Neustart ist ESPuino dann Teil des eigenen WLANs.
Gut, access war entfernt und nur noch mgmt vorhanden. Das hat jetzt dazu geführt, dass ich im Captive Portal eine Fehlermeldung bekommen habe (weiß nicht mehr genau - irgendwas wie Access Point nicht erreichbar). Im Anschluss kam es zu einer Weiterleitung zu unserem Mgmt-Interface. Also im Grunde war ich quasi dort, wo ich bin wollte. Problem jedoch: Über das Fenster des Captive Portals ist das quasi nur ein Guckloch und man kann das Fenster auch nicht größer oder kleiner machen. In den dortigen WLAN-Einstellungen konnte ich dann die Auswahl der verfügbaren WLANs sehen, ich konnte das passende WLAN auswählen und auch speichern. Beim nächsten Start konnte ESPuino dann meinem WLAN beitreten. Also an für sich war es das, was ich wollte, aber von der Usability halt total kacke.
Also im Grunde haben wir hier einen Zielkonflikt. Einerseits möchten wir es den Benutzern mit dem Captive Portal einfacher machen. Andererseits besteht (meine ich?) der Wunsch, bestenfalls nur noch ein Formular zu haben und gleichfalls die Möglichkeit, auch im Urlaub auf das Mgmt-Interface zugreifen zu können.
Was man auf jeden Fall durch die lokale Auslieferung gewinnt: Auch im Access-Interface hätte man schon Zugriff auf die Js-Elemente, die man sonst nur im mgmt-Interface hatte. Vielleicht egal.
Perfekt kann man das glaube ich nicht lösen. Ich vermute mal, dass man Folgendes machen müsste:
- access lässt man weiterhin bestehen - für das Captive Portal. Bisschen aufhübschen könnte man es bei Bedarf.
- Den WLAN-Picker des access-Interface integriert man im Mgmt-Interface ebenfalls in der WLAN-Kladde (oder haben wir das eh schon?).
- Benutzer, die im Urlaub auf ihr Mgmt-Interface zugreifen wollen, müssen das Captive Portal schließen und eine Adresse im Browser manuell aufrufen. Das müsste klappen und die Darstellung einwandfrei sein.
- Die lokale Auslieferung der JS/CSS-Files bleibt bestehen. Das ändert funktionell nichts, hinterlässt bei CDN-Providern aber keine Datenspuren mehr. Und ermöglicht Punkt 3.
Meinungen / Kommentare erwünscht.
