dies ist ein Thema, dass ich mit besonderem Interesse lese; - auch wenn ich vermutlich nichts dazu beitragen kann. Dazu bin ich zu sehr „Anfänger“.
Mein Hintergrund:
aktuell habe ich noch keinen Arduino Nano ESP32. Kann also momentan die recht interessanten Ideen hier nicht „live“ miterleben. Deswegen bitte ich um Entschuldigung, wenn der ein oder andere Gedankenansatz von mir noch „unausgegoren“ oder „rüpelhaft“ wirkt.
Eingestiegen bin ich mit dem ToUINO ganz rudimentär mit dem Arduino Nano. Danach habe ich gesehen, dass es auch eine Variante mit dem ESP32 unter ESPuino gibt und habe daraufhin in beiden Foren reingeschnuppert.
Fazit für mich: Beide haben Ihre Berechtigung. Den TonUINO habe ich nun für meinen Enkel im Einsatz; - den ESPuino eher für mich (das mit BL für Podcasts oder Spotify, Webradio, WebGUi ist halt eher wenig für einen einjährigen).
Nun meine Fragen:
Sehe ich das richtig, dass man in dieser ESP32 Nano Variante einfach den „normalen“ Arduino Nano rausnehmen kann und den Arduino Nano ESP32 „reindrückt“ bei gleichzeitig richtig hochgeladener Version aus Github (siehe @Boerge1 Version 3.3.0) und angepassten Defines?
Warum gibt es eigentlich dann eine Arduino Nano ESP32 Variante, wenn das in dem anderen Forum auf ESP32 Basis schon ziemlich abgefrühstückt wurde? Also; - was sind die Wesentlichen Ängerungen zwischen den Beiden?
Hoffentlich trete ich jetzt niemanden auf die Füße. War nicht meine Absicht. Wollte nur doppelt gemoppelte Zeiteinsätze von mir reduzieren / verhindern.
Prinzipiell ist es schon so, wie du schreibst. Man nimmt anstelle des Arduino nano den ESP32 nano. Das gute ist, dass alles hardwaremäßig auf der gleichen Plattform laufen kann. Z.B. auf der Tonuino Platine von Thorsten, oder auf Eigenentwicklungen, wie z.B. meine Trägerplatine. Dadurch hat man den Vorteil, dass man je nach Funktionsumfang den höheren Bedarf an Programmspeicher durch Auswahl des jeweiligen Boards problemlos abdecken kann. Dabei bleiben die Grundfunktionen bei allen Varianten gleich.
Tatsächlich hat der ESPuino hier seine Ursprünge [1][2]
Was für mich den TonUINO ausmacht ist letztendlich immer noch @Thorstens Grundidee
Ja, inzwischen gibt es einige #defines im Code. Bevor jeder selbst die Anpassungen für die Eigenheiten der unterschiedlichen DFPlayer-Chips vornehmen muss, ist ein #define nunmal doch die einfachere Wahl.
Und die Einfachheit in der Bedienung macht ihn für mich, wie für dich, gerade für Kleinkinder so geeignet. Wenn das Kind älter ist und lesen kann werden vermutlich ohnehin andere Geräte zum abspielen von Musik und Hörbüchern verwendet.
Das Webinterface kommt hier ja nicht als einzige Bedienungsmöglichkeit, sondern als zusätzliche Option, wie die Option für Fernbedienungen auch. Ich kann aber immer noch eine Karte anlernen ohne dass ich irgendwas außer TonUINO und Karte brauche.
Und natürlich schränkt der DFPlayer mit den Bedürfnis nach exakt benannten Dateien ein, dafür bietet er aber zum Beispiel das „advert“ Feature und kann den aktuell laufenden Track unterbrechen, etwas anderes abspielen und dann die Wiedergabe fortsetzen. So sind zum Beispiel der Stopptanz und die Ansage der aktuellen Tracknummer möglich.
Die HW ist bei diesem Projekt viel einfacher und vor allem rückwärtskompatibel. Man braucht nur die Platine von Thorsten, einen DFPlayer, RFID522 und einen Prozessor. Und wenn man einen TonUINO schon hat, kann man ihn mit dem Tausch des Prozessors recht einfach aufpeppen.
Beim EspUINO sind auch einige Konzepte einfach anders (RFID Behandlung, SD-Karte wird vom Esp32 selber behandelt…), da muss jeder selbst entscheiden, was für ihn besser ist.
Den Ersatz vom DFPlayer habe ich aber auch auf die Fahne geschrieben, das mal auszuprobieren.
Habe gerade das Verhalten von Sleep-Timer und Standby-Timer nochmal getestet.
Ich meine sogar, mich dunkel zu erinnern, dass wir das Thema schon hatten (habe aber mit der SuFu nichts finden können).
Test + Ergebnis:
Auf dem Nano ESP32 mit dem Webinterface den Standby-Timer auf NULL gesetzt, den Sleep-Timer auf 1 Minute.
Nach Ablauf des Sleep-Timers geht der TonUINO in „Pause“, der Standby-Timer wird nicht getriggert. Auch nach ca. 10 Minuten ist der TonUINO immer noch im „Pause“ Status.
Die Tasten sind gesperrt (OK), aber erfreulicherweise funktioniert noch der lange Tastendruck auf die Pause-Taste zum Abschalten.
Dennoch finde ich den Vorschlag von @Thomas-Lehnert sehr gut, mit keiner oder nur sehr kurzer „Nachlaufzeit“ den TonUINO vollständig abzuschalten, auch wenn kein Standby-Timer (oder einer mit höherer Zeitangabe) gesetzt sein sollte.
Bemerkung zur Info:
Vor Ostern hatte ich ein äußerst merkwürdiges Verhalten des Sleep-Timers und wollte schon eine Meldung an @Boerge1 geben. Bei Analysen des LOGs ist mir allerdings aufgefallen, dass die Karte auf dem Leser in sehr kurzen Abständen mehrfach geantwortet hat (und damit anscheinend den TonUINO „durcheinander“ gebracht hat.) Dieselben Daten auf eine andere Karte geschrieben und alles funktioniert einwandfrei - also habe ich nichts mehr dazu geschrieben, sondern überlege, wie ich solche Karten in den Beschreibungen zur Fehlersuche einbauen könnte.
Muss Mal was korrigieren. Der Effekt, den ich beschrieben hatte, war durch mich selbst verursacht. Ich hatte in den Settings den Wert für die Grundeinstellung des Standbytimers fest auf 5 min gesetzt, aber nicht mehr dran gedacht. Trotzdem favorisiere ich aber eine direkte Abschaltung, oder Abschaltung mit kurzer Verzögerung nach Ablauf des Sleeptimers.
Habe die Änderung angetestet und finde nicht, dass es zu lange dauert (Player GD3200B).
Bei der Meldung fehlt mir allerdings spontan die Anzahl der Tracks. Nur die Aussage, dass der angegebene Track kleiner oder gleich der Anzahl der Tracks im Ordner sein muss, hilft nicht wirklich, ohne zu wissen, wieviele Tracks enthalten / erkannt sind.
Ich habe kurz auch eine Meldung gesehen, dass der Ordner nicht vorhanden ist. Das war korrekt, aber jetzt kann ich diese Meldung nicht mehr produzieren.
Stattdessen wird versucht (Album), Tracks aus dem nicht vorhandenen Ordner abzuspielen.
Das ergibt allerdings keinen DfPl Error 6, wie ich erwartet hätte, sondern der Play-Befehl wird mit missingOnPlayFinished quittiert und der nächste nicht vorhandene Track wird aufgerufen. Das geht dann im Sekundentakt so weiter.
Mit Angabe gültiger Parameter läuft dann alles wieder ganz normal.
Ich hoffe, dass das keine spezielle „Eigenart“ des GD3200B Chips ist
Ja, das ist es. Diese DFPlayer muss erst überredet werde, bevor man getFolderTrackCount() aufrufen kann. Der ignoriert nämlich den Folder-Parameter und man muss erst einen Track im Folder anspielen, dann kann man die Funktion aufrufen. Wenn nun der Folder gar nicht existiert, läuft das auf zwei Timeout hinaus und das bringt den Player wahrscheinlich durcheinander.
Ich werde das Feature dann optional machen.
Ist es wirklich ein weiteres define wert, wenn nur der GD
betroffen ist. Bei existierenden Foldern funktioniert der Plausi-Check doch ganz gut. Das (Fehl-)Verhalten bei den Foldern doch gut erklärbar (und damit aus meiner Sicht akzeptabel).
Wenn es sein muss könnte man das doch auch gleich mit dem Player-define verknuüpfen, oder?
In Kūrze werde ich noch einen LKP und einen 24SS aufstecken und testen / berichten:
Edit:
Dank OTA schnell erledigt.
MH2024K24SS reagiert, wie erwartet / bekannt etwas langsamer. Der Plausi-Check für Folder und Tracks funktioniert einwandfrei.
LKP-Player reagiert zügig, wie gewohnt. Der Plausi-Check für Folder und Tracks funktioniert einwandfrei.
Zu dem Player GD3200: Ich habe das nochmal genauer angeschaut und nachgetestet:
Es ist unmöglich eine vernünftige Antwort auf getFolderTrackCount() zu bekommen, wenn der Folder nicht existiert. Das ist ja auch kein Wunder, da ja erst ein Track aus dem Folder angespielt werden muss und das geht ja schief. Man bekommt da aber auch keine vernünftigen Fehler (z.B. Error 6).
Also mache ich den Check dann doch nicht optional.
Modifier SleepTimer: Nach Ablauf wird direkt Shutdown aufgerufen.
Kleiner Bug in getFolderTrackCount() behoben wenn beim Player GD3200 danach doch nichts gespielt wird (z.B. falscher Track, dann wurde der erste (angespielte) Track einfach nicht gestoppt)
Beim Parameter Check wird jetzt die Anzahl der Tracks im Folder mit ausgegeben.
So ist die Angabe nun sehr gut verständlich und man kann die Eingabe entsprechend korrigieren
Schaltet wie vorgesehen nach Ablauf des Timers ab, in der Statusanzeige bleibt aber „Standby: 4:59 Min. übrig“ stehen. Schöner wäre wenn einfach „Shut off“ angezeigt würde. Ist das machbar?
Ist erledigt. Als Status kommt „Ausgeschaltet“, egal wie er ausgeschaltet wurde (Standby, SleepTimer, Pause-Lang oder Ausschaltknopf im Webinterface)
Weitere Änderungen:
Der NeoPixelRing wird jetzt auch beim Ausschaltknopf im Webinterface ausgeschaltet
Wenn man auf der Startseite Buttons drückt, kommt ein „Wait“ Indikator (Cursor und Button) bis eine Antwort kommt. Wenn man z.B. einen falschen Folder angibt, kann es ja etwas länger dauern.
Ja, klasse
So hat man nun im Webinterface den korrekten Status, wenn der TonUINO durch SW abgeschaltet wurde.
Obwohl nun rundum zufrieden mit dem Webinterface stellte sich mir bei den Tests (während der Wartezeiten) folgende Frage:
Wird es für das Webinterface eine leicht austauschbare (editierbare) Sprachdatei geben?
Schießlich wird bei den Audio-Ansagen ja auch englisch und französisch angeboten.
Sprachversionen sind für meine Anwendungsfälle zwar nicht wichtig (und werden wohl auch nur von einer Minderheit der TonUINO User verwendet), aber wenn so etwas beabsichtigt ist, muss es vermutlich frühzeitig in der Variablen- und Programmstruktur angelegt werden.
Obwohl alles prima läuft sind, in Zusammenhang mit dem Sleep-Timer, Dinge aufgefallen / Wünsche entstanden:
In bisherigen Programmversionen wurden die Tasten Vor und Zurück mit Ablauf des Sleep-Timers gesperrt, um Verlängerungen zu verhindern, solange der Stanby-Timer lief.
Das ist jetzt nicht mehr nötig, da der TonUINO ja direkt durch den Sleep-Timer in Standby (ab-)geschaltet wird.
Bei der Variante „Track wird zu Ende gespielt“ bleiben die Tasten in Funktion.
Damit lässt sich dann mit der Zurück-Taste der vorherige Track in der Queue, oder der aktuelle Track von Beginn an starten. Die Vor-Taste hingegen führt m.M. nach fälschlich zum sofortigen Abschalten des TonUINO
Mir erscheint es sinnvoll, die Vor- / Zurück-Tasten mit Ablauf des Sleep-Timers für die verbleibende „Nachlaufzeit“ des Tracks zu deaktivieren.
Ich habe auch schon daran gedacht, dass die Vor- und Zurück-Tasten grundsätzlich deaktiviert sein könnten sobald der Sleep-Timer läuft.
Ich meine, dass die Vor/Zurück tasten bei laufendem Sleeptimers funktionieren sollten. Wenn die Option „Track zuende spielen“ aktiv ist, finde ich es auch sinnvoll, dass beim letzten Track, also in der Nachlaufzeit, die Tasten gesperrt werden.
