Anzeige der RFID bei allen Ordnern gleich

Im WebUI wird ja unten die RFID der aktuellen Karte angezeigt:
grafik

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

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.

Schau dir doch mal meinen PR an: Embed swagger UI by caco3 · Pull Request #314 · biologist79/ESPuino · GitHub :
Ich habe die Swagger-Doku noch ins Menu aufgenommen.

Wie macht Ihr das mit dem Review/Mergen? Muss ich da noch explizit jemanden anschreiben oder werdet Ihr von euch aus Aktive?

Gute Frage, sich einmal im Dev-Branch - #546 von tueddy melden ist garantiert nicht verkehrt :wink:

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:
grafik
Dadurch würden Mehrfach-Belegungen einfach sichtbar.
Auch diese Erweiterung könnte rein mit Javascript umgesetzt werden. Bei Interesse kann ich mir dem annehmen.

@tueddy, was denkst Du dazu?

Die Luxus-Erweiterung wäre natürlich, dass man die einzelnen RFIDs bei den Ordnern/Dateien auswählen und bearbeiten kann. Aber das ist wohl komplexer.

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.

Wie denn? Die RFID ist quasi der Primary Key im NVS und hat exakt eine Zuordnung, die bei einer Neuzuweisung überschrieben wird.

Ich bin zwar nicht @tueddy aber ich lehne es ab. Das ist völlig nerdig und (meines Erachtens) nutzlos, da irgendwelche Zahlenkolonnen zu sehen.

1 „Gefällt mir“

Das ist aus dem UI aber nicht ersichtlich, dass die vorherige Zuweisung überschrieben wird!

Die Darstellung könnte man ja auch anders machen, z.b. mit einem Icon per Zuweisung. Und die ID/Settings im Tooltip verstecken.

Ich sehe einfach folgendes Szenario:

  1. Wähle Ordner A aus
  2. Lege RFID-Karte A auf → Wird erkannt
  3. Speichern
  4. Wähle Ordner B aus
  5. Lege RFID-Karte A auf - wird aber nicht erkannt (Zu grosse Distanz, …)
  6. Speichern

Nun habe ich, ohne es zu merken, die Zuweisung zu Ordner A verloren und fälschlich die Karte A dem Ordner B zugewiesen.

Schön wäre sicher, wenn das UI eine Abfrage machen würde ala „Diese Karte ist schon anders in Verwendung, Zuweisung aktualisieren?“.

Und mit den IDs in der Liste (oder nur Icons) würde man das bei einer Kontrolle auch sehen.

Soweit ich sehe, ist das so nicht korrekt im aktuellen Dev! Obiges Szenario habe ich gerade durchgespielt, und da kam immer ein grüner Success-Toast!

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?

1 „Gefällt mir“

Wenn du wissen willst welche RFID für was zugeordnet ist kannst du dir ja die JSON angucken die die Api auswirft…

oder in schöner macht das mein Projektvorstellung: Espuino Manager :wink:

2 „Gefällt mir“

Ganz ruhig!

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

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.

2 „Gefällt mir“

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.