Entwicklung einer WebApp für AURORA

Hallo,

da es unter Windows immerwieder Probleme mit der Steuerung von aurora über WiFi per auverdionControl gibt, deren Ursache häufig in der PC-Konfiguration liegen (mal fehle Berechtigungen, mal spielt eine Firewall verrückt, dann schiesst wieder ein andere Programm quer, etc. pp) und der Support für Windows alleine vom Zeitaufwand ins unermessliche steigt, gibt es als Lösungsidee, die Steuerung und Parametrierung von Aurora nicht mehr über einzelne Apps für jede Plattform zu machen, sondern über eine ein WebApp.
Dazu wird auf dem Aurora-Board (genauer auf dem ESP32) ein kleiner Webserver ausgeführt. Der Anwender ruft nun die IP-Adresse des DSPs in seinem Browser auf und der ESP32 liefert dann eine Website aus, auf der alle Einstellungen vorgenommen werden können. Der DSP kann so komplett konfiguriert werden. Auch einfache Alltags-Einstellungen können so vorgenommen werden (Lautstärke, Presets..). Im Prinzip also der gleiche Funktionsumfang wie auverdionControl. Das heisst aber nicht, dass Hardwaresteuerung (Poti, IR, etc. pp.) dadurch fallengelassen werden. Hardware bzw. Planungen für Hardwareoptionen bleiben davon unberührt.

Die Lösung mittels WebApp hat mehrere Vorteile:
- Man sollte davon ausgehen, das der Browser immer auf Webserver zugreifen kann. Wenn er das nicht kann, sind bei dem PC ganz andere Dinge im Argen. Dann würde auverdionControl sowieso nicht laufen.
- Es muss nur noch der Code im ESP32 gepflegt und getestet werden anstatt das für jede Plattform einzelen.
- Es werden direkt alle Internet-fähigen Geräte mit einem Browser unterstützt (PCs, MACs, Tablets...)
- Da das Benutzerinterface als HTML-Datei auf dem ESP32 liegt, kann man sich sehr leicht eigene Benutzeroberflächen z.B. für eigene Dateien bauen ohne in die C++-Programmierung von auverdionControl einsteigen zu müssen.

Als Nachteil seh ich derzeit, dass man etwas tricksen muss, um mit dem begrenzten Speicher im ESP32 auszukommen, d.h die HTML-Datei darf nicht wahnsinnig gross werden. Viele bunte Bildchen ist also nicht...

In den vergangenen Tagen habe ich dieses Konzept schonmal ein wenig erprobt. Es wird darauf hinauslaufen, dass der ESP bei der ersten Browseranfrage die entsprechende HTML-Seite liefert. Diese beinhaltet einen JavaScript-Teil, der sich um das Senden und Empfangen von Parametern kümmert. JavaScript muss als zwingend im Browser aktiviert sein. Die gesamte folgende Kommunikation (Request und Response) läuft dann über JSON. Vorteil: Dies ist alles Standard und daher gut implementierbar.

Da ich beruflich aus der DSP-Ecke komme, wo C/C++ und Assembler mehr angesagt ist als JavaScript, werde ich Eure Hilfe benötigen. Helfen könnt Ihr durch Testen, Einbringen von Idee, Kritik und wer will, Programmschnipsel. Am Mittwoch, wenn ich von meiner Dienstreise zurück bin, werde ich mein Grundgerüst bei github einstellen.

Und nun los! Lasst Euren Gedanken freien Lauf!

Raphael

Hallo,

dann fang ich einfach mal an. :D

Finde die Idee super. Ich würde mir erst mal wünschen, so wie ich es im Thread schon gesagt hab, das man pro Board ne eigene IP vergeben kann.

Danke...

Zitat:

---

Zitat von rkv

Hallo,

Als Nachteil seh ich derzeit, dass man etwas tricksen muss, um mit dem begrenzten Speicher im ESP32 auszukommen, d.h die HTML-Datei darf nicht wahnsinnig gross werden. Viele bunte Bildchen ist also nicht...

---

Es müssen nicht alle Ressourcen von der selben Domain kommen! Verschiedene Frameworks (jQuery etc.) kann man sich auch von einer zentralen Domain holen, z.B. bei den "hosted libraries" von Google:
https://developers.google.com/speed/libraries
Man könnt auch andere größere Ressourcen direkt im Web hosten, z.B. auf einer Subdomain von auverdion.de?
Das hätte einen Nachteil: das Endgerät muss nicht nur mit Aurora sondern auch mit dem WWW verbunden sein. Aber auf welches Endgerät trifft das nicht zu?

