Deconz-rest-plugin: IKEA-Leuchten verloren gelegentlich die Verbindung

Gleiches hier mit 2.05.58. Ein Tradfri GU10 scheint unverantwortlich zu sein:

Ist mir ein paar Tage zuvor auch mit einem hellen Lichtstreifen passiert, also nehme ich kein IKEA-spezifisches Problem an. Geräte müssen aus- und wieder eingeschaltet werden und sind danach wieder normal. In einigen Fällen immer noch ärgerlich, vor allem bei meinen FLOALT-Panels, die direkt mit Strom versorgt werden und keinen Wandschalter zum Einschalten haben.

1. Irgendein Hinweis warum?

Das REST-API-Plugin markiert ein Licht als nicht erreichbar, wenn es einige Male keine Antwort erhält, wenn das Licht nach seinem Status abgefragt wird. Die Ursache für das Nichterhalten einer Antwort ist in der Reihenfolge der Wahrscheinlichkeit:
ein. Die Stromversorgung des Lichts wurde unterbrochen (z. B. durch einen Wandschalter aus dem 20. Jahrhundert).
b. Das ZigBee-Netzwerk hat einen Schluckauf (z. B. aufgrund von Funkstörungen oder Routing-Problemen im Netz). In diesem Fall reagiert das Licht immer noch auf Gruppenbefehle.
c. Die Firmware des Lichts ist abgestürzt.

1. Ist es möglich, die Verbindung wiederherzustellen, außer die Stromversorgung zu trennen / anzuschließen?

In a) und c): nein. In b): ja.

Das REST-API-Plugin markiert das Licht als erreichbar, wenn es eine Nachricht von ihm empfängt. Wenn Sie das Licht einschalten, wird eine Geräteankündigungsnachricht gesendet. In b) kommt das Licht normalerweise spontan zurück, wenn die nächste Umfrage erfolgreich ist. Sie können den Knoten auch in der deCONZ-GUI auswählen und 0 drücken.

Gleiches Problem auch in Version 2.05.59.

Ich habe auch dieses Problem, auch nach dem Upgrade auf 2.05.59. Heute war eine meiner drei Außenleuchten "weg".
Seine Tradfri-Glühbirnen alle drei.

@ebaauw Danke für deine Erklärung.

ein. Die Stromversorgung des Lichts wurde unterbrochen (z. B. durch einen Wandschalter aus dem 20. Jahrhundert).

Für diese Leuchten sind keine Wandschalter verfügbar, daher kann ich die Stromversorgung nicht versehentlich trennen.

b. Das ZigBee-Netzwerk hat einen Schluckauf (z. B. aufgrund von Funkstörungen oder Routing-Problemen im Netz). In diesem Fall reagiert das Licht immer noch auf Gruppenbefehle.

Die Lichter reagieren nicht auf Gruppenbefehle, wenn die Verbindung unterbrochen wird (die Lichter werden in der Phoscon-App einem Farbton-Dimmer zugewiesen und reagieren nicht auf den Farbton-Dimmer, wenn die Verbindung unterbrochen wird).

c. Die Firmware des Lichts ist abgestürzt.

Firmware 1.2.214 ist auf allen meinen IKEA GU10-Spots installiert. Habe 20+ von ihnen und ein zufälliges Licht geht offline, sagen wir eines in den 2-3 Wochen.

Sie können die neueste deCONZ-Version mit https://github.com/dresden-elektronik/deconz-rest-plugin/commit/48d2c39a267b5c6d025577eed7530be27932aa2c ausprobieren

Ich hatte in den letzten Monaten zweimal die gleiche Erfahrung mit zwei verschiedenen E14 IKEA-Lampen (IKEA fw 1.2.214).
Power Cycling hat bei mir beide Male funktioniert.

c. Die Firmware des Lichts ist abgestürzt.

Wenn die Lichter nicht einmal auf Gruppenbefehle reagieren, scheint es wie ein Firmware-Absturz.

2.05.59 hat die IKEA-Gateway-Parameter angepasst, um die Lichtzustandsberichterstattung zu konfigurieren. Hauptsächlich in der Hoffnung, durch die Verwendung von Konfigurationen, die IKEA selbst nicht testet, keine Fehler auszulösen. Nebenbei bemerkt, die Änderung führt dazu, dass keine Timer mehr für die Berichterstellung auf dem Gerät verwendet werden.

Die neue Konfiguration wird angewendet, sobald ein Licht aus- und wieder eingeschaltet wird.

Wir senden weiterhin einige Wartungsanfragen wie Gruppenmitgliedschafts- und Nachbartabellenabfragen an die Lichter und können diese weiter einschränken, wenn sich die Stabilität mit 2.05.59 nicht verbessert.

Beachten Sie, dass möglicherweise auch ein Fehler in der Light-Firmware vorliegt, der nicht mit den vom Gateway gesendeten Anforderungen zusammenhängt.

c. Die Firmware des Lichts ist abgestürzt.

Wenn die Lichter nicht einmal auf Gruppenbefehle reagieren, scheint es wie ein Firmware-Absturz.

2.05.59 hat die IKEA-Gateway-Parameter angepasst, um die Lichtzustandsberichterstattung zu konfigurieren. Hauptsächlich in der Hoffnung, durch die Verwendung von Konfigurationen, die IKEA selbst nicht testet, keine Fehler auszulösen. Nebenbei bemerkt, die Änderung führt dazu, dass keine Timer mehr für die Berichterstellung auf dem Gerät verwendet werden.

Die neue Konfiguration wird angewendet, sobald ein Licht aus- und wieder eingeschaltet wird.

Wir senden weiterhin einige Wartungsanfragen wie Gruppenmitgliedschafts- und Nachbartabellenabfragen an die Lichter und können diese weiter einschränken, wenn sich die Stabilität mit 2.05.59 nicht verbessert.

Beachten Sie, dass möglicherweise auch ein Fehler in der Light-Firmware vorliegt, der nicht mit den vom Gateway gesendeten Anforderungen zusammenhängt.

+1 auf "nicht unbedingt bezogen auf deconz, sondern auf das ZigBee-Netzwerk oder den Hersteller FW" in Korrelation mit der ZigBee-Standardinterpretation im Hersteller FW.

Ich habe gerade auf 2.05.59 aktualisiert und nach dem Neustart von deconz ist das gleiche Licht nicht mehr erreichbar. Durch Drücken von 0 in GUI wird es nicht zurückgebracht. Jedes andere Licht funktioniert. In meinem Fall könnte dies genauso gut ein Problem mit dem Licht selbst sein.

@ peer69 @ thomas70 Haben Sie das Licht aus- und wieder eingeschaltet, da dies von @manup unter https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment -463948127 erwähnt wird?

Die neue Konfiguration wird angewendet, sobald ein Licht aus- und wieder eingeschaltet wird.

Guter Hinweis, habe das nicht getan. Vorerst musste ich aus einem anderen Grund auf .58 zurückgreifen (hohe CPU-Last, wodurch das Gateway nicht mehr reagiert), werde dies später heute mit .59 erneut versuchen und alle Ikea-Lichter aus- und wieder einschalten.

Ich habe auch dieses Problem, es ist zweimal für das gleiche GU 10-Licht passiert. Derzeit läuft 2.05.59, und ich habe die Lichter nach dem Update aus- und wieder eingeschaltet.

Ich habe vergessen hinzuzufügen, dass es manchmal so aussieht, als ob es dieselbe Glühbirne ist, die immer wieder ausfällt. Vor einiger Zeit hatte ich Probleme mit einer anderen Glühbirne, und es war immer diese, die aufhörte zu reagieren.

Nach dem Aus- und Einschalten kamen meine IKEA-Lampen zurück. Mein IKEA FLOALT Panel WS ist jedoch immer noch offline

Ich habe das gleiche Problem und mache es schon eine ganze Weile, und ich würde sagen, dass .59 die Dinge für mich tatsächlich noch schlimmer gemacht hat. Ich habe 80 Knoten, von denen 32 Trådfri-Lichter und -Schalter sind, 5 Hue-Lichter und der Rest verschiedene batteriebetriebene Xiaomi-Geräte wie Temperatur, Bewegung, Rauchmelder usw. In meinem Fall hat jeder einzelne Gerätetyp mindestens einmal nicht reagiert Es sind nicht nur die Trådfri-Lichter, sondern zur Zeit habe ich nur Probleme mit den Trådfri- und Hue-Lichtern.

Die Sache ist, dass ich alle Lichter durch eine Hue-Brücke und die Xiaomi-Sensoren durch das Xiaomi-Gateway geleitet habe und sie dann alle absolut solide waren. Ich denke also nicht, dass die Geräte-Firmware der Schuldige in meinem Fall ist, es sei denn, sie wird durch verursacht die Änderung der Umstände.

Ich habe sechs Trådfri GU10-Leuchten an einem Ort, die zuvor einwandfrei funktioniert haben, aber nach dem Upgrade auf .59 und einigen Stromzyklen später reagieren sie jetzt fast nicht mehr und ich muss sie wahrscheinlich zurücksetzen. Was seltsam ist, ist, dass sich diese Unempfindlichkeit auch von verschiedenen Lichtern "zu bewegen" scheint, je nachdem, welche Lichter Strom haben. Wenn ich einige der nicht reagierenden Lichter ausschalte, kann es eine Weile dauern, und dann ist es plötzlich ein anderes Licht, das nicht richtig funktionieren möchte. Vielleicht gibt es irgendwo einen Versatz, der Dinge kaputt macht?

Die Sache ist, dass ich alle Lichter durch eine Hue-Brücke und die Xiaomi-Sensoren durch das Xiaomi-Gateway geleitet habe und sie dann alle absolut solide waren. Ich denke also nicht, dass die Geräte-Firmware der Schuldige in meinem Fall ist, es sei denn, sie wird durch verursacht die Änderung der Umstände.

Interessant, hatten Sie auch alle 32 Ikea-Leuchten im Hue-Netzwerk? Ich frage, weil Hue Bridge nur Polling verwendet und keine Attributberichte konfiguriert.

Hatten Sie auch Router-Geräte wie die Hue- oder Ikea-Leuchten im Xiaomi-Netzwerk?

Ich habe sechs Trådfri GU10-Leuchten an einem Ort, die zuvor einwandfrei funktioniert haben, aber nach dem Upgrade auf .59 und einigen Stromzyklen später reagieren sie jetzt fast nicht mehr und ich muss sie wahrscheinlich zurücksetzen. Was seltsam ist, ist, dass sich diese Unempfindlichkeit auch von verschiedenen Lichtern "zu bewegen" scheint, je nachdem, welche Lichter Strom haben. Wenn ich einige der nicht reagierenden Lichter ausschalte, kann es eine Weile dauern, und dann ist es plötzlich ein anderes Licht, das nicht richtig funktionieren möchte. Vielleicht gibt es irgendwo einen Versatz, der Dinge kaputt macht?

Hmm, das ist ziemlich schlimm. Ich frage mich wirklich, wie das passiert. 2.05.59 ist Ikea-Lichtern "vertraut" als frühere Versionen. Die Konfiguration erfolgt jetzt wie beim Ikea-Gateway.

Wenn ein Licht nicht mehr reagiert, können Sie den Knoten in deCONZ auswählen und 0 drücken, wenn es wieder reagiert / gelb wird. Das Licht muss nicht aus- und wieder eingeschaltet werden. Beachten Sie, dass das Licht, das in diesem Fall zum Zombie wird, bald behoben wird. Dies kann derzeit in einer bestimmten Netzwerkkonstellation geschehen.

Übrigens die üblichen Fragen:

• Welche Firmware-Version verwenden Sie?
• RaspBee oder ConBee?
• Wenn ConBee, verwenden Sie ein USB-Verlängerungskabel?

Es hat eine Weile länger gedauert als erwartet, aber jetzt scheint alles wieder gut zu funktionieren. Zumindest für den Moment, soweit ich das beurteilen kann.

Ich habe den Server neu gestartet und außerdem jedes einzelne Netzlicht im Netzwerk aus- und wieder eingeschaltet, um sicherzustellen, dass die neueste Konfiguration abgerufen wurde. Trotzdem dauerte es einige Stunden, bis das Problem behoben war, sodass ich davon ausgegangen war, dass dies ein wenig verfrüht war Das Problem blieb bestehen, da es nicht sofort funktionierte.

Interessant, hatten Sie auch alle 32 Ikea-Leuchten im Hue-Netzwerk? Ich frage, weil Hue Bridge nur Polling verwendet und keine Attributberichte konfiguriert.

Mehr oder weniger. Ich hatte 31 Ikea-Lichter im Hue-Netzwerk sowie die Hue-Lichter. Das 32. Ikea-Gerät ist die Schaltsteckdose, die ich damals noch nicht gekauft hatte.

Hatten Sie auch Router-Geräte wie die Hue- oder Ikea-Leuchten im Xiaomi-Netzwerk?

Nein, nur batteriebetriebene Sensoren

Wenn ein Licht nicht mehr reagiert, können Sie den Knoten in deCONZ auswählen und 0 drücken, wenn es wieder reagiert / gelb wird. Das Licht muss nicht aus- und wieder eingeschaltet werden. Beachten Sie, dass das Licht, das in diesem Fall zum Zombie wird, bald behoben wird. Dies kann derzeit in einer bestimmten Netzwerkkonstellation geschehen.

Ich habe es schon mehrmals ohne Wirkung versucht. Und was die Hardware und das Setup betrifft, verwende ich einen ConBee mit USB-Verlängerungskabel und 262F0500. Da jetzt für mich alles in Ordnung zu sein scheint, sind diese Informationen im Moment möglicherweise nicht von Nutzen, aber ich werde versuchen, keine Schlussfolgerungen zu ziehen und das Netzwerk einige Tage laufen zu lassen, um sicherzustellen, dass das Problem nicht auftritt Rückkehr.

Ich habe seit dem letzten Wochenende .59 ausgeführt und ich verliere immer noch zufällige Ikea-Lichter. (16 E27-Lampen an der Hausfassade.)
Bulb FW ist die gleiche wie andere, die sich noch auf dem Ikea Gateway befinden.
Verwenden von ConBee mit 262F0500 FW.
Letztes Wochenende kaufte ich auch eine HUE-Brücke und wollte gerade die Lichter bewegen, als ich den Release Note 'Under the Hood' für .59 bemerkte. Beschlossen, sich zurückzuhalten, werden aber das kommende Wochenende überdenken.
Deconz wird immer noch mein bester Xiaomi / mi Cube-Controller meiner Wahl sein. Ich habe noch keine Geste verpasst.

Ich habe seit dem letzten Wochenende .59 ausgeführt und ich verliere immer noch zufällige Ikea-Lichter. (16 E27-Lampen an der Hausfassade.)
Bulb FW ist die gleiche wie andere, die sich noch auf dem Ikea Gateway befinden.
Verwenden von ConBee mit 262F0500 FW.
Letztes Wochenende kaufte ich auch eine HUE-Brücke und wollte gerade die Lichter bewegen, als ich den Release Note 'Under the Hood' für .59 bemerkte. Beschlossen, sich zurückzuhalten, werden aber das kommende Wochenende überdenken.
Deconz wird immer noch mein bester Xiaomi / mi Cube-Controller meiner Wahl sein. Ich habe noch keine Geste verpasst.

Ich habe hier die gleiche Situation, 16 IKEA-Leuchten, 2 IKEA-Steckdosen, einen Heiman-Stecker und einen Innr-Stecker sowie einige Xiaomi-Sensoren (Würfel- / Türsensoren / Bewegungssensor). Hatte nie Probleme mit Nicht-IKEA-Geräten. Derzeit habe ich jedoch fast täglich Probleme, bei denen ein IKEA-Licht aus dem Netzwerk fällt

Ich verwende einen Conbee mit einem USB-Verlängerungskabel für die Firmware 0x26300500 und deCONZ .59

Meine Lichter funktionieren schon eine Weile einwandfrei, aber vor ein paar Tagen reagierte meine Trådfri E14-Lampe plötzlich nicht mehr. Ein Zyklus später wurde es wieder lebendig.

Heute war es Zeit für einen der GU10 auszusteigen. Es liegt physisch sehr nahe am zuvor erwähnten E14, daher bin ich mir nicht sicher, ob es ein Zufall ist oder nicht. Das GU10 wurde möglicherweise über das E14 geroutet, obwohl sich alle meine Lichter in ConBee-Reichweite befinden.

Das Auswählen der Knoten und das Drücken von 0 in deCONZ bewirkt nichts. Ich habe auch versucht, den deCONZ-Container neu zu starten, und während das Netzwerk beim Start umgeleitet wird, wird keine Route mit dieser bestimmten Lampe verbunden. Was wäre hier der beste Ansatz, um mit der Fehlerbehebung fortzufahren?

12 Tage später ist ein anderes GU10 nicht mehr erreichbar und kann ohne Aus- und Wiedereinschalten nicht wieder verbunden werden.

Gerne teilen wir Ihnen alle Informationen mit, die Sie benötigen, um dieses Problem zu lösen.

Gleich hier, gestern nach 6 Tagen einwandfreier Verbindung, habe ich eine meiner Tradfri-Lampen verloren. Ein- / Ausschalten und Zurücksetzen haben nicht geholfen. Es ist immer noch gelb in deConz, kann es aber nicht verbinden oder steuern.

Hier gilt das gleiche. Nach einigen Tagen ohne Probleme reagierten heute zwei meiner GU10 Tradfri-Lampen nicht mehr. Ich konnte einen von ihnen durch Drücken von 0 in der GUI wieder zum Leben erwecken, aber ich musste den anderen mit dem Powercycle fahren.
Glücklicherweise scheint dies nur für GU10-Geräte atm zu passieren, meine FLOALT-Panels hatten noch keine Probleme (in meinem Setup können sie nur mit dem Leistungsschalter aus- und wieder eingeschaltet werden).

Das Problem hat sich auch für mich fortgesetzt. Ich habe jetzt 3-4 weitere GU10-Lampen gesehen, die die Verbindung verloren haben, sowie eine meiner Hue E27 und einen Xiaomi-Türsensor (Magnet). Einige Lichter haben nach einem Aus- und Wiedereinschalten wieder funktioniert, andere nicht. Das Drücken von 0 bewirkt nichts.

Es ist auch bemerkenswert, dass der Xiaomi-Sensor wieder funktioniert hat, nachdem ich ein benachbartes und nicht reagierendes GU10 aus- und wieder eingeschaltet habe. Ich nehme also an, dass der Sensor durch dieses Licht geleitet wurde. Sollte er nicht automatisch umleiten, wenn Verbindungsprobleme auftreten?

Gleiches Problem hier. Gestern habe ich auf die neueste Version .59 aktualisiert, jetzt reagieren einige Ikea-Lichter nicht mehr

Hallo, können Sie mehr Einblicke in das gesamte Netzwerk geben, wie z. B. die Netzwerkgröße und andere netzbetriebene Geräte?

Ich habe mein Heimnetzwerk vor einigen Tagen neu geordnet, jetzt einschließlich:

• 5x IKEA WS GU10 (Firmware 1.2.221, Produktcode LED1537R6GU10EU)
  Mit Mac-Adresse 0x000b57ff ..... (älterer Stapel)
• 2x IKEA dimmbares E27 (Firmware 1.2.214)
• 1x IKEA E14 WS light (Firmware 1.2.221)
• 1x IKEA Repeater (Firmware 2.0.019)
• 1x IKEA-Steckdose (Firmware 2.0.019)
• 1x OSRAM GU 10
• 1x OSRAM E27 Farbbirne
• 1x OSRAM-Stecker
• 1x Farbton E27 Farbbirne
• 1x Hue E27 dimmbare Luxbirne

deCONZ 2.05.59; ConBee-Firmware 0x26300500 (aber 0x262f0500 ist auch in Ordnung).

Ich habe 4x FLS-PP lp, aber diese sind jetzt zum Testen ausgeschaltet, da sie als sehr starke Signalverstärker fungieren.

Bei Sensoren und Switches beträgt die Gesamtnetzwerkgröße 55.
Alle Lichter sind immer mit Strom versorgt und zeigen bisher keine Ausfälle.

Hier sind einige detailliertere Spezifikationen meines Netzwerks, falls dies hilfreich sein kann. Ich verwende immer noch 2.05.59 mit 262F0500 und einem Verlängerungskabel zum ConBee. Wie oben erwähnt, war das Netzwerk nach dem ersten Update auf 2.05.59 und dem Aus- und Einschalten jedes netzbetriebenen Geräts und dem Warten auf einige Stunden fast eine Woche lang fehlerfrei. Es scheint also eine Weile zu dauern, bis die Probleme auftreten. Leider ist das Problem erneut aufgetreten, und ein vollständiger Aus- und Wiedereinschalten aller netzbetriebenen Geräte sowie ein Neustart von deCONZ lösen das Problem nicht mehr. Es scheint auch, dass das Problem von Gerät zu Gerät wandert, da manchmal ein Licht für eine Weile nicht reagiert und sich dann selbst behebt.

Ich hatte heute ein Problem, bei dem der Trådfri E14 nicht mehr reagierte, sowie ein Farbton E27. Nach einem Aus- und Wiedereinschalten des E27 wurde der E14 wieder zum Leben erweckt, ohne dass ich ihn überhaupt berührte. Das Gleiche gilt für die nicht reagierenden GU10s, die ab und zu Handelsplätze zu sein scheinen. Es gibt also jeden Tag mindestens zwei nicht reagierende GU10s, aber es sind nicht immer die gleichen Lichter, so dass einige anfangen zu arbeiten, während andere brechen und umgekehrt.

Mein Netzwerk besteht derzeit aus den folgenden 80 Geräten, einschließlich ConBee, und die netzbetriebenen Geräte werden rund um die Uhr mit Strom versorgt.

Netzstrom

| Menge | Geben Sie | ein Firmware |
| ---------- | ------ | ------------- |
| 30 | Trådfri GU10 dimmbar | 1.2.214 |
| 4 | Trådfri GU10 Weißspektrum | 1.2.217 |
| 1 | Trådfri E14 opal dimmbar | 1.2.217 |
| 1 | Trådfri Steckdose | 1.4.020 |
| 3 | Farbton E27 Weiß und Farbe A19 | 1.29.0_r21169 |
| 2 | Farbton E14 Weißes Ambiente LTW012 | 1.29.0_r21169 |

Batteriebetrieben

Menge | Geben Sie | ein Firmware
--------- | ------ | -----------
1 | Trådfri Ein / Aus-Schalter | 1.4.018
10 | Xiaomi Aqara Multisensor (quadratische Temperatur / Brummen / Druck) | 20161129
3 | Xiaomi Aqara Bewegungssensor (Bewegung / Lux) | 20170627
4 | Xiaomi Aqara Wassersensor | 20170721
1 | Farbton Bewegungssensor | 6.1.0.18912
11 | Xiaomi Aqara Kontaktsensor | 20161128
8 | Xiaomi / Honeywell Rauchsensor | N / A

Letzte Woche schien Deconz größtenteils gut zu laufen, aber gestern hatte ich eine andere IKEA-Lampe (weißes Spektrum), die die Verbindung zu Deconz verlor. Selbst das Aus- und Wiedereinschalten half nicht. Musste deconz neu starten, damit es irgendwie wieder funktioniert.

Ich habe ein Netzwerk mit hauptsächlich IKEA-Lampen, einer Heiman-Steckdose und einigen Xiaomi-Sensoren.

Einige Spezifikationen meines ZigBee-Netzwerks:

Conbee-Firmware 262F0500 mit Verlängerungskabel an einem NUC.
deCONZ 2.05.55 in Docker, also muss ich als erstes auf 2.05.59 upgraden, denke ich.

Angetrieben (24/7)

| Menge | Geben Sie | ein Firmware |
| ------------- | ------------- | ------------- |
| 4x | Tradfri E27 weiß | 1.1.1.0-5.7.2.0 |
| 2x | Tradfri E27 weiß | 1.2.214 |
| 21x | Tradfri GU10 dimmbar | 1.2.214 |
| 3x | Osram Smart + Buchse | 1.04.12 |

Batteriebetrieben

| Menge | Geben Sie | ein Firmware |
| ------------- | ------------- | ------------- |
| 3x | Farbton-Dimmerschalter | 5.45.1.17846 |
| 1x | Aqara Smart Switch | 20180525 |
| 1x | Aqara Smart Switch | 20161128 |
| 1x | Aqara Doppel-Funkschalter | 20170411 |
| 1x | TRADFRI remote | 1.2.214 |
| 6x | Aqara Multisensor | 20161129 |
| 10x | Aqara Kontaktsensor | 20161128 |
| 5x | Aqara Bewegungssensor | 20170627 |
| 1x | Aqara Lecksensor | 20170721 |
| 1x | Aqara Vibrationssensor | 20180130 |

Irgendwelche Updates dazu für die aktuelle Version? Ich habe 3 Tage lang .60 ausgeführt und noch kein Licht hat die Verbindung verloren.

Leider hatte ich bereits eine verlorene Verbindung mit einer normalen weißen Tradfri E27-Lampe auf .60 und der neuesten Firmware.

Das sind schlechte Nachrichten ... wenn ich das richtig verstehe, wurden die Abfrageintervalle in .60 geändert, um weniger aggressiv zu sein. Aggressive Umfragen, bei denen ein Licht auflegte, machten für mich vollkommen Sinn. Schade, dass dies nicht die Lösung für unser Problem zu sein scheint.

Gestern habe ich die Stromversorgung für alle netzbetriebenen Geräte ausgeschaltet und auf 2.05.60 und 26320500 aktualisiert, bevor ich sie wieder einschaltete, nur um auf Nummer sicher zu gehen. Die Lichter funktionierten dann alle ungefähr 24 Stunden lang einwandfrei, aber erst vor wenigen Minuten bemerkte ich, dass einer meiner GU10s nicht mehr reagierte. Zum Glück wurde es einige Minuten später ohne manuelle Interaktion von meinem Ende wieder zum Leben erweckt, sodass das Netzwerk möglicherweise nur verstopft war.

@ JBS5 Ich würde empfehlen, das 4x Tradfri E27 white unter 1.1.1.0-5.7.2.0 auf eine aktuelle Firmware-Version zu aktualisieren. Wenn ich mich richtig erinnere, ist dies immer noch die allererste Version.

@jurriaan Welche Version hat Ihre Tradfri E27 weiße Glühbirne?

Das sind schlechte Nachrichten ... wenn ich das richtig verstehe, wurden die Abfrageintervalle in .60 geändert, um weniger aggressiv zu sein.

Ja, im Grunde sehr ähnlich zu IKEA Gateway. Der einzige verbleibende Unterschied ist nun die periodische Abfrage von Nachbartabellen (die zum Anzeigen der Maschennetzwerklinien verwendet wird).

Dies kann deaktiviert werden, indem Sie in deCONZ auf das CRE-Symbol klicken und "Router und Koordinator" deaktivieren.
Könnte einen Test wert sein.

Auf Reddit wurde in einem Post erwähnt, dass das IKEA-Gateway theoretisch bis zu 100 Geräte unterstützen sollte, aber dass es nicht sehr gut getestet wird. Es wäre interessant zu wissen, welche Netzwerkgröße das IKEA-Team normalerweise testet.

https://www.reddit.com/r/tradfri/comments/96yiq4/google_home_losing_lamps_and_rooms/e4x1scz/?context=1

Möglicherweise sind 100 Geräte an Ihr Gateway angeschlossen. Dies wird von uns nicht richtig getestet, weshalb wir dies nicht garantieren. Aber die technische Grenze liegt bei 100, und ich habe Leute gesehen, die 100 Geräte mit keinen oder nur geringfügigen Problemen haben.

Neue Versionen für das Gateway unterstützen dieselbe Anzahl von Geräten (offiziell 50). Sie können Ihrem System ein weiteres Gateway hinzufügen, wenn Sie dies verdoppeln möchten.

@ JBS5 Ich würde empfehlen, das 4x Tradfri E27 white unter 1.1.1.0-5.7.2.0 auf eine aktuelle Firmware-Version zu aktualisieren. Wenn ich mich richtig erinnere, ist dies immer noch die allererste Version.

Diese E27-Lampen mit der alten Firmware sind in den letzten 6 Monaten nicht ausgefallen, während andere ...

Sehr interessant, wie wäre es mit dem E27 in Version 1.2.214?

Sehr interessant, wie wäre es mit dem E27 in Version 1.2.214?

Sie haben in den letzten Monaten nur einmal die Verbindung verloren.

Es ist ein paar Wochen her, seit das letzte GU10 die Verbindung verloren hat, während ich noch deCONZ 2.05.55 und die Firmware 262F0500 auf dem Conbee verwende.

Ich habe auch dieses Problem. Nur Ikea-Knoten (43, hauptsächlich Lichter). Ich habe keine Kenntnisse über ZigBee, aber da ich es nicht erwähnt habe: Mein Netzwerk scheint stabiler zu sein, wenn OTAU deaktiviert ist. Neulich habe ich auch die Netzwerkeinstellungen auf weniger sicher geändert. Ich kann mich nicht erinnern, welches, aber danach habe ich kein Licht verloren.

Nach einigen Tagen ohne Probleme reagieren einige GU10 nicht mehr.
Ein anderes Problem hat möglicherweise nichts damit zu tun, aber auch ein Osram-Licht hat die Verbindung verloren. Obwohl es immer noch in der GUI angezeigt wurde und zu greifen schien, konnte ich es nicht mehr kontrollieren. Musste das Licht löschen und lesen, wurde ihm ein anderes Licht Nr. Zugewiesen, erhielt aber kurz nach dem Hinzufügen seinen früheren Namen zurück. Keine Ahnung, was hier passiert, aber dies ist einiges mehr Wartung, als ich für mein Setup sehen möchte.

@ peer69 hast du auch versucht, das Licht einzuschalten ? Normalerweise sollte ein Zurücksetzen auf die Werkseinstellungen nicht erforderlich sein.
Du bist am 2.05.60? Können Sie auch weitere Details zu Ihrem Netzwerk, der Anzahl der Leuchten und netzbetriebenen Geräte angeben?

@manup Ich habe das Licht
In der Zwischenzeit trat dieses Problem auch nach dem Zurücksetzen auf die Werkseinstellungen wieder auf und betraf auch ein anderes OSRAM-Licht. Im Moment habe ich die einzigen zwei OSRAM-Leuchten in meinem Netzwerk entfernt und sie durch Farbbirnen ersetzt. Ich kann einige Tests mit den ORSAM-Leuchten anbieten, aber dafür würde ich etwas Zeit brauchen.

Ich verwende 2.05.60. Derzeit sind 57 Knoten mit dem Netzwerk verbunden, von denen 27 Geräte über das Stromnetz mit Strom versorgt werden. Ich verwende 13 IKEA GU10, 1 IKEA FLOALT Panel, 2 IKEA E14, 3 OSRAM Smart + Stecker, 3 E14-Farbbirnen, 5 E27-Farbbirnen, 1 Farbton-Lichtstreifen.

Ich musste in den letzten Tagen auch einige IKEA GU10 mit dem Fahrrad fahren, was nicht mehr reagierte. Nach dem Powercycle ist alles wieder normal und ich sehe kein Muster. Ich habe Lampen mit mehreren GU10 und nicht mehr als ein GU10 reagierte gleichzeitig nicht mehr, obwohl sie immer als Gruppe gesteuert werden.

Im Moment bin ich wieder auf dem ersten Platz. Jetzt habe ich regelmäßig 2-3 Lichter, die nicht reagieren, aber es springt zwischen verschiedenen Lichtern, so dass sie manchmal funktionieren und manchmal nicht davon abhängen, welche anderen Lichter online sind. Das Problem scheint kaskadierend zu sein, denn wenn ich einige Lichter durch Ausschalten der Stromversorgung physisch ausschalte, wird das Problem auf andere Lichter verschoben.

Ich habe auch ein paar Xiaomi-Temperatursensoren sowie Türsensoren und einen IKEA-Ein / Aus-Schalter verloren, aber sie werden nicht wieder eingeblendet, sodass sie wahrscheinlich erneut gekoppelt werden müssen, um wieder zu arbeiten.

Die Dinge funktionierten sofort nach einem vollständigen Aus- und Einschalten einwandfrei, wie ich bereits bemerkte, aber einige Tage später reagierten die Lichter wieder nicht mehr und das schon seit ein paar Wochen. Damals, als es das erste Mal passierte, dass ein Gast den E14 mehrere Stunden lang versehentlich vom Stromnetz getrennt hat, bin ich mir nicht sicher, ob er völlig unabhängig ist oder ob unerwartete Störungen des ZigBee-Netzes das Routing verrückt gemacht haben. Angesichts der Tatsache, dass ich anscheinend nicht der einzige mit diesen Problemen bin, denke ich, dass es nur ein Zufall gewesen sein könnte.

Ich mag das Konzept, alle meine ZigBee-Geräte in einem einzigen Netz zu haben, sehr, aber ich bin fast an dem Punkt angelangt, an dem ich die alten Hue- und Xiaomi-Gateways hochfahre und den ConBee in eine Schublade lege, was ich wirklich nicht tun möchte aus mehreren anderen Gründen. Hat jemand Tipps zur weiteren Fehlerbehebung, anhand derer ich genau ermitteln kann, was gerade passiert und wie ich das Problem beheben kann?

Einer meiner IKEA GU10-Spots reagiert jetzt ebenfalls nicht mehr.

Im Sniffer sehe ich, dass es noch etwas "lebendig" ist und NWK-Verbindungsstatusnachrichten sendet, aber es denkt offensichtlich, dass es allein im Netzwerk ist (Verbindungsstatusanzahl: 0).

Es reagiert nicht auf Unicast-Befehle, sondern sendet regelmäßig den ZCL-Attributbericht der Modell-ID.

Schnüffeln seit ~ 2 Stunden, nicht sicher, wann es nicht mehr reagierte und ob es verwandt ist, aber die ZCL-Sequenznummer des Berichts ist niedrig:

Ich werde noch einige Tests machen und es für eine Weile nicht aus- und wieder einschalten.

Meine Tradri-Steckdose hat sich auch heute wirklich komisch verhalten und lief in Neustartkreisen, hatte diese noch nie zuvor.

Gerade bemerkt, dass ein zweiter IKEA GU10 ebenfalls ein geführter ist, die gleichen Symptome wie der andere.

Beide Geräte antworten nicht auf Unicast-, Groupcast- oder ZCP-NWK-Adressanfragen (Drücken von 0).
Sie senden leere NWK-Verbindungsstatusbefehle.

Die zweite GU10 hat auch ZCL OTA Query Next Image-Anforderungen gesendet.

Es scheint, dass die Antwort nicht durchkommt.

Nur eine wilde Vermutung, aber ich denke, die Lichter in den Puffern sind blockiert und deshalb wird nichts empfangen und verarbeitet. Die Out-Puffer funktionieren immer noch, daher kann die Firmware Berichte und andere Abfragen senden.

Es wäre gut, wenn sie so etwas wie eine einfache Integritätsprüfung implementieren würden, damit die Firmware nach einer Weile neu gestartet werden kann, wenn die Mac-Ebene funktioniert (Befehle werden empfangen), die Ebenen nwk und aps jedoch stumm bleiben.

Ich habe auch dieses Problem, auch nach dem Upgrade auf 2.05.59. Heute war eine meiner drei Außenleuchten "weg".
Seine Tradfri-Glühbirnen alle drei.

Off Topic. Wie findest du dein Licht in all dem? Lol. Ich habe ein ähnliches Setup und ich war wie ... keine Zeit dafür

mit ähnlich meine ich + - 50 Geräte

+ - 50 ist irgendwie ok. Eines unserer Testnetzwerke hat +180 Geräte mit deCONZ auf einem Raspberry Pi 1, das macht Spaß :)

Wir haben einige Pläne, deCONZ um eine bessere Filterung / Sortierung zu erweitern, um das Auffinden von Geräten zu vereinfachen. Derzeit ist dies bei einer bestimmten Anzahl von Geräten sehr umständlich.

Die Lichter stecken noch fest.

Eine interessante Beobachtung: Ich habe den Elternteil eines Philips Hue-Bewegungssensors (einen Hue Lux) ausgeschaltet, damit er nach einem neuen Elternteil suchen muss. Der Sensor versucht nun, über eine der festsitzenden IKEA GU10-Leuchten wieder eine Verbindung herzustellen.

Das Licht reagiert mit einem Befehl zum Verlassen (mit Wiedereintritt). Also hat es die Rejoin-Anfrage bearbeitet!

Leider ist der Hue-Bewegungssensor hartnäckig und versucht, sich für immer wieder dem festgefahrenen GU10-Licht anzuschließen, anstatt nach einem besseren Elternteil zu suchen.

Der interessante Teil hier ist jedoch, dass das feststeckende IKEA-Licht auf die Wiedereintrittsanforderung reagiert, möglicherweise auch NWK-Urlaubsanforderungen verarbeitet, die eine Grundlage für eine Problemumgehung sein könnten, um das Licht wieder in einen funktionierenden Zustand zu versetzen.

Korrektur, Farbton-Bewegungssensor ist nicht zu hartnäckig; Nach einigen Minuten wählte der Sensor einen anderen arbeitenden Elternteil aus (gut).

Der interessante Teil hier ist jedoch, dass das feststeckende IKEA-Licht auf die Wiedereintrittsanforderung reagiert, möglicherweise auch NWK-Urlaubsanforderungen verarbeitet, die eine Grundlage für eine Problemumgehung sein könnten, um das Licht wieder in einen funktionierenden Zustand zu versetzen.

Ich habe das getestet, aber leider funktioniert es nicht. Während die Lichter im festgefahrenen Zustand sind, verarbeiten sie den NWK-Urlaub nicht mit einer erneuten Beitrittsanforderung.

Derzeit kann ich nur den Schluss ziehen, dass IKEA entweder das Grundproblem des feststeckenden Lichts beheben oder eine Art Watchdog + Health Check für NWK / APS-Schichten der Firmware implementieren muss.

Es ist immer noch unbekannt, was genau das Licht in diesen Zustand versetzt - Broadcast-Sturm, bestimmte Befehle, Routing-Probleme ...?

Ich werde meine Ergebnisse und Sniffer-Protokolle an IKEA weiterleiten, hoffentlich können sie damit das Problem aufspüren.

Also @manup , was ist die beste Vorgehensweise, um sich wieder einem festgefahrenen IKEA-Licht

Für mich funktioniert ein Aus- und Wiedereinschalten des Lichts eindeutig am besten

@manup Ich denke, wenn Sie nicht wissen, wie Sie den Patienten
Basieren diese Lichter nicht auch auf dem Ember-Stapel? Vielleicht gibt es Support-Teams oder Foren, die ein Licht ins Dunkel bringen könnten (Wortspiel beabsichtigt).

Reagieren sie laut IKEA auf Anfragen nach Unterstützung wie diesen? Oder sollten wir uns zusammenschließen, um Aufmerksamkeit zu erregen?

Für mich funktioniert ein Aus- und Wiedereinschalten des Lichts eindeutig am besten

Nicht so sehr für mich ...
Ein Neustart von Conbee ist das einzige, was das Problem vorübergehend behebt.
Und dann bleibt das gleiche oder öfter ein anderes IKEA-Licht nach einer Weile hängen ...
Immer nur ein Licht! Es ist so seltsam ... und irritierend ...: /

@manup Super ! Vielen Dank, dass Sie sich damit befasst haben!

Ich habe diesen Thread auch über Reddit an das IKEA Tradfri-Team weitergeleitet. Ich habe gerade eine Antwort von ihnen erhalten, dass sie die Informationen weitergeleitet haben. Hoffen wir, dass sie damit ihre Firmware verbessern oder eine Lösung für dieses Problem finden können :)

In den nächsten Tagen scheint es eine neue Firmware für das tradfri-Gateway zu geben, die sich speziell an den HomeKit-Support richtet. Möglicherweise gibt es auch eine neue Firmware für die Lampen.

@ peer69 Dies ist die neueste Firmware-Version:

[
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/190579-ncp572b444.ebl.ota.ota.signed",
    "fw_build_version": 444,
    "fw_file_version_LSB": 444,
    "fw_file_version_MSB": 5720,
    "fw_filesize": 166270,
    "fw_hotfix_version": 2,
    "fw_image_type": 2,
    "fw_major_version": 5,
    "fw_manufacturer_id": 4476,
    "fw_minor_version": 7,
    "fw_type": 1
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/10005777-4.1-TRADFRI-control-outlet-2.0.022.ota.ota.signed",
    "fw_file_version_LSB": 9763,
    "fw_file_version_MSB": 8194,
    "fw_filesize": 204222,
    "fw_image_type": 4353,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/10005778-4.1-TRADFRI-onoff-shortcut-control-2.0.020.ota.ota.signed",
    "fw_file_version_LSB": 1571,
    "fw_file_version_MSB": 8194,
    "fw_filesize": 182078,
    "fw_image_type": 4549,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/10035514-TRADFRI-bulb-ws-1.2.221.ota.ota.signed",
    "fw_file_version_LSB": 5490,
    "fw_file_version_MSB": 4642,
    "fw_filesize": 172734,
    "fw_image_type": 8705,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/10035534-TRADFRI-bulb-ws-gu10-1.2.221.ota.ota.signed",
    "fw_file_version_LSB": 5490,
    "fw_file_version_MSB": 4642,
    "fw_filesize": 172734,
    "fw_image_type": 8707,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/10038562-TRADFRI-sy5882-bulb-ws-2.0.022.ota.ota.signed",
    "fw_file_version_LSB": 9763,
    "fw_file_version_MSB": 8194,
    "fw_filesize": 209790,
    "fw_image_type": 16900,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/1004764-TRADFRI-bulb-cws-1.3.009.ota.ota.signed",
    "fw_file_version_LSB": 38258,
    "fw_file_version_MSB": 4864,
    "fw_filesize": 178366,
    "fw_image_type": 10241,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159495-TRADFRI-transformer-1.2.245.ota.ota.signed",
    "fw_file_version_LSB": 21874,
    "fw_file_version_MSB": 4644,
    "fw_filesize": 181118,
    "fw_image_type": 16641,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159695-TRADFRI-bulb-ws-1000lm-1.2.217.ota.ota.signed",
    "fw_file_version_LSB": 30066,
    "fw_file_version_MSB": 4641,
    "fw_filesize": 173246,
    "fw_image_type": 8706,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159696-TRADFRI-bulb-w-1000lm-1.2.214.ota.ota.signed",
    "fw_file_version_LSB": 17778,
    "fw_file_version_MSB": 4641,
    "fw_filesize": 168318,
    "fw_image_type": 8449,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159697-TRADFRI-driver-hp-1.2.217.ota.ota.signed",
    "fw_file_version_LSB": 30066,
    "fw_file_version_MSB": 4641,
    "fw_filesize": 173246,
    "fw_image_type": 16898,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159698-TRADFRI-driver-lp-1.2.217.ota.ota.signed",
    "fw_file_version_LSB": 30066,
    "fw_file_version_MSB": 4641,
    "fw_filesize": 173246,
    "fw_image_type": 16897,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159699-2.1-TRADFRI-remote-control-1.2.223.ota.ota.signed",
    "fw_file_version_LSB": 13683,
    "fw_file_version_MSB": 4642,
    "fw_filesize": 159806,
    "fw_image_type": 4545,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159700-TRADFRI-motion-sensor-1.2.214.ota.ota.signed",
    "fw_file_version_LSB": 17778,
    "fw_file_version_MSB": 4641,
    "fw_filesize": 157822,
    "fw_image_type": 4548,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159701-TRADFRI-wireless-dimmer-1.2.248.ota.ota.signed",
    "fw_file_version_LSB": 34162,
    "fw_file_version_MSB": 4644,
    "fw_filesize": 172926,
    "fw_image_type": 4546,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/10032198-2.1-TRADFRI-gateway-1.8.25.p.elf.sig.ota.signed",
    "fw_filesize": 698748,
    "fw_hotfix_version": 25,
    "fw_major_version": 1,
    "fw_minor_version": 8,
    "fw_req_hotfix_version": 26,
    "fw_req_major_version": 9,
    "fw_req_minor_version": 9,
    "fw_type": 0,
    "fw_update_prio": 5,
    "fw_weblink_relnote": "https://ww8.ikea.com/ikeahomesmart/releasenotes/releasenotesltd.html"
  }
]

Nur Updates sind:

• 10005777-4.1-TRADFRI-control-outlet-2.0.022.ota.ota.signed
• 10005778-4.1-TRADFRI-onoff-shortcut-control-2.0.020.ota.ota.signed
• 10032198-2.1-TRADFRI-gateway-1.8.25.p.elf.sig.ota.signed
• 10038562-TRADFRI-sy5882-bulb-ws-2.0.022.ota.ota.signed
• 159699-2.1-TRADFRI-remote-control-1.2.223.ota.ota.signed

Also hauptsächlich auf die Outlets / Gateway konzentriert.

Heute zeigte eine meiner Farbbirnen genau das gleiche Problem. Musste es aus- und wieder einschalten, um wieder reagieren zu können.

Gibt es Neuigkeiten für wen, der deCONZ und die Firmware des Conbee aktualisiert?

Bis jetzt werden 1 oder 2 GU10s in 2-4 Wochen offline gehen. Ein bisschen sporadisch, aber Powercycling ist ärgerlich, weil ich an einigen Stellen keinen Powerswitch habe.

Wir haben gerade die Firmware auf 0x26330500 aktualisiert.

Leider ist heute einer meiner GU10s nicht verfügbar.
Verwenden von deCONZ 2.05.64 mit der Firmware 26330500 auf dem Conbee.

Ich denke, es wurde der Schluss gezogen, dass dies ein Glühbirnen-FW-Problem ist, da wir genau das gleiche Problem auf einer Philips HUE-Brücke sehen. Ich bemerkte in der Trådfri App, Abschnitt Versionshinweise, eine Erwähnung einer CT v2-Lampe. Vielleicht hängt es sogar mit der Glühbirne HW zusammen?

Ich hatte bisher keine Probleme mit 2.05.65.

Ebenso habe ich mich seit Wochen nicht mehr mit diesem Problem befasst

Ich hatte das gleiche mit der neuesten Version von deconz bis jetzt .. habe vor ein paar Tagen einige Lampen umgeschaltet. Ich musste nur eine dieser Lampen manuell aus- und wieder einschalten, damit sie wieder ansprach.

Einige GU10 und eine E27-Lampe sind vor einigen Tagen offline gegangen. Nur Power Cycling bringt sie wieder online.

Vielleicht relevant: Dies geschah während meines Urlaubs, als dort für einen Tag oder 10 keine Lichter schalteten.

Firmware 26330500 mit deCONZ 2.05.64

Wie wäre es mit diesem Problem für diejenigen, die sagten, sie hätten vor ein paar Wochen ein paar Wochen lang kein Problem gehabt?

Ich habe immer noch dieses Problem. Manchmal geht keiner von ihnen offline, und aus heiterem Himmel ist ein GU10 offline, und einige Tage später ein anderer.

Soweit ich sehen kann, ist für den Tradfri GU10 noch keine neue Firmware verfügbar.

Ich habe auch noch dieses Problem. Da für mich Gruppenbefehle die meiste Zeit immer noch funktionieren, auch wenn ich das Licht nicht als einzelnes Gerät steuern kann, verwende ich diese in meinen Wall-Switch-Skripten als Problemumgehung.

Gruppenbefehle funktionieren auch bei mir, aber nur wenige Male. Danach bleibt das Licht an oder aus und reagiert nicht mehr. Nicht einmal bei Verwendung eines gebundenen Farbton-Dimmers.

Gleiche für mich. Ich habe den Eindruck, dass sich das Problem verzögert, mehr als gelöst hat.
Ich habe auch das Problem mit der Verwendung von Gruppenbefehlen umgangen.

Ich bemerke übrigens, dass einige Lichter für dieses Problem viel anfälliger erscheinen. Erkennst du das?

@djwlindenaar Schwer zu sagen, aber ich denke, die Hälfte der 25+ GU10, die ich hatte, hatte dieses Problem noch nie und ich bin sicher, dass einige das Problem mehrmals hatten.

@ peer69 @djwlindenaar Funktioniert der Gruppenbefehl weiter? Heute ging ein GU10 offline und reagierte nicht einmal auf einen Gruppenbefehl (Gruppenbefehl von deCONZ und ein gebundener Farbton-Dimmer).

Der Gruppenbefehl funktioniert normalerweise weiter, aber ich erinnere mich an eine Gelegenheit, bei der ich ein Licht aus- und wieder einschalten musste. Ich erinnere mich auch an ein Mal, als es eine Weile nicht reagierte und ohne Aktion später wieder zu reagieren begann.

Früher oder später scheiterte auch ein Gruppenbefehl und musste das Licht aus- und wieder einschalten.

Was meinst du mit einer Weile? Ein paar Stunden oder ein paar Tage?

Nicht sicher, wahrscheinlich Stunden, vielleicht ein Tag. Ich habe es nur für einige Zeit vergessen, aber ich bemerkte, dass es beim nächsten Mal, wenn ich das Licht benutzte, wieder da sein würde.
Es bezog sich auf eine Regel, die durch Bewegung ausgelöst wurde, also ...

Ich habe ungefähr 2 Tage gewartet, als ein GU10 Anfang dieser Woche offline ging, aber es kam nicht zurück. Ein Powercycle wurde benötigt, der GU10 war überhaupt nicht warm.

Jetzt habe ich eine GU10-Leuchte, die offline ging, aber nach einem Aus- und Einschalten nicht wieder online geht. Auch das Drücken von 0 in VNC löst dieses Problem nicht.

Auch ein Gruppenbefehl oder ein gebundener Hue DImmer-Schalter kann das Licht nicht mehr ein- und ausschalten.

Ab letzter Nacht habe ich im Flur 4 Ikea-Lichter, die nach x Zeit von einem Timer (Home Assistant) ausgehen. Jetzt bleibt eines der 4 Lichter an und kann von Home Assistant / Deconz nicht ausgeschaltet werden. Laut Deconz ist es offline und seit 7 Stunden nicht mehr wieder dabei. Ich werde versuchen, mit dem Fahrrad zu fahren und zu sehen, ob das den Trick macht.

Licht funktioniert nicht: TRÅDFRI Birne E27 Opal 1000lm mit Version 1.2.214
Licht funktioniert: TRÅDFRI Birne E27 Opal 1000lm mit Version 1.2.214
Firmware: 26330500
Deconz: V2_05_69

Ich glaube, es gibt ein Hardwareproblem mit den Weißspektrumlampen Ikea Trafri GU10. Auch in meinem Setup (Ikea-Gateway über lokale API mit Home Assistant verbunden) geht mindestens die Hälfte meiner 17 Lampen alle paar Tage offline. Die einzige Lösung besteht darin, die Lampen aus- und wieder einzuschalten.

Dies könnte der Grund sein, warum Ikea eine neue Hardwareversion herausgebracht hat, auf der eine andere Version der Firmware ausgeführt wird (2. * statt 1. *).

Soweit ich weiß, gibt es kein neues Firmware-Update für die alte Version. Dies könnte ein Zeichen für Hardware sein.

Ich bin mir nicht sicher, wie hoch die Garantie ist, aber ich plane, einen Ersatz durch die neue Version zu beantragen.

Ich glaube, es gibt ein Hardwareproblem mit den Weißspektrumlampen Ikea Trafri GU10. Auch in meinem Setup (Ikea-Gateway über lokale API mit Home Assistant verbunden) geht mindestens die Hälfte meiner 17 Lampen alle paar Tage offline. Die einzige Lösung besteht darin, die Lampen aus- und wieder einzuschalten.

Dies könnte der Grund sein, warum Ikea eine neue Hardwareversion herausgebracht hat, auf der eine andere Version der Firmware ausgeführt wird (2. * statt 1. *).

Soweit ich weiß, gibt es kein neues Firmware-Update für die alte Version. Dies könnte ein Zeichen für Hardware sein.

Ich bin mir nicht sicher, wie hoch die Garantie ist, aber ich plane, einen Ersatz durch die neue Version zu beantragen.

Ich bin mir nicht sicher, ob es sich nur um einen Typ handelt, da ich das warmweiße GU10 verwende, nicht das weiße Spektrum.

Hatte heute das gleiche Problem mit zwei IKEA GU 10 WW. Power Cycling hat nicht geholfen. Es hat geholfen, deconz aus- und wieder einzuschalten. Vielleicht ein Problem mit dem Nachbartisch? Beide Lichter sind in einer Gruppe von zwei und werden immer als Gruppe gesteuert.

Was für ein Zufall, dass dies heutzutage bei mehreren Installationen passiert ... Oder passiert etwas anderes?

@ peer69

Welche Version der deCONZ- und Conbee-Firmware verwenden Sie?

Ich benutze:
deCONZ V2_05_66
Firmware 26330500

Gleiche Firmware hier. deCONZ Version 2.05.69.

Und ein anderes warmes Weiß des Tradfri GU10 verliert seine Verbindung.

Es gibt neuere Firmware-Dateien im Testzweig, aber ich weiß nicht, ob diese die Probleme beheben oder neue Probleme verursachen, die möglicherweise sogar Schaden anrichten.

http://fw.test.ota.homesmart.ikea.net/feed/version_info.json

10046695-1.1-TRADFRI-light-unified-w-2.1.022.ota.ota.signed 10038562-TRADFRI-sy5882-bulb-ws-2.0.022.ota.ota.signed 10038562-TRADFRI-sy5882-bulb-ws-2.0.023.ota.ota.signed 10035514-TRADFRI-bulb-ws-2.3.007.ota.ota.signed 10035534-TRADFRI-bulb-ws-gu10-2.3.007.ota.ota.signed 159695-TRADFRI-bulb-ws-1000lm-2.3.007.ota.ota.signed

@manup Diese sind für https://www.ikea.com/nl/nl/p/tradfri-led-lamp-gu10-400-lumen-draadloos-dimbaar-warm-wit-60420041/

Vielleicht kann das 10046695-1.1-TRADFRI-light-unified-w-2.1.022.ota.ota.signed für sie verwendet werden. Ich werde es an einem meiner dimmbaren IKEA E27-Lichter testen. Hoffentlich ist der schlimmste Fall ein Absturz, aber kein Brennen :)

Ich habe versucht, die Datei manuell zuzuweisen, aber die Glühbirne nimmt das Update nicht auf (startet nicht).

Nur ein "Ich auch". Mein gesamtes Haus ist Tradfri und nach dem heutigen Neustart meines Servers habe ich zum dritten Mal in ebenso vielen Tagen das gesamte Netzwerk verloren. Power-Cycling hat keinen Unterschied gemacht. Ich habe nur Tradfri in meinem Haus, also habe ich nichts Vergleichbares. Ich habe eine Mischung aus E27 Weiß, E27 Farbe und GU10. Die einzige Lösung, die ich gefunden habe, besteht darin, die Glühbirnen hart zurückzusetzen und das Ganze von vorne zu beginnen - leider ist dies nicht nachhaltig.

Conbee-Firmware: 264A0700
Leichte Firmware: 1.2.214

Gerne helfe ich bei der Diagnose, aber ich muss den größten Teil meines Hauses wieder an das Tradfri-Gateway zurückgeben, damit meine Familie das Licht ein- und ausschalten kann. Ich werde ein paar Lampen zur Verfügung stellen.

Ich habe gerade eine vielleicht interessante Ergänzung zu diesem Thema realisiert.

Einige Räume sind mit mehreren Tradfri GU10-Spots ausgestattet und die meisten Räume mit einem Farbton-Dimmer-Schalter, wobei eine direkte Bindung zu den GU10s in dem Raum hergestellt wird, der durch Hinzufügen zur Farbton-Dimmer-Schalter-Gruppe in der Phoscon-App erstellt wurde.

• Nur GU10s mit einer direkten Bindung mit einem Farbton-Dimmer-Schalter gehen ab und zu offline und benötigen einen Aus- und Wiedereinschalten, um wieder online zu gehen.
• GU10s ohne direkte Bindung mit einem Farbton-Dimmer-Schalter werden nicht offline geschaltet.

Scheint bei mir nicht der Fall zu sein. Bisher scheinen nur Hue Bulbs ziemlich belastbar zu sein. Alle Arten von IKEA-Geräten (GU10, E14, FLOALT Panel) und Osram-Geräten (Glühbirnen, Lichtleisten und Gartenmasten), die ich besitze, sind ausgefallen. Besonders Osram-Geräte fallen komplett aus, Power Cycle macht nichts. Sie müssen entfernt und repariert werden, was für diese Geräte schmerzhaft ist.

Ich habe einige Tage darüber nachgedacht, alle meine ZigBee-Geräte durch Geräte für meine viel zu teure KNX-Installation zu ersetzen, nachdem mehrere Geräte ausgefallen waren und die Migration auf einen Conbee II-Stick wahrscheinlich auch aufgrund einer etwas beschädigten zll-db fehlgeschlagen ist. Ich habe dann den radikalen Ansatz gewählt, um alles von Grund auf neu einzurichten. Ich habe das Gateway zurückgesetzt und alle Geräte repariert. Bei IKEA-Geräten war dies viel einfacher als früher. In der Vergangenheit musste ich sie in die Nähe des Gateways bringen, sie mehrmals zurücksetzen und sie über einen Touchlink reagieren lassen - diesmal nichts davon. Ich habe gerade die Lampen zurückgesetzt und sie haben sich ohne Probleme gepaart. Trotzdem war es ein Schmerz, dies für 70 Geräte zu tun, und einige Xiaomi-Sensoren machten es etwas schwieriger als das Ikea-Zeug. Aber ich denke schon, dass ich jetzt ein stabileres Netzwerk haben könnte. Dennoch ist nichts gescheitert, aber ich werde Ihnen sagen, ob dies der Fall ist.

Es ist eine Weile her, seit ich meine Raspbee aktualisiert habe. Meine alte Version hatte Probleme beim Ablesen der Lichttemperatur. Daher habe ich mich entschlossen, auf die neueste Firmware und deCONZ zu aktualisieren. Habe nur 2 Lichter (OSRAM 73674). 1 Licht (wahrscheinlich zufällig) verliert nach einigen Minuten die Verbindung mit dem neuesten deCONZ und ich muss manuell aus- und wieder einschalten. Die einzige Version, die ich finden konnte, die Temperaturen ablesen konnte und keine Lichter verlor, war deconz-2.04.40-qt5.deb, die super alt ist, aber für meine grundlegende Verwendung funktioniert.

Passiert in letzter Zeit auch für mich mit IKEA GU10 Single Color viel mehr. Eine Art Schmerz im Hintern. Allerdings werden die Knoten für mich nicht rot, sondern nur ausgegraut. Sie reagieren auf das Drücken einer Remote-Taste, jedoch nicht über Phoscon oder HA.

Aktualisiert deCONZ den Lichtstatus immer noch, wenn Sie sie von der Fernbedienung aus steuern?

Dies geschieht normalerweise, wenn deCONZ den Weg zur Lampe verloren hat. Die Lampe befindet sich noch im Netzwerk, kann das Gateway erreichen und empfängt Sendungen. Das Gateway kann das Licht jedoch nicht über Unicast erreichen. Um dieses Problem zu umgehen, können Sie anstelle von /lights /groups Befehle verwenden, sodass deCONZ stattdessen Broadcasts sendet.

Ich habe immer noch gelegentlich (~ einmal pro Woche) das gleiche Problem mit meinem Xiaomi Curtain Controller (der ein ZigBee-Router ist). Die Geräteankündigung nach dem Aus- und Einschalten des Geräts bewirkt, dass deCONZ die Route neu lernt.

Diese Routing-Probleme wurden mit der Unterstützung der von Trådfri-Leuchten verwendeten Routing-Erkennung eingeführt, sodass 2.04.40 ungefähr richtig klingt.

@ebaauw Wenn ein Licht nicht verfügbar ist, funktionieren Gruppenbefehle für mich, aber nur für eine begrenzte Zeit. Danach bleibt das Licht an oder aus und reagiert nicht mehr auf einen Gruppenbefehl. Verwenden eines gebundenen Farbton-Dimmer-Schalters (Bindung, die durch Hinzufügen der Lichter zur standardmäßig erstellten Gruppe erstellt wird, wenn ein Farbton-Dimmer-Schalter in der Phoscon-App gekoppelt ist).

Aktualisiert deCONZ den Lichtstatus immer noch, wenn Sie sie von der Fernbedienung aus steuern?

Dies geschieht normalerweise, wenn deCONZ den Weg zur Lampe verloren hat. Die Lampe befindet sich noch im Netzwerk, kann das Gateway erreichen und empfängt Sendungen. Das Gateway kann das Licht jedoch nicht über Unicast erreichen. Um dieses Problem zu umgehen, können Sie anstelle von /lights /groups Befehle verwenden, sodass deCONZ stattdessen Broadcasts sendet.

Ich werde diese Vorschläge beim nächsten Mal überprüfen. Aber ja, sie kommen normalerweise zurück. Ich habe den Strom für ein paar Minuten abgeschaltet. Übrigens benutze ich die IKEA "Hockey Puck" Fernbedienung.

Ich habe immer noch gelegentlich (~ einmal pro Woche) das gleiche Problem mit meinem Xiaomi Curtain Controller (der ein ZigBee-Router ist). Die Geräteankündigung nach dem Aus- und Einschalten des Geräts bewirkt, dass deCONZ die Route neu lernt.

Diese Routing-Probleme wurden mit der Unterstützung der von Trådfri-Leuchten verwendeten Routing-Erkennung eingeführt, sodass 2.04.40 ungefähr richtig klingt.

Hmm, ich weiß nicht, dass es so lange so schlimm für mich war. Ich habe es ständig auf dem neuesten Stand gehalten.

Hmm, ich weiß nicht, dass es so lange so schlimm für mich war.

Es ist ein zeitweiliges Problem. Ich konnte es nicht nach Belieben reproduzieren, siehe # 849. Tatsächlich basieren alle meine Regeln zur Steuerung von Lichtern auf /groups Aktionen, sodass ich das Problem noch nie bemerkt habe, bis ich den Vorhang-Controller bekam.

Wenn ein Licht nicht verfügbar ist, funktionieren Gruppenbefehle für mich, jedoch nur für eine begrenzte Zeit. Danach bleibt das Licht an oder aus und reagiert nicht mehr auf einen Gruppenbefehl.

Ich würde die Theorie aufstellen, dass das Licht beschließt, das Netzwerk zu verlassen, wenn es über einen längeren Zeitraum keine ACKs vom Gateway für seine Attributberichte empfängt.

Ich würde die Theorie aufstellen, dass das Licht beschließt, das Netzwerk zu verlassen, wenn es über einen längeren Zeitraum keine ACKs vom Gateway für seine Attributberichte empfängt.

Für mich passiert dies auch bei eingeschalteten Lichtern oder nur wenige Minuten / Stunden zuvor.

Wie oben in einigen Antworten angegeben, sind die meisten meiner GU10-Leuchten an einen Farbton-Dimmer-Schalter gebunden (3-8 in einem Raum mit einem eigenen Farbton-Dimmer-Schalter). Einige sind es nicht, und diese sind seit Monaten online. Keiner von ihnen war nicht verfügbar. Zufall oder nicht .. Was denkst du über dieses @ebaauw?

Die meisten meiner GU10-Leuchten sind an einen Farbton-Dimmer gebunden

Das scheint unwahrscheinlich. Haben Sie im _Bind Dropbox_-Bereich in der deCONZ-GUI eine Bindung vom Dimmer zum Licht erstellt?

Beachten Sie, dass "Bindung" in ZigBee-Begriffen bedeutet: Erstellen eines Eintrags in der Bindungstabelle des Geräts an die ZigBee-Adresse, an die Befehle vom gebundenen Cluster gesendet werden sollen. Ich denke, die (client!) _OnOff_- und _Level Control_-Cluster Ihres Dimmerschalters sind an eine Gruppe gebunden (durch das deCONZ REST API-Plugin). Diese Gruppe ist in der ZHASwitch-Ressource unter config.group . Als nächstes wurde das Licht zu dieser Gruppe hinzugefügt. ZigBee-Gruppen ähneln eher Multicast-Adressen, daher ist es wahrscheinlich korrekter zu sagen, dass das Licht Nachrichten an diese Gruppe abonniert hat.

Theoretisch könnte die Light-Firmware einen Fehler aufweisen, der dazu führt, dass sie hängen bleibt, während Befehle verarbeitet werden, die über eine Gruppe empfangen werden. Ich denke jedoch nicht, dass dies wahrscheinlich ist. Ich würde mir ansehen, wie nahe (wie viele Sprünge über das ZigBee-Netzwerk) die Lichter an RaspBee / ConBee liegen und / oder ob alle Lichter dieselbe Hardware- und Firmware-Version haben. IKEA scheint neue ZigBee 3.0 (ZHA) -Versionen aller seiner Geräte herauszubringen.

Die meisten meiner GU10-Leuchten sind an einen Farbton-Dimmer gebunden

Das scheint unwahrscheinlich. Haben Sie im _Bind Dropbox_-Bereich in der deCONZ-GUI eine Bindung vom Dimmer zum Licht erstellt?

Beachten Sie, dass "Bindung" in ZigBee-Begriffen bedeutet: Erstellen eines Eintrags in der Bindungstabelle des Geräts an die ZigBee-Adresse, an die Befehle vom gebundenen Cluster gesendet werden sollen. Ich denke, die (client!) _OnOff_- und _Level Control_-Cluster Ihres Dimmerschalters sind an eine Gruppe gebunden (durch das deCONZ REST API-Plugin). Diese Gruppe ist in der ZHASwitch-Ressource unter config.group . Als nächstes wurde das Licht zu dieser Gruppe hinzugefügt. ZigBee-Gruppen ähneln eher Multicast-Adressen, daher ist es wahrscheinlich korrekter zu sagen, dass das Licht Nachrichten an diese Gruppe abonniert hat.

Nein, ich habe keine Bindung im Bereich de _Bind Dropbox_ in der deCONZ-GUI erstellt.

Meinen Sie, dass das Hinzufügen von Licht zu diesen Gruppen in der Phoscon-App keine Bindung zwischen Fernbedienung und Licht (en) herstellt? Ich habe dies angenommen, da das Umschalten der hinzugefügten Lichter mit dem entsprechenden Farbton-Dimmer auch möglich ist, wenn mein deCONZ-Docker-Container oder der gesamte NUC offline ist.

Ok, ich habe jetzt eine nicht reagierende Glühbirne. Es wurde in bth deCONZ und Phoscon ausgegraut.

Es reagierte auf Remote-Befehle und auch darauf, wann ich den Schieberegler in Phoscon im "Gruppen" -Modus bewegte.

Aktualisiert deCONZ den Lichtstatus immer noch, wenn Sie sie von der Fernbedienung aus steuern?

Nicht zuerst, da es ausgegraut war.

Ich habe es dann mit "Zurücksetzen des ausgewählten Knotens" in deCONZ versucht, und dann war es für einige Minuten nicht mehr ausgegraut, obwohl es in deCONZ kein Cluster-Optionsfeld mehr gab.

Reagierte immer noch nur auf Remote- und Gruppenbefehle, aber jetzt wurde der Lichtstatus aktualisiert.

Nach einer Weile wurde es in Phoscon wieder grau.

Ich habe dann versucht, den Strom für ein paar Minuten zu unterbrechen. Hat nicht geholfen.

Eine interessante Situation ereignete sich heute Abend:

Eine der warmweißen GU10-Leuchten von Tradfri ist seit einigen Stunden wieder offline. Der Hue Dimmer-Schalter, der an 8 GU10s gebunden ist, einschließlich desjenigen, der jetzt offline ist, schaltet den laut deconz Offline-GU10 ein / aus. Seltsam genug, nur dieser eine.
Die anderen GU10s reagieren nicht auf den gebundenen Farbton-Dimmer-Schalter.

Durch Umschalten der Gruppe mit der Rest-API werden alle Anzeigen einschließlich der Offline-GU10 ein- und ausgeschaltet.

Wenn ein GU10 zuvor offline geschaltet wurde, schaltet der gebundene Farbton-Dimmer alle Lichter in der Gruppe ein / aus, einschließlich des Off-Deconz-Offline-GU10 (früher oder später hört der laut Deconz auch Offline-GU10 auch nicht mehr auf Gruppenbefehle entweder).

Könnte das nützlich sein?

\ Edit: Der 'Name' dieses Offline-GU10 in deCONZ via VNC ist leer.

Wenn Sie dies erneut ausfüllen, wird es nicht festgelegt (dies wurde hier normalerweise in der Phoscon-App nie getan):

Auch noch gelb:

Durch Drücken von '0' oder 'Ausgewählten Knoten zurücksetzen' wird das GU10 nicht wieder online geschaltet.

Bearbeiten 2 : Ungefähr 24 Stunden nachdem das GU10 offline gegangen ist, reagiert das GU10 nicht mehr wie zuvor beschrieben auf den gebundenen Farbton-Dimmer-Schalter. Keines der GU10-Lichter in der Gruppe reagiert jetzt nicht. Der Knoten in der deCONZ-GUI ist immer noch gelb, aber der Name ist grau.
Nach dem Einschalten des Offline-GU10-Lichts reagieren alle 8 Lichter in der Gruppe, einschließlich des Offline-Lichts, erneut auf den gebundenen Farbton-Dimmer-Schalter.

@manup Dieses Verhalten / diese Situation ist ganz anders als zuvor. Vielleicht kann dies helfen, die Ursache zu finden?

Ich habe gerade eine vielleicht interessante Ergänzung zu diesem Thema realisiert.

Einige Räume sind mit mehreren Tradfri GU10-Spots ausgestattet und die meisten Räume mit einem Farbton-Dimmer-Schalter, wobei eine direkte Bindung zu den GU10s in dem Raum hergestellt wird, der durch Hinzufügen zur Farbton-Dimmer-Schalter-Gruppe in der Phoscon-App erstellt wurde.

• Nur GU10s mit einer direkten Bindung mit einem Farbton-Dimmer-Schalter gehen ab und zu offline und benötigen einen Aus- und Wiedereinschalten, um wieder online zu gehen.
• GU10s ohne direkte Bindung mit einem Farbton-Dimmer-Schalter werden nicht offline geschaltet.

Leider ist einer meiner Tradfri GU10 Warmwhite ohne gebundenen Farbton-Dimmer seit gestern offline.

Ich frage mich immer noch, warum ein paar GU10-Spots (dasselbe Warmweiß) niemals offline sind.
\ Edit : Auch ein GU10, der monatelang online war, ist seit gestern offline.

Habe letztes Wochenende einen Tradfri Hub gekauft und alle GU10-Spots eines Raums damit gepaart. Mal sehen, was in den kommenden Wochen passiert.

Zufällige Lichter in meinem System reagierten nicht mehr, nachdem ich meinem System vier IKEA-Ein- / Ausschalter hinzugefügt hatte (für die Weihnachtsfensterlichter) ... Die Steckdosen sind in meinem ganzen Haus verteilt. Mindestens eines meiner Lichter in meinem System muss pro Tag aus- und wieder eingeschaltet werden.

Kann ich irgendeine Art von Protokollen oder Informationen bereitstellen, um die Fehlerbehebung zu vereinfachen?

@tubalainen Was meinst du mit nicht reagierend? Werden sie von selbst ansprechbar oder brauchen sie ein Powercycle?

@tubalainen Was meinst du mit nicht reagierend? Werden sie von selbst ansprechbar oder brauchen sie ein Powercycle?

Sie werden als "online" aufgeführt (nicht ausgegraut) und sind gemäß meinem Bild Teil des Netzes, aber wenn sie in Home Assistant (oder über Phoscon) umgeschaltet werden, passiert nichts. Um sie wieder zum Laufen zu bringen, muss ich mit dem Fahrrad fahren.

Gibt es hier Fortschritte? Es wird ein bisschen lächerlich, wenn meine GU10-Lichter grau werden :(

Ich glaube, ich habe jemanden gesehen, der den Vorhangregler oder den Ein / Aus-Schalter erwähnt hat. Mir fällt tatsächlich auf, dass sich die Probleme um die Zeit, als ich die FYRTUR-Jalousien bekam, erheblich verschlimmerten. Dies war auch der erste Ikea-Button, den ich dem Netzwerk hinzugefügt habe ... Ich weiß nicht ...

Ich habe hier keine Tradfri-Ein / Aus-Wandschalter oder IKEA-Vorhänge und habe das Problem.

Ich hatte dieses Problem im Sommer. Meine GU10s würden die ganze Zeit ausfallen. Ich habe alle meine GU10s auf die neueste "Test" -Software aktualisiert und laufe seit fast zwei Monaten ohne Probleme.

Letztes Wochenende habe ich ein paar neue E27-Lampen hinzugefügt und jetzt fallen einige meiner GU10s immer wieder aus.

Ich hatte dieses Problem im Sommer. Meine GU10s würden die ganze Zeit ausfallen. Ich habe alle meine GU10s auf die neueste "Test" -Software aktualisiert und laufe seit fast zwei Monaten ohne Probleme.

Letztes Wochenende habe ich ein paar neue E27-Lampen hinzugefügt und jetzt fallen einige meiner GU10s immer wieder aus.

Welche GU10-Lampen haben Sie und welche Firmware haben Sie installiert?

Habe letztes Wochenende einen Tradfri Hub gekauft und alle GU10-Spots eines Raums damit gepaart. Mal sehen, was in den kommenden Wochen passiert.

Als ich das Tradfri-Gateway benutzte, hatte ich fast jeden Tag nicht reagierende Glühbirnen (Tradfri GU10-Weißspektrum, erste Generation). Ich wechselte zur Philips Hue-Brücke und das Problem schien behoben zu sein, aber nach 2 Wochen reagierte eine Glühbirne nicht mehr (wie üblich löste ein Aus- und Einschalten das Problem).

Ich bin mir nicht sicher, warum und wie die Hue-Brücke mit den Tradfri-Glühbirnen besser funktioniert, aber es scheint mir, dass das eigentliche Problem bei den Glühbirnen liegt.

Ich besitze kein einziges GU10 und habe immer noch das Problem.

Bitte sagen Sie mir, wie ich Ihnen bei Protokollen usw. behilflich sein kann, um dies zu lösen.
Es scheint leicht (meine Vermutung hier), dass einige Knoten "einschlafen" und nicht beim ersten Versuch aufwachen, sie zu wecken?

Ist dies nur ein Problem, wenn sich mehrere Knotensprünge im Netz befinden? Für mich ist es ziemlich konsequent, wenn es mehr als einen Sprung zum Conbee gibt. Wieder nur ein Gefühl. Nicht bestätigt.

Ich habe 8 GU-10 ungefähr 18 Monate alt. Einer von ihnen ist in dieser Zeit einmal grau geworden. Sie befinden sich alle im selben Raum wie der Conbee-Stick. Ich habe einige 3 Jahre alte 980lm Glühbirnen. Derjenige, der am weitesten vom GW-Springen über eine Gu 10 entfernt ist, wird vielleicht alle zwei Wochen grau.
@ Tubalainen könnte auf etwas sein.

Neben dem grau werdenden habe ich einen Osram, der noch nie schief gelaufen ist.

Ja, @tubalainen könnte einen Hinweis haben. Ich habe meine grauen GU10s tatsächlich in eine Lampenfassung an einem Kabel gesteckt, das ich beim Hinzufügen neuer Lichter verwende, und wenn sie sich darin befinden, sind sie oft wieder zum Leben erweckt worden. Aber wenn ich sie wieder an ihren Platz zurückbringe, sind sie wieder draußen. Es ist nicht 100% konsistent, dass sie zurückkommen, aber dennoch eine Komplizen-Sache sein könnten.

Hier ist ein weiterer möglicher Hinweis. Ich hatte noch nie Lampen, die grau wurden (in über einem Jahr Betriebszeit mit 8 IKEA-Lampen), aber dann habe ich das Home Assistant-Dekonz-Plugin von 3,8 auf 3,9 aktualisiert und in zwei Tagen waren zwei GU10 grau hat ein Backup der 3.8-Version des Plugins wiederhergestellt und es gab seitdem keine Probleme mehr. Das Seltsame ist, dass das Plugin 3.8 und 3.9 dieselbe Deconz-Version verwendet (wenn das Änderungsprotokoll vollständig ist). Doch selbst in Phoscon waren die Lampen nicht zugänglich. Das ist alles ziemlich seltsam, aber ich gehe davon aus, dass die 3.9-Version des Plugins eine Art Dekonzierungsanforderung stellt, die die IKEA-Lampen instabil macht.

Ich benutze kein HA und leide immer noch unter dem Problem. Ich habe mir ein ne GU10 gekauft und ersetze jetzt jede Lampe, die mehr als einmal grau wird. Jede Lampe, die ich ersetzt habe, wurde nicht wieder grau. Könnte ein Hardwareproblem sein, vielleicht auch nicht, aber es scheint, als hätten wir bald keine Lösung mehr.

Ich habe ähnliche Probleme. Einige der Lichtknoten reagieren nicht auf Befehle und werden grau. Das Seltsame ist, dass, wenn ich Gruppenbefehle sende, jedes Mal derselbe Lichtknoten perfekt reagiert.

Ich habe ähnliche Probleme. Einige der Lichtknoten reagieren nicht auf Befehle und werden grau. Das Seltsame ist, dass, wenn ich Gruppenbefehle sende, jedes Mal derselbe Lichtknoten perfekt reagiert.

Funktioniert ein Gruppenbefehl nach ein paar Tagen / mehr als einer Woche weiter?
In meinem Fall: Früher oder später hört das Licht auch auf, Gruppenbefehle zu hören.

Ich habe ähnliche Probleme. Einige der Lichtknoten reagieren nicht auf Befehle und werden grau. Das Seltsame ist, dass, wenn ich Gruppenbefehle sende, jedes Mal derselbe Lichtknoten perfekt reagiert.

Funktioniert ein Gruppenbefehl nach ein paar Tagen / mehr als einer Woche weiter?
In meinem Fall: Früher oder später hört das Licht auch auf, Gruppenbefehle zu hören.

Ja, es scheint auch im Laufe der Zeit gut zu funktionieren. Aber ich habe eine Theorie darüber, was falsch ist. Wenn Lichtknoten durch die TRADFRI-Lampe E27 WS opal 1000lm geleitet werden, treten die Probleme auf. Also habe ich gestern die beiden ausgeschaltet, die ich in meinem Netzwerk hatte. Seitdem scheint alles perfekt zu funktionieren.

Ich habe TRADFRI Birne GU10 WS 400lm, TRADFRI Birne E14 CWS Opal 600lm und TRÅDFRI Birne E27 CWS Opal 600lm. Sie scheinen keine Probleme zu verursachen.

Es könnte mit der älteren Trådfri-Firmware zusammenhängen. Neuere Leuchten werden mit neuerer Firmware geliefert, aber ich glaube nicht, dass IKEA eine aktualisierte Firmware für alle Leuchten der ersten Generation veröffentlicht hat. Ich habe keine Trådfri GU10-Spots, aber die CWS-Lampe hat ein Firmware-Update erhalten. Meine 1000lm dimmbare Glühbirne tat es nicht; Ich bin mir nicht sicher über die weiße Spektrallampe.

Es könnte mit der älteren Trådfri-Firmware zusammenhängen. Neuere Leuchten werden mit neuerer Firmware geliefert, aber ich glaube nicht, dass IKEA eine aktualisierte Firmware für alle Leuchten der ersten Generation veröffentlicht hat. Ich habe keine Trådfri GU10-Spots, aber die CWS-Lampe hat ein Firmware-Update erhalten. Meine 1000lm dimmbare Glühbirne tat es nicht; Ich bin mir nicht sicher über die weiße Spektrallampe.

Meine TRADFRI-Lampe GU10 WS 400lm hat dieselbe Firmware, 2.0.022. Sie scheinen (noch) keine Probleme zu verursachen :))

Es könnte mit der älteren Trådfri-Firmware zusammenhängen. Neuere Leuchten werden mit neuerer Firmware geliefert, aber ich glaube nicht, dass IKEA eine aktualisierte Firmware für alle Leuchten der ersten Generation veröffentlicht hat. Ich habe keine Trådfri GU10-Spots, aber die CWS-Lampe hat ein Firmware-Update erhalten. Meine 1000lm dimmbare Glühbirne tat es nicht; Ich bin mir nicht sicher über die weiße Spektrallampe.

Genau. Die erste Version von Ikea-Lampen (auf 1. * Firmware) hatte einen Software- / Hardwarefehler, der die zweiten Iterationen (auf 2. *) nicht beeinflusst.

Leider scheint Ikea die Originalversion nicht mehr zu unterstützen und kein Firmware-Update mehr bereitzustellen. Gleichzeitig ist es nicht möglich, die Glühbirnen zurückzugeben und gegen die neuen auszutauschen (ich habe es in Großbritannien versucht).

Es könnte mit der älteren Trådfri-Firmware zusammenhängen. Neuere Leuchten werden mit neuerer Firmware geliefert, aber ich glaube nicht, dass IKEA eine aktualisierte Firmware für alle Leuchten der ersten Generation veröffentlicht hat. Ich habe keine Trådfri GU10-Spots, aber die CWS-Lampe hat ein Firmware-Update erhalten. Meine 1000lm dimmbare Glühbirne tat es nicht; Ich bin mir nicht sicher über die weiße Spektrallampe.

Genau. Die erste Version von Ikea-Lampen (auf 1. * Firmware) hatte einen Software- / Hardwarefehler, der die zweiten Iterationen (auf 2. *) nicht beeinflusst.

Leider scheint Ikea die Originalversion nicht mehr zu unterstützen und kein Firmware-Update mehr bereitzustellen. Gleichzeitig ist es nicht möglich, die Glühbirnen zurückzugeben und gegen die neuen auszutauschen (ich habe es in Großbritannien versucht).

Ich habe cws Glühbirnen am 1.3.009. Sie scheinen keine Probleme zu verursachen.

Aktualisieren:

Es scheint, als würden auch andere IKEA-Lampen Probleme verursachen.

Hier sind meine IKEA Glühbirnen. Bisher verursacht nur die TRADFRI-Glühlampe E27 WS opal 1000lm Probleme. Sie sind jetzt getrennt und die Dinge scheinen zu funktionieren. Aber ich poste ein Update, wenn ich neue Fehler bekomme.

Ich scheine keine 2.x-Geräte zu besitzen.
Einige GU10 funktionieren einwandfrei, andere nicht. Ich fing an, die fehlerhaften durch "neue" zu ersetzen, die ich einige Monate später gekauft hatte. Sie scheinen dieselbe Firmware auszuführen, obwohl auf dem Sockel eine Nummer "1808-S" aufgedruckt ist, während die "neueren" "1729-S" haben.
Ich habe bisher 3 Lampen ausgetauscht und 2 Wochen lang sind keine neuen Probleme aufgetreten. Ich hatte nicht nur ein Problem mit GU10, sondern auch mit einem FLOALT-Panel, das ich nicht ersetzt habe.

Ich scheine keine 2.x-Geräte zu besitzen. Einige GU10 funktionieren einwandfrei, andere nicht. Ich fing an, die fehlerhaften durch "neue" zu ersetzen, die ich einige Monate später gekauft hatte. Sie scheinen dieselbe Firmware auszuführen, obwohl auf dem Sockel eine Nummer "1808-S" aufgedruckt ist, während die "neueren" "1729-S" haben. Ich habe bisher 3 Lampen ausgetauscht und 2 Wochen lang sind keine neuen Probleme aufgetreten. Ich hatte nicht nur ein Problem mit GU10, sondern auch mit einem FLOALT-Panel, das ich nicht ersetzt habe.

Interessant! Ich werde einen Blick auf meine Glühbirnen werfen, um festzustellen, ob eine Korrelation besteht.

Es scheint, als wäre einer meiner Knoten wieder von dem Problem betroffen. Ich habe noch einige IKEA-Knoten im Netzwerk, daher werde ich einige Tests durchführen, um festzustellen, ob ich einige Schlussfolgerungen ziehen kann.

Ich habe TRADFRI Birne GU10 WS 400lm, TRADFRI Birne E14 CWS Opal 600lm und TRÅDFRI Birne E27 CWS Opal 600lm. Sie scheinen keine Probleme zu verursachen.

Es scheint, als ob nach einer Weile des Netzes sogar die anderen IKEA-Geräte Probleme verursachen und die Knoten nicht mehr auf Befehle reagieren. Sogar andere IKEA-Knoten können betroffen sein. Mir scheint, dass die Probleme auftreten, wenn Knoten über einen IKEA-Knoten geleitet werden.

Sind Aktivitäten geplant, um dies zu prüfen? Ich werde alle meine IKEA-Geräte auf mein Farbton-Gateway verschieben, während dies behoben ist.

Knoten stoppen, um auf Befehle zu antworten.

Sind Sie sicher, dass dies der Fall ist? Haben Sie dies durch das Schnüffeln des ZigBee-Verkehrs bestätigt? Reagieren die anderen Knoten nicht mehr auf drahtlose Switches, die Lichter steuern, ohne das Gateway zu durchlaufen? Reagieren sie nicht mehr auf Gruppenbefehle?
Nach meiner Erfahrung besteht das Problem darin, dass das Gateway die Route zu den anderen Knoten nicht mehr kennt, sodass Unicast-Befehle vom Gateway niemals die anderen Knoten erreichen. Die Knoten selbst reagieren einwandfrei, sie erhalten einfach nichts, worauf sie antworten können.

Sogar andere IKEA-Knoten können betroffen sein. Mir scheint, dass die Probleme auftreten, wenn Knoten über einen IKEA-Knoten geleitet werden.

Der (nicht?) Routing-IKEA-Knoten unterbricht irgendwie die Route von und / oder die Routenerkennung durch das Gateway zu den anderen Knoten.

Sind Aktivitäten geplant, um dies zu prüfen?

Sie müssen sich an den dresden elektronik Support wenden. Das Routing wird von der RaspBee / ConBee-Firmware (und dem deCONZ-Kernprogramm?) Verwaltet. Im REST-API-Plugin können wir nichts dagegen tun.

Habe letztes Wochenende einen Tradfri Hub gekauft und alle GU10-Spots eines Raums damit gepaart. Mal sehen, was in den kommenden Wochen passiert.

Vielleicht ist es etwas früh zu sagen, aber vor 29 Tagen habe ich alle Tradfri GU10s (8x warmweiß - 1.2.214) von einem Raum in einen Tradfri Hub verschoben, und keiner von ihnen reagierte bis jetzt nicht mehr.

Vielleicht ist es etwas früh zu sagen, aber vor 29 Tagen habe ich alle Tradfri GU10s (8x warmweiß - 1.2.214) von einem Raum in einen Tradfri Hub verschoben, und keiner von ihnen reagierte bis jetzt nicht mehr.

Ich würde es erwarten. Das Problem wird weniger durch Geräte eines einzelnen Herstellers verursacht, als vielmehr durch die Interaktion zwischen Geräten verschiedener Hersteller, die den ZigBee-Standard unterschiedlich interpretieren. Aus diesem Grund unterstützen die meisten Hubs / Gateways / Bridges nur ihre eigenen Geräte. Ein interessanteres Experiment wäre, die Trådfri-Spots mit der Hue-Brücke oder dem OSRAM-Gateway zu verbinden.

Außerdem führen acht Lichter in einem einzelnen Raum wahrscheinlich zu einer direkten Verbindung zwischen dem Hub und jedem Licht: alle Single-Hop-Verbindungen. Routing-Probleme treten nur bei größeren Netzwerken mit mehr Geräten als Einträgen in einer Nachbartabelle auf (normalerweise um die 20). und / oder mit Geräten, die sich physisch außerhalb der Reichweite des Hubs befinden.

Knoten stoppen, um auf Befehle zu antworten.

Sind Sie sicher, dass dies der Fall ist? Haben Sie dies durch das Schnüffeln des ZigBee-Verkehrs bestätigt? Reagieren die anderen Knoten nicht mehr auf drahtlose Switches, die Lichter steuern, ohne das Gateway zu durchlaufen? Reagieren sie nicht mehr auf Gruppenbefehle?
Nach meiner Erfahrung besteht das Problem darin, dass das Gateway die Route zu den anderen Knoten nicht mehr kennt, sodass Unicast-Befehle vom Gateway niemals die anderen Knoten erreichen. Die Knoten selbst reagieren einwandfrei, sie erhalten einfach nichts, worauf sie antworten können.

Ich habe keine Erfahrung oder Ausrüstung, um den Verkehr zu schnüffeln. Sie haben wahrscheinlich Recht, wie sich das Problem verhält. Meine Knoten reagieren ständig auf Gruppenbefehle. Das Problem ist (wenn ich es bekomme), dass die Unicast-Befehle niemals ihr Ziel erreichen.

Solange ich nur Gruppenbefehle sende, scheint alles ganz gut zu funktionieren.

Sogar andere IKEA-Knoten können betroffen sein. Mir scheint, dass die Probleme auftreten, wenn Knoten über einen IKEA-Knoten geleitet werden.

Der (nicht?) Routing-IKEA-Knoten unterbricht irgendwie die Route von und / oder die Routenerkennung durch das Gateway zu den anderen Knoten.

Sind Aktivitäten geplant, um dies zu prüfen?

Sie müssen sich an den dresden elektronik Support wenden. Das Routing wird von der RaspBee / ConBee-Firmware (und dem deCONZ-Kernprogramm?) Verwaltet. Im REST-API-Plugin können wir nichts dagegen tun.

Ja, ich habe ihnen eine E-Mail gesendet, aber außer einer Checkliste keine Antwort erhalten.

Vielleicht ist es etwas früh zu sagen, aber vor 29 Tagen habe ich alle Tradfri GU10s (8x warmweiß - 1.2.214) von einem Raum in einen Tradfri Hub verschoben, und keiner von ihnen reagierte bis jetzt nicht mehr.

Ich würde es erwarten. Das Problem wird weniger durch Geräte eines einzelnen Herstellers verursacht, als vielmehr durch die Interaktion zwischen Geräten verschiedener Hersteller, die den ZigBee-Standard unterschiedlich interpretieren. Aus diesem Grund unterstützen die meisten Hubs / Gateways / Bridges nur ihre eigenen Geräte. Ein interessanteres Experiment wäre, die Trådfri-Spots mit der Hue-Brücke oder dem OSRAM-Gateway zu verbinden.

Außerdem führen acht Lichter in einem einzelnen Raum wahrscheinlich zu einer direkten Verbindung zwischen dem Hub und jedem Licht: alle Single-Hop-Verbindungen. Routing-Probleme treten nur bei größeren Netzwerken mit mehr Geräten als Einträgen in einer Nachbartabelle auf (normalerweise um die 20). und / oder mit Geräten, die sich physisch außerhalb der Reichweite des Hubs befinden.

Ich habe dies getan, um sicherzustellen, dass es nicht mit der Firmware 1.2.214 des alten GU10 zusammenhängt, die hier häufig als mögliche Ursache genannt wird (und möglicher Grund, eine neue Version des GU10 zu erstellen).
Möglicherweise in Verbindung mit über einen anderen Router verbunden.

Ich werde in Betracht ziehen, meine anderen GU10-Leuchten (ebenfalls warmweiß 1.2.214) ebenfalls mit dem Tradfri-Hub zu koppeln (auch die im 2./3. Stock).

Gibt es hier Fortschritte? Es wird ein bisschen lächerlich, wenn meine GU10-Lichter grau werden :(

Ich glaube, ich habe jemanden gesehen, der den Vorhangregler oder den Ein / Aus-Schalter erwähnt hat. Mir fällt tatsächlich auf, dass sich die Probleme um die Zeit, als ich die FYRTUR-Jalousien bekam, erheblich verschlimmerten. Dies war auch der erste Ikea-Button, den ich dem Netzwerk hinzugefügt habe ... Ich weiß nicht ...

Ich habe seit meinem letzten Beitrag keinen Fyrtur-Ein / Aus-Schalter mehr im Netzwerk und in dieser Zeit keine Aussetzer mehr. Könnte ein Zufall sein ...?

Gibt es hier Fortschritte? Es wird ein bisschen lächerlich, wenn meine GU10-Lichter grau werden :(
Ich glaube, ich habe jemanden gesehen, der den Vorhangregler oder den Ein / Aus-Schalter erwähnt hat. Mir fällt tatsächlich auf, dass sich die Probleme um die Zeit, als ich die FYRTUR-Jalousien bekam, erheblich verschlimmerten. Dies war auch der erste Ikea-Button, den ich dem Netzwerk hinzugefügt habe ... Ich weiß nicht ...

Ich habe seit meinem letzten Beitrag keinen Fyrtur-Ein / Aus-Schalter mehr im Netzwerk und in dieser Zeit keine Aussetzer mehr. Könnte ein Zufall sein ...?

Nein, ich habe keine Tradfri-Ein / Aus- oder Tradfri-Vorhänge und habe dieses Problem.
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment -562299982

Dieses Problem wurde versehentlich geschlossen. Wiedereröffnung.

Ein interessanteres Experiment wäre, die Trådfri-Spots mit der Hue-Brücke oder dem OSRAM-Gateway zu verbinden.

Ich hatte das gleiche Problem mit Trådfri-Lampen (erste Generation), die an den Trådfri-Hub angeschlossen waren. Das Problem verschwand vollständig, als ich alle Glühbirnen auf eine Hue-Brücke stellte.

Übrigens - ich bin immer noch davon überzeugt, dass die erste Generation von Trådfri-Lampen fehlerhaft ist, aber die Hue-Brücke behandelt die Lichter anders (ich habe festgestellt, dass die Lichter manchmal für den Bruchteil einer Sekunde nicht mehr synchron sind, wenn sie mit Hue verbunden sind - ist bei Trådfri nie passiert ).

Die Hue-Brücke behandelt die Lichter anders (ich habe festgestellt, dass die Lichter manchmal für den Bruchteil einer Sekunde nicht mehr synchron sind, wenn sie mit Hue verbunden sind - was bei Trådfri nie passiert ist).

Im Hue-Setup werden Lichter immer nur von der Hue-Brücke gesteuert: Drahtlose Schalter und Sensoren senden Benachrichtigungen an die Brücke und lösen Regeln aus, die die Lichter steuern. Die Brücke sagt den Lichtzustand voraus und aktualisiert ihren Cache im Voraus, wenn Befehle an die Lichter gesendet werden. Die Lichter werden regelmäßig abgefragt, um den zwischengespeicherten Status zu überprüfen / zu aktualisieren.

Im Trådfri-Setup werden die Lichter direkt durch Befehle von drahtlosen Schaltern und Sensoren gesteuert. Die Lichter senden dann einen Bericht mit aktualisiertem Status an den Hub.

Wenn Sie Lichter steuern, die direkt über (Trådfri) drahtlose Schalter oder Sensoren mit einer Hue-Brücke verbunden sind, wird eine Verzögerung angezeigt, da die Hue-Brücke keine Attributberichte für die Lichter einrichtet. Je mehr Lichter in Ihrem Netzwerk sind, desto länger ist die Verzögerung, da die Abfrage mehr Lichter durchläuft.

Wenn Sie Hue-Lampen an einen Trådfri-Hub anschließen und diese Lichter direkt über (Trådfri) Funkschalter oder -sensoren steuern, wird der Hub-Status niemals aktualisiert, da Hue-Lichter keine Attributberichte erstellen und der Trådfri-Hub keine Abfragen durchführt.

Beachten Sie, dass diese Unterschiede auf Anwendungsebene liegen und sich in der Kontrolle des REST-API-Plugins befinden. Das Routing befindet sich im ZigBee-Stack auf einer niedrigeren Ebene.

Jetzt werden alle meine IKEA-Routerknoten auf meine Farbtonbrücke verschoben. Ich habe immer noch das gleiche Problem in meinem Netzwerk. Ich vermute also, dass es etwas anderes ist, das es verursacht. Auch hier sind Knoten betroffen, die geroutet sind und keine direkte Verbindung zum Gateway haben.

Jetzt werden alle meine IKEA-Routerknoten auf meine Farbtonbrücke verschoben. Ich habe immer noch das gleiche Problem in meinem Netzwerk. Ich vermute also, dass es etwas anderes ist, das es verursacht. Auch hier sind Knoten betroffen, die geroutet sind und keine direkte Verbindung zum Gateway haben.

Das gleiche Problem mit den Tradfri-Lichtern, die jetzt mit der Hue-Brücke gekoppelt sind?

@ebaauw Sollte das Routing-Problem auftreten, wenn eine Leuchte direkt UND über einen Router mit der Bridge verbunden ist oder nur, wenn sie nicht direkt mit der Bridge verbunden ist?

Jetzt werden alle meine IKEA-Routerknoten auf meine Farbtonbrücke verschoben. Ich habe immer noch das gleiche Problem in meinem Netzwerk. Ich vermute also, dass es etwas anderes ist, das es verursacht. Auch hier sind Knoten betroffen, die geroutet sind und keine direkte Verbindung zum Gateway haben.

Das gleiche Problem mit den Tradfri-Lichtern, die jetzt mit der Hue-Brücke gekoppelt sind?

Ich habe nur 3 Glühbirnen gepaart. Aber keine Probleme, die mir aufgefallen sind.

@ebaauw Sollte das Routing-Problem auftreten, wenn eine Leuchte direkt UND über einen Router mit der Bridge verbunden ist oder nur, wenn sie nicht direkt mit der Bridge verbunden ist?

In meinem Netzwerk habe ich das Problem, dass Probleme mit verlorenen Befehlen Knoten betreffen, die über andere Knoten und nicht direkt mit dem Gateway geleitet werden. Ich habe jetzt die gleichen Probleme, auch wenn keine IKEA-Lampen angeschlossen sind.

Ich hatte einen Knoten (1) ohne direkte Verbindung zum Gateway. Es reagierte nicht auf Unicast-Befehle (oder wie ebaauw erwähnte, erreichen sie den Knoten möglicherweise aufgrund von Routing-Problemen nie). Als ich den Knoten (2) ausschaltete, wurde er durch den Knoten (1) geleitet, der einen direkten Weg zum Gateway erhielt und perfekt funktionierte.

Sollte das Routing-Problem auftreten, wenn eine Leuchte direkt UND über einen Router an die Bridge angeschlossen ist oder nur, wenn sie nicht direkt mit der Bridge verbunden ist?

In ZigBee gibt es keine "Verbindungen". Jeder Router führt eine Nachbartabelle mit Geräten in der Nähe, die direkt (auf MAC-Ebene) erreichbar ist. Die Zeilen in der deCONZ-GUI sind nichts anderes als eine grafische Darstellung dieser Nachbartabellen (sofern deCONZ diese tatsächlich gelesen hat).

Wenn ein Router eine Nachricht an ein Gerät senden muss, das sich nicht in seiner Nachbartabelle befindet, sendet er die Anforderung an einen benachbarten Router, damit dieser sie weiterleiten kann. Die einzelne Nachricht auf NWK-Ebene wird über mehrere Hops auf MAC-Ebene erneut übertragen. Der RaspBee / ConBee (in dieser Perspektive) ist nur ein weiterer Router. Afaik ein Endgerät sendet nur Nachrichten an seinen übergeordneten Router.

Wenn sich also ein Licht in der Nachbartabelle von RaspBee / ConBee befindet, ist keine Routenerkennung beteiligt, unabhängig davon, ob dieses Licht die Nachbartabelle anderer Router ist. Wenn dies nicht der Fall ist, muss der RaspBee / ConBee herausfinden, welcher benachbarte Router weiß, wie er das Licht erreicht. Wenn das Licht mehrere Sprünge entfernt ist, muss jeder Router auf dem Weg dorthin rekursiv dasselbe tun.

Ich fürchte, die Details gehen mir verloren, aber es gibt mehrere Möglichkeiten, diese Routenerkennung durchzuführen. Wenn Router auf dem Pfad zwischen dem Gateway und der Lampe unterschiedliche Methoden verwenden, können Fehler auftreten. Das Gateway sendet möglicherweise die Nachricht an den Router des falschen Nachbarn (der nicht weiß, wie er das Licht erreicht), oder das Gateway weiß möglicherweise überhaupt nicht, wie das Licht erreicht wird, und sendet überhaupt keine Nachricht. Unicast-Nachrichten sollten im Allgemeinen mit einer ACK beantwortet werden, damit das Gateway ein Gerät als nicht erreichbar markiert, wenn es die ACK nicht empfängt. Natürlich kann nicht festgestellt werden, ob die ursprüngliche Nachricht oder die ACT verloren gegangen ist (das Remote-Gerät muss die Route zum Gateway kennen, um die ACK zu senden).

Broadcast-Nachrichten (von Gruppenbefehlen verwendet) verwenden kein Routing. Sie werden einfach von allen Routern auf MAC-Ebene erneut gesendet. Sie sind zwar sehr zuverlässig, verbrauchen jedoch viel Netzwerkbandbreite. Außerdem werden sie nicht von einem ACK beantwortet.

In meinem Netzwerk habe ich das Problem, dass Probleme mit verlorenen Befehlen Knoten betreffen, die über andere Knoten und nicht direkt mit dem Gateway geleitet werden. Ich habe jetzt die gleichen Probleme, auch wenn keine IKEA-Lampen angeschlossen sind.

Für Routing-Probleme benötigen Sie ein Netzwerk, das groß genug ist, damit Geräte nicht in der Routing-Tabelle von RaspBee / ConBee angezeigt werden. Entweder weil die Anzahl der Geräte die Größe der Routing-Tabelle überschreitet oder weil Remote-Geräte physisch außerhalb der Reichweite von RaspBee / ConBee liegen und nur über andere Router erreichbar sind. Ich nehme an, mehrere Hopfen würden das Problem verschlimmern.

Auch hier ist es nicht so sehr IKEAs Schuld, sondern es sind verschiedene Hersteller, die unterschiedliche, etwas inkompatible Methoden zur Routenerkennung verwenden. Insbesondere bei Multi-Hop-Routen kann in der RaspBee / ConBee-Firmware nur so viel umgangen werden.

Ich hatte einen Knoten (1) ohne direkte Verbindung zum Gateway. Es reagierte nicht auf Unicast-Befehle (oder wie ebaauw erwähnte, erreichen sie den Knoten möglicherweise aufgrund von Routing-Problemen nie). Als ich den Knoten (2) ausschaltete, wurde er durch den Knoten (1) geleitet, der einen direkten Weg zum Gateway erhielt und perfekt funktionierte.

Auch hier befürchte ich, dass die Details für mich verloren gehen, aber ich kann mir mehrere Szenarien vorstellen, die dieses Verhalten verursachen würden. Der RaspBee / ConBee möchte eine Nachricht an Knoten2 oder Knoten1 senden, erhält keine Bestätigung, kommt zu dem Schluss, dass Knoten2 nicht erreichbar ist, und entfernt sie aus seiner Nachbartabelle. Die Tabelle bietet jetzt Platz für einen neuen Eintrag, der für Knoten1 verwendet wird.

Auch hier ist es nicht so sehr IKEAs Schuld, sondern es sind verschiedene Hersteller, die unterschiedliche, etwas inkompatible Methoden zur Routenerkennung verwenden. Insbesondere bei Multi-Hop-Routen kann in der RaspBee / ConBee-Firmware nur so viel umgangen werden.

Das klingt für mich so, als ob der Ansatz einer ZigBee-Plattform mit mehreren Anbietern vom Design her zum Scheitern verurteilt ist, bis ein gründlicherer Standard festgelegt und befolgt wird. Trotzdem bin ich momentan irgendwie eingesperrt, da ich nicht mehrere Gateways verwenden möchte, die in meiner Umgebung wahrscheinlich sowieso nicht funktionieren würden (z. B. für Sensoren, die nicht direkt vom Gateway erreicht werden können, wenn ich derzeit funktionierende Lampen entferne als Router).

Das klingt für mich so, als wäre der Ansatz einer ZigBee-Plattform mit mehreren Anbietern zum Scheitern verurteilt

Ich hoffe sicherlich nicht, aber es ist definitiv eine Herausforderung. Die Größe scheint hier eine Rolle zu spielen: Wenn Ihr Netzwerk klein genug ist, treten diese Routing-Probleme möglicherweise überhaupt nicht auf. Wenn das (geografische) Zentrum Ihres Netzwerks aus Routern kompatibler Anbieter besteht, spielen einige weniger kompatible Router am Rand Ihres Netzwerks wahrscheinlich keine Rolle (da sie nicht weitergeleitet werden, um andere Geräte zu erreichen).

Ich habe meine OSRAM-, Trådfri- und Innr-Lampen (die Probleme verursachten) durch Hue-Lampen ersetzt. Ich habe jetzt 104 Knoten, 51 Router und 53 Endgeräte. 2/3 der Router sind Hue-Lichter. Der einzige Router, der nicht mehr erreichbar ist (aber immer noch Berichte sendet), ist der Xiaomi Curtain Controller. 20 der Endgeräte sind Hue, 20 Xiaomi, 8 Eurotronic Spirit und 5 IKEA. Der Eurotronic Spirit und IKEA Fyrtur verursachen mir regelmäßig Probleme (sie werden von ihren Eltern rausgeschmissen, finden aber keine neuen Eltern - wieder nicht erreichbar durch das Gateway, senden aber immer noch Berichte), die anderen scheinen in Ordnung zu sein. Bei allen Geräten behebt das Aus- und Wiedereinschalten normalerweise die Situation, aber manchmal muss ich das Netzwerk öffnen, wenn das Gerät aus- und wieder eingeschaltet wird.

Ich habe überlegt, mein Netzwerk nicht nach Anbietern aufzuteilen, sondern nach Etage oder Straßenseite und Rückseite meines Hauses. Dies ist eine Menge Arbeit, und ich zögere es, dies zu tun, bis ich ein besseres Verständnis dafür habe, was die Probleme im Detail verursacht und welche Einrichtung sie möglicherweise verhindert.

@ebaauw , wenn Sie darüber
Dies wäre keine endgültige Lösung, würde jedoch viel größere (geografische und Anzahl der Geräte) Netzwerke ermöglichen, während immer "bevorzugte" Router verwendet werden.

Ein anderer Gedanke: Da wir wissen, welche Chips von IKEA verwendet werden (Silabs EFR32, Gecko-Engine) und wir (aus verschiedenen Quellen im Internet) wissen, dass sie die von Silabs bereitgestellte ZigBee-Engine verwenden, können wir zwei Aktionen in Betracht ziehen.

1. Wir analysieren die Art und Weise, wie die Silabs-Engine das Routing durchführt, und leiten daraus ab, was dieses Problem verursacht
2. Wir erstellen eine benutzerdefinierte Version der Lampen-Firmware, die auf derselben Silabs-Engine basiert, beheben das Problem und finden heraus, wie diese Firmware von OTA installiert werden kann

Beide würden Zugriff auf das Silabs SDK erfordern, was ich nicht tue. Ist hier jemand aktiv, der das tut? Ich freue mich nicht darauf, 500 US-Dollar für das Entwicklungskit auszugeben, das das SDK enthält. Vielleicht ist die Dresdner Elektronik dazu bereit?

meine 2 cts (ziemlich frustriert über die gelegentlich verlorenen Verbindungen).

Könnten wir in Betracht ziehen, Router auf die schwarze Liste zu setzen, die als erster Hop nicht vorzuziehen sind?

Wir Nein. Es müsste in der RaspBee / ConBee-Firmware implementiert werden, nehme ich an. Imho keine schlechte Idee, aber ich habe keine Ahnung, wie machbar dies ist, angesichts der Größenbeschränkungen im EEPROM und NVRAM des Geräts. @manup , was denkst du darüber?

1. Wir erstellen eine benutzerdefinierte Version der Lampen-Firmware, die auf derselben Silabs-Engine basiert, beheben das Problem und finden heraus, wie diese Firmware von OTA installiert werden kann

Dies geht weit über mein derzeitiges Wissen und ehrlich gesagt über meinen Ehrgeiz hinaus - ich mache dies für ein Hobby. Ich habe mit dem XBee herumgespielt, um zu sehen, ob ich eine ZigBee-Anwendung schreiben kann (mein ultimatives Ziel wäre es, meine Jalousien zu intelligent zu machen), aber ich habe nie in die unteren Ebenen des ZigBee-Stapels geschaut, in denen das Routing stattfindet .

Wir Nein. Es müsste in der RaspBee / ConBee-Firmware implementiert werden, nehme ich an. Imho keine schlechte Idee, aber ich habe keine Ahnung, wie machbar dies ist, angesichts der Größenbeschränkungen im EEPROM und NVRAM des Geräts. @manup , was denkst du darüber?

Ich denke, ich betrachte @manup als Teil von We;)

Dies geht weit über mein derzeitiges Wissen und ehrlich gesagt über meinen Ehrgeiz hinaus - ich mache dies für ein Hobby. Ich habe mit dem XBee herumgespielt, um zu sehen, ob ich eine ZigBee-Anwendung schreiben kann (mein ultimatives Ziel wäre es, meine Jalousien zu intelligent zu machen), aber ich habe nie in die unteren Ebenen des ZigBee-Stapels geschaut, in denen das Routing stattfindet .

Ich stimme zu, für mich ist es auch ein Hobby, aber ich hoffe, dass jemand mehr über diese Details weiß.

Ich habe etwas Ähnliches getan, indem ich CC2530-Karten verwendet habe, die ich vorhabe, meine Sprinkleranlage im Zickzack zu verkleinern (ich kann nicht akzeptieren, dass ich im Garten herumlaufen muss, um bestimmte Sprinkler manuell ein- und auszuschalten :)). Ich konnte eine kompilieren ZigBee-Firmware für mein CC2530-Board, das als Ein / Aus-Licht in das deCONZ-Netzwerk aufgenommen wird. Die Ventile, die ich verwenden möchte, haben einen Verriegelungsmechanismus, daher ist zum Schalten ein bestimmtes Signal erforderlich, daher musste ich meine eigene Firmware erstellen ...

Wir Nein. Es müsste in der RaspBee / ConBee-Firmware implementiert werden, nehme ich an. Imho keine schlechte Idee, aber ich habe keine Ahnung, wie machbar dies ist, angesichts der Größenbeschränkungen im EEPROM und NVRAM des Geräts. @manup , was denkst du darüber?

Der ZigBee-Stack in der Firmware verfügt über einen Parameter, mit dem gesteuert werden kann, ob eine Route anstelle einer direkten Verbindung verwendet werden soll, basierend auf ihrer Qualität (RSSI / LQI). Dies sollte bereits recht gut funktionieren und wurde im Laufe der Jahre optimiert.

Ein weiterer Pfad könnte ein allgemeinerer Ansatz zur Steuerung der Routing-Tabellen aller Geräte sein.

Hinweis: Sie können die Routing-Tabelle eines Routers abfragen, indem Sie sie auswählen und die Taste R drücken. Die Routen für den nächsten Hop werden blau angezeigt.

Derzeit dürfen beim Öffnen des ZigBee-Netzwerks alle Router ein übergeordneter Knoten sein, da Mgmt_Permit_Joining_req als Broadcast gesendet wird. Wenn wir diese Anforderung jedoch nur als Unicast an einen bestimmten Router senden, kann ein neues Gerät nur über dieses eine Gerät beitreten. Dies kann für Xiaomi-Endgeräte nützlich sein, die häufig bei ihren Eltern bleiben. Für andere Verbindungsgeräte wie Router und beispielsweise Philips Hue-Endgeräte hilft dies nicht viel, da sie frei sind, neue Eltern und Routen selbst auszuwählen.

Interessant sieht auch die (neue) Mgmt_NWK_IEEE_Joining_List_req in der Zigbee R22-Spezifikation aus:

Der Befehl Mgmt_NWK_IEEE_Joining_List_req wird als Mechanismus bereitgestellt, um die Liste der IEEE-Adressen abzurufen, von denen erwartet wird, dass sie dem Netzwerk beitreten. Auf diese Weise kann der lokale Router Enhanced Beacon Requests filtern und nur auf die Geräte reagieren, die beitreten.

Ohne Beacons würden Geräte nicht einmal versuchen, einem bestimmten Router beizutreten. Mir ist jedoch nicht bekannt, wie gut diese Anforderung von derzeit verfügbaren Routern unterstützt wird.

Eine Silberkugel verwendet möglicherweise das Quell-Routing, bei dem das Gateway die vollständige Route innerhalb jedes Frames bereitstellt. Ich habe jedoch noch nie gesehen, dass dies von einem Verbraucherprodukt oder Gateway verwendet wird, und ich denke, dass es von aktuellen Routern möglicherweise nicht (oder nur schlecht) unterstützt wird. Könnte aber einen Versuch wert sein.

Hinweis: Sie können die Routing-Tabelle eines Routers abfragen, indem Sie sie auswählen und die Taste R drücken. Die Routen für den nächsten Hop werden blau angezeigt.

Cool, das wusste ich nicht. Gibt es eine Übersicht aller von der GUI unterstützten Tasten / Befehle? Ist es möglich, die blauen Linien zurückzusetzen, bevor der nächste Knoten abgefragt wird? Es scheint nicht für das RaspBee / ConBee selbst zu funktionieren?

Unterscheidet sich die Routing-Tabelle von der Nachbartabelle? Beim Schnüffeln werden nur ZDP-Nachrichten _Link Quality Request_ und _Link Quality Response_ angezeigt, die die Nachbartabelle melden. Bedeutet dies, dass die Linien zu einem Knoten, die nicht blau gefärbt sind, die "eingehenden" Routen sind?

@manup , in der Tat eine interessante Visualisierung

Eine Silberkugel verwendet möglicherweise das Quellrouting

Nun ... das wäre einen Versuch wert, denke ich. Es scheint mir, dass in meinem Netzwerk die am stärksten betroffenen IKEA-Lichter diejenigen sind, die sich in größerer Entfernung vom Koordinator befinden. Ich habe vermutet, dass etwas im Zusammenhang mit dem Routing die Probleme verursacht, wie @ebaauw erwähnte.
Ich wäre bereit, so etwas für Sie zu testen. Obwohl ich zugeben muss, dass der Verlust der Verbindungen nicht sehr zuverlässig ist, kann das Testen schwierig sein.

Ich dachte eher nach dem Vorbild des Koordinators darüber nach, welchen Router ich für den ersten Hop auswählen sollte. Wenn wir Router finden, die mit den IKEA-Geräten gut funktionieren (möglicherweise sind dies die IKEA-Router), sollte das Weiterleiten aller Pakete durch diese die Dinge robuster machen. Sie sind sich nicht sicher, ob Sie den Routenerkennungsprozess austricksen können, um einen bestimmten Router für den ersten Hop zu bevorzugen, aber wahrscheinlich können Sie dies kommentieren,

Hinweis: Sie können die Routing-Tabelle eines Routers abfragen, indem Sie sie auswählen und die Taste R drücken. Die Routen für den nächsten Hop werden blau angezeigt.

Cool, das wusste ich nicht. Gibt es eine Übersicht aller von der GUI unterstützten Tasten / Befehle? Ist es möglich, die blauen Linien zurückzusetzen, bevor der nächste Knoten abgefragt wird? Es scheint nicht für das RaspBee / ConBee selbst zu funktionieren?

Wenn jemand alle Schlüsselkombinationen und deren Aufgaben auflisten möchte, bereinige ich sie gerne und schreibe eine Wiki-Seite.

Cool, das wusste ich nicht. Gibt es eine Übersicht aller von der GUI unterstützten Tasten / Befehle?

Request Node Descriptor = 1
Power Descriptor anfordern = 2
Nwk-Adresse anfordern = 0
Request Routing Table = R
Anfrage Mgmt Leave = L (bei Wiedereintritt nicht mit Innr Lights verwenden!)
Aktive Endpunkte anfordern = 7
Einfache Deskriptoren anfordern = 8
Aktualisieren = F5 / Cmd-R
Löschen = Delete / Backspace
Gateway Device Annce = A (nicht so nützlich)

Ist es möglich, die blauen Linien zurückzusetzen, bevor der nächste Knoten abgefragt wird?

Noch nicht, es war nur eine schnelle und schmutzige Ergänzung, um Routen zu sehen :)
Vielleicht ist es nützlich, einen weiteren Schlüssel wie Shift-R hinzuzufügen, um die Routen eines Knotens zu löschen?

Es scheint nicht für das RaspBee / ConBee selbst zu funktionieren?

Leider unterstützt RaspBee I / ConBee I den zugehörigen ZDP-Befehl nicht, er funktioniert mit ConBee II.

Unterscheidet sich die Routing-Tabelle von der Nachbartabelle? Beim Schnüffeln werden nur die Nachrichten ZDP Link Quality Request und Link Quality Response angezeigt, die die Nachbartabelle melden.

Dies sind zwei separate Tabellen. In der Regel enthält die Routing-Tabelle nur Routen zu Knoten, die nicht direkt erreichbar sind und für die Nachbartabelle (1-Hop-Knoten) gelten.

Für Knoten, die sich in der Nachbartabelle befinden (und ein starkes Signal haben), ist keine Routenerkennung erforderlich. Die Nachbartabelle selbst wird hauptsächlich mit 1-Hop-NWK-Verbindungsstatusbefehlen erstellt.

Bedeutet dies, dass die Linien zu einem Knoten, die nicht blau gefärbt sind, die "eingehenden" Routen sind?

Die nicht blauen Linien (grün / orange / gelb) repräsentieren nur die 1-Hop-Nachbartabelle. Die blauen Linien sind ausgehende Routen zu einem bestimmten Ziel und stellen nur den nächsten Hop (nicht die vollständige Route) dar. In der aktuellen Ansicht wird die NWK-Adresse des Ziels nicht angezeigt, aber es gibt wahrscheinlich Debug-Ausdrucke.

Wir Nein. Es müsste in der RaspBee / ConBee-Firmware implementiert werden, nehme ich an. Imho keine schlechte Idee, aber ich habe keine Ahnung, wie machbar dies ist, angesichts der Größenbeschränkungen im EEPROM und NVRAM des Geräts. @manup , was denkst du darüber?

Der ZigBee-Stack in der Firmware verfügt über einen Parameter, mit dem gesteuert werden kann, ob eine Route anstelle einer direkten Verbindung verwendet werden soll, basierend auf ihrer Qualität (RSSI / LQI). Dies sollte bereits recht gut funktionieren und wurde im Laufe der Jahre optimiert.

Ein weiterer Pfad könnte ein allgemeinerer Ansatz zur Steuerung der Routing-Tabellen aller Geräte sein.

Hinweis: Sie können die Routing-Tabelle eines Routers abfragen, indem Sie sie auswählen und die Taste R drücken. Die Routen für den nächsten Hop werden blau angezeigt.

Wirklich nützliche Funktion! Gestern habe ich meine TRÅDFRI-Lampe GU10 WS 400lm (7 Lampen) mit Firmware 2.0.022 eingeschaltet. Heute kamen die Probleme zurück, es erschien auf einer TRÅDFRI-Lampe E27 CWS Opal 600lm mit Firmware 1.3.009. Dank dieser Funktion konnte ich sehen, dass die E27-Lampe durch die GU10-Lampe geführt wurde. Ich habe das gesamte GU10 ausgeschaltet und wie durch Zauberei begann das E27 wieder zu funktionieren.

Es wird also ziemlich klar, dass das Routing durch Innr und IKEA Probleme verursacht. Ich habe begonnen, Innr och IKEA-Lampen an mein Farbton-Gateway zu bringen. Es scheint, dass die Philips-Lampen gute Router sind und keine Probleme verursachen.

Also habe ich ein kleines Experiment gemacht, während ich meine Lichter im Wohnzimmer neu positioniert habe. Ich entfernte zwei Router und positionierte ein Licht neu. Et voila, ein Licht ist Zombie geworden, aber nicht vollständig. Es verhält sich genau so, wie ich es bei den IKEA-Leuchten gesehen habe, die gelegentlich die Verbindung verlieren.

Das IKEA-Licht wird als nicht erreichbar aufgeführt, reagiert jedoch weiterhin auf Gruppenbefehle. Da es noch mehreren anderen Routern bekannt ist, scheinen sie zu berichten, dass sie das Licht sehen (es ist 0x000B57FFFEC52C7D ):

11:49:33:392 ZDP Mgmt_Lqi_rsp zdpSeq: 190 from 0x000B57FFFE9BEBC3 total: 11, startIndex: 6, listCount: 3
11:49:33:392     * neighbor: 0x00158D00017028B0 (0xA3F5), LQI: 71, relation: 0x02 rxOnWHenIdle: 1
11:49:33:392     * neighbor: 0x90FD9FFFFE054F81 (0xC7BC), LQI: 41, relation: 0x02 rxOnWHenIdle: 1
11:49:33:393     * neighbor: 0x000B57FFFEC52C7D (0xD338), LQI: 69, relation: 0x02 rxOnWHenIdle: 1

und

11:49:50:017 Node 0x000B57FFFEC52C7D is known by 7 neighbors, last seen 33 s

Manchmal scheint Kommunikation möglich zu sein:

11:49:44:901 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 11:49:44:902 0x0000 11:49:44:902 ]
11:49:44:902 add task 6636 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 213
11:49:44:902 Poll APS request 213 to 0x000B57FFFEC52C7D cluster: 0x0006
11:49:44:904 Idle timer triggered
11:49:44:951 Poll APS confirm 213 status: 0x00
11:49:44:951 Erase task req-id: 213, type: 19 zcl seqno: 89 send time 0, profileId: 0x0104, clusterId: 0x0006

manchmal nicht:

12:18:51:033 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 12:18:51:033 0x0000 12:18:51:033 ]
12:18:51:033 add task 4658 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 119
12:18:51:033 Poll APS request 119 to 0x000B57FFFEC52C7D cluster: 0x0006
---
12:19:02:077 Poll APS confirm 119 status: 0xA7
12:19:02:077     drop item attr/modelid
12:19:02:077     drop item attr/swversion
12:19:02:077     drop item state/bri
12:19:02:077 0x000B57FFFEC52C7D error APSDE-DATA.confirm: 0xA7 on task

Es gibt nur sehr wenige Informationen darüber, was falsch läuft. Was bedeutet der 0xA7-Status?

Gibt es weitere Informationen, die helfen könnten, herauszufinden, was passiert?

Also habe ich ein kleines Experiment gemacht, während ich meine Lichter im Wohnzimmer neu positioniert habe. Ich entfernte zwei Router und positionierte ein Licht neu. Et voila, ein Licht ist Zombie geworden, aber nicht vollständig. Es verhält sich genau so, wie ich es bei den IKEA-Leuchten gesehen habe, die gelegentlich die Verbindung verlieren.

Das IKEA-Licht wird als nicht erreichbar aufgeführt, reagiert jedoch weiterhin auf Gruppenbefehle. Da es noch mehreren anderen Routern bekannt ist, scheinen sie zu berichten, dass sie das Licht sehen (es ist 0x000B57FFFEC52C7D ):

11:49:33:392 ZDP Mgmt_Lqi_rsp zdpSeq: 190 from 0x000B57FFFE9BEBC3 total: 11, startIndex: 6, listCount: 3
11:49:33:392     * neighbor: 0x00158D00017028B0 (0xA3F5), LQI: 71, relation: 0x02 rxOnWHenIdle: 1
11:49:33:392     * neighbor: 0x90FD9FFFFE054F81 (0xC7BC), LQI: 41, relation: 0x02 rxOnWHenIdle: 1
11:49:33:393     * neighbor: 0x000B57FFFEC52C7D (0xD338), LQI: 69, relation: 0x02 rxOnWHenIdle: 1

und

11:49:50:017 Node 0x000B57FFFEC52C7D is known by 7 neighbors, last seen 33 s

Manchmal scheint Kommunikation möglich zu sein:

11:49:44:901 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 11:49:44:902 0x0000 11:49:44:902 ]
11:49:44:902 add task 6636 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 213
11:49:44:902 Poll APS request 213 to 0x000B57FFFEC52C7D cluster: 0x0006
11:49:44:904 Idle timer triggered
11:49:44:951 Poll APS confirm 213 status: 0x00
11:49:44:951 Erase task req-id: 213, type: 19 zcl seqno: 89 send time 0, profileId: 0x0104, clusterId: 0x0006

manchmal nicht:

12:18:51:033 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 12:18:51:033 0x0000 12:18:51:033 ]
12:18:51:033 add task 4658 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 119
12:18:51:033 Poll APS request 119 to 0x000B57FFFEC52C7D cluster: 0x0006
---
12:19:02:077 Poll APS confirm 119 status: 0xA7
12:19:02:077     drop item attr/modelid
12:19:02:077     drop item attr/swversion
12:19:02:077     drop item state/bri
12:19:02:077 0x000B57FFFEC52C7D error APSDE-DATA.confirm: 0xA7 on task

Es gibt nur sehr wenige Informationen darüber, was falsch läuft. Was bedeutet der 0xA7-Status?

Gibt es weitere Informationen, die helfen könnten, herauszufinden, was passiert?

Das klingt nach einer exakten Nachbildung meiner Probleme!

Was bedeutet der 0xA7-Status?

Siehe hier: https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Zigbee-Error-Codes-in-the-Log

Die Stromversorgung schaltete das Licht aus

12:39:21:833 ZDP device announce: 0x000B57FFFEC52C7D, 0xD338, 0x8E
12:39:21:833 ZDP add fast discover for 0x000b57fffec52c7d
12:39:21:838 DeviceAnnce of LightNode: 0x000b57fffec52c7d Permit Join: 0
12:39:22:040 ZDP finished fast discover for 0x000b57fffec52c7d

Und scheint glücklich über seinen Status zu berichten

12:39:22:665 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 12:39:22:665 0x0000 12:39:22:665 ]
12:39:22:665 add task 10024 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 175
12:39:22:665 Poll APS request 175 to 0x000B57FFFEC52C7D cluster: 0x0006
12:39:22:753 Poll APS confirm 175 status: 0x00
12:39:22:753 Erase task req-id: 175, type: 19 zcl seqno: 167 send time 0, profileId: 0x0104, clusterId: 0x0006
12:39:22:920 Node 0x000B57FFFEC52C7D is known by 9 neighbors, last seen 1 s

dann:

12:39:26:760 ZDP active ep request to 0x000b57fffec52c7d
12:39:26:760 ZDP send request id: 0x07 to 0x000b57fffec52c7d
---
12:39:32:520 node 0000B57FFFEC52C7D leave wait state
12:39:32:521 ZDP active ep request to 0x000b57fffec52c7d
12:39:32:521 Incr. ZDP retry count 2 on item 7
---
12:39:44:655 add task 10125 type 21 to 0x000B57FFFEC52C7D cluster 0x0004 req.id 60
12:39:44:700 Erase task req-id: 60, type: 21 zcl seqno: 171 send time 0, profileId: 0x0104, clusterId: 0x0004
---
12:39:45:405 create binding for attribute reporting of cluster 0x0000
12:39:45:405 queue binding task for 0x000B57FFFEC52C7D, cluster 0x0000
12:39:45:405 create binding for attribute reporting of cluster 0x0006
12:39:45:405 queue binding task for 0x000B57FFFEC52C7D, cluster 0x0006
12:39:45:405 create binding for attribute reporting of cluster 0x0008
12:39:45:405 queue binding task for 0x000B57FFFEC52C7D, cluster 0x0008
12:39:45:405 Force binding of attribute reporting for node HK houtlamp 2
---
12:39:50:760 Node 0x000B57FFFEC52C7D is known by 9 neighbors, last seen 28 s
---
12:40:06:904 binding/unbinding timeout srcAddr: B57FFFEC52C7D, retry
12:40:08:905 binding/unbinding timeout srcAddr: B57FFFEC52C7D, retry
---
12:40:11:881 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 12:40:11:881 0x0000 12:40:11:881 ]
12:40:11:882 add task 10241 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 205
12:40:11:882 Poll APS request 205 to 0x000B57FFFEC52C7D cluster: 0x0006
---
12:40:21:640 ZDP skip fetch, node 0xB57FFFEC52C7D has unconfirmed requests [1]
---
12:40:22:957 Poll APS confirm 205 status: 0xA7
12:40:22:957     drop item attr/modelid
12:40:22:957     drop item attr/swversion
12:40:22:957     drop item state/bri
12:40:22:957 0x000B57FFFEC52C7D error APSDE-DATA.confirm: 0xA7 on task
12:40:22:957 Erase task req-id: 205, type: 19 zcl seqno: 175 send time 11, profileId: 0x0104, clusterId: 0x0006
12:40:22:957 max transmit errors for node 0x000B57FFFEC52C7D, last seen by neighbors 78 s
---
12:40:28:904 giveup binding srcAddr: B57FFFEC52C7D
---
12:40:30:904 binding/unbinding timeout srcAddr: B57FFFEC52C7D, retry
---
12:40:32:050 giveup binding srcAddr: B57FFFEC52C7D
---
12:40:33:568 ZDP skip fetch, node 0xB57FFFEC52C7D has unconfirmed requests [1]
---
12:40:39:481 ZDP skip fetch, node 0xB57FFFEC52C7D has unconfirmed requests [1]
---
12:40:42:987 max transmit errors for node 0x000B57FFFEC52C7D, last seen by neighbors 10 s
---
12:40:43:276 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 12:40:43:276 0x0000 12:40:43:276 ]
12:40:43:277 add task 10380 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 157
12:40:43:277 Poll APS request 157 to 0x000B57FFFEC52C7D cluster: 0x0006
---
12:40:54:621 Poll APS confirm 157 status: 0xA7
12:40:54:621     drop item attr/modelid
12:40:54:621     drop item attr/swversion
12:40:54:621     drop item state/bri
12:40:54:621 0x000B57FFFEC52C7D error APSDE-DATA.confirm: 0xA7 on task
12:40:54:621 Erase task req-id: 157, type: 19 zcl seqno: 180 send time 12, profileId: 0x0104, clusterId: 0x0006
12:40:54:621 max transmit errors for node 0x000B57FFFEC52C7D, last seen by neighbors 22 s

es hört auf zu arbeiten. bis .. 2 Minuten später

12:42:10:529 LightNode removed 0x000b57fffec52c7d
12:42:10:530 Node zombie state changed 0x000b57fffec52c7d
---
12:42:39:361 Node 0x000B57FFFEC52C7D is known by 0 neighbors, last seen 0 s
---
12:43:06:904 add task 11002 type 21 to 0x000B57FFFEC52C7D cluster 0x0004 req.id 83
12:43:06:953 Erase task req-id: 83, type: 21 zcl seqno: 198 send time 0, profileId: 0x0104, clusterId: 0x0004
12:43:07:329 Node 0x000B57FFFEC52C7D is known by 0 neighbors, last seen 22 s
---
12:43:12:455 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 12:43:12:455 0x0000 12:43:12:455 ]
12:43:12:455 add task 11026 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 125
12:43:12:455 Poll APS request 125 to 0x000B57FFFEC52C7D cluster: 0x0006
12:43:12:498 ZDP status = 0x00 -> SUCCESS

Ich denke, ich muss mir einen ZigBee-Schnüffler besorgen, um herauszufinden, was über Funk passiert.

danach hörte es wieder auf zu arbeiten, diesmal etwas dauerhafter.

Was bedeutet der 0xA7-Status?

Siehe hier: https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Zigbee-Error-Codes-in-the-Log

Dank dafür! irgendwie ist es das, was ich erwartet hatte ...

Ich habe versucht, meine TRÅDFRI-Lampe GU10 WS 400lm (7 Lampen) mit meiner Philips Hue-Brücke zu koppeln. Mehrere andere Lampen im Netzwerk waren nicht mehr verfügbar, und die TRÅDFRI-Lampe GU10 WS 400lm hatte das gleiche Verhalten wie bei Deconz, Antwort auf Gruppenbefehl, aber keine Antwort auf Unicast.

Die TRÅDFRI-Lampe GU10 WS 400lm scheint ein Problem zu haben. Ich werde einige Tests durchführen, wenn es sich um einzelne Glühbirnen handelt oder wenn alle nicht funktionieren.

Jetzt habe ich einige Tests durchgeführt. Mein Fazit ist, dass es tatsächlich einzelne Glühbirnen sind, die dazu führen, dass das Netzwerk nicht mehr reagiert. Es erschien sofort Almonen auf der Hue Bridge und es fing wieder an zu funktionieren, sobald ich sie abschaltete. Von 7 Glühbirnen sind also 3 betroffen . Ich werde berichten, wenn ich neue Probleme finde.

@MikaelHoogen , welche Version der Lampen und Firmware hast du?

Ich habe dieses Problem in den letzten anderthalb Jahren auf v1 E27 WS 980lm, GU10 WS 400lm, E27 CWS 600lm, E15 WS und allen 3 FLOALT-Panels auf den Ikea-, HUE- und DeCONZ-Gateways gesehen.
Ich bin überzeugt, dass dies ein HW-Problem ist. Es ist völlig zufällig, welcher Knoten stirbt.
Hier in Norwegen gilt für die gesamte Elektronik eine Garantie von 2 Jahren. Ich werde versuchen, ein Ticket zu öffnen und zu hören, was sie sagen.
In Bezug auf den FLOALT. Vor ein paar Monaten führte Ikea einen Ausverkauf für sie durch. Vielleicht war das, um alle v1 loszuwerden?
Hat jemand da draußen einen FLOALT v2 gesehen? (vielleicht mit dem sy5882-Treiber?)

Ich habe dieses Problem in den letzten anderthalb Jahren auf v1 E27 WS 980lm, GU10 WS 400lm, E27 CWS 600lm, E15 WS und allen 3 FLOALT-Panels auf den Ikea-, HUE- und DeCONZ-Gateways gesehen.
Ich bin überzeugt, dass dies ein HW-Problem ist. Es ist völlig zufällig, welcher Knoten stirbt.
Hier in Norwegen gilt für die gesamte Elektronik eine Garantie von 2 Jahren. Ich werde versuchen, ein Ticket zu öffnen und zu hören, was sie sagen.
In Bezug auf den FLOALT. Vor ein paar Monaten führte Ikea einen Ausverkauf für sie durch. Vielleicht war das, um alle v1 loszuwerden?
Hat jemand da draußen einen FLOALT v2 gesehen? (vielleicht mit dem sy5882-Treiber?)

Das versuche ich auch schon seit einiger Zeit zu sagen. Ich habe nur Probleme mit Trådfri v1-Lampen. Die Philips Hue-Brücke hilft, aber Knoten werden von Zeit zu Zeit nicht mehr erreichbar.

Vor ein paar Tagen habe ich beschlossen, alle 12 IKEA GU10-Lampen durch die neue Version (warmweiß) zu ersetzen.
Das machte dieses Problem noch schlimmer. Jetzt verliere ich auch das weiße Ambiente von Hue GU10 und die Farbe von Hue E14.

Ich habe von Anfang an deConz und IKEA light verwendet, als sie herauskamen. Ich habe ungefähr 70 Knoten in meinem Netzwerk. Die meisten davon sind IKEA-Lichter. Ich habe auch einige Philips Hue (4 Lichter) und einen Osram. Sensoren Ich habe nur wenige Ikea-Bewegungssensoren und viele Xiaomi-Bewegungssensoren.

Ich bin schon eine ganze Weile mit diesem Setup unterwegs und kein Tag vergeht, ohne dass die Lichter stecken bleiben, also muss ich das Gerät aus- und wieder einschalten. Meine Frau ist nicht begeistert und ich auch nicht. Ich bin sehr nah dran, alle ZigBee-Geräte loszuwerden und gehe einfach zu einfachen alten Schullichtern. Es funktioniert einfach nicht. sehr enttäuschend. Ich frage mich, ob andere die gleichen Probleme mit reinen Philips- oder Osram-Lichtern sehen, oder ist es nur IKEA, der Mist ist?

Ich habe von Anfang an deConz und IKEA light verwendet, als sie herauskamen. Ich habe ungefähr 70 Knoten in meinem Netzwerk. Die meisten davon sind IKEA-Lichter. Ich habe auch einige Philips Hue (4 Lichter) und einen Osram. Sensoren Ich habe nur wenige Ikea-Bewegungssensoren und viele Xiaomi-Bewegungssensoren.

Ich bin schon eine ganze Weile mit diesem Setup unterwegs und kein Tag vergeht, ohne dass die Lichter stecken bleiben, also muss ich das Gerät aus- und wieder einschalten. Meine Frau ist nicht begeistert und ich auch nicht. Ich bin sehr nah dran, alle ZigBee-Geräte loszuwerden und gehe einfach zu einfachen alten Schullichtern. Es funktioniert einfach nicht. sehr enttäuschend. Ich frage mich, ob andere die gleichen Probleme mit reinen Philips- oder Osram-Lichtern sehen, oder ist es nur IKEA, der Mist ist?

Wenn man sich alle Leute ansieht, die genau die gleichen Probleme in diesem Thread haben, und die Hersteller von deconz nicht herausfinden können, wie das Problem mit den IKEA-Leuchten ist, riecht es und sieht aus wie ein IKEA-Firmware-Problem.

Viele Benutzer haben ähnliche Probleme, selbst mit dem IKEA-Hub. Ich denke, dies ist kein einzigartiges Problem im Zusammenhang mit Deconz. Wenn jedoch jemand dies beheben könnte, "patche es / finde eine Problemumgehung", wären es die Jungs hier! <3

Ich habe genau das gleiche Problem sowohl mit der Familie als auch mit dem Setup.

Es ist traurig :( vor allem, dass selbst die neuen, die sie heute verkaufen, immer noch diese Probleme haben. Ich verstehe es einfach nicht. Ich habe meine ab 2017, also würde man erwarten, dass sie das Problem inzwischen behoben haben. Ich muss überlegen, das Ganze zu entfernen Es kann hier nicht behoben werden, @manup hat zuvor gesagt, dass dies ein Problem in der Firmware des Geräts ist, so dass nur IKEA dies beheben kann, und da sie dies noch nicht getan haben, gibt es keine Hoffnung.

Deconz Version 2.05.69
Conbee II-Firmware 264A0700

Es ist nicht 100% perfekt und die Aussetzer, die mir aufgefallen sind, sind E27 Ikea (Rev1) Glühbirnen.
Als ich diese Ikea-Leuchten mit meiner Philips Hue-Brücke hatte, waren sie absolut stabil, daher verschiebe ich sie wahrscheinlich zurück nach Hue und behalte dieses ZigBee-Netz rein als CC2531- (Router-Firmware) und Xiaomi-Sensoren.
Ich habe auch eine Innr-Lampe (E14) und eine SP120, aber diese sind mit Deconz immer noch in Ordnung.

Ich verwende Home Assistant und Deconz, um ungefähr 20 Ikea-Lampen (und eine Vielzahl anderer Sensoren) zu steuern. Die Lampen sind hauptsächlich GU10s, die durch 3 Punkte zu einem Licht gruppiert sind.

Ich benutze dieses Setup seit mehr als 15 Monaten und seit diesem Sommer habe ich Probleme damit, dass eine oder mehrere einzelne Glühbirnen stecken bleiben und einen Stromzyklus benötigen oder sogar entfernt und dem ZigBee-Netzwerk wieder hinzugefügt werden. Dies waren immer GU10s, die in einer Lichtgruppe in HASS definiert wurden.

Vor einigen Wochen habe ich in Phoscon Gruppen für meine Lichter erstellt und begonnen, diese Gruppen in HASS zu referenzieren.

Danach hatte ich kein einziges Problem damit, dass die Glühbirnen stecken bleiben und einen Stromzyklus benötigen. Das einzige Problem, das ich sehe, ist, dass beim gleichzeitigen Ausschalten aller Innenlichter manchmal eine ganze Phoscon / Deconz-Gruppe eingeschaltet bleibt.

Für mich scheint dies ein Problem mit der Deconz-API zu sein und möglicherweise mehrere Lampen schnell hintereinander zu handhaben.

Ich habe auch Probleme mit Ikea-Geräten (Lampen und in letzter Zeit auch mit der Symfonisk-Fernbedienung), die nicht mehr verfügbar sind und ein erneutes Pairing mit deCONZ erfordern. Ich glaube, ich habe diese Probleme seit ungefähr 6 Monaten. Nicht viel hinzuzufügen, als ich denke, dass es in letzter Zeit häufiger vorkommt. Ich habe keine GU10-Lampen, nur verschiedene E27 und E14 (und verschiedene Fernbedienungen). Es scheint, dass bestimmte Geräte anfälliger für Ausfälle sind (möglicherweise abhängig davon, wie sie ineinander greifen oder ähnlich). Ich habe ca. 20 Geräte mit einer maximalen Reichweite von 5 m vom Conbee I mit neuester FW / Phoscon / deCONZ.

Ich habe auch Probleme mit Ikea-Geräten (Lampen und in letzter Zeit auch mit der Symfonisk-Fernbedienung), die nicht mehr verfügbar sind und ein erneutes Pairing mit deCONZ erfordern. Ich glaube, ich habe diese Probleme seit ungefähr 6 Monaten. Nicht viel hinzuzufügen, als ich denke, dass es in letzter Zeit häufiger vorkommt. Ich habe keine GU10-Lampen, nur verschiedene E27 und E14 (und verschiedene Fernbedienungen). Es scheint, dass bestimmte Geräte anfälliger für Ausfälle sind (möglicherweise abhängig davon, wie sie ineinander greifen oder ähnlich). Ich habe ca. 20 Geräte mit einer maximalen Reichweite von 5 m vom Conbee I mit der neuesten FW / Phoscon / deCONZ.

Versuchen Sie Deconz Version 2.05.69. Ziemlich stabil für mich mit Ikea, Innr und Xiaomi

Ich habe ein ähnliches Problem und ein offenes Ticket unter https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2256#issue -543476970

Ich würde sagen, dass mein Netzwerk beim Downgrade auf die Version 2.05.67 viel stabiler geworden ist als je zuvor. Hatte ein paar Glühbirnen, die nicht mehr reagierten, aber die gleichen zwei und konnten damit leben. Gestern hat alles wie erwartet funktioniert.

Es scheint ein Problem mit einer Mischung aller möglichen Teile zu sein und es natürlich schwer zu finden. Die Deconz-Version scheint jedoch ein wesentlicher Bestandteil einer stabilen Lösung zu sein oder nicht.

Ich habe auch Probleme mit Ikea-Geräten (Lampen und in letzter Zeit auch mit der Symfonisk-Fernbedienung), die nicht mehr verfügbar sind und ein erneutes Pairing mit deCONZ erfordern. Ich glaube, ich habe diese Probleme seit ungefähr 6 Monaten. Nicht viel hinzuzufügen, als ich denke, dass es in letzter Zeit häufiger vorkommt. Ich habe keine GU10-Lampen, nur verschiedene E27 und E14 (und verschiedene Fernbedienungen). Es scheint, dass bestimmte Geräte anfälliger für Ausfälle sind (möglicherweise abhängig davon, wie sie ineinander greifen oder ähnlich). Ich habe ca. 20 Geräte mit einer maximalen Reichweite von 5 m vom Conbee I mit der neuesten FW / Phoscon / deCONZ.

Versuchen Sie Deconz Version 2.05.69. Ziemlich stabil für mich mit Ikea, Innr und Xiaomi

Werde das genauso versuchen wie das

Vor einigen Wochen habe ich in Phoscon Gruppen für meine Lichter erstellt und begonnen, diese Gruppen in HASS zu referenzieren.

Also habe ich endlich meine Schnüffelhardware bekommen und Wireshark ein wenig gehackt, um Namen für alle ieee802.15.4-Adressen anzuzeigen (was es viel einfacher macht zu lesen, was los ist).

Wie auch immer, mein Wissen über das ZigBee-Zeug ist nicht sehr stark, also stelle ich möglicherweise dumme Fragen. Ich habe jedoch einige Schnüffelprotokolle durchgesehen und hoffentlich können wir etwas sehen, das das schuppige Verhalten der Ikea-Lichter erklärt.

Siehe das Protokoll unten. Scheint das "normales" Verhalten zu sein? Beide beteiligten Lichter sind Ikea-Lichter. Zuerst sendet DeConz eine Anfrage an die 'Garage', die durch den 'Zolder' geleitet wird. Dann versucht 'Zolder' es an die 'Garage' zu übertragen, aber das scheint zu scheitern (Warum?) Und es wird 20 Mal in sehr schneller Folge wiederholt (die meisten sind innerhalb von 3 ms). Schließlich gibt 'Zolder' auf und sendet einen Verbindungsfehler zurück an DeConz.

Sollte es so aggressiv sein, wenn es darum geht, die Übertragung erneut zu versuchen?

Außerdem: Ich stelle fest, dass DeConz weiterhin gerne Anfragen über Zolder an Garage sendet, obwohl die Verbindung eindeutig fehlschlägt. DeConz tut dies sogar, wenn Garage nicht mehr im Link Status Report von Zolder enthalten ist. Auch wenn Garage manchmal im Verbindungsstatusbericht von Zolder enthalten ist, kostet es 7 sowohl eingehende als auch ausgehende Kosten. Eigentlich führt die Route von Garage nach DeConz nicht über Zolder ...
Warum leitet DeConz auch nach einer Link Failure-Nachricht weiter durch Zolder?

No.          Time         Source       Transmit Dev Receive Dev  Destination  Protocol     Info         
7580         748.356336   DeConz       DeConz       Zolder       Garage       ZigBee ZDP   Link Quality Request
7582         748.360218   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7583         748.363417   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7584         748.368857   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7585         748.373337   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7587         748.419739   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7588         748.424219   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7589         748.429019   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7590         748.434460   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7591         748.481181   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7592         748.485021   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7593         748.488541   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7594         748.492702   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7595         748.541983   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7596         748.545824   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7597         748.550944   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7598         748.556384   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7599         748.594786   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7600         748.597986   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7601         748.602787   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7602         748.608226   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7603         748.640867   Zolder       Zolder       DeConz       DeConz       ZigBee       Network Status, 0x9e0c: Non-tree Link Failure

Ok, ich habe einige Zeit damit verbracht, die ZigBee-Dokumentation zu Silabs zu lesen (die IKEAs basieren auf Silabs-Chips).
Anscheinend ist das Wiederholungsverhalten genau wie in den Dokumenten beschrieben.

Das lässt die Frage offen, warum DeConz darauf besteht, diese Route zu verwenden. Die Verbindungskosten sind hoch, es gibt eine Antwort auf einen Verbindungsfehler und dennoch wird diese Route verwendet. Warum..?
(und bessere Routen sind verfügbar ...)

Sehr nützliche Einblicke @djwlindenaar, obwohl ich Ihnen auf dieser Ebene nicht

Danach bin ich wieder zurück und denke, ich habe wieder schlechte Routen.

Eine andere Sache. Wie kommt es, dass deconz die Zustände festlegt, auch wenn das tatsächliche Gerät nicht reagiert? Es sieht so aus, als ob eine Glühbirne in den Schnittstellen eingeschaltet ist, aber physisch ist sie ausgeschaltet (immer noch mit Strom versorgt). Manchmal funktioniert es, um es wieder einzuschalten (über Software), manchmal funktioniert es mit dem Aus- und Wiedereinschalten, aber oft reagiert es auch nach einem Aus- und Wiedereinschalten überhaupt nicht. Dieselbe Glühbirne kann nach einer Weile plötzlich wieder reagieren

Etwas interessanteres Verhalten (ich zeige die gleichen Lichter, aber dies geschieht auch an anderen Stellen in meinem Netzwerk)

• DeConz sendet many-to-one route Route Request Pakete. Das Ergebnis ist, dass jedes Gerät zuerst eine Routenerkennung durchführt. Dies soll den Konzentrator (Koordinator) mit Informationen darüber versorgen, wie man dieses Gerät erreicht. Es scheint, dass DeConz diese Informationen für das Routing ignoriert ...

No.         Time        Source      Tran Dev    Recv Dev    Destination Protocol    Info
7544        747.873     DeConz      DeConz      Zolder      Garage      ZigBee ZDP  Link Quality Request
7546        747.876     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7547        747.882     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7548        747.887     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7549        747.892     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7550        747.919     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7551        747.925     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7552        747.929     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7553        747.932     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7554        747.980     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7555        747.985     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7556        747.990     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7557        747.995     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7558        748.046     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7559        748.052     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7560        748.055     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7561        748.061     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7563        748.066     Garage      Garage      Kerstver    DeConz      ZigBee      Route Record, Dst: 0x0000
7565        748.076     Garage      Kerstver    HK zoutlamp DeConz      ZigBee      Route Record, Dst: 0x0000
7567        748.084     Garage      HK zoutlamp DeConz      DeConz      ZigBee      Route Record, Dst: 0x0000

Das letzte Paket enthält Informationen darüber, wie Sie die Garage erreichen:

Command Frame: Route Record
    Command Identifier: Route Record (0x05)
    Relay Count: 2
    Relay Device 1: 0x731e[Kerstverli]
    Relay Device 2: 0xa3f5[HK zoutlam]

Aber die nächste Anfrage an Garage wird erneut über den Zolder gesendet

No.         Time        Source      Tran Dev    Recv Dev    Destination Protocol    Info
7569        748.112847  DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7570        748.117327  DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7573        748.126608  DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request

Es würde mich nicht wundern, dass dieses Verhalten etwas mit dem schuppigen IKEA-Lichtverhalten zu tun hat.

@manup , kannst du das kommentieren? Ihre Aussage, dass Source Routing helfen würde, ist sehr sinnvoll.
Alternativ erwarte ich, dass die Verwendung der Informationen aus dem Routendatensatz zum Aktualisieren der Routing-Tabelle von DeConz bereits eine enorme Verbesserung darstellt ...
Oder wir müssen herausfinden, warum DeConz weiterhin eine Route verwenden möchte, die Verbindungsprobleme meldet / im Vergleich zu einer Alternative hohe Routingkosten verursacht.

Eine weitere Beobachtung ... Die beiden Relaisgeräte im obigen Paket sind beide Xiaomi-Stecker. Sie werden niemals nach Linkqualität abgefragt. Warum?
Könnte es sein, dass DeConz die Informationen in der Link Quality Response verwendet, um seine Routentabelle zu erstellen, und daher die recht gültigen Router ignoriert? Mit guter Verbindungsqualität zu einigen meiner unglücklichen IKEA-Lichter ...

Sehen Sie dieses Verhalten nur für Ikea-Geräte oder ein allgemeines Verhalten, um die optimale Route zu ignorieren? Ich vermute, Sie haben eine anständige Anzahl von Ikea-Geräten?

Ich bin mir nicht sicher, ich müsste das überprüfen. Gute Frage.

Ich habe ziemlich viele Ikea-Lampen, ja.

In meinen Augen erklärt dies einen großen Teil des Verhaltens, das wir mit den nicht erreichbaren IKEA-Lichtern gesehen haben. Obwohl es vorerst nur Hypothesen gibt, die überprüft werden müssen.

Wenn ich in mehrere andere Routen schaue, sehe ich das gleiche Verhalten.

Ich sehe nur, dass die Xiaomi-Geräte nicht nach Link-Qualität abgefragt werden, wie es alle anderen Marken tun. Ich denke, das ist eine Art schwarze Liste ..?

Beispiel für ein anderes Routing-Verhalten:

Von DeConz immer:
DeConz --> WC Lamp --> Badkamer Ledstrip

Routenänderungen werden häufig nach einer Mehr-zu-Eins-Routenanforderung geändert. Beachten Sie, dass aus geografischer Sicht all dies sinnvoll ist ...
Badkamer Ledstrip --> WC Lamp --> DeConz
Badkamer Ledstrip --> Gang 1 --> DeConz
Badkamer Ledstrip --> Zoldertrap Lamp --> DeConz
Badkamer Ledstrip --> Gang 1 --> Zoldertrap Lamp --> DeConz

Für das Garagenlicht sehe ich von DeConz:
DeConz --> Zolder Noord Lamp --> Garage (sehr schuppige Route ..!)

Rückweg sehe ich:
Garage --> Kerstverlichting --> On/Off Light 36 --> DeConz
Garage --> Kerstverlichting --> HK Zoutlamp --> DeConz

Wenn ich mir nun die Tabelle in den Verbindungsstatusberichten ansehe, ist die Route über den Routen von Garage nach DeConz sinnvoll:
Garage --> Kerstverlichting --> On/Off Light 36 --> DeConz Gesamtkosten: 4
Garage --> Kerstverlichting --> HK Zoutlamp --> DeConz Gesamtkosten: 4

von DeConz nach Garage nicht:
DeConz --> Zolder Noord Lamp --> Garage Gesamtkosten: 12 (basierend auf den eingehenden Kosten von DeConz bis Zolder Noord Lamp)

@manup , könnten Sie den verwendeten

Noch etwas Analyse heute ...
In meinen vorherigen Beiträgen haben Sie gesehen, dass mein Garagenlicht durch mein Zolder-Licht geleitet wird. Beide IKEA Glühbirnen. Die Funkverbindung von Zolder nach Garage befindet sich direkt am Rande der Reichweite und fällt daher häufig aus.

Obwohl das Garagenlicht heute auf Gruppenbefehle reagiert, reagiert es heute nicht auf Unicast-Befehle. Eigentlich manchmal und manchmal nicht. Dies ist ein Verhalten, das denjenigen bekannt sein sollte, die diesen Thread gelesen / dazu beigetragen haben.

Ich kann dies in den Schnüffelprotokollen finden. Manchmal kann das Zolder-Licht mit Garage kommunizieren und manchmal nicht. Jedes Mal, wenn Zolder light nicht mit Garage kommunizieren kann, wird Folgendes gemeldet:

ZigBee Network Layer Command, Dst: DeConz, Src: Zolder No
    Frame Control Field: 0x1a09, Frame Type: Command, Discover Route: Suppress, Security, Destination, Extended Source Command
    Destination: 0x0000[DeConz]
    Source: 0xd6b7[Zolder Noo]
    Radius: 30
    Sequence Number: 65
    Destination: dresden-_ff:ff:00:c4:9a (00:21:2e:ff:ff:00:c4:9a)
    Extended Source: SiliconL_ff:fe:c3:4a:3e (00:0b:57:ff:fe:c3:4a:3e)
    ZigBee Security Header
    Command Frame: Network Status
        Command Identifier: Network Status (0x03)
        Status Code: Non-tree Link Failure (0x02)
        Destination: 0x9e0c[Garage]

Dieses Paket sollte DeConz anweisen, eine andere Route zu finden, um Garage zu erreichen, aber das passiert nicht. Das nächste an Garage gesendete Paket wird erneut über Zolder weitergeleitet. Für mich ist das ein Fehler, der behoben werden muss.
Dieses nächste Paket für Garage wird vom Zolder-Licht empfangen, aber dieses Licht versucht nicht einmal, es an die Garage zu senden. Möglicherweise ist dies ein Verhalten der IKEA-Firmware, das nicht gut ist, aber die Hauptursache des Problems ist die Weigerung von DeConz, eine alternative Route zu finden.
Ich denke, wenn eine Route für einen längeren Zeitraum nicht verfügbar ist, ist das Garagenlicht möglicherweise für ACKs auf einer höheren Ebene als das 802.15.4-Protokoll ausgehungert, was dazu führen kann, dass die Firmware getrennt wird oder sogar abstürzt. Und ich stimme zu, dass dies nicht der Fall sein sollte, aber das Hauptproblem ist, dass DeConz sich weigert, einen neuen Weg zum Garagenlicht zu finden.

Heute habe ich ein Experiment durchgeführt, um DeConz dazu zu bringen, einen anderen Weg zum Garagenlicht zu finden. Also habe ich das Stromnetz vom Zolder-Licht getrennt und mir die Schnüffelprotokolle angesehen. Nach einigen Versuchen stellt DeConz fest, dass Zolder verschwunden ist und sucht nach einer alternativen Route zu Garage. Als nächstes verbinde ich Zolder wieder und nachdem ich seine Anwesenheit auch für Zolder angekündigt habe, wird eine neue Route gefunden. DeConz kehrt (noch) nicht zum Routing von Garage durch Zolder zurück.

Lustige Sache ist, dass DeConz in der neuen Situation jetzt direkt mit Garage Light spricht, keine Router dazwischen.
Zolder wird jetzt über eine Route über 2 andere Router erreicht (obwohl es offensichtlich direkt von DeConz erreichbar war), so dass es für mich so aussieht, als ob eine Tabelle (Nachbartabelle?) In der DeConz-Routing-Firmware voll ist.

Vielleicht hängt dies mit der Weigerung zusammen, eine neue Route als Reaktion auf eine fehlerhafte Route zu erstellen.

@manup , ich würde mich über jeden Kommentar von Ihnen zu den oben genannten Beiträgen

Ich möchte helfen, eine Lösung für diese Probleme zu finden, da sie mich stören. Wenn Sie Zugriff auf den Firmware-Quellcode gewähren, kann ich direkt einen Beitrag leisten (auch wenn es sich nicht um Open Source handelt). Es macht mir nichts aus, Dresden Elektronik auf diese Weise zu helfen :)

Hervorragende Arbeit geleistet! 💪🏼
Ich hoffe, wir können die Aufmerksamkeit der Entwickler darauf lenken, dies zu beheben. Es sieht so aus, als hätten Sie ein gutes Setup und einen guten Prozess, sodass ein Fix ganz einfach überprüft werden kann.
Ich verstehe jetzt das Verhalten, das ich gesehen habe und das ich als "Selbstheilung" bezeichnet habe und warum einige Glühbirnen plötzlich funktionieren.

Gute Arbeit @manup kann sich das ansehen.

@manup irgendwelche Kommentare?

Vielen Dank für diesen Thread und die Arbeit. Ich habe selbst 20 ikea Bulb Update Firmware und ein Jahr alt. Ich hatte von Anfang an ein Einfrieren der Tropfen oder einen Glühbirnenverlust, aber nicht zu häufig. Mit späteren Deconz-Updates wurde es schlimmer. Ich habe mein Netzwerk überprüft und es in einer 2.4-gepackten Umgebung optimiert. Die Glühbirne fällt immer noch täglich aus und macht Tasten oder Sensoren unbrauchbar, da sie immer noch über diese Glühbirne geleitet werden und somit keine Datenbewegung senden. Ich muss das Gerät aus- und wieder einschalten, um die Sensoren wieder verfügbar zu machen, wenn die Lampen beginnen, sie wieder zu routen. Hoffentlich bekommt das mehr Aufmerksamkeit. Es ist frustrierend.

Eine weitere Beobachtung ... Die beiden Relaisgeräte im obigen Paket sind beide Xiaomi-Stecker. Sie werden niemals nach Linkqualität abgefragt. Warum?
Könnte es sein, dass DeConz die Informationen in der Link Quality Response verwendet, um seine Routentabelle zu erstellen, und daher die recht gültigen Router ignoriert? Mit guter Verbindungsqualität zu einigen meiner unglücklichen IKEA-Lichter ...

Die Abfrage der Nachbartabelle (auch bekannt als ZDP Mgmt_Lqi_req) wurde für Xiaomi-Geräte deaktiviert, da diese nach einer Weile nicht mehr auf diese Abfragen antworten, und ich vermutete, dass ein Fehler in der Firmware einen ungültigen oder schlimmeren Status auslösen könnte.

Daher besteht der Haupttreiber für die Begrenzung bestimmter Anforderungen darin, Fehler in der Firmware des Endgeräts zu vermeiden und das zugehörige Verhalten des Hersteller-Gateways genau nachzuahmen. Einige der Untersuchungsergebnisse finden Sie unter https://github.com/dresden-elektronik/deconz-rest -plugin / wiki / Endgeräte-Polling

Als Randnotiz werden die Abfragen der Nachbartabellen nur zum Erstellen der visuellen Netzpräsentation verwendet und haben keinen Einfluss auf den Netzwerkbetrieb oder die Routing-Tabellen.

Also habe ich endlich meine Schnüffelhardware bekommen und Wireshark ein wenig gehackt, um Namen für alle ieee802.15.4-Adressen anzuzeigen (was es viel einfacher macht zu lesen, was los ist).

Wie auch immer, mein Wissen über das ZigBee-Zeug ist nicht sehr stark, also stelle ich möglicherweise dumme Fragen. Ich habe jedoch einige Schnüffelprotokolle durchgesehen und hoffentlich können wir etwas sehen, das das schuppige Verhalten der Ikea-Lichter erklärt.

Siehe das Protokoll unten. Scheint das "normales" Verhalten zu sein? Beide beteiligten Lichter sind Ikea-Lichter. Zuerst sendet DeConz eine Anfrage an die 'Garage', die durch den 'Zolder' geleitet wird. Dann versucht 'Zolder' es an die 'Garage' zu übertragen, aber das scheint zu scheitern (Warum?) Und es wird 20 Mal in sehr schneller Folge wiederholt (die meisten sind innerhalb von 3 ms). Schließlich gibt 'Zolder' auf und sendet einen Verbindungsfehler zurück an DeConz.

Sollte es so aggressiv sein, wenn es darum geht, die Übertragung erneut zu versuchen?

Außerdem: Ich stelle fest, dass DeConz weiterhin gerne Anfragen über Zolder an Garage sendet, obwohl die Verbindung eindeutig fehlschlägt. DeConz tut dies sogar, wenn Garage nicht mehr im Link Status Report von Zolder enthalten ist. Auch wenn Garage manchmal im Verbindungsstatusbericht von Zolder enthalten ist, kostet es 7 sowohl eingehende als auch ausgehende Kosten. Eigentlich führt die Route von Garage nach DeConz nicht über Zolder ...
Warum leitet DeConz auch nach einer Link Failure-Nachricht weiter durch Zolder?

No.          Time         Source       Transmit Dev Receive Dev  Destination  Protocol     Info         
7580         748.356336   DeConz       DeConz       Zolder       Garage       ZigBee ZDP   Link Quality Request
7582         748.360218   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7583         748.363417   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7584         748.368857   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7585         748.373337   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7587         748.419739   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7588         748.424219   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7589         748.429019   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7590         748.434460   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7591         748.481181   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7592         748.485021   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7593         748.488541   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7594         748.492702   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7595         748.541983   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7596         748.545824   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7597         748.550944   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7598         748.556384   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7599         748.594786   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7600         748.597986   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7601         748.602787   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7602         748.608226   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7603         748.640867   Zolder       Zolder       DeConz       DeConz       ZigBee       Network Status, 0x9e0c: Non-tree Link Failure

Guter Fang! Hier würde ich vermuten, dass die deCONZ-Firmware diesen Fehler behandeln und erneut versuchen sollte, eine neue Route zu finden. Ich werde die Firmware überprüfen, ob und wie dieser Fall behandelt wird. Ich kann mir vorstellen, dass die Route tatsächlich verworfen wird, aber wenn eine neue Nachricht über dieselbe Route empfangen wird. Zum Beispiel wird der Eintrag aufgrund eines ZCL-Attributberichts aus dem Licht nur am Leben erhalten.

Routen können einfach durch Empfangen eines Befehls von einem eingehenden Frame eingerichtet werden. Aber wenn der letzte Hop den Hop nicht davor hält (was sie normalerweise tun), funktioniert der Rückweg durch denselben Hop nicht. Ihre Ergebnisse könnten genau diesen Fall widerspiegeln.

Vielen Dank.

In diesem Fall wird niemals eine Nachricht von der Garagenleuchte über Zolder empfangen. Daher würde ich nicht erwarten, dass DeConz die Route weiter benutzt. Siehe meine anderen Beiträge ...

Statuscode: Nicht-Baum-Verbindungsfehler (0x02)

Scheint, wir haben einen Gewinner, ich habe die ZigBee-Stack-Quelle (R21, ConBee II) überprüft und dieser Statuscode wird vollständig ignoriert. : -O Sie müssen auch den AVR ZigBee-Stapel überprüfen, wahrscheinlich das gleiche Problem.

Als Fix möchte ich diesen Code genauso behandeln, wie der Status "Keine Route verfügbar" behandelt wird. Dies dient lediglich dazu, den Routeneintrag freizugeben und den Stapel einen neuen herausfinden zu lassen.

Haben Sie auch ein vollständiges Paket des Befehls, der zuvor vom Koordinator an das IKEA-Licht gesendet wurde? Wäre interessant, wenn das Erkennungsroutenbit gesetzt wäre.

Hier ist der Abschnitt aus der ZigBee-Spezifikation, was in diesem speziellen Fall passieren sollte:

Beim Empfang eines Netzwerkstatus-Befehlsrahmens durch einen Router, der das beabsichtigte Ziel des Befehls ist, wobei das Statuscodefeld der Befehlsrahmen-Nutzdaten den Wert 0x01 oder 0x02 hat, was auf einen Verbindungsfehler hinweist, entfernt die NWK-Schicht den Routing-Tabelleneintrag Entspricht dem Wert des Zieladressfelds der Befehlsrahmen-Nutzdaten, falls vorhanden, und informiert die nächsthöhere Schicht über den Fehler mithilfe der NLME-NWK-STATUS.indication unter Verwendung des gleichen Statuscodes.

Das obige Update sollte hier für 0x02 funktionieren, 0x01 wird auch nicht behandelt. Ich werde das auch hinzufügen.

0x00 No Route Available  (already handled)
0x01 Tree Link Failure
0x02 Non Tree Link Failure

Tolles @manup! Sie haben die Conbee II erwähnt. Funktioniert dieses Update auch für den Conbee I?

Ja, ich habe nur die von ConBee I und RaspBee verwendeten Stapelquellen. Das gleiche Problem hier, ich werde neue Firmware-Versionen zum Testen bis Dienstag kochen. Es wäre cool, Feedback zu erhalten, wenn dies zumindest die IKEA-Routing-Probleme löst.

Beachten Sie, dass es auch andere Probleme gab, die dadurch nicht behoben werden können, wie z. B. IKEA-Lampen, die völlig leise werden und nicht einmal Gruppenbesetzungen hören.

Dieses Problem wurde versehentlich geschlossen ... Wiedereröffnet. Schön, dass wir hier Fortschritte machen.

Ich denke, @djwlindenaar ist derjenige, der in der Lage ist, Feedback zu geben, nachdem die neue Firmware verfügbar ist, weil die Sniffing-Hardware dafür benötigt wird?

Haben Sie auch ein vollständiges Paket des Befehls, der zuvor vom Koordinator an das IKEA-Licht gesendet wurde? Wäre interessant, wenn das Erkennungsroutenbit gesetzt wäre.

Ich bin mir nicht sicher, ob ich deine Frage verstehe. Welches Paket suchen Sie? Und zu welchem ​​Licht (Garage oder Zolder)?

Ja, ich habe nur die von ConBee I und RaspBee verwendeten Stapelquellen. Das gleiche Problem hier, ich werde neue Firmware-Versionen zum Testen bis Dienstag kochen. Es wäre cool, Feedback zu erhalten, wenn dies zumindest die IKEA-Routing-Probleme löst.

Beachten Sie, dass es auch andere Probleme gab, die dadurch nicht behoben werden können, wie z. B. IKEA-Lampen, die völlig leise werden und nicht einmal Gruppenbesetzungen hören.

Ich werde es auf jeden Fall testen. Obwohl es einige Zeit dauern kann, bis eine Schlussfolgerung gezogen wird, gibt es manchmal lange Zeit kein Problem ...

Ich dachte, dass es vielleicht etwas gibt, das dieses Verhalten auslöst, völlig still zu werden. Ich hatte dies letzte Woche, hatte aber noch keine Zeit, die Sniffer-Protokolle durchzugehen.

Ich bin übrigens auf Raspbee.

Ja, ich habe nur die von ConBee I und RaspBee verwendeten Stapelquellen. Das gleiche Problem hier, ich werde neue Firmware-Versionen zum Testen bis Dienstag kochen. Es wäre cool, Feedback zu erhalten, wenn dies zumindest die IKEA-Routing-Probleme löst.

Lassen Sie uns wissen, ich habe dieses Problem sehr oft und könnte es testen, obwohl ich nicht schnüffle.

Beachten Sie, dass es auch andere Probleme gab, die dadurch nicht behoben werden können, wie z. B. IKEA-Lampen, die völlig leise werden und nicht einmal Gruppenbesetzungen hören.

Beziehen Sie sich auf das Problem, dass die Software (deconz) einen Status meldet und einstellt, die Lampe selbst jedoch nicht reagiert oder den Status ändert? Vielleicht wäre das Problem nicht gleich schwerwiegend, wenn wir das Routing-Problem beheben würden.

Vielen Dank, dass Sie sich das angesehen haben, sehr geschätzt!

Ja, ich habe nur die von ConBee I und RaspBee verwendeten Stapelquellen. Das gleiche Problem hier, ich werde neue Firmware-Versionen zum Testen bis Dienstag kochen. Es wäre cool, Feedback zu erhalten, wenn dies zumindest die IKEA-Routing-Probleme löst.

Beachten Sie, dass es auch andere Probleme gab, die dadurch nicht behoben werden können, wie z. B. IKEA-Lampen, die völlig leise werden und nicht einmal Gruppenbesetzungen hören.

Danke manup! Ich werde in der Sekunde, in der es verfügbar ist, auf das neue fw upgraden und Updates bereitstellen.

Könnte dieses Problem auch mit dem Problem bei der Steuerung der Ikea Fyrtur-Jalousien zusammenhängen?

Ein anderer, der mir seltsam erscheint. @manup , könnte dies auch ein Problem sein?

Ich sehe viele solcher Sequenzen. Ich habe mich damit befasst, weil dies die letzte Mitteilung von houtlamp ist, bevor sie nicht mehr reagiert. DeConz konfiguriert zwei Attributberichtselemente und fordert fast gleichzeitig Gruppenmitgliedschaften an. In de DeConz-Protokollen sieht dies wie folgt aus.

Ich frage mich, ob es einen Fehler bei der Auswahl der Sequenznummer gibt oder ob er zulässig ist (ich weiß nicht) und dieses Verhalten einen Fehler in der Tradfri-Firmware auslöst. Es gibt eine Anfrage mit der Nummer 215 und zwei Anfragen mit der Nummer 216. Könnte es sein, dass wir eine Art Race-Bedingung haben, bei der die Behandlung der Anfragen durch die tradfri-Firmware dazu führt, dass der Speicher aufgrund der beiden Anfragen leckt oder auf andere Weise auflegt mit der gleichen Nummer fast zur gleichen Zeit? Soll DeConz zwei Anfragen mit derselben Sequenznummer haben?

13:09:40:905 Force read attributes for node HK houtlamp
13:09:40:905 binding for cluster 0x0000 of 0x000B57FFFEDBFE18 exists (verified by reporting)
13:09:40:905 binding for cluster 0x0006 of 0x000B57FFFEDBFE18 exists (verified by reporting)
13:09:40:905 configure reporting rq seq 215 for 0x000B57FFFEDBFE18, attribute 0x0006/0x0000
13:09:40:906 binding for cluster 0x0008 of 0x000B57FFFEDBFE18 exists (verified by reporting)
13:09:40:906 configure reporting rq seq 216 for 0x000B57FFFEDBFE18, attribute 0x0008/0x0000
13:09:40:906 Force binding of attribute reporting for node HK houtlamp
13:09:40:908 add task 7435258 type 21 to 0x000B57FFFEDBFE18 cluster 0x0004 req.id 233
13:09:41:013 Erase task req-id: 233, type: 21 zcl seqno: 216 send time 0, profileId: 0x0104, clusterId: 0x0004
13:09:41:053 ZCL configure reporting rsp seq: 215 0x000B57FFFEDBFE18 for cluster 0x0006 attr 0x0000 status 0x00
13:09:41:077 ZCL configure reporting rsp seq: 216 0x000B57FFFEDBFE18 for cluster 0x0008 attr 0x0000 status 0x00
13:09:41:116 verified group capacity: 255 and group count: 2 of LightNode 0x000b57fffedbfe18
13:09:41:116 0x000b57fffedbfe18 found group 0x0001
13:09:41:116 0x000b57fffedbfe18 found group 0xFFF0

Über Funk sieht das so aus: (Es sieht so aus, als würde ich nicht jedes Paket über Funk sehen, was seltsam ist, da sich der Schnüffler direkt neben der Himbeere befindet. Vielleicht werden sie so schnell gesendet, dass sie sich in einem Pufferüberlauf oder etwas anderem verlieren der Schnüffler)

No.          Source       Transmit Dev Receive Dev  Destination  Protocol     Info
2196482      DeConz       HK zoutlamp  HK houtlamp  HK houtlamp  ZigBee HA    ZCL: Configure Reporting, Seq: 215
2196484      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       Route Record, Dst: 0x0000
2196486      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       Route Record, Dst: 0x0000
2196488      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       Route Record, Dst: 0x0000
2196490      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       Route Record, Dst: 0x0000
2196492      DeConz       DeConz       HK zoutlamp  HK houtlamp  ZigBee HA    ZCL Groups: Get Group Membership, Seq: 216
2196494      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee HA    ZCL: Configure Reporting Response, Seq: 215
2196496      DeConz       HK zoutlamp  HK houtlamp  HK houtlamp  ZigBee HA    ZCL Groups: Get Group Membership, Seq: 216
2196497      DeConz       DeConz       HK zoutlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196498      DeConz       DeConz       HK zoutlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196500      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196502      DeConz       HK zoutlamp  HK houtlamp  HK houtlamp  ZigBee HA    ZCL Groups: Get Group Membership, Seq: 216
2196504      DeConz       HK zoutlamp  HK houtlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196506      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       Route Record, Dst: 0x0000
2196508      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee HA    ZCL: Configure Reporting Response, Seq: 216
2196510      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196511      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196512      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196513      DeConz       DeConz       HK zoutlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196515      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196517      DeConz       HK zoutlamp  HK houtlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196519      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee HA    ZCL Groups: Get Group Membership Response, Seq: 216
2196521      DeConz       DeConz       HK zoutlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196523      DeConz       HK zoutlamp  HK houtlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1

In der Tat sollten die Sequenznummern in dieser kurzen Zeit nicht gleich sein. Ich werde den Code überprüfen. Es sieht so aus, als ob ein Inkrement fehlt.

Hier ist die erste Test-Firmware für ConBee II

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_R21_0x26520700.bin.GCF

Die Portierung in die ConBee I / RaspBee-Firmware wird in Kürze online sein.

Und hier ist die Testversion für ConBee I und RaspBee mit der Routenfehlerbehebung.
Ich hoffe, es bringt einige Verbesserungen, um eine neue Route zu entdecken, wenn der Fehler auftritt.

Zum Testen denke ich, dass es gut wäre, wenn es nur ein paar Tage / Wochen läuft und wir werden sehen, ob die Lichter immer noch nicht mehr auf Unicasts reagieren. In diesem Fall versuchen Sie bitte, ob die Lichter noch auf Gruppenbefehle reagieren oder ganz still sind.

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26340500.bin.GCF

Zum Testen denke ich, dass es gut wäre, wenn es nur ein paar Tage / Wochen läuft und wir werden sehen, ob die Lichter immer noch nicht mehr auf Unicasts reagieren. In diesem Fall versuchen Sie bitte, ob die Lichter noch auf Gruppenbefehle reagieren oder ganz still sind.

Wenn es auf Gruppenbefehle reagiert, warten Sie einige Tage, um sicherzustellen, dass es weiterhin auf Gruppenbefehle reagiert. In meinem Fall, wenn Lichter nur auf Gruppenbefehle reagieren, werden sie früher oder später völlig still.

Wenn es auf Gruppenbefehle reagiert, warten Sie einige Tage, um sicherzustellen, dass es weiterhin auf Gruppenbefehle reagiert. In meinem Fall, wenn Lichter nur auf Gruppenbefehle reagieren, werden sie früher oder später völlig still.

Ich habe das auch in der Vergangenheit gesehen, vielleicht tun sie das, da keine Unicasts mehr empfangen werden, wird die Zeit zeigen.

@manup Könnte dieses Problem zusammenhängen? https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1657

Vielleicht ja, zumindest würde der erreichbare Zustand auch falsch werden, wenn die Route unterbrochen wird. Dies kann aber auch andere Gründe haben.

Ich habe festgestellt, dass es für einige Ikea-Lampen eine neuere Firmware gibt. Das Änderungsprotokoll gibt eine Verbesserung der Netzwerk- / Konnektivitäts- und Fehlerverwaltung an. Ich aktualisiere 20 Glühbirnen ... ich werde Updates bereitstellen, wenn hilfreich.

https://ww8.ikea.com/ikeahomesmart/releasenotes/releasenotes.html

Schade, dass es keine Veröffentlichungstermine enthält ...

https://ww8.ikea.com/ikeahomesmart/releasenotes/releasenotes.html

Schade, dass es keine Veröffentlichungstermine enthält ...

Es scheint veröffentlicht zu werden, da ich die in den Versionshinweisen beschriebene Firma 2.3.007 herunterladen konnte.

Muss im Januar gewesen sein https://www.iphone-ticker.de/ikea-home-smart-homekit-und-bridge-update-verfuegbar-152574/

kein Programmierer sie. Ich denke, ich sollte r21 nicht auf conbee 2 installieren und warten? Dies ist eine Beta-Firmware?

Etwas abseits des Themas: auch neue Firmware für den Trådfri-Dimmer, die auf ZB3 aktualisiert wird. Querverweis Nr. 2485, wir haben das gleiche Problem für den Dimmer ... Ich erwarte, dass der alte Bewegungssensor des Modells als nächstes kommt ...

Und hier ist die Testversion für ConBee I und RaspBee mit der Routenfehlerbehebung.
Ich hoffe, es bringt einige Verbesserungen, um eine neue Route zu entdecken, wenn der Fehler auftritt.

Zum Testen denke ich, dass es gut wäre, wenn es nur ein paar Tage / Wochen läuft und wir werden sehen, ob die Lichter immer noch nicht mehr auf Unicasts reagieren. In diesem Fall versuchen Sie bitte, ob die Lichter noch auf Gruppenbefehle reagieren oder ganz still sind.

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26340500.bin.GCF

Danke, @manup , habe es gerade installiert. Mal sehen, was es bringen wird.

Obwohl ich davon ausgehe, dass sich dies verbessern wird, wie denken Sie, dass die DeConz-Firmware die aufgezeichneten Routen ignoriert (aufgrund des Mane-to-One-Routings)? Im Allgemeinen habe ich gesehen, dass die aufgezeichneten Routen viel logischer sind als die von der DeConz-Firmware verwendeten.
Obwohl ich mir vorstellen kann, dass das Aktivieren des Quellroutings eine große Aufgabe ist, könnte (sollte?) Die DeConz-Firmware die Informationen aus dem Routendatensatzpaket weiterhin verwenden, um den ersten Hop auf ein Gerät zu aktualisieren. Überprüfen Sie möglicherweise einfach, ob der letzte Sprung zum Koordinator mit dem übereinstimmt, was in der Routing-Tabelle gespeichert ist, und machen Sie den Eintrag in der Routing-Tabelle ungültig, wenn nicht. Ich bin nicht sicher, ob es in Ordnung ist, den Eintrag durch den letzten Sprung von der aufgezeichneten Route zu ersetzen, da die Geräte auf dem Weg die Informationen wahrscheinlich ignorieren, aber zumindest eine neue Routenerkennung für diesen Knoten durch die DeConz-Firmware initiieren könnten.

Was denkst du darüber?

Ich habe die Firmware auf meiner Raspbee installiert (ich habe 73 Knoten, meistens Ikea), wird die Ergebnisse zurückmelden.

In der Tat sollten die Sequenznummern in dieser kurzen Zeit nicht gleich sein. Ich werde den Code überprüfen. Es sieht so aus, als ob ein Inkrement fehlt.

@manup , Vielleicht, um Ihnen zu helfen, das Problem zu lokalisieren, habe ich dieses Problem heute wieder gesehen. Es scheint im Zusammenhang mit 2 Konfigurieren von Berichtsaktionen zu stehen, die sehr nahe beieinander liegen. Die zweite Sequenz: 183 ist in diesem Fall eine andere als die, über die ich zuvor berichtet habe.

No.             Source          Transmit Dev    Receive Dev     Destination     Protocol        Info
39174           DeConz          DeConz          Gang 1          Gang 1          ZigBee HA       ZCL: Configure Reporting, Seq: 182
39180           DeConz          DeConz          Gang 1          Gang 1          ZigBee HA       ZCL: Configure Reporting, Seq: 183
39227           DeConz          DeConz          On/Off light 36 Badkamer ledstr ZigBee HA       ZCL: Read Attributes, Seq: 183

Das Problem mit der Sequenznummer sollte in 2.05.74 behoben sein, das gerade erstellt wird und in wenigen Stunden verfügbar sein wird.

https://github.com/dresden-elektronik/deconz-rest-plugin/commit/33d8a8b349c9f4967e8b94ed2657e038406317c8

Und hier ist die Testversion für ConBee I und RaspBee mit der Routenfehlerbehebung.
Ich hoffe, es bringt einige Verbesserungen, um eine neue Route zu entdecken, wenn der Fehler auftritt.
Zum Testen denke ich, dass es gut wäre, wenn es nur ein paar Tage / Wochen läuft und wir werden sehen, ob die Lichter immer noch nicht mehr auf Unicasts reagieren. In diesem Fall versuchen Sie bitte, ob die Lichter noch auf Gruppenbefehle reagieren oder ganz still sind.
http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26340500.bin.GCF

Danke, @manup , habe es gerade installiert. Mal sehen, was es bringen wird.

Obwohl ich davon ausgehe, dass sich dies verbessern wird, wie denken Sie, dass die DeConz-Firmware die aufgezeichneten Routen ignoriert (aufgrund des Mane-to-One-Routings)? Im Allgemeinen habe ich gesehen, dass die aufgezeichneten Routen viel logischer sind als die von der DeConz-Firmware verwendeten.
Obwohl ich mir vorstellen kann, dass das Aktivieren des Quellroutings eine große Aufgabe ist, könnte (sollte?) Die DeConz-Firmware die Informationen aus dem Routendatensatzpaket weiterhin verwenden, um den ersten Hop auf ein Gerät zu aktualisieren. Überprüfen Sie möglicherweise einfach, ob der letzte Sprung zum Koordinator mit dem übereinstimmt, was in der Routing-Tabelle gespeichert ist, und machen Sie den Eintrag in der Routing-Tabelle ungültig, wenn nicht. Ich bin nicht sicher, ob es in Ordnung ist, den Eintrag durch den letzten Sprung von der aufgezeichneten Route zu ersetzen, da die Geräte auf dem Weg die Informationen wahrscheinlich ignorieren, aber zumindest eine neue Routenerkennung für diesen Knoten durch die DeConz-Firmware initiieren könnten.

Was denkst du darüber?

Hmm seltsam, die Firmware sollte diese Routendatensätze bereits verwenden, um neue Routen einzurichten. Sie müssen den Code hier überprüfen, aber wenn mein Speicher mich richtig bedient, wurde dies vor einiger Zeit aktiviert.

Was denkst du darüber?

Hmm seltsam, die Firmware sollte diese Routendatensätze bereits verwenden, um neue Routen einzurichten. Sie müssen den Code hier überprüfen, aber wenn mein Speicher mich richtig bedient, wurde dies vor einiger Zeit aktiviert.

Nun, ich habe dieses Zeug mit Zolder und Garage (von einer Reihe von Posts zurück) in Gang gebracht und ich habe dieses Verhalten bekommen:

No.             Source          Transmit Dev    Receive Dev     Destination     Protocol        Info
163778          Garage          Kerstverlicht   DeConz          DeConz          ZigBee          Route Record, Dst: 0x0000
163779                                                                          IEEE 802.15.4   Ack

Der Streckenrekord zeigte:

Command Frame: Route Record
    Command Identifier: Route Record (0x05)
    Relay Count: 1
    Relay Device 1: 0x731e[Kerstverli]

Die nächste Mitteilung von DeConz an Garage lautet:

No.             Source          Transmit Dev    Receive Dev     Destination     Protocol        Info
163788          DeConz          DeConz          Zolder          Garage          ZigBee          APS: Ack, Dst Endpt: 0, Src Endpt: 0

Es übernimmt also eindeutig nicht die Streckenaufzeichnungen.

Was mir zu diesem Zeitpunkt auffiel, war, dass DeConz sofort in der Lage war, eine neue Route zu finden, sobald ich Zolder abschaltete. Vielleicht sind einige der Routing-bezogenen Tabellen in der DeConz-Firmware voll. Könnte das wahr sein? Wie groß sind die Nachbar- / Routing-Tabellen in der Firmware? Könnte eine vollständige Tabelle die Übernahme neuer Routenaufzeichnungen blockieren?

Erfolg! Ich kann bestätigen, dass das Verhalten jetzt so ist, dass nach einem Nicht-Baumverbindungsfehler die Routenerkennung tatsächlich beginnt.

No.             Source          Transmit Dev    Receive Dev     Destination     Protocol        Info
173142          DeConz          Buiten - R sch  Tuin rechtsach1 Tuin rechtsach1 ZigBee ZDP      Bind Request, Basic (Cluster ID: 0x0000) Src: SiliconL_ff:fe:16:47:5f, Dst: dresden-_ff:ff:00:c4:9a
173143          Buiten - R sch  Buiten - R sch  DeConz          DeConz          ZigBee          Network Status, 0x35b7: Non-tree Link Failure
173144                                                                          IEEE 802.15.4   Ack
173206          DeConz          DeConz          Broadcast       Broadcast       ZigBee          Route Request, Dst: 0x35b7, Src: 0x0000

Das Problem mit der Sequenznummer sollte in 2.05.74 behoben sein, das gerade erstellt wird und in wenigen Stunden verfügbar sein wird.

33d8a8b

"swversion": "2.5.74",

: smile: Danke @manup tolle Antwortzeit: 1st_place_medal:

Bitte warten Sie auf das Update auf 2.05.74 oder verwenden Sie http://phoscon.de/app , um die Phoscon App anzuzeigen. Wir haben gerade gesehen, dass eine Gateway-Offline-Seite auf einigen Seiten angezeigt wird, auf denen dies nicht der Fall sein sollte. Die Neuerstellung erfolgt jetzt ca. 2 Stunden.

In der Tat sollten die Sequenznummern in dieser kurzen Zeit nicht gleich sein. Ich werde den Code überprüfen. Es sieht so aus, als ob ein Inkrement fehlt.

Hier ist die erste Test-Firmware für ConBee II

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_R21_0x26520700.bin.GCF

Die Portierung in die ConBee I / RaspBee-Firmware wird in Kürze online sein.

Diese FW funktioniert bei mir nicht. Es zeigt alle meine Geräte als verbunden an, aber es wird kein Netz erstellt. Weder werden die Verbindungen in der GUI angezeigt, noch funktionierte ein Wechsel von Phoscon (2.05.74). Der Conbee II wurde auf 264A0700 zurückgesetzt und alles funktioniert wieder wie erwartet ...

Hmm seltsam wie lange hat es gedauert?
Ich führe diese Firmware jetzt auf mehreren Setups ohne Probleme aus.

Hmm seltsam wie lange hat es gedauert?
Ich führe diese Firmware jetzt auf mehreren Setups ohne Probleme aus.

Ein paar Minuten. Ich habe einige Aktivitäten auf einigen Geräten gesehen (blaue Punkte), aber keine Links aufgebaut. Und das Umschalten hat überhaupt nicht funktioniert. Soll ich länger testen?

Es kann eine Weile dauern, bis das Netz aufgebaut ist, aber Sie sollten nach 5 bis 10 Minuten Linien sehen.

Diese FW funktioniert bei mir nicht.

Gleich hier Rasperry Pi 4B, deCONZ 2.05.74, ConBee II. Kleines Testnetzwerk mit Trådri-Repeater, Trådfri-Stecker, XBee, Trådfri-Dimmer, 2 Trådfri-Bewegungssensoren (alt und neu) und Trådri-Ein / Aus-Schalter. Das Gateway scheint von keinem Gerät Datenverkehr zu senden oder zu empfangen. Im Syslog werden USB-Trennungen angezeigt. Nach dem Zurückblitzen auf 4A ist alles wieder gut gelaunt.
log.gz

Einfach nochmal geflasht um zu testen:

• Keine Zeilen in der GUI (15 Minuten laufen lassen)
• Die USB-Verbindung scheint stabil zu sein
• Die Schalter UBISYS C4 und D1 funktionieren weiterhin
• Tradfri Buttons nicht

@ebaauw Das Protokoll zeigt, dass der Koordinator mit dieser Version nur zwei Nachbarn sieht.

Vielleicht ist es die Netzwerkgröße. Ich habe derzeit nur 40 Geräte hier mit Strom versorgt. Diese Firmware-Version hat zwei weitere Änderungen, die die Ursache sein könnten, eine erhöhte Nachrichtenpuffergröße (etwas übertrieben, soweit ich das beurteilen kann, wird dies wieder reduzieren) und eine etwas niedrigere TX-Leistungseinstellung.

Ich werde eine andere Version vorbereiten, bei der diese Einstellungen entfernt wurden, um zu sehen, ob dies besser funktioniert.

Verwenden Sie ein USB-Verlängerungskabel oder ist der ConBee II direkt angeschlossen?

Für mich funktioniert es gut auf Raspbee ...

Bei RaspBee und ConBee 1 ist in der neuen Version nur der Route Fix enthalten (andere Firmware).

Das Protokoll zeigt, dass der Koordinator mit dieser Version nur zwei Nachbarn sieht.

Ja, zwei der Endgeräte wurden in der GUI als Nachbarn angezeigt. Ein bisschen seltsam, weil sie nach dem Downgrade der ConBee II-Firmware eine Verbindung zu einem anderen Router zeigten.

Verwenden Sie ein USB-Verlängerungskabel oder ist der ConBee II direkt angeschlossen?

Es ist direkt verbunden, seit ich es habe. An einen USB-2-Anschluss am Pi, wobei der XBee an den anderen USB-2-Anschluss angeschlossen ist; nichts auf USB-3. Die Verbindung war stabil, außer als ich den ConBee II als Router konfiguriert habe (siehe # 2463).

Bei RaspBee und ConBee 1 ist in der neuen Version nur der Route Fix enthalten (andere Firmware).

Hab das noch nicht ausprobiert. Muss bis später warten ...

Ich sehe ziemlich viele konfigurierte Berichtspakete. Nach einigem Suchen scheint es, dass diese regelmäßig etwa jede halbe Stunde gesendet werden. Was ist der Grund, warum diese konfigurierten Berichtsanforderungen regelmäßig wiederholt werden?
@ebaauw , erinnere ich mich richtig, dass Sie viele dieser Untersuchungen zum Verhalten des IKEA-Koordinators durchgeführt haben? Tut es das auch?

Ich habe es in de_web_plugin_private.h bemerkt

#define IDLE_ATTR_REPORT_BIND_LIMIT 1800

Ich fand einen weiteren Beweis für das Routing-Verhalten von DeConz, bei dem die Viele-zu-Eins-Routendatensätze ignoriert wurden. Dies führt dazu, dass einige Router das Routing auf "altmodische" Weise herausfinden müssen.
(Beachten Sie, dass ich in Paket 117130 eine teuflische Störung habe: zwinker :)

Die Route für badkamer ledstrip beginnt laut DeConz mit dem On/Off light 36 der offensichtlich nicht weiß, wie er dorthin kommt. Also startet es eine Routenerkennung und findet schließlich heraus, dass es (kaum, glaube ich) das ledstrip selbst erreichen kann. Der Rückweg führt über Gang 1

Es sieht so aus, als ob On/Off light 36 jedes Mal, wenn eine Route-Anfrage von vielen zu eins verarbeitet wird, Badkamer ledstrip On/Off light 36 vergisst ...

No.               Source            Transmit Dev      Receive Dev       Destination       Protocol          Info
177114            DeConz            DeConz            On/Off light 36   Badkamer ledstrip ZigBee HA         ZCL: Read Attributes, Seq: 55
177115                                                                                    IEEE 802.15.4     Ack
177116            On/Off light 36   On/Off light 36   Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177117            On/Off light 36   HK plafond ledstrip                 Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177118            On/Off light 36   HK zoutlamp       Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177119            On/Off light 36   Zoldertrap Lamp   Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177120            On/Off light 36   Kerstverlichting  Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177121            On/Off light 36   HK stalamp        Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177122            On/Off light 36   DeConz            Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177123            On/Off light 36   HK houtlamp 2     Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177124            On/Off light 36   Keuken links      Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177125            On/Off light 36   Keuken Rechts     Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177126            On/Off light 36   HK houtlamp       Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177127            On/Off light 36   Keuken mid        Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177128            On/Off light 36   Tuin linksvoor 2  Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177129            On/Off light 36   WC lamp           Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177130            0x6666            0x6666            0x6666            0x6666            IEEE 802.15.4     Data, Dst: 0x6666, Src: 0x6666, Bad FCS
177131            On/Off light 36   Gang 1            Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177132            On/Off light 36   Hal lamp          Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177133            DeConz            On/Off light 36   Badkamer ledstrip Badkamer ledstrip ZigBee HA         ZCL: Read Attributes, Seq: 55
177134                                                                                    IEEE 802.15.4     Ack
177135            Badkamer ledstrip Badkamer ledstrip Gang 1            DeConz            ZigBee            Command, Dst: DeConz, Src: Badkamer , Bad FCS
177136                                                                                    IEEE 802.15.4     Ack
177137            On/Off light 36   Voordeur          Broadcast         0xfcfd            ZigBee            Command, Dst: 0xfcfd, Src: On/Off li, Bad FCS
177138            Badkamer ledstrip Gang 1            DeConz            DeConz            ZigBee            Route Record, Dst: 0x0000

nächste Mitteilung:

No.               Source            Transmit Dev      Receive Dev       Destination       Protocol          Info
177366            DeConz            DeConz            On/Off light 36   Badkamer ledstrip ZigBee HA         ZCL: Read Attributes, Seq: 58

Ein weiterer Versuch mit der ConBee II-Firmware:

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26530700.bin.GCF

Diese Version hat die Sendeleistungseinstellungen von 0x264a0700. Die Puffer sind immer noch groß (aber laut Karte sollten sie gut in den RAM passen), um jeweils nur eine Sache zu überprüfen.

Ich habe diesen Fehler jedes Mal erhalten, wenn ich versuche, auf die neueste Firmware zu aktualisieren. Irgendwelche Hinweise warum?
rich710 @ RichHassPc01 : ~ $ sudo GCFFlasher_internal -d / dev / ttyACM1 -f deCONZ_ConBeeII_0x26530700.bin.GCF
GCFFlasher V3_13 (c) dresden elektronik ingenieurtechnik gmbh
Starten Sie das Gerät / dev / ttyACM1 (ConBee II) neu.
deCONZ Firmware-Version 26490700
R21B18 Bootloader
Vers: 2.05
Bau: 22. März 2019
blinkende 161378 Bytes: | ============================== |
überprüfen :.
Flash-Update fehlgeschlagen, ungültiger CRC. Bitte versuche es erneut.
rich710 @ RichHassPc01 : ~ $

Haben Sie die MD5-Summe der heruntergeladenen Datei überprüft? (http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26530700.bin.GCF.md5)

Ja, ich habe mehrmals überprüft und heruntergeladen und sogar versucht, auf alte Firmware zurückzugreifen, und es lief bis jetzt gut. Jetzt stecke ich mit diesem Fehler fest. Ich habe meinen NUC mehrmals neu gestartet, aber ich stecke immer noch fest, wenn Flasher versucht, meinen ConbeeII neu zu starten.
rich710 @ RichHassPc01 : ~ $ sudo GCFFlasher_internal -d / dev / ttyACM1 -f deCONZ_ConBeeII_0x26490700.bin.GCF
[sudo] Passwort für rich710:
GCFFlasher V3_13 (c) dresden elektronik ingenieurtechnik gmbh
Starten Sie das Gerät / dev / ttyACM1 (ConBee II) neu.

2139: Fehler: Uart-Reset fehlgeschlagen, Wiederholungsversuch überprüfen

Beachten Sie, dass Sie ttyACM1 verwenden, wenn Sie verwenden

GCFFlasher -l

Es wird die Seriennummer angezeigt.
Sie können es verwenden, um einen stabileren Gerätenamen im Befehl anzugeben.

GCFFlasher_internal -sn DE1948474 -f deCONZ_ConBeeII_0x26530700.bin.GCF

(durch die Seriennummer Ihres Geräts ersetzen)

Entschuldigung, es hat nicht funktioniert, vielleicht sollte ich es auf meinen Windows-Computer verschieben und es versuchen
rich710 @ RichHassPc01 : ~ $ GCFFlasher_internal -l
GCFFlasher V3_13 (c) dresden elektronik ingenieurtechnik gmbh
Pfad | Anbieter | Produkt | Seriennummer | Art
----------------- + -------- + --------- + ------------ + -------
/ dev / ttyACM1 | 0x1CF1 | 0x0030 | DE1964163 | ConBee II
/ dev / ttyUSB0 | 0x0403 | 0x6001 | A1YV35M2 | Generisches FTDI
rich710 @ RichHassPc01 : ~ $ GCFFlasher_internal -sn DE1964163 -f deCONZ_ConBeeII_0x26530700.bin.GCF
GCFFlasher V3_13 (c) dresden elektronik ingenieurtechnik gmbh
Gerät neu starten (ConBee II)

2139: Fehler: Uart-Reset fehlgeschlagen, Wiederholungsversuch überprüfen
rich710 @ RichHassPc01 : ~ $

Entweder das oder alternativ können Sie Folgendes versuchen:

• Trennen Sie den ConBee II vom Stromnetz
• GCFFlasher_internal -t 60 -sn DE1964163 -f deCONZ_ConBeeII_0x26530700.bin.GCF
• Stecken Sie den ConBee II erneut ein

Mit den Parametern -t versucht der GCFFlasher eine Minute lang, das Update zu verarbeiten.

Es funktionierte, um die Firmware in Windows zu aktualisieren, und als ich sie mit Ubuntu wieder in meinen NUC steckte, wurde sie verbunden. ABER nach einer Stunde hat es gerade eine Verbindung zu 4 meiner Knoten hergestellt ..: S.

Ein weiterer Versuch mit der ConBee II-Firmware: http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26530700.bin.GCF

Keine USB-Verbindung mehr, aber deCONZ scheint den ConBee II ziemlich oft wieder zu erkennen. Immer noch kein Verkehr.
log.gz

BEARBEITEN Um Sie zu unterhalten, habe ich den XBee getrennt und ein 10 cm langes USB-Verlängerungskabel verwendet, um den ConBee II anzuschließen: keine Änderung.

Ein weiterer Versuch mit der ConBee II-Firmware:

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26530700.bin.GCF

Diese Version hat die Sendeleistungseinstellungen von 0x264a0700. Die Puffer sind immer noch groß (aber laut Karte sollten sie gut in den RAM passen), um jeweils nur eine Sache zu überprüfen.

Sie haben Ihre neue Version getestet, aber nach 10 Minuten wird immer noch kein Link angezeigt ... Mit der stabilen FW werden alle guten (Router-) Links im Netzwerk nach ca. 2 Minuten angezeigt. Der IKEA-Druckknopf funktioniert sofort, während er mit der Test-Firmware überhaupt nicht funktioniert.

Hmm gruselig, danke, dass du das getestet hast. Als nächstes werde ich versuchen, die Puffergrößen wie zuvor erwähnt zu verringern.
Trotzdem frage ich mich, warum es bei meinem Setup funktioniert. Aus dem obigen Screenshot kann ich nur erkennen, dass ich mehr Endgeräte als Router habe.

@manup hatte die gleichen Probleme nach dem

Und hier ist die Testversion für ConBee I und RaspBee mit der Routenfehlerbehebung.

Scheint auf meinem Pi 3B + Testsystem einwandfrei zu laufen. Ich werde bis zu diesem Wochenende warten, bevor ich mein Produktionsnetzwerk aktualisiere.

@ebaauw , erinnere ich mich richtig, dass Sie viele dieser Untersuchungen zum Verhalten des IKEA-Koordinators durchgeführt haben? Tut es das auch?

Ich habe Unterstützung für die meisten Trådfri-Geräte hinzugefügt, konnte jedoch keinen ZigBee-Verkehr zum / vom Trådfri-Hub abhören. Es wird nur die Touchlink-Kopplung verwendet, und ich muss noch versuchen, diese zu erfassen, um den Netzwerkschlüssel wiederherzustellen. Vorausgesetzt, es ist überhaupt möglich.

Ich habe die neue FW auf dem Conbee 1-Stick in meinem ~ 40-Knoten-Setup seit der Veröffentlichung der neuen Firmware ausgeführt und sie hat ohne Probleme hervorragend funktioniert ! (In der Abbildung sind die nicht angeschlossenen Knoten entweder leer oder nicht mit Strom versorgt.)

Vielen Dank an alle Beteiligten, die den Code behoben und aktualisiert haben. Es wird so geschätzt! <3

Ich arbeite nicht für mich. Fast keine Anschlüsse im Netz. Habe ca. 20 min nach dem Neustart gewartet.

Himbeer Pi 3 Modell B Rev 1.2
Conbee II
Version 2.05.74
Version 26530700

77 Knoten

3 Verbindung zu
1 TRÅDFRI Ein / Aus-Schalter
1 Xiaomi Multisensor
1 Philips Dimmer
Ich kann Ereignisse über den Philips-Dimmer auslösen.
Diese, die Verbindungen haben, befinden sich ziemlich nahe am Conbee-Stick. Der Stock befindet sich in der Garage. Ich habe einige Glühbirnen in der Garage, die keine Verbindungen haben.

Keine Verbindung zu
Viele Ikea-Lampen, sowohl E27 als auch GU10
Viele Xiaomi Multisensoren
Viel Ikea TRÅDFRI Fernbedienung
Und andere Knoten.

Protokolle
27. Februar 09:29:06 raspberrypi systemd [1]: deCONZ gestartet: ZigBee-Gateway - GUI / REST-API.
27. Februar 09:29:06 raspberrypi deCONZ [7204]: libEGL-Warnung: DRI2: Authentifizierung fehlgeschlagen
27. Februar 09:29:06 raspberrypi deCONZ [7204]: libpng Warnung: iCCP: Bekanntes falsches sRGB-Profil

Beim Downgrade auf 264A0700 wird das Netz direkt erstellt.

@ebaauw , erinnere ich mich richtig, dass Sie viele dieser Untersuchungen zum Verhalten des IKEA-Koordinators durchgeführt haben? Tut es das auch?

Ich habe Unterstützung für die meisten Trådfri-Geräte hinzugefügt, konnte jedoch keinen ZigBee-Verkehr zum / vom Trådfri-Hub abhören. Es wird nur die Touchlink-Kopplung verwendet, und ich muss noch versuchen, diese zu erfassen, um den Netzwerkschlüssel wiederherzustellen. Vorausgesetzt, es ist überhaupt möglich.

Richtig, sorry. Hätte git Schuld überprüfen sollen. Der Code, der das Verhalten des IKEA-Gateways erwähnt, wurde tatsächlich in 48d2c39a267b5c6d025577eed7530be27932aa2c von @manup ... eingeführt.

@manup , haben Sie tatsächlich

Conbee I wurde auf Beta FW und deCONZ .74 aktualisiert

Mesh baut sich sofort auf und sieht wirklich gut aus!

Vielen Dank an natürlich danke auch

Conbee I und .74 auch. Ikea FW wurde auf 2.3.007 aktualisiert (einige andere 2.x).
Große Verbesserung! Noch keine Aussetzer!

Ein großes Dankeschön an alle, die in diesem Thread und darüber hinaus Beiträge geleistet, entwickelt, debuggt und getestet haben.

Dabei habe ich etwas herausgefunden:
Das normale Ein- und Ausschalten der Gruppe funktioniert schnell, aber nach dem Abrufen einer Szene (nach dem Einblenden) und dem erneuten Ausschalten (<10 Sekunden) gehen die Lichter nur in der GUI aus (unabhängig von der alten oder neuen Benutzeroberfläche). Einige von ihnen werden dann wieder eingeschaltet (in der GUI) in der Gruppe, während ALLE physischen Glühbirnen noch eingeschaltet sind. Nach einem zweiten oder dritten Drücken werden sie manchmal dunkel.

Es ist nicht ungewöhnlich, Szenen nach einem Firmware-Upgrade wiederherzustellen / neu zu erstellen
Unabhängig davon, ob ich eine neue Szene erstelle oder versuche, eine ältere zu reparieren, bleibt das Verhalten gleich. Normales Ein-Aus ist nicht betroffen.

Ich fand heraus, dass es wie gewohnt funktioniert, wenn ich etwas länger warte. Sagen wir 15-20 Sekunden. Dann gehen die Lichter wie gewohnt aus. Ich gehe davon aus, dass Deconz verwirrt ist, wie wenn Sie ein Licht ausschalten, bis es einblendet.

Es scheint, dass die Verzögerung zunimmt, bis jeder Lichtzustand zurückgemeldet wird und der Szenenrückruf in Dekonz erfolgt oder erfolgreich gemeldet wird, sodass andere Aktionen in dieser Gruppe wie gewünscht funktionieren. Dies scheint jetzt etwas länger zu dauern. Innerhalb dieser Zeit - Sie dürfen nicht (bestehen;)) - schalten Sie das Licht aus. Dies ist nicht kritisch.

Ich habe etwas weiter getestet. Wir haben eine Verhaltensänderung. Zuvor war es möglich, mit einem neuen Befehl zu unterbrechen, wenn ein Bri mit einer bestimmten Geschwindigkeit geändert wurde oder eine Szene eine längere Übergangszeit hatte. Auch wenn die vorherige Aktion noch ausgeführt wurde, wurde der nächste Befehl in die Warteschlange gestellt. Jetzt ist es verloren. Egmy Bodenleuchten werden vom Bewegungssensor betrieben. Bevor sie losgehen, dimme ich sie und warte 10 Sekunden, bevor ich sie ausschalte. Wenn ich eine Bewegung auslöste und mich an die Szene erinnere, während sie verblasst, geht der Befehl verloren. Davor wurde es in die Warteschlange gestellt und anschließend ausgeführt. Liegt das an. 74 oder die neue Firmware? Vielen Dank

Mein Conbee II hat kein Mesh auf der Beta-Version erstellt. Ich kann mir nur vorstellen, dass dies von den "normalen" Einstellungen abweichen könnte, wenn der Kanal auf 25 eingestellt wird. Zurück zu 264a0700 wurde dies behoben

@realwax , ich denke, Sie haben einen Trådfri-Firmware-Fehler, siehe # 2068. Sie können dies leicht überprüfen, indem Sie einen Befehl mit einer längeren Übergangszeit in der GUI und anschließend einen zweiten Befehl ausgeben.

Davor wurde es in die Warteschlange gestellt und anschließend ausgeführt.

Haben Sie die Light-Firmware aktualisiert? Sind Sie sicher, dass Sie dasselbe Licht verwenden? Das REST-API-Plugin verfolgt die Übergangszeit nicht mehr, sobald es einen Befehl an das Licht gesendet hat.

@ebaauw Danke, dass du mich in die richtige Richtung geführt hast. Da IKEA angegeben hat, Netzwerk- und Stabilitätsverbesserungen in das Release-Protokoll aufzunehmen, aktualisiere ich meinen TRÅDFRI Lampe E14 WS-Opal 400lm auf Firmware 2.3.007 (neueste Version). Ich dachte, es könnte einige dieser Probleme lösen. Ich frage mich, wie IKEA den Trick auf ihrer eigenen Brücke macht, weil dies ein großes Problem mit der Benutzerfreundlichkeit ist. Jetzt muss ich schnellere Übergangszeiten anstreben, wie Sie in der anderen Ausgabe angegeben haben. Ich erlebe das seit Tag 1, aber es wurde schlimmer. Jetzt wirkt es sich nicht nur auf das Ausblenden von Szenenrückrufen aus, sondern auch auf Änderungen mit einem längeren Übergang. Das ist neu ... Was kann ich tun? Ein Rückblick auf ältere FW ist fast ein No-Go, weil es ein Kampf mit Deconz ist. Danke Erik.

Ich frage mich, wie IKEA den Trick auf ihrer eigenen Brücke macht, weil dies ein großes Problem mit der Benutzerfreundlichkeit ist.

Der Trådfri-Hub ist weit weniger aktiv als das deCONZ-Gateway oder die Hue-Brücke. Die Trådfri-Steuerungen (Schalter, Dimmer, aber auch ihre Bewegungssensoren) steuern die Lichter direkt. Die Trådfri-Anzeigen senden Push-Benachrichtigungen mit Statusänderungen an den Hub. Der Hub wird nur für ihre App benötigt / verwendet. Es werden möglicherweise einige Alarme ausgeführt, aber keine Regeln für die Behandlung von Schaltflächenereignissen oder anderen ausgefallenen Ereignissen.

Ich bin mir nicht sicher, ob die Trådfri-App überhaupt die Angabe längerer Übergangszeiten unterstützt, aber die Controller, die ich gesehen habe, nicht. Sie werden wahrscheinlich nicht in der Lage sein, Befehle von den Controllern schneller als die Standardübergangszeit der Lichter zu senden. Und wenn Sie dies gelegentlich tun, denken Sie wahrscheinlich, dass Sie den Knopf nicht vollständig gedrückt haben.

@ebaauw Ich

Genau gemessene Zeiten (20 Versuche):
Gruppe von 8 E14
Gruppe EIN -> Gruppe AUS - Schaltzeiten 1 Sekunde
Szene abrufen -> einschalten -> AUS reagiert erst nach 10-12 Sekunden!

Ich verstehe, dass mit einem Rückruf mehr Verkehr generiert wird und jede Glühbirne mehr Nachrichten erhält, aber eine Differenz von 10 Sekunden? Selbst wenn ich für eine ganze Gruppe bri und ct ändere, kann ich es in einer Sekunde ausschalten, aber ein Rückruf ist wieder wie ein Einfrieren. Ich denke, das scheint ein Dekonz-Problem zu sein, nicht wahr?

Ich kann es per Video aufnehmen. ;) Vielleicht fehlt mir hier das Wissen, dann entschuldige mich bitte, dass ich mein Unverständnis darstelle, aber ich bin irgendwie frustriert, weil es ein Kampf ist ...

Ich fürchte, ich bin immer noch ein bisschen verwirrt über Szenen. Wie Gruppen existieren sie in ZigBee nicht als Objekt, sondern sind nur eine Zahl, unter der ein Gerät (Licht) einen Status speichert. Bei einem Szenenabruf wird die Nummer übertragen, und jedes Gerät stellt den Status aus seinem nichtflüchtigen Speicher wieder her.

Der unscharfe Teil ist, dass nicht alle Geräte ihren Status beim Speichern der Szene korrekt zu speichern scheinen: Die Farbtemperatur ist in dieser Hinsicht berüchtigt. Ich habe auch lustige Sachen gesehen, die die Szene gespeichert haben, während das Licht noch im Übergang ist. In diesem Fall ist die Ressource /scenes nicht mit dem im Licht gespeicherten Status synchron, sodass die API den Ressourcenzustand anstelle des tatsächlichen Lichtzustands widerspiegelt, der erst beim nächsten Lichteinfall aktualisiert wird abgefragt. Normalerweise wird die Übergangszeit beim Abrufen der Szene angegeben, aber es scheint, dass sie sich auch im gespeicherten Zustand befindet.

Ich habe das Setup meines Produktionsnetzwerks per Skript erstellt (mit ph ), damit ich es einfach neu erstellen kann. Es fiel mir sehr schwer, Szenen auf vorhersehbare Weise zu erstellen. Am Ende stellte ich die Lichtzustände ein, schlief ein paar Sekunden, wartete darauf, dass sich die Zustände beruhigten, speicherte die Szene und schlief wieder ein paar Sekunden und wartete darauf, dass der Zustand gespeichert wurde.

Sie könnten versuchen, Ihre Szene neu zu erstellen, aber keine Garantie ...

Ich konnte das nicht synchronisierte Thema vom ersten Tag an reproduzieren. Ich war es gewohnt, von Zeit zu Zeit zu dekonzieren und die Notwendigkeit einer Neukonfiguration der Szene. Jetzt ist es wirklich schlimmer. Derzeit müsste ich von deconz zu iobroker gehen und alle meine Szenen dort neu erstellen. Aber das ist viel Arbeit. Hoffentlich wird das behoben. Darf ich ein Problem erstellen? Lichter sind nicht mehr zuverlässig, wenn Szenen verwendet werden ... - Ich versuche auch, sie neu zu erstellen. Ich habe gestern zusätzlich zu den bereits existierenden eine "Testszene" gemacht, aber es zeigte sich kein anderes Verhalten.

Ich bin mir nicht sicher, ob es damit zusammenhängt, aber nach dem Upgrade meines Conbee I auf die Beta-Firmware und deCONZ auf .74 hat es einen Tag gedauert und jetzt hat deCONZ die Verbindung zum Conbee verloren. Ich habe das seit Jahren noch nie erlebt ... Aber ich wollte es erwähnen ... Das Protokoll gab nur Versuche an, sich immer wieder damit zu verbinden ... Neustart von deCONZ hat es gelöst ... (mit dem Docker-Container)

Ich habe gerade versucht, eine Gruppe neu zu erstellen, alle Szenen ... Beim Erstellen läuft so viel schief. Bei Verwendung von Phoscon und der Auswahl der "ALL" -Lampen werden die Szenenwerte nicht richtig gespeichert. Selbst die konfigurierten Lichter zeigen an, was Sie gewünscht haben, ein Rückruf jedoch nicht. Sie müssen jedes Licht für sich steuern, auch wenn Sie dieselben Einstellungen vornehmen. Insbesondere muss die alte GUI verwendet werden, um Farbtemperaturfehler von falsch gespeicherten Farben zu korrigieren. Bis eine Szene "funktioniert", müssen Sie dies einige Male durchgehen und möglicherweise die Lichter während des Szenenkonfigurationsprozesses ein- und ausschalten, damit sie ordnungsgemäß gespeichert werden. Ich habe hier nicht viele technische Details, aber ich möchte Sie alle im Thread dazu ermutigen, Szenen zu testen, zu erstellen, zu speichern, zurückzurufen und nach einem Rückruf auszuschalten. Ich denke, das ist mit IKEA-Lampen durcheinander und es wird schlimmer ... Möge es mit IKEA sein, aber ich bezweifle, dass alles andere und die direkte Gruppensteuerung wie ein Zauber mit Dekonz funktionieren.

Ich werde jetzt die Firmware auf 1.x zurücksetzen / downgraden und sehen, ob es besser funktioniert. Ich werde zurückmelden.

IN ORDNUNG. Zurück zum Zeichenbrett. Gestern haben sich 2 IKEA-Leuchten beurlaubt, um nach dem Einschalten einen Zyklus zurückzukommen. Nicht zu sagen, dass die Fehler, die behoben wurden, keine Fehler waren. Sie sind. Nur nicht diejenigen, die das Problem verursachen.

Ich habe mich eingehender mit der Attributberichterstattung befasst. Ich habe mich gefragt, ob die wiederholte Konfiguration des Attributberichts alle 30 Minuten (1800) die Probleme mit der leichten Firmware verursacht.
Ich habe dieses Stück Code bemerkt, das rq.maxinterval == 0 explizit zu behandeln scheint. Nun, wie man diesen Fall richtig behandelt, ist ein bisschen schwierig, da rq.maxinterval == 0 bedeutet, dass das Licht nur eine Änderung meldet, so dass es für diesen Fall keine "gute" Zeitüberschreitung gibt ... Vielleicht ist die aktuelle Implementierung jedoch in Ordnung Ich frage mich, ob es vielleicht eine bessere Idee gibt.

bool DeRestPluginPrivate::sendConfigureReportingRequest(BindingTask &bt, const std::vector<ConfigureReportingRequest> &requests)
{
<hidden>
        if (val.clusterId == bt.binding.clusterId)
        {
            // value exists
            if (val.timestampLastReport.isValid() &&
                val.timestampLastReport.secsTo(now) < qMin((rq.maxInterval * 3), 1800))
            {
                DBG_Printf(DBG_INFO, "skip configure report for cluster: 0x%04X attr: 0x%04X of node 0x%016llX (seems to be active)\n",
                           bt.binding.clusterId, rq.attributeId, bt.restNode->address().ext());
            }
 ```

I Did some experiments, including asking the IKEA lights to report `ONOFF` and `LEVEL` periodically instead of only when a change is made. The lights happily report their status periodically, so that may be an acceptable way to avoid the above issue. To be verified properly of course.

Anyway, while doing these experiments, I stumbled upon an actual bug. I noticed the magical Default Response Command being returned whenever the IKEA lights now report their attributes. So I looked into what that thing is. Apparently that is supposed to conclude an ZCL/APS transaction when requested. There's a bit in the ZCL packet which dictates whether or not it should be sent `Disable Default Response`.

For attribute reports these are handled nicely by deCONZ

Nr. Zeitquelle Senden Dev Empfangen Dev Ziel Deaktivieren Standardantwortinformationen
208134 10h 43m 23.151s Gruppe 1 Gruppe 1 DeConz DeConz Falsch ZCL: Berichtsattribute, Seq: 15
208136 10h 43m 23.158s DeConz DeConz Gang 1 Gang 1 APS: Ack, Dst Endpt: 1, Src Endpt: 1
208138 10h 43m 23.212s DeConz DeConz Gang 1 Gang 1 True ZCL: Standardantwort, Seq: 15

However for Configure Reporting Response command, deCONZ fails to send the Default Response. I'm not sure how the IKEA lights handle this situation, but it may be a cause for a memory leak. Remembering that the Default Response is a kind of closure of the transaction, it may be that the firmware only releases a certain amount of memory after it is received.

Nr. Zeitquelle Senden Dev Empfangen Dev Ziel Deaktivieren Standardantwortinformationen
207941 10h 43m 8.422 DeConz DeConz Gang 1 Gang 1 True ZCL: Reporting konfigurieren, Seq: 41
207949 10h 43m 8.481 Gang 1 Gang 1 DeConz DeConz False ZCL: Konfigurieren der Berichtsantwort, Seq: 41
207951 10h 43m 8.485 Gang 1 Gang 1 DeConz DeConz APS: Ack, Dst Endpt: 1, Src Endpt: 1
207952 10h 43m 8.487 DeConz DeConz Gang 1 Gang 1 APS: Ack, Dst Endpt: 1, Src Endpt: 1
207954 10h 43m 8.493 Gang 1 Gang 1 DeConz DeConz APS: Ack, Dst Endpt: 1, Src Endpt: 1

I'm going to test this hypothesis with this patch in place:
```diff
diff --git a/bindings.cpp b/bindings.cpp
index 9607b09..0c2b5fc 100644
--- a/bindings.cpp
+++ b/bindings.cpp
@@ -443,6 +443,12 @@ void DeRestPluginPrivate::handleZclConfigureReportingResponseIndication(const de
         allNodes.push_back(&l);
     }

+    // send DefaultResponse if not disabled
+    if (!(zclFrame.frameControl() & deCONZ::ZclFCDisableDefaultResponse))
+    {
+        sendZclDefaultResponse(ind, zclFrame, deCONZ::ZclSuccessStatus);
+    }
+
     for (RestNodeBase * restNode : allNodes)
     {
         if (restNode->address().ext() != ind.srcAddress().ext())

Ich habe dieses Codebit bemerkt, das rq.maxinterval == 0 nicht explizit zu verarbeiten scheint. Nun, wie man diesen Fall richtig behandelt, ist ein bisschen schwierig, da rq.maxinterval == 0 bedeutet, dass das Licht nur eine Änderung meldet, so dass es für diesen Fall keine "gute" Zeitüberschreitung gibt ... Vielleicht ist die aktuelle Implementierung jedoch in Ordnung Ich frage mich, ob es vielleicht eine bessere Idee gibt.

Ja, das REST-API-Plugin überprüft, ob die Attributberichterstattung funktioniert. Wenn nicht, versucht es, es neu zu konfigurieren, und ich denke, es greift auch auf die Abfrage des Geräts zurück.

Ich habe einige Experimente durchgeführt, einschließlich der Aufforderung an die IKEA-Leuchten, ONOFF und LEVEL regelmäßig zu melden, anstatt nur, wenn eine Änderung vorgenommen wird. Die Lichter melden regelmäßig ihren Status, so dass dies ein akzeptabler Weg ist, um das oben genannte Problem zu vermeiden. Natürlich richtig zu überprüfen.

Ich denke, wir haben einige Zeit mit dieser Einstellung gearbeitet. Es wurde geändert, zusammen mit einer weniger häufigen Abfrage der Nachbartabellen und einer Abfrage des Status nicht mehr, da ein Teil der Trådfri-Firmware hängen blieb (was einen Aus- und Wiedereinschalten des Lichts erforderlich machte). Ich bezweifle, dass die Berichtseinstellung tatsächlich zum Firmware-Absturz beigetragen hat.

Das ZCL-Paket enthält ein Bit, das vorschreibt, ob es Disable Default Response gesendet werden soll oder nicht.

Ich denke nicht, dass das Senden der Standardantwort so viel Schaden anrichten würde, wenn das Bit Disable Default Response gesetzt ist. Wenn die Standardantwort nicht gesendet wird, wenn das Bit nicht gesetzt ist, kann dies schaden, da das auf die Antwort wartende Gerät möglicherweise zu dem Schluss kommt, dass der Koordinator nicht mehr erreichbar ist und schließlich das Netzwerk verlässt.

Das ZCL-Paket enthält ein Bit, das vorschreibt, ob es Disable Default Response gesendet werden soll oder nicht.

Ich denke nicht, dass das Senden der Standardantwort so viel Schaden anrichten würde, wenn das Bit Disable Default Response gesetzt ist. Wenn die Standardantwort nicht gesendet wird, wenn das Bit nicht gesetzt ist, kann dies schaden, da das auf die Antwort wartende Gerät möglicherweise zu dem Schluss kommt, dass der Koordinator nicht mehr erreichbar ist und schließlich das Netzwerk verlässt.

@ebaauw , in der Tat. Genau darum geht es. deCONZ kann keine Default Response als Antwort auf eine Configure Reporting Response senden. Es kommt vor, dass IKEA-Lichter ein Default Response für Configure Reporting Response anfordern.
Wie Sie sagen, kann dies der Grund dafür sein, dass IKEA-Lichter zusammen mit den Configure Reporting Request jede halbe Stunde ausfallen.

Nur eine Erinnerung:
Ikea-Lampen (E27 & GU10 v1) sind gelegentlich nicht mehr erreichbar und müssen auch beim Anschluss an eine HUE-Brücke aus- und wieder eingeschaltet werden, sodass dieses Problem nicht nur bei Conbee I / II auftritt
Von 16 E27 und 12 GU10 auf meiner HUE-Brücke würde ich sagen, dass ungefähr eine Lampe pro 1-2 Wochen "hängt". Mal länger, mal schneller. Dieses Problem hat sich mit den neuesten HUE-Firmware-Versionen in den letzten anderthalb Jahren verbessert.

@all Welche Tradfri-Firmware-Version verwenden Sie?

Bist du auf 1.x oder 2.x? Mit dem 2.x haben sie ZigBee 3.0 eingeführt. Ich habe ein Upgrade auf 2.x durchgeführt und die Probleme begannen. E14 Glühbirnen. Ich habe Verbesserungen in Bezug auf Netzwerkgeschwindigkeit und Konnektivität festgestellt. Aber zwei Dinge ließen mich 20 Glühbirnen zurückrollen. Das "Soft On" funktionierte nicht mehr. Die Lampen schalteten sich ein, ohne einzublenden. Die Szenen funktionierten nicht mehr so ​​wie früher. Genau nach dem Abrufen einer Szene war eine Wartezeit erforderlich, bevor das Licht ausgeschaltet oder das nächste Szene zurückgerufen wurde. Andernfalls wurde Deconz asynchronisiert und erneut synchronisiert, während die Glühbirne nichts tat.

Ich schätze Ihre gemeinsame Erfahrung mit Versionen und dekonziere 'Makellosigkeit' mit 2.x, es scheint nicht gegeben zu sein.

Gibt es eine Empfehlung? FW v.? Neben dem Problem mit der verlorenen Verbindung und den Verbindungsproblemen auf Ikeas fw selbst scheint deconz besser mit 1.x umgehen zu können.

Vielen Dank!

Ich benutze:

• Conbee 1 mit 0x26340500 Firmware
• Deconz Version 2.05.73 (mit Marthoc Docker Container unter Debian)
• ~ 60 Knoten, hauptsächlich IKEA Trådfri
• Conbee 1 (Koordinator) ist NICHT zentral in meinem 200 m² großen Haus installiert. Das System ist stark auf Roaming und Meshing angewiesen.
• Der Conbee 1-Stick wird an einem 0,5 m langen USB-Verlängerungskabel installiert und an der Seite des Regals montiert, an der sich der Computer befindet, um mehr Platz für die HF-Signale zu haben.

Seit dem Upgrade (am selben Tag wie veröffentlicht) der Conbee 1-Sticks funktioniert die Firmware deconz wie ein Zauber ! Keine Probleme, was auch immer.

Mein Produktionsnetzwerk (RPi 3B +, Stretch, RaspBee) wurde gestern auf 2.05.74 und 0x26340500 aktualisiert. Scheint stabil, mit Ausnahme der folgenden Probleme.

Ich bin mir nicht sicher, ob ich damit verwandt bin, aber der Weg zu meinem lumi.curtain Vorhang-Controller ist heute Morgen verloren gegangen. Berichte des Controllers würden weiterhin das Gateway erreichen. Die Route wird beim Aus- und Einschalten des Controllers nicht wiederhergestellt. Ich musste das Netzwerk öffnen und den Controller aus- und wieder einschalten, bevor der Koordinator ihn wieder erreichen konnte.

Außerdem war eines meiner Eurotronic Spirit-Heizkörperventile nach dem Start von deCONZ für deCONZ nicht erreichbar, während weiterhin Berichte gesendet wurden. Das Einschalten des TRV brachte es wie gewohnt zurück.

Diesmal hatte ich keine Gelegenheit, eingehende Untersuchungen durchzuführen, aber beide Geräte waren von Anfang an problematisch und zeigten diese Symptome gelegentlich. Gleiches gilt für meinen IKEA Fyrtur Blind. Ich werde die Situation weiterhin überwachen und zurückmelden, wenn weitere Probleme auftreten.

@ Tubalainen
Welche Firmware verwenden Sie für Ihre Tradfri-Lampen? Dies macht auch in diesem Thread einen Unterschied in Bezug auf das Problem der verlorenen Verbindung, soweit ich es getestet habe. Meine Ergebnisse sind, dass die hier unternommenen Schritte den Betrieb von 1.x-betriebenen Tradfri-Lampen auf Conbee 1 verbessert haben. Aber ein Netzwerk von 20 e14 mit tradfri fw 2.3.x ist ein Chaos. Timings, Szenen stecken, Dekonz wird, Licht beginnt zu blinken (verloren?), .. wie oben berichtet. Ich denke, dies ist ein Punkt, der diskutiert und erwähnt werden muss, um eine klare Empfehlung von ikea fw für eine gute Erfahrung abzugeben. Vielleicht gibt es schon einen Git-Artikel. Aber aus meiner Erfahrung nicht upgraden 😅

Also aus meiner Sicht und stundenlanges Testen und Blinken. Vielen Dank für die Verbesserung für ikea fws 1.x! Ist es möglich, die aktuellen Probleme zu verringern, wenn 2.x betrieben wird? Andernfalls ist ein Upgrade auf zigbee 3 mit ikea derzeit nicht möglich. Es scheint, als hätte sich das Verhalten geändert und die Bedienung in Dekonz muss angepasst werden. Dies ist wahrscheinlich für @ebaauw zu beurteilen oder zu behandeln?

Prost
Habt einen schönen Sonntag 😊

@ Realwax
Ich habe versucht, alle meine Entitäten auf die neueste FW zu aktualisieren. Hier ist meine Liste aller (derzeit aktiven) Knoten.

Einverstanden mit allen "beweglichen Teilen" gleichzeitig, die versuchen, die Grundursache der Probleme zu finden.

@ Tubalainen

Vielen Dank für Ihre Liste.

Wenn ich besonders auf die Router (Glühbirnen) schaue, sehe ich, dass Sie 2.3.007 auf Ihren E14s betreiben. Können Sie meine Problemliste reproduzieren? https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518
Da mir das automatische fw-Upgrade auf 2.3.x nicht bekannt war, war mein Netzwerk mit 1.x und 2.x nicht sehr gut gemischt. Ich habe von Hand auf 2.3.x aktualisiert und dann wurde es schlimmer. (Netzwerk schneller, aber massive Benutzerfreundlichkeit dran und blinkende Glühbirnenausfälle) Daher kann ich empfehlen, wenn Sie blinkende Glühbirnen auf Ihrem e14 oder "Nachlässigkeit" auf Szenen erleben, die sie auf 1,2 herabstufen ... Ich wäre daran interessiert, einen "offiziellen" / Professionelle Aussage unserer Pro-Entwickler hier dazu. Ich bin mir ziemlich sicher, dass es eine Zeit gab, in der Deconz ähnlich mit 1.2 behandelt wurde und es verbessert wurde. Ich habe das Gefühl, dass dies auch für 2.3.x getan werden muss, oder Ikea hat es selbst durcheinander gebracht. Schwer zu sagen, da ich nicht tief in Code bin.

@ Realwax
Ich verwende die otau-Funktion von deconz und das Firmware-Update-Skript, um die fw-Dateien herunterzuladen.
Ich weiß nicht, warum die E14 nicht aktualisiert werden ... huhum.

Wie haben Sie die Glühbirnen "manuell" aktualisiert / heruntergestuft?

Gut gut. Es funktioniert alles einwandfrei und der Großteil des Routings wird von den E27s mit fw 2.3.x und den Panel-LED-Treibern Jormen und FLOALT durchgeführt.

@ Tubalainen
Interessant, dass Sie diese Probleme nicht erleben. Vielleicht liegt es an der Maschenweite. Ich habe 23 Glühbirnen von diesen 20 e14 am 2.3.007. Ich habe die automatische Otau deaktiviert, da sie meine Benutzerfreundlichkeit mit der neuen Firmware beeinträchtigt hat. Über Gui können Sie mit der Update-Schaltfläche ein Downgrade durchführen. Wählen Sie zuerst die richtige Firmware aus, klicken Sie auf Aktualisieren und möglicherweise erneut. Der Formularstatus wurde angehalten und geht zu -> Warteschlange -> Leerlauf -> Firmware-Aktualisierung starten (Prozentsatz). Manchmal hängt es. Irgendwann muss es neu gestartet werden. Irgendwann reicht ein Power Cyle. Manchmal müssen Sie die Glühbirne näher an den Koordinator bringen.

Es scheint, als hätte sich das Verhalten geändert und die Bedienung in Dekonz muss angepasst werden. Dies ist wahrscheinlich für @ebaauw zu beurteilen oder zu behandeln?

Ich bin mir nicht sicher, was du hier meinst. Ich habe einige Unterschiede zwischen der ZLL- und der ZB3-Firmware für die Controller (Trådfri-Fernbedienung und Trådfri-Funkdimmer) behandelt, siehe Nr. 2485. Dies befindet sich auf APS-Ebene im ZigBee-Stack und wird vom REST-API-Plugin verarbeitet.

Die Routingprobleme in diesem Thema liegen auf NWK-Ebene, die von der Gerätefirmware behandelt wird. Wie jeder andere hier habe ich keinen Zugriff auf die Firmware-Quellen. Selbst wenn ich würde, könnte ich nichts tun, da ich die Details der NWK- und MAC-Schichten nicht kenne.

@ebaauw
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518
Genau genommen. Ich habe meine Ergebnisse mit 20 E14 2.3.007 mesh hier aufgenommen. Einige Funktionen sind weg und der Szenenrückruf bringt 10 bis 15 Sekunden lang alles in dieser Gruppe durcheinander. Ich weiß nicht, ob dies nur mit Firmware oder Deconz zusammenhängt. Das habe ich mit Veränderung gemeint. Für den täglichen Betrieb sehe ich 2.3.007 als no go. Beispiel für die Benutzerfreundlichkeit: Ein einfacher Schalter, der Szenen dreht, die in phoscon konfiguriert sind, funktioniert nicht mehr, wenn er nicht sorgfältig gedrückt wird, was bedeutet, dass nach einer Szenenrotation gewartet werden muss. Während in 1.x alles schnell und gut mit 2.3.x ist, bleibt es stecken.

Danke, @manup , habe es gerade installiert. Mal sehen, was es bringen wird.
Obwohl ich davon ausgehe, dass sich dies verbessern wird, wie denken Sie, dass die DeConz-Firmware die aufgezeichneten Routen ignoriert (aufgrund des Mane-to-One-Routings)? Im Allgemeinen habe ich gesehen, dass die aufgezeichneten Routen viel logischer sind als die von der DeConz-Firmware verwendeten.
Obwohl ich mir vorstellen kann, dass das Aktivieren des Quellroutings eine große Aufgabe ist, könnte (sollte?) Die DeConz-Firmware die Informationen aus dem Routendatensatzpaket weiterhin verwenden, um den ersten Hop auf ein Gerät zu aktualisieren. Überprüfen Sie möglicherweise einfach, ob der letzte Sprung zum Koordinator mit dem übereinstimmt, was in der Routing-Tabelle gespeichert ist, und machen Sie den Eintrag in der Routing-Tabelle ungültig, wenn nicht. Ich bin nicht sicher, ob es in Ordnung ist, den Eintrag durch den letzten Sprung von der aufgezeichneten Route zu ersetzen, da die Geräte auf dem Weg die Informationen wahrscheinlich ignorieren, aber zumindest eine neue Routenerkennung für diesen Knoten durch die DeConz-Firmware initiieren könnten.
Was denkst du darüber?

Hmm seltsam, die Firmware sollte diese Routendatensätze bereits verwenden, um neue Routen einzurichten. Sie müssen den Code hier überprüfen, aber wenn mein Speicher mich richtig bedient, wurde dies vor einiger Zeit aktiviert.

@manup , hast du etwas Zeit Network Address Request von deCONZ zu antworten. Letzteres geschieht nur, weil es sich um Broadcast-Nachrichten im Netzwerk handelt ..!
Der dazwischen liegende Router löscht jedoch stillschweigend alle Unicast-Frames, die er an diese Leuchte weiterleiten soll. Dieser Router sollte sie natürlich nicht stillschweigend fallen lassen, andererseits sollte deCONZ robust gegen dieses schlechte Verhalten sein.
In der Zwischenzeit sendet das Licht auch gerne Routenaufzeichnungsnachrichten an deCONZ, die eintreffen und von deCONZ ignoriert werden.

Ich denke, es sollte eine Logik geben, die deCONZ auslösen sollte, um seine Routen in diesem Fall zu überdenken. Insbesondere, wenn festgestellt wird, dass die ZCL-Anforderungen nicht beantwortet werden. Was am Ende dazu führt, dass das Licht als Zombie markiert wird. Die Entdeckung, die der Markierung als Zombie folgt, führt tatsächlich zu einer Antwort des Lichts. Wenn eine Entdeckung für einen Zombie gestartet wird, sollte sie möglicherweise auch alle verfügbaren Routeninformationen ungültig machen. Aber noch besser, wenn die Route bereits früher ungültig wird, wenn einige ZCL-Anfragen nicht beantwortet werden (wahrscheinlich bereits bei der ersten oder zweiten).

Was denkst du darüber?

Diese neue Firmware hat mein Problem nicht gelöst.

Ich benutze eine Raspbee auf einem separaten Pi und Home Assistant (läuft auf einem NUC) und habe ca. 25 tradfri Lichter. Meistens wird GU10 in Dreiergruppen verwendet.

Ich hatte große Probleme mit einzelnen Lichtern in einer Lichtgruppe, die nicht mehr reagierten und einen Aus- und Wiedereinschalten benötigten, um wieder zurückzukehren. Dies geschah sowohl mit Ikea FW v1 als auch nach dem Upgrade der Lampen auf 2.3.007.

Die Lösung bestand darin, meine Konfiguration von der Gruppierung der Lichter in HASS zur Definition von Lichtgruppen in Phoscon und der Referenzierung der Phoscon-Gruppen als einzelne Lichter in HASS zu ändern. Nach dieser Änderung bin ich seit ein paar Monaten ohne Probleme gelaufen.

Ich möchte in der Lage sein, die Gruppierung in HASS durchzuführen, also habe ich mein Raspbee auf 0x26340500 und Deconz auf 2.05.74 aktualisiert und meine Konfiguration wieder auf die Verwendung von Lichtgruppen in HASS geändert. Nachdem ich dies eine Woche lang ausgeführt habe, hatte ich drei- oder viermal veraltete Glühbirnen und wechsle jetzt wieder zur Verwendung von Phoscon-Gruppen.

Ich denke, es sollte eine Logik geben, die deCONZ auslösen sollte, um seine Routen in diesem Fall zu überdenken. Insbesondere, wenn festgestellt wird, dass die ZCL-Anforderungen nicht beantwortet werden. Was am Ende dazu führt, dass das Licht als Zombie markiert wird. Die Entdeckung, die der Markierung als Zombie folgt, führt tatsächlich zu einer Antwort des Lichts. Wenn eine Entdeckung für einen Zombie gestartet wird, sollte sie möglicherweise auch alle verfügbaren Routeninformationen ungültig machen. Aber noch besser, wenn die Route bereits früher ungültig wird, wenn einige ZCL-Anfragen nicht beantwortet werden (wahrscheinlich bereits bei der ersten oder zweiten).

Ich bin immer noch auf der neuen Firmware und teste ein paar Dinge, einschließlich der Routenaufzeichnungen. Ich hoffe, sie diese Woche online zu stellen.

Was denkst du darüber?

Das ist ein guter Punkt, ich muss hier den Kern- und REST-API-Plugin-Code überprüfen, da ich denke, dass die Firmware die "Qualität" der Route bereits verschlechtern sollte, wenn kein ACK auf APS-Ebene empfangen wird. Das APS ACK ist ein Flag, das optional in den ZCL / APS-Anforderungen gesetzt wird und häufig deaktiviert wird, um den Netzwerkverkehr zu verringern. Eine grobe Idee ist also, dass wir APS ACK aktivieren sollten, wenn das Plugin erkennt, dass Unicast-Anforderungen zu Zeitüberschreitungen führen.

Möglicherweise ist ein Teil davon bereits vorhanden. Sie müssen den Code überprüfen.

Der dazwischen liegende Router löscht jedoch stillschweigend alle Unicast-Frames, die er an diese Leuchte weiterleiten soll. Dieser Router sollte sie natürlich nicht stillschweigend fallen lassen, andererseits sollte deCONZ robust gegen dieses schlechte Verhalten sein.

Das Licht sollte eine neue Route aufnehmen, sobald eine neue Routenerkennung ausgelöst wird. Daher sollte das Ziel darin bestehen, eine unterbrochene Route so schnell wie möglich zu erkennen (hoffentlich wird APS ACK den Trick ausführen) und die Routenerkennung auszulösen.

Die Zustandsmaschine dafür ist bereits im deCONZ-Kern vorhanden (dies führt zur Übertragung der NWK-Adressanforderung). Dies funktioniert bei One-Hop-Verbindungen und bei Lichtern, die Routen basierend auf eingehenden Befehlen aufnehmen (die Antwort auf die Übertragung). Die Sendung ist nett, da sie auch Änderungen an der NWK-Adresse berücksichtigt, da die MAC-Adresse enthalten ist. Ich werde versuchen, als nächsten Schritt ein Unicast mit aktiviertem APS ACK zu senden, falls keine Antwort eingeht.

Leider musste ich gestern auch eine IKEA E27-Lampe (White 1000LM, v1-Firmware) aus- und wieder einschalten. Es reagierte nur auf Gruppenbefehle, nicht jedoch auf Unicast-Befehle. Das Problem scheint noch nicht behoben zu sein :(

(und ja, ich bin auf v74 und der Beta-Firmware für RaspBee)

In den obigen Kommentaren können die nächsten Änderungen dazu beitragen, das Routing wiederherzustellen.

Was denkst du darüber?

Das ist ein guter Punkt, ich muss hier den Kern- und REST-API-Plugin-Code überprüfen, da ich denke, dass die Firmware die "Qualität" der Route bereits verschlechtern sollte, wenn kein ACK auf APS-Ebene empfangen wird. Das APS ACK ist ein Flag, das optional in den ZCL / APS-Anforderungen gesetzt wird und häufig deaktiviert wird, um den Netzwerkverkehr zu verringern. Eine grobe Idee ist also, dass wir APS ACK aktivieren sollten, wenn das Plugin erkennt, dass Unicast-Anforderungen zu Zeitüberschreitungen führen.

Möglicherweise ist ein Teil davon bereits vorhanden. Sie müssen den Code überprüfen.

Selbst wenn das APS ACK-Anforderungsbit gesetzt ist, macht deCONZ anscheinend nichts mit der fehlenden Bestätigung (nur ein erneuter Versuch und dann nichts ...).

Übrigens ist houtlamp 2 derjenige, der die an Tuin linksvoor 2 gerichteten Pakete

No. Time    Source  Transmit Dev    Receive Dev Destination Disable Default Response    Info
245915  10h 28m 42.108501s  DeConz  DeConz  HK houtlamp 2   Tuin linksvoor 2    True    ZCL: Read Attributes, Seq: 245
245922  10h 28m 46.033452s  DeConz  DeConz  HK houtlamp 2   Tuin linksvoor 2    True    ZCL: Read Attributes, Seq: 245

ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1
    Frame Control Field: Data (0x40)
        .... ..00 = Frame Type: Data (0x0)
        .... 00.. = Delivery Mode: Unicast (0x0)
        ..0. .... = Security: False

        .1.. .... = Acknowledgement Request: True

        0... .... = Extended Header: False
    Destination Endpoint: 1
    Cluster: On/Off (0x0006)
    Profile: Home Automation (0x0104)
    Source Endpoint: 1
    Counter: 107

Der dazwischen liegende Router löscht jedoch stillschweigend alle Unicast-Frames, die er an diese Leuchte weiterleiten soll. Dieser Router sollte sie natürlich nicht stillschweigend fallen lassen, andererseits sollte deCONZ robust gegen dieses schlechte Verhalten sein.

Das Licht sollte eine neue Route aufnehmen, sobald eine neue Routenerkennung ausgelöst wird. Daher sollte das Ziel darin bestehen, eine unterbrochene Route so schnell wie möglich zu erkennen (hoffentlich wird APS ACK den Trick ausführen) und die Routenerkennung auszulösen.

Die Zustandsmaschine dafür ist bereits im deCONZ-Kern vorhanden (dies führt zur Übertragung der NWK-Adressanforderung). Dies funktioniert bei One-Hop-Verbindungen und bei Lichtern, die Routen basierend auf eingehenden Befehlen aufnehmen (die Antwort auf die Übertragung). Die Sendung ist nett, da sie auch Änderungen an der NWK-Adresse berücksichtigt, da die MAC-Adresse enthalten ist. Ich werde versuchen, als nächsten Schritt ein Unicast mit aktiviertem APS ACK zu senden, falls keine Antwort eingeht.

Tatsächlich sieht der houtlamp 2 nie eine Antwort auf die Sendung address request . Die Nachrichten an deCONZ werden über tuin linksvoor 3 . Selbst wenn houtlamp 2 diese Route übernehmen würde, hat sie nie die Chance. Dies wird dann wieder dadurch verursacht, dass deCONZ die route record als neue Route aufnimmt.

ZigBee Network Layer Command, Dst: DeConz, Src: Tuin link
    Frame Control Field: 0x1a09, Frame Type: Command, Discover Route: Suppress, Security, Destination, Extended Source Command
    Destination: 0x0000[DeConz]
    Source: 0x0ea5[Tuin linksvoor 2]
    Radius: 29
    Sequence Number: 51
    Destination: dresden-_ff:ff:00:c4:9a (00:21:2e:ff:ff:00:c4:9a)
    Extended Source: EnergyMi_ff:fe:e9:91:86 (d0:cf:5e:ff:fe:e9:91:86)
    ZigBee Security Header
    Command Frame: Route Record
        Command Identifier: Route Record (0x05)
        Relay Count: 1
        Relay Device 1: 0xc9fa[Tuin linksvoor 3]

Jetzt sendet Tuin linksvoor 2 eine Antwort auf die Sendung network address request und ist erfolgreich, aber die APS ACK von deCONZ erreicht nie Tuin linksvoor 2 , da sie um houtlamp 2 gesenkt wird. Es wird also ein paar Mal erneut gesendet, bevor es aufgegeben wird. Das hat eine gute Chance, Tuin linksvoor 2 durcheinander zu bringen.

No. Time    Source  Transmit Dev    Receive Dev Destination Disable Default Response    Info
246199  10h 29m  1.496384s  Tuin linksvoor 2    Tuin linksvoor 3    DeConz  DeConz      Network Address Response, Status: Success, Address: EnergyMi_ff:fe:e9:91:86 = 0x0ea5
246201  10h 29m  1.502056s  DeConz  DeConz  HK houtlamp 2   Tuin linksvoor 2        APS: Ack, Dst Endpt: 0, Src Endpt: 0

Conbee 1 + neueste fw + .74 spielt nicht 100%.
Hatte einige Hits / Misses. Es scheint besser mit .73 für mich zu funktionieren, aber nicht 100%.

Also zurück zum Zeichenbrett. Es ist immer noch nicht 100% in Ordnung mit dem neuen (Beta) Conbee 1 fw.

Nach ein paar Tagen Betrieb mit .74 und 26340500 auf Conbee 1 auf Tradfir E14 mit Firmware 1.2.221 kann Folgendes gemeldet werden:

IKEA light wurde stabiler, da ich nur eine Glühbirne hatte, die innerhalb von 4 Tagen verloren ging. Ich habe auch herausgefunden, dass, wenn Sie die Hölle aus Ihrem deconz betriebenen ZigBee-Netzwerk herausholen, das auf E14 fw 1.2.221 läuft. Ich habe ein Skript ausgeführt, das eine Glühbirne ausgeblendet hat, indem ich jede Sekunde einzelne Anfragen mit geändertem Bri gesendet habe. Auf diese Weise habe ich sehr schnell 4 Glühbirnen verloren. Aber wer will das schon;)

Noch ungelöst:
Das Problem und die Sorge, die ich immer noch habe, ist, dass Tradfri FW 2.3.x nicht gut läuft oder nicht gut implementiert ist, um mit deconz verwendet zu werden. Es ist in Ordnung, bei tradfri fw 1.2.x zu bleiben und nicht zu zigbee 3.0 zu gehen. Aber es wird einen Zeitpunkt geben, der nicht vermieden werden kann. Oder ich fürchte, neue Glühbirnen werden nicht mehr herabgestuft.
Ich entdeckte, dass eine Gruppe von 2-3 Glühbirnen dieses Problem als Gruppe von 4-8 Glühbirnen nicht so schlimm zeigt.
Ich habe meine Entdeckung hier gemeldet und bin froh und dankbar, wenn sie aufgegriffen wird. Ich habe versucht, hier auf https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518 aufmerksam zu machen
Da ich dieses Problem reproduzieren kann, indem ich einfach meine gesamte Glühbirne auf 2.3.x blitze, hoffe ich, dass Sie das auch können.

Fazit: Es macht einen Unterschied, welche Tradfri-Firmware verwendet wird und über welche wir sprechen. Es gibt einen großen Unterschied in der Benutzerfreundlichkeit und dem erlebten Problem sowie im Betrieb mit deconz. Während 1.2.x fws eher älter sind und wie ein Zauber neben den bekannten Aussetzern wirken, hat 2.3.x nicht die Benutzerfreundlichkeit verloren, wie in dem angesprochenen Problem beschrieben. Ich kann mir nicht vorstellen, dass ich der einzige bin, der diesen Unterschied bei FWs erlebt.

Ich habe jetzt eine E-Mail an den dresden elektronik support in deutscher Sprache gesendet, um darauf aufmerksam zu machen, da ich verstanden habe, dass einige von Ihnen Hobby-Enthusiasten sind, wie @ebaauw in einem anderen Thread deutlich gemacht hat. Ich dachte, die meisten Entwickler sind dresden elektronik Auftragnehmer. Entschuldigen Sie das Missverständnis und bedanken Sie sich für Ihre Beiträge. Ich bin gespannt auf die offizielle Antwort.

Ist die Conbee II-Firmware jetzt auch behoben? Ich habe nur Conbee I in der Veröffentlichung gesehen. Vielen Dank übrigens für Ihre harte Arbeit.

Dies wird dann wieder dadurch verursacht, dass deCONZ den Routendatensatz nicht als neue Route aufnimmt.

@djwlindenaar stellt sich heraus, dass ich hier schuld bin. Ich habe die Commits für den Routendatensatzcode im Stapel-Repository (ConBee I und RaspBee I) überprüft. 2018 hatte ich ein "Fix" (oder ich dachte es) für ein ähnliches Problem hinzugefügt, bei dem die Aktualisierung der Adresse des nächsten Hops in einem eingehenden Routendatensatz deaktiviert wurde.

Wenn mein Gedächtnis mir recht tut, bestand das Problem zu der Zeit darin, dass wir ein großes gemischtes Netzwerk mit etwa 150 Knoten hatten und Routendatensätze anscheinend nicht richtig funktionierten. Der neue Pfad zurück funktionierte nicht richtig. Möglicherweise hat der Code jedoch mit dem anderen Fix der Fehlercodes des NWK-Statusbefehls funktioniert.

Ich mache dies jetzt wieder rückgängig, daher sollte der Routendatensatz die Route auf den besseren Pfad aktualisieren.

Ich liebe diesen Absatz aus der ZigBee-Spezifikation:

Ein ZigBee-Router oder ZigBee-Koordinator kann eine Routing-Tabelle verwalten. Die Informationen, die in einem ZigBee-Routing-Tabelleneintrag gespeichert werden sollen, sind in Tabelle 3-66 aufgeführt. Die Alterung und Stilllegung von Routing-Tabelleneinträgen, um Tabellenbereich von nicht mehr verwendeten Einträgen zurückzufordern, wird empfohlen. es liegt jedoch außerhalb des Geltungsbereichs dieser Spezifikation.

Dies bedeutet im Grunde, dass jeder Stapel die Routenalterung anders handhabt.

Also habe ich überprüft, wie es in unserem Fall funktioniert. In Bitcloud Zigbee haben Stapelrouten eine Routenrate, die anfänglich 1 beträgt.

1. Bei einer erfolgreichen NWK-Übertragung wird die Rate erhöht, wenn sie unter dem Maximum liegt, das ist
   (1 << 8) - 1 = 255
2. Wenn bei einer erfolgreichen NWK-Übertragung das Maximum von 255 erreicht wird, werden alle Routing-Tabelleneinträge "normalisiert".
   rate = (rate >> 1) + 1 (effektiv geteilt durch 2, mit einem Minimum von 1)
3. Bei einer fehlgeschlagenen NWK-Übertragung wird die Rate des zugehörigen Routeneintrags wie folgt festgelegt:
   rate -= (rate / 2) > 0 ? rate / 2 : 1
4. Bei zu vielen fehlgeschlagenen Übertragungen wird die Rate 0 und die Route wird entfernt

Dies bedeutet, dass sich ein Top-Link wie folgt verschlechtert:

255  top rate
127  first failed transmission
63   ...
31
15
7
3
1
0    the record gets removed

Daher sind 8 fehlgeschlagene Befehle erforderlich, bis ein Eintrag entfernt und die Erkennung erneut gestartet wird.
Das ist in normalen Netzwerken ganz in Ordnung, besonders wenn sie auf 50 bis 100 Knoten anwachsen. Eine Route sollte nicht zu früh verworfen werden.

Was mich betrifft, ist Punkt (2), weil zum Beispiel eine sehr frische Route oder eine Route, die nicht verwendet wird, die häufig durch völlig unabhängige Hochleistungsknoten mit guten Verbindungen beeinträchtigt wird, zum Beispiel ein Philips Hue-Licht, das alle paar Sekunden abgefragt wird Trigger (2) multiplizieren dies häufig mit der Anzahl der Lichter in einem großen Netzwerk. Ganz zu schweigen von aktiven OTA-Updates.

Ich denke, es ist sicher, (2) zu ändern, um nicht alle Routeneinträge zu verschlechtern (zu normalisieren), sondern nur die 255 Top-Route, die sich auf die erfolgreiche Übertragung bezieht. Dies sollte verhindern, dass Routen verloren gehen, die gut funktionierten, aber nicht oft verwendet wurden und bei der ersten fehlgeschlagenen NWK-Übertragung entfernt wurden.

Ich werde morgen eine neue Firmware mit diesen Änderungen erstellen, auch eine für ConBee II, wahrscheinlich gilt das Gleiche dort.

Ich mache dies jetzt wieder rückgängig, daher sollte der Routendatensatz die Route auf den besseren Pfad aktualisieren.

OK, klingt gut. Ich freue mich auf den Test!

Ich liebe diesen Absatz aus der ZigBee-Spezifikation:

Ja, ich denke, diese Art der Spezifikation macht es uns schwer, alle Anbieter dazu zu bringen, gut zusammen zu existieren. :Lächeln:

In Bitcloud Zigbee haben Stapelrouten eine Routenrate, die anfänglich 1 beträgt.

Ich verstehe die Logik hinter Regel 2 nicht wirklich. Es scheint eine Art Version des Alterns eines armen Mannes zu sein. Das funktioniert ganz gut, wenn alle Knoten eine ähnliche Menge an Verkehr sehen, aber wenn es unausgeglichen ist (was meiner Meinung nach ziemlich häufig ist), wird es schief gehen.
Ich habe festgestellt, dass der ZStack ein aktuelles expiryTime -Feld in seiner Routing-Tabelle neben einem status -Byte verwendet.

3. On a failed NWK transmission the rate of the related route entry is set as:

Wie funktioniert das eigentlich?
Wenn ich mich nicht irre, bedeutet eine fehlgeschlagene NWK-Übertragung tatsächlich nur den nächsten Hop, da NWK nur die 802.15.4 MAC ACK überprüft. Um zu überprüfen, ob die Ende-zu-Ende-Übertragung in Ordnung ist, müssen wir uns auf APS ack verlassen. Ist das korrekt? Funktioniert das in BitCloud so?
Außerdem: Wenn das Bestätigungsanforderungsbit in der APS-Schicht nicht gesetzt ist, wird dies als erfolgreiche Übertragung angesehen (da keine Bestätigung zu erwarten ist) und erhöht dies die "Rate" dieses Routeneintrags? Denn wenn ja, könnten wir uns in den Fuß schießen, indem wir nicht ständig APS Layer ACK anfordern.

Wenn es nur auf NWK-Fehlern basiert, hilft dies nicht der Situation, dass sich ein Zwischenrouter schlecht verhält, und wir müssen zusätzliche Logik hinzufügen, um zu berücksichtigen, dass ACKs der APS-Schicht nicht ankommen. Vermutlich basierend auf einer ähnlichen Logik zur Erkennung von "Zombie" -Routern, aber zuerst durch Ungültigmachen des Routentabelleneintrags für diese Route.

Die Firmware-Version 0x26350500 für ConBee I und RaspBee I steht zum Testen zur Verfügung.

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26350500.bin.GCF

• Wie bei 0x26340500 werden alle NWK-Statusroutenfehler behandelt
• Behebung einer ungerechten Routenverschlechterung (siehe Punkt 2. in https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment-596142584)
• Fix Routendatensätze haben den nächsten Sprung einer Route nicht aktualisiert. Beachten Sie, dass dies jetzt funktioniert, jedoch nur, wenn die aktuellen Routenkosten beim Routendatensatz höher sind
• Behebung fehlgeschlagener APS-Anforderungen mit aktiviertem APS-ACK hat die Route nicht beeinträchtigt

Ich schaue jetzt im ConBee II-Code nach, ob und wo diese Korrekturen angewendet werden können. 0x26520700 und 0x26530700 werden verworfen und dies basiert auf dem aktuellen stabilen 0x264a0700.

Ich verstehe die Logik hinter Regel 2 nicht wirklich. Es scheint eine Art Version des Alterns eines armen Mannes zu sein. Das funktioniert ganz gut, wenn alle Knoten eine ähnliche Menge an Verkehr sehen, aber wenn es unausgeglichen ist (was meiner Meinung nach ziemlich häufig ist), wird es schief gehen.
Ich habe festgestellt, dass der ZStack ein aktuelles expiryTime-Feld in seiner Routing-Tabelle neben einem Statusbyte verwendet.

Völlig einverstanden, dies ist jetzt behoben, so dass nur die Route einer erfolgreichen Übertragung normalisiert wird, wenn die Rate das Maximum erreicht. Die abgelaufene Timer-Methode, um dies zu handhaben, ist möglicherweise eine weitere Option, hat jedoch ihre eigenen Fallstricke im Maßstab. Ich denke, die "Rate" -Methode sollte ziemlich gut funktionieren, ohne von der Netzwerkgröße und -zeit abhängig zu sein.

Wenn es nur auf NWK-Fehlern basiert, hilft dies nicht der Situation, dass sich ein Zwischenrouter schlecht verhält, und wir müssen zusätzliche Logik hinzufügen, um zu berücksichtigen, dass ACKs der APS-Schicht nicht ankommen. Vermutlich basierend auf einer ähnlichen Logik zur Erkennung von "Zombie" -Routern, aber zuerst durch Ungültigmachen des Routentabelleneintrags für diese Route.

Dies schien der Fall zu sein, und tatsächlich könnten sich schlecht verhaltende Router, die keine NWK-Statusbefehle mit Routenfehlern senden, eine tote Route am Leben erhalten. Dies ist jetzt in 0x26350500 behoben, basiert jedoch auf APS ACK-fähigen Befehlen. Was in Ordnung sein sollte und von deCONz und dem REST-API-Plugin gesteuert werden kann.

Die Firmware-Version 0x26350500 für ConBee I und RaspBee I steht zum Testen zur Verfügung.

Hat es geflasht und jetzt getestet.

Dies ist jetzt in 0x26350500 behoben, basiert jedoch auf APS ACK-fähigen Befehlen.

Was tun Sie als Reaktion auf eine fehlende ACK? Halbieren Sie den rate wie bei einer fehlgeschlagenen NWK-Übertragung oder mehr / anders? Weil ich denke, dass eine fehlende APS-ACK im Vergleich zu einer fehlgeschlagenen NWK-Übertragung als schwerwiegender angesehen werden sollte. Andernfalls können im Falle eines Routers, der sich schlecht verhält, die erfolgreichen NWK-Übertragungen die rate mehr erhöhen, als die fehlenden APS-ACKs sie senken.

Was tun Sie als Reaktion auf eine fehlende ACK? Halbieren Sie den Ratenwert wie bei einer fehlgeschlagenen NWK-Übertragung oder mehr / anders? Weil ich denke, dass eine fehlende APS-ACK im Vergleich zu einer fehlgeschlagenen NWK-Übertragung als schwerwiegender angesehen werden sollte. Andernfalls können im Fall eines Routers, der sich schlecht verhält, die erfolgreichen NWK-Übertragungen die Rate stärker erhöhen als die fehlenden APS-ACKs sie senken.

Ich dachte das gleiche, hier ist was in diesem Fall passiert:

• NWK-Übertragung positiv MAC ACK rate + 1
• Kein APS ACK rate = rate / 4

Die Rate sinkt also ziemlich schnell, ist vielleicht etwas zu aggressiv und rate / 2 ist genug, aber lassen Sie uns sehen, wie es in der Praxis funktioniert.

Nett. Ich werde es ausführen und zurückmelden.

Derzeit werden auch Stresstests durchgeführt, indem alle paar Sekunden Unicast-Nachrichten (OnOffwithLevel) an ein Licht gesendet werden, das ziemlich weit im Netz entfernt ist.

Übrigens habe ich auch den Rest-Plugin-Code geändert, um APS ACK in allen Nachrichten anzufordern.

Ich starte Deconz auf einem Rpi 3B + mit Home Assistant
Derzeit läuft 2.05.75 mit Conbee I und 26330500

Heute Abend bemerkt, dass einige Lichter nicht eingeschaltet waren.
Es wurde versucht, sie manuell einzuschalten (siehe Protokoll unten).
Das VNC-Netz wurde überprüft, es ist Teil des Netznetzwerks, reagiert jedoch auf nichts.
Dieser Knoten ist ein Tradfri-Ein- / Ausschalter.

Seltsame Sache hier:
_Ich KANN den Schalter einschalten, wenn ich die Deconz-Gruppe anstelle des einzelnen Schalters aktiviere._

19: 23: 58: 979 Verzögerung beim Senden der Anforderung 57 dt 0 ms an 0x000D6FFFFEB1C9FF, ep: 0x01 Cluster: 0x0004 onAir: 1
19: 24: 15: 744 Aktueller Kanal 25
19: 24: 15: 776 Flags des Geräts TTL 3920: 0x7
19: 24: 46: 764 0x000D6FFFFEB1C9FF Fehler APSDE-DATA.confirm: 0xA7 bei Task
19: 25: 10: 547 0x000D6FFFFEB1C9FF Fehler APSDE-DATA.confirm: 0xA7 bei Task
19: 25: 15: 749 Aktueller Kanal 25
19: 25: 15: 782 Flaggen des Geräte-TTL 3860: 0x7
19: 25: 33: 885 0x000D6FFFFEB1C9FF Fehler APSDE-DATA.confirm: 0xA7 bei Task
19: 25: 49: 411 0x000D6FFFFEB1C9FF Fehler APSDE-DATA.confirm: 0xA7 bei Task
19: 26: 12: 765 0x000D6FFFFEB1C9FF Fehler APSDE-DATA.confirm: 0xA7 bei Task
19: 26: 12: 765 max Übertragungsfehler für Knoten 0x000D6FFFFEB1C9FF, zuletzt gesehen von Nachbarn 25 s
19: 26: 15: 742 Aktueller Kanal 25
19: 26: 15: 774 Flag des Geräts TTL 3800 s: 0x7
19: 26: 48: 221 0x000D6FFFFEB1C9FF Fehler APSDE-DATA.confirm: 0xA7 bei Task
19: 26: 48: 221 max Übertragungsfehler für Knoten 0x000D6FFFFEB1C9FF, zuletzt gesehen von Nachbarn 60 s
19: 27: 03: 845 gespeicherter Knotenstatus in 9 ms
19: 27: 33: 634 sync () in 29789 ms

Die neuesten Korrekturen sind in 26350500 ...

@djwlindenaar Ich halte den Atem an und

So weit, ist es gut. Ich kann sehen, wie deCONZ glücklich die Route wechselt. :Lächeln:

Die neuesten Korrekturen sind in 26350500 ...

Entschuldigung, die FW-Version falsch verstanden.
Ich möchte beim Testen helfen, indem ich das offizielle Home Assistant Deconz-Add-On verwende. Ich bin mir nicht sicher, wie ich dieses auf eine Beta-Firmware aktualisieren soll. (offizielle Updates sind OTA)

Lieber @manup , gibt es einen Status für das Conbee II FW-Update?

@manup , es sieht so aus, als gäbe es keine Aktion für Many-to-One Route Failure (0x0c) . Ich würde erwarten, dass deCONZ erneut eine MTORR durchführt (es sei denn, eine ist bereits in Bearbeitung). Ich bekomme diese Nachrichten regelmäßig.

Command Frame: Network Status
    Command Identifier: Network Status (0x03)
    Status Code: Many-to-One Route Failure (0x0c)
    Destination: 0x499e[Tuin rechtsachter 2]

@manup , es scheint, dass das route record immer noch nicht immer von deCONZ übernommen wird. Zum Beispiel:

No.                Time               Source             Transmit Dev       Receive Dev        Destination        Disable Default Response              Acknowledgement Request               Info
700766             13h 27m 35.628249s Tuin linksvoor 2   Tuin linksvoor 2   DeConz             DeConz                                                   Route Record, Dst: 0x0000
700784             13h 27m 39.591343s DeConz             DeConz             WC lamp            Tuin linksvoor 2   True               True               ZCL Level Control: Move to Level with OnOff, Seq: 162
700786             13h 27m 39.597002s DeConz             WC lamp            Tuin linksvoor 1   Tuin linksvoor 2   True               True               ZCL Level Control: Move to Level with OnOff, Seq: 162
700788             13h 27m 39.600699s DeConz             Tuin linksvoor 1   Tuin linksvoor 2   Tuin linksvoor 2   True               True               ZCL Level Control: Move to Level with OnOff, Seq: 162

Das Licht Tuin linksvoor 2 sendet direkt an deCONZ , aber der Weg von deCONZ führt über mehrere Hopfen ...
Es wäre hilfreich, wenn Sie einen Einblick in den Entscheidungsprozess in deCONZ geben könnten, um die Route aus der route record -Nachricht mit Ja / Nein zu akzeptieren.

--- habe die folgenden Punkte bearbeitet, weil meine Argumentation fehlerhaft war. Jetzt hoffentlich nicht: zwinker: ---

Allerdings ist die Route, die von deCONZ wird, tatsächlich viel zuverlässiger als die direkte Kommunikation mit Tuin linksvoor 2 . Dies brachte mich dazu, mich zu wundern und in das Viele-zu-Eins-Routing zu schauen. Ich denke, dass die Sendeleistung der Raspbee vielleicht nicht ideal ist ...
Das ist meine Argumentation:

• Das Viele-zu-Eins-Routing basiert auf dem Empfang von Sendungen
• Im Gegensatz zur normalen Routenbehandlung wird das Maximum der Kosten für eingehende und ausgehende Pfade als Kosten für den nächsten Hop verwendet
• Wenn ein Router oder der Koordinator beim Senden (hohe Sendeleistung) viel besser ist als beim Empfangen (niedrige Empfangsempfindlichkeit), kann dies dazu führen, dass das Viele-zu-Eins-Routing nicht sehr gut funktioniert.

Ein verwandter Punkt, den ich bemerkt habe, ist, dass deCONZ hinsichtlich der eingehenden Kosten in seiner Routentabelle (sehr) optimistisch zu sein scheint. Wenn Tuin linksvoor 2 eine Nachricht direkt an deCONZ Tuin linksvoor 2 sendet, sind ständig viele Wiederholungen erforderlich. Wenn ich jetzt in die Routentabelle schaue, sehe ich Folgendes und würde keine schwierige Übertragung bei eingehenden Kosten von 4 erwarten. Beachten Sie, dass grundsätzlich alle Elemente in der Routentabelle viel niedrigere eingehende Kosten haben als ausgehende Kosten.

Link 4
    Address: 0x0ea5[Tuin linksvoor 2]
    .... .100 = Incoming Cost: 4
    .111 .... = Outgoing Cost: 7

Wenn deCONZ also weniger optimistisch in Bezug auf die eingehenden Kosten wäre, könnten wir ein besseres Routenverhalten feststellen. Oder wenn wir die Sendeleistung erhöhen würden, um ausgeglichener zu sein (ähnliche Kosten für Ein- und Ausgang)
Oder wenn wir die Sendeleistung von deCONZ verringern würden, müssten wahrscheinlich mehr Hops weitergeleitet werden (die Kosten für 7 Geräte würden aus der Routentabelle herausfallen), aber es wird auch einfacher sein, eingehende Nachrichten zu empfangen.

Gesamtliste aus der deCONZ-Linkstatusmeldung:

Command Frame: Link Status
    Command Identifier: Link Status (0x08)
    .1.. .... = Last Frame: True
    ..1. .... = First Frame: True
    ...1 0010 = Link Status Count: 18
    Link 1
        Address: 0x0118[Buiten - R schuur]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 2
        Address: 0x0143[HK stalamp]
        .... .010 = Incoming Cost: 2
        .101 .... = Outgoing Cost: 5
    Link 3
        Address: 0x05b5[HK houtlamp 2]
        .... .010 = Incoming Cost: 2
        .101 .... = Outgoing Cost: 5
    Link 4
        Address: 0x0ea5[Tuin linksvoor 2]
        .... .100 = Incoming Cost: 4
        .111 .... = Outgoing Cost: 7
    Link 5
        Address: 0x1ad3[HK plafond ledstrip]
        .... .010 = Incoming Cost: 2
        .001 .... = Outgoing Cost: 1
    Link 6
        Address: 0x1ff6[Tuin linksvoor 1]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 7
        Address: 0x4b4d[Keuken mid]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 8
        Address: 0x5693[Keuken Rechts]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 9
        Address: 0x68c4[WC lamp]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 10
        Address: 0x6c35[Buiten - L schuur]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 11
        Address: 0x731e[Kerstverlichting]
        .... .011 = Incoming Cost: 3
        .011 .... = Outgoing Cost: 3
    Link 12
        Address: 0x7d2a[0x7d2a]
        .... .011 = Incoming Cost: 3
        .101 .... = Outgoing Cost: 5
    Link 13
        Address: 0xa3f5[HK zoutlamp]
        .... .010 = Incoming Cost: 2
        .001 .... = Outgoing Cost: 1
    Link 14
        Address: 0xc7bc[Hal lamp]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 15
        Address: 0xc9fa[Tuin linksvoor 3]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 16
        Address: 0xd6b7[Zolder Noord Lamp]
        .... .010 = Incoming Cost: 2
        .101 .... = Outgoing Cost: 5
    Link 17
        Address: 0xde81[On/Off light 36]
        .... .010 = Incoming Cost: 2
        .001 .... = Outgoing Cost: 1
    Link 18
        Address: 0xefd5[Zoldertrap Lamp]
        .... .010 = Incoming Cost: 2
        .001 .... = Outgoing Cost: 1

Entschuldigung für die Verspätung. Status: Wir arbeiten immer noch hart an der neuen Version und suchen nach Fehlern in der Firmware, die komplexer zu sein scheinen, als wir dachten. Etwas in der NVRAM-Handhabung scheint aus zu sein. Wir versuchen auch, die Probleme mit der USB-Aufzählung / dem Start zu beheben.

Ich werde hier Updates veröffentlichen, sobald sie verfügbar sind.

Update: immer noch stark!

Ich glaube nicht, dass ich das Netzwerk jemals so stabil gesehen habe. Ich habe inzwischen verschiedene Regeln geändert, um Unicast anstelle von Gruppen zu verwenden. Jetzt für 2 Wochen und 0 IKEA Lichter gingen aus.

(Hoffe ich verhexe es jetzt nicht)

Beachten Sie, dass ich das REST-Plugin geändert habe, um APS-Bestätigung für alle Anforderungen anzufordern.

Ich habe auch ein viel besseres Netzwerk. Nicht 100%. Es gab gelegentlich Lampen, die nicht reagierten, aber als ich die IKEA-Lampe manuell änderte, reagierte sie. Ich sehe auch, dass der Status der Glühbirne jetzt so ist wie der physische Status.
Eine meiner Osram-Glühbirnen reagierte jedoch nicht mehr so ​​gut wie die Ikea-Glühbirnen zuvor. Das Positive ist, dass es nicht so schwer ist wie die Ikea.

Ich hoffe, dies kann von anderen bestätigt oder festgestellt werden.

Ich verwende Conbee 1 mit FW 26350500 und Deconz 2.05.75.
Dies ist meine Erfahrung in den letzten Wochen

• Funktioniert besser, aber nicht zu 100%
• Einige meiner IKEA E27 TRÅDFRI-Lampen E27 WS opal 980lm mit fw 2.3.007 antworten manchmal nicht auf AUS-Befehle
• Ich kann einfach versuchen, sie wieder auszuschalten, und es funktioniert normalerweise (kein Aus- und Einschalten erforderlich)

@djwlindenaar schön! Ist Ihr APS-Fix für die REST-API in der Version .75 enthalten? Nur damit ich weiß, ob das einige Unterschiede in früheren Beiträgen erklären könnte ...

Nein, ist es nicht. Ich habe noch nicht einmal eine Pull-Anfrage dafür erstellt. Damit können Sie es selbst bauen. Ich mache das heute oder morgen.
Ich kann auch das eingebaute Rest-API-Plugin teilen, aber ich habe nur das für Himbeere 3.

@tubalainen , ich werde prüfen, ob das mit dem APS ack erklärt werden kann. Außerdem habe ich keine 2.3 IKEA Lichter.

Möglicherweise liegt ein Problem mit dem Wiederholungsverhalten in deCONZ vor. Ich müsste dafür ein Experiment machen oder vielleicht ist es bereits in den Schnüffelprotokollen.

Wenn Sie schnüffeln können, würde es helfen, an diesem Phänomen zu schnüffeln. Ich kann helfen zu analysieren, wenn Sie nicht können.

Mein Produktionsnetzwerk (RPi 3B +, Stretch, RaspBee) wurde gestern auf 2.05.74 und 0x26340500 aktualisiert. Scheint stabil, mit Ausnahme der folgenden Probleme.
Ich bin mir nicht sicher, ob ich verwandt bin, aber der Weg zu meinem Vorhang-Controller lumi.curtain ist heute Morgen verloren gegangen. Berichte des Controllers würden weiterhin das Gateway erreichen. Die Route wird beim Aus- und Einschalten des Controllers nicht wiederhergestellt. Ich musste das Netzwerk öffnen und den Controller aus- und wieder einschalten, bevor der Koordinator ihn wieder erreichen konnte.
Außerdem war eines meiner Eurotronic Spirit-Heizkörperventile nach dem Start von deCONZ für deCONZ nicht erreichbar, während weiterhin Berichte gesendet wurden. Das Einschalten des TRV brachte es wie gewohnt zurück.
Diesmal hatte ich keine Gelegenheit, eingehende Untersuchungen durchzuführen, aber beide Geräte waren von Anfang an problematisch und zeigten diese Symptome gelegentlich. Gleiches gilt für meinen IKEA Fyrtur Blind. Ich werde die Situation weiterhin überwachen und zurückmelden, wenn weitere Probleme auftreten.

Es ist sehr schwer, diese zeitweiligen Probleme objektiv aufzuzeichnen, aber ich habe den Eindruck, dass 0x26350500 hier Verbesserungen gebracht hat. Abgesehen von den oben genannten Geräten ist mein Netzwerk sehr stabil. Ich hatte einige TRVs, die vom Gateway aus nicht mehr erreichbar waren, aber meistens (nur?) Nach dem Neustart von deCONZ. Ich glaube nicht, dass die FYRTUR oder der Vorhang-Controller in den letzten drei Wochen MIA gegangen sind.

Beachten Sie, dass ich das REST-Plugin geändert habe, um APS-Bestätigung für alle Anforderungen anzufordern.

Ich habe APS-Bestätigungen in den Netzwerkeinstellungen in der GUI aktiviert, bin mir jedoch nicht sicher, ob dies nur für die von der GUI gesendeten Nachrichten oder auch für das REST-API-Plugin gilt.

Wenn Sie mit der obigen Pull-Anforderung ausgeführt werden möchten, können Sie auch meine Gabel auschecken und Folgendes erstellen: djwlindenaar / deconz-rest-plugin

@ebaauw , soweit ich das

Ich habe einen Schnüffler, der ununterbrochen läuft, und nicht die Wanduhrzeit, wenn ein Problem auftritt. Normalerweise kann ich mit diesen Informationen die Pakete ziemlich leicht finden ...

Übrigens habe ich viele meiner Regeln (insbesondere die, die häufig ausgelöst werden) auf Unicast umgestellt. Soweit funktioniert das super. Außerdem habe ich in den letzten 2 Wochen ein IKEA-Licht betrieben, das die Helligkeit kontinuierlich ändert (etwa alle 4 Sekunden). Das ist auch noch in Ordnung.

Nun ... Ich habe gerade etwas Ungewöhnliches in meinen Protokollen bemerkt. Ich stellte fest, dass keines der Lichter, die ich aus- und wieder einschaltete, ihre Attribute meldete. Ich dachte, ich hätte einen anderen Fehler, aber ich war es nicht, obwohl ich denke, dass wir dies sowieso als Fehler betrachten möchten.

Wie bereits erwähnt, wurde alle paar Sekunden ein Skript ausgeführt, um die Lichtstärke zu ändern. Ich denke, dass dies Probleme mit IKEA-Leuchten beschleunigen könnte. Es stellt sich heraus, dass dadurch der Zähler d->idleLastActivity , wodurch verhindert wird, dass Leerlaufaufgaben ausgeführt werden. Einschließlich der Konfiguration der Attributberichterstattung: rofl:

Wollen Sie damit sagen, dass die IKEA-Leuchten nach einem Aus- und Wiedereinschalten ihre Bindungs- und Attributberichtskonfiguration verlieren?!

Sieht so aus ... Sollten sie nicht ...?

Mein Problem ist jetzt, dass mein Docker-Container seit dem Upgrade meines Setups auf .75 und 50500 mindestens einmal pro Woche den Conbee verliert. Durch einen Neustart des Containers geht es wieder los ... SEHR nervig

@djwlindenaar , nein, ich denke nicht, dass sie sollten. Die meisten Geräte, die ich gesehen habe, speichern diese Einstellungen im nichtflüchtigen Speicher. Ich nehme an, der ZigBee-Standard lässt Raum für beide Verhaltensweisen.

Während meine IKEA-Lampen jetzt viel besser laufen, reagiert einer meiner Xiaomi-Sensoren (runder Temperatursensor) nach einer Weile leider nicht mehr. Ich werde versuchen, in den nächsten Tagen Beweise zu sammeln, indem ich schnüffle.

Ich verwende Conbee 1 mit FW 26350500 und Deconz 2.05.75.
Dies ist meine Erfahrung in den letzten Wochen

• Funktioniert besser, aber nicht zu 100%
• Einige meiner IKEA E27 TRÅDFRI-Lampen E27 WS opal 980lm mit fw 2.3.007 antworten manchmal nicht auf AUS-Befehle
• Ich kann einfach versuchen, sie wieder auszuschalten, und es funktioniert normalerweise (kein Aus- und Einschalten erforderlich)

@tubalainen Hallo, ich habe das andere Verhalten von ikea mit 2.3.x Firmware im Vergleich zu 1.2.x bemerkt. Ich habe versucht, es anzusprechen, bekam aber keine Aufmerksamkeit. Ich habe meine Glühbirnen auf 1.2.x herabgestuft und es funktioniert jetzt wie ein Zauber. Am 2.3.x. Sie können nach einem Szenenaufruf für einen bestimmten Zeitraum nicht ausschalten. Normal ein aus hat funktioniert. Seltsames Verhalten. Vielleicht möchten Sie hier testen und einen Beitrag leisten. Prost https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518

Wollen Sie damit sagen, dass die IKEA-Leuchten nach einem Aus- und Wiedereinschalten ihre Bindungs- und Attributberichtskonfiguration verlieren?!

Leider verlieren sie nach einem Aus- und Einschalten ihre Bindungen. Der Code wurde vor einiger Zeit angepasst, um dies zu beheben. Bindungen und Konfiguration werden wiederhergestellt, nachdem ein Licht aus- und wieder eingeschaltet wurde, auch wenn für eine Weile keine Berichte empfangen wurden. Der Prozess wird gestartet, um sie wiederherzustellen.

@realwax wird bei allen meinen E27-Lampen auf 1.2.x herunterrüsten und zurückmelden. (dauert einige Zeit :)).

Gestern haben sich zwei E27-Lichter (mit 2,3x FW) während der Morgensequenz nicht ausgeschaltet.

@tubalainen Verwenden Sie Gruppenbefehle oder Unicast-Befehle? (dh über die REST-API den Status über / groups / oder / opens / festlegen)

Ich denke, solange Lichter erreichbar sind, sind Unicast-Befehle zuverlässiger. Wenn ein Gruppenübertragungsbefehl irgendwie übersehen wird, wird er nicht wiederholt. Unicast-Befehle werden einige Male oder bis zur Übermittlung wiederholt.

@tubalainen Verwenden Sie Gruppenbefehle oder Unicast-Befehle? (dh über die REST-API den Status über / groups / oder / opens / festlegen)

Ich denke, solange Lichter erreichbar sind, sind Unicast-Befehle zuverlässiger. Wenn ein Gruppenübertragungsbefehl irgendwie übersehen wird, wird er nicht wiederholt. Unicast-Befehle werden einige Male oder bis zur Übermittlung wiederholt.

Ich benutze Home Assistant und die RESt-API. Ich weiß nicht, was Home Assistant macht ...

In meinem Fall ist es iobroker mit Deconz Plug-In und Phoscon ... Also Rest API. Die Probleme treten bei der Verwendung von igroups auf. Ein Gruppenszenenrückruf löst aus, dass die Gruppe nicht ausgeschaltet oder schnell in andere Gruppenszeneneinstellungen geändert oder ordnungsgemäß ausgeschaltet werden kann, insbesondere innerhalb von bis zu 15 Sekunden nach dem Szenenrückruf. Es scheint, als ob deconz vorher mit dem Befehl beschäftigt ist oder 2.3.x fw Glühbirnen einfrieren (was ich bezweifle). Ich kann noch nicht auf ZigBee-Ebene debuggen, um ein besseres Verständnis zu erhalten. Ist die Gruppierungsfunktion von deconz eine virtuelle Ebene, die in Uni-Cast-Befehle übersetzt wird, oder erfolgt sie über Gruppierungsoptionen, die in der GUI / ZigBee verfügbar sind? Fazit Ich verwende die eingebaute Gruppenfunktion, sonst müsste ich diese virtuelle Schicht in iobroker erstellen und es gibt keinen Grund, da die Gruppierungsfunktion gut ist. Also, wenn es die Gruppierung ist ... Was ist der Unterschied, da es 100% mit fw 1.2.x und nicht mit 2.3.x scheint. Was hat sich geändert? Ist es ZigBee 2, warum sie sich anders verhalten?

@tubalainen Ja, das ist eine Menge Arbeit, da Sie möglicherweise von Zeit zu Zeit neu starten oder einige Glühbirnen näher bringen müssen. Ich habe es zweimal mit 20 e14 tradfri gemacht. Sie sollten eine enorme Verbesserung sehen. Bemerken Sie, dass sich Ihre Lampen mit 2.3..x nicht weich einschalten? (einblenden) mehr und 1.2.x tun?

ABER Daumen drücken, dass mehr es reproduzieren können, so dass ikeas fw 2.3.x in deconz funktionsfähig wird, da es einen Zeitpunkt geben wird, an dem wir ein Upgrade durchführen müssen. Oder Glühbirnen ersetzen. Obwohl ZigBee 2 auch schön wäre.

Vielen Dank für Ihre Bemühungen!

@realwax @djwlindenaar @manup

Letzte Nacht ging ein Licht nicht so aus, wie es sollte (IKEA E27 mit fw 2.3.x). Ich habe getestet, um die Helligkeit des nicht ausgeschalteten Lichts zu ändern, und es hat sich sofort auf die von mir ausgewählte Helligkeitseinstellung geändert. Momente nach dem Ändern der Helligkeit reagierte das Licht plötzlich auch gut auf den Ausschaltbefehl.

Ich persönlich habe jetzt alle meine Automatisierungen in Home Assistant geändert, um zuerst die Helligkeit zu ändern, 2 Sekunden zu warten und dann den Ausschaltbefehl zu senden.

Bisher 100% Erfolgsquote.

Ich hoffe, dies kann ein Hinweis auf die Untersuchung sein.

EDIT: Es sind immer noch die Lichter, die am weitesten von der Koordination entfernt sind (der Conbee-Stick), die sich nicht ausschalten lassen. (Lichter, die aufgrund der Art des Frequenzbandes ineinander greifen müssen)

Hallo Leute!

Ich wollte nur meine Probleme ansprechen ...
Nachdem ich Stabilitätsprobleme mit meinem ConBee II-Stick hatte, überprüfte ich die Firmware-Version. Es war 26530700. Ich habe dann ein Downgrade auf 264a0700 durchgeführt, und danach kann keine Anwendung den Stick sehen. Ich habe HomeAssistant und deCONZ ausprobiert. Das Host-Betriebssystem identifiziert den Stick OK und GCFFlasher funktioniert.

Hallo Leute!

Ich wollte nur meine Probleme ansprechen ...
Nachdem ich Stabilitätsprobleme mit meinem ConBee II-Stick hatte, überprüfte ich die Firmware-Version. Es war 26530700. Ich habe dann ein Downgrade auf 264a0700 durchgeführt, und danach kann keine Anwendung den Stick sehen. Ich habe HomeAssistant und deCONZ ausprobiert. Das Host-Betriebssystem identifiziert den Stick OK und GCFFlasher funktioniert.

Nach dem Downgrade auf 26490700 scheint alles wieder zu funktionieren ... Stabiles ZigBee-Netz seit 24 Stunden ....

Irgendwelche Updates? Ich möchte wirklich mein ganzes Haus auf meinen Conbee II umstellen, aber im Moment ist es sehr instabil. Mein Farbton funktioniert perfekt, Conbee II nicht so sehr 🥺

Meine Erfahrung mit der neuesten deCONZ .75 mit RaspBee FW 0x26350500 ist bisher sehr gut.

Meine Geräte:
4xTradfri 980lu WS Lichter - FW 2.3.007
17xTradfri 1000lu WS Lichter - FW 2.0.023
3xTradfri-Stecker - FW 2.0.022
3xTradfri Round Remotes E1810 - FW 2.3.014
4xAqara THP-Sensoren

Es wurde eine andere gefunden, die die Firmware der IKEA-Lampe zum Absturz bringt. (und ich denke, es kann in deConz behoben werden)

Ich habe heute Morgen ein Licht gesehen, das nicht reagiert hat. Die letzte Mitteilung wird unten gezeigt.

Es sieht so aus, als ob deConz die Antwort auf die Gruppenmitgliedschaft erhält, aber irgendwie wird die vom Licht gesendete APS-ACK (Bestätigung der Anforderung zur Gruppenmitgliedschaft abrufen) von deConz nicht empfangen (ich sehe auch keine MAC-ACK). Infolgedessen sendet deConz die Anfrage erneut. Diese Anfrage hat dieselbe Nummer im ZCL, wodurch die Light-Firmware abstürzt.

Ich denke, deConz könnte die Anfrage als bestätigt betrachten, sobald die entsprechende Antwort eintrifft, und vermeiden, eine weitere Anfrage einzureichen. Recht? Gibt es eine API für das Plugin, die aufgerufen werden kann, um eine Anfrage abzubrechen? @manup?

Beachten Sie, dass dieser spezielle Fehler auch umgangen wird, indem das APS ACK für diese Anforderungen nicht angefordert wird. Dies ist die Standardeinstellung im aktuellen REST-API-Plugin.

No.               Time              Source            Transmit Dev      Receive Dev       Destination       Disable Default Response            Acknowledgement Request             Info
74174             2h 48m 12.832154s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2     True              True              ZCL Groups: Get Group Membership, Seq: 32
74176             2h 48m 12.841977s HK houtlamp 2     HK houtlamp 2     DeConz            DeConz                                                Route Record, Dst: 0x0000
74178             2h 48m 12.847098s HK houtlamp 2     HK houtlamp 2     DeConz            DeConz                                                Route Record, Dst: 0x0000
74180             2h 48m 12.890302s HK houtlamp 2     HK houtlamp 2     DeConz            DeConz            True              True              ZCL Groups: Get Group Membership Response, Seq: 32
74182             2h 48m 12.896074s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2                       False             APS: Ack, Dst Endpt: 1, Src Endpt: 1
74183             2h 48m 12.899402s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2                       False             APS: Ack, Dst Endpt: 1, Src Endpt: 1
74184             2h 48m 12.902460s HK houtlamp 2     HK houtlamp 2     DeConz            DeConz                              False             APS: Ack, Dst Endpt: 1, Src Endpt: 1
74185             2h 48m 12.904330s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2                       False             APS: Ack, Dst Endpt: 1, Src Endpt: 1
74190             2h 48m 14.186599s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2     True              True              ZCL Groups: Get Group Membership, Seq: 32
76346             2h 52m 41.998416s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2                       True              Link Quality Request
76354             2h 52m 43.668838s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2                       True              Link Quality Request
202171            7h 39m 10.905361s HK houtlamp 2     HK houtlamp 2     Broadcast         Broadcast                           False             Device Announcement, Nwk Addr: 0x05b5, Ext Addr: SiliconL_ff:fe:c5:2c:7d

Laufen v2.05.75 mit 0x26350500 seit ein paar Wochen. Es scheint etwas stabiler zu sein als frühere Versionen, aber ich verliere gelegentlich immer noch den Weg zu meinen Eurotronic Spirit TRVs, meinem Fyrtur Blind und meinem Xiaomi lumi.curtain Curtain Controller. Letzterer ist ein Router; Die anderen sind Endgeräte. Alle TRVs haben dieselbe Hardware- / Firmware-Version, aber einige gehen häufiger auf MIA als andere. Die Symptome sind konsistent: Das Gerät sendet weiterhin Berichte an den Koordinator, aber Befehle vom Koordinator führen nur zu einer unbeantworteten Routenanforderung.

Derzeit wird der Verkehr für den TRV, der am häufigsten vermisst wird, beschnüffelt und analysiert. Berichte erreichen den Koordinator in drei Schritten, wobei zwei Farbtonlichter verwendet werden. Ich habe auch eine Datenanforderung von der TRV zum ersten Licht auf dem Weg erfasst, so dass die TRV froh zu sein scheint, dass dies ihre übergeordnete Person ist. Übereinstimmende Deskriptoranforderungen von der TRV für den OTAU-Cluster bleiben unbeantwortet. Das übergeordnete Element meldet das nächste Licht in seinem Linkstatus, jedoch nicht das TRV (weil es ein Endgerät ist?).

Die _Link Quality Response_-Nachrichten zeigen eine Nachbartabelle mit 20 Einträgen, aber die TRV gehört nicht dazu. Ein Xiaomi Türsensor (der seit jeher stabil ist) ist. Seltsamerweise ist dies auch der Koordinator, doch der Bericht vom TRV an den Koordinator wurde über einen anderen Router weitergeleitet (der sich ebenfalls in der Nachbartabelle befindet).
OK, jetzt ist der Koordinator auch im Linkstatus enthalten und der nächste Bericht von der TRV wird direkt an den Koordinator weitergeleitet.

Das TRV wurde aus- und wieder eingeschaltet. Die TRV sendet eine MAC-Datenanforderung an das (frühere) übergeordnete Element. Der Router antwortet mit einer _Rejoin Response_, die die alte NWK-Adresse des TRV als neue Adresse übergibt. Die TRV sendet dann die Geräteankündigung (MAC-Unicast an das übergeordnete Element; das übergeordnete Element wird als MAC-Übertragung weitergeleitet). Die TRV sendet eine Endgeräte-Timeout-Anforderung an das übergeordnete Element. Das übergeordnete Element sendet ein Aktualisierungsgerät an den Koordinator und teilt ihm mit, dass der TRV sicher wieder verbunden ist. Das übergeordnete Element sendet jetzt auch eine Routenantwort an die Routenanforderung des Koordinators. In der nächsten _Link Quality Response_-Sequenz ist die TRV enthalten.

Ich werde den Schnüffler am Laufen halten, hoffentlich um den Moment einzufangen, in dem der TRV wieder vermisst wird.

Ein möglicherweise verwandter Hinweis: Einer meiner innr SP120-Smart-Stecker glaubt immer noch, dass dies der übergeordnete Punkt für die Hue-Taste ist, die ich kurz mit meinem Produktionsnetzwerk verbunden habe, während ich Unterstützung hinzugefügt habe. Der Button ist seit einigen Wochen mit meinem Testnetzwerk verbunden, und ich habe den Stecker mehrmals aus- und wieder eingeschaltet. Muss ich den Stecker auf die Werkseinstellungen zurücksetzen, damit das verlorene Kind vergessen wird?

@manup , lange her seit jeder Aktualisierung sowohl im Code als auch in Informationen darüber, was los ist. Könnten Sie uns bitte ein Update über die Fortschritte Ihres Teams in Bezug auf Stabilitätsprobleme geben und wenn Sie sich auch einen erwarteten Zeitplan trauen.

Ich habe ein weiteres Problem im Routing-Verhalten von deConz gefunden.

In diesem Fall versucht deConz, die Nachricht über Tuin linksvoor 3 an Hal lamp weiterzuleiten. Wenn man sich aber den Link Status Bericht von Tuin linksvoor 3 ansieht, weiß man nichts über Hal lamp . Und anscheinend weiß es auch nicht, wie man es durch Routing erreicht. Natürlich sollte sich dieses Licht (IKEA) verhalten und mit einer Fehlermeldung antworten, aber das tut es nicht und wir können das nicht ändern.
DeConz kommt jedoch zu dem Schluss, dass das Hal lamp ein Zombie ist, ohne zu versuchen, einen neuen Weg zu diesem Licht zu finden. Ich bin mir nicht sicher, wie das mit dem (neuen) Routing-Code interagiert, aber irgendwie hat es diese Route nicht schnell genug verschlechtert, um zu verhindern, dass sie als Zombie gekennzeichnet wird. (Übrigens ist es wirklich nicht, siehe weiter ...)

Dies verursachte ein vorübergehendes Problem, das sich nach wenigen Minuten von selbst löste (was natürlich völlig inakzeptabel ist). Weil das Hal lamp beschließt, einen Attributbericht zu senden, für den es keine APS-Bestätigung erhält und daher einen Route Request -Prozess startet. Erst jetzt, nachdem dies abgeschlossen ist, ändert deConz seine Route in Hal lamp und die Kommunikation wird wie gewohnt fortgesetzt.

Ich frage mich, wie lange es gedauert hätte, wenn das Licht nicht beschlossen hätte, eine Nachricht an deConz zu senden. (Beachten Sie, dass ich in meinem Netzwerk die IKEA-Anzeigen mit regelmäßigen Attributberichten für Ein / Aus- und Ebenen-Cluster alle 5 Minuten ausführe.)

No.                Time               Source             Transmit Dev       Receive Dev        Destination        Disable Default R  Acknowledgement Request               Info
392213             13h 31m 26.050526s Tuin linksvoor 3   Tuin linksvoor 3   Broadcast          Broadcast                                                Link Status
392241             13h 31m 26.182875s DeConz             DeConz             Tuin linksvoor 3   Hal lamp           True               True               ZCL Level Control: Move to Level with OnOff, Seq: 252

Command Frame: Link Status
    Command Identifier: Link Status (0x08)
    .1.. .... = Last Frame: True
    ..1. .... = First Frame: True
    ...1 0000 = Link Status Count: 16
    Link 1
        Address: 0x0000[DeConz]
        .... .111 = Incoming Cost: 7
        .100 .... = Outgoing Cost: 4
    Link 2
        Address: 0x0118[Buiten - R schuur]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 3
        Address: 0x0143[HK stalamp]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 4
        Address: 0x05b5[HK houtlamp 2]
        .... .111 = Incoming Cost: 7
        .101 .... = Outgoing Cost: 5
    Link 5
        Address: 0x0ea5[Tuin linksvoor 2]
        .... .011 = Incoming Cost: 3
        .001 .... = Outgoing Cost: 1
    Link 6
        Address: 0x1ff6[Tuin linksvoor 1]
        .... .011 = Incoming Cost: 3
        .011 .... = Outgoing Cost: 3
    Link 7
        Address: 0x23ec[Tuin linksachter 1]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 8
        Address: 0x2b9e[Bijkeuken]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 9
        Address: 0x325d[0x325d]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 10
        Address: 0x6339[Tuin rechtsvoor 3]
        .... .101 = Incoming Cost: 5
        .101 .... = Outgoing Cost: 5
    Link 11
        Address: 0x68c4[WC lamp]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 12
        Address: 0x731e[Kerstverlichting]
        .... .111 = Incoming Cost: 7
        .000 .... = Outgoing Cost: 0
    Link 13
        Address: 0x7d2a[HK houtlamp]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 14
        Address: 0xc520[Badkamer ledstrip]
        .... .111 = Incoming Cost: 7
        .101 .... = Outgoing Cost: 5
    Link 15
        Address: 0xca27[Tuin rechtsvoor 2]
        .... .101 = Incoming Cost: 5
        .101 .... = Outgoing Cost: 5
    Link 16
        Address: 0xd6b7[Zolder Noord Lamp]
        .... .111 = Incoming Cost: 7
        .000 .... = Outgoing Cost: 0

Ihre Beschreibung klingt wie das, was ich erlebe. Ich habe ein viel besseres Netzwerk (Conbee 1) mit der neuesten fw. Aber immer noch nicht reagierende Glühbirnen, die nach einer Weile wieder reagieren.
Ich führe keine außergewöhnlichen Befehle oder Einstellungen aus, die von Home Assistant und meinem üblichen Zeitplan für Glühbirnen bereitgestellt werden. Die inneren Glühbirnen ändern sich jedoch tagsüber (Ein / Aus oder Helligkeit), während meine äußeren Glühbirnen nur die Baumzeiten an einem Tag ändern. Manchmal kommen die nicht reagierenden Glühbirnen ziemlich schnell zurück und wenn ich einen Befehl erteile, reagiert sie. Selten, aber passiert, dauert es viel länger oder ich muss das Gerät aus- und wieder einschalten.

@djwlindenaar wieder tolle Arbeit. Vielen Dank! Teilen Sie Ihre Fehlerfindung (en) in IKEA FW mit IKEA?

@djwlindenaar :

Natürlich sollte sich dieses Licht (IKEA) verhalten und mit einer Fehlermeldung antworten, aber das tut es nicht und wir können das nicht ändern.

Nun, ich habe nicht. Vielleicht kann @manup die
Außerdem verwende ich nicht die neueste Firmware.

Vielleicht wäre es besser, sich mit Siliziumlabors in Verbindung zu setzen, da darauf das IKEA-Material aufgebaut ist. Ich bin mir nicht sicher, ob die Fehler vom Ember-Code oder der IKEA-Anpassung herrühren ...

@djwlindenaar Sie können auch versuchen, über reddit https://www.reddit.com/user/TRADFRI Sie sind dort ziemlich aktiv.

@manup Gibt es Neuigkeiten für die Conbee II-Firmware?

Nach dem Downgrade der Firmware auf 0x264a0700 kann ich keine Verbindung mehr zu Conbee II herstellen. Beim Herabstufen auf 0x264a0700 und einigen wirklich alten Firmwares funktioniert das Flashen einwandfrei, kann jedoch keine Verbindung herstellen. Irgendwelche Ratschläge zum Zurücksetzen des Conbee II-Sticks?

@manup irgendwelche Updates? Sollte ich nach etwas anderem als deConz suchen oder wird daran gearbeitet, die Probleme zu lösen? Bitte geben Sie ein Lebenszeichen 🤗

Ich möchte nur meinen Conbee II wieder zum Laufen bringen, nachdem ich die Test-Firmware ausprobiert habe ...

@djwlindenaar Irgendwelche Updates von deiner Seite? Immer noch ein stabiles Netzwerk mit Ihren Fixes?

Gut zu sehen, dass Ihre PR von @manup zusammengeführt wird :)

@djwlindenaar Irgendwelche Updates von deiner Seite? Immer noch ein stabiles Netzwerk mit Ihren Fixes?

Gut zu sehen, dass Ihre PR von @manup zusammengeführt wird :)

@ JBS5 Ich bin mittel zufrieden mit der Situation.

Es hat sich für mein Netzwerk deutlich verbessert. Ich sehe jedoch immer noch die Fehler in den IKEA-Lichtern, die deCONZ manchmal verwirren.

Der entscheidende Punkt ist, dass manchmal ein IKEA-Router Pakete für eine bestimmte Route stillschweigend verwirft. Dieses stille Ablegen ist illegal, aber deCONZ sollte darauf reagieren, indem es eine neue Route findet, und das tut es nicht.

Es sieht so aus, als würden die Änderungen an der deCONZ-Firmware die Situation verbessern, aber für diese Situationen gibt es noch etwas hinzuzufügen. Das Fehlen eines APS-ACK sollte auf jeden Fall sofort eine neue Routenfindung auslösen.

Beachten Sie, dass @manup erwähnt hat, dass das

Ich glaube, der Fehler in den IKEA-Anzeigen ist darauf zurückzuführen, dass eine Tabelle nicht alle Routen zu Remote-Knoten enthalten kann. So wird stillschweigend jedes Paket verworfen, für das es die Route nicht kennt.

Danke @djwlindenaar.
Haben Sie, da einiger Zeit hier

Dies ist eine Änderung, die in der Firmware vorgenommen werden muss. Ich bin nicht mit deCONZ verbunden, daher kann ich die Wahrscheinlichkeit nicht kommentieren ...

@manup ?

Es veranlasst mich, darüber nachzudenken, von deCONZ für mein Heimnetzwerk wegzuziehen ...

@djwlindenaar , welche Alternativen

Dies ist eine Änderung, die in der Firmware vorgenommen werden muss. Ich bin nicht mit deCONZ verbunden, daher kann ich die Wahrscheinlichkeit nicht kommentieren ...

@manup ?

Es veranlasst mich, darüber nachzudenken, von deCONZ für mein Heimnetzwerk wegzuziehen ...

Macht Zigbee2MQTT das besser oder meinten Sie das nicht mit der Alternative?

Ja. Das ist es.

Ich weiß eigentlich nicht, ob das einen besseren Job macht. Beachten Sie, dass die dort verwendeten Firmwares von den Chipherstellern bereitgestellt werden. Diese Firmwares sind keine Open Source. Wenn sie also ein Firmware-Problem haben, haben Sie wahrscheinlich weniger Unterstützung als deCONZ ...
Andererseits ist die Konfiguration dieser Firmwares Open Source. Außerdem unterstützen sie bereits das Quellrouting.

Der Chiphersteller bietet nur SDK an. Wenn Sie dazu neigen, können Sie das SDK, die Testversion von simplicity studio, herunterladen und die Firmware selbst kompilieren. Z2M bietet Patches mit Änderungen an der Firmware.

Hallo zusammen,

Entschuldigung, dass es so lange gedauert hat, hier ist die neue Firmware für ConBee II, die alle Routing-Fixes von der AVR-Firmware 0x26350500 portiert hat. Außerdem wurde der Startvorgang verbessert, um zu verhindern, dass das Gerät stumm geschaltet wird. (Wir testen immer noch verschiedene Fälle, um das Startproblem endgültig zu beheben.)

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26580700.bin.GCF

Diese Version wird wahrscheinlich Teil der kommenden Version deCONZ 2.05.76 sein. Die Firmware der ConBee I- und RaspBee I-Version 0x26350500 wird zur Installation über die Schaltfläche "Aktualisieren" angehoben.

Danke, @manup. Installierte diese Version in meinem Testnetzwerk und es scheint zu funktionieren. Im Gegensatz zu unter 52 und 53 können zumindest Geräte gesteuert werden. Das Testnetzwerk ist zu klein, um zu überprüfen, ob diese Version das Routing verbessert.

@manup deCONZ stellt auch nach dem Flashen der neuen Firmware keine Verbindung zu ConBee II her. Hatte dieses Problem für eine Weile.

@manup Ich habe ein paar Mal versucht, es zu

Flash update failed, invalid CRC. Please try again.

14:29:06:105 query bootloader v1 ID after 5 ms
14:29:06:122 RX 60 bytes ASCII
R21B18 Bootloader
Vers: 2.05
build: Mar 22 2019
, 14:55:05
 after 22 ms
14:29:06:122 bootloader start after 22 ms
R21B18 Bootloader
Vers: 2.05
build: Mar 22 2019
14:29:06:124 GCF_ResetDeviceDone
14:29:06:125 bootloader v1 update firmware
flashing 160930 bytes: |==============================|
verify: .
Flash update failed, invalid CRC. Please try again.

Ist das GCFFlasher 3.13?

Hier ist das Protokoll von meinem Update:

GCFFlasher_internal -d /dev/ttyACM0 -f deCONZ_ConBeeII_0x26580700.bin.GCF 
GCFFlasher V3_13 (c) dresden elektronik ingenieurtechnik gmbh
Reboot device /dev/ttyACM0 (ConBee II)
deCONZ firmware version 26570700
R21B18 Bootloader
Vers: 2.05
build: Mar 11 2019
flashing 160930 bytes: |==============================|
verify: .
SUCCESS
Wait 10 seconds until application starts

Ja, es war 3.13, es funktioniert jetzt, da ich das gesamte System neu gestartet habe. Seltsam, nur das erneute Einstecken des ConBee II hat nicht funktioniert, aber ein Neustart funktioniert.

In der Tat seltsam, die CRC-Prüfung wird direkt auf dem Gerät durchgeführt. Ich frage mich, wie dies passieren kann.

@manup Ich habe sogar versucht, alte Firmware (mehrere Versionen) und 9600 Baudrate zu flashen. Alle führten zu demselben CRC-Fehler.

Schön, dass es jetzt funktioniert, danke! Ich habe bereits ein problematisches Gerät gesehen, das sofort dem Netzwerk beigetreten ist. Ich bin also zuversichtlich, dass diese Firmware einige Probleme beheben wird :)

Schön, dass es jetzt funktioniert. Hatte gerade eine Diskussion mit den Colleges über den Bootloader. Version 2.05 war von der ersten Charge von ConBee II im Jahr 2019 (ca. 3500 Stück), diese Version ist in einigen Fällen etwas rau. Seit Juli 2019 liefern wir 2.07 mit einigen Korrekturen am Watchdog-Handling aus.

Es befindet sich ein neuer Bootloader 3.x in der Entwicklung, der bereits Teil von RaspBee II ist. Er verfügt über ein wesentlich robusteres Design und Protokoll, um die Probleme der 2.x-Version zu beheben.

Derzeit aktualisieren wir den ConBee II-Bootloader nicht mit GCFFlasher. Wir haben das nicht eingeführt, da es eine subtile Chance gibt, das Gerät zu blockieren, wenn das Bootloader-Update in dem Moment abgebrochen wird, in dem die Startvektortabelle geändert wird. Aber ich denke, wir können dies mithilfe des ARM-Hard-Error-Handlers herausfinden. Die Idee ist, dass wenn das Bootloader-Update fehlgeschlagen ist und der Hard-Error-Handler ausgelöst wird, er prüfen kann, ob der Bootloader gültig ist, und wenn dies fehlschlägt, in die Anwendung springt, in der das Bootloader-Update erneut versucht werden kann. Wir haben einige Tests mit dem Hard-Fehler-Handler durchgeführt, die vielversprechend aussehen, aber es wird einige Zeit dauern, bis sie zur Veröffentlichung bereit sind.

Hallo

Ich habe heute mit der neuen Firmware geflasht, aber ich sehe immer noch Protokolle wie:

0x000D6FFFFE540E7C Fehler APSDE-DATA.confirm: 0xA7 bei Task

Ist das verwandt?

0xA7 gibt an, dass ein APS ACK nicht dort bereitgestellt wurde, wo es hätte sein sollen. Ich denke, das könnte verschiedene Gründe haben.

Hallo @manup , schön wieder von dir zu hören. Haben Sie auch etwas Zeit, um die verbleibenden Routing-Probleme weiter zu besprechen? Und hoffentlich lösen?

Hallo nochmal,

Ich habe immer noch Probleme, bei denen einige Lichter nicht auf Befehle reagieren (Ein / Aus / Dimmen), und ich habe wirklich keine Ahnung warum. Ich dachte, ich hätte etwas mit diesem Problem zu tun, aber jetzt bin ich mir nicht sicher, ob es so ist.

Ich bekomme immer noch viele Fehler wie den, den ich vor 4 Tagen gepostet habe.

Codeanzahl
0xA7 29
0xAE 31
0xD0 1
0xE1 1
0xE9 14
insgesamt 76

Ich habe 26 Geräte, die diese Fehler HEUTE veröffentlichen. Es scheint, als wäre es mit 0x26580700 etwas schlimmer geworden

Kann mir jemand sagen, ob dies mit diesem Routing-Problem zusammenhängt? oder ich sollte ein Problem mit meinem Problem eröffnen

Beachten Sie, dass es nur beim Senden von FX zu passieren scheint. "an" bis ~ 20 Lichter "gleichzeitig"

Hallo @manup , schön wieder von dir zu hören. Haben Sie auch etwas Zeit, um die verbleibenden Routing-Probleme weiter zu besprechen? Und hoffentlich lösen?

Hallo @djwlindenaar ja unbedingt, ich muss die Kommentare in dieser Ausgabe während der Woche nachholen. Wenn mein Gedächtnis mir gut tut, gab es bereits mehr Ideen, um die verbleibenden Probleme zu verbessern.

Hallo @djwlindenaar ja unbedingt, ich muss die Kommentare in dieser Ausgabe während der Woche nachholen. Wenn mein Gedächtnis mir gut tut, gab es bereits mehr Ideen, um die verbleibenden Probleme zu verbessern.

@manup ,
Ich glaube, dass Nachrichten sowohl vom Fehlverhalten als auch vom betroffenen Licht immer wieder eingehen (über eine andere Route) und dass dies von der Firmware falsch interpretiert wird, als ob die nicht funktionierende Route immer noch funktioniert. Außerdem neigt deCONZ dazu, APS-Schichtanforderungen ziemlich schnell aufzugeben, wenn keine ACK empfangen wird. Ich denke, es sollte beständiger sein und / oder eine Routenerkennung als Teil des Wiederholungsprozesses starten.

Schließlich bin ich jetzt davon überzeugt, dass das Quell-Routing das Hauptproblem des Fehlverhaltens von Routern beseitigen würde. Wenn Sie das umsetzen könnten, wären wir an einem viel besseren Ort. Ich bin bereit zu helfen / testen / debuggen ...

Hallo @manup , schön wieder von dir zu hören. Haben Sie auch etwas Zeit, um die verbleibenden Routing-Probleme weiter zu besprechen? Und hoffentlich lösen?

Hallo @djwlindenaar ja unbedingt, ich muss die Kommentare in dieser Ausgabe während der Woche nachholen. Wenn mein Gedächtnis mir gut tut, gab es bereits mehr Ideen, um die verbleibenden Probleme zu verbessern.

Hallo Manup, ich kann diesen Thread entführen. Wenn ja, ignorieren Sie ihn bitte. Ich habe einen Conbee II bei Home Assistant und er hat bis vor ungefähr einem Monat hervorragend funktioniert. Zu diesem Zeitpunkt würden alle meine Xiaomi-Sensoren zu unzuverlässigen Automatisierungen werden. Ich habe einige dresden fls-pp-Controller, die ich seit ein paar Jahren habe. Diese sind mit LED-Streifen verbunden und werden verwendet, um das Netzwerk sporadisch zu verlassen und einen Neustart zu erzwingen, um sie wieder einzuschalten. Ich habe sie schließlich alle aus meinem Conbee-Netzwerk entfernt und sofort war das gesamte Netzwerk stabil. Ich habe es ein paar Tage verlassen und dann eines wieder eingeführt, das ein paar Stunden lang funktioniert hat. Dann ist mein ZigBee-Netzwerk über Nacht ausgefallen und ich konnte nicht alle meine Schalter / Sensoren wieder online schalten, bis ich den Dresdner Controller ausgeschaltet habe. Keine Ahnung warum, aber für mich bricht die Verwendung der Dresdner Controller jetzt mein ZigBee-Netzwerk. Ich bin nur ein Anfänger in diesem Bereich, daher bin ich mir nicht sicher, ob dies hilfreich / relevant ist, aber ich habe nach Kommentaren dazu gesucht und bin auf diesen Thread gestoßen, also dachte ich, ich würde meine Erfahrung für alle Fälle in den Mix einfließen lassen. Im Moment entferne ich sie nur aus meinem Netzwerk - die Kopfschmerzen, die sie mir bereiteten, nicht wert!
Prost

Hallo @djwlindenaar ja unbedingt, ich muss die Kommentare in dieser Ausgabe während der Woche nachholen. Wenn mein Gedächtnis mir gut tut, gab es bereits mehr Ideen, um die verbleibenden Probleme zu verbessern.

@manup ,
Ich glaube, dass Nachrichten sowohl vom Fehlverhalten als auch vom betroffenen Licht immer wieder eingehen (über eine andere Route) und dass dies von der Firmware falsch interpretiert wird, als ob die nicht funktionierende Route immer noch funktioniert. Außerdem neigt deCONZ dazu, APS-Schichtanforderungen ziemlich schnell aufzugeben, wenn keine ACK empfangen wird. Ich denke, es sollte beständiger sein und / oder eine Routenerkennung als Teil des Wiederholungsprozesses starten.

Schließlich bin ich jetzt davon überzeugt, dass das Quell-Routing das Hauptproblem des Fehlverhaltens von Routern beseitigen würde. Wenn Sie das umsetzen könnten, wären wir an einem viel besseren Ort. Ich bin bereit zu helfen / testen / debuggen ...

Ich habe mich aufgrund der Routing-Probleme für zigbee2mqtt entschieden (am ärgerlichsten ist die Notwendigkeit, Ikea / Xiaomi gelegentlich neu zu koppeln). Ich werde meine Ergebnisse in einigen Wochen hier veröffentlichen ...

Nach dem Flashen der Firmware 0x26350500 auf meinem Conbee I (und dem Aktualisieren von deCONZ auf 2.05.76) am vergangenen Montag ging leider ein GU10 offline.

In VNC ist es ein bisschen grau:

Phoscon:

Müssen alle Lampen hochgefahren werden, bevor sie den Routing-Fix in der neuen Firmware-Version nutzen können?

@ JBS5 , ich glaube nicht, dass es notwendig ist, die Lichter nach dem Firmware-Upgrade einzuschalten (es sei denn, sie waren vor dem Upgrade ausgefallen, sie werden nicht auf magische Weise wiederbelebt ...).
Dies liegt wahrscheinlich an der Tatsache, dass wir, obwohl verbessert, keine vollständigen Probleme mit dem Routing haben. siehe meine vorherigen Beiträge.

@djwlindenaar Danke. Ich verstehe.

Für das, was es wert ist, denn es ist das gleiche Verhalten wie bei der vorherigen Firmware:

Nachdem das GU10 als nicht verfügbar markiert wurde, reagierte es immer noch auf Gruppenbefehle. Nach einigen Tagen gingen auch 2 batteriebetriebene Geräte (Aqara-Bewegungssensor und Xiaomi / Honeywell-Rauchmelder) offline. Das GU10 reagierte immer noch auf Gruppenbefehle.

Nach dem Aus- und Einschalten des GU10 waren auch die beiden batteriebetriebenen Geräte sofort wieder online.
Nachdem das GU10 offline gegangen war, dauerte es einige Tage, bis ein batteriebetriebenes Gerät mit dem spezifischen GU10 als Router ebenfalls offline ging.

@ JBS5 , ja, das klingt nach typischem Verhalten. An diesem GU10-Licht ist eigentlich nichts auszusetzen. Es ist nur so, dass deCONZ seinen Weg verloren hat, direkt mit ihm zu kommunizieren. Nach einiger Zeit werden auch die Endgeräte offline geschaltet, da sie auch kein Feedback von deCONZ erhalten. Schließlich wird das GU10, wenn es ausreichend an Netzwerkpaketen mangelt, tatsächlich offline geschaltet.

Wahrscheinlich können Sie in der Phase, in der noch auf Gruppenbefehle reagiert wird, einen anderen Router aus- und wieder einschalten, was anscheinend in Ordnung ist, und das GU10 wird wiederhergestellt. Dieser andere Router spielt eigentlich nicht gut und deCONZ reagiert nicht gut auf die Situation.
Also sei nicht böse auf die GU10;)

Hallo @djwlindenaar ja unbedingt, ich muss die Kommentare in dieser Ausgabe während der Woche nachholen. Wenn mein Gedächtnis mir gut tut, gab es bereits mehr Ideen, um die verbleibenden Probleme zu verbessern.

@manup ,

Hmm, die Routen sollten nach mehreren fehlgeschlagenen Übertragungen beeinträchtigt und gelöscht werden. Die neueste Firmware wird jedes Mal beeinträchtigt, wenn ein Fehler in der APS-DATA.confirm gemeldet wird (z. B. Routing-Fehler oder kein empfangener APS-ACK).

Ich glaube, dass Nachrichten sowohl vom Fehlverhalten als auch vom betroffenen Licht immer wieder eingehen (über eine andere Route) und dass dies von der Firmware falsch interpretiert wird, als ob die nicht funktionierende Route immer noch funktioniert.

Das ist ein sehr guter Hinweis, das werde ich überprüfen. es würde erklären, warum Routen nicht sterben werden. Ich denke, der einzig vernünftige Weg, eine Route zu bewerten, sollte auf erfolgreichen Übertragungen beruhen.

Außerdem neigt deCONZ dazu, APS-Schichtanforderungen ziemlich schnell aufzugeben, wenn keine ACK empfangen wird. Ich denke, es sollte beständiger sein und / oder eine Routenerkennung als Teil des Wiederholungsprozesses starten.

deCONZ führt keine Routenerkennung durch. Dies wird alles vom ZigBee-Stack erledigt. Wir können die REST-API erweitern, um Wiederholungen für einige Befehle (wie Steuerbefehle) durchzuführen, aber dies ist eine gute Sache.

Der Stapel selbst kann so konfiguriert werden, dass mehrere APS-Wiederholungen durchgeführt werden, bis er aufgegeben wird. Dies kann jedoch viele Dinge durcheinander bringen und die Warteschlange für lange Zeit blockieren. Ich denke, es ist am besten, dies in der REST-API als feinkörniger zu betrachten.

Schließlich bin ich jetzt davon überzeugt, dass das Quell-Routing das Hauptproblem des Fehlverhaltens von Routern beseitigen würde. Wenn Sie das umsetzen könnten, wären wir an einem viel besseren Ort. Ich bin bereit zu helfen / testen / debuggen ...

Theoretisch ist Source Routing der heilige Gral, um alles zu reparieren :)

In der realen Welt wird es jedoch von vielen Gateways nicht verwendet (oder?), Was bedeutet, dass die meisten Produkte entweder kein Quellrouting unterstützen oder nicht damit getestet wurden. IMHO sind die Chancen, dass es in gemischten Netzwerken funktioniert, sehr gering. Aber es ist schon eine Weile her, dass ich verschiedene Gateways auf dieser Ebene verglichen habe. Es wäre interessant, einen aktuellen Überblick darüber zu haben, welche Gateways heutzutage welchen Routing-Ansatz verwenden.

Es wäre interessant, einen aktuellen Überblick darüber zu haben, welche Gateways heutzutage welchen Routing-Ansatz verwenden.

Gerne helfe ich beim Testen / Schnüffeln der Hue-Brücke (Gen 2 und Gen 1), des Innr-Gateways, des IKEA-Hubs und des OSRAM Lightly Home-Gateways, benötige jedoch einige Informationen zum zu verwendenden Test-Setup (wie viele Router, Endgeräte, Abstände zwischen ihnen) , ...) und worauf zu achten ist.

Z-Stack FW ist ein Beispiel für FW, das Quellrouting anbietet / verwendet und es für größere Netzwerke empfiehlt. Aber ich habe auch einige Kommentare gesehen, dass es für den schwächeren CC2351 nicht wirklich gut funktioniert.

https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator

Außerdem neigt deCONZ dazu, APS-Schichtanforderungen ziemlich schnell aufzugeben, wenn keine ACK empfangen wird. Ich denke, es sollte beständiger sein und / oder eine Routenerkennung als Teil des Wiederholungsprozesses starten.

deCONZ führt keine Routenerkennung durch. Dies wird alles vom ZigBee-Stack erledigt. Wir können die REST-API erweitern, um Wiederholungen für einige Befehle (wie Steuerbefehle) durchzuführen, aber dies ist eine gute Sache.

Der Stapel selbst kann so konfiguriert werden, dass mehrere APS-Wiederholungen durchgeführt werden, bis er aufgegeben wird. Dies kann jedoch viele Dinge durcheinander bringen und die Warteschlange für lange Zeit blockieren. Ich denke, es ist am besten, dies in der REST-API als feinkörniger zu betrachten.

Der Stapel führt einige Wiederholungsversuche durch. Ich erinnere mich, dass er es dreimal versucht, wenn ich mich nicht irre. Es scheint mir, dass Sie diesem Code ein Verhalten hinzufügen könnten, um die zugehörige Route ungültig zu machen und es ein- oder zweimal erneut zu versuchen. Oder Sie können einen Rückruf im Stapel haben, mit dem Sie dieses Verhalten implementieren können. Das sollte eine Routenentdeckung hervorrufen, oder?

Schließlich bin ich jetzt davon überzeugt, dass das Quell-Routing das Hauptproblem des Fehlverhaltens von Routern beseitigen würde. Wenn Sie das umsetzen könnten, wären wir an einem viel besseren Ort. Ich bin bereit zu helfen / testen / debuggen ...

Theoretisch ist Source Routing der heilige Gral, um alles zu reparieren :)

In der realen Welt wird es jedoch von vielen Gateways nicht verwendet (oder?), Was bedeutet, dass die meisten Produkte entweder kein Quellrouting unterstützen oder nicht damit getestet wurden. IMHO sind die Chancen, dass es in gemischten Netzwerken funktioniert, sehr gering. Aber es ist schon eine Weile her, dass ich verschiedene Gateways auf dieser Ebene verglichen habe. Es wäre interessant, einen aktuellen Überblick darüber zu haben, welche Gateways heutzutage welchen Routing-Ansatz verwenden.

Um ehrlich zu sein, mache ich mir über dieses Problem keine großen Sorgen. Das Verhalten der Router beim Quellrouting ist äußerst einfach. Vor allem, wenn Sie es mit dem Verhalten vergleichen, das erforderlich ist, um das Routing selbst durchzuführen. Grundsätzlich muss die NWK-Schicht in einem Router nur prüfen, ob das Quell-Routing aktiviert ist, den nächsten Hop aus dem Paket lesen und an die MAC-Schicht zurückgeben. Keine Tabellen, kein Speicher, nichts falsch zu machen. Ich bin nicht sicher, ob das grundlegende Verhalten für die ZigBee-Zertifizierung überprüft wird, aber es ist sicher viel einfacher und es gibt viel weniger Fehler als beim normalen Routing.

Ich erwarte, dass nur wenige Koordinatoren dies implementieren, da die Komplexität in der Firmware des Koordinators liegt. Auch sehr wenige (Verbraucher-) ZigBee-Implementierungen konzentrieren sich tatsächlich auf die größeren Netzwerke, die von diesem Routing-Modus profitieren würden.

Schließlich würde ich argumentieren, dass dies der beste Routing-Modus für gemischte Netzwerke ist, da normales Routing von den einzelnen Implementierungen der Router und insbesondere von den schlecht spezifizierten Verbindungsqualitätsangaben abhängt. Da das Quell-Routing so einfach ist (= geringe Wahrscheinlichkeit von schlechten Implementierungen), würde ich dem vor dem normalen Routing-Verhalten vertrauen.

Nachdem ich dies gesagt habe, bin ich bereit, es für Sie zu testen, wenn Sie eine Firmware bereitstellen könnten. Ich bin auf einer Himbeere, mein Schnüffler ist bereit zu gehen.

Schließlich würde ich argumentieren, dass dies der beste Routing-Modus für gemischte Netzwerke ist, da normales Routing von den einzelnen Implementierungen der Router und insbesondere von den schlecht spezifizierten Verbindungsqualitätsangaben abhängt. Da das Quell-Routing so einfach ist (= geringe Wahrscheinlichkeit von schlechten Implementierungen), würde ich dem vor dem normalen Routing-Verhalten vertrauen.

KISS - macht für mich sehr viel Sinn.

Der Stapel führt einige Wiederholungsversuche durch. Ich erinnere mich, dass er es dreimal versucht, wenn ich mich nicht irre. Es scheint mir, dass Sie diesem Code ein Verhalten hinzufügen könnten, um die zugehörige Route ungültig zu machen und es ein- oder zweimal erneut zu versuchen. Oder Sie können einen Rückruf im Stapel haben, mit dem Sie dieses Verhalten implementieren können. Das sollte eine Routenentdeckung hervorrufen, oder?

Wenn ich den Code, der bereits passiert, richtig verstehe, besteht das Problem darin, dass Routen aufgrund anderer Faktoren (die derzeit untersucht werden) am Leben zu bleiben scheinen.

Um ehrlich zu sein, mache ich mir über dieses Problem keine großen Sorgen. Das Verhalten der Router beim Quellrouting ist äußerst einfach. Vor allem, wenn Sie es mit dem Verhalten vergleichen, das erforderlich ist, um das Routing selbst durchzuführen. Grundsätzlich muss die NWK-Schicht in einem Router nur prüfen, ob das Quell-Routing aktiviert ist, den nächsten Hop aus dem Paket lesen und an die MAC-Schicht zurückgeben. Keine Tabellen, kein Speicher, nichts falsch zu machen. Ich bin nicht sicher, ob das grundlegende Verhalten für die ZigBee-Zertifizierung überprüft wird, aber es ist sicher viel einfacher und es gibt viel weniger Fehler als beim normalen Routing.

Ich kann nur für die BitCloud-basierten Produkte sprechen, die ich durch Zertifizierung (FLS-Vorschaltgeräte) gebracht habe. Im Zertifizierungsprozess wurden sie nie auf Quellrouting getestet. Ich bin nicht sicher, ob es zum Zeitpunkt der Kompilierung überhaupt im Stapel aktiviert war. Beachten Sie, dass die meisten Stapel so konfiguriert sind, dass sie mit den minimal erforderlichen Funktionen kompiliert werden, um Platz zu sparen.

Meine persönliche Erfahrung mit selten verwendeten / getesteten Funktionen, egal wie einfach sie theoretisch sind, ist, dass sie immer Fehler haben. Zum Beispiel mussten wir für das FLS Tonnen von Fehlern in der Beispiel-BitCloud-Stack-Anwendung beheben. Ich weiß, dass Philips auch für einige seiner Produkte zahlreiche Verbesserungen im BitCloud-Stack vorgenommen hat.

Ich erwarte, dass nur wenige Koordinatoren dies implementieren, da die Komplexität in der Firmware des Koordinators liegt. Auch sehr wenige (Verbraucher-) ZigBee-Implementierungen konzentrieren sich tatsächlich auf die größeren Netzwerke, die von diesem Routing-Modus profitieren würden.

Die Komplexität muss im deCONZ REST-API-Plugin oder einem neuen Router-Plugin implementiert werden, da die Firmware nicht genügend Einblick in die gesamte Netzwerktopologie oder den Flash-Bereich bietet. Zu diesem Zweck könnte das deCONZ::ApsDataRequest mit einer Quellroutenoption in Form eines std::vector<quint16> , das die NWK-Adressen einer Route enthält.

Ich habe keinen guten Überblick über die Komplexität, die dies mit sich bringt und die derzeit vom Mesh-Routing behandelt wird. Die folgenden Aufgaben müssen mindestens und in großem Maßstab berücksichtigt werden:

• Rekursive Abfrage der Netzwerktopologie (Mgmt_Lqi_req). Das ist das Einfache, dies funktioniert bereits für das Mesh-Routing und könnte an Quellrouten angepasst werden.
• Knoten sind ausgeschaltet. Hier muss eine Logik alternative Routen auswählen, die möglicherweise auch nicht funktionieren, wenn ihre Verbindungen ebenfalls unterbrochen sind.
• Knoten werden wieder eingeschaltet.
• Knoten, die die NWK-Adresse ändern.
• Endgeräte wechseln die Eltern.
• Endgeräte verbinden sich, in Multi-Hop-Netzwerken kennen wir das übergeordnete Netzwerk nicht, ohne das Netzwerk abzufragen.

Was wir noch nicht wissen:

• Unterstützen alle Router das Quellrouting?
• Gibt es kommerzielle Gateways, die Quellrouting verwenden? Hier müssen wir den Verkehr abhören und uns die NWK-Header ansehen, die die Quellrouten enthalten und für die entsprechende Flags gesetzt sind.
• Wie gut funktioniert es bei Geräten, die Quellrouting unterstützen?

Ich kann nur für die BitCloud-basierten Produkte sprechen, die ich durch Zertifizierung (FLS-Vorschaltgeräte) gebracht habe. Im Zertifizierungsprozess wurden sie nie auf Quellrouting getestet. Ich bin nicht sicher, ob es zum Zeitpunkt der Kompilierung überhaupt im Stapel aktiviert war. Beachten Sie, dass die meisten Stapel so konfiguriert sind, dass sie mit den minimal erforderlichen Funktionen kompiliert werden, um Platz zu sparen.

Ich bin nicht mit der Funktionsweise vertraut, aber sind die Stapel nicht auch irgendwie zertifiziert?

Meine persönliche Erfahrung mit selten verwendeten / getesteten Funktionen, egal wie einfach sie theoretisch sind, ist, dass sie immer Fehler haben. Zum Beispiel mussten wir für das FLS Tonnen von Fehlern in der Beispiel-BitCloud-Stack-Anwendung beheben. Ich weiß, dass Philips auch für einige seiner Produkte zahlreiche Verbesserungen im BitCloud-Stack vorgenommen hat.

Ich erwarte, dass nur wenige Koordinatoren dies implementieren, da die Komplexität in der Firmware des Koordinators liegt. Auch sehr wenige (Verbraucher-) ZigBee-Implementierungen konzentrieren sich tatsächlich auf die größeren Netzwerke, die von diesem Routing-Modus profitieren würden.

Die Komplexität muss im deCONZ REST-API-Plugin oder einem neuen Router-Plugin implementiert werden, da die Firmware nicht genügend Einblick in die gesamte Netzwerktopologie oder den Flash-Bereich bietet. Zu diesem Zweck könnte das deCONZ::ApsDataRequest mit einer Quellroutenoption in Form eines std::vector<quint16> , das die NWK-Adressen einer Route enthält.

Ich verstehe diese Aussage nicht. Das Quellrouting wird vollständig auf NWK-Ebene im Stapel verarbeitet. Der Bitcloud-Stapel sollte ein Flag für die Kompilierungszeit (oder eine weniger wahrscheinliche Laufzeit) haben, um das Quellrouting zu aktivieren. Es gibt eine Quellroutentabelle, die vom Stapel auf dem neuesten Stand gehalten wird, basierend auf den Routenaufzeichnungsnachrichten, die sich aufgrund des vom Koordinator alle paar Minuten gesendeten MTORR bereits in unserem Netzwerk befinden.

• Grundsätzlich ist für jedes Gerät im Netzwerk die Route zum Koordinator über MTORRs bekannt
• Der Koordinator kennt jede (vollständige) Route zu jedem Gerät über die Routenaufzeichnungsnachrichten. Es ist keine Analyse erforderlich, nur ein Kopieren der RR-Nachricht in die Quellroutentabelle

Siehe die ZigBee-Spezifikation in Kapitel 3.6.3.5.4 und Kapitel 3.6.3.3

Ich habe keinen guten Überblick über die Komplexität, die dies mit sich bringt und die derzeit vom Mesh-Routing behandelt wird. Die folgenden Aufgaben müssen mindestens und in großem Maßstab berücksichtigt werden:

* Recursive query of network topology (Mgmt_Lqi_req). Thats, the easy one, this already works for mesh routing and could be adapted to source routes.

* Nodes are powered off. Here some logic needs to select alternate routes, which may also not work if their links are broken too.

* Nodes are powered on again.

* Nodes changing the nwk address.

* End-devices changing parents.

* End-devices joining, in multi-hop networks we don't know the parent without querying the network.

Ich glaube, diese werden alle von der NWK-Schicht im Bitcloud-Stack verarbeitet. Es sollte so einfach sein wie das Anpassen einiger Kompilierungszeit-Flags (ähnlich wie beim Aktivieren des MTOR-Verhaltens).

Was wir noch nicht wissen:

* Do all routers support source routing?

Ich würde es erwarten, da dies Teil der grundlegenden ZigBee-Spezifikation der NWK-Schicht ist. Ich kann nicht sicher sein, aber ich habe keine Bemerkung gesehen, dass die Unterstützung des Quellroutings optional ist. Es ähnelt dem MTOR-Verhalten, das wir bereits in unserem Netzwerk verwenden.

* Are there any commercial gateways which use source routing? Here we need to sniff traffic and look at the NWK headers which hold the source routes and have respective flags set.

Sie kennen diesen nicht, wissen auch nicht, was uns das sagen wird?

* For the devices which support source routing, how well does it work?

Wenn Sie die Firmware mit aktiviertem Quellrouting erstellen können, werden wir dies schnell erfahren. Es sollten nur ein paar Kompilierungszeit-Flags sein, um es in Bitcloud zu aktivieren.

Auch Zigbee2MQTT hat es für einige Koordinator-Firmwares aktiviert und ich habe (nach einem kurzen Google) noch keine Probleme mit bestimmten Routern gefunden, die mit aktiviertem Quell-Routing nicht gut funktionieren.

Ich bin nicht mit der Funktionsweise vertraut, aber sind die Stapel nicht auch irgendwie zertifiziert?

Ja, aber während der Zertifizierung werden bestimmte Konfigurationen aktiviert, die später in den Produkten möglicherweise nicht mehr aktiviert werden.

Ich verstehe diese Aussage nicht. Das Quellrouting wird vollständig auf NWK-Ebene im Stapel verarbeitet. Der Bitcloud-Stapel sollte ein Flag für die Kompilierungszeit (oder eine weniger wahrscheinliche Laufzeit) haben, um das Quellrouting zu aktivieren. Es gibt eine Quellroutentabelle, die vom Stapel auf dem neuesten Stand gehalten wird, basierend auf den Routenaufzeichnungsnachrichten, die sich aufgrund des vom Koordinator alle paar Minuten gesendeten MTORR bereits in unserem Netzwerk befinden.

Grundsätzlich ist für jedes Gerät im Netzwerk die Route zum Koordinator über MTORRs bekannt
Der Koordinator kennt jede (vollständige) Route zu jedem Gerät über die Routenaufzeichnungsnachrichten. Es ist keine Analyse erforderlich, nur ein Kopieren der RR-Nachricht in die Quellroutentabelle

Siehe die ZigBee-Spezifikation in Kapitel 3.6.3.5.4 und Kapitel 3.6.3.3

Ah, du hast recht, dumm mich, ich habe es irgendwie mit der allgemeinen Knotenerkennung (facepalm) falsch interpretiert.
Der Stapel kann zwar eine Menge aufgrund von Routenaufzeichnungsbefehlen herausfinden, aber ich bin bereits auf einen Fall gestoßen, in dem keine gesendet wurden, siehe unten.

Heute habe ich viele Konfigurationen ausprobiert. Es scheint, dass das Quell-Routing irgendwie funktioniert, aber nur, wenn das Mesh-Routing deaktiviert ist und für Geräte, die zuvor Routenaufzeichnungsbefehle senden.

Mein Philips Hue-Bewegungssensor macht Probleme und sendet Broadcast-NWK-Adressanforderungen, um die Gateway-NWK-Adresse abzurufen. In diesem Fall wurden keine Routenaufzeichnungsrahmen an ein Priorat gesendet (ich denke wegen der Sendung). Da das Mesh-Routing deaktiviert war, hat das Gateway keine Routenerkennung gestartet, sodass keine Kommunikation zum Sensor hergestellt wurde.

Wenn das Mesh-Routing neben dem Quell-Routing aktiviert ist, wird das Quell-Routing anscheinend nicht mehr verwendet, obwohl beide aktiviert sind.

Ich muss weitere Tests durchführen. Ich denke, die Erkennung von Netzrouten sollte verhindert werden, wenn sich bereits Routendatensatzeinträge im Routencache befinden. Der Code ist ziemlich komplex, ich muss hier tiefer graben.

deCONZ_ConBeeII_0x26600700_many2one.bin.zip

Hier ist die Firmware, für die sowohl das Mesh- als auch das Quell-Routing aktiviert ist (Routenaufzeichnungstabellengröße 32). Sie können es versuchen, aber wie in meinem kleineren Netzwerk erwähnt, wurde das Routing in dieser Konfiguration nicht ausgelöst.

Ich bin auf Himbeere, also kann ich das nicht testen. Könnten Sie auch eine dafür erstellen?
Ich frage mich, ob wir dieses Problem mit einer Art statischer Route umgehen können, die wir beim Start auf die Firmware hochladen können oder die tatsächlich auf anderen Informationen basiert.
Haben Sie dieses Gerät auch nach der Änderung des Quellroutings repariert? Sie fragen sich, ob für ein Endgerät eine Interaktion erforderlich ist, um MTOR zu erkennen, und ob Quellrouting verwendet wird. Natürlich empfangen sie die ausgestrahlten MTOR-Nachrichten nicht, wenn ihr Empfänger ausgeschaltet ist.
Übrigens habe ich gesehen, dass meine Xiaomi-Endgeräte den Routenrekord in meinem Schnüffeln gesendet haben ...

Ich habe über Firmware über Nacht geführt. Es scheint, dass das Quellrouting auch bei aktiviertem Mesh-Routing verwendet wird, jedoch sehr selten. Ab ca. Nur 2 Millionen Pakete <5 verwendeten eine Quellroute.

Ich bin auf Himbeere, also kann ich das nicht testen. Könnten Sie auch eine dafür erstellen?

Ich bin mir nicht sicher, ob ich die andere von ConBee I und RaspBee I verwendete Stapelkonfiguration überprüfen muss, wenn dies möglich ist.

Ich frage mich, ob wir dieses Problem mit einer Art statischer Route umgehen können, die wir beim Start auf die Firmware hochladen können oder die tatsächlich auf anderen Informationen basiert.

Ja, ich denke, es sollte möglich sein, Routen irgendwie in den Routen-Cache einzufügen. Aber wenn wir zu meinen oben erwähnten Bedenken zurückkehren, Routen beizubehalten. Auf jeden Fall bietet es zu Testzwecken und für feste Netzwerke eine nützliche Möglichkeit, das Routing zu konfigurieren.

Haben Sie dieses Gerät auch nach der Änderung des Quellroutings repariert? Sie fragen sich, ob für ein Endgerät eine Interaktion erforderlich ist, um MTOR zu erkennen, und ob Quellrouting verwendet wird.

Nein, ich habe gerade die Firmware aktualisiert, keine Reparatur - Quellrouten wurden kurz nach Erhalt der Routenaufzeichnungsbefehle eingerichtet.

Übrigens habe ich gesehen, dass meine Xiaomi-Endgeräte den Routenrekord in meinem Schnüffeln gesendet haben ...

IKEA scheint auch hier zu passen. Ich würde gerne mehr Tests mit Philips und anderen Markengeräten durchführen, um mehr Details darüber zu erhalten, wie verschiedene Geräte mit Quellrouting verwendet werden können.

Ich könnte mich auch einschalten, um zu testen, ob es für Raspbee funktioniert.

Ich habe über Firmware über Nacht geführt. Es scheint, dass das Quellrouting auch bei aktiviertem Mesh-Routing verwendet wird, jedoch sehr selten. Ab ca. Nur 2 Millionen Pakete <5 verwendeten eine Quellroute.

Interessant! Es wäre schön, einen Einblick in die Entscheidungslogik zu bekommen, wenn eine Quellroute verwendet wird und ob sie irgendwie beeinflusst / abgestimmt werden kann.

Ich bin auf Himbeere, also kann ich das nicht testen. Könnten Sie auch eine dafür erstellen?

Ich bin mir nicht sicher, ob ich die andere von ConBee I und RaspBee I verwendete Stapelkonfiguration überprüfen muss, wenn dies möglich ist.

Wäre großartig...

Ich frage mich, ob wir dieses Problem mit einer Art statischer Route umgehen können, die wir beim Start auf die Firmware hochladen können oder die tatsächlich auf anderen Informationen basiert.

Ja, ich denke, es sollte möglich sein, Routen irgendwie in den Routen-Cache einzufügen. Aber wenn wir zu meinen oben erwähnten Bedenken zurückkehren, Routen beizubehalten. Auf jeden Fall bietet es zu Testzwecken und für feste Netzwerke eine nützliche Möglichkeit, das Routing zu konfigurieren.

Einverstanden

Haben Sie dieses Gerät auch nach der Änderung des Quellroutings repariert? Sie fragen sich, ob für ein Endgerät eine Interaktion erforderlich ist, um MTOR zu erkennen, und ob Quellrouting verwendet wird.

Nein, ich habe gerade die Firmware aktualisiert, keine Reparatur - Quellrouten wurden kurz nach Erhalt der Routenaufzeichnungsbefehle eingerichtet.

Ich frage mich, ob es für das Philips Gerät helfen würde ...

Hallo Leute, ich habe die Z2M Source Routing-Firmware seit 24 Stunden ausgeführt (erlaubt nur 5 direkte Verbindungen). Ich habe ~ 35 Geräte. Es funktioniert einwandfrei, aber ich habe festgestellt, dass die Hue-Geräte nach dem Wechsel von der Standard-FW zur SR-Firmware einen Aus- und Wiedereinschalten benötigen. Ikea und Xiaomi werden automatisch wieder verbunden. Vielleicht kann dies Teile des Hue-Verhaltens erklären, das Sie sehen?

Hallo,
Ich habe meine TRADFRI-Glühlampe E14 WS opal 400lm mit der ikea-Firmware 2.3.050 und der neuesten Deconz-Beta und der neuesten Firmware auf meinem Conbee I erneut getestet. Ich kann bestätigen, dass sich die Glühlampen und die Kommunikation verbessert haben. Das Abrufen von Szenen, das Ein- und Ausschalten sowie das Ein- und Ausblenden funktionieren jetzt besser, aber es gibt noch ein Problem.

Die hier # 2518 dokumentierten Probleme wurden größtenteils behoben. Es scheint, dass Gruppenbefehle (außerhalb der Phoscon-GUI) noch besser funktionieren. # 2518 geschlossen

Mir ist bisher aufgefallen, dass ein CT-Wechsel manchmal mehr als einmal ausgelöst werden muss, um erfolgreich zu sein, wenn er von Hand und nicht in einer Szene geändert wird.

Ein neues Problem # 2892, das angezeigt wird, ist, dass innerhalb einer Gruppe eine Szene abgerufen wird und alle zugehörigen Glühbirnen eingeschaltet werden (aufgrund der Szene) und später eine andere Szene in dieser Gruppe mit nur wenigen eingeschalteten Glühbirnen (definiert durch die Szene). wird daran erinnert, dass die "unerwünschten" Lampen, die sich ausschalten sollten, eingeschaltet bleiben.
Wenn Sie die Gruppe ausschalten, werden außerdem nur die aktuell definierten Szenenbirnen ausgeschaltet und die anderen von zuvor (vorherige Szene aus der Gruppe) bleiben eingeschaltet. Sie benötigen mehrere Ausschaltbefehle, bevor sie losfahren.
Das Problem wird hier beschrieben, ist aber sicher in der API enthalten, da es keinen Unterschied macht, ob Sie Phoscon oder die API selbst verwenden. https://github.com/dresden-elektronik/phoscon-app-beta/issues/52

zusätzlicher Hinweis: Verwenden der neuesten Version von ikea fw 2.3.050 am 20.5.2020

Release-Version: 1.12.1
20. Mai 2020
Neue Funktionen und Änderungen im Zubehör:
WS 1.0 (E14, E27, GU10) V-2.3.050.
Ein-Aus-Status nach OTA-Upgrade behoben.

Vielen Dank für Ihre kontinuierliche Verbesserung und die aufgewendete Arbeit.

@manup , gibt es Neuigkeiten für die Firmware-Version der Quellroute von conbee I? Ich freue mich darauf, das zu testen :)

@manup , gibt es Neuigkeiten für die Firmware-Version der Quellroute von conbee I? Ich freue mich darauf, das zu testen :)

Mein erster Versuch, es zu aktivieren, endete in einem schrecklichen Fehler beim Kompilieren: / Ich habe noch nicht herausgefunden, was die Ursache ist, und hoffe, dass es irgendwie kompiliert wird.

@manup , gibt es Neuigkeiten für die Firmware-Version der Quellroute von conbee I? Ich freue mich darauf, das zu testen :)

Mein erster Versuch, es zu aktivieren, endete in einem schrecklichen Fehler beim Kompilieren: / Ich habe noch nicht herausgefunden, was die Ursache ist, und hoffe, dass es irgendwie kompiliert wird.

Hmmmm klingt nicht großartig ... @manup , ich würde gerne helfen, aber ich habe keinen Zugriff auf diesen Code.

@manup , irgendwelche Fortschritte?

@manup , pssst! 😁

Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivitäten gab. Es wird geschlossen, wenn keine weitere Aktivität stattfindet. Vielen Dank für Ihre Beiträge.

Immer noch passiert. @manup irgendwelche Fortschritte und / oder Updates zu diesem Problem?

@djwlindenaar @ JBS5 Ich habe @manup um ein Update gebeten.

Ja, immer noch ein Problem - wenn auch viel weniger als zuvor.

Was ist das Neueste zu diesem Thema?

Ich habe ungefähr 20 Weißspektrum-GU10 (erste Generation) an eine Hue-Brücke angeschlossen und wollte im Rahmen meiner ZigBee-Netzwerkrationalisierung alle meine Geräte nach Deconz migrieren.

Der Farbton ist ziemlich stabil, aber die Lichter gehen von Zeit zu Zeit immer noch offline (z. B. einmal pro Woche geht ein Licht offline). Ich muss nur die Glühbirnen neu starten, um sie wiederzubeleben.

Ist Deconz mehr oder weniger stabil?

Kein Deconz ist nicht stabiler, ich habe auch ungefähr 40 Ikea-Lampen und manchmal gehen einige offline

@salopette Ich habe diese Erfahrung nicht. Würde es Ihnen etwas ausmachen, eine separate Ausgabe zu eröffnen? Irgendwelche Protokolle?

@Mimiix In diesem Problem geht es um Lichter, die offline gehen. Warum eine neue Ausgabe eröffnen?

Hier gilt das gleiche. Ab und zu gehen die Lichter immer noch aus. Aber es hat sich im Laufe der Zeit viel verbessert. Als ich 2018 anfing, deCONZ zu verwenden, musste ich meine Ikea-Lichter fast täglich aus- und wieder einschalten. Ich habe dieses Problem am häufigsten mit einem FLOALT-Panel, aber dies ist auch das Licht, das am weitesten von meinem Conbee Stick entfernt ist.

@ JBS5 Da wir nichts über das Setup dieses Benutzers wissen. Keine Version, keine Protokolle, keine Informationen zum Setup. Wir sind nicht in der Lage festzustellen, ob sein Problem damit zusammenhängt.

Das Hinzufügen von Kommentaren ohne Informationen hilft in einem Fall nicht weiter. Deshalb möchte ich separate Themen, damit wir einen besseren Überblick haben.

Ich bitte @manup einmal privat, dies zu

@djwlindenaar hat tief

Allgemeine Ankündigung:

Ich habe gerade privat mit @manup darüber gesprochen. Er sagte mir folgendes:

`` `Dass die Firmware in Bezug auf die Routing-Probleme aktualisiert wird und das neue Netzwerk hoffentlich dazu beitragen sollte, die Probleme neu zu erstellen (was vorher nicht möglich war).
Mein Plan ist, dass diese nächste Firmware innerhalb der nächsten 2-3 Wochen verfügbar ist.

Einige Änderungen sind bereits vorgenommen, aber noch nicht öffentlich.
`` `

Ich werde euch alle auf dem Laufenden halten.

Allgemeine Ankündigung:

Ich habe gerade privat mit @manup darüber gesprochen. Er sagte mir folgendes:

My plan is that this next firmware is available within the next 2–3 weeks.

Some changes are already done but are not public yet.

Ich werde euch alle auf dem Laufenden halten.

3 Wochen später ein Update dazu?

@ JBS5 Noch keine 3 Wochen. Wartete hier auf den abgestandenen Bot;)

Pmed @manup heute morgen wieder. Erhielt die folgende Antwort:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

Ich habe um eine ETA gebeten und er ist gerade dabei.

@ JBS5 Noch keine 3 Wochen. Wartete hier auf den abgestandenen Bot;)

Pmed @manup heute morgen wieder. Erhielt die folgende Antwort:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

Ich habe um eine ETA gebeten und er ist gerade dabei.

Nun, Sie haben der Community ein Versprechen gegeben, so dass es normal ist, dass sie Sie an dieses Versprechen halten, 21 Tage / 7 Tage = 3 Wochen
dann ist es lahm, sich hinter dem stalebot zu verstecken, wenn dieses problem bereits seit februar 2019 aktiv ist. Wenn du der sprecher für dresden sein willst, benimm dich so oder lass einfach @manup damit umgehen :)

Was ist nun die ETA? Die 2-3 Wochen sind vergangen

@lubbertkramer Bitte sei hier vernünftig, der abgestandene Bot war ein Witz. Das einzige Versprechen, das @Mimiix zuvor gemacht hat, besteht darin, Updates zu teilen, sobald einige verfügbar sind. Es ist also durchaus gültig, nach dem aktuellen Status zu fragen. Für die ETA wurde keine versprochen, und ich verstehe, dass dies auch nicht der Fall sein wird, da dies komplex ist. Wie ich weiß, wenn man über böse Dinge spricht, ist es leider nichts, was innerhalb eines Tages geklärt werden kann, sich erst nach einiger Zeit zeigt oder einige unvorhergesehene Nebenwirkungen entwickelt.

In diesem Sinne, bitte haben Sie etwas Geduld und lassen Sie die Jungs daran arbeiten (es ist übrigens immer noch Urlaubszeit). Wenn Sie von der nächsten Veröffentlichung sprechen, ist das in 1,5 Wochen, um Ihre Hand zu heben und nach Neuigkeiten zu fragen.

@ JBS5 Noch keine 3 Wochen. Wartete hier auf den abgestandenen Bot;)

Pmed @manup heute morgen wieder. Erhielt die folgende Antwort:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

Ich habe um eine ETA gebeten und er ist gerade dabei.

Neustartprobleme hängen nicht mit diesem Problem zusammen, denke ich?
Was ist mit den Routing-Änderungen und den erwähnten Debug-Verbesserungen? Beziehen sich diese Debug-Verbesserungen auf dieses Problem?

Und basieren diese Routing-Änderungen auf @ djwlindenaar- Ergebnissen oder kann @manup bereits spezifischer sein?

@lubbertkramer Bitte sei hier vernünftig, der abgestandene Bot war ein Witz. Das einzige Versprechen, das @Mimiix zuvor gemacht hat, besteht darin, Updates zu teilen, sobald einige verfügbar sind. Es ist also durchaus gültig, nach dem aktuellen Status zu fragen. Für die ETA wurde keine versprochen, und ich verstehe, dass dies auch nicht der Fall sein wird, da dies komplex ist. Wie ich weiß, wenn man über böse Dinge spricht, ist es leider nichts, was innerhalb eines Tages geklärt werden kann, sich erst nach einiger Zeit zeigt oder einige unvorhergesehene Nebenwirkungen entwickelt.

In diesem Sinne, bitte haben Sie etwas Geduld und lassen Sie die Jungs daran arbeiten (es ist übrigens immer noch Urlaubszeit). Wenn Sie von der nächsten Veröffentlichung sprechen, ist das in 1,5 Wochen, um Ihre Hand zu heben und nach Neuigkeiten zu fragen.

Ich denke, es ist mehr als vernünftig, Menschen dazu zu bringen, Kommunikation oder Versprechen zu bestehen, ohne „Witze“ zu machen, wenn 2-3 Wochen vergangen sind und 3 Wochen ohne Folgemaßnahmen vergangen sind. Benutzer, die viel recherchiert und hier geantwortet haben, sind wegen mangelnder Nachverfolgung / Kommunikation bereits weitergezogen.

Zurück zum Problem: Was sind die neuesten Informationen zu diesem Problem?

@ JBS5 Noch keine 3 Wochen. Wartete hier auf den abgestandenen Bot;)

Pmed @manup heute morgen wieder. Erhielt die folgende Antwort:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

Ich habe um eine ETA gebeten und er ist gerade dabei.

Nun, Sie haben der Community ein Versprechen gegeben, so dass es normal ist, dass sie Sie an dieses Versprechen halten, 21 Tage / 7 Tage = 3 Wochen
dann ist es lahm, sich hinter dem stalebot zu verstecken, wenn dieses problem bereits seit februar 2019 aktiv ist. Wenn du der sprecher für dresden sein willst, benimm dich so oder lass einfach @manup damit umgehen :)

Was ist nun die ETA? Die 2-3 Wochen sind vergangen

Ich habe kein Problem damit, dieses Problem hinter mir zu lassen, wenn Sie so handeln. Ich bin in keiner Weise ein Sprecher, ich strecke hier meinen Hals aus, um die Dinge in Ordnung zu bringen, da ich eine direkte Verbindung habe. Der veraltete Bot, mit dem ich Probleme verfolge, und ich erhalte die Benachrichtigung. Ich erwarte, dass Manup zu mir zurückkehrt, und wenn der Zeitrahmen abgelaufen ist, hilft mir der abgestandene Bot, mich daran zu erinnern.

Also nein, es ist nicht "lahm", sich dahinter zu verstecken. Wenn Sie das tun würden, was ich für die Community getan habe, würden Sie es besser wissen. Außerdem ist es nicht so, dass ich im Leben keine anderen Dinge zu tun hatte.

Sei die Veränderung, die du in dieser Welt sehen willst

@ JBS5 Noch keine 3 Wochen. Wartete hier auf den abgestandenen Bot;)
Pmed @manup heute morgen wieder. Erhielt die folgende Antwort:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

Ich habe um eine ETA gebeten und er ist gerade dabei.

Nun, Sie haben der Community ein Versprechen gegeben, so dass es normal ist, dass sie Sie an dieses Versprechen halten, 21 Tage / 7 Tage = 3 Wochen
dann ist es lahm, sich hinter dem stalebot zu verstecken, wenn dieses problem bereits seit februar 2019 aktiv ist. Wenn du der sprecher für dresden sein willst, benimm dich so oder lass einfach @manup damit umgehen :)
Was ist nun die ETA? Die 2-3 Wochen sind vergangen

Ich habe kein Problem damit, dieses Problem hinter mir zu lassen, wenn Sie so handeln. Ich bin in keiner Weise ein Sprecher, ich strecke hier meinen Hals aus, um die Dinge in Ordnung zu bringen, da ich eine direkte Verbindung habe. Der veraltete Bot, mit dem ich Probleme verfolge, und ich erhalte die Benachrichtigung. Ich erwarte, dass Manup zu mir zurückkehrt, und wenn der Zeitrahmen abgelaufen ist, hilft mir der abgestandene Bot, mich daran zu erinnern.

Also nein, es ist nicht "lahm", sich dahinter zu verstecken. Wenn Sie das tun würden, was ich für die Community getan habe, würden Sie es besser wissen. Außerdem ist es nicht so, dass ich im Leben keine anderen Dinge zu tun hatte.

Sei die Veränderung, die du in dieser Welt sehen willst

Niemand bittet oder zwingt Sie, der mittlere Mann als Benutzer zu sein. Verlassen Sie dieses Problem also erneut als Sprecher oder kehren Sie zum Problem und den neuesten Informationen zurück, anstatt zu flammen und die Flower Power zu ändern.

Die 2-3 Wochen sind vergangen, die Sie seit mehr als 3 Wochen als allgemeine Ankündigung veröffentlicht haben. Wie sieht das Follow-up aus?

@ JBS5 Noch keine 3 Wochen. Wartete hier auf den abgestandenen Bot;)
Pmed @manup heute morgen wieder. Erhielt die folgende Antwort:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

Ich habe um eine ETA gebeten und er ist gerade dabei.

Nun, Sie haben der Community ein Versprechen gegeben, so dass es normal ist, dass sie Sie an dieses Versprechen halten, 21 Tage / 7 Tage = 3 Wochen
dann ist es lahm, sich hinter dem stalebot zu verstecken, wenn dieses problem bereits seit februar 2019 aktiv ist. Wenn du der sprecher für dresden sein willst, benimm dich so oder lass einfach @manup damit umgehen :)
Was ist nun die ETA? Die 2-3 Wochen sind vergangen

Ich habe kein Problem damit, dieses Problem hinter mir zu lassen, wenn Sie so handeln. Ich bin in keiner Weise ein Sprecher, ich strecke hier meinen Hals aus, um die Dinge in Ordnung zu bringen, da ich eine direkte Verbindung habe. Der veraltete Bot, mit dem ich Probleme verfolge, und ich erhalte die Benachrichtigung. Ich erwarte, dass Manup zu mir zurückkehrt, und wenn der Zeitrahmen abgelaufen ist, hilft mir der abgestandene Bot, mich daran zu erinnern.
Also nein, es ist nicht "lahm", sich dahinter zu verstecken. Wenn Sie das tun würden, was ich für die Community getan habe, würden Sie es besser wissen. Außerdem ist es nicht so, dass ich im Leben keine anderen Dinge zu tun hatte.
Sei die Veränderung, die du in dieser Welt sehen willst

Niemand bittet oder zwingt Sie, der mittlere Mann als Benutzer zu sein. Verlassen Sie dieses Problem also erneut als Sprecher oder kehren Sie zum Problem und den neuesten Informationen zurück, anstatt zu flammen und die Flower Power zu ändern.

Die 2-3 Wochen sind vergangen, die Sie seit mehr als 3 Wochen als allgemeine Ankündigung veröffentlicht haben. Wie sieht das Follow-up aus?

Ich hatte nur das, was ich erwähnte. Bitte lassen Sie sich von mir raten, Ihre Emotionen unter Kontrolle zu halten. Ich verstehe deine Wut, aber respektlos zu sein hilft nicht. Ich akzeptiere hier kein Flammen. Halten Sie es auf Thema und bürgerlich. Ich erkläre nur, was meine Argumente sind und warum ich Sachen so mache, wie ich es mache.

Wenn Sie ein Problem zur Beschwerde starten möchten, seien Sie bitte mein Gast. Mach es einfach nicht in dieser Ausgabe.

@ JBS5 Noch keine 3 Wochen. Wartete hier auf den abgestandenen Bot;)
Pmed @manup heute morgen wieder. Erhielt die folgende Antwort:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

Ich habe um eine ETA gebeten und er ist gerade dabei.

Nun, Sie haben der Community ein Versprechen gegeben, so dass es normal ist, dass sie Sie an dieses Versprechen halten, 21 Tage / 7 Tage = 3 Wochen
dann ist es lahm, sich hinter dem stalebot zu verstecken, wenn dieses problem bereits seit februar 2019 aktiv ist. Wenn du der sprecher für dresden sein willst, benimm dich so oder lass einfach @manup damit umgehen :)
Was ist nun die ETA? Die 2-3 Wochen sind vergangen

Ich habe kein Problem damit, dieses Problem hinter mir zu lassen, wenn Sie so handeln. Ich bin in keiner Weise ein Sprecher, ich strecke hier meinen Hals aus, um die Dinge in Ordnung zu bringen, da ich eine direkte Verbindung habe. Der veraltete Bot, mit dem ich Probleme verfolge, und ich erhalte die Benachrichtigung. Ich erwarte, dass Manup zu mir zurückkehrt, und wenn der Zeitrahmen abgelaufen ist, hilft mir der abgestandene Bot, mich daran zu erinnern.
Also nein, es ist nicht "lahm", sich dahinter zu verstecken. Wenn Sie das tun würden, was ich für die Community getan habe, würden Sie es besser wissen. Außerdem ist es nicht so, dass ich im Leben keine anderen Dinge zu tun hatte.
Sei die Veränderung, die du in dieser Welt sehen willst

Niemand bittet oder zwingt Sie, der mittlere Mann als Benutzer zu sein. Verlassen Sie dieses Problem also erneut als Sprecher oder kehren Sie zum Problem und den neuesten Informationen zurück, anstatt zu flammen und die Flower Power zu ändern.
Die 2-3 Wochen sind vergangen, die Sie seit mehr als 3 Wochen als allgemeine Ankündigung veröffentlicht haben. Wie sieht das Follow-up aus?

Ich hatte nur das, was ich erwähnte. Bitte lassen Sie sich von mir raten, Ihre Emotionen unter Kontrolle zu halten. Ich verstehe deine Wut, aber respektlos zu sein hilft nicht. Ich akzeptiere hier kein Flammen. Halten Sie es auf Thema und bürgerlich. Ich erkläre nur, was meine Argumente sind und warum ich Sachen so mache, wie ich es mache.

Wenn Sie ein Problem zur Beschwerde starten möchten, seien Sie bitte mein Gast. Mach es einfach nicht in dieser Ausgabe.

Die einzige Verlegenheit in dieser Ausgabe ist Manup und Dresden ist offensichtlich nicht in der Lage, dieses Problem zu beheben. Conbee ist ein kommerzielles Produkt und damit verbunden Verantwortung. Deshalb haben viele von uns deCONZ / Conbee bereits für TI-Chip und Z2M verlassen, die seitdem einwandfrei funktionieren.

@ JBS5 Noch keine 3 Wochen. Wartete hier auf den abgestandenen Bot;)
Pmed @manup heute morgen wieder. Erhielt die folgende Antwort:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

Ich habe um eine ETA gebeten und er ist gerade dabei.

Nun, Sie haben der Community ein Versprechen gegeben, so dass es normal ist, dass sie Sie an dieses Versprechen halten, 21 Tage / 7 Tage = 3 Wochen
dann ist es lahm, sich hinter dem stalebot zu verstecken, wenn dieses problem bereits seit februar 2019 aktiv ist. Wenn du der sprecher für dresden sein willst, benimm dich so oder lass einfach @manup damit umgehen :)
Was ist nun die ETA? Die 2-3 Wochen sind vergangen

Ich habe kein Problem damit, dieses Problem hinter mir zu lassen, wenn Sie so handeln. Ich bin in keiner Weise ein Sprecher, ich strecke hier meinen Hals aus, um die Dinge in Ordnung zu bringen, da ich eine direkte Verbindung habe. Der veraltete Bot, mit dem ich Probleme verfolge, und ich erhalte die Benachrichtigung. Ich erwarte, dass Manup zu mir zurückkehrt, und wenn der Zeitrahmen abgelaufen ist, hilft mir der abgestandene Bot, mich daran zu erinnern.
Also nein, es ist nicht "lahm", sich dahinter zu verstecken. Wenn Sie das tun würden, was ich für die Community getan habe, würden Sie es besser wissen. Außerdem ist es nicht so, dass ich im Leben keine anderen Dinge zu tun hatte.
Sei die Veränderung, die du in dieser Welt sehen willst

Niemand bittet oder zwingt Sie, der mittlere Mann als Benutzer zu sein. Verlassen Sie dieses Problem also erneut als Sprecher oder kehren Sie zum Problem und den neuesten Informationen zurück, anstatt zu flammen und die Flower Power zu ändern.
Die 2-3 Wochen sind vergangen, die Sie seit mehr als 3 Wochen als allgemeine Ankündigung veröffentlicht haben. Wie sieht das Follow-up aus?

Ich hatte nur das, was ich erwähnte. Bitte lassen Sie sich von mir raten, Ihre Emotionen unter Kontrolle zu halten. Ich verstehe deine Wut, aber respektlos zu sein hilft nicht. Ich akzeptiere hier kein Flammen. Halten Sie es auf Thema und bürgerlich. Ich erkläre nur, was meine Argumente sind und warum ich Sachen so mache, wie ich es mache.

Wenn Sie ein Problem zur Beschwerde starten möchten, seien Sie bitte mein Gast. Mach es einfach nicht in dieser Ausgabe.

Und wieder antworten oder aktualisieren Sie nicht den Status, der oft gefragt wird, und das einzige, was Sie tun, ist eine offtopische Diskussion, bei der Sie bereits ein Update hätten geben können, wie am Ende jedes Beitrags gefragt. Sie prahlen mit direkten Verbindungen / Einladungen in den Entwicklungsmeetings, sollten also über den Status dieses Problems auf dem Laufenden sein und alle lesenden Benutzer hier aktualisieren können.

Also noch einmal ein Update posten oder aufhören, offtopic zu posten, ich denke, das ist deine Aufgabe als Community-Moderator, anstatt die offtopic-Diskussion am Leben zu erhalten :)

Allgemeine Ankündigung:

Ich habe gerade privat mit @manup darüber gesprochen. Er sagte mir folgendes:

My plan is that this next firmware is available within the next 2–3 weeks.

Some changes are already done but are not public yet.

Ich werde euch alle auf dem Laufenden halten.

Die 2-3 Wochen sind vergangen, die Sie seit mehr als 3 Wochen als allgemeine Ankündigung veröffentlicht haben. Was ist also das Follow-up, was können wir Benutzer erwarten?

Ein neues Reliese wird in weniger als einer Woche erscheinen. Ich schlage vor, ruhig zu bleiben
und warten Sie ab, was die neuen Änderungen bringen werden

Ich habe viele Tradfri, die seit mehr als einem Jahr ohne Probleme arbeiten.
In letzter Zeit bekam ich Probleme mit nur einem meiner Tradfri-Lichter
begann etwa alle 15 Minuten zu fallen und sich mit dem Netz zu verbinden. 15 Minuten
erreichbar, 15 min nicht erreichbar. Habe viele Tests durchgeführt, um das Problem zu finden.
Ratet mal, was ... die Probleme waren? Es war nicht von deCONZ, sondern mein WiFi
Repeater planen einen erneuten Einsatz.

Seien Sie sich nicht so sicher, ob die Probleme immer mit deCONZ zusammenhängen, manchmal nicht.

Am Sonntag, 6. September 2020, 11:38 schrieb lubbertkramer [email protected] :

@ JBS5 https://github.com/JBS5 Noch keine 3 Wochen. Wartete auf den abgestandenen Bot
Hier ;)
Pmed @manup https://github.com/manup heute morgen wieder. Habe das
folgende Antwort:

Ich habe in den letzten Tagen in der Firmware gecrawlt, um die Probleme beim Neustart zu untersuchen, und einige böse Fehler gefunden.
Es wird auch ein paar Routing-Änderungen enthalten, hoffe, es mit der kommenden Version herauszubringen.

Die Debug-Verbesserungen werden nach der nächsten stabilen Version folgen.

Ich habe um eine ETA gebeten und er ist gerade dabei.

Nun, du hast der Gemeinde ein Versprechen gegeben, so dass es normal ist, dass sie dich halten
zu diesem Versprechen 21 Tage / 7 Tage = 3 Wochen
dann ist es lahm, sich hinter dem Stalebot zu verstecken, wenn dieses Problem bereits besteht
aktiv seit februar 2019. Wenn Sie der Sprecher für Dresden sein wollen
benimm dich wie es oder lass einfach https://github.com/manup damit umgehen :)
Was ist nun die ETA? Die 2-3 Wochen sind vergangen

Ich habe kein Problem damit, dieses Problem hinter mir zu lassen, wenn Sie so handeln.
Ich bin in keiner Weise ein Sprecher, ich strecke hier meinen Hals heraus, um Dinge zu bekommen
sortiert, da ich eine direkte Verbindung habe. Der abgestandene Bot, den ich benutze, um den Überblick zu behalten
Probleme und ich bekomme die Benachrichtigung. Ich erwarte, dass Manup zu mir zurückkommt und
Wenn der Zeitrahmen abgelaufen ist, hilft mir der abgestandene Bot, mich daran zu erinnern.
Also nein, es ist nicht "lahm", sich dahinter zu verstecken. Wenn du getan hast, was ich für das getan habe
Gemeinschaft, würden Sie besser als das wissen. Auch um das hinzuzufügen, ist es nicht das
Ich hatte keine anderen Dinge im Leben zu tun.
Sei die Veränderung, die du in dieser Welt sehen willst

Niemand bittet oder zwingt Sie, noch einmal der mittlere Mann als Benutzer zu sein
anstatt zu flammen und die Blütenkraft zu verändern, lassen Sie dieses Thema als
Sprecher oder kommen Sie auf das Thema und die neuesten Informationen zurück.
Die 2-3 Wochen sind vergangen, die Sie als allgemeine Ankündigung von gepostet haben
mehr als 3 Wochen jetzt, was ist das Follow-up?

Ich hatte nur das, was ich erwähnte. Bitte lassen Sie sich von mir raten, Ihre zu behalten
Emotionen unter Kontrolle. Ich verstehe deine Wut, aber respektlos zu sein
hilft nicht. Ich akzeptiere hier kein Flammen. Halten Sie es auf Thema und
bürgerlich. Ich erkläre nur, was meine Argumente sind und warum ich Sachen so mache, wie ich es mache.

Wenn Sie ein Problem zur Beschwerde starten möchten, seien Sie bitte mein Gast. Tu es einfach nicht
Mach es in dieser Ausgabe.

Und wieder antworten oder aktualisieren Sie nicht den Status, der gefragt wird
viele Male und das einzige, was Sie tun, ist mit einem Offtopic weiterzumachen
Diskussion, bei der Sie bereits ein Update hätten geben können, wie am Ende gefragt
von jedem Beitrag. Sie prahlen mit direkten Verbindungen / Einladungen in
die Entwicklungstreffen, so sollten Sie über den Status von auf dem Laufenden sein
dieses Problem und könnte alle lesenden Benutzer hier aktualisieren.

Also noch einmal ein Update posten oder aufhören, offtopic zu posten :)

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment-687726432 ,
oder abbestellen
https://github.com/notifications/unsubscribe-auth/AO4LI5G32N546L6GKHSHISLSENDABANCNFSM4GXPM2DA
.

@ morfei1 und @Mimiix Die nächste Veröffentlichung kommt hoffentlich in ungefähr 2 Wochen, wenn Sie sich ansehen, wie die Veröffentlichung von DE funktioniert ("15." = wenig, bevor Sie bezahlt werden). Und es ist kein Wort, ob ein Fix mit oder ohne Urlaub drin ist.
Und haben einige gesagt (und ich oft), wie die offizielle Unterstützung funktioniert, dann haben Kunden große Probleme.
Off the record: ZHA wird in 1 - 2 Wochen alle Versionen ihrer Stack-Protokolle offiziell für Silabs EZSP unterstützen. Ich denke, eine Sonoff Zigbee Bridge oder Elelabs-ELU013 / ELR023 ist besser, wenn Sie das Geld aufbringen und dann mehr HF- und SoC-Leistung erhalten die DE-Produkte und bessere Unterstützung durch die Community.
Aber ich warte auf deCONZ REST-API Version 2, bevor ich alle DE-Produkte RIP lasse.

@ JBS5 Noch keine 3 Wochen. Wartete hier auf den abgestandenen Bot;)
Pmed @manup heute morgen wieder. Erhielt die folgende Antwort:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

Ich habe um eine ETA gebeten und er ist gerade dabei.

Nun, Sie haben der Community ein Versprechen gegeben, so dass es normal ist, dass sie Sie an dieses Versprechen halten, 21 Tage / 7 Tage = 3 Wochen
dann ist es lahm, sich hinter dem stalebot zu verstecken, wenn dieses problem bereits seit februar 2019 aktiv ist. Wenn du der sprecher für dresden sein willst, benimm dich so oder lass einfach @manup damit umgehen :)
Was ist nun die ETA? Die 2-3 Wochen sind vergangen

Ich habe kein Problem damit, dieses Problem hinter mir zu lassen, wenn Sie so handeln. Ich bin in keiner Weise ein Sprecher, ich strecke hier meinen Hals aus, um die Dinge in Ordnung zu bringen, da ich eine direkte Verbindung habe. Der veraltete Bot, mit dem ich Probleme verfolge, und ich erhalte die Benachrichtigung. Ich erwarte, dass Manup zu mir zurückkehrt, und wenn der Zeitrahmen abgelaufen ist, hilft mir der abgestandene Bot, mich daran zu erinnern.
Also nein, es ist nicht "lahm", sich dahinter zu verstecken. Wenn Sie das tun würden, was ich für die Community getan habe, würden Sie es besser wissen. Außerdem ist es nicht so, dass ich im Leben keine anderen Dinge zu tun hatte.
Sei die Veränderung, die du in dieser Welt sehen willst

Niemand bittet oder zwingt Sie, der mittlere Mann als Benutzer zu sein. Verlassen Sie dieses Problem also erneut als Sprecher oder kehren Sie zum Problem und den neuesten Informationen zurück, anstatt zu flammen und die Flower Power zu ändern.
Die 2-3 Wochen sind vergangen, die Sie seit mehr als 3 Wochen als allgemeine Ankündigung veröffentlicht haben. Wie sieht das Follow-up aus?

Ich hatte nur das, was ich erwähnte. Bitte lassen Sie sich von mir raten, Ihre Emotionen unter Kontrolle zu halten. Ich verstehe deine Wut, aber respektlos zu sein hilft nicht. Ich akzeptiere hier kein Flammen. Halten Sie es auf Thema und bürgerlich. Ich erkläre nur, was meine Argumente sind und warum ich Sachen so mache, wie ich es mache.
Wenn Sie ein Problem zur Beschwerde starten möchten, seien Sie bitte mein Gast. Mach es einfach nicht in dieser Ausgabe.

Und wieder antworten oder aktualisieren Sie nicht den Status, der oft gefragt wird, und das einzige, was Sie tun, ist eine offtopische Diskussion, bei der Sie bereits ein Update hätten geben können, wie am Ende jedes Beitrags gefragt. Sie prahlen mit direkten Verbindungen / Einladungen in den Entwicklungsmeetings, sollten also über den Status dieses Problems auf dem Laufenden sein und alle lesenden Benutzer hier aktualisieren können.

Also noch einmal ein Update posten oder aufhören, offtopic zu posten, ich denke, das ist deine Aufgabe als Community-Moderator, anstatt die offtopic-Diskussion am Leben zu erhalten :)

Allgemeine Ankündigung:
Ich habe gerade privat mit @manup darüber gesprochen. Er sagte mir folgendes:

My plan is that this next firmware is available within the next 2–3 weeks.

Some changes are already done but are not public yet.

Ich werde euch alle auf dem Laufenden halten.

Die 2-3 Wochen sind vergangen, die Sie seit mehr als 3 Wochen als allgemeine Ankündigung veröffentlicht haben. Was ist also das Follow-up, was können wir Benutzer erwarten?

Um Ihre Frage direkt zu beantworten: Das hat mir @manup gesagt, nachdem ich ihn erneut gefragt habe. Ich kann niemanden zwingen, etwas zu tun. Ich werde nach dem Wochenende noch einmal fragen.

Dies ist eine allgemeine letzte Warnung zu Ihren Kommentaren. Der nächste Off-Topic-Kommentar hier ist das Sperren dieses Problems, bis weitere Neuigkeiten vorliegen.

@ JBS5 Noch keine 3 Wochen. Wartete hier auf den abgestandenen Bot;)
Pmed @manup heute morgen wieder. Erhielt die folgende Antwort:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

Ich habe um eine ETA gebeten und er ist gerade dabei.

Nun, Sie haben der Community ein Versprechen gegeben, so dass es normal ist, dass sie Sie an dieses Versprechen halten, 21 Tage / 7 Tage = 3 Wochen
dann ist es lahm, sich hinter dem stalebot zu verstecken, wenn dieses problem bereits seit februar 2019 aktiv ist. Wenn du der sprecher für dresden sein willst, benimm dich so oder lass einfach @manup damit umgehen :)
Was ist nun die ETA? Die 2-3 Wochen sind vergangen

Ich habe kein Problem damit, dieses Problem hinter mir zu lassen, wenn Sie so handeln. Ich bin in keiner Weise ein Sprecher, ich strecke hier meinen Hals aus, um die Dinge in Ordnung zu bringen, da ich eine direkte Verbindung habe. Der veraltete Bot, mit dem ich Probleme verfolge, und ich erhalte die Benachrichtigung. Ich erwarte, dass Manup zu mir zurückkehrt, und wenn der Zeitrahmen abgelaufen ist, hilft mir der abgestandene Bot, mich daran zu erinnern.
Also nein, es ist nicht "lahm", sich dahinter zu verstecken. Wenn Sie das tun würden, was ich für die Community getan habe, würden Sie es besser wissen. Außerdem ist es nicht so, dass ich im Leben keine anderen Dinge zu tun hatte.
Sei die Veränderung, die du in dieser Welt sehen willst

Niemand bittet oder zwingt Sie, der mittlere Mann als Benutzer zu sein. Verlassen Sie dieses Problem also erneut als Sprecher oder kehren Sie zum Problem und den neuesten Informationen zurück, anstatt zu flammen und die Flower Power zu ändern.
Die 2-3 Wochen sind vergangen, die Sie seit mehr als 3 Wochen als allgemeine Ankündigung veröffentlicht haben. Wie sieht das Follow-up aus?

Ich hatte nur das, was ich erwähnte. Bitte lassen Sie sich von mir raten, Ihre Emotionen unter Kontrolle zu halten. Ich verstehe deine Wut, aber respektlos zu sein hilft nicht. Ich akzeptiere hier kein Flammen. Halten Sie es auf Thema und bürgerlich. Ich erkläre nur, was meine Argumente sind und warum ich Sachen so mache, wie ich es mache.
Wenn Sie ein Problem zur Beschwerde starten möchten, seien Sie bitte mein Gast. Mach es einfach nicht in dieser Ausgabe.

Und wieder antworten oder aktualisieren Sie nicht den Status, der oft gefragt wird, und das einzige, was Sie tun, ist eine offtopische Diskussion, bei der Sie bereits ein Update hätten geben können, wie am Ende jedes Beitrags gefragt. Sie prahlen mit direkten Verbindungen / Einladungen in den Entwicklungsmeetings, sollten also über den Status dieses Problems auf dem Laufenden sein und alle lesenden Benutzer hier aktualisieren können.
Also noch einmal ein Update posten oder aufhören, offtopic zu posten, ich denke, das ist deine Aufgabe als Community-Moderator, anstatt die offtopic-Diskussion am Leben zu erhalten :)

Allgemeine Ankündigung:
Ich habe gerade privat mit @manup darüber gesprochen. Er sagte mir folgendes:

My plan is that this next firmware is available within the next 2–3 weeks.

Some changes are already done but are not public yet.

Ich werde euch alle auf dem Laufenden halten.

Die 2-3 Wochen sind vergangen, die Sie seit mehr als 3 Wochen als allgemeine Ankündigung veröffentlicht haben. Was ist also das Follow-up, was können wir Benutzer erwarten?

Um Ihre Frage direkt zu beantworten: Das hat mir @manup gesagt, nachdem ich ihn erneut gefragt habe. Ich kann niemanden zwingen, etwas zu tun. Ich werde nach dem Wochenende noch einmal fragen.

Dies ist eine allgemeine letzte Warnung zu Ihren Kommentaren. Der nächste Off-Topic-Kommentar hier ist das Sperren dieses Problems, bis weitere Neuigkeiten vorliegen.

Das ist eine kleine Antwort. Wenn ich also richtig lese, können wir später in dieser Woche eine detailliertere Antwort erwarten, da dann fast 4 Wochen vergangen sind, anstatt der 2-3, die @manup über Sie als allgemeine Ankündigung für das Update mitgeteilt hat verfügbar

@Mimiix Wenn Sie den Drang sehen, diese fast zwei Jahre offene Ausgabe mit vielen Informationen von sehr unterstützenden und engagierten Benutzern ohne Lösung zu schließen, dann bin ich nicht die Person, die Sie zurückhalten kann, das liegt an Ihnen als Community Sprecher:)

@lubbertkramer Ich sagte Lock, nicht in der Nähe.

Und damit werde ich dieses Problem sperren. Ich werde in ein paar Tagen freischalten oder wenn Manuel hier antwortete.

Hallo nochmal, ich denke, es ist mehr als Zeit für ein Update zu diesem Thema.

Aber das Wichtigste zuerst, wenn hier jemand schuld ist, bin ich es und nur ich. Ich verstehe die Frustration, aber es gibt keinen Raum, hier gegenüber @Mimiix unhöflich zu sein. Zivilisten , wenn er nicht gewesen wäre und alles, was er für diese Community erreicht hat, hätte ich nicht die Zeit Dinge zu erledigen in deCONZ Core und der Firmware und Arbeiten an Bugfixes und Verbesserungen. In der Vergangenheit war es einfacher, aber da diese ganze Sache wie verrückt skaliert wurde, wuchsen Aufgabenlisten, Supportanrufe und E-Mails ebenso wie verrückt, wobei die Fehler in der Neustartschleife meine persönliche Hölle waren. Dank der Moderatoren und all der großartigen Entwickler und Mitwirkenden sieht es jetzt viel besser aus, um tiefere Probleme einzeln anzugehen.

Fortschrittsbericht

(Vorschau für die nächste Version)

Ich habe viel mit Quell-Routing getestet und mit den Ergebnissen in dieser Ausgabe und verschiedenen Sniffer-Protokollen experimentiert. Nehmen Sie sich viel Zeit, damit das "automatische" Quell-Routing basierend auf eingehenden Routenaufzeichnungsbefehlen zuverlässig funktioniert. Welches ist im Grunde das, was die meisten Implementierungen mit Sourcing-Routing tun - wie die Quell-Routing-Firmware für zigbee2mqtt. Es funktioniert manchmal, aber es scheint eine größere Dynamik zu geben, wie / ob eine Quellroute basierend auf den LQI / RSSI-Werten ausgewählt (und beibehalten) wird, die ein Route Record-Hop von seinen Nachbarn sieht. In gemischten Netzwerken ist dies schwierig weil Unterschiede im Stack und in der Hardware. Die Verbindungsqualität kann auch sehr dynamisch sein, wenn sich Personen zwischen Knoten bewegen und Türen geöffnet und geschlossen werden, was sich leider auch auf das Routing auswirkt.

Daher habe ich mit der Idee experimentiert, feste Quellrouten zu einem Zielknoten zu konfigurieren. In vielen Fällen weist nur ein Teil des Netzwerks Routingprobleme auf. Hier kann es hilfreich sein, eine feste Quellroute anzugeben, auf der:

• Quellrouten können optional pro Knoten angegeben werden.
• Jeder Hop sollte immer mit Strom versorgt werden.
• Die Sprungpositionen durch den Pfad sollten angemessen sein. In einigen Fällen hat ein Benutzer möglicherweise einen besseren Plan, wohin Pakete weitergeleitet werden sollen, als der automatische Algorithmus herausfinden kann.

Zu diesem Zweck wurde das Firmware-Protokoll erweitert, um optional eine Quellroute pro APS-Anforderung bereitzustellen. Die Anzahl der konfigurierbaren Quellrouten ist unbegrenzt. Die Firmware muss nur einige für die Anforderungen und die ACK im Speicher behalten.

deCONZ ermittelt automatisch, ob jeder Hop auf der Route erreichbar ist, und verwendet nur in diesem Fall die Quellroute.
Hinter den Kulissen werden Quellrouten mit MAC-Adressen der Knoten konfiguriert, um gegen Änderungen der NWK-Adresse resistent zu sein.

Feste Quellroute erstellen

• Wählen Sie in der deCONZ-GUI alle Sprünge aus, während Sie STRG (Mehrfachauswahl) vom Koordinator (Quelle) bis zum Zielknoten gedrückt halten. Wichtig, dass zwischen Quelle und Ziel mindestens ein Hop vorhanden sein muss.
• Klicken Sie mit der rechten Maustaste auf den Zielknoten, um das Kontextmenü zu öffnen.
• Wählen Sie "Quellroute hinzufügen".

Dadurch wird die neue Quellroute erstellt, die durch die bläuliche Linie und die roten Endmarkierungen zum Zielknoten sichtbar gemacht wird.

(In späteren Versionen wird es möglich sein, alternative Fallback-Routen anzugeben, aber ich muss eine gute Benutzeroberfläche dafür finden.)

So entfernen Sie eine Quellroute: Wählen Sie im Kontextmenü des Zielknotens "Quellroute entfernen".

Die Route wird für die nächste Anfrage verwendet:

Dies funktioniert ziemlich gut und ermöglicht das manuelle Überschreiben des Routings, falls erforderlich, sollte auch zum Testen nützlich sein.
Derzeit funktioniert dies nur, wenn es über die GUI konfiguriert wurde, sollte aber zu einem späteren Zeitpunkt über die REST-API verfügbar sein.

Wird dies alles reparieren?

Unwahrscheinlich, sollte aber das Routing zu Zielen verbessern (das Routing auf den Knoten selbst kann nicht konfiguriert werden). Beachten Sie, dass feste Quellrouten nur für Router geeignet sind, da Endgeräte dazu neigen, die übergeordnete Route zu ändern und die Quellroute nicht mehr funktioniert. In diesem Fall funktioniert das automatische Quellrouting möglicherweise besser.

Wann wird es veröffentlicht?

Bald, in der nächsten Version 2.05.81, habe ich die folgenden (ziemlich leichten) Elemente auf der Aufgabenliste für die Version:

• Speichern / Wiederherstellen von Quellrouten in der Datenbank.
• Korrektur der Behandlung des NWK-Sicherheitszählers, um die Sicherung zwischen verschiedenen ConBee / RaspBee zu korrigieren und den Neustart durchzuführen.
• Lassen Sie GCFFlasher überprüfen, ob die Firmware nach dem Update ausgeführt wird.

Mit seiner Antwort @manup wurde eine Antwort gegeben. Bitte bleiben Sie beim Thema und beim Thema.

Hallo nochmal, ich denke, es ist mehr als Zeit für ein Update zu diesem Thema.

Fortschrittsbericht

(Vorschau für die nächste Version)

Ich habe viel mit Quell-Routing getestet und mit den Ergebnissen in dieser Ausgabe und verschiedenen Sniffer-Protokollen experimentiert. Nehmen Sie sich viel Zeit, damit das "automatische" Quell-Routing basierend auf eingehenden Routenaufzeichnungsbefehlen zuverlässig funktioniert. Welches ist im Grunde das, was die meisten Implementierungen mit Sourcing-Routing tun - wie die Quell-Routing-Firmware für zigbee2mqtt. Es funktioniert manchmal, aber es scheint eine größere Dynamik zu geben, wie / ob eine Quellroute basierend auf den LQI / RSSI-Werten ausgewählt (und beibehalten) wird, die ein Route Record-Hop von seinen Nachbarn sieht. In gemischten Netzwerken ist dies schwierig weil Unterschiede im Stack und in der Hardware. Die Verbindungsqualität kann auch sehr dynamisch sein, wenn sich Personen zwischen Knoten bewegen und Türen geöffnet und geschlossen werden, was sich leider auch auf das Routing auswirkt.

Daher habe ich mit der Idee experimentiert, feste Quellrouten zu einem Zielknoten zu konfigurieren. In vielen Fällen weist nur ein Teil des Netzwerks Routingprobleme auf. Hier kann es hilfreich sein, eine feste Quellroute anzugeben, auf der:

• Quellrouten können optional pro Knoten angegeben werden.
• Jeder Hop sollte immer mit Strom versorgt werden.
• Die Sprungpositionen durch den Pfad sollten angemessen sein. In einigen Fällen hat ein Benutzer möglicherweise einen besseren Plan, wohin Pakete weitergeleitet werden sollen, als der automatische Algorithmus herausfinden kann.

Zu diesem Zweck wurde das Firmware-Protokoll erweitert, um optional eine Quellroute pro APS-Anforderung bereitzustellen. Die Anzahl der konfigurierbaren Quellrouten ist unbegrenzt. Die Firmware muss nur einige für die Anforderungen und die ACK im Speicher behalten.

deCONZ ermittelt automatisch, ob jeder Hop auf der Route erreichbar ist, und verwendet nur in diesem Fall die Quellroute.
Hinter den Kulissen werden Quellrouten mit MAC-Adressen der Knoten konfiguriert, um gegen Änderungen der NWK-Adresse resistent zu sein.

Feste Quellroute erstellen

• Wählen Sie in der deCONZ-GUI alle Sprünge aus, während Sie STRG (Mehrfachauswahl) vom Koordinator (Quelle) bis zum Zielknoten gedrückt halten. Wichtig, dass zwischen Quelle und Ziel mindestens ein Hop vorhanden sein muss.
• Klicken Sie mit der rechten Maustaste auf den Zielknoten, um das Kontextmenü zu öffnen.
• Wählen Sie "Quellroute hinzufügen".

Dadurch wird die neue Quellroute erstellt, die durch die bläuliche Linie und die roten Endmarkierungen zum Zielknoten sichtbar gemacht wird.

(In späteren Versionen wird es möglich sein, alternative Fallback-Routen anzugeben, aber ich muss eine gute Benutzeroberfläche dafür finden.)

So entfernen Sie eine Quellroute: Wählen Sie im Kontextmenü des Zielknotens "Quellroute entfernen".

Die Route wird für die nächste Anfrage verwendet:

Dies funktioniert ziemlich gut und ermöglicht das manuelle Überschreiben des Routings, falls erforderlich, sollte auch zum Testen nützlich sein.
Derzeit funktioniert dies nur, wenn es über die GUI konfiguriert wurde, sollte aber zu einem späteren Zeitpunkt über die REST-API verfügbar sein.

Wird dies alles reparieren?

Unwahrscheinlich, sollte aber das Routing zu Zielen verbessern (das Routing auf den Knoten selbst kann nicht konfiguriert werden). Beachten Sie, dass feste Quellrouten nur für Router geeignet sind, da Endgeräte dazu neigen, die übergeordnete Route zu ändern und die Quellroute nicht mehr funktioniert. In diesem Fall funktioniert das automatische Quellrouting möglicherweise besser.

Wann wird es veröffentlicht?

Bald, in der nächsten Version 2.05.81, habe ich die folgenden (ziemlich leichten) Elemente auf der Aufgabenliste für die Version:

• Speichern / Wiederherstellen von Quellrouten in der Datenbank.
• Korrektur der Behandlung des NWK-Sicherheitszählers, um die Sicherung zwischen verschiedenen ConBee / RaspBee zu korrigieren und den Neustart durchzuführen.
• Lassen Sie GCFFlasher überprüfen, ob die Firmware nach dem Update ausgeführt wird.

Vielen Dank für die ausführliche Antwort. Ich denke, viele von uns warten auf eine Antwort wie oben, da die Community hart für dieses Problem arbeitet und Sie als Entwickler arbeiten.

Einige Anschlussfragen, die ich habe:

• Wann wird oben ein Update in Beta / Stable verfügbar sein?

• Wird es einen Unterschied geben, wie oben in Bezug auf Conbee 1/2 und Raspbee funktionieren wird, oder wird dies alles gleich sein?

• Für das Update 2.05.81 erwähnen Sie, dass eher (leichte) Elemente auf der Aufgabenliste stehen. Wann können wir mit diesem Update rechnen (vielleicht ist es eine Idee, diesem Git eine Roadmap hinzuzufügen?).

Hallo @lubbertkramer

Ich kann Nummer 1 beantworten: Version 2.05.81 wird am 15. des Monats erwartet (Windows Build einige Tage später). Ich habe das früher in der Zwietracht angekündigt, aber ich habe nur gedacht, dass dies beim Github nicht der Fall ist. Ich werde das der Readme hinzufügen! Mein Fehler!

Bearbeiten: Hat eine Pull-Anfrage der Datei readme.md ausgeführt. Ich bin mir nicht sicher, wie der stabile Kanal läuft, der etwas geklärt werden muss.

Wird es einen Unterschied geben, wie oben in Bezug auf Conbee 1/2 und Raspbee funktionieren wird, oder wird dies alles gleich sein?

Es sollte genauso funktionieren, ich habe jetzt den Code auf RaspBee I / ConBee I portiert und die Quellrouten werden dort auf die gleiche Weise verwendet.

Ich habe derzeit einen merkwürdigen Fall, in dem ein IKEA-Repeater-Stecker lebt, aber nicht mit dem Rest des Netzwerks spielen möchte.
An ihn gesendete Befehle (mit und ohne Quellrouten) werden unbemerkt ignoriert.

Der Repeater sendet seine NWK-Verbindungsstatus-Frames, meldet jedoch eine leere Nachbarliste:

Befehle des Koordinators sowie eines OSRAM-Sensors, dessen Eltern der Repeater ist, werden ignoriert. Der Sensor versucht, wie viele Xiaomi-Geräte, nicht automatisch, einen neuen Elternteil zu finden ... schlechte Situation:

Dieses Szenario läuft jetzt seit zwei Tagen und hat keine Möglichkeit gefunden, den Repeater wiederherzustellen. Vielleicht behebt ein Aus- und Wiedereinschalten des Repeaters das Problem, aber ich werde es vorerst so lassen, um zu sehen, ob es irgendwie über Luft gelöst werden kann.

Gibt es ein Problem mit dem Tradfri USB Repeater oder dem Tradfri Stecker?

In diesem Fall war es der Stecker, ich bin nicht sicher, ob es sich um die neueste Version handelt, muss dies später überprüfen.

Ist es möglich zu überprüfen? Ich habe 3 Tradfri-Stecker, die ungefähr 1,5 Jahre lang mit der neuesten FW Rock Solid laufen. Wenn ich Probleme mit der neuen Beta habe, muss ich das Update verzögern.

Vielen Dank!

Hier sind die Daten aus dem Basiscluster. Beachten Sie, dass das Problem vor zwei Tagen in meinem Heimnetzwerk aufgetreten ist, in dem zu diesem Zeitpunkt noch keine neue Firmware vorhanden war.

Es sieht so aus, als wären Sie auf der neuesten FW als meine Stecker. Ich hoffe es ist, wegen der Ikea alten FW ...

Die Webseite mit dem tradfri-Änderungsprotokoll ist nicht verfügbar, um zu überprüfen, was die letzte FW behoben hat.

Die neuesten Firmware-Dateien sind jetzt online:

ConBee II

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26650700.bin.GCF

RaspBee II

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_RaspBeeII_0x26650700.bin.GCF

RaspBee I und ConBee I.

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26370500.bin.GCF

• Bei diesen ist das Quellrouting mit max. 32 Quellrouten, bei denen die ältesten Einträge automatisch durch neuere ersetzt werden. Der Betrag wird wahrscheinlich in späteren Versionen erhöht, sollte aber bereits gut funktionieren.
• Wenn eine Quellroute und ein "normaler" Routeneintrag vorhanden sind, wird die Quellroute bevorzugt. Dies ist nicht Standard, scheint aber besser zu funktionieren.
• Die Firmware bietet allgemeine Verbesserungen für die Robustheit des seriellen Protokolls.
• ConBee II und RaspBee II wurden verbessert, um Probleme zu vermeiden, bei denen das Netzwerk nach einem Aus- und Einschalten möglicherweise verloren gegangen ist, bis der Frame-Zähler wieder seinen alten Wert erreicht.

@manup hat Firmware für ConBee erstellt. Ich habe version Befehls-ID 0x0D gelöscht. Ich bekomme keine Antwort mehr auf diesen Befehl

@Adminiuga @manup Dinge über die Firmware: Bitte verwenden Sie # 3260.

Die neuesten Firmware-Dateien sind jetzt online:

ConBee II

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26650700.bin.GCF

RaspBee II

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_RaspBeeII_0x26650700.bin.GCF

RaspBee I und ConBee I.

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26370500.bin.GCF

• Bei diesen ist das Quellrouting mit max. 32 Quellrouten, bei denen die ältesten Einträge automatisch durch neuere ersetzt werden. Der Betrag wird wahrscheinlich in späteren Versionen erhöht, sollte aber bereits gut funktionieren.
• Wenn eine Quellroute und ein "normaler" Routeneintrag vorhanden sind, wird die Quellroute bevorzugt. Dies ist nicht Standard, scheint aber besser zu funktionieren.
• Die Firmware bietet allgemeine Verbesserungen für die Robustheit des seriellen Protokolls.
• ConBee II und RaspBee II wurden verbessert, um Probleme zu vermeiden, bei denen das Netzwerk nach einem Aus- und Einschalten möglicherweise verloren gegangen ist, bis der Frame-Zähler wieder seinen alten Wert erreicht.

Wie flashe ich diese Firmware (ich verwende das deCONZ Docker-Image von marthoc)?

Ich habe die Datei heruntergeladen (ConBee II), aber die Anweisungen zur manuellen Aktualisierung gelten nicht für das deCONZ Docker-Image von marthoc, und die Anleitung für deCONZ von marthoc erlaubt nicht die Verwendung einer Firmware, die nicht im Image enthalten ist (und diese Datei ist nicht aufgeführt Wie verfügbar).

Wie flashe ich diese Firmware (ich verwende das deCONZ Docker-Image von marthoc)?

Ich schließe den USB-Dongle einfach an einen Windows-Laptop an und mache es von dort aus und zurück in mein Synology NAS, wenn es fertig ist.

Wie flashe ich diese Firmware (ich verwende das deCONZ Docker-Image von marthoc)?

Ich schließe den USB-Dongle einfach an einen Windows-Laptop an und mache es von dort aus und zurück in mein Synology NAS, wenn es fertig ist.

Gibt es ein Windows-Dienstprogramm zum Flashen der Firmware? Wenn ja, können Sie den Link teilen?

Wie flashe ich diese Firmware (ich verwende das deCONZ Docker-Image von marthoc)?

Ich schließe den USB-Dongle einfach an einen Windows-Laptop an und mache es von dort aus und zurück in mein Synology NAS, wenn es fertig ist.

Gibt es ein Windows-Dienstprogramm zum Flashen der Firmware? Wenn ja, können Sie den Link teilen?

https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Update-deCONZ-manually#update -in-windows

Daher habe ich mit der Idee experimentiert, feste Quellrouten zu einem Zielknoten zu konfigurieren. In vielen Fällen weist nur ein Teil des Netzwerks Routingprobleme auf. Hier kann es hilfreich sein, eine feste Quellroute anzugeben, auf der:

• Quellrouten können optional pro Knoten angegeben werden.
• Jeder Hop sollte immer mit Strom versorgt werden.
• Die Sprungpositionen durch den Pfad sollten angemessen sein. In einigen Fällen hat ein Benutzer möglicherweise einen besseren Plan, wohin Pakete weitergeleitet werden sollen, als der automatische Algorithmus herausfinden kann.

Wird dies alles reparieren?

Unwahrscheinlich, sollte aber das Routing zu Zielen verbessern (das Routing auf den Knoten selbst kann nicht konfiguriert werden). Beachten Sie, dass feste Quellrouten nur für Router geeignet sind, da Endgeräte dazu neigen, die übergeordnete Route zu ändern und die Quellroute nicht mehr funktioniert. In diesem Fall funktioniert das automatische Quellrouting möglicherweise besser.

Nur zur Klarstellung ... wird diese neue Firmware die zufällige Trennung der Ikea-Geräte beheben (oder zumindest verbessern), wenn ich keine neuen statischen Quellrouten manuell konfiguriere? Oder besteht die einzige Möglichkeit, von diesem Update zu profitieren, darin, die Routen der Geräte, die dazu neigen, die Verbindung zu verlieren, manuell festzulegen?

Ohne manuelle Einstellungsrouten findet das automatische Quellrouting statt, wenn Geräte diese bewerben (wie dies bei IKEA-Geräten der Fall ist).
Im Vergleich zur früheren Firmware wird das Quell-Routing für diese Geräte verwendet, wenn eine solche Route bekannt ist.

Wenn es wirklich hilft, offen zu bleiben, wäre es gut, wenn jeder, der regelmäßig Probleme mit der früheren Firmware hatte, melden kann, wenn sich etwas geändert hat.

In meinen Testnetzwerken funktioniert die Firmware recht gut und Quellrouten werden häufig verwendet, wie in den Sniffer-Protokollen angegeben. Das bedeutet nicht viel, da meine Netzwerke auch ohne Quell-Routing ziemlich solide waren.

Ich habe 21 Lichter (4 - 980lu WS, 17 - 1000lu WS), 3 Stecker und 3 (5 Tasten) runde Fernbedienungen von Ikea. Alle auf den neuesten Ikea FWs. Ich habe in den letzten ungefähr +1,5 Jahren noch nie eine Instabilität mit ihnen erlebt. Nighter mit einer der vorherigen deCONZ-Versionen oder FW-Versionen oder mit der aktuellen. Ich verwende eine stabile .81 mit der neuesten RaspBee FW 0x26370500 und habe auch in der letzten Woche keine Probleme damit.

Ich denke ... (vielleicht habe ich nicht ganz recht) Ikea hat kein allgemeines Problem, ist aber einrichtungsspezifisch. Es gibt viele verschiedene Faktoren, die ihr Verhalten und ihre Leistung in deCONZ und allgemein beeinflussen können.

Ich denke, die meisten Probleme traten bei den Ikea GU10-Lampen auf. Die Stabilität hatte sich im Laufe der Zeit erheblich verbessert, aber es war ein Chaos Ende 2018, als ich anfing. Ich musste in den letzten drei Monaten durchschnittlich alle zwei Wochen einen von 30 GU10 aus- und wieder einschalten.

Ich denke, die meisten Probleme traten bei den Ikea GU10-Lampen auf. Die Stabilität hatte sich im Laufe der Zeit erheblich verbessert, aber es war ein Chaos Ende 2018, als ich anfing. Ich musste in den letzten drei Monaten durchschnittlich alle zwei Wochen einen von 30 GU10 aus- und wieder einschalten.

Könnte sein. Die GU10 haben, soweit ich weiß, kein FW-Update wie andere Lichter von Ikea erhalten. Kürzlich haben wir es in den Zwietrachtkanälen diskutiert. Ein Benutzer, der GU10 Ikea-Leuchten ausführt, erfährt ein solches Verhalten. Egal was wir versucht haben, nichts scheint seine Probleme zu lindern. Er teilte uns sogar mit, dass er einen Ikea Tradfri Hub gekauft hat und er hat die gleichen schlechten Erfahrungen gemacht, selbst mit dem Ikea Hub und den GU10 Lichtern.

Ich denke, es ist eine Frage der Zeit, dass Ikea eine neue FW für diese Art von Lichtern veröffentlicht, um dieses Problem möglicherweise zu beheben.

Ich frage mich, ob @djwlindenaar bereits auf die neueste deCONZ und Firmware aktualisiert wurde und seine Erfahrungen teilen kann. :) :)

Eigentlich noch nicht ... Ich habe noch keine Zeit für ein Upgrade gefunden. Außerdem habe ich keine Zeit gefunden, auf z2mqtt umzusteigen. Die gute Nachricht ist also, dass ich auf die neue Firmware aktualisieren werde und wenn es etwas zu berichten gibt, werde ich es tun.

Wenn es wirklich hilft, offen zu bleiben, wäre es gut, wenn jeder, der regelmäßig Probleme mit der früheren Firmware hatte, melden kann, wenn sich etwas geändert hat.

Ich habe vor 2 Tagen auf die neueste Firmware aktualisiert und seitdem hat einer meiner Xiaomi-Wandschalter (ctrl_neutral2, 25.11.2017) dreimal von selbst umgeschaltet. Ich hatte noch nie ein solches Problem.

Es ist am 1.3.009 über eine Tradfri-Lampe E27 CWS mit dem Koordinator verbunden.

Außerdem nicht eng mit diesem Problem verbunden, aber ich habe es nie geschafft, ein OTA-Update mit Deconz (Community-Container) zu erhalten.

Ich habe die Tradfri-Lampen:

• E27 CWS am 1.3.009
• E14 W am 1.2.214
• Drahtloser Dimmer am 1.2.248
• 17 * GU10 WS am 1.2.221

Ich kann die heruntergeladenen Trafri OTA-Dateien sehen, aber es passiert nichts. Was soll ich machen?

Als Referenz startet der Container folgendermaßen:

docker run -d --name=deconz --net=host --restart=always -v /etc/localtime:/etc/localtime:ro -v /opt/otau:/root/otau -v /opt/deconz:/root/.local/share/dresden-elektronik/deCONZ --device=/dev/ttyACM0 -e DECONZ_WEB_PORT=801 -e DECONZ_WS_PORT=445 -e DECONZ_VNC_PORT=5930 -e DECONZ_VNC_PASSWORD=... -e DECONZ_VNC_MODE=1 -e DEBUG_INFO=1 marthoc/deconz

@ ReX1983 Dies hat hier afaik nichts mit diesem Problem zu tun. Bitte öffnen Sie eine separate Ausgabe. Ich denke, Sie sollten in der Docker-Version Repo posten. https://github.com/marthoc/docker-deconz

Moderationshinweis:

Bevor hier alles durcheinander kommt, möchte ich hier einen Bereich festlegen.

Alles, was mit dem ursprünglichen Problem zu tun hat: IKEA-Leuchten, die gelegentlich die Verbindung verlieren, sind in dieser Ausgabe zulässig.

Alle anderen Probleme im Zusammenhang mit der Firmware können hier veröffentlicht werden

Eigentlich noch nicht ... Ich habe noch keine Zeit für ein Upgrade gefunden. Außerdem habe ich keine Zeit gefunden, auf z2mqtt umzusteigen. Die gute Nachricht ist also, dass ich auf die neue Firmware aktualisieren werde und wenn es etwas zu berichten gibt, werde ich es tun.

@ JBS5 , dein Trigger hat geholfen;)

Ich habe gerade die Firmware und die neueste deCONZ .deb installiert. Bisher kann ich bestätigen, dass das Quell-Routing funktioniert, natürlich noch keine Rückschlüsse auf die Stabilität. Ich werde euch auf dem Laufenden halten

ZigBee Network Layer Data, Dst: 0x0ea4, Src: DeConz
    Frame Control Field: 0x0608, Frame Type: Data, Discover Route: Suppress, Security, Source Route Data
    Destination: 0x0ea4[0x0ea4]
    Source: 0x0000[DeConz]
    Radius: 10
    Sequence Number: 190
    [Extended Source: dresden-_ff:ff:00:c4:9a (00:21:2e:ff:ff:00:c4:9a)]
    [Origin: 366]
    Source Route, Length: 2
        Relay Count: 2
        Relay Index: 1
        Relay 1: 0xc803[0xc803]
        Relay 2: 0xf1e5[0xf1e5]
    ZigBee Security Header

@ ReX1983 Schauen Sie, wie das OTA-Plugin funktioniert https://github.com/dresden-elektronik/deconz-ota-plugin und aktualisieren Sie Ihre Geräte.
Entschuldigung, aber es ist ein Kommunikationsproblem mit dem IKEA-Gerät.

@ morfei1 @ peer69
Ich kann bestätigen, dass es nicht nur durch die GU10-Glühbirnen verursacht wird. Ich hatte das Routing und verlor lange Zeit Verbindungsprobleme ohne GU10 in meinem System.

Ich hatte nach der Veröffentlichung von .82 einige anfängliche Probleme mit der neuen Firmware auf meinem Conbee 1.
Aber jetzt, nachdem sich das Netz und einige Stromzyklen beruhigt haben, war es in den letzten Tagen absolut stabil.

So dumm ich auch bin, ich habe mich entschlossen, alle meine Lampen auf die neueste Firmware (OTAU) zu aktualisieren, um eine bessere Ausgangsbasis zu haben, wenn es zukünftige Probleme gibt. Wünsch mir Glück. Werdet euch über den Fortschritt auf dem Laufenden halten.

@tubalainen bist du auf HA Add-On?

@tubalainen bist du auf HA Add-On?

Nein, ich verwende HA Core unter Debian im Docker - daher verwende ich auch das eigenständige Docker-Paket https://github.com/marthoc/docker-deconz . Beide verwenden die von dresten bereitgestellte .deb-Datei, sodass sie identisch funktionieren sollten. Ich bin nicht sicher, ob das OTAU-Plugin im deconz HA-Add-On enthalten ist.

Ich stimme nur meinen bisherigen Beobachtungen zu.

Ich habe nur Probleme mit meinem Ikea GU-10 (23 davon), und ich verwende den Home-Assistenten, der über die Rest-API eine Verbindung zu deconz (Docker) herstellt, und ich kann sehen, wie HA die Ereignisse erfolgreich mit deconz abfeuert.

Wenn ich HA zum Einschalten verwende, schalten sich 17 Glühbirnen nacheinander (direkt nacheinander) vielleicht 3 von 17 nicht ein, aber HA sieht sie als eingeschaltet an.
ABER wenn ich eine Gruppe in Dekonz mache. Setzen Sie alle Lichter in diese Gruppe und fordern Sie HA auf, diese Gruppe einzuschalten. Es gab noch keine Probleme. Alle Lichter gehen an.

Verwenden der Firmware: 0x26650700 Ich habe keine Verbesserung festgestellt (außer dass ich diese 17 Lampen aus irgendeinem Grund neu koppeln musste, und selbst nach dem erneuten Koppeln hatte ich die gleichen Probleme).

Ist es vielleicht eine Einschränkung der Rest-API?

@MartinTerp : Wenn Sie für jedes Gerät jeweils einen Befehl anstelle eines Befehls für eine Gruppe verwenden, schlägt dies fehl, möglicherweise nicht jedes Mal, aber meistens tun zufällige Geräte, die etwas tun sollen, dies nicht.

Meine Problemumgehung hierfür ist eine Verzögerung von 5 Sekunden zwischen den Befehlen. Zum Beispiel
Wenn ich meine Schlafzimmerbeleuchtung um 23:00 Uhr um bri: 127 und ct: 454 einschalten möchte, und auch in meinem Flur gebe ich 5 Sekunden Verspätung für einen der Räume. Wenn ich die Verzögerung nicht einstelle, wird der vollständige Befehl für einen der Räume oder möglicherweise für beide zufällig nicht ausgeführt. Ich experimentiere viel damit. Es ist ähnlich wie der Ikea-Fehler, mit dem Farbe und Helligkeit von Schaltern nicht gleichzeitig verarbeitet werden können.

Ich weiß nicht genau, was das ist, ein Dekonz-Fehler, eine ZigBee-Einschränkung im Allgemeinen oder ein Ikea FW-Fehler. Vielleicht ist es mein Mangel an Wissen, wie ZigBee funktioniert, aber die 5-Sekunden-Verzögerung funktioniert immer für mich.

In der Regel verwende ich immer: Sand so wenig Befehle wie möglich oder eine Verzögerung. So halten Sie den Kanal sauber.

Wenn Sie mehrere Gruppen / Lichter gleichzeitig wechseln müssen, ist es, wie Sie bemerkt haben, immer besser, eine neue Phoscon-Gruppe zu erstellen. Fügen Sie diese Gruppen von Lichtern hinzu und senden Sie einen einzelnen Gruppenbefehl an sie. Sie können viele verschiedene Gruppen haben, einschließlich des gleichen Lichts. Wir sind nicht darauf beschränkt, nur eine Gruppe pro Licht zu verwenden. Wenn Sie nicht viele Gruppen in Phoscon haben möchten, ist die Verzögerung Ihr bester Freund.

@ morfei1 Ich verwende eine ähnliche Problemumgehung und sie funktioniert die meiste Zeit mit einer Verzögerung von 5 Sekunden zwischen allen Befehlen.
@MartinTerp Ich hatte dieses Problem auch mit anderen Geräten als den IKEA-Tradfri-Leuchten, zum Beispiel den OSRAM Smart Plugs und Light Strips. Ich denke, es ist möglich, obwohl das Problem durch einige fehlerhafte Tradfri-Lights verursacht wurde, die die Befehle nicht weiterleiten.

Aber es soll nicht so sein, oder?
In dem Moment, in dem das Skript sie mit einer Verzögerung von 1 Sekunde 1-zu-1 einschaltet, sollte es in der Lage sein, damit umzugehen?

@ morfei1 @MartinTerp

Ich habe auch Verzögerungen + verwendet, die ich zweimal pro ausgelöster Automatisierung vom Home Assistant aus ein- und ausschalte.

Ich habe jetzt die Verzögerungen entfernt und Befehle seit .82 wiederholt.

Ich bin mir ziemlich sicher, dass es keine Verzögerung von 5 Sekunden brauchen soll. Ich denke, dass dies bei einer früheren Version nicht benötigt wurde, aber ich würde nicht darauf wetten, da mein Netzwerk seitdem gewachsen ist. Möglicherweise verbessern 82 (noch nicht mit reduzierter Verzögerung versucht) oder zukünftige Versionen dieses Verhalten.

@ morfei1 @githtz @tubalainen @martinterp

Könnten wir die Diskussion darüber führen, wie Geräte-Firmwares an anderer Stelle aktualisiert werden können?

Wir kümmern uns nicht um die Aktualisierung der Firmware?

Wenn ich es richtig lese, sind die Probleme beim Senden mehrerer Befehle, bei denen nicht alle durchkommen, unterschiedlich. Dies ist wahrscheinlich eher ein Problem mit dem Taskplaner.

Ich würde vorschlagen, ein separates Problem zu öffnen, z. B. "Nicht alle Lichter reagieren, wenn Unicast-Befehle an mehrere Lichter gesendet werden".

Hier geht es eher darum, wann Lichter vollständig verloren gehen und überhaupt nicht erreichbar sind, was mit dem Routing zusammenhängen kann.

Von Mimiix redigiert

Von Mimiix redigiert

@inconsx @ ReX1983 Ich dachte, ich wäre klar auf https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment -696541484 und https://github.com/dresden-elektronik/deconz- Rest-Plugin / Issues / 1261 # Issuecomment -696046160

Bitte halten Sie sich an diese Regeln. Öffnen Sie separate Probleme, wenn Sie möchten.

Hier ist mein Feedback: Ich habe auf die neueste Firmware und die Deconz-API aktualisiert. Ich betreibe mein Netzwerk von HA aus.

Ich habe ungefähr 72 Knoten, die meisten davon sind IKEA GU10-Leuchten. Nach dem Upgrade bemerkte ich zwei verschiedene GU10, die an zwei verschiedenen Tagen "gestorben" waren. Der einzige Weg, es zurückzubekommen, ist das Aus- und Einschalten. Das GU10 verwendet eine Vorrichtung von 1.2.217 und 1.2.221. Ich werde versuchen, sie alle auf dieselbe Version zu aktualisieren.

Ich habe nur 4 GU10, ich denke, diese sind von der ersten veröffentlichten Version, die auf der neuesten ota-Version läuft. Ich hatte nie ein Problem damit in Bezug auf die Erreichbarkeit, nur meine Szenen waren nach dem leichten Firmware-Update durcheinander.

Ich hatte gerade eine meiner IKEA TRADFRI-Lampen E14 W op / ch 400lm Version 1.2.214 nicht mehr reagiert. Diese Lampe hat dies viele Male und auf verschiedenen Dekonz-Firmwares getan. Im Moment verwende ich deconz 26370500 und 2.05.82.

Ich habe nur 4 GU10, ich denke, diese sind von der ersten veröffentlichten Version, die auf der neuesten ota-Version läuft. Ich hatte nie ein Problem damit in Bezug auf die Erreichbarkeit, nur meine Szenen waren nach dem leichten Firmware-Update durcheinander.

Haben Sie nach dem Update auf 2.3.050 eine Stabilitätsverbesserung bei diesen GU10-Lampen festgestellt? Ich bin jetzt auf 0x26650700 und seit dem Update auf 2.3.050 (von 17 Glühbirnen) scheint mein Netzwerk viel stabiler zu sein. Geräte werden nicht über Nacht offline geschaltet und meine Aqara-Tasten funktionieren bei den ersten Versuchen. Es ist jetzt 4 Tage, so früh zu sagen.

Ich habe nur 4 GU10, ich denke diese sind von der ersten veröffentlichten Version

Es gibt tatsächlich günstigere Versionen von IKEA GU10 (nur W). Sie wurden noch nie auf 2.x-Software aktualisiert und laufen noch auf 1.2.214. Und das waren die problematischsten. Ich persönlich gebe einfach auf und jetzt laufen sie reibungslos mit dem IKEA Hub.

Ich denke, @antonbo nähert sich dem Verlauf des Problems.
IKEA verwendet dieselben Firmware-Images mit unterschiedlicher Hardware (Netzteil / LED-Laufwerke) und hat unterschiedliche Einstellungen in den "Benutzerdaten" für unterschiedliche Hardware (und die Modell-ID ist darin gespeichert). So kann eine Firmware auf einer Hardware (E14) einwandfrei funktionieren und auf anderen (GU10 / E27) Probleme haben.
Ein Unterschied besteht darin, dass der IKEA GW im ZLL-Modus (auf Zigbee PRO) ausgeführt wird und nicht den Gerätestatus abruft. Er hört nur auf Statusänderungen, die die Geräte im Netzwerk senden (ala Zigbee PRO / ZB3-Standard) und mischt sie mit HUE und anderen Anbieter, bei denen der Koordinator den Status von den Geräten abruft (kein ZB3-Verhalten), können das Netzwerk einmal durcheinander bringen.
Ich habe das älteste IKEA RGBW und ein E27 Opal WW auf alter aktualisierter (1.X) Firmware, die in Ordnung läuft, und ein paar neue ZB3 GU10 WS, die großartig funktionieren. Mein Backbone besteht aus ungefähr 10 IKEA-Steckern, die die Netzwerkkommunikation stabil halten, und auch meine Xioami-Sensoren funktionieren mit allen einwandfrei.
Meiner Meinung nach ist dies kein allgemeines Problem mehr HW und vielleicht FW in Kombination mit dem Netzwerklayout und der Vermeidung einiger problematischer Geräte (wie OSRAM Outdoor Plug, das Pakete beschädigt und ständig Kinder verliert).

@manup Ich kann nur sagen, dass die neue Firmware mein System wesentlich schlechter gemacht hat als zuvor. Ob es sich um das Quell-Routing handelt oder um das, was es ist, ich habe jetzt jeden Tag eine oder zwei Glühbirnen festgefahren und muss aus- und wieder eingeschaltet werden. Ich habe sogar gesehen, dass eine meiner Philips-Lampen feststeckte, aber dafür war kein Aus- und Wiedereinschalten erforderlich. Ich weiß nicht, ob die Probleme jetzt durch die alte Firmware verursacht werden, auf der ich sie verwende, aber andererseits kann ich auch kein Upgrade durchführen, da sie stecken bleibt. :(

Ich frage mich, ob jemand weiß, ob das neuere GU10 noch Probleme hat oder nicht? Ich habe gehört, dass auf neueren Geräten ZigBee 3.0 ausgeführt wird. Meine Frau ist über diese Probleme nicht erfreut, sodass ich sie alle ändern kann, wenn dies hilft.

Ich habe heute Morgen ein hängendes Licht gehabt. Ich denke, es ist eines der neueren.

Das Licht reagierte nicht auf einen Befehl, wurde als offline angezeigt. Ein Powercycle hat das Problem nicht behoben. Ich musste es zurücksetzen und erneut zum Netzwerk hinzufügen.

@ JBS5 @djwlindenaar @lubbertkramer Feedback zu den neuesten Firmwares im Vergleich zu dieser Ausgabe?

Ich kann hinzufügen, dass ich 48 Stunden lang keine Probleme damit hatte, was dieses Thema anspricht und was ich zuvor erlebt habe.

Es muss jedoch Folgendes hinzugefügt werden

• Starten Sie den Container jede Nacht mit deconz neu
• Die Gruppierung wurde von Home-Assistant nach Deconz / Phoscon verschoben.

Ich hatte einige weniger ansprechende Glühbirnen vor den obigen Änderungen, obwohl eine bessere Erfahrung, aber noch nicht ab sofort.

@Mimiix ,

Was mich ärgert ist, dass sich das Netzwerk viel träger anfühlt. Die Zeit zwischen dem Drücken einer Taste und dem Einschalten des Lichts (über eine Regel) ist länger als zuvor. Auch das Einschalten des Lichts und das Ändern der Helligkeit erfolgt in zwei Schritten mit einer gewissen Zeit dazwischen. Ich muss noch in die Schnüffelprotokolle schauen, um zu überprüfen, was dies verursacht. Wahrscheinlich hat dies nichts mit der Änderung des Quellroutings zu tun, aber los geht's.

Ich hatte ein Licht, das nicht mehr reagierte, aber ich habe diese Situation auch nicht analysiert, so schwer zu sagen, was passiert ist.

Meine E27 Ikea-Lampen haben gemeinsam aufgehört zu kooperieren.
Bisher hat Power Cycling für einige von ihnen funktioniert. 3 sind immer noch nicht zurück. Ich denke, ich muss sie erneut hinzufügen ... :(

Firmware: 26610700
Version: 2.05.84 / 14.9.2020
(Raspbee2)

@umrath Dies scheint nichts mit dem in dieser Ausgabe behandelten Problem zu

Das Symptom sieht für mich sehr ähnlich aus: Lampen reagieren ohne ersichtlichen Grund nicht mehr.

Wie ich gerade sagte: Das scheint nichts damit zu tun zu haben. Bitte öffnen Sie eine separate Ausgabe. Wir können immer später feststellen, dass dies zusammenhängt. Ich halte ein dichtes Schiff in dieser Angelegenheit.

Ja, ich denke auch, dass es verwandt ist. Nach ein paar Monaten ohne den Fehler hatte ich gestern erneut das Problem mit zwei Geräten, einem (sehr alten) IKEA E27 und dem neueren IKEA-Ausgang, beide mit aktueller Firmware.

Das einzige, was ich damals getan habe, war, einen KADRILJ-Rollo außerhalb der Reichweite und später zurück zu transportieren, aber das könnte völlig unabhängig sein.

Das Starten des Schnüfflers zeigt das gleiche Problem:

• Die Geräte senden weiterhin regelmäßig NWK-Verbindungsstatusbefehle.
• Aber immer mit einer leeren Liste scheinen sie alle umgebenden Router zu ignorieren;
• Sie bestätigen eingehende Befehle auf MAC-Ebene.
• Sie reagieren auf Beacon-Anfragen und senden ein Beacon aus, aber das ist die einzige "Antwort", die sie geben.

Irgendwie scheint der ZigBee-Stack auf den IKEA-Geräten teilweise für NWK- und APS-Schichten und höher abzustürzen, oder eingehende NWK-Puffer sind voll und werden nie freigegeben.

Ich habe versucht, die Geräte wieder zum Leben zu erwecken, indem ich Folgendes gesendet habe:

• ZDP Mit Wiedereintritt verlassen;
• NWK Mit Wiedereintritt verlassen (untere Ebene).

Beide werden auf MAC-Ebene bestätigt, ansonsten jedoch ignoriert.

Ich habe dann versucht, die NWK-Verbindungsstatusbefehle des Koordinators mit einem gültigen Eintrag zu fälschen, der angibt, dass auf dem Gerät eingehende und ausgehende Verbindungskosten (3/3) anfallen, in der Hoffnung, dass das Gerät den Koordinator in seiner Nachbartabelle abholen würde. ... hat auch nicht funktioniert.

Leider scheint es keine Möglichkeit zu geben, die Situation zu umgehen, nachdem dies geschehen ist, und das IKEA-Gerät befindet sich in diesem größtenteils toten Zustand. In einigen Foren kann das Verhalten mit allen Arten von Gateways und zugrunde liegenden ZigBee-Stapeln beobachtet werden. Das ist interessant, da zum Beispiel die Hue-Brücke keine ausgefallenen ZigBee-Aufgaben wie das Abfragen von Nachbartabellen oder Bindungen und das Melden erledigt und dennoch der Fehler auftritt.

Was IKEA tun muss, ist, mindestens einen Watchdog zu implementieren, der überprüft, ob die NWK- und APS-Komponenten noch funktionieren, und das Gerät den Watchdog zum Neustart auslösen lässt. Dies würde den Fehler nicht beheben, aber es würde zumindest das Gerät funktionsfähig halten, wenn es passiert.

@manup Ist Ihr alter E27 ein LL mit Diagnosecluster?
Vielleicht kann es interessant sein zu sehen, ob mit den Schaltern dort etwas passiert, mit einigen Wochen dazwischen.
Es kann das Problem nicht beheben, gibt aber einen Hinweis darauf, dass die Firmware nicht funktioniert.
Gute Beobachtung und Schlussfolgerungen mande !!

Ich denke, Silabs bekommt für einen der größten Kunden etwas mehr Bug-Jagd zu tun ;-)

Hallo, das verwirrt mich, da ich dieses Problem seit meinem Wechsel zu Z2M mit dem ZZH vor einigen Monaten nicht mehr gesehen habe. Vielleicht gibt es eine andere Variable in der Gleichung. Wäre toll, wenn jemand anderes, der den gleichen Schritt gemacht hat, dies bestätigen könnte.

@mvjt Verwenden Sie Rasp / CornBee mit Z2M oder einem anderen Koordinator?
Verschiedene ZigBee-Stapel funktionieren auf unterschiedliche Weise und können unterschiedliche Probleme haben / verursachen.

Edit: Sorry ich sehe ZZH = neuer TI Koordinator.
deCONZ NCP = Atmel / Mikrochip
IKEA-Geräte / NCP = Sirlabs EFR32 / EZSP

Ich kann bestätigen, dass HA / ZHA / Zigpy / Bellows mit dem Modul "Billy EZSP" = IKEA ICC-1-A als Koordinator für IKEA-Router und Endgeräte von IKEA und Xiaomi sowie für NO OSRAM- oder Xiaomi-Router hervorragend funktioniert.

@MattWestb Ja, das E27 verfügt über den Diagnosecluster, aber ich habe ihn noch nicht

Zumindest in der Vergangenheit ist das Problem, das ich sehe, auch bei TI CC253X aufgetreten, und am Ende des Problems wird das CC26X2R1 erwähnt, aber das war der Zustand im Januar, in dem es sich inzwischen möglicherweise verbessert hat. https://github.com/Koenkk/zigbee2mqtt/issues/2032#issuecomment -547483373

Es könnte sich im Allgemeinen nicht um einen Silabs-Fehler handeln, sondern auch um benutzerdefinierte Elemente in der Anwendungsschicht. Ich denke, dass neuere Hue-Geräte auch Silabs verwenden. Von der Hue-Brücke gibt es mindestens TI- und Microchip-Versionen.

Es ist eine wirklich böse Sache, in vielen Fällen tritt der Fehler möglicherweise gar nicht oder erst nach einigen Monaten auf, in anderen Netzwerken tritt er in viel kleineren Intervallen auf. Ich denke, es ist auch wichtig, wie die Netzwerke betrieben werden und dass Lichter, die regelmäßig ausgeschaltet werden, weniger betroffen sind.

@manup Ich habe ein Szenario, das Ihr "IKEA-Problem" sehr gut
Wenn Sie Ihr Netzwerk eingerichtet haben, beginnt es mit einem Netzwerkschlüssel und der Sicherheitsrahmenzähler beginnt zu ticken. Wenn Sie das Netzwerk nicht sehr lange reformieren oder den Netzwerkschlüssel rollen, bleibt der Zähler stehen, da er das Maximum von 0xFFFFFFFF (32 Bit) erreicht hat und nicht ansteigen kann.
Dann wirft das Gerät alle Daten, die in die ZigBee-Schicht kommen, weil der Frame-Zähler falsch ist, die untere Netzwerkschicht jedoch weiterhin normal funktioniert.
Das Problem Ich kenne keine Methode, um den Status des Sicherheitsrahmenzählers von Geräten zu ermitteln. Ich denke, das ist nicht möglich, sehen Sie es in Wireshark (Denken = nicht wissen).

Dies deutet darauf hin, dass früh gekoppelte Geräte, die nicht zurückgesetzt werden, schneller zum Stillstand kommen.
Neuere gekoppelte / zurückgesetzte Geräte laufen länger, bevor der Zähler blockiert.
Mutch-Befehle an ein Gerät führen auch dazu, dass es schneller blockiert als ein Gerät, das nicht so "kommunikativ" ist.

Es wird empfohlen, den Netzwerkschlüssel regelmäßig im ZB3-Netzwerk zu rollen, um die Sicherheit zu gewährleisten, und anschließend den Sicherheitsrahmenzähler zurückzusetzen, damit er nicht blockiert wird.
Einige Informationen AN1233: ZigBee-Sicherheit 2.1.6 Der Zähler für Netzwerksicherheitsrahmen.

Es ist ein wildes Brainstorming, aber es kann sein, dass das Problem nach langer Zeit im Netzwerk auftritt.

Ein Test besteht darin, den Netzwerkschlüssel zu rollen und das "lebende" Gerät sollte ziemlich lange in Ordnung sein, aber das blockierte Gerät muss zurückgesetzt / wieder verbunden werden, um den Sicherheitsrahmenzähler von Null zu starten.

Hrm, ziemlich sicher, dass durch Rollen des Netzwerkschlüssels alle Xiaomis gelöscht werden.

Falsch 200% sicher, dass sie nicht aktualisieren und das Netzwerk verlassen (die alten keine ZB3) !!!

@Adminiuga Haben Sie versucht, den Netzwerkschlüssel auf EZSP zu rollen?
Ich finde es interessant vom Ergebnis !!!

Ich habe nicht versucht, den Netzwerkschlüssel zu rollen. Eigentlich wäre es interessant zu wissen, wie viele Implementierungen den Schlüssel regelmäßig rollen.
Aber ich kann bestätigen, dass Pan-ID-Änderungen sehr hohe Chancen haben, dass Xiaomis abfällt, wie 4 von 5 Chancen

Ich habe einige Sicherheits-Penetrationstests gesehen, bei denen Pan-ID von der Straße beschnüffelt wurde und die einige Monate später mehrmals zurückgingen, und keiner der großen Lichtanbieter (hier nicht genannt) hat den Netzwerkschlüssel nach einem Jahr nicht gerollt (Mariahilferstraße in Wien) ) also hast du höchstwahrscheinlich recht (agen).

Wenn und nur wenn es der Sicherheitsrahmenzähler ist, der das Problem verursacht, dann ist es für alle echten ZigBee 3-Geräte gleich, dann ist es in der "Basis-Geräte-Verhaltensspezifikation" definiert und in der alten LL empfohlen, aber höchstwahrscheinlich nicht mit Nein zigbee PRO-Geräte (alte HA- und LL-Geräte) oder nicht zertifizierte Geräte (nicht benannt .... mi).
Dann ist es besser, die Netzwerkschlüssel "manuell" oder zweimal im Jahr zu rollen und das Haus nicht abzureißen, um eingebaute Geräte mehrmals im Mund zurückzusetzen, als sie blockieren und das Zurücksetzen / Wiedereinsetzen alter Xiaomi-Sensoren in Anspruch nehmen, die normalerweise nicht vorhanden sind integriert in die Hausstruktur und einfacher zurückzusetzen (normalerweise offen verbinden und den Knopf drücken und sie verbinden).
Menny "chinese Zigbee 3" wirft den "alten" Sicherheitsrahmenzähler nach dem Zurücksetzen der Stromversorgung und verwendet einen neuen aus dem ersten ankommenden Paket seiner Nachbarn (habe gesehen, dass beim Testen von tasmotas zigbee 3-Problemen der NCP-Zähler beim Neustart fälschlicherweise zurückgesetzt wurde). Sie sind also nur Repower und sie sind wieder da.

Wir hatten letztes Jahr auch einige Tests durchgeführt, kein Gateway hat den Netzwerkschlüssel gedreht. Wie in der Spezifikation beschrieben, ist dies die einzige Möglichkeit, den NWK-Sicherheitsrahmenzähler zurückzusetzen, wenn die Netzwerkschlüsselnummer erhöht wird. Ich teile auch Bedenken, dass dies von allen Geräten unterstützt wird. In der Regel werden Funktionen, die fast nie verwendet werden, nicht gut getestet. Ich hoffe wirklich, dass ich hier falsch liege und es für die meisten Geräte funktioniert.

In jedem Fall ist das Zurücksetzen des Frame-Zählers für das Gateway am wichtigsten, da es die meisten ausgehenden Befehle enthält. Lichter und Sensoren sollten für die nächsten Jahre in Ordnung sein. Derzeit ist dies kein Problem, aber es wird eines in zwei bis drei Jahren, wenn der Gateway-Zähler in größeren Netzwerken erreicht wird. Dafür haben wir bereits Pläne zu prüfen, ob die Drehung des Netzwerkschlüssels sowie das Zurücksetzen der Schlüsselnummer und des Frame-Zählers funktioniert.

Wie auch immer, das Problem hier ist anders, die Frame-Zähler des Gateways und die Lichter im Fehlerzustand sind immer noch in Ordnung und ziemlich niedrig.

@djwlindenaar Ich frage mich,

Nun, danke für die Anerkennung ... Um ehrlich zu sein, bin ich mit der aktuellen Netzwerkstabilität nicht ganz zufrieden. Es ist seit dem Update auf die neueste Deconz-Firmware ausgefallen. Einige Lichter gingen in den letzten Wochen offline, wo dies lange vor dem Upgrade nicht geschah. Ich habe mit den Patches gearbeitet, die regelmäßige Attributberichte für IKEA-Leuchten ermöglichen, die ich in der aktuellen Situation noch nicht angewendet habe

Obwohl es Spaß macht, dies zu analysieren, ist es ein Hobby für mich und meine Zeit ist jetzt voll von Umbauten des Hauses beansprucht. Ich werde sehen, ob ich ein bisschen Zeit dafür haben kann ...

Nun, danke für die Anerkennung ... Um ehrlich zu sein, bin ich mit der aktuellen Netzwerkstabilität nicht ganz zufrieden. Es ist seit dem Update auf die neueste Deconz-Firmware ausgefallen.

Ich habe die gleiche negative Erfahrung. Jetzt gehen die meisten meiner Xiaomi-Geräte (hauptsächlich Aqara-Wandschalter) tagsüber häufig offline und arbeiten nach wenigen Minuten wieder (ich nehme an, dies liegt an der Tatsache, dass Xiaomi-Geräte neu gestartet werden, wenn sie keine Antwort auf die Anfrage von erhalten Attribute des Zeitclusters vom Koordinator).

Die neue Version 2.5.88 könnte die Situation verbessern. Hier wurde die IKEA-Berichtskonfiguration geglättet, damit Statusübergänge das Netzwerk nicht mit Berichten bombardieren. Vor dem Zustandsübergang wurde jedes Attribut sehr schnell gemeldet.

Die neue Version 2.5.88 könnte die Situation verbessern. Hier wurde die IKEA-Berichtskonfiguration geglättet, damit Statusübergänge das Netzwerk nicht mit Berichten bombardieren. Vor dem Zustandsübergang wurde jedes Attribut sehr schnell gemeldet.

Klingt vielversprechend :) Auch ein / aus ist ein Zustandsübergang, denke ich? Oder meistens Helligkeits- oder Farbmodusänderungen?
Eine minimale Firmware-Version, die für diese Änderung benötigt / empfohlen wird?

Nur Helligkeit und alle farbspezifischen Attribute wie colorX, colorY und Farbtemperatur.
Für die Firmware würde ich immer die neueste Version 0x26660700 empfehlen (im Fall von ConBee II und RaspBee II).

Die neue Version 2.5.88 könnte die Situation verbessern. Hier wurde die IKEA-Berichtskonfiguration geglättet, damit Statusübergänge das Netzwerk nicht mit Berichten bombardieren. Vor dem Zustandsübergang wurde jedes Attribut sehr schnell gemeldet.

@manup , ich denke, dieses Update hat auch die Stabilitätsprobleme mit den Aqara-Geräten gelöst. Vielen Dank

Die neue Version 2.5.88 könnte die Situation verbessern. Hier wurde die IKEA-Berichtskonfiguration geglättet, damit Statusübergänge das Netzwerk nicht mit Berichten bombardieren. Vor dem Zustandsübergang wurde jedes Attribut sehr schnell gemeldet.

@manup , ich denke, dieses Update hat auch die Stabilitätsprobleme mit den Aqara-Geräten gelöst. Vielen Dank

Leider ist das Problem (# 3605) immer noch da, ich bin zu früh zu Schlussfolgerungen gekommen