Webcontrol und dynamisches Button-Layout

@QDaniel hatte die Tage u.a. Commits für zwei Sachen bereitgestellt:

Webcontrol. Da kann man ein paar grundsätzliche Steuerungen über die Webgui machen. Wurde ja schon einige Male gefordert. Hier mal ein Screenshot vom Handy, wie das aussehen wird:

Als zweiten Punkt ist noch das dynamische Button-Layout zu nennen. Das ist mit der Umsetzung ein Stück weit in den ersten Punkt verflochten, weswegen ich das zusammen umsetze.

Bin jetzt gerade am testen und werde es demnächst hochladen. Dann könnt ihr das auch eifrig testen.

Vielen Dank an dieser Stelle an @QDaniel. Ich komme selbst in letzter Zeit gar nicht mehr so viel zu Coden, da hier aktuell auch viel administrativer Aufwand anfällt. Aber ist ja schön, dass mich die Community so emsig unterstützt :+1:.

4 „Gefällt mir“

Am button layout arbeite ich gerade noch mal. Daher evtl. warte mit den buttons noch.

Eieiei… jetzt habe ich da schon Arbeit reingesteckt…
Was genau überarbeitest du denn? Paar kleinere Fehler habe ich gefunden, aber nix Wildes (Gültigkeitsbereich von GPIOs darf zB nicht bei >0 anfangen, da ein GPIO auch 0 sein kann). Lautstärkeregelung via Buttons klappt nicht, da currentVolume nicht geändert wird. Aber das hat auch halt damit zu tun, wie es aktuell implementiert wurde von mir. Und es kommt zu Problemen, wenn man die Lautstärke per Drehencoder ODER Buttons ändern will, da der Drehencoder einen internen Wert hat, der nicht davon weiß, wenn currenVolume sich anderweitig ändert. Weiter bin ich jetzt noch nicht gekommen.

Übrigens war die große Switch-Funktion (doCmdAction() oder so) bei mir nicht Compile-fähig. Ich musste jeden einzelnen Case in geschweifte Klammern setzen. Was in Anbetracht der vielen Cases kein „Heimspiel“ war, hehe.

Fies war allerdings, dass du in den settings einen RFID-GPIO von ich glaube 21 auf 5 gesetzt hast. Das hat sich dann mit einem Button überlappt und einerseits dazu geführt, dass der PN5180 nicht erkannt wurde und andererseits, dass der Code wohl in einer Endlosschleife gelaufen ist und dadurch die anderen Tasks gegen die Wand gefahren hat (=> ständige Neustarts).

Aber sonst gefällt mir die Lösung gut. Habe halt Doku hinzugefügt.

Schau mal in mein master habs dir gerade commitet

Hmm, also technisch mag das besser skalieren. Aber ich halte das für zu abstrakt und unübersichtlich, um unbedarfte Benutzer damit zu konfrontieren.

ja da fehlten break Anweisungen.
Deine DoButtonAction ist dafür nun weg :wink:

Hatte ich auch das Problem (mein next Button ist GPIO 0)

Muss evtl. ein wenig mehr beschrieben werden.
Aber die Defaults sind ja trotzdem gleich.

Damit alle Ihr Meinung dazu äussern können hier der entsprechende Config Ausschnitt.

Jede Zeile ist eine Button Definition. Line 158 - 160 zeigen Button Kombinationen und zb. 172-174 Longpress Actionen ( mit | BUTTON_LP)

Man könnte für BUTTON_01 bis BUTTON_04 noch Aliase definieren.
zb. BUTTON_PREV, BUTTON_NEXT, BUTTON_PLAY, BUTTON_DREH .

Man sollte dann aber entweder die GPIO Settingnamen ändern und mit _GPIO suffix versehen oder die BIT Defines im Namen etwas anpassen.
Damit da weniger Missverständnisse aufkommen.

Könnte man die Buttonbelegung auch ins WebGUI auslagern, oder ist das der Plan? Dann wäre das vielleicht für den weniger programmieraffinen Nutzer einfacher zu machen. Mir schwebt eine Drag 'n Drop Lösung vor, wo man die Knöpfe Aktionen zuordnen kann. Ich könnte versuchen, dafür Grafiken zu liefern. Das in Javascript (oder was auch immer) umzusetzen kann ich leider mangels Kompetenz nicht anbieten.

Also grundsätzlich machen kann man das natürlich. Aber ob das jetzt mit Drag’n’Drop sein muss… GUI ist nicht so mein Metier. @Christian oder @Harry: Wie seht ihr das?

