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…
- die WLAN-Verbindung nicht gut ist oder das Kind beim Transfer durch die Butze läuft und es zwischendrin einen Abriss der Übertragung gibt?
- beim Download ggf. die Audiowiedergabe ruckelt (oder unterbindest du die, weil das Kind halt warten soll?), weil es zu viel Rechenzeit braucht, während das Kind was hören will? Tritt dann aber vielleicht nicht immer auf - hängt ggf von der Bitrate ab.
- das Kind mitten im Download den ESPuino ausschaltet und die Datei nur halb übertragen ist?
- hier sukzessive immer mehr Medien-Portale unterstützt werden müssen, weil jeder zu Hause was Anderes laufen hat? Vielleicht ändert sich auch noch ein API und dann kann man unterschiedliche Versionen vorhalten.
- sich ESPuino plötzlich komisch verhält, weil die SD-Karte komplett voll ist, da man auf die SD gar nicht mehr schaut?
- dann kommt der Nächste kommt, der den ESPuino gar nicht mehr selbst anschalten will, sondern stattdessen möchte, dass dieser zyklisch aufwacht und schaut, ob neuer Kram da ist? Dann wacht der ESPuino mitten in der Nacht auf und leuchtet => dann muss er „silent“ aufwachen.
- keiner da ist, der den Lifecycle macht, wenn wir zB mal auf Arduino3 gehen?
…
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.
2 „Gefällt mir“
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.
3 „Gefällt mir“
sowas könnte man mit „meinem“ Espuino Manager lösen, der kann ja RFID-Zuordnungen lesen und exportieren
Damit könnte man also auf allen Geräten alle Karten des Haushaltes synchron halten (noch nicht vollständig von meiner Seite implementiert)
Das dann BB Teil 4711 einmal mit ID 1 und einmal mit ID 2 abgespielt werden kann, ist ja kein Problem.
Von mir gab es noch die Idee: "Internetradio" mit URL auf der Karte
1 „Gefällt mir“
Also was man zunächst schauen könnte ob man eine Playlist-M3U von einer URL laden kann und zwar so das nicht nur der erste Eintrag sondern alle abgespielt werden. @laszloh überarbeitet ja gerade die Playlist & will sie in eine Datei- & Stream-Klasse packen. Dann könnte man das dort recht leicht und vor allem universell erweitern. Bislang wird die M3U-Url direkt an den Audioplayer übergeben & die spielt eben nur den ersten Eintrag ab.
Über die Rest-API des ESPuino kann man schon jetzt die Zuordnungen Karte zu URL bearbeiten, @JHB hat das ja schon gezeigt. Ich hatte die verfügbaren Endpunkte schon mal zusammengeschrieben, eine gute Dokumentation dazu fehlt aber noch, also damit könnt Ihr mal anfangen 
Ich halte aber nichts von schreiben auf’s RFID-Tag und auch nichts von einer Anbindung einer spezifischen Cloud-XY.
3 „Gefällt mir“
Kleines Update von mir:
Habe mich für eine Integration mit audiobookshelf entschieden.
Die Implementierung ist aktuell noch recht rudimentär:
Audiobookshelf wurde erweitert um Hörbüchern, etc. RFID Tag UIDs zuordnen zu können. Eine neue API liefert dann für einen RFID Tag eine Playlist mit zusätzlichen Metadaten (Abspielmodus, etc.) zurück.
ESPuino macht aktuell bei einem unbekannten Tag einen API Request zu der audibookshelf API und Spielt die Dateien aus der Playlist ab. Wenn Die Datei schon auf der SD Karte liegt von dort, andernfalls wird die Datei gestreamt und beim abspielen gespeichert.
Geplant ist noch ein Hintergrund Downloader, der bei Inaktivität oder ggf. die ganze Zeit mit niedriger Priorität fehlende Dateien herunterläd.
Ich warte aktuell vorallem auch noch auf @laszloh’s playlist patches, aktuell ist vieles noch sehr hacky impementiert.
1 „Gefällt mir“
@freddy Das hört sich sehr interessant an. Könnte man die „cloud“ auf einem NAS im Docker laufen lassen ?
Ja, audiobookshelf gibt es schon als Docker Container. Die Frage ist, ob die ESPuino spezifischen Änderungen in den master branch übernommen werden oder ob es ein parallellen Fork geben wird (Es gibt kein Plugin System).
Ah ok. Wahrscheinlich sind es am Ende nicht viele die es nutzen werden, daher verstehe ich wenn es nicht in den Master kommen würde. Einfacher wäre es trotzdem für die, die es nutzen wollten, wenn es per define oder so aktiviert werden könnte.
Die Idee, erst lokal schauen ob bekannt, dann in der Cloud, fände ich sehr interessant. Wenn man grad nicht im Netz daheim ist, dasnn würde ja auch rot blinken reichen. Es würde aber bei mehreren ESPuinos im Haushalt die Verwaltung der Dateien erleichtern. Wobei es aktuell ja auch schon sehr komfortabel übers WLAN geht.
Ich beobachte das Thema mal weiter, habe einiges im Docker laufen, von daher wäre generell offen für eine eigene Cloud 
Danke für die Rückmeldung.
Hello, kann ich euch etwas helfen wäre auch sehr interessiert an dieser Lösung.
Ganz aktuell fällt mir da nur testen des großen playlist Pull requests von @laszloh ein: Playlist improvements by laszloh · Pull Request #269 · biologist79/ESPuino · GitHub (nicht verwechseln mit dem „kleinen“ Rework playlist generation by laszloh · Pull Request #275 · biologist79/ESPuino · GitHub) Ich werde versuchen meinen aktuellen code entsprechend umzubauen das der auf der neuen Playlist Architektur basiert und dann mal eine minimale Version veröffentlichen.