Refactoring des Web Interfaces und der REST API

Moin @eating_bananas! Du kannst auf ESPuino gucken, wie der aktuelle Stand ist. Ich bin auch offen für Vorschläge, PRs etc.

Das Projekt selbst ist mit Svelte + TailwindCSS gemacht. An einigen Stellen bin ich mit der UX noch recht unzufrieden, aber es ist mal ein Anfang.

Ich habe mich vllt etwas ungeschickt ausgedrückt: Die Weboberfläche erkennt selbst ihre Sprache anhand von System-/Browser-Einstellungen und stellt entsprechend um. Das ist soweit auch drin, ich hab nur temporär „Deutsch“ rausgenommen, damit es nicht halb Deutsch, halb Englisch ist.
Die Compiler-Direktive wird dabei nicht genutzt, die ist dann nur noch für die Ausgaben über UART relevant.

@sonovice ok, sehr cool, danke.
Gibt es etwas konkretes, wo ich dich helfen kann?
Würde das helfen, wenn ich ein mal drüber gehen, und einfach notiere was mit auffählt?

Im Moment überlege ich an einigen Stellen, ob das die optimale Lösung ist, also ist noch nicht ganz klar, wohin es soll. Allgemeines Feedback hilft daher natürlich immer sehr!

Ebenfalls sehr gerne, aber vllt erst, wenn alle Strings soweit ihren Platz haben.

Wenn du Interesse hast? Ich habe mir die Mühe für so ein recht überschaubares Projekt nicht machen wollen, aber ich will auch niemanden abhalten. :smiley: Bin mir allerdings nicht sicher, wie nötig bzw. hilfreich e2e testing tatsächlich hier ist.

Nach etwas Überlegung würde ich die Play Modes etwas anders gestalten wollen:


(Letzte Option nur ersichtlich, wenn Ordner oder Playlist ausgewählt wurde.)

Leider mappt das Modell auf diese Weise nicht 1:1 mit dem aktuellen internen Playlist Management.

@biologist Natürlich kann ich im Backend alles auf die einzelnen Modi münzen, die es gibt (wenn auch nicht jede Kombination, „Repeat“ gibts bei Playlists z.b. [noch] nicht). Nicht gänzlich ungeschickt wäre es aber vllt auch, mittelfristig diese Optionen auch im ESP Code zu vereinheitlichen. Könnte man zumindest mal drüber sprechen, wenngleich ich hier niemandem Extraarbeit machen will :wink: .

Ich kann die Motivation verstehen, das so machen zu wollen. Weil dann braucht man nicht x Playmodes, um die gesamte Kombinatorik zu erschlagen. Der Ansatz ist generischer und im Grunde lebt das Ganze intern im Bitfeld auch eh bereits so: ESPuino/AudioPlayer.h at d5828e42210eab3f8d694c45f031d1a3d6e88838 · biologist79/ESPuino · GitHub.
Aber was man nicht vergessen sollte:

a) Man muss die bestehenden NVS-Einträge on-the-fly migrieren. Es ist dem Benutzer definitiv nicht zuzumuten, dass er alle Zuweisungen neu macht. Keine Raketenwissenschaft, aber darf man nicht vergessen.
b) Es gibt Dinge, die technisch nicht gehen. Beispielsweise Shuffle+Save Position. Weil ich speichere die letzte Position in Titelnummer und auch Position im Titel in Bytes. Die Titelnummer zu speichern bringt mich nur dann weiter, wenn die Titel immer die gleiche Reihenfolge haben. Und genau das mache ich da auch: Ich sortiere die Titel alphanumerisch vorher. Das macht bei Shuffle natürlich keinen Sinn.

Also das ist schon bisschen was in Arbeit. Weil der aktuelle Weg geht so:

  1. RFID-Erkennung
  2. Kenne ich den Eintrag im NVS?
  3. Normale Karte oder Modifikationskarte?
  4. Modifkationskarte: Aktion via CMD ausführen
  5. Normale Karte: Dispatcher
  6. Audio-Ablaufsteuerung

Neu:

  1. Gleich
  2. Gleich
  3. Neues oder altes Format im NVS? Alt => Migration
  4. Normale Karte oder Modifikationskarte?
  5. Modifkationskarte: Aktion via CMD ausführen
  6. Normale Karte: Dispatcher => Der Dispatcher muss angepasst werden. Vorteil: Dieser wird deutlich kürzer, da redundanter Code entfällt.
  7. Audio-Ablaufsteuerung => Ablaufsteuerung muss an diversen Punkten angepasst werden. Insbesondere auch NVS-Write