Beste Grüße,
Werner

Hallo Daniel,

da jeder ESP32 eine andere Mac Adresse hat, bekommt auch jedes Board eine eigne IP von deinem Router.

Du kannst in deinem Router den Aurora Boards eine feste IP vergeben.
Das hat nicht mit der Programmierung zu tun, sondern ist Netzwerktechnik.

Naja, rein netzwerktechnisch gibt es da ja m.W.n. wohl zwei Möglichkeiten:

Man weist einem Endgerät im Router eine feste IP-Adresse zu, das Endgerät kann dann weiter in dem Modus bleiben, die IP-Adresse automatisch zugewiesen zu bekommen.

Oder man man weist dem Endgerät selbst eine feste IP-Adresse zu, so dass es nicht mehr auf "automatisch beziehen" oder so eingestellt ist. Die IP-Adresse muss dann natürlich aus einem Adressbereich stammen, der außerhalb des vom DHCP-Server des Routers feilgebotenen Bereiches liegt.

Über die Vor- und Nachteile beider Methoden bin ich mir allerdings nicht so im klaren. :denk:

Diese Enstellungen finden auf Endgeräteseite eigentlich auf Betriebssystemebene statt und wohl eher nicht in der darauf laufenden Software.

Ansonsten: ich habe mich schon öfter gefragt, warum bei Geräten wie DSPs nicht ähnlich wie bei Routern häufiger mit Web-Interfaces gearbeitet wird. Man würde sich eine Menge Kompatibilitätsprobleme sparen. Daher:

Super Idee. :prost:

Viele Grüße,
Michael

Hallo Michael,

im Netz findest du viel über DCHP vs. Feste IP.
z.B. https://www.router-forum.de/router-f...rgeben.t64336/

Wenn die Adresse fest im Router eingetragen ist, braucht man nur die Adresse in der Setting.ini einzutragen. Die dann auf den Esp hochladen und fertig ist die Verbindung. Dazu muss man einmal die Mac Adresse des Aurora Boards kennen.

Was den Esp allgemein betrifft rentiert ein Blick auf https://fipsok.de/Esp32-Webserver/Esp32

Zitat:

---

Zitat von mcdwerner

Das hätte einen Nachteil: das Endgerät muss nicht nur mit Aurora sondern auch mit dem WWW verbunden sein. Aber auf welches Endgerät trifft das nicht zu?

---

Da sehe ich 2 Punkte:
1) Angenommen der Internetzugang ist gestört bzw. nicht möglich, warum auch immer. Könnte z.b. auch beim mobilen Einsatz mal der Fall sein. Was wäre dann?
2) Wie sieht es mit der Netzwerksicherheit aus? Bei der Gelegenheit: gäbe es eigentlich die Möglichkeit, den AP-Zugang ohne großen Aufwand mit Passwort zu schützen?


Allgmeine Frage. Wieviel Speicherplatz wäre denn auf dem esp32 noch frei?

Zitat:

---

Zitat von mcdwerner

Man könnt auch andere größere Ressourcen direkt im Web hosten, z.B. auf einer Subdomain von auverdion.de?
Das hätte einen Nachteil: das Endgerät muss nicht nur mit Aurora sondern auch mit dem WWW verbunden sein. Aber auf welches Endgerät trifft das nicht zu?

---

Z.B. wenn man den DSP aus bestimmten Gründen nicht in das heimische Netzwerk einbinden will ihn aber per iPad konfigurieren möchte. Dann hat man nur die Möglichkeit das iPad mit dem Access Point zu verbinden, das iPad kann nicht mit zwei WiFis gleichzeitig verbunden sein, soweit ich weiss.

Zitat:

---

Zitat von sion

Allgmeine Frage. Wieviel Speicherplatz wäre denn auf dem esp32 noch frei?

---

Für die WebApp stehen ungefähr 1MB zur Verfügung. Damit kann man schon einiges Anstellen.
Wenn wir auf webOTA verzichten kommen noch mal 1MB freier Speicher oben drauf, dann muss man bei einem Firmwareupdate über USB2Serial gehen. DSP Plugins können weiterhin drahtlos eingespielt werden. Mittelfristig finde ich den Verzicht auf webOTA aber nicht schön. Wenn drahtlos, dann bitte auch alles drahtlos und nicht so halb gegoren.

