Das wird aktuell gerade umgesetzt: Refactoring des Web Interfaces und der REST API.
Ich hatte das jetzt erstmal Quick&Dirty umgesetzt.
Also eigentlich verhindern, dass die Seite des APs geladen wird und stattdessen die normale Seite laden wenn kein Wlan da ist.
Dann im Ordner .html eine angepasste HTML-Seite wo die ganzen Javascripte und CSS Dateien durch zwei einzelne lokale Dateien ersetzt werden in denen alle JS und CSS Dateien zusammengefasst sind + zwei Dateien von FontAwesome in dem Ordner ablegen.
Im webServerstart() reicht dann die zusätzliche Zeile
wServer.serveStatic(„/“, gFSystem, „/.html/“).setCacheControl(„max-age=1200“);
Im Endeffekt sind also zwei Zeilen Code verändert und eine hinzugekommen.
Kann ich heute Abend ja mal in nem Branch reinpacken.
Das reicht aus meiner Sicht so nicht aus, weil damit bietest du die MGMT-GUI an, während du einen ungesicherten AP stellst. Damit kann sich ja jeder verbinden und beliebigen Quatsch machen.
Ich will da eigentlich nix mehr dran ändern, da @sonovice an dem Thema ja eh dran ist. Aber das soll dich natürlich nicht abhalten, das in deinen Branch aufzunehmen.
Ja klar, das war jetzt ja auch nur Quick&Dirty, weil ich über das Wlan vom Park nicht auf die GUI gekommen bin. Man könnte das ja auch nur aktivieren, wenn ein Passwort für den AP gesetzt ist.
Weiter hab ich dann auch nicht mehr gemacht, weil dann ja das Kabel kaputt gegangen ist.
Moin,
bin gerade dazu gekommen mal mit der Version der Lib zu testen und siehe da, es gibt keine Störgeräusche mehr …
1 „Gefällt mir“
Ich hab nun die Änderungen mal per Pull-Request rüber geschickt.
1 „Gefällt mir“
Hey @Xento , ich versuche deinen Branch gerade für mein ESP Muse Proto zu bauen - zusammen mit PN532, drei Buttons und einem HW-040 Rotary Encoder.
Für welches Env Platform baust du letztendlich in Platform.io? Und muss ich die settings-muse-luxe.h irgendwo explizit includen?
Danke
Lukx
Nimm am besten diesen Branch:
GitHub - Xento/ESPuino at dev
Ich weiß gerade nicht, ob ich die letzten Änderungen für den PN532 schon gepusht habe.
Da hatte ich noch ein paar Fehler drin.
Ich hab für den Muse Luxe eine eigene Plattform erstellt, dann kann man im VS Code direkt dafür bauen lassen.
Ich schau morgen mal, ob ich alle Änderungen gepusht habe.
Super, danke! Bei mir scheint etwas in platformio.ini zu fehlen, nach dem Flashen lande ich in einer Reset Loop mit 0x33, keine Ahnung was das bedeutet 
Würd mich freuen Deine Plattform und ggf. noch andere Settings zu bekommen!
Ich habe gerade meinen aktuellen Stand gepushed.
An der Plattform hat sich aber nichts geändert.
Ich hatte am Anfang auch Abstürze, da lags aber daran, dass ich die falsche Partitionen genommen habe.
Mit dem 4 MB hats dann funktioniert.
Ich habe ESPuino gestern auf dem Muse Proto Board zum laufen bekommen:
- NeoPixel on-board vom Muse Proto Board
- Drehencoder KY-040 für Lautstärke
- 3 Taster für Play/Pause, Next, Prev
- PN532 als NFC-Reader via I2C
- Externer An/Aus-Schalter, weil ich das schon so im Gehäuse hatte
- Visaton FX 10/4 Ohm 2-Wege-Koaxlautsprecher
- 2x 18650 Akkus die vom MuseProto gemessen werden
Ich habe auf Basis des Branches von @Xento begonnen, musste aber an zwei oder drei kleinen Stellen etwas anpassen. Am Wochenende räume ich meinen Fork auf und versuche ihn so sauber zu kriegen dass er auch anderen hilft, die ein Muse Proto Board als Basis verwenden möchten.
1 „Gefällt mir“
Hey,
ich habe @Xento s Branch genommen und etwas reduziert, um für das Raspiaudio Muse Proto Board mit der genannten Peripherie zu funktionieren.
Danke an dieser Stelle an alle beteiligten, dass ich ein so tolles Projekt und so viel Forschung einfach „verwenden“ konnte.
Ich habe meinen Branch gesäubert und mal als PR gestellt, da ich glaube dass Muse Proto ein niederschwelliger Einstieg in ESPUino ist:
https://github.com/biologist79/ESPuino/pull/183
Basisert natürlich zu fast 100% auf Xentos Arbeit, danke!
Es freut mich, dass ihr das jetzt mit ESPMuse ans Laufen bekommen habt. Aber…
Ihr habt mir jetzt insgesamt 29 Commits über den Zaun geworfen. Dabei werden mitunter wild irgendwelche Sachen wild hin und her verschoben/konfiguriert, wieder gelöscht und weiß nicht was. Ich möchte mir ehrlich gesagt nicht die Arbeit machen, das alles in einen gesitteten Feature-Branch zu überführen und als squash commit zu mergen, um die History clean zu halten.
In der Vergangenheit habe ich im Prinzip so ziemlich alles in meinen Master aufgenommen, da ich die Feature-Forkerei im Nachbarforum irgendwie unübersichtlich fand. Das hat große Vorteile, bringt jedoch auch den Nachteil mit, dass das Feature-Set inzwischen so groß ist, dass das keiner mehr alles testen will und kann. Und so schleichen sich dann immer mal wieder Bugs in Funktionen ein, die mir nicht auffallen, da ich sie nicht nutze (und auch in Zukunft nicht nutzen werde). Das gefällt mir irgendwie nicht.
Also seid mir nicht böse, aber nachdem ich vor Ewigkeiten das Audiokit aufgenommen habe und es aber (mangels Zeit und Lust) nicht wirklich supporte, bin geneigt zu sagen, dass man ESPMuse lieber forken sollte. Spricht ja nix dagegen, dass ihr das hier supportet - ich freue mich ja, wenn das auch auf anderer Hardware läuft. Ich verlinke eure Branches auch gerne zentral.
Wie seht ihr das?
Also ich habe nochmal drüber nachgedacht:
Ich werde es doch aufnehmen, jedoch es ganz klar so kennzeichnen, dass es experimentell ist und ich dafür keinen Support übernehme.
Ich denke damit sollten alle Beteiligten leben können.
Hey,
Danke!
Ich hatte zwischenzeitlich überlegt, dass es reichen würde den PN532 zu mergen. Die Settings für das ESPMuse könnte man dann als settings-custom anderswo dokumentieren.
Falls das eine Option ist mit der du als Maintainer besser zufrieden bist würde ich
- dir ein PN532 zur Verfügung stellen (klar, löst das Zeitproblem nicht)
- den PR auf meinen Fix in der Sample-Override reduzieren
- Xentos PR für den 532 squashen und ggf aufräumen, sodass da weniger History und Nebenschauplätze sind
Wenn du auch den ESPMuse als experimental reinlassen magst, räume ich meinen PR auf und squashe ihn auf 3 Einheiten mit guten Messages (PN532, ESPMuse, sonstige Fixes)
Lass mich wissen was Dir lieber ist
Nein, wir müssen das nicht über Overrides machen. Wir können das normal integrieren. D.h. RFID_READER_TYPE_PN532_I2C als neuen RFID-Typ. Und auch ein eigenes Setting-File mit entsprechendem Eintrag in der platformio.ini.
Was aus meiner Sicht der optimale Zustand wäre:
- PN532 als eigener squashed commit. Hinter RFID_READER_TYPE_PN532_I2C steht als Kommentar „use PN532 via I2C (experimental! Please review ESPMuse)“
- ESPMuse als eigener squashed commit. Im Settings-File von ESPMuse oben im Kopf bitte ebenfalls auf den Thread hier verweisen und hinschreiben, dass offiziell nicht supportet wird.
- An den Grundeinstellungen, die aktuell im Master sind, werden keine Änderungen vorgenommen.
Wie ihr das mit der Autorenschaft beim sq. Commit macht, das müsst ihr unter euch ausmachen 
Alternativ, anstelle hier in den Thread zu verlinken, kannst du auch einen neuen Thread aufmachen, indem ESPMuse so ein bisschen beschrieben wird und was es braucht, um das mit ESPuino zum Laufen zu bringen. Also dass man einfach direkt im ersten Post sieht, was gemacht werden muss, ohne sich durch den kompletten Thread zu hangeln. Und darauf verweist du dann in den settings-Files. Wäre denke ich clean. Ich würde das hier auch in meine Doku aufnehmen.
Das würde ich dann ad hoc in den Master-Branch aufnehmen. Den PN532 habe ich auch hier, so dass ich das ggf. mal kurz antesten könnte. Aber ganz grundsätzlich werde ich das nicht regelmäßig testen.
Deal?