Kommend aus ESPuino: Wie geht's weiter? habe ich mir den Aktionspunkt mitgenommen, dass es eine Liste geben sollte mit Punkten, deren Umsetzung noch offen ist. Idee: Entwickler, die Lust haben, sich an der Entwicklung zu beteiligen, können sich solche Aktionspunkte schnappen.
Hier lebt dann also die Liste mit Punkten, die ich (hoffentlich immer) pflege. Weitere Punkte können gerne eingebracht werden, aber es sollte ein gewisser Konsens bestehen, dass diese notwendig sind.
Hinweis: Die Nummern entsprechen keiner Priorisierung.
Hinweis #2: Wenn sich ein Entwickler dazu entscheidet, einen Punkt aufzugreifen, dann sollte er, sofern es dazu nicht bereits eine Diskussion gibt, einen neuen Thread öffnen, so dass man die Umsetzung diskutiert. Auf jeden Fall sollte vermieden werden, dass unnötigerweise zwei Leute gleichzeitig + unkoordiniert parallel am gleichen Thema arbeiten.
| # | Datum | Kurzbeschreibung | Status |
|---|---|---|---|
| 1 | 24.3.23 | Möglichkeit der Speicherung mehrerer WLANs | Erledigt (in dev) |
| 2 | 24.3.23 | Bisher muss im Access-Formular der WLAN-Name händisch eingetragen werden. Das soll weiterhin möglich sein, es sollte jedoch parallel einen WLAN-Scan und die gefundenen WLANs zum Anklicken angezeigt werden. Das Anklicken bewirkt, dass der Name des WLANs übernommen wird. Hat gewisse Abhängigkeiten zu Punkt 1. | Erledigt (in dev) |
| 3 | 24.3.23 | Der Drehencoder soll flexibler eingesetzt werden können. | offen |
| 4 | 24.3.23 | Support für externe m3u-Playlists. Aktueller Stand: m3u-Playlists müssen lokal liegen. Liegen sie extern, so kann man sie für Webstreams zwar aufrufen, es wird jedoch immer nur der erste Eintrag abgespielt (das steuert nicht ESPuino sondern das ist von Wolles Audiolib gekapselt. | offen |
| 5 | 24.3.23 | MQTT in eigenen Task stecken. Möglicherweise aber auch nicht nötig, aber ganz generell sollte geprüft werden, ob es neben PubSubClient, der offenbar nicht mehr weiterentwickelt wird, bessere Alternativen gibt. Beispielsweise espMqttClient, der als „non-blocking“ beschrieben wird. Unter Arduino 1 gibt es Stand jetzt (März 2023) auf jeden Fall Probleme mit MQTT, die sich so darstellen, dass die Audio-Wiedergabe ruckelt. | offen |
| 6 | 24.3.23 | Analyse/Umsetzung, ob sich mit ESP Web Tools Prozesse für User vereinfachen lassen. Frage: Ist es ggf. möglich, Usern Standard-Builds bereitzustellen, so dass nicht jeder mit Platformio & Co hantieren muss? | offen |
| 7 | 24.3.23 | Hängt mit Punkt 6 ein Stück weit zusammen: Bereitstellung von automatischen Builds, die von GitHub generiert werden. | offen |
| 8 | 24.3.23 | Seitdem der WLAN-Start asynchron ist, werden Karten, die WLAN brauchen, so lange abgelehnt, bis WLAN vorhanden ist. Wünschenswert wäre es, wenn man die Karte auflegen könnte und ESPuino würde sich die Karte so lange „merken“, bis WLAN verfügbar ist und das Ganze dann automatisch ausführen. Die genaue Umsetzung muss aber diskutiert werden, denn da gibt es diverse Sachen, die man beachten muss, um das sinnvoll umzusetzen. | offen |
| 9 | 03.4.23 | Playlists beinhalten aktuell immer für jedes Item den absoluten Pfad. Beispielsweise bei einer Playlist, die lediglich alle Files eines Ordners abspielen sollen, könnte man einmalig den Pfad in der Playlist halten und ansonsten nur die Namen der Audiofiles. Den gesamten Dateinamen würde man dann zur Laufzeit konkattenieren. Das würde Speicher sparen und ggf. Abstürze bei sehr großen Playlists verhindern. | offen |
