Ach ja, ich dachte es wäre „-1“ als SSID. Das konnte ich auch nicht nachvollziehen, aber für den Hostnamen trat das aufgrund eines Fehlers auf.
Wie du schon festgestellt hast, hab ich noch einen relativ kleinen PR erstellt, der einige Verbesserungen enthält. Danke dazu für das gute Feedback von allen!
Neue Runde im DEV-Branch:
Die Bugfixes & Verbesserungen von @SZenglein sind jetzt eingecheckt, Vielen Dank für Deine Arbeit & Mühe!
Beim WLAN-Scan und nach Verbindungsherstellung wird jetzt zus. die BSSID ausgegeben um die noch bestehenden Probleme bei Mesh/Repeater Netzwerken einzugrenzen. Damit kann man bei gleichen WLAN-Namen (SSID) schonmal sehen womit sich der ESPuino eigentlich verbindet.
Scan für verfügbarer Netzwerke:
[ 304798 ] WLAN 'Vodafone-407580'gefunden (Signalstärke: -67 dBm, Kanal: 13, BSSID: 7C:13:1D:68:50:32)
[ 304799 ] WLAN 'EasyBox-919850'gefunden (Signalstärke: -71 dBm, Kanal: 1, BSSID: 74:9D:79:B9:78:8C)
[ 304809 ] WLAN 'WLAN-89XPXA'gefunden (Signalstärke: -71 dBm, Kanal: 1, BSSID: C4:86:E9:43:F5:B8)
[ 304820 ] WLAN 'MyWLAN'gefunden (Signalstärke: -74 dBm, Kanal: 1, BSSID: 98:9B:CB:AB:8B:63)
[ 304830 ] WLAN 'FRITZ!Box 5530 IG'gefunden (Signalstärke: -80 dBm, Kanal: 5, BSSID: 3C:37:12:FB:B5:D5)
Nach Verbindungsherstellung:
[ 1264 ] Verbunden mit WLAN 'MyWLAN' (Signalstärke: -71 dBm, Kanal: 1, BSSID: 98:9B:CB:AB:8B:63)
[ 1264 ] Aktuelle IP: 192.168.178.101
[ 1275 ] Synchronisiere Uhrzeit via NTP...
Ah, das ist sehr cool - danke! Und auch für’s Testen.
Ich habe vorhin den DEV-Branch mal auf ein nagelneues Develboard geflasht und hatte diesmal mit der Anmeldung keine Probleme. Ich habe dann mal den Upload getestet und kam so bei 300 kB/s raus (aber keine Ahnung, ob er sich wirklich mit dem Router verbunden hat.
Was mir auf jeden Fall positiv aufgefallen ist: Der Batch-Upload funktioniert einwandfrei. Also im Master-Branch hatte ich beim Upload von mehreren Dateien immer wieder Probleme, dass. der Upload abgebrochen ist. Das scheint ihr jetzt nachhaltig gefixt zu haben 
.
Habe gerade bei mir Stabilitätsprobleme beim FTP upload von vielen Dateien auf dem aktuellen dev-Branch festgestellt. Werde das noch näher anschauen, falls jemand den ebenfalls ab und zu verwendet hier nur kurz die Info.
Dafür funktioniert der Web-Upload mittlerweile wirklich super zuverlässig.
Gerade hatte ich noch folgende Exception beim Bootup:
[ 2238 ] WLAN 'HZN247115178'gefunden (Signalstärke: -91 dBm, Kanal: 13, BSSID: 1C:3A:DE:89:4D:E8)
Guru Meditation Error: Core 1 panic'ed (Cache disabled but cached memory region accessed).
Core 1 register dump:
PC : 0x4025e2fc PS : 0x00060035 A0 : 0x400874e4 A1 : 0x3ffbf74c
A2 : 0x00000000 A3 : 0x3ff56000 A4 : 0x01000000 A5 : 0x3ffc4dd8
A6 : 0x00000018 A7 : 0x3ffbe27c A8 : 0x80081a1d A9 : 0x8486325c
A10 : 0x3ffc50c8 A11 : 0x00000001 A12 : 0x800850c0 A13 : 0x3ffb7a70
A14 : 0x3ffc8ec0 A15 : 0x84800044 SAR : 0x00000018 EXCCAUSE: 0x00000007
EXCVADDR: 0x00000000 LBEG : 0x4009383c LEND : 0x40093847 LCOUNT : 0xffffffff
Backtrace: 0x4025e2f9:0x3ffbf74c |<-CORRUPTED
#0 0x4025e2f9:0x3ffbf74c in hsv2rgb_rainbow(CHSV const&, CRGB&) at .pio/libdeps/lolin_d32_pro_sdmmc_pe/FastLED/src/hsv2rgb.cpp:445
ELF file SHA256: d7ff8097a78175bb
E (2571) esp_core_dump_flash: Core dump flash config is corrupted! CRC=0x7bd5c66f instead of 0x0
Rebooting...
@laszloh könnte das eventuell was mit dem immer wieder beschriebenen Problem der kommischen Reboots zu tun haben?
FastLED ist erschienen in Version 3.6.0. U.a. aus den Release-Notes:
* Greatly improved support for ESP32 and ESP8266
Die neue Version ist jetzt im Master & DEV-Branch verfügbar.Außerdem ist das PlatformIO-Package aktualisiert Version 6.3.1. Ob das den Absturz beim FTP-Upload behebt? Der ganze FTP-Teil wird etwas stiefmütterlich behandelt weil der HTTP-Upload schneller & stabiler läuft. Da ist sicher noch Luft nach oben…
Ah vielen Dank. Werde ich nachher wenn ich wieder zu Hause bin gleich aufspielen. War nur sporadisch, ich werde aber versuchen ob ich es nochmal mit der neuen Fast-Led-Version beobachten kann…
Ich würde jetzt als Nächstes ein wenig Aufräumen, den Support für Arduino 1.0.6 & Playlist-Cache entfernen.
Arduino 2 läuft stabil & 1.0.6 kompiliert nicht mehr durch den neuen C++17 Compiler. Der Playlist Cache brachte den Turbo ist jetzt aber durch das verbesserte Dateisystem überflüssig & bringt keine Vorteile mehr.
Gibt es noch Meinungen dazu?
Das ist in Ordnung für mich
Dieser PR bringt keine Neuigkeiten sondern räumt ein wenig auf,
es werden ca. 240 jetzt überflüssige Codezeilen entfernt:
Bitte Rückmeldung hier ob Alles soweit passt 
Sieht gut aus und läuft erstmal ohne Auffälligkeiten. Wenn noch was auffällt melde ich mich 
.
Update:
Gerade kam ziemlich unvermittelt eine Exception mitten im Abspielen eines Liedes:
[ 490210 ] info : VBR recognized, audioFileDuration is estimated
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
E (613672) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (613672) task_wdt: - async_tcp (CPU 1)
E (613672) task_wdt: Tasks currently running:
E (613672) task_wdt: CPU 0: IDLE
E (613672) task_wdt: CPU 1: IDLE
E (613672) task_wdt: Aborting.
abort() was called at PC 0x401319e8 on core 0
Backtrace: 0x400847b5:0x3ffbee5c |<-CORRUPTED
#0 0x400847b5:0x3ffbee5c in panic_abort at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/esp_system/panic.c:408
ELF file SHA256: 4b88666cba59c608
E (11849) esp_core_dump_flash: Core dump flash config is corrupted! CRC=0x7bd5c66f instead of 0x0
Rebooting...
Selten was so nichtssagendes gesehen ^^. Ist bis jetzt allerdings erst einmal aufgetreten.
Lag evenutell auch daran, dass ich verschiedene Dateien auf der SD-Karte gelöscht habe, während abgespielt wurde. Konnte es nicht nochmal nachstellen. War vermutlich eher was anderes…
Kommt tatsächlich immer wieder zu komischem Verhalten wenn während dem Abspielen Dateien (eigentlich nicht vom Abspielen Betroffen) gelöscht werden…
Gute Nacht euch allen und einen guten Start in die neue Woche
Ich habe die WLAN-Implementierung, die dafür sorgt, dass der beste AP verwendet wird eben mal getestet: läuft . Was ich ja irgendwie gar nicht verstehe: Unten in meinem Arbeitszimmer teste ich normalerweise und da ist die Fritzbox 7490 auf dem gleich Tisch, auf dem auch der Laptop steht. Ergo: Da reden wir von vielleicht 50 cm Abstand und irgendwie so -49 dB. Da hatte ich im Upload etwa 300 kB/s rum. Ich bin dann mal ins Obergeschoss gegangen und folgerichtig hat sich der ESP32 dann mit dem besseren AP verbunden. RSSI ist hier so -65 dB rum. Ergebnis: 450 kB/s. Jetzt lasse ich gerade nochmal einen Upload mit mehreren Files laufen (ohne Neustart zwischendrin) und habe dann nur noch 250 kB/s. Also mal neu gestartet und jetzt bleibt’s bei 250 kB/s. Also das bleibt irgendwie ein Mysterium.
Vor etwa zwei Jahren hat ein großes Refactoring stattgefunden. Dazu gab’s bis heute eine Warnung. Ich denke zwei Jahre sind mal genug, deswegen habe ich das eben ausgebaut.
@biologist Fein das es bei Dir läuft!
Die Unterschiede in der Uploadrate habe ich ja auch und es wurde mir so erklärt , aber irgendwie ist das auch „magic“
Also bei mir sind beide Repeater per Ethernet angebunden. FB7490 ist im EG, ein Repeater im DG und ein weitere Repeater im Keller. Wobei man den aus dem Keller nach oben eigentlich wenig bis gar nicht empfängt. Von daher geht’s eigentlich nur um den Repeater im DG.
Ich weiß nicht woran es noch liegen könnte. Trotz schlechter Signalstärke: -70 dBm erreiche ich konstant 550 KB/s beim Web-Upload und das schon ganz nett
Weil wir jetzt beim Upload alle nicht benötigten Tasks (LED, Audio & RFID) pausieren ist die Uploadrate reproduzierbar konstant & bietet auch Raum für weitere Verbesserungen. Was fehlt ist das Pausieren von MQTT - weil das läuft noch nicht in einem eigenen Task. Steht an Punkt 5 der Liste geplanter Features. @biologist Auf dieser Liste könntest Du Punkt 1 & 2 als erledigt markieren ? Sicher wird es dazu noch den einen oder anderen kleinere Bugfix geben…
Vielleicht könnte man ja auch markieren, in welchem Branch das jetzt verfügbar ist. Bei „erledigt“ würde ich erwarten, dass das auch im master drin ist.
Moin @moin,
alle geplanten Features beziehen sich auf den DEV-Branch.
Der Master erhält nur Fehlerkorrekturen aber keine neuen Funktionen. Wenn die Zeit reif ist wird die Entwicklerversion zum neuen Master.
Kannst Du wählen was Du möchtest
Dann ist das ein Missverständnis. Ich hatte den Eingangspost so verstanden, dass ein Feature zunächst im DEV-Branch getestet wird und dann in den master kommt.
Für den DEV-Branch ist die Distanz zwischen dem ESPuino und mir zu groß.
Ja, das ist an für sich auch richtig. Aber hier haben wir aktuell ich sage mal den Sonderfall, dass DEV auf Arduino2 läuft während master auf Arduino1 läuft. Da sind diverse Sachen drin, die man so nicht migrieren kann.
Wir werden mittelfristig auf Arduino2 wechseln und dann sind Master + DEV auf dem Stand. Und dann soll es so laufen, wie du vermutet hast.
Die Aussage verstehe ich nicht
Erledigt.
Habe dev dazugeschrieben.