Moin
Da es mir jetzt gerade in den Fingern gejuckt hat und ich ein paar Minuten Freizeit hatte, musste ich auch mal meine Idee zum Input Preset umsetzen.
Vllt wäre dies ja eine zusätzliche Möglichkeit, diese zu realisieren.

Wäre es möglich, mehrere Seiten zu erstellen und diese dann durch unterschiedliche IPs aufzurufen? So könnte man der Unübersichtlichkeit einer allumfassenden GUI entgegenwirken.


Mfg
Julian

Zitat:

---

Zitat von Rainer

Hallo Daniel,

da jeder ESP32 eine andere Mac Adresse hat, bekommt auch jedes Board eine eigne IP von deinem Router.

Du kannst in deinem Router den Aurora Boards eine feste IP vergeben.
Das hat nicht mit der Programmierung zu tun, sondern ist Netzwerktechnik.

---

Ja stimmt, soweit habe ich gar nicht gedacht. Dann passt das ja wohl.

Moin
Und schon kommt meine nächste Idee. Die Möglichkeit, ein Monosignal für jeden Output-Kanal zu erzeugen, denn so manches mal möchte man auch ein "Mono"-Signal für Subwoofer erstellen.
Hoffentlich habe ich mich verständlich ausgedrückt. :D

Im Anhang dazu eine Umsetzungsidee.


Anhang 52430
Anhang 52431

Hi JuBa3006,

so ganz verstehe ich die Logik da dahinter jetzt nicht.
Was ist bei 8 ( oder mehr ) Eingangskanälen "Mono"?
Da müsste man doch definieren können, welche Inputs genau auf den jeweiligen Output aufsummiert werden sollen? Oder?

Gruß
Bernhard

Edith: wer lesen kann, ist klar im Vorteil: :eek::(
Bei Aktivierung von Mono geht ein 2. Inputfenster auf?!.
Wär da nicht generell freies Routing eine gute Alternative?

Moin
Du hast es schon richtig erkannt. :prost:
Somit kann man das einfach variieren, wenn man will.
Ich denke das ist schon sehr offen. Es geht immer mehr, aber das wäre für mich eine bedienbare alternative, die eigentlich so gesehen keine Nachteile darstellt. Also nur von der Bedienbarkeit her ;)

Ich finde es gut, wenn man die Möglichkeit hat, aber wenn man sie nicht braucht, optisch nicht überladen wird. ;)

Da ich beruflich im Moment 'ne Menge mit Webentwicklung zu tun habe:

Finger weg von irgendwelchen Bastellösungen mit jQuery (Igitt!) oder irgendwelchem Kruden Template Kram mit PHP :eek: und Konsorten.

Meine Empfehlung:
Angular für's Frontend und Node, ggf. mit nativem C++ Addon, für's Backend.

Um Gottes willen nichts noch extern (bspw. von Google) reinladen, für sowas gibt es heutzutage Bundler.

Dann wird das auch amtlich.

Zitat:

---

Zitat von java4ever

Meine Empfehlung:
Angular für's Frontend und Node, ggf. mit nativem C++ Addon, für's Backend.

---

Node auf dem ESP zum Laufen zu bringen wird spannend ;-)

Och, mit genügend Hass geht das sicherlich.
Ansonsten low.js

Das Problem bei Backends in C++ ist, vor allem bei offenen Community Projekten, dass das am Ende in 99% der Fälle in einem unwartbaren Haufen aus Code Smells und Antipattern resultiert...


EDIT: Huch, ich hatte den ESP32 ja mit *ganz* anderen Größenordnungen in Erinnerungen. Mea Culpa.
Das könnte tatsächlich spannend werden...

Zitat:

---

Zitat von java4ever

Angular für's Frontend

---

Das ist an sich ein prima Framework. Sehr mächtig. Und damit leider auch komplex und mit hoher Einstiegskurve.
Da in TypeScript entwickelt wird, braucht man zum übersetzen in JS eine node.js Installation. Besser noch NPM dazu.
Denke das ist für dieses FE hier eher etwas Overkill. Zumal auch die Lernkurve dafür recht steil ist.

Mein Tip wäre eher vue.js.
Das ist schlanker, hat einen einfacheren Einstieg und ist direkt im Browser lauffähig. Zudem wurde es bereits zum 4. Mal in Folge auf Github zum FE-Projekt des Jahres gewählt. Ist also kein kompletter Exot ;)
Dazu noch vuetify zum "schön" machen.
Zusammen wären das ca 200KB. Bleibt also noch Platz für das eigentliche FE.

