Also ist es eher ein Download in eine Richtung und keine Synchronisation mehrerer Geräte. Ergibt Sinn, ist ja auch einfacher so.
Die einzige Logik, die man dann braucht, ist dann ein Abgleich, was schon geladen wurde und was noch fehlt, richtig?
Viel Erfolg!
Ja, genau. Es geht mir nur darum die Dateien zentral zur Verfügung zu stellen und dass die Kinder dann die RFID-Tags untereinander tauschen können.
Danke 
Die Idee finde ich auch sehr spannend. Hatte bisher eher in Richtung HTTP-Server als Quelle gedacht. Dafür haben wir schon recht viel im Code. Der Ringbuffer könnte verwendet werden. Gibt es schon S3 Libs für den ESP?
Eine fertige Lib habe ich bisher nicht gefunden. Ich sehe aber auch kein Problem die Requests selbst zu bauen. Der ESP muss ja nur wissen, was es gibt und abgleichen. Daher hält es sich ESP-seitig in Grenzen. Die restlichen Befehle werden nicht direkt auf dem ESP benötigt und für den PC gibt es ja viele SDKs und Command Line Tools.
Hello, finde die Idee sehr gut. Mein Ansatz dazu wäre folgender.
Es muss den Verweis zwischen Ordner und Karten id geben diese müsste auf allen Geräten synchronisiert sein dann schaut der der esp beim Aufruf nach ob es den Ordner lokal gibt wenn nicht kann über eine config per ftp https smb oder was auch immer dieser odner lokal kopiert werden dann muss nicht alles auf jedem Gerät verfügbar sein.
Habe aber im Moment noch keinen Espuino am laufen deshalb bin ich noch nicht in der Lage dies zu beurteilen bzw zu helfen.
Lg
Ja ich hatte da mal was erstellt.
Bei mir hatte ich die aber URLs auf die Karten geschrieben.
Aus Kompatibilitätsgründen fange ich beim schreiben immer beim 2ten Cluster an.
Dann ein eigenes Daten-Format. mit einer Version und Typ ,Interner eindeutiger Name und dann eine URL zum Katalogfile.
Im Hintergrund wurde dann das Katalogfile geladen (M3u-File) und dann die Files im Hintergrund auf die SD syncronisiert (ordnername = eindeutiger interner Name ). Durch die direkte zuordnung des ordners konnte die Musik sofort nach dem ersten file oder bei fehlender Internet verbindung abgespielt werden.
Hatte mich gegen die Karten-ID als Ordner entschieden um mehrere gleiche Karten erstellen zu können.
@QDaniel Hast du mit SD_MMC mal eine Geschwindigkeitsmessung gemacht? Würde mich mal interessieren, wie schnell man da runterladen kann. Oder kommt das aufs Gleiche raus, als wenn man via Webtransfer die Daten auf die SD schiebt?
Nein, hatte ich damals nicht. Mir war es nur wichtig das ich eine MP3 ungefähr in max. 4 min runterladen kann. damit die nächste datei fertig ist wenn das ende der aktuellen erreicht ist.
Da ich aber ein m3u format genommen habe konnte ich bei noch nicht vollständiger syncronisation, einfach auf stream umstellen.
Ich finde QDaniels Lösung auf den Karten Links zu M3U-Dateien zu speichern und dann die Audio-Dateien herunterzuladen ziemlich gut.
Perfekt wäre es, wenn man das mit einer Nextcloud oder einem Subsonic-Server nutzen kann, das muss ich mal probieren.
@biologist: ich weiß, du willst nur die IDs der Karten nutzen.
Ein optionales Feature, bei unbekannten IDs auch auf den Inhalt zu achten, finde ich aber gar nicht so schlecht.
EDIT: oder man speichert die Dateien in Verzeichnissen, welche aus der Karten-ID abgeleitet sind. [0]
Dann kann man bei nicht-angelernten Karten dort nach schauen.
Ich persönlich finde, bei einer neuen Karte sollte zuerst beachtet werden, was im NVS steht, danach ob es einen Karten-ID-Ordner gibt und drittens ob auf der Karte eine URL gespeichert ist.
@QDaniel : die eindeutige Ordner-ID bei dir verhindert eine doppelte Belegung von Speicherplatz bei gleichen Karten (mit unterschiedlicher ID) und ermöglicht es, die SD-Karten einfacher manuell zu befüllen, oder?
ja.
bezüglich unbekannten karten , hatte ich sogar die idee, dass man ne „Catalog-URL“ hinterlegen kann und diese mit der Karten-ID befragt wird. Und dann evtl. ein Daten-File zurück bekommt wie es auf der Karte gespeichert werden würde. Die Daten-Files würde ich dann auf der SD cachen. So kann man auch Karten verwenden wo nichts drauf gespeichert werden kann/darf.
Hello, wie ist da der Stand? Würde das auch gerne haben/ machen. Kann da eventuell helfen?
Mein Code ist Hier: Reusable Cards / Trackinfo on Cards · QDaniel/ESPuino@9aed057 · GitHub
Aber ist lange nichts geändert und oder ins refactoring gebracht worden.
Das Datenformat sieht aktuell so aus:
Folgende Werte gibt es für den CardType
Also das ist mir im Moment zu steil …
schreibst du mir dem RFID Reader dann auf die Karten oder machst du das vorher?
was ist der Server dann ? Geholt wird es dann per http Richtig?
Hello, hat das schon jemand am laufen?
ich bin erst jetzt wieder aktiv am Projekt.
Die Karten werden vorher beschrieben. Mach ich über „Mifare Classic Tool“ am Android Handy.
Der Server ist egal da in der payload die vollständige url drin steht.
Super kann ich dir irgendwie helfen?
wobei ich erst Ende August wieder wircklich Zeit haben werde.
LG
Hello,
War lange nicht aktiv und habe das Projekt leider liegen lassen, da ich mit dem 3D Drucker Probleme hatte (funktionieren beide wieder) und mich dann um andere Dinge gekümmert habe. PV Anlage und Smarthome.
Möchte es jetzt aber fertig bauen
Deshalb meine Frage hat sich da etwas getan?
Danke
LG
Ich bin noch neu in dem ganzen Thema, aber eine Cloud Anbindung bei der die Content/Karten Zuordnung extern erfolgt (so das die Karten an mehreren Boxen gleichzeitig funktionieren ohne diese manuell in jeder BOX verwalten zu müssen) steht bei mir auch auf Platz 1 der Wunschliste. Die Lösung von @QDaniel ist sehr generisch, das finde ich erstmal nicht schlecht. Man muss sich halt von Anfangen Gedanken machen, eine URL auf den Tags zu speichern die dann langfristig auch verfügbar ist. Zusätzlich würde ich mir eine Form der Authentifizierung des ESPuino gegenüber dem Server wünschen.
Seitens @biologist und @tueddy gibt es Bedenken bezüglich der Nutzung von anderen Daten die auf dem Tag gespeichert sind als die UID. Gab es diesbezüglich hier schon eine Diskussion (konnte auf die Schnelle keinen entsprechenden Thread finden)? Im aktuellen Code von @QDaniel schreibt der ESPuino ja nicht selbst auf die Karten, sondern liest die Daten nur. Schreiben muss man die Daten selbst mit anderer Hardware. Auf den ersten Blick wüste ich nicht was dagegen spricht.
Mein Ansatz wäre es ein (oder mehrere) Fallback URLs im ESPuino konfigurieren zu können, an die der ESPuino dann unbekannte Tag UIDs schickt. In der minimal Implementierung wäre das vermutlich quasi ein Webradio Stream Request mit der UID in der URL. In einer fortschrittlicheren Implementierung dann aber auch mit lokalem Caching und Authentifizierung.
Serverseitig ist man dann grundsätzlich flexibel.
Für “reparierte” tonieboxen gib es z.B. TeddyCloud (GitHub - toniebox-reverse-engineering/teddycloud: teddyCloud is an open source server replacement for the Boxine Cloud) mit der man wohl custom Tags mit entsprechenden Audiodateien verknüpfen kann. Alternativ dürfte eine UID/Content Verwaltung auch als Plugin für große Media Server Lösungen (Jellyfin/Emby/Plex) möglich sein. Das wäre entsprechend eine Lösung ohne Daten in den Tag schreiben zu müssen (Wobei ich mir das Hinzufügen eines entsprechenden Servers via RFID Tag auch vorstellen könnte).
Ich habe gesagt, dass man beliebige Tags verwenden kann (sofern ESPuino sie unterstützt). D.h. auch Tags, die irgendwo als Zugangskontrolle verwendet werden. Das ist kein Problem, denn wir schreiben nix drauf. Und dabei bleibe ich: ESPuino liest nur IDs von den Karten - weiterer Content befindet sich darauf nicht. Das wird auch so bleiben. Wenn, dann kommt das ins NVS rein und dann braucht man aber auch eine Migrationsroutine. Wer das anders möchte, der muss ESPuino forken. Das ist völlig in Ordnung. Im Forum nebenan haben sie zum Programmieren der Karten teilweise einen ESP32. Das bringt mich zum „Staunen“, wenn man quasi einen Hilfs-Mikrocontroller braucht, der um Längen potenter ist als der eigentlich verwendete, nur um den angedachten Workflow bequem aufrecht zu erhalten (RFIDs beschreiben).
Da muss man sich eine Reihe von Gedanken machen. Was ist wenn…
Also man kann das schon hinkriegen, keine Frage, aber das wird echt viel viel Arbeit mit sich bringen. Wir haben hier grundsätzlich immer so ein bisschen das Problem, dass, abgesehen von einem „harten Kern“, die meisten Leute immer nur eine gewisse Weile hier sind und dann mitunter ein Feature „hier lassen“, was sie gut gebrauchen konnten. Dann ist das in ESPuino integriert und irgendwann kommt irgendwer hier ins Forum und berichtet von Problemen, die in einem Kontext geschehen, an den nie jmd. gedacht hat. Und dann sitzt du (inzwischen hauptsächlich @tueddy) als Maintainer da, musst dir erstmal ein Testsetup bauen und dich mit Features rumschlagen, die du selbst eigentlich gar nicht haben willst.
Und es kommt noch dazu, dass ESPuino inzwischen ein solcher Brocken ist, dass es ohne PSRAM gar nicht mehr geht, weil wir Unmengen an Features haben. Ich habe ehrlich gesagt große Bedenken, das noch weiter so komplex aufzublähen. Irgendwann fliegt das alles auseinander. Bei Arduino1 hatten wir das quasi schon: Da hat die Audiowiedergabe auf unerklärliche Weise geruckelt, selbst wenn nur ein paar Zeilen Code noch eingefügt hat, die mit Audio gar nix zu tun hatten und auch nicht rechenintensiv waren. Warum das passierte haben wir nie rausfinden können. BTW: @QDaniel hat das genannte Feature kürzlich als PR eingereicht und das sind fast 500 Zeilen Code(!)
Ich sage NICHT, dass ich das alles total doof finde und ich kann die Beweggründe auch verstehen. Aber ich halte es dafür, dass es eh nur ein paar Wenige nutzen werden, eigentlich für zu aufwändig und potentiell fehleranfällig. Klar, gedanklich lädt man da einfach nur Kram runter und spielt’s halt ab. Aber da warten Probleme an vielen Stellen und jeder stellt sich das ein bisschen anders vor, wie das zu funktionieren hat. Dass es für Diejenigen gut funktioniert, die es programmieren, da habe ich keinen Zweifel dran - weil die kennen potentielle Schwächen. Aber es werden unbedarfte User kommen und dann wird’s Probleme geben. Wer wird das supporten?
Das ist jetzt kein „Wir machen das auf jeden Fall nicht“ und ich hoffe, dass das nicht zu unfreundlich rüberkommt. Aber ich melde an, dass ich eine Reihe von Problemen sehe und es selbst nicht aktiv supporten möchte.
Torsten hat Recht, es ist zwar immer super, neue Features hinzuzufügen, aber irgendwo muss letztendlich die Grenze gezogen werden und es ist gut, dass du daran denkst.
Andere Herangehensweise: Inzwischen hat @tueddy ja einige Arbeit in eine HTTP-API gesteckt. Diese sollte zumindest im lokalen Netzwerk verwendbar sein.
Wäre also eine externe Verwaltung mehrerer ESPuinos denkbar? Die kann ja dann dafür sorgen, dass auf jedem ESPuino die gleichen Daten liegen und die gleichen Zuweisungen gespeichert sind.
Dabei müsste man eben eine externe Anwendung schreiben die ESPuinos im lokalen Netzwerk findet und programmiert. Das ist dann aber quasi ein ESPuino „Community“ Projekt ohne offiziellen Support.
