Im WebUI wird ja unten die RFID der aktuellen Karte angezeigt:
Ich finde das recht verwirrend. Denn ich würde erwarten, dass da die RFID angezeigt wird, welche für den gewählten Ordner/Datei gespeichert ist. Dann könnte man bei einem nicht-konfigurierten Ordner/Datei auch ein leeres Feld anzeigen und man würde sehen, das es keiner RFID zugeweisen ist.
Ich finde das eigentlich ganz praktisch, dass die aktuelle oder zuletzt verwendete rfid angezeigt wird. Meistens will man die ändern, und dann steht sie bereits da.
Es kann außerdem sein, dass ein Ordner verschiedene tags hat. Etwa einen zum abspielen des gesamten Ordners, einen mit „Zufälliger Titel, danach sleep“.
Die Logik, welchen Tag man anzeigt wäre kompliziert oder höchst unzuverlässig.
Ich stimme dir aber zu, die webui ist für Einsteiger nicht immer super intuitiv. Da gab es auch schon mal Ideen, das ein wenig moderner zu machen, das hing aber dann an der API ein wenig fest. Inzwischen ist die aber glaub ich durch, also wird es mal Zeit die wieder auszugraben. Ich warte schon sehnsüchtig mal auf ein freies Wochenende um mich da ran zu setzen
Es kann außerdem sein, dass ein Ordner verschiedene tags hat. Etwa einen zum abspielen des gesamten Ordners, einen mit „Zufälliger Titel, danach sleep“.
Man könnte die RFIDs ja oben im Verzeichnisbaum anzeigen, dabei wären problemlos auch Mehrfachauflistungen möglich. Ev. mache ich da mal einen PR.
Ich stimme dir aber zu, die webui ist für Einsteiger nicht immer super intuitiv.
Ich finde das aktuelle UI eigentlich ganz ok. Die REST API ist auch sauber dokumentiert.
Mein Erwartung wäre, dass wenn ich ein anderes Verzeichnis/Datei auswähle und keine RFID-Karte aufgelegt ist, das RFID-Feld leer bleibt, bis eine Karte aufgelegt wird. Die Überlegung ist, dass man selten bis nie eine Karte für mehrere Ordner/Dateien speichert (mir ist kein valides Szenario bewusst).
So wie es jetzt ist, könnte ich unbewusst eine RFID auf mehrere Ordner/Dateien speichern. Wie geht die Firmware damit um? Sie kann ja nur eine Datei aufs mal abspielen.
Ich vermute, die Detektion „RFID-Karte erkannt/verloren“ wird über den Websocket kommuniziert?
Dann könnte man das rein mit Javascript umsetzen.
Und dann, unabhängig davon fände ich es hilfreich, wenn die gespeicherten RFIDs bei den Ordnern/Dateien angezeigt würde:
Dadurch würden Mehrfach-Belegungen einfach sichtbar.
Auch diese Erweiterung könnte rein mit Javascript umgesetzt werden. Bei Interesse kann ich mir dem annehmen.
Das verhalten, bei Kartenauflegen is immer, dass das input die Tag Nummer erhält und angezeigt wird, was sie tut. Ein neuer Befehl lasst sich auf die Karte nur dann legen, wenn sie vorher unter dem tab Tools gelöscht wird.
Der Case ist also abgedeckt und die Firmware muss sich um keine Dopplungen kümmern.
Karte verloren könnte der Vollständigkeit halber natürlich noch den input löschen, das stimmt.
Man muss da kein Problem konstruieren, wo keines ist.
Legt man eine Karte auf, dann wird das entweder auf dem Neopixel rot quittiert („die Karte kenne ich nicht“) oder das, was dem RFID zugewiesen wird, beginnt zu spielen. Ist beides nicht passiert, dann wurde die Karte (noch) nicht erkannt.
Mal ganz abgesehen davon wird auch ein „Toast-PopUp“ angezeigt, wenn eine Karte erkannt wurde.
Genau, und du lädst dann ständig die Sachen zum Abgleich aus dem NVS nach oder hältst sie gleich im Speicher, da wir davon ja massig haben. Echt?
Ich bin ja nur am verstehen, wie es funktioniert und stosse auf einige Ungereimtheiten. Meine Überlegungen steuern darauf zu, dass es verbessert werden könnte, nicht, dass ich etwas bemängeln möchte!
Spielt doch bitte auch mal das Szenario durch. Die Zuweisung wird überschrieben und es wird ein grüner Toast angezeigt.
Swagger bestätigt das übrigens als bewusstes Design:
Wäre es wirklich eine Überlastung, wenn man vor dem Speichern die Liste abfragt und in Javascript validiert?
Noch besser wäre, man würde das im Gerät machen und anstatt success einen Fehlercode zurück geben (z.B. 406 Not Acceptable, oder 409 Conflict). Da ich mich bei meiner Arbeit genau mit solchen APIs beschäftige, kann ich da gerne unterstützen, aber natürlich nur, wenn das auch erwünscht ist.
Es geht nicht drum, dass man Dinge nicht bemängeln darf. Glaube es gibt wenig Projekte, wo es so liberal zugeht, wie hier.
Passt doch. Weil die Zuweisung geklappt hat. Um das geht’s hier, weil da hätte man sonst kein Feedback.
Korrekt.
Davon war nicht die Rede. Du wolltest, dass die ganzen existierenden Zuweisungen irgendwie inline in die Baumstruktur gewurschtelt werden. Und dafür machst du entweder dauernd Lookups oder du hältst es alles im Speicher (und musst ggf. Updates drauf machen). Und spätestens wenn’s viel wird, dann wird’s speicherintensiv und/oder langsam.
Lediglich eine Prüfung beim Speichern ist etwas ganz Anderes.
Das ist sogar der einzig gangbare Weg, wenn man das in konsistent machen will, wenn man auch am Webinterface vorbei über das REST-API laufen kann.
Vielleicht kann sich @tueddy ja dafür begeistern. Ich persönlich halte es für unnötigen Aufwand, einen Benutzer extra nochmal zu warnen. Selbst wenn sowas fälschlicherweise mal passiert, ist der Aufwand absolut gering, wieder den Ursprungszustand herzustellen.
Die IDs direkt im Baum anzuzeigen finde ich auch nicht optimal.
Für den use case „SD Karte ist voll, was kann ich löschen?“ fände ich eine ggf. Markierung der Ordner/Dateien (farbiges icon?) sinnvoll. Das finden/anzeigen von zugeordneten Karten würde ich über eine Funktion im Kontextmenü machen.