WebRadio Station auf eine Taste legen?

Habe ich da etwas übersehen. Ich denke, ich kann nicht einfach das Abspielen einer WebRadio Station auf eine Taste legen, oder?

Korrekt, das geht nicht.

Idee 1)
Solltest du, wie ich, quasi immer Webradio hören und du hast vielleicht nur eine handvoll Webradios, die du hörst, dann kannst du eine Karte als .m3u anlernen und im m3u-File stehen deine ganzen Webradios drin. Da kannst du bequem mit vor/zurück zwischen den Webradios springen. Zudem könntest du dann PLAY_LAST_RFID_AFTER_REBOOT aktivieren und dann wird beim Neustart automatisch das Auflegen der simuliert, so dass du gar nichts tun müsstest. Vielleicht löst das dein Problem ja schon.

Idee 2)
Du kodierst dir diese Aktion hart ein. Wenn du dir mal die Cmd.cpp anschaust, dann siehst du dort die ganzen Cases, in die man reinlaufen kann und was dann halt passiert. Da kannst du dir einen neuen definieren (dafür musst du aber auch die values.h erweitern und das Frontend ebenfalls) oder du zweckentfremdest halt eine Aktion, die du sonst eh nie benutzen würdest (z.B. CMD_SLEEP_TIMER_MOD_120). Dann räumst du bis auf das break (break nicht rausnehmen!) alles raus aus dem jeweiligen Case und schreibst über das break:

xQueueSend(gRfidCardQueue, gPlayProperties.playRfidTag, 0);

Und statt gPlayProperties.playRfidTag schreibst du hier hart die 12stellige Nummer deines RFID-Tags rein. In die Cmd.cpp musst du oben noch #include "Queues.h" reinnehmen, damit sich der Code kompilieren lässt.

Im letzten Schritt weist du die in Cmd.cpp neu erstellte/umgebaute Aktion einem Button zu:

Das Drücken der Taste simuliert dann die Aktion des Auflegens der Karte. D.h. das muss dann auch kein Webradio sein.

1 „Gefällt mir“

Vielen Dank für die ausführliche Antwort!

Kurzes Feedback:
Funktioniert so wie vorgeschlagen perfekt.
Hab einfach ein virtuelle Kartennummer „123456789012“ genommen.
Vorerst hab ich die CMD_SLEEP_TIMER_MOD_120 dafür zweckentfremdet.
VD&LG

1 „Gefällt mir“

Hallo Torsten!
Ich habe bei mir ja nach deinem Vorschlag die CMD_SLEEP_TIMER_MOD_120 Funktion umgebaut, dass diese das Auflegen einer RFID mit vorgegebener ID auslöst. Damit kann ich sehr flexibel auf jede Taste z.B: auch das Abspielen einer PlayList oder WebRadioStation legen.

Ich hätte vor, das bei mir wie folgt zu erweitern:

Definition von sagen wir 10 neuen CMD’s
CMD_FORCE_RFID_900000000001
CMD_FORCE_RFID_900000000002

CMD_FORCE_RFID_900000000010
Dieses dann konsequent bis zum WebGUI durchziehen.
Nachdem das aber doch, wie ich denke, eine allgemeine sinnvolle Erweiterung wäre, möchte ich die Bitte aussprechen, das doch ins offizielle Release zu implementieren.

Damit könnte man dann Tasten bzw. Tastenkombis einer dieser RFID CMDs zuordnen und damit
dann jederzeit die auszulösende Action / Funktion via WebGUI dynamisch anpassen.

Viele Grüße

Also wenn, dann würde ich das gerne generischer lösen, so dass man in der settings.h, wo man aktuell schon die Aktionszuweisungen macht, die RFID-ID direkt eintragen kann. Obwohl die bisherigen Aktionen schon intern numerisch (dreistellig) sind wäre das allerdings nicht komplett trivial, da man, mindestens teilweise, mit anderen (größeren Datentypen) arbeiten müsste.

