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… 
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 
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. 
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 
.
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
- 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
- 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“
Ein Modus wie in folgendem Thema diskutiert wäre sehr nützlich.