Das Testen von (7) ist halt aufwändig denke ich.

Übrigens: Man könnte „Dimm LEDs“ noch als Eigenschaft hinzufügen. Aber ist insgesamt schon ne komplexe Änderung.

Danke für die flotte Rückmeldung!

Die Kombi habe ich soeben ausgeschlossen, danke. Ist auch bereits online.

Theoretisch könnte man auch den Inhalt der backup.txt am Stück migrieren, statt bei jeder Karte 2 Logiken zu unterscheiden. Da werden ja quasi die Bitmasken gespeichert, falls ich das richtige sehe? Also beim Booten kurz checken, ob die Datei in der ersten Zeile etwas hat wie version: XYZ. Falls nein oder Version zu niedrig, würden kurz alle Einträge migriert werden und die Zeile entsprechend eingefügt oder angepasst.

Mir ist aber klar, dass das nicht „mal eben“ gemacht ist bzw. vllt auch gar nicht. Bis dahin kann ich ja im Backend die (2^4-3) Fälle unterscheiden und auf die bekannten Modi mappen, ist ja kein Beinbruch.

Ja, könnte man machen. Man muss das allerdings auch mit hinreichend vielen (500?) NVS-Einträgen testen, damit man sieht, ob das auch skaliert.

Hier kannst du sehen, wie das linearisiert gespeichert wird:

  • Playmode/Aktion (Modifkation) ist der Integer aus der values.h.
  • Nummerierung fängt bei 0 an.
  • ‚#‘ ist das Trennzeichen.
  • Key im NVS ist die RFID

Klingt gut.
Habe eben mal kurz durchgeklickt. Für die Playmodi mit Verzeichnis ergeben sich denke ich mehr Möglichkeiten, als momentan anklickbar sind. Beispielsweise der Playmode 12. Nicht so einfach, hehe.

Was mir in der aktuellen GUI auch noch fehlt ist:

  • Shutdown
  • Restart
  • Info
  • Log
  • Link zum Forum

Ich glaube allerdings, dass ich mind. Letztgenanntes schonmal gesehen hatte.

Mühsam nährt sich das Eichhörnchen… Wird alles :wink:

1-4 kommen noch in die Settings unter „System“, danke. Den Link hab ich tatsächlich nicht mehr drin. Wie wärs mit Klick aufs Logo?

:sunglasses:
image

1 „Gefällt mir“

Ich fand ja dieses Symbol mit den Sprechblasen gut :slight_smile:
Intuitiv würde ich beim Klick auf das ESPuino-Symbol ein Reload der Seite erwarten. Ich war, auch bei der aktuellen GUI, immer mal versucht, da draufzuklicken. Aber am Ende doch zu faul, es einzubauen. Weil wirklich was bringen tut einem das ja nicht :slight_smile:

1 „Gefällt mir“

Wow, ganz tolles UI!
Was mir noch aufgefallen ist bzw. so für mich nicht ersichtlich ist:

Kann man die Tag UID auch ohne Tag manuell eingeben?

Wäre es nicht sinnvoll, Tag assignments nicht nur manuell auslösen zu können sondern auch löschen zu können. Z. B. Tag geht verloren und Audiofile wird neuem zugeordnet. Nur so eine Idee.

Super Job, vielen Dank!

Vielen Dank :slight_smile:

Hmm, hatte ich bislang nicht vorgesehen, da ich mir nicht vorstellen konnte, dass jemand eine Liste mit UIDs irgendwo pflegt, um dann manuell Dinge zu ändern. Aber vllt irre ich mich da. Wie genau sieht denn dein Workflow aus?

Prinzipiell ja, könnte man natürlich leicht mit reinnehmen. Auch da hatte ich angenommen, dass XX überflüssige Einträge nicht interessieren, aber ich überlege mir was!

Danke dir für das Feedback!

Das geht doch jetzt schon mittels Backup und Restore der backup.txt . Damit halte ich die 2 Boxen meiner Enkel auf dem gleichen Stand und bereinige falls nötig .

Der Weg geht natürlich immer, ist allerdings aus Benutzersicht eher fummelig. Wäre ESPuino ein kommerzielles Produkt (und den Anspruch hab ich in der Regel an UI Designs, auch wenn’s über das Ziel hinausschießt), dann würde sich diese Lösung disqualifizieren. Bin da aber - wie immer - offen für Ideen!

