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
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
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. Nicht mehr notwendig. Ruckeln hatte andere Gründe.
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
10 02.11.23 Tastenaktionen sollen Playlisten starten können: WebRadio Station auf eine Taste legen?. erledigt
11 02.11.23 Equalizer über Webinterface konfigurieren können: Bass und Höhen einstellen. erledigt

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…

Würdet ihr es für Sinnvoll erachten, das Einstellen von Höhe und Bass im UI mit aufnehmen?

Das wird man nicht dreimal am Tag ändern - ich habe zuletzt bei mir ein bisschen am Klang gespielt und empfand es als nervig jedes mal alles neu zu kompilieren. Vielleicht geht es anderen ja auch so :thinking:

Seit einiger Zeit unterstützt Wolles Lib 64 Steps für Volume . Unsere 21 Steps sind manchmal zu grob , 64 ist sicher zu fein weil das in ewige Kurbelei ausartet , vielleicht wären 42 ein guter Kompromiss.
Ich hatte mal Nuberts nugo zur Ansicht hier und da waren 64 der Standart, was nervig war . In der neuen SW-Version haben die das in den Settings anpassbar gemacht.

4 „Gefällt mir“

Wie sieht es aus mit (HA Mqtt Discovery)

(dann würde der ESP von „alleine“ im HA auftauchen)

Zur Zeit hat MQTT ja feste Topics, wie wäre das der Hostname da mit ein geht?
(mehr Kinder im Haus = mehr ESP am selben Broker)

1 „Gefällt mir“

Ich arbeite daran, zusammen mit der Unterstützung für mehrere Geräte. :wink:

4 „Gefällt mir“

Zu 1) Da habe ich persönlich keine Aktien drin, da ich OpenHAB4 nutze. Aber passt für mich, wenn das jmd. Anderes macht.

Zu 2) Man müsste es eigentlich aus dem Settings-File in die GUI verschieben. Weil wenn man mehrere ESPuinos hat, dann vergisst man das beim Neukompilieren der Firmware gerne, dass man auch hier Anpassungen machen muss. Also die Änderungen sind da schnell per Copy’n’Paste gemacht, aber stimmt natürlich, dass man das eleganter lösen kann. Ne extra Kladde für MQTT haben wir auf jeden Fall ja im Webinterface.

@pcppcp Vielleicht skizzierst du mal kurz, wie du dir eine Lösung vorgestellt hast. Wenn du möchtest auch gerne in Englisch.

2 „Gefällt mir“

zu 2. Daher meine Idee mit dem Hostname, der wird ja beim init abgefragt…

state//playState … als Topic

dann brauchst kein extra GUI Setting…

Wenn einem egal ist, dass das die ein oder andere Bestandskonfiguration kaputt macht, kann man das so statisch machen :slight_smile:.
Also dass man den Hostname da reinbringt finde ich gut. Aber das jetzt einfach so, quasi ohne Wahlmöglichkeit, umzustellen… naja, geht so.

das würde ich nicht wollen, wäre halt ein Schalter mehr in der Settings USE_HOSTNAME_FOR_MQTT

  1. Anzahl Lautstärkestufen != Anzahl LEDs Neopixel

Es gibt 21 Lautstärkestufen. Hier wäre eine Wählbare Anzahl, analog zur Anzahl LEDs beim Neopixel, wünschenswert. Denn standard sind 21 Lautstärkestufen ↔ 24 LEDs. Ich habe versucht, die 3 Definitionen* wo die 21 auftaucht, auf 24 zu ändern, das hat jedoch nicht funktioniert.

*Zeile 24 in AudioPlayer.cpp: #define AUDIOPLAYER_VOLUME_MAX 21u
*469+470 in lib → ESP32-audioI2S-master → src → Audio.h
uint16_t m_vol = 21; // volume default 21
uint8_t m_vol_steps = 21; // default default 21

  1. Neopixel - Darstellung des Fortschritts

