UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[diwoma]

Hi
ich habe mich mit meinen Fragen schon an den Thread [https://forum.iobroker.net/topic/60287/zigbee-cc2538-kommt-an-seine-grenzen/8] angehängt.
Aber die Fragen, die sich mir jetzt stellen, gehen dort am Thema vorbei.

Ich habe endlich einen Plan-Graphen im Zigbee-Adapter bekommen, auch wenn ich weiss, das man dem nicht unbedingt trauen soll/kann. Trotzdem ist er (glaube ich) nicht so falsch:

Aus dem Bild geht hervor, das Mesh anscheinend doch funktioniert und trotzdem ist das Verhalten irgendwie komisch:
ROLL-006 ist connected (anscheinend mit dem Coordinator) und hat viele Verbindungen zu anderen Devices
ROLL-005 ist disconnected, aber nur 10cm von ROLL-006 enfernt, hat viel weniger Connections, aber eine laut Graph eine gleich starke Verbindung zum Coordinator?
Warum ist er dann disconnected?

Kann man irgendwie herausfinden, an wen ein Router-Device connected ist und wer an ein Router-Device connected ist?
Oder was bei einer "starken" Verbindung ein disconnect verusacht?
Ich habe alle meine WLAN auf höhere Frequenzen eingestellt, der Zigbee-Kanal 11 ist ja am unteren Ende der Skala und dort ist keine Auslastung.

[Asgothian]

@diwoma sagte in Zigbee Mesh Fragen:

Kann man irgendwie herausfinden, an wen ein Router-Device connected ist und wer an ein Router-Device connected ist?
Oder was bei einer "starken" Verbindung ein disconnect verusacht?
Ich habe alle meine WLAN auf höhere Frequenzen eingestellt, der Zigbee-Kanal 11 ist ja am unteren Ende der Skala und dort ist keine Auslastung.

Fangen wir unten an:

• Ob ein device als Connected oder Disconnected angezeigt wird hängt von mehreren Faktoren ab. Dazu gehören wann das Gerät das letzte mal seinen Status aktualisiert hat, ob das Gerät auf einen "Ping" antwortet, und wann es das letzte mal getan hat. Im Bezug auf die Netzwerkkarte ist da auch noch wichtig wann das passiert ist relativ zum Aufbau der Netzwerkkarte
• Die Zahl die an einer Verbindung steht ist die im Koordinator / Router gespeicherte letzte Verbindungsstärke als das letzte mal kommuniziert wurde. Wenn ein Gerät sich nicht mehr meldet wird diese Zahl nicht automatisch angepasst.
• gerade bei modernen Funknetzen im 2.4 GHz Bereich sind Abstand und Verbindungsstärke nicht direkt proportional. Innerhalb geschlossener Gebäude gibt es durch Reflektionen, Beugung von Wellen und Überlagerungen durchaus Bereiche die erstaunlich gute / schlechte Funkverbindung haben. Dazu kommt das insbesondere lebendes Material (Menschen, Tiere, Pflanzen) sehr gute Dämpfungseigenschaften für 2.4 GHz Wellen haben. Das konnte ich bei meinen Tests Live beobachten. Anordnung: X o C (X = Thermostat, o = der Programmierer wenn er am ioBroker arbeitet, C der Koordinator für die Einbindungstests. Immer wenn ich von meinem Platz aufgestanden bin hatte der Thermostat eine gute Verbindung. Hab ich mich gesetzt war sofort wieder mau.
• Geräte auf der Karte die keine Verbindungen zeigen sind nicht zwangsläufig ohne Funktion. Das gleiche gilt für Geräte die als "Disconnected" angezeigt werden.

A.

[diwoma]

@asgothian said in Zigbee Mesh Fragen:

Vielen Dank für die Erklärung.

Geräte auf der Karte die keine Verbindungen zeigen sind nicht zwangsläufig ohne Funktion. Das gleiche gilt für Geräte die als "Disconnected" angezeigt werden.

Sie sind zwar nicht ohne Funktion, aber sie sind nicht mehr steuerbar. Ich sehe das an einer TADFRI-Led, die sich anscheinend noch per Steuerung einschaltet, dann sich aber nicht mehr ausschalzrn läßt. Was unangenehm ist, weil sie sonst nicht ausgeschaltet werden kann. Und auch bei der Rollo-Steuerung, wenn bei Gruppensteuerung eine Rollo geht und die andere nicht.

Ob ein device als Connected oder Disconnected angezeigt wird hängt von mehreren Faktoren ab. Dazu gehören wann das Gerät das letzte mal seinen Status aktualisiert hat, ob das Gerät auf einen "Ping" antwortet, und wann es das letzte mal getan hat. Im Bezug auf die Netzwerkkarte ist da auch noch wichtig wann das passiert ist relativ zum Aufbau der Netzwerkkarte

Bedeutet das, das es nur im Device selbst selbst auszulesen ist.
Und das mit dem Ping - Ja ich habe im Log gesehen, das die Meldung gekommen ist, Devices hätten auf Pings nicht geantwortet.

gerade bei modernen Funknetzen im 2.4 GHz Bereich sind Abstand und Verbindungsstärke nicht direkt proportional. Innerhalb geschlossener Gebäude gibt es durch Reflektionen, Beugung von Wellen und Überlagerungen durchaus Bereiche die erstaunlich gute / schlechte Funkverbindung haben. Dazu kommt das insbesondere lebendes Material (Menschen, Tiere, Pflanzen) sehr gute Dämpfungseigenschaften für 2.4 GHz Wellen haben. Das konnte ich bei meinen Tests Live beobachten. Anordnung: X o C (X = Thermostat, o = der Programmierer wenn er am ioBroker arbeitet, C der Koordinator für die Einbindungstests. Immer wenn ich von meinem Platz aufgestanden bin hatte der Thermostat eine gute Verbindung. Hab ich mich gesetzt war sofort wieder mau.

Das würde ja bedeuten, das WLAN bzw. Zigbee ein äußerst instabiles Verhalten aufweisen würde, was der Definition eines stabilen Netzwerk wiedersprächen, für das Mesh wirbt (bei anderen funktioniert es ja)

Kann es nicht sein, dass alle Devices prinzipiell sich nur am Coordinator anmelden wollen, weil sie initial dort angemeldet worden sind? Und gar nicht versuchen, auf einen Router zu springen? Und 37 Devices zuviel für den Coordinator sind?

[Asgothian]

@diwoma sagte in Zigbee Mesh Fragen:

Das würde ja bedeuten, das WLAN bzw. Zigbee ein äußerst instabiles Verhalten aufweisen würde, was der Definition eines stabilen Netzwerk wiedersprächen, für das Mesh wirbt (bei anderen funktioniert es ja)

WLan und Zigbee sind 2 vollständig unterschiedliche Systeme, die sich bei ungünstigem Parallelbetrieb durchaus beeinflussen können. In diesem Fall zieht Zigbee zumeist den kürzeren.

Was den Mesh Anteil angeht, so ist die Sache durchaus kompliziert. Es gibt eine x Seiten lange Definition der Zigbee Spezifikation. Leider halten sich bei weitem nicht alle Hersteller in allen Punkten an besagte Spezifikation, da sie primär auf Interoperabilität mit dem eigenen Gateway aus sind. Daraus entstehen Auffälligkeiten.

Kann es nicht sein, dass alle Devices prinzipiell sich nur am Coordinator anmelden wollen, weil sie initial dort angemeldet worden sind? Und gar nicht versuchen, auf einen Router zu springen?

Für bestimmte Geräte gilt das sicher. Die Aqara Geräte sind da beliebte Beispiele, da sie nur dann über Router arbeiten wollen wenn sie den Koordinator vollständig nicht erreichen können. Das mag sich ändern wenn Aqara eigene Router dazu kommen - das probiere ich gerade aus. Bei den Ikea geräten sieht die Sache anders aus. Die sind eigentlich für den Einsatz ohne Koordinator konzipiert, und verhalten sich auf der Seite machmal seltsam.
TuYa kocht ein ganz besonderes Süppchen. Mir schmeckt das überhaupt nicht, da TuYa einen Grossteil der Spezifikation ignoriert und auch Standard-Funktionen über den (im Standard vorgesehenen) "Manufacturer-Specific" Cluster abbildet. Um zu sehen wozu das führt, such einfach mal bei Zigbee2mqtt.io nach TS0601. Da findet du einen Strauss an Geräten die sich alle als "TS0601" Zigbee-Geräte ausgeben, und die nach der Spezifikation eigentlich gleich sein sollten.

Und 37 Devices zuviel für den Coordinator sind?

Je nach Koordinator stimmt das. Was nutzt du denn ? Ich hab aktuell knapp 90 Geräte im Netz, mit wenig Problemen.

[diwoma]

@asgothian said in Zigbee Mesh Fragen:

Je nach Koordinator stimmt das. Was nutzt du denn ? Ich hab aktuell knapp 90 Geräte im Netz, mit wenig Problemen.

Zur Zeit verwende ich einen Conbee II an einem RPi4-Slave.
Aber ich habe schon einen LAN-Coordinator mit CC2652P2 bestellt, der dann stärker sein soll und selbst mehr Devices verwalten kann.

Für bestimmte Geräte gilt das sicher. Die Aqara Geräte sind da beliebte Beispiele, da sie nur dann über Router arbeiten wollen wenn sie den Koordinator vollständig nicht erreichen können. Das mag sich ändern wenn Aqara eigene Router dazu kommen - das probiere ich gerade aus

Tja, ich habe sehr viele Aquara/TuYa Geräte, weil ich nicht dachte, dass der Standard nicht gleich Standard ist :astonished:
Und weil sie billig waren.

Und so wie es beschrieben ist, wird es auch nichts bringen, den Conbee mal für eine Stunde auszustecken, um diese Geräte zu zwingen, sich auf den nächsten Router zu hängen, weil sie sofort wieder zurückswitchen würden.

Wenn ich mir die Shepherd.db ansehe, haben alle Devices ein Array epList
Die Endgeräte mit nur einem Eintrag '1'
Router mit mehreren Einträgen, z.B.: ("epList":[1,242]) oder ("epList":[1,41,242])

Sind das die zur Verfügung stehenden Endpoints zum Verbinden, ausgelesen aus den Devices?

Aber kurz eine Frage für die Zukunft:
Wenn ich den LAN-Stick habe, brauche ich den Slave nicht mehr. Genügt es den Zigbee-Adapter auf dem Slave zu löschen, auf dem Master zu installieren und die Shepherd.db und die dev_names.json zu kopieren, dass die Devices nicht neu angelernt werden müssen?
Wobei natürlich der Adapter auf dem Master die gleichen EInstellungen haben muß.

[diwoma]

@asgothian
Anscheinend hatte das große Problem der nicht verbundenen Devices tatsächlich etwas mit äusseren Einflüssen zu tun:
Ich hatte einen 5-Port tp-Link Switch an der Wand gegenüber dem Stick montiert. Der ist defekt geworden und ich habe ihn durch einen Netgear 5-Port PoE-Switch ersetzt, weil ich keinen anderen hatte. Anscheinend störte der so stark, das der Koordinator nicht alle Devices erreichen konnte (oder umgekehrt die Devices nicht den Koordiator).
Was dann allerdings wiederum die Frage nach dem Mesh aufwirft, denn durch die stromgebunden Rollo-Aktoren rund ums Haus und die zahlreichen Licht-Schalter und mobilen Steckdosen (die verbunden waren) hätten die Signale ohne weiteres über eine andere Route zum Koordinator kommen können.

Jetzt habe ich den Switch wieder ersetzt und die meisten Devices sind wieder erreichbar (bis auf ein paar, die sich immer noch weigern)

Ich habe meinen LAN-Koordinator mit CC2652P2 bekommen und werde ihn in Betrieb nehmen, ausserhalb meines Büros mit allen möglichen Störquellen. Mal sehen, wie sich das verbessert.

[Pedder007]

@diwoma
Hallöle, hier mal noch meine 5-Cent bzgl. Erfahrungswerten, wobei @Asgothian schon ganz vieles genannt hat, was ich auch so kenne.

Mein ioBroker Master, bestückt mit deCONZ und ConBee II Stick, fing über die Feiertage an, vermeintlicher 'langsamer' zu werden. Latenzen bei Betätigung von ZigBee Remotes (Ikea Tradfri Button und auch Osram Mini Switches), bis hin zu gar keiner Reaktion mehr, wobei die Aktoren (in dem Fall Lampen und Jalousien, ebenfalls Zigbee) z. B. via VIS, oder aus Scripten heraus, weiter einwandfrei funktionierten.

Nach einem Reboot des ganzen Systems war dieses zwar wieder etwas schneller, allerdings hat es genau besagte Buttons nun völlig 'zerlegt'. Hellgrau in der Phoscon App und auch in der deCONZ GUI nicht mehr per Signal-Monitor PlugIn 'anpingbar', obwohl dort teils noch mit dicker grüner Verbindung dargestellt.

Da ich ohnehin schon einen ZigBee LAN Stick von Dmitrij (=CC2652P) hier hatte, habe ich nun angefangen die Problem-Devices auf den ZigBee Adapter auf einen meiner ioBroker Slaves umzuziehen. Erste Wahrnehmung: Das System, sprich auch z. B. deCONZ GUI reagieren wieder flüssiger.

Meine Schlussfolgerung: Bei insgesamt rd. 100 Devices im deConz/ConBee II Mesh, könnte es dann wohl doch evtl. mal eng werden. Interessant daran ist allerdings, dass das lange Zeit so ganz gut lief. Das Gefühl, das es enger werden könnte, habe ich eigentlich erst seit dem Upgrade auf Bullseye, welches ich erst im Spätherbst gemacht hatte.