Was ich mir vorstellen könnte: Man steuert ESPuino via MQTT von extern und sagt, dass man so viele Karten gar nicht möchte, wie man Audiofiles hat. Dann kann man hingehen und sich Dummy-Nummern überlegen und diese von extern (REST oder MQTT), ohne wirklich die Karte dafür zu besitzen, antriggern. Also insgesamt wird das sicher sehr selten benutzt, aber grundsätzlich halte ich es für sicher nicht nachteilig, wenn man auf die Nummer manuell Einfluss nehmen kann.

Ein zweiter Use Case ist: Du hast zwei ESPuinos (E1 und E2). Auf E1 sind diverse Sachen eingerichtet, die auf E2 noch fehlen (Kinder würden sich eine Karte teilen (*)), aber E1 und E2 sind nicht so ähnlich, dass sowas wie NVS löschen und Backup einspielen tragbar ist. Dann bin ich z.B. jemand, der nicht die ganzen Karten raussucht (meine Kinder haben jeweils so zwischen 50 bis 100), sondern lieber mit der ID hantiert. Also schaue ich ins Backup-File rein und lerne den Kram mit Copy’n’Paste an. Ganz klar ist das der Nerdweg, aber es ist halt einfach eine Möglichkeit mehr.

Kurz: Ich hänge nicht krampfhaft dran, aber ich halte es für vorteilhaft. Und sei dir sicher: Immer wenn du denkst, dass du gut für andere Leute mitgedacht hast, kommt mind. eine Person um die Ecke und fragt trotzdem danach :slight_smile:.

(*) Don’t try this at home! In der Praxis fährt man besser, wenn Kinder ihre jeweils ihre eigene Karten haben, weil sonst gibt’s unnötig Krach :rofl:.

Am Webinterface hat sich wirklich viel getan - ich mag es sehr und fühle mich da wirklich gut aufgehoben/abgeholt.

Mir ist folgendes Aufgefallen:
Wenn ich das Webinterface auf dem Smartphone (Android mit Firefox - ich glaube das ist jedoch überall so) öffne und durch die Settings per touch scrolle, dann werden die Slider sofort gesetzt sobald man mit dem Finger draufkommt. Das Verhalten ist in der Übersicht der Aktionen von Tags nicht so. Dort kann man problemlos scrollen und erst durch gezieltes Drücken auf eine Aktion wird diese ausgewählt.
Das ist eher eine Goldkante, weil man das Verhalten auch umgehen kann, indem man beim Scrollen anstatt den Schiebereglern, den Hintergrund anfasst.

Ohne Touchbedienung (z.B. am Rechner mit Maus) ist dies natürlich auch keine Auffälligkeit

Ich hoffe du konntest meiner Ausführung folgen :grinning:

Moin und danke für Lorbeeren und Feedback! Unter uns: Mir ist das Verhalten auch schon negativ aufgefallen, aber der Workaround dafür ist recht langwierig, weswegen ich es unter den Teppich gekehrt hatte in der Hoffnung, dass niemand darunter Staubsaugen will - Mist :smiley:

Sobald wieder etwas Luft ist, schaue ich mal, was da geht.

EDIT: War doch easy, fixed.

1 „Gefällt mir“

Ich hab noch ein komisches Verhalten auf dem Android Smartphone im Firefox:

Wenn ich in die Texteingabefelder klicke dann wird hinein gezoomt. Beim Verlassen jedoch nicht wieder die richtige Größe hergestellt.

Bei Brave, Tor Browser und Chrome tritt dies nicht auf. Bei den wird auf einfach gar nicht gezoomt, was auch okay ist.

Und ich dachte im Herzen gibt es nur noch Safari, Firefox und Chrome und damit wird es einfacher :frowning:



Hmm, das kann ich hier bei mir mit Android + FF leider nicht nachvollziehen. Deine Auflösung scheint aber auch etwas geringer zu sein als meine.

Konntest du das Verhalten auch schon auf anderen Webseiten beobachten?

EDIT: Ich schätze, es handelt sich um etwas in dieser Art: android - Prevent zooming in after input field focus in Firefox on mobile - Stack Overflow

EDIT2: Gefixt. Magst du mal testen?

1 „Gefällt mir“