So oder so macht ein Framework hier wohl Sinn, weil es einfach den eigentlichen Code schlanker und besser wartbar macht.

Und wer hat Lust und Zeit diese Vorschläge zumindest als Gerüst auch zu implementieren?

Eine einfache Steuerung könnte bspw. so aussehen.
Anhang 52449

Die verlinkten JS&CSS Files kann man natürlich auch lokal auf dem ESP ablegen.
Um Platz zu sparen, können die verwendeten Icons auch entweder weglassen oder durch eigene ersetzen werden.

@icebaer
Sehr nette Aufmachung. Finde ich sehr gut für die einfache Bedienung. Alternativ könnte man vllt. unten noch eine Anzeige für den derzeitigen Wert [dBsf Volume] machen.
Aber so in der Art, hatte ich mir das auch vorgestellt.

Ich würde mir wünschen, das alles Lokal liegt und kein externer Zugriff statt findet.

// Ich weiß nicht, in wieweit ich Raphael helfen kann. Denn ich bin schon längere Zeit aus dem Thema raus und bin gerade wieder beim einarbeiten. Ich könnte versuchen eine GUI zu erstellen. Jedoch wäre dafür eine Struktur interessant, damit man nicht ins blau läuft :p
Das tatsächliche Leben müsste dann im Nachgang von Ihm selbst eingehaucht werden, bzw er könnte die Oberfläche als Anhaltswert nehmen?

Zitat:

---

Zitat von JuBa3006

Alternativ könnte man vllt. unten noch eine Anzeige für den derzeitigen Wert [dBsf Volume] machen.

---

Also so in etwa ;)

Zitat:

---

Zitat von JuBa3006

Ich würde mir wünschen, das alles Lokal liegt und kein externer Zugriff statt findet.

---

Das muss es sowieso, wie Raphael schon richtig erwähnt hat. Wenn man mit dem DSP als AP verbunden ist, hat man u.U. keine andere Verbindung nach draussen.

Zitat:

---

Zitat von JuBa3006

Jedoch wäre dafür eine Struktur interessant, damit man nicht ins blau läuft :p
Das tatsächliche Leben müsste dann im Nachgang von Ihm selbst eingehaucht werden, bzw er könnte die Oberfläche als Anhaltswert nehmen?

---

Dafür war die GUI an sich auch gedacht, um zu zeigen wie so etwas mit vue.js aussehen könnte.
Man sollte sich halt auf eine Basis einigen, egal welche das nun ist.

Exakt das meinte ich ! :prost:
Ich bin mal gespannt wo die Reise hingeht. Vllt bekomme ich meinen Vorschlag mal fertig, aber derzeit ist es doch noch einiges, was ich wieder aufholen muss -.-'

So ich werde vllt. noch heute Abend mit meiner Version für die ersten Eindrücke fertig.
Nicht perfekt und auch nicht die Ideallösung, aber bestimmt eine gute Grundlage zum diskutieren.

Anhang 52450

Zitat:

---

Zitat von icebaer

Das muss es sowieso, wie Raphael schon richtig erwähnt hat. Wenn man mit dem DSP als AP verbunden ist, hat man u.U. keine andere Verbindung nach draussen.

---

Somit wird alles schwieriger, bzw man muss zweimal überlegen. So geht es zumindest mir.

Zitat:

---

Zitat von Micha_HK

Und wer hat Lust und Zeit diese Vorschläge zumindest als Gerüst auch zu implementieren?

---

Genau das habe ich auch gedacht, aber mich nicht getraut, es zu sagen. :p

So, ich habe die letzten Nächte an der webapp gebastelt. Anbei ein erster Screenshot. Mir ist klar, dass das alles noch schöner und eleganter geht. Ich finde sie z.B. derzeit noch viel zu bunt. Würde sie mir etwas eleganter wünschen. Anyway. Das Ding soll ja auch erstmal dazu dienen, das Gerüst unter der Haube zu bauen. Und das macht sie jetzt. Der ESP32 liefert die gezeigte Website aus und kommuniziert mit ihr anschliessen über JSON requests und responses.
Die html-Datei ist derzeit nur 37KB groß und kommt ohne externe Module oder sonst was aus. Lediglich ein HTML5-fähiger Browser und JavaScript wird benötigt. Beides sollte kein Problem sein in 2020.
Ich werde mich jetzt erstmal darum kümmern, die Kommunikation zwischen ESP32 und ADAU1452 nun nachzuziehen. Das ist eine kleine Fleißarbeit. Copy&Paste aus der alten Firmware.
Vorher werde ich einen feature-Branch bei GitHub erstellen und den bisherigen Stand hochladen, dann könnt ihr damit gerne schon spielen.

