Stereo: Wenn es so einfach ist, würde ich jetzt kein zusätzliches PCB benötigen, das kann man einfach hinbekommen 
OTA: Das wäre natürlich auch elegant.
App: Das kann ich verstehen, war auch mehr ein Gedankenspiel. Mir reicht es eh wenn ich auf dem Handy meiner Frau die Webseite dann als Shortcut auf dem Launcher ablege oder über Home Assistant. Vielleicht findet sich ja irgendwann mal ein Entwickler der ne Progressive Webapp schustert oder ähnliches…
Ja. Die Kopfhörerplatine macht es nicht anders. Die wird einfach auf i2s aufgeschaltet.
Du mußt lediglich auf dem MAX98357-Modul 1 Widerstand anpassen . Dieser eine Widerstand bestimmt ob Mono , Rechts oder Links .
(siehe Datenblatt ) . Habe es nie getestet , aber das ist gut beschrieben .
Zur App für’s Smartphone: wenn ich das richtig sehe, kommuniziert die Weboberfläche durch einen Websocket mit dem Server, richtig? Gibt’s da irgendwo ne Doku welche API der ESPuino bereitstellt?
Prinzipiell interessiert mich das Thema, aber ich mag nicht versprechen dass da was raus kommt. Gibt schon zu viele Freizeitprojekte die unfertig auf Halde liegen… Aber ansehen würde ich es Mal.
Nee. Ich habe zwar zu so ziemlich allem Doku geschrieben, aber dazu noch nicht. Die Schnittstelle kann jetzt auch noch nicht alles, was man dafür benötigen würde. Also das müsste erst erweitert werden.
Wäre auch ein Bluetooth Modus denkbar in dem ein Kopfhörer gekoppelt wird?
Also grundsätzlich senden geht jetzt bereits, nur halt nicht die mp3lib als Quelle. Ich denke wenn man das hinkriegt, dann wird es vermutlich nur auf dem WROVER laufen, da dieser zusätzlich PSRAM besitzt. Aber ob das alles parallel von der Rechenleistung geht kann ich nicht sagen.
Kurz: Vielleicht 
Hi @biologist?
würdest Du für Featurerequest evtl. eine eigene Kategorie anlegen?
Dann würde ich schon mal fleißig Einträge machen 
LG,
Elmar
Sehe gerade gib es schon unter Software 
Ein flexibles Konzept für das Konfigurieren von Buttons wurde von Rockbox, der open source Firmware für MP3-Player, genutzt.
Jedes Gerät hat einmal eine Definition der Hardware, um z.B. zu definieren wie der Play/Pause-Button angesteuert wird.
Dazu kommt eine Keymap, in der den Buttons Aktionen zugewiesen werden. Dabei kann zwischen kurz Drücken, lang Drücken, drücken während anderer Button gedrückt ist, Drückstart und Drückende unterschieden werden. Auch Dreh-Bedienungen wurden damit konfiguriert.
Das ist übrigens alles als C-Code implementiert, sollte also sogar mit einigen Anpassungen so übernehmbar sein.
Informationen zu Tracks/Modifikation etc. zusätzlich oder evtl. ausschließlich auf der Karte speichern:
Im Nachbarforum wurde deine Software ein wenig umgebaut.
https://discourse.voss.earth/t/quino-v1-outdoor/9176
Es geht darum, dass die Informationen, was die Karte machen soll, auf der Karte liegt.
Das wäre klasse, wenn das aus irgendwie gehen würde. Zwar hat man hier die Backup Datei, aber die hilft gerade bei einem Mix der Inhalte nicht weiter, oder wenn man den espuino verschenkt.
Bei uns daheim sind die Geschmäcker auch verschieden, teilweise wollen die Kinder aber auch die gleichen Inhalte.
Bei dem tonUINO habe ich es auch auch ein gemacht, dass ich dem beschenkten einfach einen USB Stick mit Dateien und die fertige Karte mitgegeben habe.
Wenn ich mich recht erinnere, wolltest du @biologist hattest du einen Grund das nicht einzubauen.
Evtl. kann man das aber Konfigurierbar machen, oder eben zweistufig: sind Infos auf der Karte, dann nehme diese, wenn nicht dann nehme die aus dem Speicher?
Dankeschön
Ja, dafür hatte ich natürlich Gründe 
a) Ich halte es generell für unklug, sich auf Daten zu verlassen, die man „aus der Fremde“ bekommt, deren Integrität jedoch für die Erbringung eines Service sehr wichtig sind. Für mich ist das so ein bisschen, als wenn man eine Passwort-Zugangsbeschränkung per Javascript umsetzt. Schönes und aktuelles Beispiel ist für mich das hier: l+f: Prost! Die Kaffee-Flatrate ist da | heise online
Mir ist schon klar, dass der Service eines ESPuino jetzt nicht lebensnotwendig ist, aber ich kann diesem System ganz grundsätzlich einfach nix abgewinnen.
b) Lagert man das auf die Karte aus, so benötigt man die Dateien exakt an der gleichen Stelle auf beiden ESPuinos. Menschen sind jedoch Meister darin, Dinge immer wieder unterschiedlich zu machen (doppelte Leerzeichen, Bindestriche - weiß der Geier). Führt bei der Speicherung auf der Karte zu Problemen. Lernt man dagegen auf beiden System dediziert an, hat man das dieses Problem nicht. Du kannst übrigens aus ESPuino (a) die backup.txt nehmen und sie auf einem Rechner derart editieren, dass nur noch das drin ist, was auf (b) gebraucht wird. Das importierst du auf (b) und dann hast du die Datenbasis auf (b) um diese Einträge „angereichert“ (die bereits bestehenden sind weiterhin da).
c) Ich find’s „witzig“, dass ich auch meine RFID-Tags, die als Zugangsbeschränkungen für die Häuslichkeiten „bei der Arbeit“ dienen, dafür verwenden kann. Warum kann ich das? Ganz einfach: Ich verändere ja auf der Karte nix.
Zweistufiger Mischbetrieb klingt erstmal nicht schlecht, aber dann wird es bestimmt auch Leute geben, die im Laufe der Zeit umstellen. Dann ist aber vielleicht noch Kram auf der Karte gespeichert und dann wundert sich der Benutzer, dass nicht der „Kram“ passiert, der gerade angelernt wurde. D.h. dann brauchst auch wieder eine Behandlung, mit der man Karten einfach nur löschen kann.
Finde es gut das auf die Karten nur lesend zugegriffen wird und hoffe das es auch so bleibt!
Ich verwende zum Abspielen u.A. auch Tonies, wenn hier auf dem Chip etwas verändert würde könnten die auf der Original-Box nicht mehr abgespielt werden! Also bitte keine Schreibzugriffe auf den NFC Chip!
Für Dateien auf der SD-Karte halte ich das für weniger sinnvoll… beim Kopieren der Dateien von der SD-Karte kann man auch einfach das Backup einspielen (notfalls vorher Zeilen bearbeiten).
Für externe Medien, Webradio, NAS, etc. wäre es schon eher interessant.
In dem Fork, in dem das implementiert ist (GitHub - QDaniel/ESPuino: RFID-controlled musicplayer powered by ESP32), ist auch ein Download vorgesehen (falls die Datei noch nicht vorhanden ist).
Man muss auf jeden Fall die Wahl haben.
So langsam wird es echt immer schwieriger alle Anforderungen unter einen Hut zu bekommen.
PS: Der Link zur QUino - V1 - Outdoor ist nicht mehr verfügbar.
EDIT: Link ist verfügbar, wenn man angemeldet ist. Danke @joker
Mal schauen, ob QDaniel bald hier auftaucht.
Der Link ist noch verfügbar, dazu muss man im Forum angemeldet sein. Ich vermute der Eintag wurde zu 3rd Party verschoben. Irgendwie muss man für gefühlt alle Einträge in der Kategorie angemeldet sein.
Danke für die Richtigstellung.
Ich würde auch bevorzugen, keine Daten auf dem Chip abzulegen. Es gibt ja auch keine Garantie, dass dort genug Speicherplatz vorhanden ist. Somit würde man sich ohne Not potentielle Inkompatibilitäten holen.
Nicht nur angemeldet, man benötigt für das TonUINO 3r Party Forum auch mindestens Discourse Trust Level 1.
Hab mich auch hier angemeldet Und auch mein Projekt in Hardware schon vorgestellt.
Ich habe das Problem das ich an die Boxen schlecht wieder rankommen werde (werden im Familienkreis verteilt über verschiedene Orte hinweg). Da die entsprechenden Eltern (meiner Nichten / Neffen) wenig Technik-Affin sind benötige ich eine Möglichkeit Ihnen einfach eine neue Karte oder Figur zukommen zu lassen welche dann funktioniert.
Auch gibt es Geschwister die dann die Karten untereinander tauschen daher ist es sinnvoll eine Möglichkeit zu haben die Daten vom RFID Chip zu lesen.
Es werden von Gerät keine Daten geschrieben. Die Karten werden über eine Android-App erstellt.
Die Daten der Karte werden nur ausgelesen und verwendet wenn keine Zuordnung existiert.
Aktuell unterstützt wird nur der RC522 und Mifare Classic mit min. 512Byte
Sektor 1: Info Daten
Sektor 2-5: Filename / URL / Webstream Adresse
Sektor 0 ist ungenutzt , da viele Systeme diesen für einfach settings verwenden.