Fragen zu den Grenzen zigbee2mqtt

Hausierer · 10 Juli 2020, 09:42:17

Hallo Leute,

ich nutze einen CC2531 Stick am Raspberry. Auf dem Stick läuft die Z-Stack Firmware von Koenkk. Ich habe aktuell das Problem das zigbee2mqtt regelmäßig mit einem Time out stehen bleibt. In diesem Zusammenhang bin ich über die Grenzen gestolpert. Darüber hatte ich mir vorher keinen Kopf gemacht, da alles prima lief.
Ich lese, das System kann max 15 oder auch 20 Geräte (was ist richtig?)verwalten. Ich habe 14 Geräte plus einem Repeater plus einem CC2530 Coordinator am laufen. Zählen Repeater auch als Geräte? Kann das überhaupt der Grund für meine Probleme sein?

LG
Holger

OdfFhem · 10 Juli 2020, 13:00:59

1) Einige Informationen zur Verwendbarkeit der aktuellsten Coordinator-Firmware gibt's hier: https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator

2) Enthält der zigbee2mqtt-Log Hinweise bzgl. Timeout ?

Hausierer · 10 Juli 2020, 13:23:07

Danke für die Antwort,
1. Das hatte ich auch gesehen, dort steht 20 an anderen Stellen hatt ch auch schon 15 gelesen. Daher meine Verunsicherung
2. Ja, diesen hier:

Code Auswählen

Jul 08 18:40:58 raspberrypi npm[537]: zigbee2mqtt:info  2020-07-08 18:40:58: MQTT publish: topic 'zigbee2mqtt/0x00124b001c2c98f6', payload '{"led":false,"linkquality":39}'
Jul 08 18:41:03 raspberrypi npm[537]: (node:559) UnhandledPromiseRejectionWarning: Error: SRSP - ZDO - mgmtPermitJoinReq after 6000ms
Jul 08 18:41:03 raspberrypi npm[537]:     at Timeout.waiter.timer.setTimeout [as _onTimeout] (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/utils/waitress.js:47:35)
Jul 08 18:41:03 raspberrypi npm[537]:     at ontimeout (timers.js:436:11)
Jul 08 18:41:03 raspberrypi npm[537]:     at tryOnTimeout (timers.js:300:5)
Jul 08 18:41:03 raspberrypi npm[537]:     at listOnTimeout (timers.js:263:5)
Jul 08 18:41:03 raspberrypi npm[537]:     at Timer.processTimers (timers.js:223:10)
Jul 08 18:41:03 raspberrypi npm[537]: (node:559) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .

MadMax-FHEM · 10 Juli 2020, 13:30:52

Umstieg auf deCONZ und HUE-Bridge-Modul!?

Gruß, Joachim

OdfFhem · 10 Juli 2020, 13:31:55

@Hausierer

zu 1) Generell würde ich den "offiziellen" Zahlen mehr Glauben schenken ...

zu 2) Welche Version setzt Du ein und gibt es das Timeout-Problem erst seit dem letzten Update ?

Hausierer · 10 Juli 2020, 13:46:21

1. ok. Ich war vor allem unsicher ob die beiden Repeater als Device zählen oder nicht.
2. Ich mußte nach einen SD Karten defekt den FHEM Server letzte Woche neu aufsetzen und vermute, das ich die aktuelle Version nutze. Es ist die 20190608.

@MadMax-FHEM: Nö, nicht umgestellt aber neu aufgesetzt. Siehe oben...

OdfFhem · 10 Juli 2020, 14:02:37

zu 1) Deine Firmware-Version für den Stick hat sich in der letzten Woche vermutlich nicht geändert. Welche zigbee2mqtt-Software-Version nutzt Du denn ? Evtl. passen die installierten node bzw. npm-Versionen nicht dazu ... oder setzt Du die docker-Variante ein ?

MadMax-FHEM · 10 Juli 2020, 14:06:01

Nein ich meinte: warum du nicht auf deCONZ und HUE-Bridge Modul umsteigst!?

Gruß, Joachim

Hausierer · 10 Juli 2020, 15:13:28

@OdfFhem: Wie frage ich die zigbee2mqtt-Software-Version ab. Wurde aber wie schon beschrieben erst letzte Woche erst installiert und sollte dann doch aktuell sein. (dachte ich)