Raphael

Schaut doch schon vielversprechend aus.

P.S. Ich habe mich jetzt erstmal auf firefox konzentriert. D.h. mit anderen Browsern kann es etwas anders aussehen, weil ich noch nicht alle graphischen Anpassungen gemacht habe.

Moin Raphael,

das sieht doch schon amtlich aus! Sehr schön. Ich finde die Möglichkeit der Input-Wahl sehr schön.
Was hälst du von der Idee für das Input-Routing? Die Sidebar könnte dann die Menüführung übernehmen um so die Übersichtlichkeit zu wahren.

Hallo zusammen,

ich hätte da auch noch eine Idee wie man das Platzproblem eventuell totschlagen kann :)

Einfach die Benutzeroberfläche mit Ionic (basiert auf Angular) entwickeln

Die daraus resultierende Website (die ist natürlich auch im Browser lauffähig) kann man dann mithilfe von Cordova zu einer APP für alle möglichen Systeme bauen lassen (IOS, Android, Windows PC, etc)
-> Dann muss quasi nur noch das Backend (egal in welcher Sprache) auf dem esp32 liegen/laufen und über die JSON Schnittstelle die Daten zur Verfügung stellen (Weil ja das Frontend schon auf dem jeweiligen Gerät liegt :D )

Wenn dann immer noch Platz auf dem ESP ist und man die "Website" noch drauf bekommt, kann man die dann immer noch zusätzlich über den Browser aufrufen.

Ich kann da gerne mal was basteln, wenns da mal eine JSON Schnittstelle gibt, die auch einigermaßen dokumentiert sein muss :D

Zitat:

---

Zitat von KeVKeR

Die daraus resultierende Website (die ist natürlich auch im Browser lauffähig) kann man dann mithilfe von Cordova zu einer APP für alle möglichen Systeme bauen lassen (IOS, Android, Windows PC, etc)

---

Genau dass will ich ja erstmal vermeiden: Eine eigene App für jede Plattform. Der Supportaufwand ist enorm. In einem zweiten oder dritten Schritt kann man das durchaus überlegen, ich habe auch schon diese Tools gesehen, die aus einer Webapp eine native App machen. Aber wie gesagt, mit einer nativen App bin ich gehörig auf die Fresse geflogen.

Zitat:

---

Zitat von KeVKeR

Ich kann da gerne mal was basteln, wenns da mal eine JSON Schnittstelle gibt, die auch einigermaßen dokumentiert sein muss :D

---

Nur zu. Du bist herzlich willkommen. Derzeit habe ich nur den JavaScript-Code, der die JSON-Objekte erzeugt. Wenn Dir das reicht? Wird sich aber in den nächsten Tagen noch etwas verändern.

@all: Es ist mir heute erfolgreich gelungen, ein DSP-Plugin hochzuladen und über die Webapp die Lautstärke zu verändern :prost: Im nächsten Schritt jetzt das Gleiche nochmal für alle anderen Parameter. Eine kleine Fleißaufgabe für das Wochenende...

Zitat:

---

Zitat von JuBa3006

Moin Raphael,

das sieht doch schon amtlich aus! Sehr schön. Ich finde die Möglichkeit der Input-Wahl sehr schön.
Was hälst du von der Idee für das Input-Routing? Die Sidebar könnte dann die Menüführung übernehmen um so die Übersichtlichkeit zu wahren.

---

Julian, würdest Du mir den html-Code für die Sidebar schicken, dann würde ich das wohl übernehmen wollen, wenn es Dir recht ist?

Sehr cool !

Hi Raphael,

erst mal danke für deine Bemühungen und ich weiß du hast momentan andere Probleme aber was ich nicht verstehe warum kann man nicht bei jedem Filter bestimmen welche Art Filter ich anwenden will (LS, HS, PEQ usw.)? Es gibt nur einen fixen Highshelv und Lowshelf?

lg Alpi

Zitat:

---

Zitat von rkv

Genau dass will ich ja erstmal vermeiden: Eine eigene App für jede Plattform. Der Supportaufwand ist enorm. In einem zweiten oder dritten Schritt kann man das durchaus überlegen, ich habe auch schon diese Tools gesehen, die aus einer Webapp eine native App machen. Aber wie gesagt, mit einer nativen App bin ich gehörig auf die Fresse geflogen.




