Ist es nicht CPU Zeit aufwendig die Einstellungen jedesmal auszulesen?
Ich würde ein Struct mit alle für den Bereich möglichen Einstellungen machen.
Dann zwei Funktionen eine zum lesen und evtl. eine zum speichern.
Die Lesefunktion wird immer dann aufgerufen wenn die Settings über die UI geändert wurden.
Ich denke nicht, die werden ja nicht in einer Loop ständig neu gelesen sondern z.B. in LED_Init() oder Rotary_Init() nur einmal. Wenn sich Einstellungen ändern wird das jeweilige Init neu aufgerufen. Das haben wir bereits so auch schon gemacht für z.B. die Batterieeinstellungen hier.
Oh wow, das war ja ganze Arbeit! Coolio, da bin ich gespannt das dann gleich zu testen 
Werd ich mir ansehen, was sich da machen lässt 
Ja das waren schon einige Stunden zwischen den Tagen 
Wer’s ausprobieren möchte inklusive meiner bescheidenen HTML Künste: GitHub - tueddy/ESPuino at MoreSettingsFrontend
Dir auch!
Sehr geil! Danke für deine ganze Arbeit.
Dazu habe ich eine Frage und zwei Anmerkungen:
a) Für was sind die Farben gelb und blau?
b) Die Apostrophe müssen aus dem UI noch raus
c) Kannst du, wenn du die LED-Anpassung jetzt machst, auch gleich NEOPIXEL_REVERSE_ROTATION mit reinnehmen?
Ich glaube das ist tatsächlich gar nicht verkehrt, da es viel Übersicht bietet, wenn man später mal was sucht oder erweitern will. Für den Audioplayer haben wir ja ein ziemlich großes Struct (als Bitfeld). Auch wenn das mit gPrefsSettings nix zu tun hat, finde ich es exemplarisch doch immer wieder hilfreich, da alle Laufzeit-Variablen auf einen Blick zu haben, weil das sind doch echt viele. Wie man das befüllt ist nochmal ne andere Sache, aber ich denke das zentral an einer Stelle zu haben, ist grundsätzlich nicht verkehrt.
Wie auch immer: Vielen Dank @tueddy!
a) Für was sind die Farben gelb und blau?
Exemplarisch hier 2 zusätzliche Kontroll-LEDs, siehe Statische WS2812 LEDs . Da sollte in der Web-UI sicher noch ein Text „Kontroll-LED“ davor und ein schönerer Farbpickerl.
b) Die Apostrophe müssen aus dem UI noch raus
Mit der UI-Umsetzung bin ich ja noch nicht ganz glücklich & bitte hier um Mithilfe. Weil es so viel ist bezieht sich mein PR zunächst nur auf das Backend.
Aber das lässt sich bestimmt umsetzen;-)
c) Kannst du, wenn du die LED-Anpassung jetzt machst, auch gleich NEOPIXEL_REVERSE_ROTATION mit reinnehmen?
Oh ja, zusätzlich fehlt auch noch LED_OFFSET. Reiche ich noch nach…
Ich glaube das ist tatsächlich gar nicht verkehrt, da es viel Übersicht bietet, wenn man später mal was sucht oder erweitern will.
Die globalen Variablen sind bereits recht verstreut, evt. schiebt man noch ein Refactoring hinterher, sollte dann nicht so schwer sein. Vom Laden/Speichern rücke ich aber erstmal nicht ab, das funktioniert perfekt ohne neue Bugs. Init() muss eh aufgerufen werden um z.B. die geänderte Anzahl von LEDs neu zu setzen.
Ja, ist für mich auch ok 
.
Hallo und frohes Neues,
Ich hätte auch noch eine Idee.
Um sich die Arbeit in der Web UI zu ersparen und leichter zu erweitern, könnte man die ganzen wichtigen Parameter auch in eine .txt Datei (wie die Backup Datei für die RFID) packen und einmalig laden.
Die Datei kann man ggf. in der Web UI öffnen und ändern oder man macht es direkt am PC.
Das Gute wäre, wir könnten rel. einfach Standard- bzw. Beispieleinstellungen bereitstellen.
Grüße
Felix
Moin @felixSt,
Sichern/Wiederherstellen/Übertragen der Einstellungen kam hier irgendwo schon mal auf.
Das wäre superleicht mit < 30 Zeilen HTML/JavaScript Code umsetzbar:
Zum Sichern wird http://espuino.local/settings aufgerufen und als Datei gespeichert. Das kannst Du jetzt bereits machen.
Zur Wiederherstellung wird im Browser ein Dateidialog geöffnet und die Daten als JSON an fillSettings() übergeben. Dann sind die neuen Werte in der UI gesetzt, können nochmal kontrolliert und dann gespeichert werden.
Die Frage wäre nur, ob man sich das ganze in der WebUI komplett spart und man macht das ganze nur in einer externen Datei.
Dann könnten man die Parametrierung zur Laufzeit machen und man hätte etwas weniger Arbeit.
Grundsätzlich finde ich das Ganze aber eine feine Sache;)
Ich habe den PR jetzt um das Frontend erweitert. Da sind jetzt doch einige Zeilen zusammengekommen:
So könnte es aussehen:
Bei so vielen neuen Einstellungen sind diese jetzt standardmässig eingeklappt um langes Scrollen zu verhindern:
Drehenkoder:
LEDs:
Taster Zuordnungen:
Multi-Taster Zuordnungen:
Noch Anmerkungen, Vorschläge?
Sieht gleich viel besser aus
Ich hab mich heute Nachmittag mal ein bisschen umgesehen und hab ein wenig mit der Aufteilung und icons herumprobiert. Bin leider nicht fertig geworden mit herzeigbarem, aber da lässt sich bestimmt noch was machen
Ist das dann im Frontend-Branch eingecheckt?
Kann man schon machen, aber schöner und einstiegsfreundlicher für non-Techies is es schon per UI 
@tueddy Das ist funktioniell wirklich sehr geil geworden muss ich sagen .
Insbesondere ist es eine feine Sache, dass das zur Laufzeit aktiv wird. Habe ein bisschen was getestet (bei weitem nicht alles, will heute Abend noch ein bisschen testen) und sieht soweit gut aus. Allerdings scheint Farbton Start+Ende nicht aktiv zu werden - auch nach einem Neustart nicht.
Ich habe das Ganze jetzt endlich mal zum Anlassen genommen und die Frontend-Dokumentation geschrieben, so dass man im Webinterface auch drauf verweisen kann. Ich werde das noch in einen Wiki-Eintrag konvertieren, so dass auch andere Leute daran Änderungen vornehmen können, so dass Änderungen da sofort eingetragen werden können (ohne mich).
So einige Dinge sind noch eingeflossen, z.B. Farbton Start/Ende für den Playlist-Fortschritt sind jetzt als Farb-Slider ausgeführt & viel klarer, Besonderen Dank an @trainbird !
Es gibt aber noch ein größeres Problem: Werden mehrfach Werte geändert & gespeichert wird jedesmal der LED-Task neu gestartet. Irgendwann reagiert der Task dann nicht mehr. Entweder wird der Speicher nicht richtig aufgeräumt oder der Task nicht richtig beendet bevor er neu gestartet wird. Ich muss da noch die genaue Ursache finden aber so scheint es noch nicht sauber. Evt. ist der LED Task Neustart überhaupt nur notwendig wenn sich die Anzahl der LEDs geändert hat.
Mach doch ne Zusätzliche Reload Funktion anstelle der Init. Dann kann besser darauf reagiert werden und geprüft werden ob da Äderungen sind
Den Led-Task nach Übernahme der dynamischen Einstellungen neu zu starten hat nicht gut funktioniert, er blieb in vielen Fällen hängen. Daher habe ich es umdesignt:
Der Led-Task läuft jetzt immer und bekommt eine Task-Nachricht wenn sich etwas geändert hat. Das funktioniert bei meinen Tests jetzt absolut stabil & die geänderten Einstellungen werden sofort angezeigt. Um beim Refactoring möglichst keine Bugs einzuschmuggeln bin ich so vorgegangen:
Man könnte sicher die globale Variable noch ganz in den Task verschieben & es noch weiter optimieren, aber für mich ist es so erstmal fein. Mag es noch jemand testen, gibt es Anmerkungen?
Es werde es kurzfristig testen und nochmal Feedback geben.
Wenn man Sachen hochlädt, pausieren wir ja glaube ich den LED-Task. Das ist im Einklang mit deinem jetzigen Refactoring?
Danke für deine Arbeit!
