Liste geplanter Features

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

als Hinweis zu 2: bei einer anderen Bastelei läuft auf einem ESP8266 folgender AP super.

Vielleicht hilft das ja irgendwie. Falls nicht, dann kann der Beitrag auch gelöscht werden.

Ich verwende: AutoConnect for ESP8266/ESP32 kann auch empfehlen… liefert aber glaube ich zu viel für dieses Projekt…

Punkt 6 würde mich extrem freuen - fertige Images die man dann per Web Tools flasht oder OTA updated… :smiling_face_with_three_hearts:
Da wäre die Einstiegshürde deutlich niedriger.

vor 6 würde bei mit „automatische Builds bei Github“ stehen, weil vorher sollen die gebauten Images kommen?

Ich glaube ich muss noch ergänzen, dass die Nummerierung keiner Prio folgt. Aber ich nehme den Punkt gerne auf.

Das trifft auch auf „play last rfid after reboot“ zu, was ich bereits gefixt habe und auch einen PR für den dev-branch abgesetzt habe.
Läuft bei mir einwandfrei. Für Punkt 8 erkenne ich die Notwendigkeit nicht wirklich, es sei denn, dass eine Karte beim Start bereits ausliegt. Das lässt sich dann aber über den gleichen Mechanismus erweitern.

zu MQTT (Punkt 5) Link da lass:

klingt ganz gut…