Könnte man in dem Zug die Readerempfindlichkeit mit in die WebGUI aufnehmen. Da spart man sich bei Einstellen auf das Gehäuse oder die verwendeten Tags das neu kompilieren

Lasst uns Mal Brainstormen was alles in die webgui muss.

1 „Gefällt mir“

Grundsätzlich finde ich es cool Sachen konfigurieren zu können. Aber ich bin mir unsicher ob man das alles in die WebGUI packen soll, oder ob es da nicht auch ein Configfile auf der SD Karte tut.
@QDaniel streng genommen müsste so ziemlich alles aus Settings.h rein, außer die compiler switches.

Also alles was Hardware spezifisch ist sollte in der settings bleiben. Also Compilerswitche und GPIO Config.

Viel bleibt dann nicht mehr aus der Settings.h über.

  • Die neuen Buttonactions
  • die timeouts
  • Reader gain

Es sind halt im Endeffekt Sachen dabei, für die sich das erstmal gut anhört, es via GUI konfigurierbar zu machen. Aber es sind auch Sachen, die man nicht dauernd ändert. RFID-Gain ist für mich sowas, zumal es auch nur spezifisch für den RC522 ist. Bei PN5180 ist es dann wieder ganz anders.

Aber klar, da kann man getrennter Meinung sein.

Beim Gain seh ich das so ähnlich, wie beim Lautstärke Min/Max. Man kann das am besten im eingebauten Zustand testen. Letztlich spielt man ja selten in der GUI rum, aber manche Sachen gehen schneller, wenn man nicht in den Code muss und neu compilieren. Das Bedienkonzept find ich auch schwer vorher abzuschätzen. Ginge natürlich auch mit einer Textdatei auf der SD, die beim Start eingelesen oder neu erstellt wird.

Es gibt einfach halt auch Sachen, die nur so gehen. Also ein Vorteil der Compile-Switches ist halt auch, dass man die Firmware nicht mit Sachen aufbläht, die man nicht braucht. MQTT oder FTP z.B. Neopixel auch, wobei das Konzept so elementar in meinem Code verankert ist, dass ich ein Weglassen nicht so wirklich empfehlen kann :slight_smile:

Den Neopixel finde ich auch genial. Freue mich schon, wenn der endlich im Briefkasten liegt. War mir am Anfang zu meiner Schande nicht so elementar aufgefallen. Da könnte man bspw. aber die Farbe in der GUI konfigurieren.

Hab’ jetzt keine Idee bezgl. Drag’n’Drop wäre aber eher bei einer Auflistung wo eine Zeile aus drei dropdown nebeneinander besteht. Dort kann man die oben beschriebene Kombination auswählen. Dann mit „+“ / „-“ eine Zeile / Kombination hinzufügen / entfernen.

Ich muss gestehen, dass ich im ersten Moment den Sinn einer solchen Erweiterung nicht verstanden habe. So flexibel wie es hier jetzt beschrieben ist, finde ich es tatsächlich auch gut.

Nicht nur die Button Zuordnung ist damit individuell möglich. Auch ist es für „Forks“ sehr einfach andere Button-Systeme hinzuzufügen.

Grundsätzlich sind damit pro Button dann 3 Actionen verknüpfbar. + so wie jede mögliche MultiButtonKombi (auch mal 3)

In der Standard 4 Button Variante wären das (2^4)*3 =48 mögliche Kombination :firecracker:

Ich bin dafür, das wenn alle 3 Buttons gedrückt werden mit
PLAY_FILE /Hör_auf_alle_knöpfe_zu_drücken_{Name des Kindes}.mp3
zu belegen :grin:

Aber die Idee das über die web gui zugänglich zu machen finde ich schon gut. Es muss ja kein drag&drop sein (es sei denn jemand will das programmieren), aber ich könnte mir eine Matrix aus checkboxen vorstellen in der man die Buttons den möglichen Funktionen zuordnet und dann noch ob es durch gedrückt halten geschehen soll. So zum Beispiel:

Demnach müsste man den ersten und zweiten Knopf gedrückt halten um das Wifi ein- und auszuschalten. (Vielleicht nicht gerade wenn man in der webgui arbeitet :stuck_out_tongue_winking_eye:)
So könnte jeder nach Belieben durch anklicken der Checkboxen die Knöpfe den Commands zuweisen.

haukino

PS: Wenn ihr eine Kombination aus long press und short press anbieten wolltet, müsste man checkboxen mit 3 Zuständen haben. Und dann würde die letzte Spalte wegfallen.