Das ist bei mir alles ein „endpoint“ welcher ein JSON bekommt wo drin steht was passieren soll.
Execute CMD - Hier übergebe ich z.B. einfach Befehle aus der values.h
Get-Settings
Get-File-List
usw.
Will sagen, ich habe das nicht auf verschiedene Endpoints aufgeteilt, sondern in der web.ccp eine Funktion, die den empfangenen JSON auswertet. Aber kann man sicher auch anders machen.
Die gibt es ja schon - unter anderem Namen. Da musst Du nicht viel machen.
Ich habe fast alles auf WebSockets umgestellt. Aber das ist halt die Frage. Wenn Du vom Client per GET abfragst und immer nur eine Antwort bekommst, kommst Du auch ohne WebSockets aus. Das macht es deutlich einfacher. Ich habe es so implementiert, dass der Client per WebSocket einen Befehl sendet und dann auch per WebSocket 1-n Antworten bekommt. Das hat z.B. den Vorteil, dass wenn große Verzeichnisse gelesen werden, sehr schnell die ersten Daten kommen und sich das Verzeichnis in der UI aufbaut.
Wenn der Client ein „Init-Me“ sendet - sich quasi anmeldet - bekommt er alle x-Sekunden eine Status-Info. Er würde z.B. auch die Info bekommen, dass ein neues Cover-Bild vorhanden ist, dieses müsste er dann aber per HTTP-GET abholen.
So gesehen ist Dein Ansatz, erst einmal aufzuräumen, sicher gut - Ich habe zu viele Funktionen gleichzeitig implementiert. Ich geniesse es allerdings auch im privaten Bereich mal herrlich unstrukturiert das zu machen was gerade Spaß macht
Guten Morgen und danke für die Einblicke, @Christian.
Ich bin großer Verfechter von „separation of concerns“ in der Softwarearchitektur, weil es langfristig einfach den Code sehr viel wartbarer macht. Daher die strikte Aufteilung der Endpoints. Ich möchte genau die Daten holen oder schreiben können, die mich interessieren, ohne den Overhead dafür zu erhöhen. Macht die Code Basis letztlich schlanker.
Auch da würde ich mich auf Sockets beschränken, wo es notwendig ist. Für konstante Datenströme oder viel Verkehr (z.B. der Explorer) ist das natürlich vorteilhaft.
Was man, wenn man eh keine externen Quellen nachladen muss, direkt aufgeben sollte, ist die Access-GUI. Da sollte man dann einfach immer die Mgmt-GUI anzeigen.
Nur was dann aber auf jeden Fall rein muss, ist ein PWD-Schutz. Das wurde hier immer mal wieder andiskutiert, aber letztlich war der potentielle „Schadvektor“ über die Access-GUI auch ziemlich begrenzt. Das würde sich jetzt natürlich ändern. Vielleicht macht man das der Einfachheit halber jedoch so, dass man nicht die GUI selbst sondern den Zugang für den AP des ESP32 mit einen PWD versieht. Dafür braucht man hier lediglich ein zweites Argument für das Passwort. Vorteil: Das Passwort gibt man dann pro Zugangsgerät (Handy, Laptop) nur exakt einmal ein, wenn man sich erstmalig mit dem Netzwerk verbinden will und dann nervt das nie wieder. Man muss sich nur überlegen, wo man das PWD speichert. Also ob man es via settings.h hartkodiert oder ob man es in die GUI zieht und im NVS speichert. Der zweite Fall ist sicherlich komfortabler, allerdings sollte man dann das PWD beim Start in der seriellen Konsole anzeigen (das halte ich sicherheitstechnisch für vertretbar), da sich sonst garantiert irgendwelche Leute früher oder später aussperren .
Also grundsätzlich bin ich dafür, und das hast du mir per PM ja auch vorgeschlagen, dass man die aktuelle Funktionalität einfach erstmal abbildet und keine neuen Features einbaut. Aber die Abschaffung der Access-GUI ist aus meiner Sicht ein logischer Schritt, den man hier gleich mitmachen sollte. Weil räumt sofort den Code auf, bringt Komfort und ist eine logische Konsequenz.
Ja, und ja. Access-Seite würde ich auch direkt droppen bzw. die Funktionalität mit integrieren, Passwort gehört (meiner Ansicht nach) ins NVS und ebenso konfigurierbar in die UI. Ich werde den Use case bzw. Workflow dafür nochmal genau aufdröseln, wenn es soweit ist.
Settings-Seite sollte demnächst abgeschlossen sein inkl. Anbindung an’s (noch imaginäre) Backend. Als „Seiten“ sind nach eingehenden Monologen nur noch „Control“, „Collection“ und „Settings“ übriggeblieben, der Rest ist zu diesen Karten unter „Settings“ zusammengefasst worden.
Wording in den unteren Texten ist noch etwas „lala“ bzw. für den einfachen Benutzer zu technisch, fixe ich im Laufe der Weiterentwicklung.
Habe einen kleinen Mock-Server, um auch ohne Hardware ein Backend zum Testen zu haben. Soweit klappt alles erstmal ganz gut. Die kommende Woche ist dann die Control-Seite dran.
Falls jemand Lust und Laune hat, ein paar Regler zu schieben. Funktionieren tut davon noch nichts wirklich. Der „Reset“-Button setzt momentan auch alle anderen Regler auf der Seite zurück, weil der Mock-Server zu dämlich ist…
Sehr geil, die UI fühlt sich super modern an
Klasse auch das wir die Aktualiserungen in Echtzeit sehen können.
Svelte, kommt das aus Dänemark?
Sammlung → „Kartenzuweisung“, „Kartenverwaltung“, „RFID Karten“…
Für die Steuerung evt. noch ein Lautstärkeregler, kenne ich so von iOS Music und Spotify.
Der Hauptentwickler ist jedenfalls kein Däne, aber der Name hat definitiv etwas Nordisches.
Beim Begriff komme ich immer noch ins Straucheln: Nicht alle benutzen Karten, manchmal sind es auch Sticker (oder - Gott verhüte - originale Ton**figuren). „RFID“ hingegen mutet für meinen Geschmack etwas zu technisch an, wenn man z.B. (wie in meinem Falle) so eine Box an technisch eher wenig versierte Menschen verschenken möchte. Vllt einfach „Verknüpfungen“?
Lautstärke- und Helligkeitsdimmer kommt noch rein, ich hab erst gestern Abend mit der Control Seite angefangen.
Man könnte auch einfach den englischen Begriff „Tag“ oder lose übersetzt „Marke“ verwenden. Generisch vielleicht auch „Auslöser“.
Aber generell zum Thema: Finde es sehr gut und wichtig die Endpoints von der UI zu trennen. So ist es wesentlich einfacher neue Features hinzuzufügen.
Ich z.B. wollte andere Optionen für die Batteriekonfiguration hinzufügen (Fuel Gauge). Das war aber sehr umständlich und ich hab es dann bis eine neue UI kommt aufgeschoben.
Kann mir aber auch vorstellen, dass man dann zukünftig die ein oder andere Option die nur in settings.h einstellbar ist im Frontend verfügbar macht.
Dann wäre es sogar möglich, die komplette UI ohne viel Aufwand auszutauschen.
Falls das jemand braucht, ist auch eine Integration in Heimautomatisierungs-Software machbar (ohne MQTT).
Ja, der Aufbau einer in sich geschlossenen REST API ohne den Zuschnitt auf ein ganz bestimmtes Frontend hat definitiv seine Vorzüge. Sobald hier die ESPs eintrudeln, fange ich damit an.
Mittlerweile ändert sich meine Meinung ein wenig… Ohne Web Sockets gehen einige Sachen deutlich schlechter oder gar nicht. Vllt plane ich doch von Anfang an, alles darüber laufen zu lassen. Hab mir dazu auch Web UIs von kommerziellen Geräten (v.a. Audio-Interface aus dem Pro-Segment) angeguckt, die lösen das tatsächlich auch durch die Bank weg mit Sockets, aus recht gutem Grund.
Und da geht die saubere Strukturierung vorerst flöten…
Ich hab mir jetzt auch mal die Demo und den Code angeschaut.
Feedback: Finde die UI im Design und der Steuerung super. Vor allem die Card-Based Einstellungsseite. Persönliche Meinung: Akku, Lautstärke, LED würde ich in einzelne Karten unterteilen.
Technische Frage: Ist es (später) möglich, einzelne Settings-Kategorien auszublenden oder auszutauschen? Frage ist aus persönlichem Interesse, weil ich gerne andere Batterieeinstellungen hinzufügen würde ohne die alten zu ändern. Aber ganz allgemein kann man ja auch eine Box ohne Batterie, ohne LEDs, ohne Kopfhörer, etc. bauen. Da wäre es natürlich ideal die Hardware in der UI widerzuspiegeln.
Technisch wäre das natürlich machbar (und auch erstrebenswert), aber vorerst wird nach Rücksprache mit unserem BDFL quasi nur die alte UI ersetzt. Features können dann später hinzukommen, sobald Parity mit dem bisherigen Code besteht.
.
