Die Idee hatte ich in einem anderen Projekt gesehen. Dort war aber der Browser auch nur für eine statische Ansicht ausgelegt. Ich habe das Ganze dann mit dem jstree Ansatz von Mario Lukas, dessen Browser ja davor benutzt wurde und mit eigenen Code ergänzt und rausgekommen ist der aktuelle Browser. Er funktioniert aber hat sicherlich noch verbesserungspotential.
@Christian: dein zweiter Ansatz das Ganze in mehrere Teile zu zerstückeln habe ich auch schon länger im Kopf. War mir aber unsicher wie gut das mit dem Websocket funktioniert, da ich da noch keine Erfahrung habe.
Vorteile:
Das würde Speicher sparen.
Der Browser würde reaktiver wirken, da man den Baum schon aufbauen kann, sobald die ersten Daten ankommen.
Es ist dann auch egal wieviele Dateien im Ordner sind, die Anzeige wird dann nicht mehr abgeschnitten sobald der reservierte Speicher voll ist.
Man kommt auch von der HTTP Request/Response Architektur weg. Der AsyncWebserver neigt beim Auflisten/Löschen vieler Daten zu Instabilitäten, da dort ein Watchdog-Trigger anschlägt, wenn die Callback Funktion zu lange braucht.
Man merkt ich wäre von einer solchen Lösung begeistert
Ich auch nicht und bin auch unsicher wie zuverlässig das klappt. Ich würde mich mal an einem „poc“ versuchen. Du würdest dann aber auch eher direkt ins JSTree übertragen?
Hi @tuniii
Ich verwende seit gestern deinen Code und spiele mit OTA . Klappt hervorragend bis auf eine Sache die mir aufgefallen ist . Plattformio legt die firmware.bin im versteckten Ordner .pio ab . Damit findet es mein Browser (Safari) nicht auch wenn " Dateien anzeigen" aktiviert ist und ich kopiere die Datei immer in einen anderen Ordner. Unter Windows geht es . Ich weiß nicht ob das eine Einstellung in Safari ist und vielleicht kann man ja auch in Platformio den Ausgabepfad ändern . Ich habe dazu nichts gefunden . Hast du eine Idee?
VG
Wie eine Katze. Kaum isses woanders schöner, da isser weg Nein, alles gut.
Idee: Es gibt die Möglichkeit, in VSC python-Scripte einzubinden, die zu verschiedenen Zeitpunkten ausgeführt werden: Redirecting...
Hier könntest vermutlich ein POST-Script einfügen, welches nach dem Kompilieren aufgerufen wird. Und im Script verschiebst du dann das File.
@Christian: Zerstückelt zu Übertragen wäre optimal. Der Web-Server beherrscht „chunked response“.
Am besten man benutzt dann auch nur Stack. Letztendlich läuft das im Kontext eines Tasks der AsyncTCP Lib, welcher mit 16K Stack ausgestattet ist.
@compactflash: Wie @biologist schon geschrieben hat, wäre das grundsätzlich möglich. Du kannst aber auch einfach im Finder-Fenster, wenn Safari es geöffnet hat, Shift+Command+Punkt drücken. Damit aktivierst du die Anzeige der versteckten Dateien und Ordner.
Zudem könntest du auch das updateFirmware.py Skript nehmen, falls du öfters die Firmware updaten willst. Einfach in den ESPuino-Ordner und dann das Skript ausführen, z.B.:
Voraussetzung: MDNS muss bei ESPuino kompiliert/aktiviert werden.
Das Skript findet dann selbst den ESPuino und bügelt die neue Firmware drauf. Ich benutze das Skript, um von der Couch aus zu entwickeln .
Tausend Dank @tuniii , ich habe gefühlt Stunden nach der Safari-Funktion gegoogelt und nichts gefunden , der Skript klappt auch , alles ok . So macht es noch mehr Spaß .
VG
Ich hab gestern ein „poc“ zum Thema „zerstückelt“ übertragen umgesetzt. Nur „offline“ mit einem lokalen websocket-server auf dem Notebook aber es funktioniert ganz gut.
Das Frontend fordert per websocket einen Ordner an und das Backend überträgt jede Datei als websocket Nachricht. Hab eine „Start-“ und „Ende-“ Nachricht der Sequenz vorgesehen. Hab es jetzt mal komlett ohne JSON gemacht. Einfach nur als String und parse entsprechend.
Frage mich gerade, in welchem Fork ich das nun mal testweise implementiere…?
Am Besten bei @biologist, da ich in meinem Fork den Code für den Arduino Core 2.0.0-alpha1 anpasse, um den ESP32 S2 zu unterstützen. Das wird dann nicht mehr mit den älteren Cores kompatibel sein.
Für mein Board mit dem S2, welcher weniger SRAM hat, muss ich einiges vom SRAM auf den PSRAM schieben. Für Klassen kann man auch den new Operator überschreiben, sodass, falls vorhanden, PSRAM verwendet wird.
class AudioCustom: public Audio {
public:
void *operator new(size_t size) {
return psramFound() ? ps_malloc(size) : malloc(size);
}
};
Man muss dann nur die Instanz mit new anlegen.
AudioCustom *audio = new AudioCustom();
Gerade bei der Audio-Klasse macht das einiges aus.
@tuniii Sag mal kann es sein, dass mit deinem letzten Fix für PN5180 ein Bug reingekommen ist? Ich habe aktuell das Problem, dass nach dem Auflegen einer Karte die Playlist 2mal generiert wird. War mir bisher nicht aufgefallen, weil ich Webradio gehört habe.
Weil ich bin grade am rumtesten wegen dem Filecaching und wundere mich, dass die Playlist 2mal generiert wird. Hab dann meinen neuen Code entfernt, aber das kommt weiterhin.
EDIT: Habe gerade die Karte mal drauf liegen lassen (das mache ich sonst nicht), dann wird „Neue Karte“ ja am laufenden Band getriggert. Also da fehlt quasi ein Debounce.
Also die von mir angestrebte Funktionsweise ist, dass man eine Karte auflegt (und auch liegen lassen kann) und dann wird das gespielt. Nimmt man sie weg, dann ändert sich daran nichts (wobei es hier eine zweite Meinung gibt, dass dann die Musik ausgehen muss, hehe). Legt man dann die gleiche Karte jedoch wieder auf, dann muss das als neues Event erkannt werden.
So funktioniert auf jeden Fall RC522. PN5180 war einfach nur dahingehend „buggy“, dass ein erneutes Auflegen nicht erkannt wurde. Man musste immer eine andere Karte dazwischen auflegen. Außerhalb eines Tasks hat das interessanterweise aber funktioniert.
Damit erklärt sich auch, warum beim PN5180 die letzte Karte gespeichert wurde und nur eine neue Karte akzeptiert wurde. War also eine Art Workaround, welcher nun entfernt wurde. Müsste man mal überlegen wie man das nachhaltig löst, sodass das Verhalten bei beiden gleich ist.
Wenn eine Karte aufgelegt wird, dann wird ja cardReceived=true gesetzt. Vielleicht reicht es schon, im else-Fall einen Dummy-Wert zu setzen.
Weil dann kann man den Vergleich zwischen neu/alt, den du vorher hattest, drinlassen. Damit würde man eine aufgelegte Karte nicht mehrfach erkennen, aber wenn sich der Wert zwischendrin mal geändert hat (Karte weggenommen) und die Karte dann wieder aufgelegt wurde, müsste ein neuer Event geworfen werden.
Nein, alles gut.
.
