Hallo,
bin gerade dabei meine 2. Box in Angriff zu nehmen.
Diesmal nicht unbedingt für ein Kid, sondern als Backgroundplayer in SmartHome eingebunden.
Als MQTT Broker verwende ich meinen bestehenden IOBroker.
Die feinen Unterschiede (in den Topics statt / einen Punkt als Trennzeichen) habe ich angepasst.
Soweit so gut.
Nun tauchen bei mir aber doch Unschönheiten auf, wobei ich nicht weiß ob es ein Setupproblem bei mir ist oder ob das prinzipiell, ESP32 WiFi bedingt, ein Problem in sich birgt.
Wenn ich Musik via WebStream höre, dann habe ich sehr oft bei den minütlichen MQTT refreshes (MQTT.reconnect) Tonaussetzer. Sollte der erweiterte Buffer in Folge des PSRAM nicht eine Streamunterbrechung von sagen wir 1 sekunde überbrücken können?
Ich sehe im IOBroker dass die Werte aktualisiert werden und gleichzeitig die Lautsprecher kurzzeitig verstummen. Die Lautsprecher, ja richtig gelesen.
Mein neues Setup sieht wie folgt aus:
default_envs = lolin_d32_pro_sdmmc_pe
Lolin ESP32 D32 Pro (interner SD-Reader inaktiv)
PSRAM: 4194172 bytes
SDmmc an obligatorischen Pins
Linker Kanal: MAX98357a
Rechter Kanal: MAX98357a
Tasten derzeit noch deaktiviert: Pin 99 jeweils
Drehencoder deaktiviert
Power off im DeepSleep mit MosFet IRLML2244 war ich gerade am Testen und aktivierte dazu MQTT, was mich in weiterer Folge zu diesem Beitrag führte.
(wichtig z.B. 100kOhm zw. Gate und Source, da im DeepSleep der GPIO hochohmig wird und das Gate dann quasi in der Luft hängt, was bei MOSFet zu undefinierten Zustand führt!)
Also nochmals die eigentliche Frage:
Sollte ein Parallelbetrieb WebStreaming und minütliche MQTT refreshes störungsfrei laufen?
Wenn ja, wo könnte dann das Problem bei mir liegen.
Ich habe vorerst den Bereich MQTT-publish States komplett auskommentiert und verwende nur die MQTT-Cmds. Das funktionier wunderbar störungsfrei.
Vielen Dank für Hinweise und
viele Grüße
Zunächst: Bei mir funktionieren Webstreams und MQTT aktuell gut.
Muss dazu sagen: Ich habe in letzter Zeit einige Verbesserungen für MQTT implementiert und dabei auch einige seltsame Dinge gesehen. Insbesondere Knackser in Audio, die zum Teil aufgetreten sind wenn ich an völlig anderen Codeteilen etwas geändert hatte. Wobei die Störungen dann aber durchgehend vorhanden waren.
Kannst du mal Prüfen, welche Version der ESP32-audioI2S du benutzt? Ich hatte die Störungen mit 43735d8 (vom 8. Oktober). Seit der Version cda9a10 (vom 3. November) sind die Probleme bei mir gänzlich verschwunden.
Was meinst du denn mit ‚minütlichen MQTT refreshes‘? Minütlich sollte eigentlich nur die Nachricht mit der WiFi Empfangsstärke raus gehen. Falls da bei dir tatsächlich mehr passiert (insbesondere ein reconnect), dann kann ich mir gut Vorstellen, dass das Schwierigkeiten macht.
Was mir noch einfällt: Es gibt Sender die Titelinformation und Coverart verschicken. Bei welchem Sender treten die Probleme denn bei dir auf?
Ich habe gestern das aktuelle Git Repository geklont und nur alles deaktiviert, was in meinem Testaufbau noch nicht vorhanden war (Drehencoder, Buttons, …
Sonst so wenig wie möglich verändert.
plattformio.ini:
lib_deps =
Muss vorausschicken, dass ich noch nicht den Überblick über die Programmstruktur habe. Kommt aber noch - hoffe ich zumindest. Da wo ich bei einem Tonaussetzter die iobroker objecte beobachtet habe, wurden alle ESPuino status aktualisiert. Das war dann wohl ein Reconnect. Aber auch das sollte ohne Unterbrechung funktionieren oder liege ich da falsch. Hab mir das threading und die corezuweisung noch nicht angesehen.
Könnte schon sein, dass auch nur ein update der Empfangsstärke ausreicht. Insgesamt zeigt sich das bei mir doch zu instabil. Ich konnte zum Beispiel via MQTT den deepsleep aktivieren. Nach drücken der Resettaste am DevBoard startete alles wieder. Serialmonitor zeigte MQTT verbunden (DE Test für OK) eine weiteres Kommando wurde aber trotzdem nicht erkannt (kein Logeintrag) nach geraumer Zeit oder nach USB Strom aus und wieder an ging es dann wieder.
Nach mehreren Std. verschiedenster Versuche und Logauswertungen habe ich dann versucht einen Gang zurückzuschalten und das Publishing der status deaktiviert. Lediglich beim init() läuft das einmal durch mit 3 fachen Versuch bei !connected.
Das Publishing erfolgt dabei natürlich auch nicht, das ich das in der core-funktion mit return true ohne was zu machen unterbunden habe.
Das versenden von CMDs läuft bisher extrem stabil und ohne Tonunterbrechungen.
Bin mir nicht sicher, ich denke das war Antenne Bayern. Das checke ich aber nocheinmal.
Welcher Status war das genau? Also bis vor ein paar Wochen wurde tatsächlich alle 60s sowas wie „Ich lebe noch“ geschickt. Das hat @fetzerch auf last will+testament umgebaut.
Ich hatte relativ am Anfang mit sowas mal Probleme (wobei das glaube ich nicht zu Aussetzern geführt hat). Damals habe ich das hier eingeführt:
Hast du in der Gegend vielleicht viele WLANs? Also mit dem ESP32 gibt es schon hier und da Problemchen mit WLAN - ich denke da zB an die fehlgeschlagenen Connects beim Neustart. Könnte mir vorstellen, dass zu viele WLANs da Probleme machen.
Für mich hat es so ausgesehen als wären alle status aktalisiert worden (werden dabei kurzfristig grün dargestellt). Jetzt weiß ich es etwas genauer:
Da ich von Beginn an schon einmal eine RFID als CMD abgesetzt habe, wurde dieser bei Neustart bzw. reconnect ausgeführt was zu weiteren status updates führte wie z.B. RFID, Play Mode etc.
Ich komme der Sache aber schon recht gut näher nachdem ich jetzt besser verstanden habe wie der Sollzustand laufen sollte.
Probleme machte z.B. auch, dass die Datenpunkte initial im iobroker mit einem befüllt sind.
Das hat nach Neustart z.B. den SleepTimer immer wieder ausgelöst. Den musste ich manuell schon mal auf 0 setzen.
Nachdem ich für das neue DevBoard LOLIN D32 Pro SDmmc gestern das Git-repository frisch geklont habe (damit denke ich den aktuellsten Stand zu haben) ist dieser #define vor der LibEinbindung vorhanden.
Nein, vernünftig nur meine FritzBox in 3m Entfernung. RSSI: -53
Vielen Dank für das Feedback!
Sollte ich gar nicht weiterkommen, werde ich mich wieder dazu melden.
Eine Verständnisfrage hat sich mir noch gestellt:
Warum sind die Cmd und Status Datenpunkte getrennt.
Jedenfalls bei zumindest folgendem Datenpunkte denke ich bewirkt das für mich ein unerwartetes Verhalten bei einem Reconnect zum MQTT Broker:
Ich setze die Lautstärke via MQTT z.B. auf 8
Lautstärke stellt sich ein und dieser Wert wird auch im Datenpunkt STATE.LOUDNESS aktualisiert
Nun ändere ich die Lautstärke über die WebGUI z.B. zurück auf 5
Lautstärke stellt sich ein und dieser Wert wird auch im Datenpunkt STATE.LOUDNESS aktualisiert
Dann kann es passieren, dass der ESPuino wieder lauter wird (Level 8), da nach einer möglichen Unterbrechung und Reconnect zum Broker sich der ESPuino wieder auf den Wert von CMND.LOUDNESS einstellt.
Würde es nicht besser sein wenn in diesem Fall beide den gleichen Datenpunk beschreiben?
Ich versuch es einfach einmal
Dann wird die einfachere Lösung sein, einen ungültigen Wert im Datenpunkt Cmnd.ESPuino.Loudness einfach zu ignorieren.
Dann kann ich im IOBroker nach Setzen der neuen Lautstärke den Wert anschließend wieder auf z.B. -1 oder „leer“ zurücksetzen. Wollte das schon mit „leer“ versuchen, aber das wird als 0 = AUS interpretiert.
EDIT:
Das funktioniert bereits mit z.B. Wert 99
da kommt nur der Logeintrag: Maximale Lautstärke bereits erreicht!
MQTT nutzt eine zustandshafte TCP Verbindung. Und die sollte dauerhaft bestehen bleiben solange der ESPuino läuft und im WLAN ist. Wenn das bei dir tatsächlich so ist, dass die Verbindung regelmäßig geschlossen wird, dann stimmt etwas nicht. Denn beim Wiederaufbau der Verbindung werden für ESP32 Verhältnisse doch eine ganze Menge an Daten übertragen. (alle States + evtl das Cover, falls du das abrufst)
In der Konsole dürftest du nur ein mal diese Zeilen sehen:
Versuche Verbindung zu MQTT-Broker aufzubauen 10.0.1.70
Verbinde zu MQTT-Server mit User und Passwort
MQTT-Session aufgebaut.
Auf Broker Seite sieht das hier so aus:
D | ESPuino: Publish received "State/ESPuino/Track" "(4/4): Webradio: ANTENNE BAYERN (David Guetta x Becky Hill x Ella Henderson - Crazy What Love Can Do)"
D | ESPuino: Publish received "State/ESPuino/WifiRssi" "-77"
D | ESPuino: Publish received "State/ESPuino/WifiRssi" "-90"
D | ESPuino: Publish received "State/ESPuino/WifiRssi" "-84"
D | ESPuino: Publish received "State/ESPuino/WifiRssi" "-86"
D | ESPuino: Publish received "State/ESPuino/WifiRssi" "-78"
D | ESPuino: Publish received "State/ESPuino/Voltage" "3.21"
D | ESPuino: Publish received "State/ESPuino/Battery" "68.25"
Habe tatsächlich noch einen Bug gefunden was den Stationsnamen/Titel angeht.
Über die Zeit wurden Titel einfach hinten angehängt, so dass recht bald immer 255 lange Titel übertragen werden. Also z.B.
D | ESPuino: Publish received "State/ESPuino/Track" "Webradio: SWR1BW MP3 128 (Such a shame / Talk Talk) (Werbung in SWR1) (SWR1 Baden-W\xC3\xBCrttemberg Nachrichten - auch in der SWR1 App)
(Aktuelle Nachrichten auch auf swr1.de)"
.