Der aktuelle Fortschritt der Musikdatei erzeugt beim Neopixel viel zu wenig Helligkeitsunterschiede. Das resultiert entsprechend in einem „stottern“ statt halbwegs gleichmäßigem Fortschritt. Das liegt daran, dass die 50 definierten Helligkeitsstufen nicht korrekt berechnet werden. Ich habe per Serial die Werte ausgeben lassen, welche bestätigten, dass die Berechnung falsch ist:

millis: 30940, currentRelPos: 1.97, leds.size(): 24, DIMMABLE_STATES: 20, ledValue: 4, fullLeds: 0, lastLed: 4
millis: 30974, currentRelPos: 1.97, leds.size(): 24, DIMMABLE_STATES: 20, ledValue: 4, fullLeds: 0, lastLed: 4
millis: 31030, currentRelPos: 2.00, leds.size(): 24, DIMMABLE_STATES: 20, ledValue: 9, fullLeds: 0, lastLed: 9
millis: 31052, currentRelPos: 2.00, leds.size(): 24, DIMMABLE_STATES: 20, ledValue: 9, fullLeds: 0, lastLed: 9
millis: 89694, currentRelPos: 6.99, map(): 29, leds.size() * DIMMABLE_STATES: 480, ledValue: 29
millis: 89744, currentRelPos: 7.00, map(): 34, leds.size() * DIMMABLE_STATES: 480, ledValue: 34
[...]
millis: 101237, currentRelPos: 7.99, map(): 34, leds.size() * DIMMABLE_STATES: 480, ledValue: 34
millis: 101262, currentRelPos: 8.01, map(): 39, leds.size() * DIMMABLE_STATES: 480, ledValue: 39

Das Problem liegt also in der map() Funktion. Diese springt immer dann, wenn currentRelPos genau die nächste ganze Zahl erreicht. Also irgendwas integer basiertes. Daher eigene map geschrieben:

float ratio = (gPlayProperties.currentRelPos - 0) / (98 - 0);
uint32_t mappedValue = ratio * (leds.size() * DIMMABLE_STATES - 0) + 0;
const uint32_t ledValue = std::clamp<uint32_t>(mappedValue, 0, leds.size() * DIMMABLE_STATES);

Mit Output:

millis: 62891, currentRelPos: 4.90, ratio: 0.05, mappedValue: 23, ledValue: 23
millis: 62940, currentRelPos: 4.92, ratio: 0.05, mappedValue: 24, ledValue: 24
[...]
millis: 65400, currentRelPos: 5.10, ratio: 0.05, mappedValue: 24, ledValue: 24
millis: 65422, currentRelPos: 5.14, ratio: 0.05, mappedValue: 25, ledValue: 25
[...]
millis: 67433, currentRelPos: 5.29, ratio: 0.05, mappedValue: 25, ledValue: 25
millis: 67456, currentRelPos: 5.31, ratio: 0.05, mappedValue: 26, ledValue: 26

→ Funktioniert, flüssiger Übergang der Helligkeiten mit dem eingestellten Wert der Helligkeitsstufen DIMMABLE_STATES.

Soll ich das bei Github als Issue eintragen? Oder wie kann ich denn korrigierten Code sogar hochladen?

@Eheran1 Es gibt Neuerdings in der Audiobibliothek die Methode setVolumeSteps()

Damit könnte man die Schritte verfeinern. Also z.B. bei 24er Neopixel 48 Lautstärkeschritte und damit weichere Übergänge. Allerdings sollte man am Drehregler von 0 auf 100 genauso viele Umdrehungen wie bisher machen. Kannst Du das in Deine Überlegungen mit einbeziehen?

Ich verwende einen 12er bzw. 8er Neopixel, dort tritt das Problem nicht auf…

Ich habe das im AI-on-the-edge-device-Projekt umgesetzt.

Ist etwas Fleissarbeit, aber danach echt cool. Wird mittlerweile auch von anderen Homeautomation-Systemen direkt unterstützt.

1 „Gefällt mir“