@MadMax-FHEM: Die Antwort ist einfach, weil ich den CC2531 da habe und der bisher einwandfrei gelaufen ist. Lohnt sich der Umstieg? Läuft der deCONZ Stick so viel besser?

MadMax-FHEM · 10 Juli 2020, 15:17:20

Zitat von: Hausierer am 10 Juli 2020, 15:13:28
@MadMax-FHEM: Die Antwort ist einfach, weil ich den CC2531 da habe und der bisher einwandfrei gelaufen ist. Lohnt sich der Umstieg? Läuft der deCONZ Stick so viel besser?

Besser würde voraussetzen, dass ich zigbee2mqtt kennen würde, was ich nicht tue.

Allerdings wäre mir neu, dass deCONZ z.B. solche Grenzen kennt...
...mag mich aber auch da täuschen, da ich (noch) nicht so viele ZigBee-Geräte habe...

Ein ganz kurzer "googler" bringt folgendes: https://forum.iobroker.net/topic/28650/conbee-ii-maximum-erreicht
(was mich wieder bestärkt, dass es offenbar keine bzw. eine deutlich höhere Grenze gibt)

Gruß, Joachim

Beta-User · 10 Juli 2020, 16:26:19

Die Grenze dürfte weniger von der dahinterliegenden Software kommen, sondern eher in den Kapazitäten des Coordinator-Chips, deswegen ja auch das "entweder oder" bei der Firmware für den CC2531... Der Speicher/EEPROM kann halt entweder die einen oder die anderen Routing-Daten speichern, aber er ist eben begrenzt.

Auch zigbee2mqtt scheint zwischenzeitlich mit dem Conbee II (&Co) zu "können", von daher ist diese Grenze "gleich", bis eben eine neue Generation der Coordinator-Chips kommt, die dann vielleicht 1000 Geräteadressen samt Routing verwalten kann, wer weiß...?

Ich kenne beide Welten, allerdings zigbee2mqtt nur bis zum Stand von ca. Jahresanfang. Beide haben ihre pros&cons, was man letztlich wählt, bleibt einem selbst überlassen. Ich bin Skeptiker, was Java angeht, und finde kleine Automatismen in deconz auch gut aufgehoben, das sich auch via apt-get aktuell halten läßt, vermisse aber andererseits die direkte Verbindung der Zigbee-Hardware-Adresse zu einem Gerät (HUEDevice macht aus einer innr SP 120 drei Geräte...). Und ich habe den Eindruck, mit zigbee2mqtt käme man näher an das ran, was die eigentliche Hardware tut (da ist deconz mAn etwas undurchsichtig und händelt viel via Software, was ich lieber in Hardware hätte!).

Wer docker kennt, wird vermutlich mit Recht behaupten, dass es updatemäßig egal ist, was man @docker nimmt usw. usf....

Kurz: Ich würde heute vermutlich den Schritt von zigbee2mqtt weg hin zu deconz nicht wieder machen, andersrum ist deconz aber auch soweit ok, dass es keinen Sinn macht, daran jetzt schon wieder was zu drehen...

EDIT: Kleine Klarstellung betr. zigbee2mqtt vs. deconz.

OdfFhem · 10 Juli 2020, 18:40:11

@Hausierer

Die zigbee2mqtt-Software-Version kann man z.B. im entsprechenden bridge-Device unter FHEM oder - je nach eingestelltem Loglevel - ebenfalls im zigbee2mqtt-Log ermitteln.

Hausierer · 21 Juli 2020, 10:52:15

@ alle: Danke für Eure Infos. Da konnt sich mein Bild wieder weiter vervollständigen.

Mein aktuelles Problem scheint im Griff zu sein. Es war nicht die Hardwaregrenze. Da hatte ich mir wieder zu komplizierte Gedanken gemacht.
Ich hatte noch einen Ersatz CC2531. Den habe ich neu geflasht und eingebunden. Seitdem läuft es wieder.
Demnächst werden ich den alten Stick neu flashen und schauen ob der tatsächlich defekt ist oder nur irgendwie "doof" wurde. Das muß aber noch warten, da auf Grund des Wetters ander Arbeiten wichtiger sind.

Da jetzt alles wieder läuft wie es soll, werde ich auch erst mal weiter beim CC2531 bleiben.

LG vom Hausierer