Tatsächlich wäre das Verschieben dieser Zuweisungen in das UI ein sehr sinnvoller Schritt, da die Zuweisungen enorm technisch sind: Man muss zuerst in die values.h schauen und von dort das passende Define übertragen. Und weiterhin kann man ne Button-Zuweisung durchaus mal ändern wollen, ohne dafür den Code neu kompilieren zu wollen.
Ich stelle mir das so vor, dass man die Belegung pro Taste (*) im NVS speichert und beim Start ausliest. Dafür prüft ESPuino zuerst für jede Taste (und auch Tastenkombination), ob der NVS-Eintrag bereits existiert. Wenn nein, so wird ein solcher angelegt. Und zwar mit dem Wert, der in settings.h hinterlegt ist. Im UI muss man dann alle Tasten und deren Kombinationen (27 insgesamt) darstellen, aus dem NVS laden und dem Benutzer konfigurierbar machen.

@sonovice ist gerade dabei, das UI zu modernisieren. Ich möchte ihm das jetzt nicht auch noch aufdrücken, aber vielleicht hat er ja eine Idee, wie er sich die Umsetzung vorstellen könnte. Auch insbesondere im Hinblick des Speicherns im NVS:

  1. Man könnte pro Wert einen NVS-Eintrag verwenden. Zum Auslesen und Speichern ist das am einfachsten im Server, da man sich den Parser spart. Aber ich glaube das will man eher nicht, weil insbesondere der Transfer von und in das UI dann die Pest ist.
  2. Man macht nur einen einzelnen NVS-Eintrag, der #-separiert alle Werte in einem großen String speichert. Das Zusammensetzen beim Speichern ist trivial und einen Parser für das Auslesen zu schreiben, ist auch nicht weiter schwer. Aus Serversicht vermutlich am besten, jedoch vermutlich nicht aus UI-Sicht.
  3. Man nimmt nur einen einzelnen NVS-Eintrag, der alle Werte (statt #-separiert) als Json-String abspeichert. Auf der Serverebene finde ich das nicht so gut, weil diese Json-Objekte immer relativ viel Overhead mit Arduinojson machen, aber eigentlich kann man das Objekt auch sehr einfach designen, so dass man es auch ohne Lib relativ einfach zusammenbauen und auch wieder parsen kann. Muss man sich dann überlegen.

Müsste @sonovice bewerten.

@tueddy Offenbar ist das hier im Sande verlaufen. Was hältst du davon, wenn man das als Feature aufnimmt?
Ggf. aber so, dass man die Nummer des RFID-Tags über das Webinterface konfigurieren kann. Oder man macht einen größeren Aufriss und macht die gesamte Tastenbelegung eh über das Webinterface konfigurierbar.

@biologist Ja könntest Du in die Liste geplanter Features aufnehmen, evt. findet sich jemand der das übernehmen möchte?

Guter Punkt, die Liste hatte ich vergessen.
Ich nehme das auf und aktualisiere das mal.

Mir gefällt das Feature. Bin dafür :wink:

Erfolgt im Code eine UID-Prüfung der Karte? Womöglich kann man die Funktion dann auch ohne große Webinterface-Änderung machen. Es ist zwar unwahrscheinlich das man eine belegte Nummer erwischt, aber wenn man das den User frei eingeben lässt hat man eine zusätzliche Fehlerquelle.

Vorschlag:

Virtuelle Karte 1 heißt: VIRTUELL_RFID_CARD1

Kann dann z. B. für 4 Stück vorbereitet werden.

Wäre dann wie bisher nur eine zusätzliche Buttonfunktion. Die dann irgendwann mal im Webinterface parametrierbar zu machen wäre wie bei den anderen möglich.

Grüße Patrick

Die IDs müssen 12stellig sein. Ob zwingend numerisch weiß ich jetzt nicht mehr genau.

Nimmst halt:
999 999 999 999
999 999 999 998
999 999 999 997
999 999 999 996

Das ist extrem unwahrscheinlich, dass das mal kollidiert.

Ich hatte das, wie beschrieben bei mir erfolgreich implementiert.
Seit dem devbranch allerdings nicht mehr nachgezogen.

Werde das für mich jedenfalls wieder implementieren.
Würde das dann natürlich als Vorschlag zur Verfügung stellen.

Scheint nicht von Interesse zu sein.
Vielen Dank für eure tolle Arbeit.
Ich klinke mich als Beitragstäter aus.