Nur zu. Du bist herzlich willkommen. Derzeit habe ich nur den JavaScript-Code, der die JSON-Objekte erzeugt. Wenn Dir das reicht? Wird sich aber in den nächsten Tagen noch etwas verändern.

---

Hmm eigentlich hat man aber nur 1 mal programmier Aufwand -> Und am Ende plummst auf jedenfall immer eine funktionierende Web Oberfläche raus :P -> Naja kann man ja immer noch machen :)

Hast du denn zu den einzelnen JSON-Objekten Klassen? Oder ist das noch alles in einer Datei :P Ist das im Git? Dann gucke ich mal :)

Ich hab da mal schnell was in Ionic zusammen programmiert :P Ist wohl noch keinerlei Logik hinter...

Ich habs mal versucht so nah wie möglich an auverdionControl zu bleiben :)

Fehlt natürlich noch einiges und unübersichtlich ist es auch noch... -> Aber so könnte man mal sehen wo die Reise hin geht

Ist auf jedenfall responsive und läuft auch als App :P

Anhang 52507

Sieht gut aus, jetzt aber die Gretchenfrage: Wieviel Speicher inkl. benötigert Frameworks etc. pp. benötigt das?

Zitat:

---

Zitat von rkv

Sieht gut aus, jetzt aber die Gretchenfrage: Wieviel Speicher inkl. benötigert Frameworks etc. pp. benötigt das?

---

Zu viel :( :( :( :( -> kompiliert noch 15Mb :( kacke...

Ich denke, dass man bei 2Mb gänzlich auf Frameworks verzichten muss - das wird dann einfach viel zu groß :( Aber wie gesagt, man muss die Ressourcen ja nicht unbedingt auf dem DSP ablegen, sondern man kann das auch lokal. Dann muss nur das Backend auf den ESP32.

Womit programmierst du das Backend jetzt eigentlich Node.js? oder was ganz anderes?

Moin Raphael,

Wie schaut der Entwicklungsstand aus?
Was gibt es derzeit für Problemstellungen und wie schaut dein Fahrplan aus ? Ich frage mal so aus reiner Neugierde:prost:



Mfg
Julian

Guten Abend,

habe gerade den aktuellen Stand bei github hochgeladen.
Die Bedienung der wesentlichen Filterblöcke funktioniert jetzt. Der DSP reagiert auch auf Benutzereingaben, wie gewünscht. Gleichwohl habe ich noch nicht alle Kanäle durchgetestet, das sind über hundert Filterblöcke, die getestet werden wollen. Das ist noch ein wenig Fleißarbeit. Für meinen persönlichen Geschmack empfinde ich die GUI derzeit als etwas zu bunt. Aber dem habe ich jetzt vorerst geringere Priorität zugewiesen.

Programmiert ist das ganz simple in HTML+CSS+JavaScript, der ESP32 ist in C++ programmiert. Also kein neumodisches Zeugs wie Node.js oder so. Das übersteigt meine Intelligenz. :prost: Derzeit ist auch noch alles in eine HTML-Datei gepackt. Ich würde das gerne noch ein wenig aufteilen, z.B. CSS in eigene Datei etc. pp.

Wer will und mutig ist, kann ja selber ein wenig testen und probieren. Aber Achtung, alpha-Version!!!

Im nächsten Schritt werde ich das Speichern von Presets unter besonderer Berücksichtigung von Eingangswahl bei installiertem oder nicht installiertem AddOn machen. Der Vorteil ist, daß vieles schon als Sourcecode existiert und wiederverwendet werden kann.

Raphael

Es gab in der Zwischenzeit einige Commits. Die neueste Version findet ihr hier:
https://github.com/freeDSP/freeDSP-a...S/WEBAPP/ESP32

Zum Ausprobieren muss die Webapp nicht notwendigerweise auf dem DSP installiert werden. Ihr könnt auch einfach das Repository herunterladen und die Datei dsp.html in webapp/aurora/data im Browser laden. Dann funktionieren halt nur die Dinge nicht, die eine Rückmeldung vom DSP brauchen.

Es fehlt eigentlich nur noch die Möglichkeit, ein anderes Plugin auf den DSP hochzuladen. Ansonsten ist der Funktionsumfang schon sehr nah an auverdionControl.

Raphael