Ok, ich teste das heute Abend auch selbst.
Es fehlt wohl noch die Benachrichtung an die Weboberfläche mit Web_SendWebsocketData(0, 40);
Hi
Was haltet ihr von einem Button für Download im RFID-Menu . Ich denke da vor allem an den Download der backup.txt . Dann ist das auch für Leute die sich mit FTP nicht auskennen einfach machbar.
VG
Ich habe die gemeldeten Probleme lösen können:
- Wechsel zwischen Audio SD-Karte und Webstream aktualisiert Coverbild und Titel
- Es wird jetzt auch ein Dummy-Icon angezeigt wenn kein Albumcover vorhanden ist.
- Im Titel steht jetzt der Stationsname des Webstreams
@compactflash oder auch weitere könnt Ihr den aktuellen Stand nochmal testen?
Hi , funktioniert , der Zeilenumbruch ist noch da .
Mir ist auch zufällig noch etwas aufgefallen . Ich habe einen Ordner abgespielt in dem verschiedene Titel mit unterschiedlichen Covern liegen . Beim Titelwechsel wird kurz das Dummy-Icon abgebildet. Ist nicht störend , wollte es nur anmerken.
VG
@compactflash Danke für’s Testen!
So ganz zufrieden bin ich mit dem Dummy-Icon auch noch nicht. Es springt einfach optisch bei Wechsel von Tracks/Karten. Ohne Icon läuft der Wechsel auf den nächsten Track etwas weicher.
Ansonsten scheint die Erweiterung - also Albumcover anzeigen + Echtzeit-Aktualisierung aller Schalter+Lautstärke ja soweit zu funktionieren.
Ich habe ja primär die andere Richtung (ESP → Webclient) angepasst. Dort werden Websocket-Nachrichten im Format „Command#Item*Value“ verschickt.
Den Rückweg (Webclient → ESP) habe ich auch angepasst, aber es gibt dort das Command „JSON“ wo dann wieder der ursprüngliche Parser genutzt wird. Das habe ich gemacht, um nicht alles sofort ändern zu müssen und ja, ich gebe Dir recht, bei vielen (unterschiedlchen) Daten ist JSON schon sinnvoll. So kann (evtl. vorübergehend) beides genutzt werden. Für Kommandos einfache Text-Strings und für komplexe Settings JSON.
Aber ja, ich hätte auch noch Ideen für das Webinterface…Button-Konfig ist spannend 
Für die Konfiguration der Hardware, sodass es nur eine Firmware + Konfiguration gibt, wäre eine Art Wartungsmodus prima. Dort könnte man die Firmware updaten (falls man mal Dauer-Resets hat), die Settings löschen oder laden und die Hardware konfigurieren. Für die 16MB-Variante wäre das eine tolle Sache. Der Wartungs-Modus würde sich dann über einen HW-Button oder über die normale Weboberfläche erreichen lassen. Der Wartungsmodus sollte dann hardwareunabhängig funktionieren. D.h. es wird keine Peripherie angebunden.
Den Modus könnte man dann Step-by-Step erweitert. Es sollte nur nicht so viel rein, damit er einigermaßen Failsafe ist.
Ich werde mit dem Wartungs-Modus bzgl. Failsafe-Firmware-Update beginnen.
4 „Gefällt mir“
Spricht etwas dagegen die Weboberfläche minified als gzip im Flash abzulegen?
Der Browser versteht ja gzip und man spart etwas Speicher 48KB → 9KB.
Zudem könnte man dann beide Sprachen gleichzeitig ablegen und über „board_build.embed_files“ in der platformio.ini anziehen, um die Auswahl der Sprache zur Laufzeit zu ermöglichen.
Bin ich dran. Allerdings inkl. der JS - Abhängigkeiten. Wird dadurch eher doppelt so groß werden.
Sprachen war mit jQuery.i18n geplant.
Sprachen im „Backend“ / ESP Logging würde ich persönlich gar nicht mehr unterscheiden.
1 „Gefällt mir“
Perfekt 
. Erfahrungsgemäß hat man mit 110k und der ESP32-Netzwerkgeschwindigkeit noch eine gute Benutzererfahrung. Bei 150k und mehr merkt man dann schon deutlich die Verzögerung aufgrund der Geschwindigkeit.
1 „Gefällt mir“
Auslieferung der Webseite als eine einzige GZip Datei sowie Einbindung der externen Bibliotheken hatte ich auch schon überlegt, eleganter Weg um die schlechte Performance des ESP32 Webserver zu kaschieren, aber:
- Die Weboberfläche lädt derzeit schnell und absolut stabil. Das was der Benutzer als Verzögerung empfindet ist evt. das Laden des SD-Karten Verzeichnis…
- Beim Aufruf der Web-UI ist der Anwender zu 99,9% auf gleichzeitig online. Ich wüsste jetzt keinen Fall wo die externen JavaScript Bibliotheken nicht geladen werden können.
Ich sehe da im Moment als Vorteil nur eine kleinere Dateigröße der Firmware Datei. Um das zu erreichen müssten aber zunächst die Template-Processor Variablen durch etwas anderes ersetzt werden, weil sonst ist die HTML nicht mehr statisch. Was sind Eure Meinungen?
Glaubensfrage Es hat beides Vor- und Nachteile.
Ich bin da ja schon recht weit. Ich habe am Wochenende den Code etwas aufgeräumt und werde die Änderungen zeigen. Am Ende kann / muss man dann entscheiden ob und was man davon übernehmen möchte.
Hab’ gerade mal geschaut…aktuell dauert der Download der 110k rd. 300ms. Wie @tuniii ja auch weiter oben schreibt, passt das gerade noch.
Content Download 279.55 ms
Ich werde mal sehen, wie gut die Header If-Modified-Since und Last-Modified in diesem Zusammenhang funktionieren, um den Browser-Cache zu nutzen. Wie Du schreibst, ist die Datei ja statisch und müsste gar nicht immer neu geladen werden…
Ja, stimmt schon. Vorteile hat man im AP-Modus.
Korrekt. Betrifft generell die Kommunikation ESP → Browser, die aufgebohrt werden muss.
Den größten Vorteil hat man im Offline-Modus und somit auch im AP-Modus, allerdings benötigen das wohl die wenigsten, aber wenn mal das Internet ausfällt, dann wäre man vllt. froh wenn es weiterhin funktioniert.
Das mit dem Template-Processor verhindert natürlich aktuell ein komprimiertes Ablegen.
@Christian Durch was hast du den Template-Processor ersetzt? Hast du den Stand schon irgendwo online?
Danke für Eure Anregungen!
Den AP-Modus halte ich jetzt für weniger wichtig, den benutzt man genau einmal 
…Moment…
Die AP-Seite vermittelt den ersten Eindruck vom ESPuino, daher vielleicht doch einen Blick Wert. Man soll ja auch gleich Lust 
bekommen den ESPuino in Betrieb zu nehmen.
Eine GZIP-Auslieferung der Webseite wäre schon fein und schnell - das geht eben nicht wenn die Webseite vorher durch den Template-Processor durchgejagt werden muss. Da könnnte man definitiv ansetzen!
Im aktuellen PR-Request habe ich die Möglichkeit eingebaut die HTML-Seite anstelle der Firmware-Standardseite optional auf der SD-Karte zu hinterlegen. Dazu legt man den Ordner „.html“ an und hinterlegt die Seite als „index.htm“. Grund dafür ist einfacheres Ändern/Debugging: Ich muss nicht jedes Mal die Firmware neu flashen sondern kann das geänderte HTML via FTP schnell hochladen.
Auch eine Individualisierung ist damit möglich: ESPuino bleibt selbstverständlich, aber ich kann so die Oberfläche auf meine Box anpassen ohne die Firmware zu ändern.
Unterstützt wird neben der HTML Seite auch das Logo „/.html/logo.png“ bzw. „/.html/logo.svg“ und das favicon. Das Verzeichnis „.html“ ist im Audiobrowser durch den Punkt ausgeblendet, stört also nicht.
Und dabei bin ich auch prompt auf einen Bug im Template processor gestoßen. Habe das so gelöst. Also auch daher Template-processor entfernen und durch Laufzeit-Variablen ersetzen z.B. über JSON Websocket oder GET-Methode? Würde mich jetzt auch interessieren wie @Christian das umgesetzt hat.
Ich räume gerade noch ein wenig auf. Bin halt noch nicht fertig, aber würde den Stand dann schon einmal in meinem Github hochladen.
Ersetzt habe ich das durch eine (oder mehrere) Websocket-Nachrichten:
=>> WebSocket Message: psid#ftpUser*esp32|ftpPwd*esp32|initBrightness*16|nightBrightness*2|inactivityTime*10|
In dieser Form kommt auch der Verzeichnisbaum. Ursprünglich ging es mal darum, eine große JSON Nachricht (Heap) durch mehrere kleine Websocket Nachrichten zu ersetzen.
Apropos AP-Modus. Der ist doch auch an wenn man nicht daheim ist, richtig? Finde das irgendwie nicht so toll wenn theoretisch jeder auf den ESPuino zugreifen kann. Hat sich mal jemand Gedanken darüber gemacht, wie man den AP nur bei der Ersteinrichtung einschalten kann ohne komplett den Zugang zu verlieren? Eventuell per Tastenkombi aktivieren?
Passt nicht ganz, aber vielleicht ergibt sich ja etwas beim überarbeiten der Weboberfläche.
@Christian veröffentlichle das doch bitte lieber früher als später. Ich habe da jetzt so ein wenig Bedenken wenn es bei der Kommunikation um ein propritäres Protokoll geht. JSON ist der Standard, hat geringes Overhead und lässt sich wunderbar im Browser debuggen, Heap Probleme habe ich noch nicht bekommen…
Ein sehr gute Idee 
.
Finde ich auch nicht so toll.
Eigentlich bräuchte man auch keine extra AP-Seite mehr, wenn das ganze Frontend im Flash liegt. Man könnte einen Wifi-Tab zur Einrichtung einführen und im AP Modus auch alle Funktionen bis auf Internet-Streams verwenden. Hier ein Beispiel:
Sobald man sich im AP-Modus zu einem WLAN verbunden hat, gibt das Backend die neue IP vom STA-Modus an das Frontend weiter und dieses leitet dann zur neuen IP um.
1 „Gefällt mir“
Ich bin eigentlich auch der Meinung dass JSON bei allen Mängeln schon ausreichen sollte. Aber sollte es dennoch ein spezielles Protokoll sein könnte man auch ProtoBuf in Erwägung ziehen, das ist wenigstens spezifiziert. Ist aber vermutlich extrem viel dev-Overhead
Von Protokoll würde ich nicht sprechen. Es kommen halt keine komplexen Daten, weswegen sich ein CSV Ansatz schnell umsetzen lässt. Man kann das aber sicher auf JSON umstellen. Es ändern sich dann die Trennzeichen
Dabei ging es um grosse Verzeichnisse, weil aktuell das gesamte Verzeichnis auf einmal kommt.