Nein, der existiert bisher nur als Mockup bei mir. Ich wollte mal warten, bis der vorherige stand eingepflegt ist bevor ich weiter mache. Und Zeit hatte ich auch grad keine 
Ja, auf jeden Fall alles rein.
Wir brauch folgende Sachen:
a) Komplett konfigurierbar über WebUI
b) Wir brauchen eine Beschreibung hier in der Kategorie Dokumentation - ESPuino :: Rfid-controlled musicplayer, so dass man den User vom WebUI drauf verweisen kann. Also dass man eine Vorstellung davon kriegt, was dieses Feature macht.
c) Das hat @tueddy ja schon erwähnt: Es braucht, am besten im Rahmen von b, auch eine Beschreibung, was zu tun ist, um den Serverdienst selbst aufzusetzen.
d) Ansonsten muss der Code noch CLANG-konform werden und etwaige Loggings müssen, statt über serial.print() entsprechend über unser Logging laufen. Aber du hattest ja gesagt, dass das Ganze noch WIP ist. Ich will’s nur erwähnt haben 
Wenn das dann soweit getestet ist, dann einen PR für den dev bereitstellen und dann mergen wir das rein.
An der Stelle schon mal danke für deine Arbeit 
.
Ich würde gerne die commands dahin ändern, das man Parameter angeben kann.
Dann können wir die Befehle vereinfachen und besser personalisieren.
Zb. Die Timer cmds als Parameter die Zeit,
Bei den ein/aus commands das ein/aus/toggle als Parameter
Bei den virtual rfid die TagID
…
Wäre zwar eine etwas größere Umstellung aber die könnte man auch fürs erste kompatibel mit dem aktuellen Code halten.
Das is ein guter Punkt, vielleicht sollte man unterscheiden in Einstellungen, die direkt nach dem einrichten des AP gemacht werden müssen und solche, die man auch laufend noch anpasst? So als eine Art Installationswizard. Den kann man dann auch später noch aufrufen, aber er ist nicht so wichtig wie bspw. MaxVolume.
Ja , das macht Sinn.
Gerade die PIN Configurationen oder Hardwareauswahl.
Das sehe ich mehr oder weniger auch so. Für die Hauptarbeit im Backend spielt das aber erstmal keine Rolle. Der Endpunkt /settings ist für den AP/STA Modus vorhanden. Dann muss man sich nur noch entscheiden, wohin die Einstellung im Frontend gehen soll.
Die Drehrichtungsumkehr oder z.B. die Anzahl der Neopixel könnte ich mir auch gut in der management.html vorstellen, diese Einstellungen sind da so in der Mitte. Dann wären wir wieder bei dem Thema AP/ Verwaltungsseite zusammenführen.
Aus Nutzersicht: Ich habe alles eingerichtet und stelle dann fest, dass die Lautstärkeregelung falsch herum ist. Dann müsste ich die WLAN Verbindung löschen um wieder in den AP Modus zu kommen und dann die Einstellung vornehmen, danach wieder mit dem WLAN verbinden.
Also etwas umständlich 
Mein Vorschlag: Wir nehmen diese Einstellungen zunächst in management.html rein. Edit: Und dann solche Einstellungen z.B. über ein „Erweitert“ Akkordeon einblenden
oder es gibt einen Knopf „Wizard neu starten“ und dann startet der AP mit allen vorherigen Infos vorausgefüllt
oder der Wizard ist von beiden Seiten erreichbar, sowohl vom AP als auch vom STA Modus… (natürlich auch mit den Daten von vorher ausgefüllt)
1 „Gefällt mir“
Den Teil hatte ich auch gedacht aber offenbar vergessen niederzuschreiben
Ja finde ich auch eine gute Idee.
Aktualisierung ArduinoJson von 6 auf 7 würde ich als nächstes vorschlagen
Ich verstehe zwar nur einen Bruchteil des hier Geschriebenen, aber die Grundidee finde ich als Anfänger sehr gut!
1 „Gefällt mir“
Ich habe mal die Machbarkeit für dynamische Hardware-Einstellungen getestet, so könnte es aussehen:
Das ist mir beim Testen aufgefallen:
Ich habe die Accespoint-Seite über http://espuino.local/ap auch im Stationsmodus aufrufbar gemacht, ein Schalter „Hardware“ in der Management-Seite ist also möglich & einfach. Aber auch unschön, da es mit dem Single-Page Konzept & Design bricht. Mein Vorschlag wäre hier die Hardwareeinstellungen sowohl in der Ersteinrichtung (Accesspoint.html) als auch in einem Reiter „Hardware“ oder aufklappbares Akkordeon in der management.html unterzubringen. Im Frontend zweimal, im Backend (Web.cpp) nur einmal.
Ein einziger „Submit“-Button erscheint mir nicht möglich, da sonst das bereits gespeicherte WLAN-Passwort wieder an das Web-UI übertragen werden müsste, was eine Sicherheitslücke wäre. Hier also ein „Submit“ für die WLAN-Einstellungen und einer für die Hardware-Konfiguration.
Die Umkehrung der Encoder-Drehrichtung funktioniert bei mir schon direkt nach dem Speichern, perfekt!
Schwieriger wird es mit dem dynamischen Ändern von NUM_INDICATOR_LEDS, NUM_CONTROL_LEDS und den anderen LED-Parametern. Das ist derzeit einfach zu statisch in Led.cpp! Wer hat das gemacht & wer kann helfen? @laszloh oder @Joe91 oder @fschrempf ?
Hier mein Testcode:
Ich freue mich über eure Meinung!
Ich würde das lieber vollständig im management.html realisieren und da per overlays und seitenweise wie es bei OS-installationen läuft. Damit hat man mehr Spielraum mit dem code, es ist cleaner von der ui her, es kann direkt wieder aufgerufen werden und spart die doppelte Implementierung.
Absenden kann man dann per „Weiter“ jeden schritt einzeln.
Insgesamt kann man auch überlegen das in ein eigenes HTML zu packen um den code zu reduzieren, aber da scheint es bedenken zu geben?
Die Frage ist, ob wir irgendwoher wissen, ob schon mal eingerichtet wurde? Vllt per LEDs auf -1 setzen und entsprechend den wizard starten?
Cool, dass das gleich funktioniert!
Wie soll das funktionieren? Mit so einem IFRAME, wird das überhaupt noch von den modernen Browsern unterstützt? Für die Accesspoint-Seite haben wir auch kein Bootstrap, JQuery usw. Ich sehe jetzt noch keine Möglichkeit den HTML-Code für beide Seiten zu verwenden?
Nein, kein iframe, das funktioniert nicht.
Ich hatte gemeint, eine neue HTML, die per http://espuino.local/wizard oder so erreichbar wäre. Dann wäre es schön getrennt und einfach wiederaufrufbar, aber hätte (nach der AP-Einstellung) auch schon mehr Power mit bootstrap und jquery per cdn.
Es würde dann auch nicht irgendeine Logik für die Entscheidung benötigt, ob man den wizard startet oder nicht.
1 „Gefällt mir“
Ja das habe ich schon verstanden die Einstellungen nur einmal anzulegen.
Aber wie sähe das konkret aus? Mit einem < embed>Tag? Evt. könnt Ihr es mal an einem Codeschipsel zeigen.
Ich hab leider grad keinen Computer bei der Hand, kann das also nicht prototypen, ist mal ein Gedanke.
Also der Ablauf wäre in etwa so:
- Erster Start: Accesspoint vom ESPuino, man kommt zur wifi-Konfiguration → save (wie bisher), dann weiterleiten auf http://espuino.local/wizard
- zweiter Start (im WLAN): der wizard führt einen Schritt für Schritt durch. Am Ende leitet es weiter auf http://espuino.local/ und man kann alles wie gewohnt nutzen.
- In den Settings gibt es dann einen Link zu http://espuino.local/wizard, damit man den wieder neu starten kann.
Kein einbetten, kein frame. Im Hintergrund liegt einfach eine separate HTML, über einen neuen Pfad (http://espuino.local/wizard), den man jederzeit wieder aufrufen kann.
Aber ich lese da große Ablehnung raus, weil alles single-page bleiben sollte … Versteh ich das richtig?
1 „Gefällt mir“
Nein, das hast Du falsch verstanden, ich bin da offen für alle Schweinereien, solange es das grundlegende Designkonzept nicht über den Haufen wirft. Und hier entscheide nicht ich sondern auch die Gemeinschaft & wenn’s mal ganz falsch läuft auch mal Papa ;-). Ein Wizard wäre OK für mich, es können da schon einige Eiinstellungen zusammenkommen, macht evt. Sinn die über mehrere Schritte zu verteilen…
Meine Bedenken gehen eher in Richtung Umsetzung, freue mich daher auf einen ersten Entwurf!
2 „Gefällt mir“
Alles was Grundeinstellungen sind welche eigentlich nie geändert werden,
wäre ich für nen Wizard der extra aufrufbar ist.
Evtl. ne NVS Setting ob der Wizard schon durchlaufen wurde und dann beim ersten Connect nach den WLAN-Settings anzeigen.
Oder auch wenn z.B. SDCard oder RFID nicht geladen werden kann.
Grundsettings sind für mich:
- PIN-Konfig
- Rfid PN5180 / MFRC522
- SDCard Mode
- Cloud-Url
- …
Auf jeden Fall! Das macht wenig Sinn, das auszulagern und dann alles auf einen screen zu packen
Da bin ich eben zu wenig bewandert, wie das am ESP funktioniert und was da technisch die schönste/geschickteste Lösung ist und entsprechend offen für Inputs
Zunächst ein frohes neues Jahr!
Bevor es zu den Hardwareeinstellungen geht habe ich mal diese #defines in zur Laufzeit änderbare Einstellungen umgewandelt:
NUM_INDICATOR_LEDS
NUM_CONTROL_LEDS
CONTROL_LEDS_COLORS
NUM_LEDS_IDLE_DOTS
OFFSET_PAUSE_LEDS
PROGRESS_HUE_START
PROGRESS_HUE_END
DIMMABLE_STATES
REVERSE_ROTARY
BUTTON_0_SHORT - BUTTON_5_SHORT
BUTTON_0_LONG - BUTTON_5_LONG
BUTTON_MULTI_01 - BUTTON_MULTI_45
Damit kann zur Laufzeit z.B. Anzahl der Neopixel oder Kontroll-LEDs, Richtung des Drehimpulsgebers oder die Zuweisung der Tasten geändert werden.
Weil es so viel ist habe ich zunächst nur das Backend als PR eingestellt. Der PR ist voll abwärtkompatibel, d.h solange die Einstellungen im Web-UI noch nicht verfügbar sind fallen sie auf die #defines zurück.
Schaut es euch hier mal an, vor allem Led.cpp:
Ich habe die Einstellungen in management.html getestet, so könnte es dann aussehen.
Für die Fertigstellung/Verschönerung des Web-UI könnte ich noch etwas Hilfe gebrauchen, wer möchte sich beteiligen, evt. @trainbird ?
2 „Gefällt mir“