Sind im nächsten Update enthalten. Wird aber erst morgen.
LG
Burkhard
Halte mich mal bitte auf dem Laufenden, ob Du es hin bekommst.
LG
Burkhard
kein Problem.
Vielen Dank
Im neuen Docker auf dem BPI, auf neuem PI3 und mit beiden meiner Slaesh Sticks das gleiche Verhalten.
Im Z2M sehr häufig mit wenigen Sekunden Abstand
[10.7.2026, 15:41:16] z2m: MQTT error: Keepalive timeout
[10.7.2026, 15:41:16] z2m: Not connected to MQTT server!
und im Symcon MQTT Server Debug
10.07.2026, 15:43:56 | MQTT:RX | Incomplete packet. Wait for more data
...
10.07.2026, 15:44:42 | MQTT:TX:PUBLISH (Forward) | Skipped sending to mqttjs_55286e93 (172.16.100.212:43172)
und dann natürlich auch
10.07.2026, 15:44:20 | Server Socket | Fehler beim Lesen: Bad file descriptor
Am Wochenende muss das erstmal so bleiben, mal sehen, was ich nächste Woche noch finde, eventuell dann noch ein Versuch mit dem SLZB-06.
Mit welchem Stick arbeitest Du momentan? Ist doch einer mit SiLabs-Chip, richtig? Ich habe mit denen gar keine Probleme.
Passt aber von der Thematik her nicht mehr so ganz hier rein.
LG
Burkhard
Hast du mal die MQTT-Protokollversion in Z2M kontrolliert? Dort sollte 4 stehen, für die MQTT Version 3.1.1
Stand und steht auf 4. Ich werde die Woche weiter analysieren.
Das mag sein, das Problem habe ich aber erst seit dem Wechsel auf die 6.0.
Meine Umgebung läuft wieder performant und mit der V6 des Moduls.
Die Ausfälle bei mir haben mehrere Ursachen:
- MQTT Server in Symcon überlastet
- Zu viel MQTT Traffic
- und vermutlich auch die Änderungen im Modul
gemini:
Interner Code-Rework (Asynchrone Verarbeitung)
Der Code für die Devices wurde für die V6 Testing komplett neu geschrieben. Die Daten werden jetzt noch feingranularer geparst. Wenn nun Datenpakete extrem schnell hintereinander eintreffen (wie bei deinen Radarsensoren), muss Symcon diese sehr schnell im PHP-Thread verarbeiten. Kommt es hier zu minimalen Verzögerungen bei der Verarbeitung des massiven Payloads, staut sich der TCP-Buffer des MQTT-Servers – und genau das hat zu den Abstürzen geführt.
Ich nutze den genannten Nous D4Z control via MQTT | Zigbee2MQTT , der in den Standardeinstellungen sehr viel Traffic erzeugt. Außerdem 13 Radar Sensoren, von denen einige in den Standardeinstellungen viel Traffic erzeugen.
Alles zusammen führt zu den regelmäßigen Abstürzen/Verbindungsverlust des MQTT Servers und damit den Aussetzern bei mir.
Mit einigen Anpassungen in der configuration.yaml, u.a.
mqtt:
keepalive: 120
include_device_information: false
das untere hat hoffentlich keine Auswirkungen auf das Modul und beim Zähler
filtered_attributes:
- alarm_set_1
- alarm_set_2
debounce: 5
die Alarm Sets brauche ich nicht und die Daten reichen auch alle 5 Sekunden, läuft es jetzt wieder.
Debounce habe ich auch bei den Radar Sensoren eingetragen, vor denen ich viel sitze, da reicht die Entfernung auch jede Sekunde.
Bei den Radarsensoren wird das System wirklich geflutet. Früher war die Aufteilung der Last ein probates Mittel.
Okay, ich schaue mir das definitiv noch mal an. Und ja, bei die V6.0 kann es durch die umfangreichere Verarbeitung zu einer höheren Last kommen.
Fällt bei mir wahrscheinlich nicht so auf, da ich zwei Zigbee Netzwerke mit zwei internen MQTT-Servern aufgebaut habe. Das eine arbeitet mit 85 Geräten (5 Radar und 2 Raumklima-Sensoren mit viel Traffic) und das andere mit 98 Geräten (4 Radar).
Wie gesagt, ich schaue mal, ob man da noch was optimieren kann.
LG
Burkhard
1 „Gefällt mir“
danke, ich werde auch noch mal einen Test mit Mosquito machen und den Z2M MQTT auslagern. Aktuell habe ich 6 MQTT Instanzen, eine davon für Z2M.
Ja, das ist gut, aber ich konnte es nicht mal in der Z2M Oberfläche, da die immer wieder weg war.
Das ist aber ab Werk aus und sollte es auch bleiben. @Burki24 oder braucht das Modul diese Infos jetzt?
Das die Einstellung Probleme macht, hatten wir hier ja schon.
Auch wenn dort ‚nur‘ massenweise Variablen angelegt wurden.
Das dieses riesen Payload, zusammen mit den Radarmeldern, hier den MQTT Server veranlasst hat die Verbindung zum Client (Z2M) zu trennen, wundert mich nicht.
hatte ich nicht geprüft, in der configuration.yaml stand es nicht und in der Oberfläche kam ich nicht dran. Ich nehme es noch mal raus zum Test.
Mit Mosquitto testen würde bedeuten, ich muss alle Z2M Instanzen auf ein anderes Gateway ändern? Das ist nicht lustig oder gibt es einen anderen Weg?
Update:
du hast natürlich recht und der Parameter sollte keine Auswirkungen haben.
Nein, braucht es nicht und wird vom Modul auch nicht automatisch aktiviert oder genutzt. Das Modul macht keine Änderungen der configuration.yaml.
Ich habe gerade ein neues Update hoch geladen mit folgenden Änderungen:
- Robustere MQTT-Payload-Verarbeitung
Numerische Root-Einträge ohne gültigen Variablen-Ident werden ignoriert. Das verhindertTypeErrorund unnötige Verarbeitung fehlerhafter Geräte-Payloads. - Rückmeldebasierte Aktionen
Schalter, Helligkeit, Farbtemperatur und andere lesbare Werte werden lokal erst aktualisiert, wenn Zigbee2MQTT die Änderung zurückmeldet. Das verhindert falsche Zustände und doppelte Updates. Reine Befehlswerte ohne Rückmeldung werden weiterhin sofort lokal gespeichert. - Unveränderte Werte werden übersprungen
Bereits identische Variablenwerte werden nicht erneut geschrieben. Dadurch sinken FlowHandler-, Ereignis-, Archiv- und Kachelaktivitäten deutlich. Das entlastet Symcon und reduziert das Risiko einer internen Überlastung; die Anzahl der von Zigbee2MQTT eingehenden MQTT-Nachrichten ändert sich dadurch nicht.
Bitte mal testen
LG
Burkhard
1 „Gefällt mir“
Das habe ich gerade installiert, mal schauen.
debounce ist zumindest für den Zähler suboptimal, da muss ja “x Sekunden Ruhe” sein bei der Quelle, das passiert bei dem dreiphasigen Zähler sehr selten. Ich teste aktuell mit “1”, damit kommen alle 1-3 Sekunden Daten in Symcon an.
Du kannst via Zigbee2MQTT noch eine Auswahl treffen, ob ungenutzte/unwichtige Exposes rausgefiltert werden sollen. Auch das senkt nochmal die Datenmenge eines Payloads.
filtered_attributes
Allows preventing certain attributes from being published. When a device would e.g. publish{"temperature": 10, "battery": 20}and you setfiltered_attributes: ["battery"]it will publish{"temperature": 10}.
filtered_cache
Allows preventing certain attributes from ending up in the cache. This prevents attributes from being published when the value did not change.
LG
Burkhard
die Filterung habe ich beim Zähler drin gelassen, die Alarm Sets brauche ich nicht. Das scheint die Menge deutlich zu reduzieren. Deine Anpassung zu “Unveränderte Werte werden übersprungen“ scheint auch was zu bringen, das finde ich sehr gut, dadurch kann man sehen, seit wann der Wert so ist, da er nicht mehr jedes mal aktualisiert wird.
Aktuell habe ich nur zwei debounce, für den Zähler und den AirIQ und bisher sieht es gut aus, Durchlauf-Reaktion wieder “quasi sofort”.
1 „Gefällt mir“
Das reduziert aber nicht den MQTT-Datenstrom, entlastet aber Symcon.
LG
Burkhard
1 „Gefällt mir“