Cloud-Anbindung

Gibt es irgendwelche Pläne für eine Cloud-Anbindung, damit man die Musik- und Meta-Daten zwischen verschiedenen ESPuinos synchronisieren kann?

Beispiel: Man hat zwei ESPuinos und zwei Kinder. Ein Kind übergibt seine Karte dem anderen Kind und kann damit auf seinem Gerät die gleiche Musik-Datei mit dieser Karte hören? Wie macht ihr das bisher? Lernt ihr das immer auf beiden Geräten an oder ex- und importiert?

Mir schwebt da aktuell etwas mit AWS bzw. MinIO für On-Premise vor. Die Musik- und Meta-Daten werden zwischen Cloud und SD-Karte synchronisiert. Raucht das Gerät mal ab, dann kann man ganz einfach wieder seine Daten holen.

1 „Gefällt mir“

Also ich habe da bisher keine Pläne, fände es aber spannend zu erfahren, wie schnell man Daten mit sdmmc auf SD speichern kann, wenn man sie parallel runterlädt.

@QDaniel hatte damals sowas (Ähnliches) umgesetzt glaube ich. Da gingen ESPuinos zu Bekannten und er hat ihnen ab und an Karten zukommen lassen, mit denen dann ein Download initiiert wurde. Weiß jetzt aber nicht mehr, ob er dafür auf die Karten was geschrieben hat (das möchte ich nicht) oder ob das Mapping zum File dann serverseitig über die ID des Tags gemacht wurde.

Ich für meinen Teil kopiere die Daten halt dann auf den zweiten ESPuino und lerne die Karten manuell an. Das geht sicherlich komfortabler, aber bei mir war das bisher kein Task, der dauernd kam.

Aber ja, klingt nicht uninteressant, was du vor hast.

Vielleicht etwas einfacher wäre ein NAS o.ä. und die Tags werden einfach mit dem Pfad assoziiert.
Die erwähnten cloud Technologien sind zwar fancy, aber eventuell mit Kanonen auf Spatzen geschossen.

Synchronisieren (wenn die tracks wirklich auf die Karte sollen) könnte man mit rsync o.ä. lösen, das los getreten wird, sobald ein FTP server eines espuino im Netz auftaucht.

Viele Wege führen nach Rom :wink:

Die ESPuinos könnten sich auch untereinander im gleichen Netzwerk synchronisieren, aber mein Use-Case ist Heimnetz-Übergreifend.

Es gibt natürlich viele Möglichkeiten so etwas umzusetzen.

Ich werde den Weg über S3-Kompatiblen-Storage mal weiterverfolgen.

Ein MinIO ist im Container schnell aufgezogen oder man mietet sich eben für ein paar Cent im Monat S3 von AWS.

Es lokal per HTTP vom NAS zu streamen ist kein Problem. Nur kann man bei einem Hörspiel halt die Position nicht gespeichert werden, wenn man es streamt.

Glaube (ich weiß es nicht) das scheitert in der Praxis daran, dass der ESP32 dann einigermaßen ausgelastet ist und nicht mehr zur Audiowiedergabe taugt. Zumal der FTP-Server per Default auch gar nicht instanziert wird, weil das speichertechnisch mit dem Heap dann eng werden kann.

@tuniii bitte nicht falsch verstehen, ich bin selbst auch an so einer Lösung interessiert :wink: Ich glaube, der Storage ist weniger das Problem sondern eher wie die Daten synchronisiert werden.
Ich finde den Sync Mechanismus von Syncthing recht spannend, da er ohne Server auskommt (nutze Ihn für Handy, Laptop und PC) aber dafür hat der ESP bestimmt nicht genug Power.

@biologist das mit dem sync hatte ich mir auch so gedacht, dass man auf das NAS als „master“ neue Sachen ablegt und danach auf den Boxen den FTP server aktiviert und somit die neusten Tracks bekommt. Ganz automatisch ist das nicht.

Karten, die einen Download anstoßen sind denke ich ein cooler Ansatz, da die Sachen eben nur bei Bedarf geladen werden und man gut Kontrolle drüber hat, wann der ESP sich damit abstrampelt. Für das Mapping müsste man sich noch etwas einfallen lassen.

So oder so, ich bin gespannt, was hierbei raus kommt und werde ein Auge auf diesen Thread haben :slight_smile:

Die Idee ist, dass der ESPuino selbständig sich die Informationen vom S3-Storage holt. D.h. im ESPuino gibt man die Zugangsdaten für den S3-Bucket an und er schaut dann selbst was ihm fehlt. Im S3 lassen sich ja auch zu den Dateien beliebige Meta-Daten abspeichern. Der RFID-Tag wird dann einer dieser Meta-Daten sein. Man kann dann direkt vom PC zum S3 hochladen und der ESPuino erledigt den Rest. Die Lösung kann man dann beliebig schön machen. Entweder als Skript oder als Applikation.

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 :slight_smile:

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?

[0] toniebox/Audio-file-format.md at fcc14a91c3be26981068f0087808c1a134796adf · toniebox-reverse-engineering/toniebox · GitHub

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:

  • Sector 0 - Ungenutzt für Kompatibilität
  • Sector 1 - Header , Flags , Card UUID
  • Sector 2-6 - Payload … wird soweit gelesen bis ein leerer Block kommt (Byte Pos 0 und 15 == 0-Byte)

Folgende Werte gibt es für den CardType

  • 17 / 0x11 = Web Card / Single File (Payload = einzelne MP3 , TrackNr = number der Datei im Ordner)
  • 18 / 0x12 = Web Card / Catalog File (Payload = M3U mit Einzelfiles)
  • 19 / 0x13 = Web Card / Only Stream Url (Payload = M3U , direkt in die PlayQueue)
  • 173 / 0xAD = Admin Card (playMode = Cmd)

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?