es hat alles mit einem BLU Gateway und einem BLU Button Tough Ende 2024 angefangen. Zu der Zeit gab es Firmware Probleme, weshalb das Setup nicht funktioniert hat (hatte ich als Bug Report eingereicht)
Nach paar Wochen gab es dann ein FW-Update, dann konnte ich es benutzen.
Ziel der ganzen Aktion war eigentlich nur um festzustellen, ob das Auto in der Garage steht, vor der Garage steht oder unterwegs ist. Das prüfe ich anhand der Empfangsstärke vom Button (welcher im Auto liegt), was im Prinzip auch gut funktioniert. Der Button ist im Beacon Modus und schickt deshalb permanent Infos raus, die das Gateway empfängt.
Nur dann tauchen des Öfteren im Debug Log des Shelly BLU Gateways die „MQTT0 queue overflow“ Meldungen auf, weshalb die Infos dann nicht mehr zum Broker rausgehen, manchmal für paar Sekunden nicht, manchmal für paar Minuten nicht, manchmal auch für ne halbe Stunde nicht, manchmal auch nie mehr, dann tauchen hunderte Zeilen Debug Log mit Deadlock Meldungen auf, dann muss ich das BLU Gateway rebooten.
Die Probleme & Logs hatte ich dem Support damals auch mitgeteilt, bisher ohne Erfolg.
Eigentlich wollte ich zu dem Zeitpunkt mit dem Vorhaben aufhören … aber irgendwie wollte ich ja auch noch alle Fenster & Türen in meinem Haus überwachen, Bewegungssensoren in jeden Raum packen etc. also fing ich an, mir zum Testen diverse andere Geräte zu kaufen (um unter anderem festzustellen, dass BLU Geräte IMMER mit einer leeren CR2032 geliefert werden (Papierschnipsel sind überbewertet 
)
Im Prinzip funktioniert das auch alles super, WENN denn das genannte MQTT Problem nicht wäre. So kommt es dann oft vor, dass der Status der Sensoren im Broker nicht korrekt ist, somit auch nicht in FHEM (Fenster/Tür wird als offen gemeldet obwohl zu, keine Bewegung obwohl ich vor dem Motion rumhampel) - und immer, wenn das eintritt, ist das „Queue overflow“-Problem da. tcpdump belegt, dass es nie am Pi, somit am Broker ankommt.
Die Shelly Cloud hat eigentlich immer die korrekten Zustände, insofern funktioniert das alles „eigentlich“. Die korrekten Zustände würde ich per MQTT auch nach und nach bekommen, wenn ich alle BLU Geräte mit Beacon AN laufen lassen würde, nur dann sind die Batterien innerhalb 1-3 Wochen leer (aus Verzweiflung auch getestet)
Dann habe ich mir mal ein PM Gen3 und 1PM Gen3 bestellt und damit getestet, da ich vermutet hatte, dass evtl. das Gateway das Problem hat (zu wenig RAM, zu wenig CPU Leistung - kein Plan) … aber die Geräte haben ebenso das gleiche Verhalten. Dann ein Plug S Gen3, damit geht das Skript aber nicht, weil zu wenig RAM (wohl weil Matter da zu viel belegt und immer noch nicht abschaltbar ist)
Wenn ich den BLU Button deaktiviere (Batterie raus) oder Beacon Modus abschalte, dann tritt das Problem deutlich weniger auf, klar warum: es kommen ja keine Daten mehr an, außer ich drücke den Knopf an dem Teil) … nur sobald ich z.B. aus dem Garten in die Garage gehe (erster Door Sensor: Tür auf, Tür zu), dann in der Garage bin (Motion Sensor), dann paar Meter zur Tür ins Haus gehe (zweiter Door Sensor, Tür auf, Tür zu) passiert es auch da: MQTT0 queue overflow, weil zu viel auf einmal passiert. Warte ich in der Garage oder schlafe beim gehen ein, oder lasse mir viel Zeit fürs Türschließen bis ich ins Haus gehe, klappt es oft ohne Queue Probleme.
Wenn ich das nun zu Ende denke, sprich an jeder Tür und jedem Fenster ein Door/Window Sensor, in jedem Raum ein Bewegungsmelder installiert habe, in fast jedem Raum ein Gateway oder PM/1PM, 3 Personen Haushalt, dann kann ich sicher sein, dass es eine 50/50 Chance gibt, dass die Zustände im Broker stimmen. Wahrscheinlich würde es besser funktionieren, wenn ich jedem BLU Gerät ein dediziertes Gateway/PM verpasse und dann im Skript alles, was es nicht verarbeiten soll, blackliste, aber … nein! 
