Deconz-rest-plugin: Les lumières IKEA ont parfois perdu la connexion

Même chose ici avec 2.05.58. Un Tradfri GU10 semble être un guichet automatique irresponsable:

Il m'est arrivé avec une bande de lumière teinte quelques jours auparavant, donc je ne suppose aucun problème spécifique à IKEA. Les appareils doivent être recyclés et reviennent à leur état normal après cela. Encore ennuyeux dans certains cas, principalement pour mes panneaux FLOALT qui sont directement alimentés et n'ont pas d'interrupteur mural pour les faire fonctionner.

1. Une idée pourquoi?

Le plugin de l'API REST marque une lumière comme inaccessible, lorsqu'elle ne reçoit pas de réponse plusieurs fois lors de l'interrogation de la lumière pour son état. La cause de ne pas recevoir de réponse est, par ordre de probabilité:
une. La puissance de la lumière a été coupée (par exemple par un interrupteur mural du 20e siècle);
b. Le réseau Zigbee a un hoquet (par exemple en raison d'interférences radio ou de problèmes de routage dans le maillage). Dans ce cas, la lumière réagit toujours aux commandes de groupe;
c. Le firmware de la lumière est tombé en panne.

1. Est-il possible de restaurer la connexion autrement que de déconnecter / connecter l'alimentation?

En a) et c): non. En b): oui.

Le plugin de l'API REST marque la lumière comme atteignable, lorsqu'il reçoit un message de sa part. La mise sous tension de la lumière provoque l'envoi d'un message _Device Announcement_. En b), typiquement, la lumière revient spontanément, lorsque le prochain sondage réussit. Vous pouvez également sélectionner le nœud dans l'interface graphique deCONZ et appuyer sur 0 .

Même problème également dans la version 2.05.59.

J'ai également ce problème, même après la mise à niveau vers 2.05.59. Aujourd'hui, l'une de mes trois lampes d'extérieur a "disparu".
Ses ampoules Tradfri toutes les trois.

@ebaauw Merci pour votre explication.

une. La puissance de la lumière a été coupée (par exemple par un interrupteur mural du 20e siècle);

Aucun interrupteur mural disponible pour ces lumières, je ne peux donc pas couper l'alimentation accidentellement.

b. Le réseau Zigbee a un hoquet (par exemple en raison d'interférences radio ou de problèmes de routage dans le maillage). Dans ce cas, la lumière réagit toujours aux commandes de groupe;

Les lumières ne réagissent pas aux commandes de groupe lorsque la connexion est perdue (les lumières sont attribuées à un variateur de teinte dans l'application Phoscon et ne répondent pas sur le variateur de teinte lorsque la connexion est perdue).

c. Le firmware de la lumière est tombé en panne.

Le firmware 1.2.214 est installé sur tous mes spots IKEA GU10. Vous en avez plus de 20 et une lumière aléatoire se déconnecte, disons une dans les 2-3 semaines.

Vous pouvez essayer la dernière version de deCONZ avec https://github.com/dresden-elektronik/deconz-rest-plugin/commit/48d2c39a267b5c6d025577eed7530be27932aa2c.

J'ai eu la même expérience deux fois ces derniers mois avec deux ampoules IKEA E14 différentes (IKEA fw 1.2.214).
Le cyclisme électrique a fonctionné les deux fois pour moi.

c. Le firmware de la lumière est tombé en panne.

Lorsque les lumières ne réagissent même pas aux commandes de groupe, cela ressemble à un crash du firmware.

Le 2.05.59 a adapté les paramètres de la passerelle IKEA pour configurer le rapport d'état de l'éclairage. Principalement dans l'espoir de ne pas déclencher de bogue en utilisant une configuration que IKEA lui-même ne teste pas. Notez que le changement n'entraînera plus l'utilisation de minuteries pour les rapports sur l'appareil.

La nouvelle configuration sera appliquée une fois qu'une lumière est mise hors tension.

Nous envoyons toujours des demandes de maintenance comme l'appartenance à un groupe et des requêtes de table voisine aux lumières, et pourrions les restreindre davantage si la stabilité ne s'améliore pas avec 2.05.59.

Gardez à l'esprit qu'il peut également y avoir la possibilité qu'un bogue se trouve dans le micrologiciel léger qui n'est lié à aucune requête envoyée par la passerelle.

c. Le firmware de la lumière est tombé en panne.

Lorsque les lumières ne réagissent même pas aux commandes de groupe, cela ressemble à un crash du firmware.

Le 2.05.59 a adapté les paramètres de la passerelle IKEA pour configurer le rapport d'état de l'éclairage. Principalement dans l'espoir de ne pas déclencher de bogue en utilisant une configuration que IKEA lui-même ne teste pas. Notez que le changement n'entraînera plus l'utilisation de minuteries pour les rapports sur l'appareil.

La nouvelle configuration sera appliquée une fois qu'une lumière est mise hors tension.

Nous envoyons toujours des demandes de maintenance comme l'appartenance à un groupe et des requêtes de table voisine aux lumières, et pourrions les restreindre davantage si la stabilité ne s'améliore pas avec 2.05.59.

Gardez à l'esprit qu'il peut également y avoir la possibilité qu'un bogue se trouve dans le micrologiciel léger qui n'est lié à aucune requête envoyée par la passerelle.

+1 sur "pas forcément lié au déconz mais plutôt au réseau Zigbee ou constructeur FW" en corrélation avec l'interprétation standard Zigbee chez les constructeurs FW.

Je viens de mettre à jour la version 2.05.59 et après le redémarrage de deconz, la même lumière n'est plus accessible. Appuyer sur 0 dans l'interface graphique ne le ramène pas. Toute autre lumière fonctionne. Dans mon cas, cela pourrait aussi bien être un problème avec la lumière elle-même.

@ peer69 @ thomas70 Avez-vous mis la lumière sous tension car cela est nécessaire mentionné par @manup sur https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment -463948127?

La nouvelle configuration sera appliquée une fois qu'une lumière est mise hors tension.

Bon indice, je n'ai pas fait ça. Pour l'instant, je devais revenir à .58 pour une autre raison (une charge élevée du processeur rendant la passerelle insensible), j'essaierai cela plus tard dans la journée avec .59 à nouveau et powercycle toutes les lampes ikea.

J'ai aussi ce problème, c'est arrivé deux fois pour la même lumière GU 10. Actuellement en cours d'exécution 2.05.59, et j'ai redémarré les lumières après la mise à jour.

J'ai oublié d'ajouter qu'il semble parfois que c'est la même ampoule qui échoue constamment. Il y a quelque temps, j'ai eu des problèmes avec une autre ampoule, et ce serait toujours celle-là d'arrêter de réagir.

Après le cycle d'alimentation, mes ampoules IKEA sont revenues. Mais mon panneau IKEA FLOALT WS est toujours hors ligne

Je rencontre le même problème et je le fais depuis un certain temps, et je dirais que .59 a en fait aggravé les choses pour moi. J'ai 80 nœuds dont 32 sont des lumières et des interrupteurs Trådfri, 5 sont des lumières Hue et le reste sont différents appareils alimentés par batterie Xiaomi comme la température, le mouvement, le détecteur de fumée, etc. Chaque type d'appareil n'a pas répondu au moins une fois, donc dans mon cas ce ne sont pas seulement les lumières Trådfri, mais à l'époque, j'ai juste des problèmes avec les lumières Trådfri et Hue.

Le fait est que j'ai fait passer toutes les lumières à travers un pont Hue et les capteurs Xiaomi à travers la passerelle Xiaomi plus tôt, puis ils étaient tous solides, donc je ne pense pas que ce soit le micrologiciel de l'appareil qui est le coupable dans mon cas, sauf s'il est causé par le changement de circonstances.

J'ai six lumières Trådfri GU10 en un seul endroit qui fonctionnaient parfaitement auparavant, mais après la mise à niveau vers .59 et plusieurs cycles d'alimentation plus tard, elles ne répondent presque plus complètement et je devrai probablement les réinitialiser. Ce qui est étrange, c'est que cette absence de réponse semble également «se déplacer» à partir de différentes lumières en fonction des lumières qui sont alimentées. Si je coupe l'alimentation de certaines des lumières qui ne répondent pas, cela peut prendre un certain temps, puis c'est soudainement une autre lumière qui ne veut pas fonctionner correctement. Peut-être y a-t-il quelque part un décalage qui brise les choses?

Le fait est que j'ai fait passer toutes les lumières à travers un pont Hue et les capteurs Xiaomi à travers la passerelle Xiaomi plus tôt, puis ils étaient tous solides, donc je ne pense pas que ce soit le micrologiciel de l'appareil qui est le coupable dans mon cas, sauf s'il est causé par le changement de circonstances.

Intéressant, aviez-vous également les 32 lampes Ikea sur le réseau Hue? Je demande parce que le pont Hue utilise uniquement le sondage et ne configure pas le rapport d'attributs.

Aviez-vous également des périphériques de routeur comme les lumières Hue ou Ikea sur le réseau Xiaomi?

J'ai six lumières Trådfri GU10 en un seul endroit qui fonctionnaient parfaitement auparavant, mais après la mise à niveau vers .59 et plusieurs cycles d'alimentation plus tard, elles ne répondent presque plus complètement et je devrai probablement les réinitialiser. Ce qui est étrange, c'est que cette absence de réponse semble également «se déplacer» à partir de différentes lumières en fonction des lumières qui sont alimentées. Si je coupe l'alimentation de certaines des lumières qui ne répondent pas, cela peut prendre un certain temps, puis c'est soudainement une autre lumière qui ne veut pas fonctionner correctement. Peut-être y a-t-il quelque part un décalage qui brise les choses?

Hmm c'est assez mauvais Je me demande vraiment comment cela se produit, 2.05.59 est bien "familier" aux lampes Ikea que les versions précédentes. La configuration se déroule maintenant comme la passerelle Ikea le fait.

Lorsqu'un voyant ne répond plus, vous pouvez sélectionner le nœud dans deCONZ et appuyer sur 0 s'il redevient réactif / jaune, le voyant n'a pas besoin d'être redémarré. Notez que la lumière devenant un zombie dans ce cas sera bientôt corrigée, cela peut se produire sur une certaine constellation du réseau actuellement.

Au fait les questions habituelles:

• Quelle version de firmware utilisez-vous?
• RaspBee ou ConBee?
• Si ConBee utilisez-vous un câble d'extension USB?

Cela a pris un peu plus de temps que prévu, mais maintenant tout semble fonctionner à nouveau correctement. Au moins pour l'instant d'après ce que je peux dire.

J'ai redémarré le serveur et mis sous tension toutes les lumières alimentées par le réseau pour m'assurer qu'elles récupéraient la dernière configuration, mais malgré cela, il a fallu quelques heures avant que le problème ne disparaisse, j'étais donc un peu prématuré dans mon hypothèse que le problème est resté car il n'a pas fonctionné tout de suite.

Intéressant, aviez-vous également les 32 lampes Ikea sur le réseau Hue? Je demande parce que le pont Hue utilise uniquement le sondage et ne configure pas le rapport d'attributs.

Oui, en quelque sorte. J'avais 31 lampes Ikea sur le réseau Hue ainsi que les lumières Hue. Le 32ème appareil Ikea est la prise de courant que je n'avais pas achetée à l'époque.

Aviez-vous également des périphériques de routeur comme les lumières Hue ou Ikea sur le réseau Xiaomi?

Non, juste des capteurs alimentés par batterie

Lorsqu'un voyant ne répond plus, vous pouvez sélectionner le nœud dans deCONZ et appuyer sur 0 s'il redevient réactif / jaune, le voyant n'a pas besoin d'être redémarré. Notez que la lumière devenant un zombie dans ce cas sera bientôt corrigée, cela peut se produire sur une certaine constellation du réseau actuellement.

J'ai essayé cela plusieurs fois plus tôt sans effet. Et en ce qui concerne le matériel et la configuration, j'utilise un ConBee avec un câble d'extension USB et 262F0500. Puisque tout semble bien fonctionner pour moi, cette information n'est peut-être d'aucune utilité pour le moment, mais je vais essayer de ne pas tirer de conclusions hâtives et de laisser le réseau fonctionner pendant quelques jours pour m'assurer que le problème ne fonctionne pas revenir.

J'utilise .59 depuis le week-end dernier et je perds toujours des lumières Ikea aléatoires. (16 ampoules E27 sur la façade de la maison.)
L'ampoule FW est la même que les autres encore sur la passerelle Ikea.
Utilisation de ConBee avec 262F0500 FW.
Le week-end dernier, j'ai également acheté un pont HUE et j'étais sur le point de commencer à déplacer les lumières lorsque j'ai remarqué la note de publication 'Under the hood' pour .59. A décidé de ne pas bouger, mais reconsidérera ce prochain week-end.
Deconz sera toujours mon meilleur contrôleur Xiaomi / mi Cube de choix. Je n'ai pas encore manqué un geste.

J'utilise .59 depuis le week-end dernier et je perds toujours des lumières Ikea aléatoires. (16 ampoules E27 sur la façade de la maison.)
L'ampoule FW est la même que les autres encore sur la passerelle Ikea.
Utilisation de ConBee avec 262F0500 FW.
Le week-end dernier, j'ai également acheté un pont HUE et j'étais sur le point de commencer à déplacer les lumières lorsque j'ai remarqué la note de publication 'Under the hood' pour .59. A décidé de ne pas bouger, mais reconsidérera ce prochain week-end.
Deconz sera toujours mon meilleur contrôleur Xiaomi / mi Cube de choix. Je n'ai pas encore manqué un geste.

J'ai un peu la même situation ici, 16 lumières IKEA, 2 prises de contrôle IKEA, une prise Heiman et une prise innr et quelques capteurs Xiaomi (cube / capteurs de porte / capteur de mouvement). Jamais eu de problèmes avec les appareils non-IKEA. Cependant, j'ai actuellement des problèmes presque quotidiens où une lumière IKEA tombe hors du réseau

J'utilise un Conbee avec un câble d'extension USB sur le firmware 0x26300500 et deCONZ .59

Mes lumières fonctionnent bien depuis un moment maintenant, mais il y a quelques jours, mon ampoule Trådfri E14 est soudainement devenue insensible. Un cycle d'alimentation plus tard, il est revenu à la vie.

Aujourd'hui, il était temps pour l'un des GU10 d'abandonner. Il est physiquement très proche de l'E14 mentionné précédemment, donc je ne sais pas si c'est une coïncidence ou non. Le GU10 peut très bien avoir été acheminé via le E14 même si toutes mes lumières sont à portée de ConBee.

Sélectionner les nœuds et appuyer sur 0 dans deCONZ ne fait rien. J'ai également essayé de redémarrer le conteneur deCONZ et, tout en redirigeant le réseau au démarrage, il ne connecte aucune route à cette ampoule spécifique. Quelle serait la meilleure approche ici pour procéder au dépannage?

12 jours plus tard, un autre GU10 devient inaccessible et ne se reconnecte pas sans un cycle d'alimentation.

Heureux de partager toutes les informations nécessaires pour aborder ce problème.

Idem ici, hier après 6 jours de connexion sans faille, j'ai perdu une de mes ampoules Tradfri .. allumer / éteindre et réinitialiser n'a pas aidé. Il est toujours jaune dans deConz mais ne peut pas le connecter ou le contrôler.

Pareil ici. Après quelques jours sans aucun problème aujourd'hui, deux de mes lampes GU10 Tradfri ont cessé de répondre. J'ai pu ramener l'un d'entre eux à la vie en appuyant sur 0 dans l'interface graphique, mais j'ai dû Powercycle l'autre.
Heureusement, cela ne semble se produire que pour les appareils GU10 atm, mes panneaux FLOALT n'ont pas encore eu de problèmes (dans ma configuration, ils ne peuvent être recyclés qu'en utilisant le disjoncteur).

Le problème a continué pour moi aussi. J'ai maintenant vu 3 à 4 ampoules GU10 supplémentaires perdant la connexion, ainsi qu'un de mes Hue E27 et un capteur de porte Xiaomi (aimant). Certaines lumières ont recommencé à fonctionner après un cycle d'alimentation, d'autres pas. Appuyer sur 0 ne fait rien.

Il est également à noter que le capteur Xiaomi a recommencé à fonctionner après avoir mis sous tension un GU10 adjacent et ne répondant pas, donc je suppose que le capteur passait à travers cette lumière, mais ne devrait-il pas automatiquement rediriger s'il y a des problèmes de connexion?

Même problème ici. Hier, j'ai mis à jour la dernière version .59 maintenant quelques lampes Ikea ne répondent plus

Salut, pouvez-vous donner plus d'informations sur l'ensemble du réseau, comme la taille du réseau et d'autres appareils alimentés par secteur?

J'ai réorganisé mon réseau domestique il y a quelques jours, y compris maintenant:

• 5x IKEA WS GU10 (firmware 1.2.221, code produit LED1537R6GU10EU)
  Avec l'adresse mac 0x000b57ff ..... (ancien lot)
• 2x IKEA dimmable E27 (firmware 1.2.214)
• 1x éclairage IKEA E14 WS (firmware 1.2.221)
• 1x répéteur IKEA (firmware 2.0.019)
• 1x prise IKEA (firmware 2.0.019)
• 1x OSRAM GU 10
• 1x ampoule de couleur OSRAM E27
• 1x prise OSRAM
• 1x ampoule de couleur Hue E27
• 1x ampoule Hue E27 dimmable lux

deCONZ 2.05.59; Micrologiciel ConBee 0x26300500 (mais 0x262f0500 convient également).

J'ai 4x FLS-PP lp mais ceux-ci sont maintenant éteints pour les tests, car ils agissent comme des répéteurs de signal très puissants.

Avec les capteurs et les commutateurs, la taille totale du réseau est de 55.
Toutes les lumières sont toujours alimentées et n'indiquent jusqu'à présent aucune panne.

Voici quelques spécifications plus détaillées de mon réseau si cela peut être utile. J'utilise toujours 2.05.59 avec 262F0500 et une rallonge vers le ConBee. Comme mentionné ci-dessus, après la première mise à jour vers la 2.05.59 et le redémarrage de chaque appareil alimenté par le secteur et en attendant quelques heures, le réseau était impeccable pendant près d'une semaine, il semble donc prendre un certain temps avant que les problèmes commencent à apparaître. Malheureusement, le problème est réapparu et un cycle d'alimentation complet de tous les appareils alimentés par le secteur ainsi qu'un redémarrage de deCONZ ne résout plus le problème. Il semble également que le problème se déplace d'un appareil à l'autre, car parfois une lumière peut ne pas répondre pendant un certain temps, puis elle se corrige d'elle-même.

Plus tôt dans la journée, j'ai eu un problème où le Trådfri E14 ne répondait pas ainsi qu'un Hue E27. Après un cycle d'alimentation du E27, le E14 est également revenu à la vie sans même que je le touche. Il en va de même pour les GU10 qui ne répondent pas qui semblent être des lieux d'échange de temps en temps, il y a donc au moins deux GU10 qui ne répondent pas tous les jours, mais ce ne sont pas toujours les mêmes lumières, donc certains commencent à fonctionner tandis que d'autres se cassent et vice versa.

Mon réseau se compose actuellement des 80 appareils suivants, y compris ConBee et les appareils alimentés sur secteur sont alimentés 24/7.

Alimentation secteur

| Quantité | Type | Micrologiciel |
| ---------- | ------ | ------------- |
| 30 | Trådfri GU10 dimmable | 1.2.214 |
| 4 | Trådfri GU10 spectre blanc | 1.2.217 |
| 1 | Trådfri E14 opale dimmable | 1.2.217 |
| 1 | Prise de contrôle Trådfri | 1.4.020 |
| 3 | Hue E27 Blanc et Couleur A19 | 1.29.0_r21169 |
| 2 | Hue E14 Ambiance blanche LTW012 | 1.29.0_r21169 |

Alimenté par pile

Quantité | Type | Micrologiciel
--------- | ------ | -----------
1 | Interrupteur marche / arrêt Trådfri | 1.4.018
10 | Multi-capteur Xiaomi Aqara (carré temp / hum / pres) | 20161129
3 | Capteur de mouvement Xiaomi Aqara (mouvement / lux) | 20170627
4 | Capteur d'eau Xiaomi Aqara | 20170721
1 | Détecteur de mouvement Hue | 6.1.0.18912
11 | Capteur de contact Xiaomi Aqara | 20161128
8 | Capteur de fumée Xiaomi / Honeywell | N / A

La semaine dernière, deconz semblait fonctionner plutôt bien, mais hier, j'avais une autre ampoule IKEA (spectre blanc) perdant la connexion avec deconz. Même l'éteindre et le rallumer n'aidait pas. J'ai dû redémarrer deconz pour qu'il fonctionne à nouveau d'une manière ou d'une autre.

J'ai un réseau avec principalement des ampoules IKEA, une prise Heiman et pas mal de capteurs Xiaomi.

Quelques spécifications de mon réseau zigbee:

Micrologiciel Conbee 262F0500 avec câble d'extension sur un NUC.
deCONZ 2.05.55 dans Docker, donc la première chose que je dois faire est de passer à 2.05.59 je suppose.

Alimenté (24/7)

| Quantité | Type | Micrologiciel |
| ------------- | ------------- | ------------- |
| 4x | Tradfri E27 blanc | 1.1.1.0-5.7.2.0 |
| 2x | Tradfri E27 blanc | 1.2.214 |
| 21x | Tradfri GU10 dimmable | 1.2.214 |
| 3x | Prise Osram Smart + | 1.04.12 |

Alimenté par pile

| Quantité | Type | Micrologiciel |
| ------------- | ------------- | ------------- |
| 3x | Gradateur Hue | 5.45.1.17846 |
| 1x | Interrupteur intelligent Aqara | 20180525 |
| 1x | Interrupteur intelligent Aqara | 20161128 |
| 1x | Interrupteur sans fil double Aqara | 20170411 |
| 1x | Télécommande TRADFRI | 1.2.214 |
| 6x | Multisensor Aqara | 20161129 |
| 10x | Capteur de contact Aqara | 20161128 |
| 5x | Détecteur de mouvement Aqara | 20170627 |
| 1x | Capteur de fuite Aqara | 20170721 |
| 1x | Capteur de vibrations Aqara | 20180130 |

Des mises à jour à ce sujet pour la version actuelle? J'utilise .60 depuis 3 jours et aucune lumière n'a encore perdu la connexion.

Malheureusement, j'avais déjà une connexion perdue avec une ampoule blanche Tradfri E27 ordinaire sur .60 et le dernier firmware.

C'est une mauvaise nouvelle ... si je comprends bien, les intervalles d'interrogation ont été modifiés en .60 pour être moins agressifs. Un sondage agressif provoquant la suspension d'une lumière me semblait parfaitement logique, dommage que cela ne semble pas être la solution à notre problème.

Hier, j'ai coupé l'alimentation de tous les appareils alimentés par secteur et mis à jour à 2.05.60 et 26320500 avant de les rallumer, juste pour jouer en toute sécurité. Les lumières ont ensuite fonctionné correctement pendant environ 24 heures, mais il y a quelques minutes, j'ai remarqué que l'un de mes GU10 avait cessé de répondre. Heureusement, il est revenu à la vie quelques minutes plus tard sans aucune interaction manuelle de ma part, alors peut-être que le réseau était simplement obstrué.

@ JBS5 Je recommanderais de mettre à jour le 4x Tradfri E27 white à 1.1.1.0-5.7.2.0 vers une version récente du firmware. Si je me souviens bien, c'est toujours la toute première version.

@jurriaan quelle version a votre ampoule blanche Tradfri E27?

C'est une mauvaise nouvelle ... si je comprends bien, les intervalles d'interrogation ont été modifiés en .60 pour être moins agressifs.

Oui, fondamentalement très similaire à la passerelle IKEA. Maintenant, la seule différence restante est l'interrogation périodique des tables voisines (qui est utilisée pour afficher les lignes du réseau maillé).

Cela peut être désactivé en cliquant sur l'icône CRE dans deCONZ et en décochant "Routeurs et coordinateur".
Ça vaudra peut-être un test

Sur Reddit, un article mentionnait que la passerelle IKEA devrait en théorie prendre en charge jusqu'à 100 appareils, mais qu'elle n'est pas très bien testée. Il serait intéressant de savoir quelle est la taille habituelle du réseau que l'équipe IKEA teste.

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

Vous pourriez probablement avoir 100 appareils connectés à votre passerelle. Ceci n'est pas testé correctement par nous, c'est pourquoi nous ne le garantissons pas. Mais la limite technique est de 100, et j'ai vu des gens qui ont 100 appareils avec aucun ou seulement des problèmes mineurs.

Les nouvelles versions de la passerelle prendront en charge le même nombre d'appareils (officiellement 50). Vous pouvez ajouter une autre passerelle à votre système si vous souhaitez le doubler.

@ JBS5 Je recommanderais de mettre à jour le 4x Tradfri E27 white à 1.1.1.0-5.7.2.0 vers une version récente du firmware. Si je me souviens bien, c'est toujours la toute première version.

Ces ampoules E27 avec l'ancien firmware n'ont pas échoué au cours des 6 derniers mois alors que d'autres l'ont fait ...

Très intéressant, que diriez-vous du E27 à la version 1.2.214?

Très intéressant, que diriez-vous du E27 à la version 1.2.214?

Ils n'ont perdu la connexion qu'une seule fois au cours des derniers mois.

Cela fait quelques semaines que le dernier GU10 a perdu la connexion, alors que j'utilise toujours deCONZ 2.05.55 et le firmware 262F0500 sur le Conbee.

J'ai aussi ce problème. Seuls les nœuds Ikea, (43, principalement des lumières). Je n'ai aucune connaissance sur zigbee, mais comme je ne l'ai pas vu mentionné: mon réseau semble plus stable avec OTAU désactivé. L'autre jour, j'ai également changé les préférences réseau en moins sécurisées. Je ne me souviens plus lequel, mais après cela, je n'ai perdu aucune lumière.

Après quelques jours sans aucun problème, plusieurs GU10 ne répondent plus.
Un autre problème peut être sans rapport, mais une lumière Osram a également perdu la connexion. Même s'il était toujours affiché dans l'interface graphique et semblait maillé, je ne pouvais plus le contrôler. A dû supprimer la lumière et la lire, elle a reçu un autre numéro de lumière mais a retrouvé son ancien nom peu de temps après l'avoir ajoutée. Aucune idée de ce qui se passe ici, mais c'est un peu plus d'entretien que je ne voudrais voir pour ma configuration.

@ peer69 avez-vous également essayé de
Vous êtes sur 2.05.60? Pouvez-vous également fournir plus de détails sur votre réseau, combien de lumières et d'appareils alimentés sur secteur?

@manup J'ai recyclé la lumière. Plusieurs fois. Il était contrôlable pendant environ 10 secondes après un cycle d'alimentation, mais il est ensuite redevenu sans réponse (les voyants rouges clignotent dans l'interface graphique).
En attendant, ce problème est revenu même après la réinitialisation d'usine et a également affecté un autre voyant OSRAM. Pour l'instant, je me suis débarrassé des deux seules lumières OSRAM de mon réseau et je les ai remplacées par des ampoules de teinte. Je peux proposer des tests avec les lampes ORSAM mais il me faudrait un peu de temps pour cela.

J'utilise 2.05.60. Actuellement, 57 nœuds sont connectés au réseau, dont 27 appareils sont alimentés par le secteur. J'utilise 13 IKEA GU10, 1 panneau IKEA FLOALT, 2 IKEA E14, 3 prises OSRAM Smart +, 3 ampoules de teinte E14, 5 ampoules de teinte E27, 1 bande lumineuse de teinte.

J'ai également dû mettre sous tension certains IKEA GU10 ces derniers jours, ce qui est devenu insensé. Après le cycle de puissance, tout est revenu à la normale et je ne vois pas de modèle. J'ai des lampes avec plusieurs GU10 et pas plus d'un GU10 qui ne répond plus en même temps bien qu'elles soient toujours contrôlées en groupe.

Pour le moment, je suis de retour à la case départ. Maintenant, j'ai régulièrement 2-3 lumières qui ne répondent pas, mais cela saute entre différentes lumières, donc parfois elles fonctionnent et parfois elles ne dépendent pas des autres lumières qui sont en ligne. Le problème semble être en cascade parce que lorsque j'éteins physiquement certaines lumières en les coupant le courant, cela déplace le problème vers d'autres lumières.

J'ai également perdu quelques capteurs de température Xiaomi ainsi que des capteurs de porte et un interrupteur marche / arrêt IKEA, mais ils ne réapparaissent pas, ils doivent donc probablement être réappariés pour pouvoir recommencer à fonctionner.

Les choses ont bien fonctionné immédiatement après un cycle d'alimentation total, comme je l'ai noté plus tôt, mais quelques jours plus tard, les lumières ont recommencé à ne plus répondre et c'est comme ça depuis quelques semaines maintenant. À l'époque où cela s'est produit la première fois qu'un invité a accidentellement débranché l'E14 pendant plusieurs heures, je ne suis donc pas sûr que ce soit complètement sans rapport ou si des perturbations inattendues du maillage en zigbee ont rendu le routage devenu fou. Étant donné que je ne suis apparemment pas le seul à avoir ces problèmes, je pense que ce n'est peut-être qu'une coïncidence.

J'aime vraiment le concept d'avoir tous mes appareils zigbee dans un seul maillage, mais je suis presque au point où je démarre les anciennes passerelles Hue et Xiaomi et mets le ConBee dans un tiroir, ce que je ne veux vraiment pas faire pour plusieurs autres raisons. Quelqu'un a-t-il des conseils pour un dépannage supplémentaire qui pourraient m'aider à identifier exactement ce qui se passe et comment le résoudre?

L'un de mes spots IKEA GU10 ne répond plus.

Dans le sniffer, je vois qu'il est encore quelque peu «vivant» et envoie des messages d'état de lien NWK, mais il pense évidemment qu'il est seul dans le réseau (nombre d'état de lien: 0).

Il ne répond pas aux commandes de monodiffusion mais envoie périodiquement le rapport d'attribut ZCL du modelid.

Reniflage depuis ~ 2 heures, je ne sais pas quand il ne répond plus et s'il est lié, mais le numéro de séquence ZCL du rapport est faible:

Je vais faire quelques tests supplémentaires et je ne le cyclerai pas pendant un moment.

Ma prise de courant Tradri a également agi vraiment bizarrement aujourd'hui et a fonctionné dans des cercles de redémarrage, jamais celle-ci auparavant.

Je viens de noter qu'un deuxième IKEA GU10 est aussi une marche à led, mêmes symptômes que l'autre.

Les deux appareils ne répondent pas à la monodiffusion, à la diffusion de groupe ou à la demande d'adresse nwk ZCP (en appuyant sur 0).
Ils envoient des commandes NWK Link Status vides.

Le deuxième GU10 a également envoyé des demandes d'image suivante de requête ZCL OTA.

Il semble que la réponse ne se concrétise pas.

Seulement une supposition sauvage, mais je suppose que les lumières dans les tampons sont bloquées et c'est pourquoi rien n'est reçu et traité. Les tampons externes fonctionnent toujours, le micrologiciel est donc capable d'envoyer des rapports et des requêtes ota.

Ce serait bien s'ils implémentaient quelque chose comme une simple vérification de l'état de sorte que le micrologiciel puisse redémarrer après un certain temps, si la couche mac fonctionne (les commandes sont reçues) mais que les couches nwk et aps restent silencieuses.

J'ai également ce problème, même après la mise à niveau vers 2.05.59. Aujourd'hui, l'une de mes trois lampes d'extérieur a "disparu".
Ses ampoules Tradfri toutes les trois.

hors sujet. Comment trouvez-vous votre lumière dans tout ça? Lol. J'ai une configuration similaire et j'étais comme ... pas le temps pour ça

par similaire je veux dire + - 50 appareils

+ - 50, c'est assez bien. L'un de nos réseaux de test a +180 appareils avec deCONZ sur un Raspberry Pi 1, c'est amusant :)

Nous prévoyons d'ajouter un meilleur filtre / tri à deCONZ pour simplifier la recherche d'appareils, actuellement c'est vraiment compliqué à un certain nombre d'appareils.

Les lumières sont toujours bloquées.

Une observation intéressante: j'ai éteint le parent d'un capteur de mouvement Philips Hue (un Hue Lux) afin qu'il ait besoin de rechercher un nouveau parent. Le capteur tente maintenant de rejoindre l'une des lumières IKEA GU10 bloquées.

La lumière répond avec une commande Quitter (avec Rejoin). Il a donc traité la demande de réintégration!

Malheureusement, le capteur de mouvement Hue est têtu et essaie de rejoindre pour toujours la lumière bloquée GU10, à la recherche d'un meilleur parent.

Cependant, la partie intéressante ici est que la lumière IKEA bloquée répond à la demande de retour, peut-être qu'elle traite également les demandes de congé NWK, ce qui pourrait être une base de contournement pour remettre la lumière en état de fonctionnement.

Correction, le capteur de mouvement Hue n'est pas trop têtu; après quelques minutes, le capteur a sélectionné un autre parent qui travaille (bon).

Cependant, la partie intéressante ici est que la lumière IKEA bloquée répond à la demande de retour, peut-être qu'elle traite également les demandes de congé NWK, ce qui pourrait être une base de contournement pour remettre la lumière en état de fonctionnement.

J'ai testé cela, mais malheureusement cela ne fonctionne pas. Tant que les lumières sont bloquées, elles ne traiteront pas le congé NWK avec la demande de retour.

Actuellement, je ne peux que conclure qu'IKEA doit résoudre soit le problème racine de la lumière bloquée, soit implémenter une sorte de chien de garde + vérification de l'état pour les couches NWK / APS du micrologiciel.

On ne sait toujours pas ce qui cause exactement la lumière dans cet état - tempête de diffusion, certaines commandes, problèmes de routage ...?

Je transmettrai mes conclusions et mes journaux de renifleurs à IKEA, j'espère qu'ils pourront les utiliser pour localiser le problème.

Alors @manup , quelle est la meilleure pratique pour rejoindre une lumière IKEA bloquée?

Pour moi, un cycle d'alimentation de la lumière fonctionne clairement mieux

@manup Je suppose que si vous ne savez pas comment améliorer le patient, vous devriez essayer de l'aggraver. Alors, bombardez une lumière avec des causes potentielles de blocage et voyez ce qui se passe.
De plus, ces lumières ne sont-elles pas basées sur la pile Ember? Peut-être qu'il existe des équipes de support ou des forums qui pourraient faire la lumière (jeu de mots).

Wrt à IKEA, répondent-ils aux demandes de soutien comme celles-ci? Ou devrions-nous faire équipe pour attirer l'attention?

Pour moi, un cycle d'alimentation de la lumière fonctionne clairement mieux

Pas tellement pour moi ...
Un redémarrage de Conbee est la seule chose qui le corrige temporairement.
Et puis le même, ou plus souvent, une autre lampe IKEA se coince au bout d'un moment ...
Toujours juste une lumière! C'est tellement étrange ... et irritant ...: /

@manup Génial! Merci d'avoir examiné cela!

J'ai également transmis ce fil à l'équipe IKEA Tradfri via Reddit. Je viens de recevoir une réponse de leur part disant qu'ils ont transmis l'information. Espérons qu'ils pourront l'utiliser pour améliorer leur firmware ou trouver une solution à ce problème :)

On dirait qu'un nouveau micrologiciel pour la passerelle tradfri est à venir dans les prochains jours, qui cible particulièrement le support HomeKit. Il pourrait également y avoir un nouveau firmware pour les ampoules.

@ peer69 Ceci est la dernière version du micrologiciel:

[
  {
    "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"
  }
]

Seules les mises à jour sont:

• 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-ampoule-ws-2.0.022.ota.ota.signed
• 159699-2.1-TRADFRI-remote-control-1.2.223.ota.ota.signed

Donc principalement concentré sur les points de vente / passerelle.

Aujourd'hui, l'une de mes ampoules de teinte a montré exactement le même problème. Il a fallu le cycler pour qu'il redevienne réactif.

Des nouvelles pour qui met à jour deCONZ et le firmware du Conbee?

Jusqu'à présent, 1 ou 2 GU10 seront hors ligne dans 2 à 4 semaines. Un peu sporadiquement, mais le cyclisme électrique est ennuyeux car je n'ai pas de commutateur électrique à certains endroits.

Je viens de mettre à jour le firmware à 0x26330500 alors voyons voir.

Malheureusement, aujourd'hui, l'un de mes GU10 n'est pas disponible.
Utilisation de deCONZ 2.05.64 avec le firmware 26330500 sur le Conbee.

Je pense qu'il a été conclu qu'il s'agissait d'un problème d'ampoule FW, car nous voyons exactement le même problème sur un pont Philips HUE. J'ai remarqué dans l'application Trådfri, section Notes de version, une mention d'une ampoule CT v2. Peut-être est-ce même lié à l'ampoule HW?

Je n'ai eu aucun problème avec 2.05.65 jusqu'à présent.

Idem, je n'ai pas rencontré ce problème depuis des semaines

J'ai eu la même chose avec la dernière version de deconz jusqu'à maintenant .. j'ai commuté des lampes il y a quelques jours. Je devais juste l'éteindre et rallumer manuellement l'une de ces lampes pour qu'elle redevienne réactive.

Quelques GU10 et une ampoule E27 ont été déconnectés il y a quelques jours. Seul le cycle d'alimentation les ramène en ligne.

Peut-être pertinent: cela s'est produit pendant mes vacances quand il n'y a pas de lumière allumée pendant un jour ou dix.

Micrologiciel 26330500 avec deCONZ 2.05.64

Que diriez-vous de ce problème pour ceux qui ont dit n'avoir eu aucun problème pendant quelques semaines il y a quelques semaines?

J'ai toujours ce problème. Parfois, aucun d'entre eux ne se déconnecte, et à l'improviste, un GU10 est hors ligne, et quelques jours plus tard, un autre.

Pour autant que je sache, il n'y a toujours pas de nouveau firmware disponible pour le Tradfri GU10.

J'ai toujours ce problème aussi. Comme, pour moi, les commandes de groupe fonctionnent toujours la plupart du temps même si je ne peux pas contrôler la lumière comme un seul appareil, je les utilise dans mes scripts d'interrupteurs muraux comme solution de contournement.

Les commandes de groupe fonctionnent pour moi aussi, mais seulement quelques fois. Après cela, la lumière reste allumée ou éteinte et ne répond plus. Pas même avec un variateur de teinte lié.

Pareil pour moi. J'ai l'impression que le problème est retardé, plus que résolu.
J'ai également travaillé sur le problème de l'utilisation des commandes de groupe.

Je remarque d'ailleurs que certaines lumières semblent beaucoup plus sensibles à ce problème. Le reconnaissez-vous?

@djwlindenaar Difficile à dire, mais je suppose que la moitié des 25+ GU10 que je possède n'ont jamais eu ce problème et je suis sûr que quelques-uns ont eu le problème plusieurs fois.

@ peer69 @djwlindenaar La commande group continue-t-elle de fonctionner? Aujourd'hui, un GU10 s'est déconnecté et n'a même pas répondu à une commande de groupe la première fois (commande de groupe de deCONZ et un variateur de teinte lié).

La commande de groupe continue généralement de fonctionner, mais je me souviens d'une occasion où j'ai dû allumer une lumière. Je me souviens aussi d'une fois où il n'a pas répondu pendant un certain temps et sans aucune action a recommencé à répondre plus tard.

Toutes les fois, tôt ou tard, une commande de groupe a également échoué et a dû faire fonctionner la lumière.

Que voulez-vous dire par un certain temps? Quelques heures ou quelques jours?

Pas sûr, probablement des heures, peut-être un jour. Je l'ai juste oublié pendant un certain temps, mais j'ai remarqué qu'il reviendrait la prochaine fois que j'utilisais la lumière.
C'était lié à une règle déclenchée par un mouvement, donc ...

Attendu environ 2 jours lorsqu'un GU10 s'est déconnecté plus tôt cette semaine, mais il n'est pas revenu. Un cycle d'alimentation était nécessaire, le GU10 n'était pas du tout chaud.

Maintenant, j'ai une lumière GU10 qui s'est déconnectée, mais ne reviens pas en ligne après un cycle d'alimentation. Appuyer également sur 0 dans VNC ne résout pas ce problème.

De plus, une commande de groupe ou un commutateur Hue DImmer lié ne peut plus allumer / éteindre la lumière.

À partir de la nuit dernière, j'ai dans le couloir 4 lumières ikea qui s'éteignent après x fois par une minuterie (Home Assistant) maintenant 1 des 4 lumières reste allumée et ne peut pas être éteinte par Home Assistant / Deconz. Il est hors ligne selon Deconz et n'est pas revenu depuis 7 heures. J'essaierai de faire du powercycle et voir si cela fait l'affaire

Lumière non fonctionnelle: ampoule TRÅDFRI E27 opale 1000lm avec version 1.2.214
Feux fonctionnant: ampoule TRÅDFRI E27 opale 1000lm avec version 1.2.214
Micrologiciel: 26330500
Déconz: V2_05_69

Je crois qu'il y a un problème matériel avec les ampoules à spectre blanc Ikea Trafri GU10. Également dans ma configuration (passerelle Ikea connectée via une API locale à Home Assistant), au moins la moitié de mes 17 ampoules se déconnecte tous les deux jours. La seule solution est de redémarrer les ampoules.

C'est peut-être la raison pour laquelle Ikea a lancé une nouvelle version matérielle qui exécute une version différente du firmware (2. * au lieu de 1. *).

Pour autant que je sache, il n'y a pas de nouvelle mise à jour du firmware pour l'ancienne version, cela pourrait être le signe de quelque chose lié au matériel.

Je ne sais pas quelle est la garantie, mais je prévois de demander un remplacement avec la nouvelle version.

Je crois qu'il y a un problème matériel avec les ampoules à spectre blanc Ikea Trafri GU10. Également dans ma configuration (passerelle Ikea connectée via une API locale à Home Assistant), au moins la moitié de mes 17 ampoules se déconnecte tous les deux jours. La seule solution est de redémarrer les ampoules.

C'est peut-être la raison pour laquelle Ikea a lancé une nouvelle version matérielle qui exécute une version différente du firmware (2. * au lieu de 1. *).

Pour autant que je sache, il n'y a pas de nouvelle mise à jour du firmware pour l'ancienne version, cela pourrait être le signe de quelque chose lié au matériel.

Je ne sais pas quelle est la garantie, mais je prévois de demander un remplacement avec la nouvelle version.

Je ne sais pas s'il est lié à un seul type, car j'utilise le GU10 blanc chaud, pas le spectre blanc.

J'ai eu le même problème avec deux IKEA GU 10 WW aujourd'hui. Le cycle de puissance n'a pas aidé. Cela a aidé à powercycle et à redémarrer deconz. Peut-être un problème de table voisin? Les deux lumières sont dans un groupe de deux et toujours contrôlées en tant que groupe.

Quelle coïncidence que cela se produise à plusieurs installations ces jours-ci ... Ou quelque chose d'autre se passe-t-il?

@ peer69

Quelle version du firmware deCONZ et conbee utilisez-vous?

J'utilise:
deCONZ V2_05_66
Micrologiciel 26330500

Même firmware ici. deCONZ Version 2.05.69.

Et un autre Tradfri GU10 blanc chaud perd sa connexion.

Il existe des fichiers de firmware plus récents dans la branche de test, mais je ne sais pas si ceux-ci résolvent les problèmes ou causent de nouveaux problèmes, peut-être même des dommages.

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 Ce sont pour les lumières GU10 à spectre blanc et, je suppose, pour la nouvelle version? https://www.ikea.com/nl/nl/p/tradfri-led-lamp-gu10-400-lumen-draadloos-dimbaar-warm-wit-60420041/

Peut-être que 10046695-1.1-TRADFRI-light-unified-w-2.1.022.ota.ota.signed peut être utilisé pour eux. Je vais le tester sur l'une de mes lumières à intensité variable IKEA E27, j'espère que le pire des cas est un crash mais pas de brûlure :)

J'ai essayé d'attribuer le fichier manuellement mais l'ampoule ne voit pas la mise à jour (ne démarre pas).

Juste un «moi aussi» à ce sujet. Toute ma maison est Tradfri et après avoir redémarré mon serveur aujourd'hui, j'ai perdu tout le réseau pour la troisième fois en autant de jours. Le cyclisme électrique n'a pas fait de différence. Je n'ai que Tradfri chez moi, donc je n'ai rien d'autre à comparer. J'ai un mélange de blanc e27, de couleur e27 et de GU10. La seule résolution que j'ai trouvée est de réinitialiser les ampoules et de recommencer à zéro - malheureusement, ce n'est pas durable.

Micrologiciel Conbee: 264A0700
Micrologiciel léger: 1.2.214

Heureux de vous aider pour tout diagnostic, mais je dois remettre la plupart de ma maison sur la passerelle Tradfri afin que ma famille puisse allumer et éteindre les lumières. Je vais laisser quelques lampes disponibles.

Je viens de réaliser un ajout peut-être intéressant à ce numéro.

Plusieurs salles sont équipées de plusieurs spots Tradfri GU10 et la plupart des chambres d'un variateur Hue, avec une liaison directe aux GU10 dans la pièce créée en les ajoutant au groupe Hue Dimmer Switch dans l'application Phoscon.

• Seuls les GU10 avec une liaison directe avec un variateur Hue se déconnectent de temps en temps et ont besoin d'un cycle d'alimentation pour revenir en ligne.
• Les GU10 sans liaison directe avec un variateur Hue ne se déconnectent pas.

Cela ne semble pas être le cas pour moi. Jusqu'à présent, seules les ampoules Hue semblent assez résistantes. Toutes sortes d'appareils IKEA (GU10, E14, panneau FLOALT) et Osram (ampoules, bandes lumineuses et poteaux de jardin) que je possède ont échoué. Surtout les appareils Osram échouent complètement, le cycle d'alimentation ne fait rien. Ils doivent être enlevés et réparés, ce qui est pénible pour ces appareils.

J'ai passé quelques jours à penser à remplacer tous mes appareils zigbee par des appareils pour ma trop chère installation KNX après l'échec de plusieurs appareils et la migration vers une clé Conbee II a également échoué probablement à cause d'un zll-db quelque peu corrompu. J'ai ensuite adopté une approche radicale pour tout configurer à partir de zéro. J'ai réinitialisé la passerelle et réparé tous les appareils. En ce qui concerne les appareils IKEA, c'était bien plus facile qu'auparavant. Dans le passé, je devais les rapprocher de la passerelle, les réinitialiser plusieurs fois, utiliser touchlink pour les faire répondre - rien de tout cela cette fois. Je viens de réinitialiser les ampoules et elles se sont associées sans aucun problème. Pourtant, faire cela pour 70 appareils était une douleur et certains capteurs xiaomi l'ont rendu un peu plus difficile que les trucs ikea. Mais cela me fait déjà penser que je pourrais avoir un réseau plus stable maintenant. Pourtant, rien n'a échoué mais je vous dirai si c'est le cas.

Cela faisait un moment que je n'avais pas mis à jour mon raspbee, mon ancienne version avait des problèmes de lecture de la température des lumières, j'ai donc décidé de mettre à jour le dernier firmware et le dernier deCONZ. Vous n'avez que 2 lumières (OSRAM 73674). 1 lumière (probablement aléatoire) perd la connexion après quelques minutes avec le dernier deCONZ et je dois éteindre et rallumer manuellement. La seule version que j'ai pu trouver capable de lire les températures et de ne pas perdre de lumière était deconz-2.04.40-qt5.deb qui est très ancienne, mais fonctionne pour mon utilisation de base.

Cela se produit beaucoup plus ces derniers temps pour moi aussi avec IKEA GU10 couleur unique. Une sorte de douleur dans le cul. Cependant les nœuds ne deviennent pas rouges pour moi, seulement grisés. Ils réagiront aux pressions sur les boutons à distance, mais pas via Phoscon ou HA.

DeCONZ met-il toujours à jour l'état de l'éclairage lorsque vous les contrôlez à partir de la télécommande?

Cela se produit généralement lorsque deCONZ a perdu la route vers la lampe. La lampe est toujours sur le réseau, peut atteindre la passerelle et reçoit des émissions. Cependant, la passerelle ne peut pas atteindre la lumière en monodiffusion. Pour contourner ce problème, vous pouvez utiliser les commandes /groups au lieu de /lights , donc deCONZ envoie des diffusions à la place.

J'ai toujours le même problème occasionnellement (~ une fois par semaine) avec mon Xiaomi Curtain Controller (qui est un routeur ZigBee). L '_Annonce de l'appareil_ après la mise hors tension de l'appareil fait réapprendre à deCONZ l'itinéraire.

Ces problèmes de routage ont été introduits avec la prise en charge de la découverte de routage utilisée par les lumières Trådfri, donc 2.04.40 sonne à peu près correct.

@ebaauw Quand une lumière est indisponible, les commandes de groupe fonctionnent pour moi mais seulement pour un temps limité. Après cela, la lumière reste allumée ou éteinte et ne répond plus à une commande de groupe. Utilisation d'un variateur Hue lié (liaison créée en ajoutant les lumières au groupe créé par défaut lorsqu'un variateur Hue est couplé dans l'application Phoscon).

DeCONZ met-il toujours à jour l'état de l'éclairage lorsque vous les contrôlez à partir de la télécommande?

Cela se produit généralement lorsque deCONZ a perdu la route vers la lampe. La lampe est toujours sur le réseau, peut atteindre la passerelle et reçoit des émissions. Cependant, la passerelle ne peut pas atteindre la lumière en monodiffusion. Pour contourner ce problème, vous pouvez utiliser les commandes /groups au lieu de /lights , donc deCONZ envoie des diffusions à la place.

Je vérifierai ces suggestions la prochaine fois. Mais oui, ils reviennent généralement, j'ai coupé le courant pendant quelques minutes. Btw j'utilise la télécommande IKEA "hockey puck".

J'ai toujours le même problème occasionnellement (~ une fois par semaine) avec mon Xiaomi Curtain Controller (qui est un routeur ZigBee). L '_Annonce de l'appareil_ après la mise hors tension de l'appareil fait réapprendre à deCONZ l'itinéraire.

Ces problèmes de routage ont été introduits avec la prise en charge de la découverte de routage utilisée par les lumières Trådfri, donc 2.04.40 sonne à peu près correct.

Hmm, je ne sais pas, ça a été si mauvais pour moi pendant si longtemps. Je l'ai mis à jour en permanence.

Hmm, je ne sais pas, ça a été si mauvais pour moi pendant si longtemps.

C'est un problème intermittent. Je n'ai pas pu le reproduire à volonté, voir # 849. En fait, toutes mes règles pour contrôler les lumières sont basées sur des actions /groups , donc je n'avais jamais remarqué le problème avant, jusqu'à ce que j'aie le contrôleur de rideau.

Lorsqu'une lumière devient indisponible, les commandes de groupe fonctionnent pour moi mais seulement pour un temps limité. Après cela, la lumière reste allumée ou éteinte et ne répond plus à une commande de groupe.

Je dirais que la lumière décide de quitter le réseau, lorsqu'elle ne reçoit pas les ACK de la passerelle pour ses rapports d'attributs pendant une période prolongée.

Je dirais que la lumière décide de quitter le réseau, lorsqu'elle ne reçoit pas les ACK de la passerelle pour ses rapports d'attributs pendant une période prolongée.

Pour moi, cela se produit aussi avec des lumières qui étaient allumées ou seulement quelques minutes / heures auparavant.

Comme indiqué dans quelques réponses ci-dessus, la plupart de mes lampes GU10 sont liées à un variateur Hue (3-8 dans une pièce avec un propre variateur Hue). Quelques-uns ne le sont pas, et ceux-ci sont en ligne depuis des mois. Jamais l'un d'entre eux n'a été indisponible. Coïncidence, ou pas .. Que pensez-vous de ce @ebaauw?

la plupart de mes lumières GU10 sont liées à un variateur Hue

Cela semble peu probable. Avez-vous créé une liaison dans le panneau _Bind Dropbox_ de l'interface graphique deCONZ du variateur à la lumière?

Notez que «liaison» dans les termes ZigBee signifie: créer une entrée dans la table de liaison de l'appareil à quelle adresse ZigBee envoyer des commandes à partir du cluster lié. Je pense que les clusters (client!) _OnOff_ et _Level Control_ de votre variateur sont liés à un groupe (par le plugin deCONZ REST API). Ce groupe est répertorié dans la ressource ZHASwitch sous config.group . Ensuite, la lumière a été ajoutée à ce groupe. Les groupes ZigBee ressemblent davantage à des adresses multicast, il est donc probablement plus correct de dire que la lumière s'est abonnée aux messages de ce groupe.

En théorie, je suppose, le micrologiciel léger pourrait avoir un bogue, le faisant se bloquer lors du traitement des commandes reçues via un groupe. Je ne pense pas que ce soit probable, cependant. Je regarderais à quelle distance (combien de sauts sur le réseau ZigBee) les lumières sont au RaspBee / ConBee et / ou si toutes les lumières ont la même révision matérielle et micrologicielle. IKEA semble déployer de nouvelles versions ZigBee 3.0 (ZHA) de tous ses appareils.

la plupart de mes lumières GU10 sont liées à un variateur Hue

Cela semble peu probable. Avez-vous créé une liaison dans le panneau _Bind Dropbox_ de l'interface graphique deCONZ du variateur à la lumière?

Notez que «liaison» dans les termes ZigBee signifie: créer une entrée dans la table de liaison de l'appareil à quelle adresse ZigBee envoyer des commandes à partir du cluster lié. Je pense que les clusters (client!) _OnOff_ et _Level Control_ de votre variateur sont liés à un groupe (par le plugin deCONZ REST API). Ce groupe est répertorié dans la ressource ZHASwitch sous config.group . Ensuite, la lumière a été ajoutée à ce groupe. Les groupes ZigBee ressemblent davantage à des adresses multicast, il est donc probablement plus correct de dire que la lumière s'est abonnée aux messages de ce groupe.

Non, je n'ai pas créé de liaison dans le panneau de _Bind Dropbox_ de l'interface graphique deCONZ.

Voulez-vous dire que l'ajout de lumières à ces groupes dans l'application Phoscon ne crée pas de liaison entre la télécommande et les lumières? Je l'ai supposé, car la commutation des lumières ajoutées avec le variateur Hue correspondant est également possible lorsque mon conteneur docker deCONZ ou tout le NUC est hors ligne.

Ok, j'ai une ampoule qui ne répond pas maintenant. Il était grisé dans bth deCONZ et Phoscon.

Il a réagi aux commandes à distance et aussi au moment où j'ai déplacé le curseur en mode "groupe" dans Phoscon,

DeCONZ met-il toujours à jour l'état de l'éclairage lorsque vous les contrôlez à partir de la télécommande?

Pas au début car il était grisé.

J'ai ensuite essayé avec "réinitialiser le nœud sélectionné" dans deCONZ, puis il n'était plus grisé pendant quelques minutes même s'il n'avait plus le bouton radio du cluster dans deCONZ.

Toujours seulement répondu aux commandes à distance et de groupe, mais maintenant l'état de l'éclairage a été mis à jour.

Au bout d'un moment, il est de nouveau grisé dans Phoscon.

J'ai ensuite essayé de couper l'alimentation pendant quelques minutes. N'a pas aidé.

Une situation intéressante s'est produite ce soir:

L'une des lumières GU10 blanc chaud de Tradfri est à nouveau hors ligne depuis quelques heures. L'interrupteur Hue Dimmer qui est lié à 8 GU10, y compris celui qui est maintenant hors ligne, active / désactive le GU10 hors ligne, selon deconz. Assez étrange, seulement celui-là.
Les autres GU10 ne répondent pas au variateur Hue lié.

Le basculement du groupe avec l'API reste allumera / éteindra toutes les lumières, y compris le GU10 hors ligne.

Lorsqu'un GU10 était auparavant hors ligne, le variateur Hue lié allume / éteint toutes les lumières du groupe, y compris le GU10 hors ligne, selon déconz, (tôt ou tard, selon deconz, le GU10 hors ligne cesse également d'écouter les commandes de groupe Soit).

Cela pourrait-il être utile?

\ Edit: Le 'Nom' de ce GU10 hors ligne dans deCONZ via VNC est vide.

Lorsque vous le remplissez à nouveau, il n'est pas défini (je ne l'ai jamais fait ici, normalement dans l'application Phoscon):

Toujours jaune soit:

Appuyer sur «0» ou «Réinitialiser le nœud sélectionné» ne remet pas le GU10 en ligne.

Edit 2 : Environ 24 heures après la mise hors ligne du GU10, le GU10 ne répond plus au gradateur de teinte lié comme décrit précédemment. Aucune des lumières GU10 du groupe ne répond maintenant. Le nœud dans l'interface graphique deCONZ est toujours jaune mais le nom est en gris.
Après la mise sous tension de la lumière GU10 hors ligne, toutes les 8 lumières du groupe, y compris celle qui était hors ligne, répondent à nouveau au gradateur de teinte lié.

@manup Ce comportement / situation est assez différent qu'avant, peut-être que cela peut aider à trouver la cause?

Je viens de réaliser un ajout peut-être intéressant à ce numéro.

Plusieurs salles sont équipées de plusieurs spots Tradfri GU10 et la plupart des chambres d'un variateur Hue, avec une liaison directe aux GU10 dans la pièce créée en les ajoutant au groupe Hue Dimmer Switch dans l'application Phoscon.

• Seuls les GU10 avec une liaison directe avec un variateur Hue se déconnectent de temps en temps et ont besoin d'un cycle d'alimentation pour revenir en ligne.
• Les GU10 sans liaison directe avec un variateur Hue ne se déconnectent pas.

Malheureusement, l'un de mes Tradfri GU10 warmwhite sans un variateur Hue lié est hors ligne depuis hier.

Je me demande toujours pourquoi quelques spots GU10 (même blanc chaud) sont _never_ hors ligne.
\ Edit : Aussi un GU10 qui était en ligne depuis des mois, est hors ligne depuis hier.

J'ai acheté un Tradfri Hub le week-end dernier et y a associé tous les spots GU10 d'une pièce. Voyons ce qui se passera dans les semaines à venir.

Les lumières aléatoires de mon système ont commencé à ne plus répondre après que j'ai ajouté quatre interrupteurs de prise marche / arrêt IKEA à mon système (pour les lumières des fenêtres de Noël) ... Les prises sont réparties dans toute ma maison. Au moins une de mes lumières dans mon système doit être mise hors tension par jour.

Puis-je fournir n'importe quel type de journaux ou d'informations pour faciliter le dépannage?

@tubalainen Que voulez-vous dire par non-responsive? Sont-ils réactifs par eux-mêmes ou ont-ils besoin d'un cycle électrique?

@tubalainen Que voulez-vous dire par non-responsive? Sont-ils réactifs par eux-mêmes ou ont-ils besoin d'un cycle électrique?

Ils sont répertoriés comme "en ligne" (non grisés) et font partie du maillage selon mon image, mais lorsqu'ils sont basculés dans Home Assistant (ou via phoscon), rien ne se passe. Pour les faire fonctionner à nouveau, j'ai besoin de faire du vélo électrique.

Y a-t-il des progrès à ce sujet? Cela devient un peu ridicule avec mes lumières GU10 qui deviennent grises :(

Je pense avoir vu quelqu'un mentionner le contrôleur de rideau ou l'interrupteur marche / arrêt. En fait, il m'est arrivé que les problèmes se soient aggravés au moment où j'ai obtenu les stores FYRTUR. C'était aussi le premier bouton ikea que j'ai ajouté au réseau ... je donno ...

Je n'ai pas d'interrupteur mural marche / arrêt Tradfri ou de rideaux IKEA ici et j'ai le problème.

J'ai eu ce problème pendant l'été. Mes GU10 abandonnaient tout le temps. J'ai mis à jour tous mes GU10 avec le dernier logiciel de «test» et je fonctionne sans problème depuis près de deux mois.

Le week-end dernier, j'ai ajouté quelques nouvelles ampoules E27 et maintenant plusieurs de mes GU10 abandonnent à nouveau tout le temps.

J'ai eu ce problème pendant l'été. Mes GU10 abandonnaient tout le temps. J'ai mis à jour tous mes GU10 avec le dernier logiciel de «test» et je fonctionne sans problème depuis près de deux mois.

Le week-end dernier, j'ai ajouté quelques nouvelles ampoules E27 et maintenant plusieurs de mes GU10 abandonnent à nouveau tout le temps.

Quelles ampoules GU10 possédez-vous et quel firmware avez-vous installé?

J'ai acheté un Tradfri Hub le week-end dernier et y a associé tous les spots GU10 d'une pièce. Voyons ce qui se passera dans les semaines à venir.

Quand j'ai utilisé la passerelle Tradfri, j'avais des ampoules qui ne répondaient presque pas tous les jours (spectre blanc Tradfri GU10, première génération). Je suis passé au pont Philips Hue et le problème semblait disparu, mais après 2 semaines, une ampoule ne répondait plus (comme d'habitude, un cycle d'alimentation a résolu le problème).

Je ne sais pas pourquoi et comment le pont Hue fonctionne mieux avec les ampoules Tradfri, mais il me semble que le vrai problème est avec les ampoules.

Je ne possède pas un seul GU10 et j'ai toujours le problème.

Veuillez me dire comment je peux vous aider avec les journaux, etc. pour essayer de résoudre ce problème.
Il semble léger (je suppose ici) que certains nœuds «s'endorment» et ne se réveillent pas du premier coup pour les réveiller?

Est-ce uniquement un problème lorsqu'il y a plusieurs sauts de nœuds dans le maillage? Pour moi, c'est assez conséquent quand il y a plus d'un saut au conbee. Encore une fois, juste un sentiment. Pas confirmé.

J'ai 8 GU-10 âgés d'environ 18 mois. L'un d'eux est devenu gris une fois pendant cette période. Ils sont tous dans la même pièce que le bâton conbee. J'ai des ampoules 980lm de 3 ans. Le plus éloigné du gw sautant via un gu 10 devient gris peut-être une fois tous les quinze jours.
@tubalainen pourrait être sur quelque chose.

À côté de celui qui devient gris, j'ai un Osram qui n'est jamais allé de loin.

Oui, @tubalainen pourrait être sur un indice. En fait, j'ai mis mes GU10 gris dans une douille de lampe sur un cordon que j'utilise pour ajouter de nouvelles lumières et quand ils sont là, ils reviennent souvent à la vie. Mais ensuite, quand je les remets à leur place, ils sont de nouveau dehors. Ce n'est pas à 100% cohérent qu'ils reviennent, mais cela pourrait quand même être complice.

Voici un autre indice potentiel. Je n'ai jamais eu de lampes grises (depuis plus d'un an avec 8 lampes IKEA), mais j'ai ensuite mis à jour le plugin Home Assistant deconz de 3,8 à 3,9 et en deux jours, j'ai eu deux GU10 gris, je restauré une sauvegarde de la version 3.8 du plugin et il n'y a eu aucun problème depuis. La chose étrange est que le plugin 3.8 et 3.9 utilise la même version deconz (si le journal des modifications est complet). Pourtant, même à Phoscon, les lampes étaient inaccessibles. Tout cela est plutôt étrange, mais je suppose que la version 3.9 du plugin fait une sorte de demande de déconzation qui rend les lampes IKEA instables.

Je n'utilise pas HA et je souffre toujours du problème. J'ai acheté du NE GU10 et je remplace maintenant chaque lampe qui devient grise plus d'une fois. Aucune lampe que j'ai remplacée n'est redevenue grise. Cela peut être un problème matériel, peut-être pas, mais il semble que nous n'aurons pas de solution de sitôt.

J'ai des problèmes similaires. Certains des nœuds légers ne répondent pas aux commandes et deviennent gris. La chose étrange est que si j'envoie des commandes de groupe, le même nœud de lumière répond parfaitement à chaque fois.

J'ai des problèmes similaires. Certains des nœuds légers ne répondent pas aux commandes et deviennent gris. La chose étrange est que si j'envoie des commandes de groupe, le même nœud de lumière répond parfaitement à chaque fois.

Une commande de groupe continue-t-elle de fonctionner après, disons, quelques jours / plus d'une semaine?
Dans mon cas: tôt ou tard, la lumière cesse également d'écouter les commandes du groupe.

J'ai des problèmes similaires. Certains des nœuds légers ne répondent pas aux commandes et deviennent gris. La chose étrange est que si j'envoie des commandes de groupe, le même nœud de lumière répond parfaitement à chaque fois.

Une commande de groupe continue-t-elle de fonctionner après, disons, quelques jours / plus d'une semaine?
Dans mon cas: tôt ou tard, la lumière cesse également d'écouter les commandes du groupe.

Oui, cela semble également fonctionner correctement avec le temps. Mais j'ai une théorie de ce qui ne va pas. Lorsque les nœuds lumineux sont acheminés à travers l'ampoule TRADFRI E27 WS opal 1000lm, les problèmes surviennent. Alors hier, j'ai éteint les deux que j'avais sur mon réseau. Depuis, tout semble fonctionner parfaitement.

J'ai l'ampoule TRADFRI GU10 WS 400lm, l'ampoule TRADFRI E14 CWS opale 600lm et l'ampoule TRÅDFRI E27 CWS opale 600lm. Ils ne semblent pas causer de problèmes.

Cela pourrait être lié à l'ancien firmware Trådfri. Les éclairages plus récents sont fournis avec un firmware plus récent, mais je ne pense pas qu'IKEA ait publié un firmware mis à jour pour tous les éclairages de première génération. Je n'ai pas de spots Trådfri GU10, mais l'ampoule CWS a reçu une mise à jour du firmware. Mon ampoule à intensité variable de 1000 lm ne l'a pas fait; Je ne suis pas sûr de l'ampoule à spectre blanc.

Cela pourrait être lié à l'ancien firmware Trådfri. Les éclairages plus récents sont fournis avec un firmware plus récent, mais je ne pense pas qu'IKEA ait publié un firmware mis à jour pour tous les éclairages de première génération. Je n'ai pas de spots Trådfri GU10, mais l'ampoule CWS a reçu une mise à jour du firmware. Mon ampoule à intensité variable de 1000 lm ne l'a pas fait; Je ne suis pas sûr de l'ampoule à spectre blanc.

Mes ampoules TRADFRI GU10 WS 400lm sont sur le même firmware, 2.0.022. Ils ne semblent pas poser de problèmes (encore :))

Cela pourrait être lié à l'ancien firmware Trådfri. Les éclairages plus récents sont fournis avec un firmware plus récent, mais je ne pense pas qu'IKEA ait publié un firmware mis à jour pour tous les éclairages de première génération. Je n'ai pas de spots Trådfri GU10, mais l'ampoule CWS a reçu une mise à jour du firmware. Mon ampoule à intensité variable de 1000 lm ne l'a pas fait; Je ne suis pas sûr de l'ampoule à spectre blanc.

Je suis d'accord. La première version des ampoules Ikea (sur le firmware 1. *) avait un bogue logiciel / matériel qui n'affecte pas les deuxièmes itérations (sur 2. *).

Malheureusement, il semble qu'Ikea ​​ne supporte plus la version originale et ne fournira aucune mise à jour du firmware. Dans le même temps, il n'est pas possible de retourner les ampoules et de les échanger contre des nouvelles (j'ai essayé, au Royaume-Uni).

Cela pourrait être lié à l'ancien firmware Trådfri. Les éclairages plus récents sont fournis avec un firmware plus récent, mais je ne pense pas qu'IKEA ait publié un firmware mis à jour pour tous les éclairages de première génération. Je n'ai pas de spots Trådfri GU10, mais l'ampoule CWS a reçu une mise à jour du firmware. Mon ampoule à intensité variable de 1000 lm ne l'a pas fait; Je ne suis pas sûr de l'ampoule à spectre blanc.

Je suis d'accord. La première version des ampoules Ikea (sur le firmware 1. *) avait un bogue logiciel / matériel qui n'affecte pas les deuxièmes itérations (sur 2. *).

Malheureusement, il semble qu'Ikea ​​ne supporte plus la version originale et ne fournira aucune mise à jour du firmware. Dans le même temps, il n'est pas possible de retourner les ampoules et de les échanger contre des nouvelles (j'ai essayé, au Royaume-Uni).

J'ai des ampoules cws sur 1.3.009. Ils ne semblent pas causer de problèmes.

Mettre à jour:

Il semble que d'autres ampoules IKEA causent également des problèmes.

Voici mes ampoules IKEA. Jusqu'à présent, seule l'ampoule TRADFRI E27 WS opale 1000lm pose problème. Ils sont désormais déconnectés et les choses semblent fonctionner. Mais je poste une mise à jour si j'obtiens de nouvelles erreurs.

Je ne semble posséder aucun appareil 2.x.
Certains GU10 fonctionnent bien, d'autres non. J'ai commencé à remplacer les défectueux par des "neufs" que j'ai achetés quelques mois plus tard. Ils semblent exécuter le même firmware bien qu'il y ait un numéro "1808 -S" imprimé sur le socket tandis que les "plus récents" ont "1729-S".
J'ai remplacé 3 ampoules jusqu'à présent et aucun nouveau problème n'est survenu pendant 2 semaines. J'ai eu non seulement le problème avec GU10 mais aussi avec un panneau FLOALT que je n'ai pas remplacé.

Je ne semble posséder aucun appareil 2.x. Certains GU10 fonctionnent bien, d'autres non. J'ai commencé à remplacer les défectueux par des "neufs" que j'ai achetés quelques mois plus tard. Ils semblent exécuter le même firmware bien qu'il y ait un numéro "1808 -S" imprimé sur le socket tandis que les "plus récents" ont "1729-S". J'ai remplacé 3 ampoules jusqu'à présent et aucun nouveau problème n'est survenu pendant 2 semaines. J'ai eu non seulement le problème avec GU10 mais aussi avec un panneau FLOALT que je n'ai pas remplacé.

Intéressant! Je vais jeter un œil sur mes ampoules pour voir s'il y a une sorte de corrélation.

Il semble que l'un de mes nœuds soit à nouveau affecté par le problème. J'ai encore des nœuds IKEA dans le réseau, je vais donc faire quelques tests pour voir si je peux tirer des conclusions.

J'ai l'ampoule TRADFRI GU10 WS 400lm, l'ampoule TRADFRI E14 CWS opale 600lm et l'ampoule TRÅDFRI E27 CWS opale 600lm. Ils ne semblent pas causer de problèmes.

Il semble qu'après que le maillage ait été en place pendant un certain temps, même les autres appareils IKEA causent des problèmes et que les nœuds cessent de répondre aux commandes. Même d'autres nœuds IKEA peuvent être affectés, il me semble que les problèmes commencent à apparaître, puis les nœuds sont acheminés via un nœud IKEA.

Y a-t-il des activités prévues pour examiner cela? Je déplacerai tous mes appareils IKEA vers ma passerelle hue pendant que cela sera résolu.

les nœuds s'arrêtent pour répondre aux commandes.

Etes-vous sûr que c'est le cas? Avez-vous confirmé cela en reniflant le trafic ZigBee? Les autres nœuds ne réagissent plus aux commutateurs sans fil qui contrôlent les lumières sans passer par la passerelle? Ne réagissent-ils plus aux commandes de groupe?
D'après mon expérience, le problème est que la passerelle ne connaît plus la route vers les autres nœuds, de sorte que les commandes de monodiffusion de la passerelle n'atteignent jamais les autres nœuds. Les nœuds eux-mêmes répondent très bien, ils ne reçoivent tout simplement rien à quoi répondre.

Même d'autres nœuds IKEA peuvent être affectés, il me semble que les problèmes commencent à apparaître, puis les nœuds sont acheminés via un nœud IKEA.

Le nœud IKEA de routage (pas?) Rompt en quelque sorte la route et / ou la découverte de route par la passerelle vers les autres nœuds.

Y a-t-il des activités prévues pour examiner cela?

Vous devrez demander le support dresden elektronik. Le routage est géré par le firmware RaspBee / ConBee (et le programme de base deCONZ?). Nous ne pouvons rien faire à ce sujet dans le plugin REST API.

J'ai acheté un Tradfri Hub le week-end dernier et y a associé tous les spots GU10 d'une pièce. Voyons ce qui se passera dans les semaines à venir.

Il est peut-être un peu tôt pour le dire, mais il y a 29 jours, j'ai déplacé tous les Tradfri GU10 (8x warmwhite - 1.2.214) d'une pièce vers un Tradfri Hub, et aucun d'entre eux n'est devenu insensible jusqu'à maintenant.

Il est peut-être un peu tôt pour le dire, mais il y a 29 jours, j'ai déplacé tous les Tradfri GU10 (8x warmwhite - 1.2.214) d'une pièce vers un Tradfri Hub, et aucun d'entre eux n'est devenu insensible jusqu'à maintenant.

Je m'y attendrais. Le problème n'est pas tant causé par les appareils d'un seul fabricant que par l'interaction entre des appareils de différents fabricants, interprétant différemment la norme ZigBee. C'est pourquoi la plupart des concentrateurs / passerelles / ponts ne prennent en charge que leurs propres appareils. Une expérience plus intéressante serait de connecter les spots Trådfri au pont Hue ou à la passerelle OSRAM.

En outre, huit lumières dans une seule pièce entraîneront probablement une connexion directe entre le hub et chaque lumière: toutes les connexions à un seul saut. Les problèmes de routage n'apparaissent qu'avec des réseaux plus grands, avec plus de périphériques que d'entrées dans une table voisine (généralement autour de 20); et / ou avec des dispositifs physiquement hors de portée du concentrateur.

les nœuds s'arrêtent pour répondre aux commandes.

Etes-vous sûr que c'est le cas? Avez-vous confirmé cela en reniflant le trafic ZigBee? Les autres nœuds ne réagissent plus aux commutateurs sans fil qui contrôlent les lumières sans passer par la passerelle? Ne réagissent-ils plus aux commandes de groupe?
D'après mon expérience, le problème est que la passerelle ne connaît plus la route vers les autres nœuds, de sorte que les commandes de monodiffusion de la passerelle n'atteignent jamais les autres nœuds. Les nœuds eux-mêmes répondent très bien, ils ne reçoivent tout simplement rien à quoi répondre.

Je n'ai ni expérience ni équipement pour flairer le trafic. Vous avez probablement raison sur le comportement du problème. Mes nœuds répondent tout le temps aux commandes de groupe. Le problème est (si je comprends bien) que les commandes de monodiffusion n'atteignent jamais sa destination.

Tant que je n'envoie que des commandes de groupe, tout semble bien fonctionner.

Même d'autres nœuds IKEA peuvent être affectés, il me semble que les problèmes commencent à apparaître, puis les nœuds sont acheminés via un nœud IKEA.

Le nœud IKEA de routage (pas?) Rompt en quelque sorte la route et / ou la découverte de route par la passerelle vers les autres nœuds.

Y a-t-il des activités prévues pour examiner cela?

Vous devrez demander le support dresden elektronik. Le routage est géré par le firmware RaspBee / ConBee (et le programme de base deCONZ?). Nous ne pouvons rien faire à ce sujet dans le plugin REST API.

Oui, je leur ai envoyé un e-mail, mais je n'ai reçu aucune réponse en plus d'une liste de contrôle.

Il est peut-être un peu tôt pour le dire, mais il y a 29 jours, j'ai déplacé tous les Tradfri GU10 (8x warmwhite - 1.2.214) d'une pièce vers un Tradfri Hub, et aucun d'entre eux n'est devenu insensible jusqu'à maintenant.

Je m'y attendrais. Le problème n'est pas tant causé par les appareils d'un seul fabricant que par l'interaction entre des appareils de différents fabricants, interprétant différemment la norme ZigBee. C'est pourquoi la plupart des concentrateurs / passerelles / ponts ne prennent en charge que leurs propres appareils. Une expérience plus intéressante serait de connecter les spots Trådfri au pont Hue ou à la passerelle OSRAM.

En outre, huit lumières dans une seule pièce entraîneront probablement une connexion directe entre le hub et chaque lumière: toutes les connexions à un seul saut. Les problèmes de routage n'apparaissent qu'avec des réseaux plus grands, avec plus de périphériques que d'entrées dans une table voisine (généralement autour de 20); et / ou avec des dispositifs physiquement hors de portée du concentrateur.

J'ai fait cela pour m'assurer qu'il n'est pas lié au firmware 1.2.214 de l'ancien GU10 qui est souvent mentionné comme une cause possible ici (et une raison possible pour faire une nouvelle version du GU10).
Peut-être en relation avec connecté via un autre routeur.

J'envisagerai de jumeler mes autres lumières GU10 (également warmwhite 1.2.214) au Tradfri Hub (également celles du 2ème / 3ème étage)

Y a-t-il des progrès à ce sujet? Cela devient un peu ridicule avec mes lumières GU10 qui deviennent grises :(

Je pense avoir vu quelqu'un mentionner le contrôleur de rideau ou l'interrupteur marche / arrêt. En fait, il m'est arrivé que les problèmes se soient aggravés au moment où j'ai obtenu les stores FYRTUR. C'était aussi le premier bouton ikea que j'ai ajouté au réseau ... je donno ...

Je n'ai pas eu le commutateur marche / arrêt fyrtur dans le réseau depuis mon dernier message et aucun abandon pendant cette période. Cela pourrait être une coïncidence ...?

Y a-t-il des progrès à ce sujet? Cela devient un peu ridicule avec mes lumières GU10 qui deviennent grises :(
Je pense avoir vu quelqu'un mentionner le contrôleur de rideau ou l'interrupteur marche / arrêt. En fait, il m'est arrivé que les problèmes se soient aggravés au moment où j'ai obtenu les stores FYRTUR. C'était aussi le premier bouton ikea que j'ai ajouté au réseau ... je donno ...

Je n'ai pas eu le commutateur marche / arrêt fyrtur dans le réseau depuis mon dernier message et aucun abandon pendant cette période. Cela pourrait être une coïncidence ...?

Non, je n'ai pas de rideaux Tradfri on / off ou Tradfri et j'ai ce problème.
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment -562299982

Accidentellement fermé ce problème. Réouverture.

Une expérience plus intéressante serait de connecter les spots Trådfri au pont Hue ou à la passerelle OSRAM.

J'ai eu le même problème avec les ampoules Trådfri (première génération) connectées au hub Trådfri. Le problème a complètement disparu lorsque j'ai déplacé toutes les ampoules sur un pont Hue.

BTW - Je suis toujours convaincu que la première génération d'ampoules Trådfri est buguée, mais le pont Hue gère les lumières différemment (j'ai remarqué que parfois les lumières se désynchronisent pendant une fraction de seconde lorsqu'elles sont connectées à Hue - cela ne s'est jamais produit avec Trådfri ).

le pont Hue gère les lumières différemment (j'ai remarqué que parfois les lumières se désynchronisent pendant une fraction de seconde lorsqu'elles sont connectées à Hue - cela ne s'est jamais produit avec Trådfri).

Dans la configuration Hue, les lumières ne sont contrôlées que par le pont Hue: des commutateurs et des capteurs sans fil envoient des notifications au pont, déclenchant des règles qui contrôlent les lumières. Le pont prédit l'état de l'éclairage et met à jour son cache à l'avance lors de l'envoi de commandes aux lumières. Il interroge les lumières périodiquement pour valider / mettre à jour l'état mis en cache.

Dans la configuration Trådfri, les lumières sont contrôlées directement par des commandes d'interrupteurs et de capteurs sans fil. Les lumières envoient ensuite un rapport avec l'état mis à jour au hub.

Lorsque vous contrôlez les lumières connectées à un pont Hue directement à partir de commutateurs ou de capteurs sans fil (Trådfri), vous verrez un retard car le pont Hue ne configure pas le rapport d'attribut sur les lumières. Plus il y a de lumières dans votre réseau, plus le délai est long, car l'interrogation passe par plus de lumières.

Lors de la connexion d'ampoules Hue à un hub Trådfri et du contrôle de ces lumières directement à partir de commutateurs ou de capteurs sans fil (Trådfri), l'état du concentrateur ne sera jamais mis à jour, car les lumières Hue ne font pas de rapport d'attribut et le hub Trådfri ne fait pas d'interrogation.

Notez que ces différences se situent au niveau de l'application, bien sous le contrôle du plugin REST API. Le routage est à un niveau inférieur dans la pile ZigBee.

Maintenant, tous mes nœuds de routeur IKEA sont déplacés vers mon pont de teinte. J'ai toujours le même problème dans mon réseau. Je soupçonne donc que c'est quelque chose d'autre qui en est la cause. Et encore une fois, cela affecte les nœuds qui sont routés et n'ont pas de lien direct avec la passerelle.

Maintenant, tous mes nœuds de routeur IKEA sont déplacés vers mon pont de teinte. J'ai toujours le même problème dans mon réseau. Je soupçonne donc que c'est quelque chose d'autre qui en est la cause. Et encore une fois, cela affecte les nœuds qui sont routés et n'ont pas de lien direct avec la passerelle.

Le même problème avec les lampes Tradfri qui sont maintenant jumelées au pont Hue?

@ebaauw le problème de routage devrait-il apparaître lorsqu'une lumière est connectée directement au pont ET via un routeur, ou seulement lorsqu'elle n'est pas directement connectée au pont?

Maintenant, tous mes nœuds de routeur IKEA sont déplacés vers mon pont de teinte. J'ai toujours le même problème dans mon réseau. Je soupçonne donc que c'est quelque chose d'autre qui en est la cause. Et encore une fois, cela affecte les nœuds qui sont routés et n'ont pas de lien direct avec la passerelle.

Le même problème avec les lampes Tradfri qui sont maintenant jumelées au pont Hue?

Je n'ai que 3 ampoules jumelées. Mais aucun problème que j'ai remarqué.

@ebaauw le problème de routage devrait-il apparaître lorsqu'une lumière est connectée directement au pont ET via un routeur, ou seulement lorsqu'elle n'est pas directement connectée au pont?

Dans mon réseau, mon expérience est que les problèmes de commandes perdues affectent les nœuds qui sont acheminés via d'autres nœuds et non directement avec la passerelle. J'ai les mêmes problèmes maintenant même lorsqu'aucune ampoule IKEA n'est connectée.

J'avais un nœud (1) sans lien direct avec la passerelle. Il n'a pas répondu (ou comme ebaauw l'a mentionné, peut-être qu'ils n'atteignent jamais le nœud en raison de problèmes de routage) aux commandes de monodiffusion. Lorsque j'ai mis le nœud (2) hors tension, il a été acheminé via le nœud (1) a obtenu une route directe vers la passerelle et a commencé à fonctionner parfaitement.

le problème de routage doit-il apparaître lorsqu'une lumière est connectée directement au pont ET via un routeur, ou seulement lorsqu'elle n'est pas directement connectée au pont?

Il n'y a pas de "connexions" dans ZigBee. Chaque routeur conserve une table voisine des périphériques à proximité, qui peut atteindre directement (au niveau MAC). Les lignes de l'interface graphique deCONZ ne sont rien de plus qu'une représentation graphique de ces tables voisines (dans la mesure où deCONZ les a effectivement lues).

Lorsqu'un routeur a besoin d'envoyer un message à un appareil qui ne figure pas dans sa table voisine, il envoie la demande à un routeur voisin, afin qu'il puisse le transférer. Le message unique au niveau NWK est retransmis sur plusieurs bonds au niveau MAC. Le RaspBee / ConBee (dans cette perspective) n'est qu'un autre routeur. Afaik un appareil final envoie uniquement des messages à son routeur parent.

Ainsi, lorsqu'une lumière se trouve dans la table voisine du RaspBee / ConBee, aucune découverte d'itinéraire n'est impliquée, que cette lumière soit ou non la table voisine d'autres routeurs. Quand ce n'est pas le cas, le RaspBee / ConBee doit déterminer quel routeur voisin sait comment atteindre la lumière. Si la lumière est éloignée de plusieurs sauts, chaque routeur sur le chemin qui y mène doit faire de même.

J'ai bien peur que les détails ne me soient perdus, mais il existe plusieurs façons de faire cette découverte d'itinéraire. Lorsque les routeurs sur le chemin entre la passerelle et la lampe utilisent des méthodes différentes, les choses peuvent mal tourner. La passerelle peut finir par envoyer le message au mauvais routeur voisin (qui ne sait pas comment atteindre la lumière), ou la passerelle peut ne pas savoir comment atteindre la lumière du tout et n'enverra aucun message. Les messages unicast doivent généralement recevoir une réponse avec un ACK, de sorte que la passerelle marquera un périphérique comme inaccessible lorsqu'il ne reçoit pas l'ACK. Bien sûr, il n'y a aucun moyen de savoir si le message d'origine ou l'ACT a été perdu (le périphérique distant doit connaître l'itinéraire vers la passerelle pour envoyer l'ACK).

Les messages de diffusion (utilisés par les commandes de groupes) n'utilisent aucun routage; ils sont simplement rediffusés au niveau MAC par tous les routeurs. Bien que très fiables, ils consomment beaucoup de bande passante réseau. En outre, ils ne sont pas répondus par un ACK.

Dans mon réseau, mon expérience est que les problèmes de commandes perdues affectent les nœuds qui sont acheminés via d'autres nœuds et non directement avec la passerelle. J'ai les mêmes problèmes maintenant même lorsqu'aucune ampoule IKEA n'est connectée.

Donc, pour les problèmes de routage, vous avez besoin d'un réseau suffisamment grand pour que les périphériques n'apparaissent pas dans la table de routage du RaspBee / ConBee. Soit parce que le nombre de périphériques dépasse la taille de la table de routage, soit parce que les périphériques distants sont physiquement hors de portée du RaspBee / ConBee et ne peuvent être atteints que via d'autres routeurs. Je suppose que plusieurs sauts aggraveraient le problème.

Encore une fois, ce n'est pas tant la faute d'IKEA, car ce sont différents fabricants qui utilisent des méthodes différentes et quelque peu incompatibles pour faire la découverte d'itinéraire. Surtout avec les routes multi-sauts, il n'y a que peu de choses qui peuvent être contournées dans le micrologiciel RaspBee / ConBee.

J'avais un nœud (1) sans lien direct avec la passerelle. Il n'a pas répondu (ou comme ebaauw l'a mentionné, peut-être qu'ils n'atteignent jamais le nœud en raison de problèmes de routage) aux commandes de monodiffusion. Lorsque j'ai mis le nœud (2) hors tension, il a été acheminé via le nœud (1) a obtenu une route directe vers la passerelle et a commencé à fonctionner parfaitement.

Encore une fois, j'ai peur que les détails ne me soient perdus, mais je peux penser à plusieurs scénarios qui provoqueraient ce comportement. Le RaspBee / ConBee veut envoyer un message à node2 ou node1, ne reçoit pas d'accusé de réception, conclut que node2 est inaccessible et le supprime de sa table voisine. La table a maintenant de la place pour une nouvelle entrée, qui est utilisée pour node1.

Encore une fois, ce n'est pas tant la faute d'IKEA, car ce sont différents fabricants qui utilisent des méthodes différentes et quelque peu incompatibles pour faire la découverte d'itinéraire. Surtout avec les routes multi-sauts, il n'y a que peu de choses qui peuvent être contournées dans le micrologiciel RaspBee / ConBee.

Cela me semble que l'approche d'une plate-forme ZigBee multi-fournisseurs est condamnée par la conception jusqu'à ce qu'une norme plus approfondie soit établie et suivie. Pourtant, je suis en quelque sorte verrouillé en ce moment car je ne veux pas utiliser plusieurs passerelles qui ne fonctionneraient probablement pas dans mon environnement de toute façon (par exemple pour les capteurs qui ne peuvent pas être atteints directement par la passerelle si je supprime les ampoules qui agissent actuellement comme routeurs).

Cela me semble que l'approche d'une plate-forme ZigBee multi-fournisseurs est vouée à l'échec

J'espère sûrement que non, mais c'est vraiment difficile. La taille semble avoir une importance ici: si votre réseau est suffisamment petit, vous risquez de ne pas rencontrer ces problèmes de routage du tout. De plus, si le centre (géographique) de votre réseau se compose de routeurs de fournisseurs compatibles, certains routeurs moins compatibles en périphérie de votre réseau n'auront probablement pas d'importance (car ils ne sont pas acheminés pour atteindre d'autres appareils).

J'ai remplacé mes ampoules OSRAM, Trådfri et innr (qui causaient des problèmes) par des ampoules Hue. J'ai maintenant 104 nœuds, 51 routeurs et 53 terminaux. 2/3 des routeurs sont des voyants Hue. Le seul routeur qui devient inaccessible (mais qui envoie toujours des rapports) est le contrôleur de rideau Xiaomi. 20 des appareils finaux sont Hue, 20 Xiaomi, 8 Eurotronic Spirit et 5 IKEA. L'Eurotronic Spirit et IKEA Fyrtur me causent régulièrement des problèmes (ils sont expulsés par leur parent, mais ne trouvent pas de nouveau parent - encore une fois inaccessible par la passerelle, mais toujours en train d'envoyer des rapports), les autres semblent bien. Pour tous les appareils, le cycle d'alimentation remédie généralement à la situation, mais je dois parfois ouvrir le réseau lors du redémarrage de l'appareil.

J'ai envisagé de diviser mon réseau, non pas par fournisseur, mais par étage ou côté rue par rapport à l'arrière de ma maison. C'est beaucoup de travail et je suis réticent à le faire, tant que je n'aurai pas une meilleure compréhension de la cause des problèmes en détail et de la configuration qui pourrait les empêcher de se produire.

@ebaauw , en pensant à ce que vous avez dit dans le post ci-dessus, il serait intéressant de considérer une sorte de préférence pour la table de routage deCONZ. Pourrions-nous envisager de «mettre sur liste noire» des routeurs qui ne sont pas préférables comme premier saut. Si vous pouvez construire votre réseau pour contenir suffisamment de «bons» routeurs, le premier saut passerait toujours par ceux-ci et le deuxième bond atteindrait tous les autres périphériques du réseau.
Ce ne serait pas une solution définitive, mais autoriserait des réseaux beaucoup plus grands (géographiques et en nombre d'appareils) tout en passant toujours par des routeurs «préférés».

Autre réflexion: comme on sait quelles puces sont utilisées par IKEA (Silabs EFR32, moteur gecko) et qu'on sait (de diverses sources sur le net) qu'elles utilisent le moteur zigbee fourni par Silabs, on pourrait envisager deux actions.

1. Nous analysons la façon dont le moteur silabs effectue le routage et en déduisons la cause de ce problème
2. Nous construisons une version personnalisée du micrologiciel de la lampe basée sur le même moteur silabs, corrigeons le problème et trouvons un moyen d'installer ce micrologiciel OTA.

Les deux nécessiteraient un accès au SDK Silabs, ce que je n'ai pas. Y a-t-il quelqu'un ici actif qui le fait…? Je n'ai pas hâte de débourser 500 $ pour leur kit de développement qui comprend le SDK. Peut-être que Dresden Electronics est prêt à le faire?

mes 2 cts (étant plutôt frustré par les connexions parfois perdues).

Pourrions-nous envisager de «mettre sur liste noire» des routeurs qui ne sont pas préférables comme premier saut.

Nous: non. Il devrait être implémenté dans le firmware RaspBee / ConBee, je suppose. Pas une mauvaise idée à mon avis, mais je n'ai aucune idée de la faisabilité de cela, étant donné les limitations de taille dans l'EEPROM et la NVRAM de l'appareil. @manup , qu'en pensez-vous?

1. Nous construisons une version personnalisée du micrologiciel de la lampe basée sur le même moteur silabs, corrigeons le problème et trouvons un moyen d'installer ce micrologiciel OTA.

C'est bien au-delà de mes connaissances actuelles et, franchement, de mon ambition - je le fais pour un passe-temps. J'ai joué avec le XBee pour voir si je pouvais écrire une application ZigBee (mon objectif ultime serait de smartify mes stores vénitiens), mais je n'ai jamais regardé dans les niveaux inférieurs de la pile ZigBee, où le routage a lieu. .

Nous: non. Il devrait être implémenté dans le firmware RaspBee / ConBee, je suppose. Pas une mauvaise idée à mon avis, mais je n'ai aucune idée de la faisabilité de cela, étant donné les limitations de taille dans l'EEPROM et la NVRAM de l'appareil. @manup , qu'en pensez-vous?

Je suppose que je considère @manup comme

C'est bien au-delà de mes connaissances actuelles et, franchement, de mon ambition - je le fais pour un passe-temps. J'ai joué avec le XBee pour voir si je pouvais écrire une application ZigBee (mon objectif ultime serait de smartify mes stores vénitiens), mais je n'ai jamais regardé dans les niveaux inférieurs de la pile ZigBee, où le routage a lieu. .

Je suis d'accord, pour moi aussi c'est un passe-temps, mais j'espère en quelque sorte que quelqu'un connaisse mieux ces détails.

J'ai fait quelque chose de similaire en utilisant des cartes CC2530 Je prévois de zigbeeify mon système d'arrosage (je ne peux pas accepter que je doive me promener dans le jardin pour allumer / éteindre manuellement certains arroseurs :)) J'ai pu compiler un firmware zigbee pour ma carte CC2530 qui rejoint le réseau deCONZ en tant que voyant marche / arrêt. Les vannes que je prévois d'utiliser ont un mécanisme de verrouillage, donc nécessitent un signal spécifique pour basculer, donc j'ai dû créer mon propre firmware ...

Nous: non. Il devrait être implémenté dans le firmware RaspBee / ConBee, je suppose. Pas une mauvaise idée à mon avis, mais je n'ai aucune idée de la faisabilité de cela, étant donné les limitations de taille dans l'EEPROM et la NVRAM de l'appareil. @manup , qu'en pensez-vous?

La pile Zigbee dans le firmware a un paramètre pour contrôler si une route doit être utilisée au lieu d'un lien direct basé sur sa qualité (RSSI / LQI) cela devrait déjà fonctionner assez bien et a été peaufiné au fil des ans.

Un autre chemin pourrait être une approche plus générale pour contrôler les tables de routage de tous les périphériques.

Remarque: vous pouvez interroger la table de routage d'un routeur en la sélectionnant et en appuyant sur la touche R , les routes du prochain saut seront affichées en bleu.

Actuellement, lorsque le réseau Zigbee est ouvert, tous les routeurs sont autorisés à être un nœud parent puisque le Mgmt_Permit_Joining_req est envoyé en diffusion. Cependant, si nous envoyons cette demande en monodiffusion uniquement à un certain routeur, un nouveau périphérique ne peut se connecter que via ce périphérique. Cela peut être utile pour les terminaux Xiaomi qui collent souvent à leur parent. Pour les autres appareils de jonction tels que les routeurs et par exemple les terminaux Philips Hue, cela n'aidera pas beaucoup car ils sont libres de sélectionner eux-mêmes de nouveaux parents et itinéraires.

Le (nouveau) Mgmt_NWK_IEEE_Joining_List_req dans la spécification Zigbee R22 semble également intéressant:

La commande Mgmt_NWK_IEEE_Joining_List_req est fournie en tant que mécanisme pour obtenir la liste des adresses IEEE censées rejoindre le réseau. Cela permet au routeur local de filtrer les demandes de balises améliorées et de répondre uniquement aux périphériques qui se joignent.

Sans balises, les appareils n'essaieraient même pas de rejoindre un certain routeur. Mais je ne sais pas dans quelle mesure cette demande est prise en charge par les routeurs actuellement disponibles.

Une solution miracle pourrait être l'utilisation du routage source où la passerelle fournit l'itinéraire complet dans chaque trame, mais je n'ai jamais vu cela utilisé par un produit ou une passerelle grand public et je suppose donc qu'il n'est peut-être pas (ou mal) pris en charge par les routeurs actuels. Cela vaut peut-être la peine d'essayer.

Remarque: vous pouvez interroger la table de routage d'un routeur en la sélectionnant et en appuyant sur la touche R , les routes du prochain saut seront affichées en bleu.

Cool, je ne connaissais pas celui-là. Existe-t-il un aperçu de toutes les touches / commandes prises en charge par l'interface graphique? Est-il possible de revenir sur les lignes bleues avant d'interroger le nœud suivant? Cela ne semble pas fonctionner pour le RaspBee / ConBee lui-même?

La table de routage est-elle différente de la table voisine? En reniflant, je ne vois que les messages ZDP _Link Quality Request_ et _Link Quality Response_, signalant la table des voisins. Cela signifie-t-il que les lignes vers un nœud qui ne sont pas colorées en bleu sont les routes «entrantes»?

@manup , en effet une visualisation intéressante

Une solution miracle pourrait utiliser le routage source

Eh bien ... ça vaudrait la peine d'essayer, je suppose. Il me semble que, dans mon réseau, les éclairages IKEA les plus touchés sont ceux qui sont à une plus grande distance du coordinateur. Je soupçonne que quelque chose lié au routage est à l'origine des problèmes, comme @ebaauw l'a mentionné.
Je serais prêt à tester quelque chose comme ça pour vous. Cependant, je dois admettre que la perte des connexions n'est pas très fiable, donc les tests peuvent être difficiles.

Je réfléchissais davantage à l'idée que le coordinateur était sélectif sur le routeur à sélectionner pour le premier saut. Si nous pouvons trouver des routeurs qui fonctionnent bien avec les appareils IKEA (ce sont peut-être les routeurs IKEA), le routage de tous les paquets à travers ceux-ci devrait rendre les choses plus robustes. Vous ne savez pas si vous pouvez tromper le processus de découverte d'itinéraire pour préférer un certain routeur pour le premier saut, mais vous pouvez probablement commenter cela, @manup

Remarque: vous pouvez interroger la table de routage d'un routeur en la sélectionnant et en appuyant sur la touche R , les routes du prochain saut seront affichées en bleu.

Cool, je ne connaissais pas celui-là. Existe-t-il un aperçu de toutes les touches / commandes prises en charge par l'interface graphique? Est-il possible de revenir sur les lignes bleues avant d'interroger le nœud suivant? Cela ne semble pas fonctionner pour le RaspBee / ConBee lui-même?

Si quelqu'un veut lister tous les combos clés et ce qu'ils font, je serai heureux de le nettoyer et d'écrire une page wiki.

Cool, je ne connaissais pas celui-là. Existe-t-il un aperçu de toutes les touches / commandes prises en charge par l'interface graphique?

Request Node Descriptor = 1
Demander un descripteur de puissance = 2
Demande d'adresse Nwk = 0
Demande de table de routage = R
Request Mgmt Leave = L (avec rejoindre, ne pas utiliser avec les lumières innr!)
Demander des points de terminaison actifs = 7
Demander des descripteurs simples = 8
Actualiser = F5 / Cmd-R
Supprimer = Delete / Backspace
Gateway Device Annce = A (pas si utile)

Est-il possible de revenir sur les lignes bleues avant d'interroger le nœud suivant?

Pas encore, c'était juste un ajout rapide et sale pour voir les itinéraires :)
Peut-être que l'ajout d'une autre clé comme Shift-R pour effacer les routes d'un nœud est utile?

Cela ne semble pas fonctionner pour le RaspBee / ConBee lui-même?

Malheureusement RaspBee I / ConBee Je ne supporte pas la commande ZDP associée, cela fonctionne avec ConBee II.

La table de routage est-elle différente de la table voisine? En reniflant, je ne vois que les messages de demande de qualité de lien ZDP et de réponse de qualité de lien, rapportant la table des voisins.

Ce sont deux tables séparées, généralement la table de routage ne contient que les routes vers les nœuds qui ne sont pas directement accessibles et sont soumis à la table voisine (nœuds à 1 saut).

Pour les nœuds qui sont dans la table des voisins (et qui ont un signal fort), aucune découverte d'itinéraire n'est nécessaire. La table voisine elle-même est construite principalement à l'aide des commandes NWK Link Status à 1 saut.

Cela signifie-t-il que les lignes vers un nœud qui ne sont pas colorées en bleu sont les routes «entrantes»?

Les lignes non bleues (vert / orange / jaune) représentent simplement la table voisine à 1 saut. Les lignes bleues sont des routes sortantes vers une destination et représentent uniquement le prochain saut (pas la route complète) dans la vue actuelle, l'adresse NWK de destination n'est pas affichée, mais il y a probablement des impressions de débogage.

Nous: non. Il devrait être implémenté dans le firmware RaspBee / ConBee, je suppose. Pas une mauvaise idée à mon avis, mais je n'ai aucune idée de la faisabilité de cela, étant donné les limitations de taille dans l'EEPROM et la NVRAM de l'appareil. @manup , qu'en pensez-vous?

La pile Zigbee dans le firmware a un paramètre pour contrôler si une route doit être utilisée au lieu d'un lien direct basé sur sa qualité (RSSI / LQI) cela devrait déjà fonctionner assez bien et a été peaufiné au fil des ans.

Un autre chemin pourrait être une approche plus générale pour contrôler les tables de routage de tous les périphériques.

Remarque: vous pouvez interroger la table de routage d'un routeur en la sélectionnant et en appuyant sur la touche R , les routes du prochain saut seront affichées en bleu.

Fonction vraiment utile! Hier, j'ai allumé mon ampoule TRÅDFRI GU10 WS 400lm (7 ampoules) avec le firmware 2.0.022. Aujourd'hui les problèmes sont revenus, il est apparu sur une ampoule TRÅDFRI E27 CWS opale 600lm avec le firmware 1.3.009. Grâce à cette fonction, j'ai pu voir que l'ampoule E27 était acheminée par les GU10. J'ai éteint tous les GU10 et comme par magie, le E27 a recommencé à fonctionner.

Il devient donc assez clair que le routage via Innr et IKEA pose des problèmes. J'ai commencé à déplacer les ampoules Innr och IKEA vers ma passerelle de teinte. Il semble que les ampoules Philips soient de bons routeurs et ne causent pas de problèmes.

J'ai donc fait une petite expérience en repositionnant mes lumières dans le salon. J'ai enlevé deux routeurs et repositionné une lumière. Et voila, une lumière est devenue zombie, mais pas complètement. Il se comporte exactement comme je l'ai vu avec les luminaires IKEA qui perdent parfois la connexion.

L'éclairage IKEA est répertorié comme inaccessible, mais répond toujours aux commandes de groupe. De plus, comme il est toujours connu par plusieurs autres routeurs, il semble qu'ils signalent avoir vu la lumière (c'est 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

et

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

Parfois, il semble que la communication soit possible:

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

parfois non:

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

Il y a très peu d'informations sur ce qui ne va pas. Que signifie l'état 0xA7 ..?

Des informations supplémentaires qui pourraient aider à comprendre ce qui se passe?

J'ai donc fait une petite expérience en repositionnant mes lumières dans le salon. J'ai enlevé deux routeurs et repositionné une lumière. Et voila, une lumière est devenue zombie, mais pas complètement. Il se comporte exactement comme je l'ai vu avec les luminaires IKEA qui perdent parfois la connexion.

L'éclairage IKEA est répertorié comme inaccessible, mais répond toujours aux commandes de groupe. De plus, comme il est toujours connu par plusieurs autres routeurs, il semble qu'ils signalent avoir vu la lumière (c'est 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

et

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

Parfois, il semble que la communication soit possible:

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

parfois non:

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

Il y a très peu d'informations sur ce qui ne va pas. Que signifie l'état 0xA7 ..?

Des informations supplémentaires qui pourraient aider à comprendre ce qui se passe?

Cela ressemble à une réplique exacte de mes problèmes!

Que signifie l'état 0xA7 ..?

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

Puissance cyclé la lumière

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

Et semble rapporter joyeusement son statut

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

puis:

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

il cesse de fonctionner. jusqu'à .. 2 minutes plus tard

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

Je suppose que je dois me procurer un renifleur en zigbee pour comprendre ce qui se passe dans les airs.

après cela, il a cessé de fonctionner à nouveau, un peu plus permanent cette fois.

Que signifie l'état 0xA7 ..?

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

Merci pour ça! c'est en quelque sorte ce à quoi je m'attendais ...

J'ai essayé de coupler mon ampoule TRÅDFRI GU10 WS 400lm (7 ampoules) avec mon pont Philips Hue. Plusieurs autres ampoules sur le réseau sont devenues indisponibles et l'ampoule TRÅDFRI GU10 WS 400lm avait le même comportement qu'avec Deconz, réponse sur commande de groupe mais pas de réponse en monodiffusion.

L'ampoule TRÅDFRI GU10 WS 400lm semble avoir un problème. Je vais faire quelques tests si ce sont des ampoules induviduelles ou toutes qui ne fonctionnent pas.

Maintenant, j'ai fait quelques tests. Ma conclusion est que ce sont en fait des ampoules individuelles qui font que le réseau ne répond plus. Il est apparu instantanément sur le pont Hue et les choses ont recommencé à fonctionner dès que je les ai éteintes. Donc sur 7 ampoules, 3 sont concernées . Je signalerai si je trouve de nouveaux problèmes.

@MikaelHoogen , quelle version des ampoules et du firmware que vous avez?

J'ai vu ce problème sur v1 E27 WS 980lm, GU10 WS 400lm, E27 CWS 600lm, E15 WS et les 3 panneaux FLOALT sur les passerelles Ikea, HUE et DeCONZ au cours de l'année dernière et demie.
Je suis convaincu que c'est un problème HW. Le nœud qui meurt est totalement aléatoire.
Ici en Norvège, tous les appareils électroniques sont garantis 2 ans. Essaiera d'ouvrir un ticket et d'entendre ce qu'ils disent.
Concernant le FLOALT. Il y a quelques mois, Ikea organisait une vente de liquidation sur eux. C'était peut-être pour se débarrasser de toute la v1?
Quelqu'un a-t-il vu un FLOALT v2? (avec le pilote sy5882 peut-être?)

J'ai vu ce problème sur v1 E27 WS 980lm, GU10 WS 400lm, E27 CWS 600lm, E15 WS et les 3 panneaux FLOALT sur les passerelles Ikea, HUE et DeCONZ au cours de l'année dernière et demie.
Je suis convaincu que c'est un problème HW. Le nœud qui meurt est totalement aléatoire.
Ici en Norvège, tous les appareils électroniques sont garantis 2 ans. Essaiera d'ouvrir un ticket et d'entendre ce qu'ils disent.
Concernant le FLOALT. Il y a quelques mois, Ikea organisait une vente de liquidation sur eux. C'était peut-être pour se débarrasser de toute la v1?
Quelqu'un a-t-il vu un FLOALT v2? (avec le pilote sy5882 peut-être?)

C’est aussi ce que j’essaie de dire depuis un certain temps. J'ai des problèmes uniquement avec les ampoules Trådfri v1. Le pont Philips Hue aide mais les nœuds deviennent toujours inaccessibles de temps en temps.

Il y a quelques jours, j'ai décidé de remplacer les 12 ampoules IKEA GU10 par la nouvelle version (blanc chaud).
Cela a rendu ce problème encore pire. Maintenant, je perds également l'ambiance blanche Hue GU10 et la couleur Hue E14.

J'utilise deConz et IKEA light depuis le début de leur sortie. J'ai environ 70 nœuds dans mon réseau. La plupart d'entre eux sont des lampes IKEA. J'ai aussi quelques Philips Hue (4 lumières) et un Osram. Capteurs J'ai peu de mouvements Ikea et de nombreux capteurs de mouvement Xiaomi.

Je cours avec cette configuration depuis un certain temps et pas un jour ne va acheter sans que les autres lumières ne restent bloquées, je dois donc redémarrer. Ma femme n'est pas ravie et moi non plus. Je suis très proche d'abandonner tous les appareils zigbee et d'aller simplement aux lumières de la vieille école. Cela ne fonctionne tout simplement pas. très décevant. Je me demande si d'autres voient les mêmes problèmes en utilisant des lampes Philips ou Osram pures ou est-ce juste IKEA qui est de la merde?

J'utilise deConz et IKEA light depuis le début de leur sortie. J'ai environ 70 nœuds dans mon réseau. La plupart d'entre eux sont des lampes IKEA. J'ai aussi quelques Philips Hue (4 lumières) et un Osram. Capteurs J'ai peu de mouvements Ikea et de nombreux capteurs de mouvement Xiaomi.

Je cours avec cette configuration depuis un certain temps et pas un jour ne va acheter sans que les autres lumières ne restent bloquées, je dois donc redémarrer. Ma femme n'est pas ravie et moi non plus. Je suis très proche d'abandonner tous les appareils zigbee et d'aller simplement aux lumières de la vieille école. Cela ne fonctionne tout simplement pas. très décevant. Je me demande si d'autres voient les mêmes problèmes en utilisant des lampes Philips ou Osram pures ou est-ce juste IKEA qui est de la merde?

En regardant toutes les personnes ayant exactement les mêmes problèmes dans ce fil et les fabricants de deconz ne peuvent pas comprendre quel est le problème avec les lumières IKEA, cela sent et ressemble à un problème de firmware IKEA.

De nombreux utilisateurs rencontrent des problèmes similaires, même avec le hub IKEA. Donc je suppose que ce n'est pas un problème unique lié au deconz. Cependant, si quelqu'un pouvait résoudre ce problème, "corrigez-le / trouvez une solution de contournement", ce serait les gars ici! <3

J'ai exactement le même problème avec la famille et avec la configuration.

C'est triste: (surtout que même les nouveaux qu'ils vendent aujourd'hui ont encore ces problèmes. Je ne comprends tout simplement pas. J'ai le mien de 2017, vous vous attendez donc à ce qu'ils résolvent le problème maintenant. Je devrai envisager de supprimer le tout Cela ne peut pas être résolu ici, @manup a déjà dit qu'il s'agissait d'un problème dans le firmware de l'appareil, donc c'est seulement IKEA qui peut résoudre ce problème et comme ils ne l'ont pas encore fait, il n'y a aucun espoir.

Deconz version 2.05.69
Micrologiciel Conbee II 264A0700

Ce n'est pas parfait à 100% et les pertes que j'ai remarquées sont des ampoules E27 Ikea (Rev1).
Quand j'ai eu ces lumières Ikea avec mon pont Philips Hue, elles étaient solides comme le roc, donc je les ramène probablement à Hue et je garde ce maillage Zigbee uniquement CC2531 (firmware du routeur) et les capteurs Xiaomi.
J'ai aussi une ampoule Innr (E14) et une SP120 mais celles-ci fonctionnent toujours avec Deconz.

J'utilise Home Assistant et Deconz pour contrôler environ 20 ampoules Ikea (et une foule d'autres capteurs). Les ampoules sont principalement des GU10 qui sont regroupées par 3 spots pour une lumière.

J'utilise cette configuration depuis plus de 15 mois et depuis cet été, j'ai eu des problèmes avec une ou plusieurs ampoules simples bloquées et nécessitant un cycle d'alimentation, ou même supprimées et ajoutées au réseau Zigbee. Il s'agissait toujours de GU10 définis dans un groupe léger dans HASS.

Il y a quelques semaines, j'ai créé des groupes pour mes lumières dans Phoscon, et j'ai commencé à référencer ces groupes dans HASS.

Après cela, je n'ai pas eu un seul problème avec les ampoules bloquées et nécessitant un cycle d'alimentation. Le seul problème que je vois est que lorsque j'éteins toutes mes lumières intérieures en même temps, parfois un groupe Phoscon / Deconz entier reste allumé.

Pour moi, cela semble être un problème avec l'API Deconz et éventuellement la gestion de plusieurs ampoules en succession rapide.

J'ai également des problèmes avec les appareils Ikea (ampoules et dernièrement aussi la télécommande Symfonisk) devenant indisponibles et nécessitant un nouveau couplage avec deCONZ. J'ai ces problèmes depuis environ 6 mois, je crois. Pas grand chose à ajouter que je pense que cela arrive plus fréquemment ces derniers temps. Je n'ai pas d'ampoules GU10, seulement diverses E27 et E14 (et diverses télécommandes). Il semble que certains appareils sont plus enclins à abandonner (peut-être en fonction de leur maillage ou similaire). J'ai environ 20 appareils avec une portée maximale de 5 m du Conbee I avec le dernier FW / Phoscon / deCONZ.

J'ai également des problèmes avec les appareils Ikea (ampoules et dernièrement aussi la télécommande Symfonisk) devenant indisponibles et nécessitant un nouveau couplage avec deCONZ. J'ai ces problèmes depuis environ 6 mois, je crois. Pas grand chose à ajouter que je pense que cela arrive plus fréquemment ces derniers temps. Je n'ai pas d'ampoules GU10, seulement diverses E27 et E14 (et diverses télécommandes). Il semble que certains appareils sont plus enclins à abandonner (peut-être en fonction de leur maillage ou similaire). J'ai environ 20 appareils avec une portée maximale de 5 m du Conbee I avec le dernier FW / Phoscon / deCONZ.

Essayez Deconz version 2.05.69. Assez stable pour moi avec Ikea, Innr et Xiaomi

J'ai un problème similaire et un ticket ouvert https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2256#issue -543476970

Je dirais que la rétrogradation à la version 2.05.67 a rendu mon réseau beaucoup plus stable que jamais. Il y avait quelques ampoules qui sont allées dans un état irresponsable, mais les mêmes deux et pourraient vivre avec celles-ci. Hier, tout a fonctionné comme prévu.

Cela semble être un problème avec un mélange de toutes les parties possibles, et bien sûr, il est difficile à trouver. Cependant, la version deconz semble être un élément majeur pour avoir une solution stable ou non.

J'ai également des problèmes avec les appareils Ikea (ampoules et dernièrement aussi la télécommande Symfonisk) devenant indisponibles et nécessitant un nouveau couplage avec deCONZ. J'ai ces problèmes depuis environ 6 mois, je crois. Pas grand chose à ajouter que je pense que cela arrive plus fréquemment ces derniers temps. Je n'ai pas d'ampoules GU10, seulement diverses E27 et E14 (et diverses télécommandes). Il semble que certains appareils sont plus enclins à abandonner (peut-être en fonction de leur maillage ou similaire). J'ai environ 20 appareils avec une portée maximale de 5 m du Conbee I avec le dernier FW / Phoscon / deCONZ.

Essayez Deconz version 2.05.69. Assez stable pour moi avec Ikea, Innr et Xiaomi

Je vais essayer cela ainsi que le

Il y a quelques semaines, j'ai créé des groupes pour mes lumières dans Phoscon, et j'ai commencé à référencer ces groupes dans HASS.

J'ai donc finalement eu mon matériel de reniflage et j'ai aussi piraté un peu Wireshark pour afficher les noms de toutes les adresses ieee802.15.4 (ce qui facilite la lecture de ce qui se passe).

Quoi qu'il en soit, ma connaissance du zigbee n'est pas très forte, donc je pose peut-être des questions stupides. Cependant, j'ai parcouru des journaux de reniflage et j'espère que nous pouvons voir quelque chose qui explique le comportement floconneux des lampes ikea.

Consultez le journal ci-dessous. Cela vous semble-t-il un comportement «normal»? Les deux lumières impliquées sont des lampes Ikea. D'abord DeConz envoie une demande au «Garage», en passant par le «Zolder». Ensuite 'Zolder' essaie de le transmettre au 'Garage', mais cela semble échouer (Pourquoi?) Et il est réessayé 20 fois de suite très rapidement (la plupart sont dans les 3 ms). Finalement, «Zolder» abandonne et renvoie un échec de liaison à DeConz.

Doit-il être aussi agressif lors de la nouvelle tentative de transmission?

Aussi: je remarque que DeConz continue à envoyer des demandes à Garage via Zolder, bien que le lien échoue clairement. DeConz fait même cela lorsque Garage n'est plus dans le rapport d'état des liens de Zolder. De plus, si parfois Garage est dans le rapport d'état des liens de Zolder, il en coûte 7 à la fois entrants et sortants. En fait, la route de Garage à DeConz ne passe pas par Zolder ...
Pourquoi DeConz continue-t-il à acheminer via Zolder même après un message d'échec de liaison?

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, j'ai donc passé du temps à lire la documentation silabs ZigBee (les IKEA sont basées sur des puces silabs).
Apparemment, le comportement de nouvelle tentative est exactement comme décrit dans les documents.

Cela laisse la question de savoir pourquoi DeConz insiste pour utiliser cette route. Le coût de la liaison est élevé, il y a une réponse d'échec de liaison et cette route est toujours utilisée. Pourquoi..?
(et de meilleurs itinéraires sont disponibles ...)

Des informations très utiles @djwlindenaar bien que je ne puisse pas vous aider à ce niveau. Cela confirme un peu mes soupçons. J'avais un réseau de travail décent (avec rétrogradation du logiciel) jusqu'à ce que je reçoive une coupure de courant accidentelle et que toute la maison soit coupée.

Après cela, je suis de retour et je pense que j'ai de nouveau de mauvaises routes.

Une autre chose. Comment se fait-il que deconz règle les états même si l'appareil réel ne répond pas? On dirait qu'une ampoule est allumée dans les interfaces mais physique, elle est éteinte (toujours alimentée). Parfois, il fonctionne pour le rallumer (via un logiciel), parfois il fonctionne avec un cycle d'alimentation, mais souvent il ne répond pas du tout même après un cycle d'alimentation. La même ampoule peut soudainement répondre après un certain temps

Un comportement plus intéressant (je montre les mêmes lumières, mais cela se produit également à d'autres endroits de mon réseau)

• DeConz envoie des paquets many-to-one route Route Request . Le résultat est que tout appareil effectuera d'abord une découverte d'itinéraire. Ceci est censé alimenter le concentrateur (coordinateur) avec des informations sur la façon d'atteindre cet appareil. Il semble que DeConz ignore ces informations pour son routage ...

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

Ce dernier paquet contient des informations sur la façon d'accéder au garage:

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

Mais la prochaine demande à Garage est de nouveau envoyée via le Zolder

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

Je ne serais pas surpris que ce comportement ait quelque chose à voir avec le comportement de la lumière irrégulière d'IKEA.

@manup , pouvez-vous commenter cela? Votre déclaration selon laquelle le routage de source aiderait, a beaucoup de sens.
Alternativement, je m'attends à ce que l'utilisation des informations du Route Record pour mettre à jour la table de routage de DeConz soit déjà une énorme amélioration ...
Ou nous devons comprendre pourquoi DeConz veut continuer à utiliser une route qui signale des problèmes de liaison / a des coûts de routage élevés par rapport à une alternative.

Une autre observation ... Les deux dispositifs de relais dans le paquet ci-dessus sont tous deux des prises Xiaomi. Ils ne sont jamais interrogés sur la qualité du lien. Pourquoi?
Se pourrait-il que DeConz utilise les informations de Link Quality Response pour construire sa table de routage et ignore donc les routeurs tout à fait valides? Avec une bonne qualité de lien vers certaines de mes malheureuses lampes IKEA ...

Ne voyez-vous que ce comportement pour les appareils ikea ou un comportement général pour ignorer l'itinéraire optimal? Je suppose que vous avez un nombre décent d'appareils ikea?

Je ne suis pas sûr, il faudrait que je vérifie cela. Bonne question.

J'ai un assez grand nombre d'ampoules Ikea, oui.

Dans mon esprit, cela explique une grande partie du comportement que nous avons vu avec les lumières IKEA inaccessibles. Même s'il ne s'agit que d'hypothèses pour l'instant, à vérifier.

En regardant dans plusieurs autres itinéraires et je vois le même comportement.

Je vois seulement que les appareils Xiaomi ne sont pas interrogés sur la qualité du lien, toutes les autres marques le sont. Je suppose que c'est une sorte de liste noire ..?

Exemple d'un autre comportement de routage:

De DeConz, toujours:
DeConz --> WC Lamp --> Badkamer Ledstrip

L'itinéraire de retour change souvent après une demande d'itinéraire plusieurs-à-un. Notez que d'un point de vue géographique, tout cela a du sens ...
Badkamer Ledstrip --> WC Lamp --> DeConz
Badkamer Ledstrip --> Gang 1 --> DeConz
Badkamer Ledstrip --> Zoldertrap Lamp --> DeConz
Badkamer Ledstrip --> Gang 1 --> Zoldertrap Lamp --> DeConz

Pour la lumière du garage, je vois de DeConz:
DeConz --> Zolder Noord Lamp --> Garage (itinéraire très floconneux ..!)

Itinéraire de retour que je vois:
Garage --> Kerstverlichting --> On/Off Light 36 --> DeConz
Garage --> Kerstverlichting --> HK Zoutlamp --> DeConz

Maintenant, lorsque je regarde le tableau dans les rapports d'état des liens, l'itinéraire ci-dessus conduit de Garage à DeConz a du sens:
Garage --> Kerstverlichting --> On/Off Light 36 --> DeConz coût total: 4
Garage --> Kerstverlichting --> HK Zoutlamp --> DeConz coût total: 4

de DeConz à Garage ne:
DeConz --> Zolder Noord Lamp --> Garage coût total: 12 (basé sur le coût entrant de DeConz à Zolder Noord Lamp)

@manup , pourriez-vous élaborer sur l'algorithme de coût d'itinéraire utilisé? Pourquoi ce qui précède a-t-il un sens?

Encore une analyse aujourd'hui ...
Dans mes messages précédents, vous avez vu que mon éclairage de garage est acheminé à travers mon éclairage Zolder. Les deux ampoules IKEA. La liaison radio de Zolder à Garage est juste à la limite de ce qu'elle peut atteindre, elle échoue donc souvent.

Aujourd'hui, bien que l'éclairage Garage réponde aux commandes de groupe, il ne répond pas aux commandes monodiffusion. En fait, parfois c'est le cas et parfois non. C'est un comportement qui devrait être familier à ceux qui ont lu / contribué à ce fil.

Je peux trouver cela dans les journaux de reniflage. Parfois, la lumière Zolder est capable de communiquer avec Garage et parfois non. Chaque fois que Zolder Light ne peut pas communiquer avec Garage, il signale ceci:

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]

Ce paquet devrait dire à DeConz de commencer à trouver une autre route pour atteindre Garage, mais cela ne se produit pas. Le prochain paquet envoyé à Garage est à nouveau acheminé via Zolder. Pour moi, c'est un bug qui doit être résolu.
Ce prochain paquet pour Garage est reçu par la lumière Zolder, mais cette lumière n'essaye même pas de l'envoyer au garage. C'est peut-être un comportement du micrologiciel IKEA qui n'est pas bon, mais la cause première du problème est le refus de DeConz de trouver un itinéraire alternatif.
Je pense que si une route n'est pas disponible pendant une période prolongée, la lumière du garage est peut-être affamée pour les ACK à un niveau plus élevé que le protocole 802.15.4 et cela peut entraîner la déconnexion du micrologiciel ou même le crash. Et je suis d'accord que ce ne devrait pas être le cas, mais le problème est que DeConz refuse de trouver un nouvel itinéraire vers l'éclairage du garage.

Aujourd'hui, j'ai fait une expérience pour que DeConz trouve un autre itinéraire vers la lumière du garage, alors j'ai déconnecté le secteur de la lumière Zolder et j'ai regardé les bûches reniflées. Après quelques essais, DeConz se rend compte que Zolder est parti et va de l'avant pour trouver un itinéraire alternatif vers Garage. Ensuite, je reconnecte Zolder et après avoir annoncé sa présence également pour Zolder, une nouvelle route est trouvée. DeConz ne revient pas (encore) au routage de Garage via Zolder.

Ce qui est drôle, c'est que dans la nouvelle situation, DeConz parle maintenant directement avec Garage light, pas de routeurs entre les deux.
Zolder est maintenant atteint via une route via 2 autres routeurs (bien qu'il était évidemment accessible directement par DeConz), donc il me semble qu'une table (table voisine?) Est pleine à l'intérieur du firmware de routage DeConz.

Peut-être que cela est lié à son refus de créer une nouvelle route en réponse à une route défaillante ..?

@manup , j'apprécierais tout commentaire de votre part sur les messages ci-dessus. Ou du moins laissez-moi savoir comment contribuer à une solution (en plus de rechercher la cause profonde).

Je voudrais aider à créer une solution à ces problèmes, car ils me dérangent. Si vous donnez accès au code source du firmware, je peux contribuer directement (même si ce n'est pas open source). Cela ne me dérange pas d'aider Dresden Elektronik de cette façon :)

Excellent travail fait! 💪🏼
J'espère que nous pourrons attirer l'attention des développeurs pour résoudre ce problème. Il semble que vous ayez une bonne configuration et un bon processus pour qu'un correctif puisse être vérifié assez «facilement».
Je comprends maintenant le comportement que j'ai vu que j'ai appelé «auto-guérison» et pourquoi certaines ampoules fonctionnent soudainement.

Beau travail @djwlindenaar j'espère que @manup pourra regarder ça.

@manup des commentaires?

Merci pour ce fil et travail. J'ai moi-même en cours d'exécution 20 firmware de mise à jour d'ampoule ikea et un an. J'ai connu des gouttes de gel ou une ampoule perdue depuis le début, mais pas trop fréquemment. Cela a empiré avec les mises à jour ultérieures de Deconz. J'ai vérifié mon réseau optimisé dans un environnement emballé 2.4. L'ampoule continue de tomber tous les jours et rend les boutons ou capteurs inutiles car ils sont toujours acheminés via ces ampoules et ne transmettent donc aucun mouvement de données. Je dois redémarrer et rendre les capteurs disponibles lorsque les ampoules recommencent à les acheminer. J'espère que cela retiendra davantage l'attention. C'est frustrant.

Une autre observation ... Les deux dispositifs de relais dans le paquet ci-dessus sont tous deux des prises Xiaomi. Ils ne sont jamais interrogés sur la qualité du lien. Pourquoi?
Se pourrait-il que DeConz utilise les informations de Link Quality Response pour construire sa table de routage et ignore donc les routeurs tout à fait valides? Avec une bonne qualité de lien vers certaines de mes malheureuses lampes IKEA ...

La requête de la table voisine (alias ZDP Mgmt_Lqi_req) a été désactivée pour les appareils Xiaomi car ils ne répondent pas à ces requêtes après un certain temps et je soupçonnais qu'une erreur dans le micrologiciel pouvait déclencher un état invalide ou pire.

Ainsi, le principal moteur pour limiter certaines demandes est d'éviter les erreurs dans le micrologiciel du périphérique final et d'imiter étroitement le comportement de la passerelle du fournisseur associé, certains des résultats de l'enquête peuvent être trouvés dans https://github.com/dresden-elektronik/deconz-rest -plugin / wiki / Interrogation de l'appareil final

En remarque, les requêtes de table voisine ne sont utilisées que pour créer la présentation visuelle du maillage et n'affectent pas le fonctionnement du réseau ou les tables de routage.

J'ai donc finalement eu mon matériel de reniflage et j'ai aussi piraté un peu Wireshark pour afficher les noms de toutes les adresses ieee802.15.4 (ce qui facilite la lecture de ce qui se passe).

Quoi qu'il en soit, ma connaissance du zigbee n'est pas très forte, donc je pose peut-être des questions stupides. Cependant, j'ai parcouru des journaux de reniflage et j'espère que nous pouvons voir quelque chose qui explique le comportement floconneux des lampes ikea.

Consultez le journal ci-dessous. Cela vous semble-t-il un comportement «normal»? Les deux lumières impliquées sont des lampes Ikea. D'abord DeConz envoie une demande au «Garage», en passant par le «Zolder». Ensuite 'Zolder' essaie de le transmettre au 'Garage', mais cela semble échouer (Pourquoi?) Et il est réessayé 20 fois de suite très rapidement (la plupart sont dans les 3 ms). Finalement, «Zolder» abandonne et renvoie un échec de liaison à DeConz.

Doit-il être aussi agressif lors de la nouvelle tentative de transmission?

Aussi: je remarque que DeConz continue à envoyer des demandes à Garage via Zolder, bien que le lien échoue clairement. DeConz fait même cela lorsque Garage n'est plus dans le rapport d'état des liens de Zolder. De plus, si parfois Garage est dans le rapport d'état des liens de Zolder, il en coûte 7 à la fois entrants et sortants. En fait, la route de Garage à DeConz ne passe pas par Zolder ...
Pourquoi DeConz continue-t-il à acheminer via Zolder même après un message d'échec de liaison?

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

Bonne prise! Ici, je soupçonne que le firmware deCONZ doit gérer cette erreur et réessayer de trouver une nouvelle route. Je vais vérifier le firmware si ce cas est traité et comment. Je peux imaginer que la route est effectivement rejetée, mais si un nouveau message est reçu par la même route. Par exemple, en raison d'un rapport d'attribut ZCL de la lumière, l'entrée est simplement maintenue en vie.

Les routes peuvent être établies simplement en recevant n'importe quelle commande d'une trame entrante. Mais si le dernier saut ne garde pas le saut avant cela (ce qu'ils font habituellement), le retour par le même saut ne fonctionnera pas. Vos conclusions pourraient refléter exactement ce cas.

Merci.

Dans ce cas, il n'y a jamais de message de la lumière du garage reçu via Zolder. Par conséquent, je ne m'attendrais pas à ce que DeConz continue à utiliser la route. Voir mes autres articles ...

Code d'état: échec de liaison non-arborescente (0x02)

Il semble que nous avons un gagnant, j'ai vérifié la source de la pile Zigbee (R21, ConBee II) et ce code d'état est complètement ignoré. : -O Besoin de vérifier la pile AVR Zigbee aussi, probablement le même problème là-bas.

En guise de solution, j'aimerais gérer ce code de la même manière que le statut "Aucune route disponible" est géré, ce qui est juste pour libérer l'entrée de la route et laisser la pile en trouver une nouvelle.

Avez-vous également un paquet complet de la commande qui a été préalablement envoyée par le coordinateur à la lumière IKEA? Ce serait intéressant si le bit de découverte d'itinéraire était défini.

Voici la section de la spécification Zigbee sur ce qui devrait se passer dans ce cas particulier:

À la réception d'une trame de commande d'état du réseau par un routeur qui est la destination prévue de la commande où le champ de code d'état de la charge utile de la trame de commande a une valeur de 0x01 ou 0x02 indiquant une défaillance de liaison, la couche NWK supprimera l'entrée de la table de routage correspondant à la valeur du champ d'adresse de destination de la charge utile de trame de commande, s'il en existe une, et informer la couche immédiatement supérieure de l'échec en utilisant l'indication NLME-NWK-STATUS en utilisant le même code d'état.

Donc, le correctif ci-dessus devrait fonctionner ici pour 0x02, 0x01 n'est pas non plus géré, je l'ajouterai aussi.

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

Super @manup! Vous avez évoqué le Conbee II. Ce correctif fonctionnera-t-il également pour le Conbee I?

Oui, je n'ai que les sources de pile utilisées par ConBee I et RaspBee. Le même problème ici, je vais cuisiner de nouvelles versions de firmware pour les tests jusqu'à mardi. Ce serait cool d'obtenir des commentaires si cela résout au moins les problèmes de routage IKEA.

Notez qu'il y avait aussi d'autres problèmes qui ne seront pas résolus par cela, comme les ampoules IKEA devenant complètement silencieuses et n'écoutant même pas les moulages de groupe.

Accidentellement fermé ce numéro ... Rouvert. C'est formidable que nous progressions dans ce domaine.

Je suppose que @djwlindenaar est celui qui est capable de donner des commentaires une fois que le nouveau firmware est disponible, car le matériel de reniflage est nécessaire pour cela?

Avez-vous également un paquet complet de la commande qui a été préalablement envoyée par le coordinateur à la lumière IKEA? Ce serait intéressant si le bit de découverte d'itinéraire était défini.

Je ne suis pas sûr de comprendre votre question. Quel paquet recherchez-vous? Et à quelle lumière (Garage ou Zolder)?

Oui, je n'ai que les sources de pile utilisées par ConBee I et RaspBee. Le même problème ici, je vais cuisiner de nouvelles versions de firmware pour les tests jusqu'à mardi. Ce serait cool d'obtenir des commentaires si cela résout au moins les problèmes de routage IKEA.

Notez qu'il y avait aussi d'autres problèmes qui ne seront pas résolus par cela, comme les ampoules IKEA devenant complètement silencieuses et n'écoutant même pas les moulages de groupe.

Je vais le tester à coup sûr. Bien que cela puisse prendre un certain temps pour arriver à une conclusion car parfois il n'y a pas de problème pendant longtemps ...

Je pensais qu'il y avait peut-être quelque chose qui déclenchait ce comportement de devenir complètement silencieux. J'ai eu cela la semaine dernière mais je n'ai pas encore eu le temps de parcourir les journaux de renifleur.

Je suis sur Raspbee btw.

Oui, je n'ai que les sources de pile utilisées par ConBee I et RaspBee. Le même problème ici, je vais cuisiner de nouvelles versions de firmware pour les tests jusqu'à mardi. Ce serait cool d'obtenir des commentaires si cela résout au moins les problèmes de routage IKEA.

Faites-nous savoir, j'ai beaucoup de problèmes et je pourrais le tester, mais sans renifler.

Notez qu'il y avait aussi d'autres problèmes qui ne seront pas résolus par cela, comme les ampoules IKEA devenant complètement silencieuses et n'écoutant même pas les moulages de groupe.

Faites-vous référence au problème que le logiciel (deconz) signale et définit un état mais que l'ampoule elle-même ne répond pas ou ne change pas d'état? Le problème ne serait peut-être pas de la même gravité si nous réglions le problème de routage.

Merci sapin de regarder cela, très apprécié!

Oui, je n'ai que les sources de pile utilisées par ConBee I et RaspBee. Le même problème ici, je vais cuisiner de nouvelles versions de firmware pour les tests jusqu'à mardi. Ce serait cool d'obtenir des commentaires si cela résout au moins les problèmes de routage IKEA.

Notez qu'il y avait aussi d'autres problèmes qui ne seront pas résolus par cela, comme les ampoules IKEA devenant complètement silencieuses et n'écoutant même pas les moulages de groupe.

Merci manup! Je passerai au nouveau fw dès qu'il sera disponible et je fournirai des mises à jour.

Ce problème pourrait-il également être lié au problème de contrôle des stores Ikea Fyrtur?

Un autre qui me semble étrange. @manup , cela pourrait-il également être un problème?

Je vois beaucoup de ce genre de séquences. J'ai commencé à examiner cela, car c'est la dernière communication de houtlamp avant qu'elle ne cesse de répondre. DeConz configure 2 éléments de rapport d'attributs et demande presque en même temps des appartenances à des groupes. Dans les journaux de DeConz, cela ressemble à ci-dessous.

Je me demande s'il y a un bug dans la sélection du numéro de séquence ou peut-être qu'il est autorisé (je ne sais pas) et ce comportement déclenche un bug dans le firmware Tradfri. Il y a une demande avec le numéro 215 et deux demandes avec le numéro 216. Se pourrait-il que nous ayons une sorte de condition de concurrence où la gestion des demandes par le micrologiciel tradfri provoque une fuite de mémoire ou un blocage en raison des deux demandes avec le même numéro à peu près au même moment? Shoud DeConz a-t-il deux requêtes avec le même numéro de séquence?

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

En direct, cela ressemble à: (il semble que je ne vois pas tous les paquets en direct, ce qui est étrange car le renifleur est juste à côté de la raspbee. Peut-être qu'ils sont envoyés si vite qu'ils se perdent dans un débordement de tampon ou quelque chose sur le renifleur)

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

En effet les numéros de séquence ne doivent pas être égaux dans ce court laps de temps, je vais vérifier le code, il semble qu'un incrément manque.

Voici le premier firmware de test pour ConBee II

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

Le portage de ce nouveau dans le micrologiciel ConBee I / RaspBee sera bientôt en ligne.

Et voici la version de test pour ConBee I et RaspBee avec le correctif d'erreur de route.
J'espère que cela apporte des améliorations pour découvrir une nouvelle route lorsque l'erreur se produit.

Pour les tests, je pense que ce serait bien si cela ne fonctionnait que pendant quelques jours / semaines et nous verrons si les lumières cessent toujours de répondre aux monodiffusions. Dans ce cas, essayez si les lumières réagissent toujours aux commandes de groupe ou deviennent complètement silencieuses.

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

Pour les tests, je pense que ce serait bien si cela ne fonctionnait que pendant quelques jours / semaines et nous verrons si les lumières cessent toujours de répondre aux monodiffusions. Dans ce cas, essayez si les lumières réagissent toujours aux commandes de groupe ou deviennent complètement silencieuses.

Et quand il réagit aux commandes de groupe, attendez quelques jours pour vérifier qu'il continue de réagir aux commandes de groupe. Dans mon cas, lorsque les lumières ne réagissent qu'aux commandes de groupe, tôt ou tard, elles deviennent complètement silencieuses.

Et quand il réagit aux commandes de groupe, attendez quelques jours pour vérifier qu'il continue de réagir aux commandes de groupe. Dans mon cas, lorsque les lumières ne réagissent qu'aux commandes de groupe, tôt ou tard, elles deviennent complètement silencieuses.

J'ai vu cela aussi dans le passé, peut-être qu'ils le font puisqu'aucune monodiffusion n'est plus reçue, le temps le dira.

@manup Ce problème peut-il être lié? https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1657

Peut-être que oui, au moins l'état accessible deviendrait également faux lorsque l'itinéraire est interrompu. Mais cela peut aussi être causé par d'autres raisons.

J'ai remarqué qu'il existe un firmware plus récent pour certaines ampoules ikea. Le journal des modifications indique l'amélioration du réseau / de la connectivité et de la gestion des pannes. Je mets à jour 20 ampoules ... je fournirai des mises à jour si cela est utile.

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

Dommage qu'il ne contienne pas de dates de sortie ...

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

Dommage qu'il ne contienne pas de dates de sortie ...

Il semble être sorti car j'ai pu télécharger le firmwas 2.3.007 décrit dans les notes de version.

Doit avoir été vers janvier https://www.iphone-ticker.de/ikea-home-smart-homekit-und-bridge-update-verfuegbar-152574/

pas un programmeur elle. Je suppose que je ne devrais pas installer r21 sur conbee 2 et attendre? Ceci est un firmware beta?

Légèrement hors sujet: nouveau firmware pour le gradateur Trådfri, mise à niveau vers ZB3. En référence croisée # 2485, nous aurons le même problème pour le gradateur ... Je m'attends à ce que l'ancien capteur de mouvement modèle soit le prochain ...

Et voici la version de test pour ConBee I et RaspBee avec le correctif d'erreur de route.
J'espère que cela apporte des améliorations pour découvrir une nouvelle route lorsque l'erreur se produit.

Pour les tests, je pense que ce serait bien si cela ne fonctionnait que pendant quelques jours / semaines et nous verrons si les lumières cessent toujours de répondre aux monodiffusions. Dans ce cas, essayez si les lumières réagissent toujours aux commandes de groupe ou deviennent complètement silencieuses.

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

Merci, @manup ,

Bien que je pense que cela apportera une amélioration, que pensez-vous du micrologiciel DeConz ignorant les itinéraires enregistrés (en raison du routage crin-à-un)? En général, j'ai vu que les routes enregistrées sont beaucoup plus logiques que celles utilisées par le firmware DeConz.
Bien que je puisse imaginer que l'activation du routage source est un gros travail, le micrologiciel DeConz pourrait (devrait?) Toujours utiliser les informations du paquet d'enregistrement d'itinéraire pour mettre à jour le premier saut vers un périphérique. Peut-être simplement vérifier si le dernier saut vers le coordinateur correspond à ce qui est stocké dans la table de routage et sinon, invalider l'entrée dans la table de routage. Je ne sais pas s'il est correct de remplacer l'entrée par le dernier saut de la route enregistrée, car les périphériques en cours de route ignorent probablement les informations, mais au moins cela pourrait initier une nouvelle découverte de route pour ce nœud par le micrologiciel DeConz.

Que penses-tu de cela?

J'ai installé le firmware sur mon raspbee (j'ai 73 nœuds pour la plupart ikea), je rendrai compte des résultats.

En effet les numéros de séquence ne doivent pas être égaux dans ce court laps de temps, je vais vérifier le code, il semble qu'un incrément manque.

@manup , Peut-être pour vous aider à identifier le problème, j'ai revu ce problème aujourd'hui. Cela semble être lié à 2 configurer des actions de reporting très proches les unes des autres. La deuxième seq: 183 dans ce cas est différente de celle que j'ai rapportée auparavant.

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

Le problème du numéro de séquence devrait être résolu dans la version 2.05.74, qui est en cours de construction et sera disponible dans quelques heures.

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

Et voici la version de test pour ConBee I et RaspBee avec le correctif d'erreur de route.
J'espère que cela apporte des améliorations pour découvrir une nouvelle route lorsque l'erreur se produit.
Pour les tests, je pense que ce serait bien si cela ne fonctionnait que pendant quelques jours / semaines et nous verrons si les lumières cessent toujours de répondre aux monodiffusions. Dans ce cas, essayez si les lumières réagissent toujours aux commandes de groupe ou deviennent complètement silencieuses.
http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26340500.bin.GCF

Merci, @manup ,

Bien que je pense que cela apportera une amélioration, que pensez-vous du micrologiciel DeConz ignorant les itinéraires enregistrés (en raison du routage crin-à-un)? En général, j'ai vu que les routes enregistrées sont beaucoup plus logiques que celles utilisées par le firmware DeConz.
Bien que je puisse imaginer que l'activation du routage source est un gros travail, le micrologiciel DeConz pourrait (devrait?) Toujours utiliser les informations du paquet d'enregistrement d'itinéraire pour mettre à jour le premier saut vers un périphérique. Peut-être simplement vérifier si le dernier saut vers le coordinateur correspond à ce qui est stocké dans la table de routage et sinon, invalider l'entrée dans la table de routage. Je ne sais pas s'il est correct de remplacer l'entrée par le dernier saut de la route enregistrée, car les périphériques en cours de route ignorent probablement les informations, mais au moins cela pourrait initier une nouvelle découverte de route pour ce nœud par le micrologiciel DeConz.

Que penses-tu de cela?

Hmm étrange, le firmware devrait déjà utiliser ces enregistrements de route pour établir de nouvelles routes, il faut vérifier le code ici, mais si ma mémoire me répond correctement, cela a été activé il y a quelque temps.

Que penses-tu de cela?

Hmm étrange, le firmware devrait déjà utiliser ces enregistrements de route pour établir de nouvelles routes, il faut vérifier le code ici, mais si ma mémoire me répond correctement, cela a été activé il y a quelque temps.

Eh bien, j'ai eu ce genre de choses avec Zolder et Garage (à partir d'un certain nombre de messages) et j'ai eu ce comportement:

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

L'enregistrement de l'itinéraire montrait:

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

La prochaine communication de DeConz à Garage fait:

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

Donc, il ne prend clairement pas en charge les enregistrements d'itinéraire.

Ce que j'ai remarqué à ce moment-là, c'est que dès que j'ai mis Zolder hors tension, DeConz était immédiatement capable de trouver une nouvelle route. Alors peut-être que certaines des tables liées au routage sont pleines dans le firmware DeConz. Cela pourrait-il être vrai? Quelle est la taille des tables voisines / de routage dans le firmware? Un tableau complet pourrait-il bloquer l'adoption de nouveaux enregistrements d'itinéraire?

Succès! Je peux confirmer que le comportement est maintenant qu'après un échec de liaison non-arborescente, la découverte d'itinéraire commence effectivement.

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

Le problème du numéro de séquence devrait être résolu dans la version 2.05.74, qui est en cours de construction et sera disponible dans quelques heures.

33d8a8b

"swversion": "2.5.74",

: smile: Merci @manup excellent temps de réponse: 1st_place_medal:

Veuillez attendre la mise à jour vers 2.05.74 ou utilisez http://phoscon.de/app pour afficher l'application Phoscon. Nous venons de voir qu'une page de passerelle hors ligne est affichée sur certaines pages là où elle ne devrait pas, se reconstruisant maintenant ~ 2 heures.

En effet les numéros de séquence ne doivent pas être égaux dans ce court laps de temps, je vais vérifier le code, il semble qu'un incrément manque.

Voici le premier firmware de test pour ConBee II

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

Le portage de ce nouveau dans le micrologiciel ConBee I / RaspBee sera bientôt en ligne.

Ce FW ne fonctionne pas pour moi. Il montre tous mes appareils comme joints, mais aucun maillage n'est construit. Ni les connexions ne sont affichées dans l'interface graphique, ni aucune commutation depuis Phoscon n'a fonctionné (2.05.74). Flashed le Conbee II à 264A0700 et tout fonctionne à nouveau comme prévu ...

Hmm étrange combien de temps a-t-il duré?
J'exécute ce firmware sur plusieurs configurations maintenant sans problèmes jusqu'à présent.

Hmm étrange combien de temps a-t-il duré?
J'exécute ce firmware sur plusieurs configurations maintenant sans problèmes jusqu'à présent.

Quelques minutes. J'ai vu des activités sur certains appareils (points bleus) mais pas de création de liens. Et la commutation ne fonctionnait pas du tout. Dois-je tester plus longtemps?

La construction du maillage peut prendre un certain temps, mais vous devriez voir des lignes après 5 à 10 minutes.

Ce FW ne fonctionne pas pour moi.

Idem ici, Rasperry Pi 4B, deCONZ 2.05.74, ConBee II. Petit réseau de test avec répéteur Trådri, prise Trådfri, XBee, variateur Trådfri, 2 détecteurs de mouvement Trådfri (anciens et nouveaux) et interrupteur marche / arrêt Trådri. La passerelle ne semble pas envoyer ni recevoir de trafic depuis aucun appareil. Voir USB se déconnecte dans le syslog. Tout est à nouveau hunky dory, après être revenu à 4A.
log.gz

Juste flashé à nouveau pour tester:

• pas de lignes dans l'interface graphique (laissez-le fonctionner pendant 15 minutes)
• La connexion USB semble stable
• Les commutateurs UBISYS C4 et D1 fonctionnent toujours
• Les boutons Tradfri ne le font pas

@ebaauw le journal montre que le coordinateur ne voit que deux voisins avec cette version.

C'est peut-être la taille du réseau. Je n'ai actuellement que 40 appareils alimentés ici. Cette version du micrologiciel a deux autres changements qui pourraient en être la cause, une augmentation de la taille du tampon de messages (un peu au-dessus pour autant que je sache, cela réduira à nouveau) et un réglage de puissance TX légèrement inférieur.

Je préparerai une autre version avec ces paramètres supprimés pour voir si cela fonctionne mieux.

Utilisez-vous un câble d'extension USB ou le ConBee II est-il connecté directement?

Pour moi, cela fonctionne bien sur Raspbee ...

Sur le RaspBee et le ConBee 1, seul le correctif Route est inclus dans la nouvelle version (firmware différent).

le journal montre que le coordinateur ne voit que deux voisins avec cette version.

Oui, deux des périphériques finaux sont affichés comme voisins dans l'interface graphique. Un peu étrange, car ils se sont montrés connectés à un autre routeur après avoir rétrogradé le micrologiciel ConBee II.

Utilisez-vous un câble d'extension USB ou le ConBee II est-il connecté directement?

Il est directement connecté depuis que je l'ai. Vers un port USB-2 sur le Pi, avec le XBee connecté à l'autre port USB-2; rien sur USB-3. La connexion a été stable, sauf lorsque j'ai configuré le ConBee II en tant que routeur (voir # 2463).

Sur le RaspBee et le ConBee 1, seul le correctif Route est inclus dans la nouvelle version (firmware différent).

Je n'ai pas encore essayé cela. Devra attendre plus tard ...

Je vois pas mal de paquets de rapports configurés. Après quelques recherches, il semble que ceux-ci soient envoyés périodiquement environ toutes les demi-heures. Quelle est la raison pour laquelle ces demandes de rapports de configuration sont répétées périodiquement?
@ebaauw , est-ce que je me souviens bien que vous avez fait beaucoup de ces enquêtes sur le comportement du coordinateur IKEA? Le fait-il aussi?

J'ai remarqué dans de_web_plugin_private.h

#define IDLE_ATTR_REPORT_BIND_LIMIT 1800

J'ai trouvé une autre preuve concernant le comportement de routage de DeConz en ignorant les enregistrements de route plusieurs-à-un. Cela oblige certains routeurs à déterminer le routage à la manière «à l'ancienne».
(notez que j'ai des interférences diaboliques dans le paquet 117130: wink :)

L'itinéraire pour badkamer ledstrip , selon DeConz, commence par le On/Off light 36 qui ne sait évidemment pas comment y arriver. Il commence donc une découverte d'itinéraire et trouve finalement qu'il peut (à peine, je pense) atteindre le ledstrip lui-même. Le chemin de retour passe par Gang 1

Il semble que On/Off light 36 oublie environ Badkamer ledstrip chaque fois qu'une demande de route plusieurs-à-un est traitée ...

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

prochaine communication:

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

Un autre essai du micrologiciel ConBee II:

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

Cette version a les paramètres d'alimentation TX de 0x264a0700. Les tampons sont toujours volumineux (mais selon la carte, ils devraient bien s'intégrer dans la RAM) pour ne vérifier qu'une seule chose à la fois.

J'ai cette erreur, chaque fois que j'essaye de mettre à jour le dernier firmware. Des indices pourquoi?
rich710 @ RichHassPc01 : ~ $ sudo GCFFlasher_internal -d / dev / ttyACM1 -f deCONZ_ConBeeII_0x26530700.bin.GCF
GCFFlasher V3_13 (C) Dresde Elektronik Ingenieurtechnik GmbH
Redémarrez le périphérique / dev / ttyACM1 (ConBee II)
Version du micrologiciel deCONZ 26490700
Chargeur de démarrage R21B18
Vers: 2.05
construction: 22 mars 2019
clignotant 161378 octets: | ============================== |
Vérifier: .
Échec de la mise à jour Flash, CRC non valide. Veuillez réessayer.
rich710 @ RichHassPc01 : ~ $

Avez-vous vérifié la somme MD5 du fichier téléchargé? (http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26530700.bin.GCF.md5)

Oui, j'ai vérifié et téléchargé plusieurs fois, même essayé de revenir à l'ancien firmware, et cela s'est bien passé, jusqu'à présent. Maintenant, je suis coincé avec cette erreur, j'ai redémarré mon NUC plusieurs fois mais je suis toujours bloqué lorsque le flasher tente de redémarrer mon ConbeeII.
rich710 @ RichHassPc01 : ~ $ sudo GCFFlasher_internal -d / dev / ttyACM1 -f deCONZ_ConBeeII_0x26490700.bin.GCF
[sudo] mot de passe pour rich710:
GCFFlasher V3_13 (C) Dresde Elektronik Ingenieurtechnik GmbH
Redémarrez le périphérique / dev / ttyACM1 (ConBee II)

2139: Erreur: la réinitialisation d'uart a échoué, vérifiez réessayer

Vous avez remarqué que vous utilisez ttyACM1, lorsque vous utilisez

GCFFlasher -l

Il affichera le numéro de série.
Vous pouvez l'utiliser pour fournir un nom de périphérique plus stable dans la commande.

GCFFlasher_internal -sn DE1948474 -f deCONZ_ConBeeII_0x26530700.bin.GCF

(remplacez-le par le numéro de série de votre appareil)

Désolé n'a pas fonctionné, je devrais peut-être le déplacer sur ma machine Windows et essayer
rich710 @ RichHassPc01 : ~ $ GCFFlasher_internal -l
GCFFlasher V3_13 (C) Dresde Elektronik Ingenieurtechnik GmbH
Chemin | Fournisseur | Produit | Série | Type
----------------- + -------- + --------- + ------------ + -------
/ dev / ttyACM1 | 0x1CF1 | 0x0030 | DE1964163 | ConBee II
/ dev / ttyUSB0 | 0x0403 | 0x6001 | A1YV35M2 | FTDI générique
rich710 @ RichHassPc01 : ~ $ GCFFlasher_internal -sn DE1964163 -f deCONZ_ConBeeII_0x26530700.bin.GCF
GCFFlasher V3_13 (C) Dresde Elektronik Ingenieurtechnik GmbH
Redémarrer l'appareil (ConBee II)

2139: Erreur: la réinitialisation d'uart a échoué, vérifiez réessayer
rich710 @ RichHassPc01 : ~ $

Soit cela, soit comme alternative, vous pouvez essayer de suivre:

• Débranchez le ConBee II
• GCFFlasher_internal -t 60 -sn DE1964163 -f deCONZ_ConBeeII_0x26530700.bin.GCF
• Branchez à nouveau le ConBee II

Les paramètres -t permettent au GCFFlasher d'essayer pendant une minute de traiter la mise à jour.

Cela a fonctionné pour mettre à jour le micrologiciel dans Windows, et quand je l'ai branché à mon NUC avec ubuntu, il s'est à nouveau connecté. MAIS, après une heure maintenant, il vient de se connecter à 4 de mes nœuds ..: S

Un autre essai sur le micrologiciel ConBee II: http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26530700.bin.GCF

Plus de déconnexion USB, mais deCONZ semble re-détecter le ConBee II assez souvent. Toujours pas de trafic.
log.gz

EDIT Pour vous faire plaisir, j'ai débranché le XBee et utilisé un câble d'extension USB de 10cm pour connecter le ConBee II: pas de changement.

Un autre essai du micrologiciel ConBee II:

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

Cette version a les paramètres d'alimentation TX de 0x264a0700. Les tampons sont toujours volumineux (mais selon la carte, ils devraient bien s'intégrer dans la RAM) pour ne vérifier qu'une seule chose à la fois.

Vous avez testé votre nouvelle version, mais après 10 minutes il n'y a toujours pas de lien affiché ... Avec le FW stable, tous les bons liens (routeur) du réseau sont affichés après environ 2 minutes. Le bouton poussoir IKEA fonctionne immédiatement, alors qu'avec le firmware de test, il ne fonctionne pas du tout.

Hmm spooky, merci d'avoir testé cela. Ensuite, je vais essayer de réduire les tailles de tampon comme mentionné précédemment.
Je me demande toujours pourquoi cela fonctionne sur ma configuration. D'après la capture d'écran ci-dessus, je peux seulement dire que j'ai plus de périphériques finaux que de routeurs.

@manup a eu les mêmes problèmes après avoir flashé le firmware, mais en appuyant sur le redémarrage du périphérique dans deconz / redémarrer deconz, les liens sont revenus.

Et voici la version de test pour ConBee I et RaspBee avec le correctif d'erreur de route.

Semble bien fonctionner sur mon système de test Pi 3B +. J'attendrai ce week-end avant de mettre à niveau mon réseau de production.

@ebaauw , est-ce que je me souviens bien que vous avez fait beaucoup de ces enquêtes sur le comportement du coordinateur IKEA? Le fait-il aussi?

J'ai ajouté la prise en charge de la plupart des appareils Trådfri, mais je n'ai pas été en mesure de détecter le trafic ZigBee vers / depuis le hub Trådfri. Il n'utilise que le couplage tactile, et je n'ai pas encore essayé de capturer cela pour récupérer la clé réseau. Autrement dit, en supposant que ce soit possible du tout.

J'utilise le nouveau FW sur le stick conbee 1 dans ma configuration de ~ 40 nœuds depuis la sortie du nouveau firmware et cela fonctionne très bien sans aucun problème! (Sur la photo, les nœuds non connectés sont soit hors batterie, soit non alimentés)

Merci à toutes les personnes impliquées qui ont dépanné et mis à jour le code. C'est tellement apprécié! <3

Ne travaille pas pour moi. Presque pas de connexions dans le réseau. Ont attendu environ 20 minutes après le redémarrage.

Raspberry Pi 3 modèle B Rev 1.2
Conbee II
version 2.05.74
version 26530700

77 nœuds

3 Connexion à
1 interrupteur marche / arrêt TRÅDFRI
1 capteur multi Xiaomi
1 variateur Philips
Je suis capable de déclencher des événements à partir du variateur philips.
Ceux qui ont des connexions sont assez proches du stick Conbee. Le bâton est situé dans le garage. J'ai des ampoules dans le garage qui n'ont pas de connexions.

Pas de connexion avec
Beaucoup d'ampoules ikea, à la fois E27 et GU10
Beaucoup de multi-capteurs Xiaomi
Beaucoup de télécommande Ikea TRÅDFRI
Et d'autres nœuds.

Journaux
27 fév 09:29:06 raspberrypi systemd [1]: Démarré deCONZ: passerelle ZigBee - GUI / API REST.
27 févr 09:29:06 raspberrypi deCONZ [7204]: avertissement libEGL: DRI2: échec de l'authentification
27 fév 09:29:06 raspberrypi deCONZ [7204]: avertissement libpng: iCCP: profil sRGB incorrect connu

Lors de la rétrogradation vers 264A0700, il commence à créer directement le maillage.

@ebaauw , est-ce que je me souviens bien que vous avez fait beaucoup de ces enquêtes sur le comportement du coordinateur IKEA? Le fait-il aussi?

J'ai ajouté la prise en charge de la plupart des appareils Trådfri, mais je n'ai pas été en mesure de détecter le trafic ZigBee vers / depuis le hub Trådfri. Il n'utilise que le couplage tactile, et je n'ai pas encore essayé de capturer cela pour récupérer la clé réseau. Autrement dit, en supposant que ce soit possible du tout.

Bon, désolé. Doit avoir vérifié git blame. Le code qui mentionne le comportement de la passerelle IKEA a en fait été introduit dans 48d2c39a267b5c6d025577eed7530be27932aa2c par @manup ...

@manup , avez-vous effectivement identifié que la passerelle IKEA reconfigure l'attribut signalant si souvent? Pourquoi une reconfiguration serait-elle nécessaire? la lumière doit-elle être rappelée régulièrement?

Mise à niveau de Conbee I vers la version bêta FW et deCONZ .74

Le maillage se construit immédiatement et a l'air vraiment joli!

Un grand merci à @djwlindenaar . Je suis extrêmement impressionné que vous veniez de nulle part et que vous trouviez des bugs aussi graves. Et merci également à @manup de les avoir

Conbee I et .74, aussi. Mise à niveau d'Ikea ​​FW à 2.3.007 (quelques autres 2.x).
Amélioration majeure! Pas encore d'abandons!

Un grand merci à tous ceux qui contribuent, développent, déboguent, testent dans ce fil et au-delà.

Quelque chose que j'ai découvert au cours du processus:
Le groupe normal ON-OFF fonctionne - rapidement, mais après avoir rappelé une scène (après un fondu dans le temps) et l'avoir à nouveau éteinte (<10sec), les lumières ne s'éteignent que dans l'interface graphique (quelle que soit l'ancienne ou la nouvelle interface graphique) Ensuite, certaines d'entre elles se rallument (dans l'interface graphique) dans le groupe pendant que TOUTES les ampoules physiques restent allumées. Après avoir appuyé une deuxième ou troisième fois sur OFF, ils s'assombrissent parfois.

Il n'est pas rare de restaurer / reconstruire des scènes après une mise à niveau du firmware
Mais que je construise une nouvelle scène ou que j'essaie de réparer une plus ancienne, le comportement reste le même. La marche / arrêt normale n'est pas affectée.

J'ai découvert que ça marche comme d'habitude quand j'attends un peu plus longtemps. Disons 15-20 secondes. Puis les lumières s'éteignent comme d'habitude. Je suppose que deconz est confus comme il le fait lorsque vous éteignez une lumière jusqu'à ce qu'elle disparaisse.

Il semble que nous ayons eu une augmentation du délai jusqu'à ce que chaque état lumineux soit signalé et que le rappel de scène soit effectué en déconz ou signalé avec succès, de sorte que d'autres actions de ce groupe fonctionnent comme souhaité. Cela semble prendre un peu plus de temps maintenant. Pendant cette période - vous ne devez pas (passer;)) - éteindre les lumières. Ce n'est pas critique.

J'ai testé un peu plus loin. Nous avons un changement de comportement. Auparavant, lorsqu'un bri était modifié avec une vitesse donnée, ou qu'une scène avait un temps de transition plus long, il était possible d'interrompre avec une nouvelle commande. Même l'action précédente était toujours exécutée, la commande suivante était mise en file d'attente. Maintenant c'est perdu. Les lampadaires Egmy fonctionnent avec un détecteur de mouvement. Avant qu'ils ne disparaissent, je les atténue et j'attends 10 secondes avant de les éteindre. Lorsque j'ai déclenché un mouvement et rappelé la scène pendant qu'il s'estompe, la commande est perdue. Avant cela, il était mis en file d'attente et exécuté par la suite. Est-ce dû à. 74 ou le nouveau firmware? Merci

Mon Conbee II n'a pas construit de maillage sur la version bêta. La seule chose à laquelle je peux penser qui pourrait être différente des paramètres "normaux" est de régler le canal sur 25. Revenir à 264a0700 l'a corrigé

@realwax , je pense que vous rencontrez un bug du firmware Trådfri, voir # 2068. Vous pouvez facilement le vérifier en émettant une commande avec un temps de transition plus long dans l'interface graphique, puis en émettant une deuxième commande.

Avant cela, il était mis en file d'attente et exécuté par la suite.

Avez-vous mis à jour le micrologiciel léger? Êtes-vous sûr d'utiliser la même lumière? Le plugin REST API ne garde pas trace du temps de transition une fois qu'il a envoyé une commande à la lumière.

@ebaauw Merci de m'avoir conduit dans la bonne direction. Comme IKEA a déclaré d'inclure des améliorations de réseau et de stabilité dans leur journal de diffusion, je mets à niveau ma TRÅDFRI Lampe E14 WS opal 400lm vers le firmware 2.3.007 (dernier). J'ai pensé que cela pourrait atténuer certains de ces problèmes. Je me demande comment IKEA fait l'affaire sur son propre pont, car c'est un gros problème de convivialité. Je dois maintenant opter pour des temps de transition plus rapides, comme vous l'avez indiqué dans l'autre numéro. J'en fais l'expérience depuis le premier jour mais ça a empiré. Maintenant, cela n'affecte pas seulement les fondus de rappel de scène, il affecte tout changement avec une transition plus longue et c'est nouveau ... Que puis-je faire? Revenir à l'ancienne fw est presque impossible, car c'est une lutte avec deconz. Merci Erik.

Je me demande comment IKEA fait l'affaire sur son propre pont, car c'est un gros problème de convivialité.

Le hub de Trådfri est beaucoup moins actif que la passerelle deCONZ ou le pont Hue. Les contrôleurs Trådfri (interrupteurs, variateurs, mais aussi leurs détecteurs de mouvement) contrôlent directement les lumières. Les lumières Trådfri envoient des notifications push au hub avec des changements d'état. Le hub n'est nécessaire / utilisé que pour leur application. Il peut exécuter des alarmes, mais pas de règles pour gérer les événements de bouton ou quoi que ce soit de fantaisie.

Je ne sais pas si l'application Trådfri prend même en charge la spécification de temps de transition plus longs, mais les contrôleurs que j'ai vus ne le font pas. Vous ne pourrez probablement pas envoyer les commandes des contrôleurs plus rapidement que le temps de transition par défaut des lumières. Et si vous le faites à l'occasion, vous pensez probablement que vous n'avez pas complètement appuyé sur le bouton.

@ebaauw je vois. Ce qui me laisse encore perplexe, c'est le fait que je peux allumer et éteindre un groupe d'E14 (fournissant une sorte de disco léger;)) en 1 seconde (marche-arrêt-marche) ça marche! Mais dès que j'appuie sur un bouton de rappel de scène dans deconz, je ne peux pas et le comportement devient bizarre. C'est là que je doute que ce soit la faute des IKEA. Pourquoi puis-je allumer et éteindre très rapidement, mais dès que je me souviens d'une scène, je suis bloqué au moins pendant 5 à 10 secondes?

Temps mesurés avec précision (20 essais):
groupe de 8 E14
groupe ON -> groupe OFF - temps de commutation 1 seconde
rappeler la scène -> allumer -> OFF ne répond pas avant 10-12 secondes!

Je comprends qu'avec un rappel, plus de trafic est généré et chaque ampoule reçoit plus de messages, mais une différence de 10 secondes? Même quand je change de bri et de côté pour tout un groupe, je peux l'éteindre en une seconde mais encore une fois, un rappel est comme un gel. Je pense que cela semble être un problème de deconz, n'est-ce pas?

Je peux l'enregistrer en vidéo. ;) Peut-être que je manque de connaissances ici, alors excusez-moi de présenter mon manque de compréhension mais je suis en quelque sorte frustré car c'est une lutte ...

J'ai peur d'être encore un peu confus au sujet des scènes. Comme les groupes, ils n'existent pas en tant qu'objet dans ZigBee, ce sont juste un nombre sous lequel un appareil (lumière) stocke un état. Lors d'un rappel de scène, le numéro est transmis et chaque appareil restaure l'état à partir de sa mémoire non volatile.

La partie floue est que tous les appareils ne semblent pas stocker correctement leur état lors du stockage de la scène: la température de couleur est notoire à cet égard. J'ai aussi vu des trucs amusants stockant la scène alors que la lumière est encore en transition. Dans ce cas, la ressource /scenes n'est pas synchronisée avec l'état stocké sur la lumière, ce qui oblige l'API à refléter l'état de la ressource au lieu de l'état réel de la lumière, qui ne sera mis à jour que la prochaine fois que la lumière est interrogé. Généralement, le temps de transition est spécifié lors du rappel de la scène, mais il semblerait qu'il soit également dans l'état stocké.

J'ai scénarisé la configuration de mon réseau de production (en utilisant ph ), afin que je puisse le recréer facilement. J'ai eu beaucoup de mal à scénariser la création de scènes de manière prévisible. J'ai fini par définir les états de lumière, dormir pendant quelques secondes, attendre que les états se règlent, stocker la scène et dormir à nouveau quelques secondes, en attendant que l'état soit stocké.

Vous pourriez essayer de recréer votre scène, mais aucune garantie ...

J'ai pu reproduire le sujet désynchronisé dès le premier jour. J'avais l'habitude de déconfigurer et de devoir reconfigurer les scènes de temps en temps. Maintenant c'est vraiment pire. Actuellement, je devrais me procurer de deconz à iobroker et reconstruire toutes mes scènes là-bas. Mais c'est beaucoup de travail. Espérons que cela soit corrigé. Puis-je créer un problème? Les lumières ne sont plus fiables lors de l'utilisation de scènes ... - J'essaye de recréer aussi. J'ai fait une scène "test" hier en plus de celles déjà existantes mais elle n'a montré aucun autre comportement.

Je ne sais pas si cela est lié, mais après la mise à niveau de mon Conbee I vers le micrologiciel bêta et deCONZ vers 0,74, il a fallu un jour et maintenant deCONZ a perdu la connexion au Conbee. Jamais vécu cela depuis des années ... Mais je voulais le mentionner ... Le journal vient d'indiquer des tentatives pour se connecter encore et encore ... Le redémarrage de deCONZ a résolu le problème ... (en utilisant le conteneur docker)

J'ai juste essayé de recréer un groupe, toutes les scènes ... Dans le processus de création, il y a tellement de problèmes. Lors de l'utilisation de Phoscon et de la sélection d'ampoules "TOUTES", les valeurs des scènes ne sont pas stockées correctement. Même les voyants configurés indiquent ce que vous souhaitez, un rappel ne le fait pas. Vous devez contrôler chaque lumière seule, même lorsque vous choisissez les mêmes paramètres. En particulier, l'ancienne interface graphique doit être utilisée pour corriger les erreurs de température de couleur des couleurs mal stockées. Jusqu'à ce qu'une scène "fonctionne", vous devez recommencer plusieurs fois, peut-être allumer et éteindre les lumières pendant le processus de configuration de la scène pour qu'elle soit stockée correctement. Je n'ai pas beaucoup de détails techniques ici mais je veux vous encourager tous dans le fil à tester des scènes, créer, stocker, rappeler et éteindre après un rappel. Je pense que c'est foiré avec les ampoules IKEA et que ça empire ... Peut-être que c'est avec IKEA mais je doute que tout le reste et le contrôle de groupe direct fonctionnent comme un charme avec deconz.

Je vais maintenant restaurer / rétrograder le firmware à 1.x et voir si cela fonctionne mieux. Je ferai rapport.

D'ACCORD. Retour à la planche à dessin. Hier, 2 lampes IKEA ont pris un congé, pour revenir après un cycle d'alimentation. Ne pas dire que les bogues corrigés n'étaient pas des bogues. Ils étaient. Mais pas ceux qui causent le problème.

J'examinais de plus près la question des rapports d'attributs. Je me demandais si la configuration répétitive du rapport d'attribut toutes les 30 minutes (1800s) provoquait les blocages du micrologiciel léger.
J'ai remarqué ce bout de code qui ne semble pas gérer explicitement rq.maxinterval == 0 . Maintenant, comment gérer correctement ce cas est un peu difficile, car rq.maxinterval == 0 signifie que la lumière ne signalera qu'un changement, donc il n'y a pas de `` bon '' délai pour ce cas ... Peut-être que l'implémentation actuelle est bonne, bien que Je me demande si une meilleure idée peut exister.

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

N ° Heure Source Transmit Dev Receive Dev Destination Désactiver les informations de réponse par défaut
208134 10h 43m 23.151s Gang 1 Gang 1 DeConz DeConz False ZCL: Attributs de rapport, 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: Réponse par défaut, 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.

N ° Heure Source Transmit Dev Receive Dev Destination Désactiver les informations de réponse par défaut
207941 10h 43m 8,422 DeConz DeConz Gang 1 Gang 1 True ZCL: Configurer le rapport, Seq: 41
207949 10h 43m 8.481 Gang 1 Gang 1 DeConz DeConz False ZCL: Configurer la réponse de rapport, Seq: 41
207951 10 h 43 min 8,485 Groupe 1 Groupe 1 DeConz DeConz APS: Ack, Dst Fin: 1, Src Fin: 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 Fin: 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())

J'ai remarqué ce bout de code qui ne semble pas gérer explicitement rq.maxinterval == 0. Maintenant, comment gérer correctement ce cas est un peu difficile, car rq.maxinterval == 0 signifie que la lumière ne signalera qu'un changement, donc il n'y a pas de `` bon '' délai pour ce cas ... Peut-être que l'implémentation actuelle est bonne, bien Je me demande si une meilleure idée peut exister.

Oui, le plug-in de l'API REST vérifie que le rapport d'attribut fonctionne. Sinon, il essaie de le reconfigurer, et je pense qu'il revient également à interroger l'appareil.

J'ai fait quelques expériences, notamment en demandant aux lumières IKEA de signaler ONOFF et LEVEL périodiquement au lieu de seulement quand un changement est effectué. Les lumières rapportent volontiers leur état périodiquement, ce qui peut être un moyen acceptable d'éviter le problème ci-dessus. A vérifier correctement bien sûr.

Je pense que nous avons fonctionné avec ce paramètre pendant un certain temps. Il a été changé, avec une interrogation moins fréquente des tables voisines et ne plus interroger l'état, car une partie du firmware Trådfri se bloquait (nécessitant un cycle d'alimentation de la lumière). Je doute que le paramètre de rapport ait réellement contribué au crash du firmware.

Il y a un élément dans le paquet ZCL qui dicte s'il doit ou non être envoyé Disable Default Response .

Je ne pense pas que l'envoi de la réponse par défaut ferait tant de mal, lorsque Disable Default Response bit est défini. Le fait de ne pas envoyer la réponse par défaut lorsque le bit n'est pas défini fera du tort, car le périphérique qui attend la réponse pourrait conclure que le coordinateur n'est plus joignable et éventuellement quitter le réseau.

Il y a un élément dans le paquet ZCL qui dicte s'il doit ou non être envoyé Disable Default Response .

Je ne pense pas que l'envoi de la réponse par défaut ferait tant de mal, lorsque Disable Default Response bit est défini. Le fait de ne pas envoyer la réponse par défaut lorsque le bit n'est pas défini fera du tort, car le périphérique qui attend la réponse pourrait conclure que le coordinateur n'est plus joignable et éventuellement quitter le réseau.

@ebaauw , en effet. C'est exactement le but. deCONZ ne parvient pas à envoyer un Default Response en réponse à un Configure Reporting Response . Il arrive que les luminaires IKEA demandent un Default Response pour Configure Reporting Response .
Donc, comme vous le dites, c'est peut-être la raison, associée aux Configure Reporting Request toutes les demi-heures, pour que les lumières IKEA fonctionnent.

Juste un rappel:
Les ampoules Ikea (E27 et GU10 v1) deviennent parfois inaccessibles et nécessitent également un cycle d'alimentation lorsqu'elles sont connectées à un pont HUE, de sorte que ce problème particulier n'est pas unique au Conbee I / II
Sur 16 E27 et 12 GU10 sur mon pont HUE, je dirais qu'une ampoule «se bloque» toutes les 1-2 semaines, environ. Parfois plus long, parfois plus rapide. Ce problème s'est amélioré avec les dernières versions du micrologiciel HUE au cours de la dernière année et demie.

@all Quelle version du firmware Tradfri utilisez-vous?

Êtes-vous sur 1.x ou 2.x? Avec le 2.x, ils ont introduit zigbee 3.0. Je suis passé à 2.x et les problèmes ont commencé. Ampoules E14. J'ai remarqué des améliorations concernant la vitesse et la connectivité du réseau. Mais deux choses m'ont fait reculer 20 ampoules soupir Le "soft on" ne fonctionnait plus. Les ampoules se sont allumées sans fondu. Les scènes ne fonctionnaient plus comme avant. En parlant précisément après avoir rappelé une scène, un temps d'attente avant d'éteindre la lumière ou de rappeler le szene suivant était nécessaire, sinon deconz s'est asynchrone et s'est resynchronisé alors que l'ampoule ne faisait rien.

J'apprécie votre expérience partagée avec les versions et déconz «parfait» avec 2.x cela ne semble pas donné.

Y a-t-il une recommandation? FW v.? Outre le problème de connexion perdue et les problèmes de connexion sur le fw d'Ikea ​​lui-même, il semble que deconz puisse mieux gérer 1.x.

Merci!

J'utilise:

• Conbee 1 avec firmware 0x26340500
• Deconz version 2.05.73 (en utilisant le conteneur docker marthoc sur Debian)
• ~ 60 nœuds, principalement IKEA Trådfri
• Conbee 1 (coordinateur) n'est PAS installé au centre de ma maison de 200 mètres carrés. Le système repose fortement sur l'itinérance et le maillage.
• La clé Conbee 1 est installée sur un câble d'extension USB de 0,5 mètre et montée sur le côté de l'étagère où réside l'ordinateur pour avoir plus d'espace libre pour les signaux RF.

Depuis la mise à jour (le jour même de la sortie) du firmware des sticks Conbee 1, deconz fonctionne comme un charme ! Aucun problème quoi que ce soit.

J'ai mis à jour mon réseau de production (RPi 3B +, stretch, RaspBee) à 2.05.74 et 0x26340500 hier. Semble stable, sauf pour les problèmes ci-dessous.

Je ne sais pas si c'est lié, mais l'itinéraire vers mon contrôleur de rideau lumi.curtain été perdu ce matin. Les rapports du contrôleur atteindraient toujours la passerelle. L'itinéraire ne serait pas restauré lors du redémarrage du contrôleur. J'ai dû ouvrir le réseau et redémarrer le contrôleur avant que le coordinateur ne l'atteigne à nouveau.

De plus, une de mes vannes de radiateur Eurotronic Spirit était inaccessible par deCONZ après le démarrage de deCONZ, tout en envoyant des rapports. Le cycle d'alimentation du TRV l'a ramené, comme d'habitude.

Je n'ai pas eu l'occasion de faire une enquête approfondie cette fois, mais les deux appareils ont posé problème dès le début, présentant ces symptômes de temps en temps. Idem pour mon store IKEA Fyrtur. Je continuerai à surveiller la situation et à faire un rapport si je rencontre d'autres problèmes.

@tubalainen
Quel firmware utilisez-vous sur vos ampoules tradfri? Cela fait une différence même dans ce fil en ce qui concerne le problème de connexion perdue dans la mesure où j'ai testé. Mes résultats sont que les mesures prises ici ont amélioré le fonctionnement des ampoules tradfri 1.x sur Conbee 1. Mais un réseau de 20 e14 avec tradfri fw 2.3.x est un gâchis. Timings, scènes bloquées, déconz, la lumière commence à clignoter (perdue?), .. comme indiqué ci-dessus. Je pense que c'est un point à discuter et à mentionner pour émettre une recommandation claire d'ikea fw à utiliser pour une bonne expérience. Peut-être qu'il y a déjà un article git. Mais d'après mon expérience, ne mettez pas à niveau 😅

Donc de mon point de vue et des heures de test et de clignotement. Merci pour l'amélioration pour ikea fws 1.x! Est-il possible d'atténuer les problèmes actuels lorsque 2.x est utilisé? Sinon, il ne sera pas possible de passer à zigbee 3 avec ikea actuellement. Il semble que le comportement a changé et que leur fonctionnement en déconz doit être adapté. C'est probablement pour @ebaauw de juger ou de gérer?

À votre santé
Passez un bon dimanche 😊

@realwax
J'ai essayé de mettre à niveau FW toutes mes entités vers le dernier FW. Voici ma liste de tous les nœuds (actuellement actifs).

Convenu du désordre avec toutes les «pièces mobiles» en même temps en essayant de déterminer la cause profonde des problèmes.

@tubalainen

Merci pour votre liste.

En regardant en particulier sur les routeurs (ampoules), je vois que vous utilisez 2.3.007 sur vos E14. Pouvez-vous reproduire ma liste de problèmes. https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518
Comme je n'étais pas au courant de la mise à niveau automatique de fw vers 2.3.x, mon réseau était mélangé avec 1.x et 2.x pas très bon. J'ai mis à jour manuellement à 2.3.x et puis ça a empiré. (Réseau plus rapide mais convivialité massive dran et, ampoules clignotantes) Je peux donc recommander si vous rencontrez des ampoules clignotantes sur votre e14 ou "laggyness" sur les scènes rétrogradez-les à 1.2 ... Je serais intéressé à obtenir un "officiel" / déclaration professionnelle de nos développeurs professionnels ici à ce sujet. Je suis à peu près sûr qu'il fut un temps où deconz a été traité de la même manière 1.2 et il a été amélioré. J'ai l'impression que cela doit être fait pour 2.3.x également ou Ikea l'a gâché. Difficile à dire car je ne suis pas profondément dans le code.

@realwax
J'utilise la fonction otau de deconz et son script de mise à jour du firmware pour télécharger les fichiers fw.
Je ne sais pas pourquoi les E14 ne sont pas mis à jour ... huhum.

Comment avez-vous mis à jour / rétrogradé "manuellement" les ampoules?

Bien bien. Tout fonctionne bien et la majorité du routage est effectuée par les E27 avec fw 2.3.x et les pilotes de panneau Jormen et FLOALT.

@tubalainen
Intéressant que vous ne rencontriez pas ces problèmes. C'est peut-être à cause de la taille du maillage. J'ai 23 ampoules de ce 20 e14 sur 2.3.007. J'ai désactivé l'otau automatique car cela gênait mon utilisation avec le nouveau firmware. Via Gui, vous pouvez rétrograder avec le bouton de mise à jour. Choisissez d'abord le firmware approprié, appuyez sur la mise à jour et peut-être à nouveau. État du formulaire suspendu, il passe à -> en file d'attente -> inactif -> démarrer la mise à jour du micrologiciel (pourcentage) Parfois, il se bloque. Parfois, il a besoin d'un redémarrage. Parfois, un power cyle suffit. Parfois, vous devez rapprocher l'ampoule du coordinateur.

Il semble que le comportement a changé et que leur fonctionnement en déconz doit être adapté. C'est probablement pour @ebaauw de juger ou de gérer?

Je ne suis pas sûr de te comprendre. J'ai géré certaines différences entre les micrologiciels ZLL et ZB3 pour les contrôleurs (télécommande Trådfri et gradateur sans fil Trådfri), voir # 2485. Ceci est au niveau APS dans la pile ZigBee et géré par le plugin API REST.

Les problèmes de routage de cette rubrique sont au niveau NWK, qui est géré par le micrologiciel de l'appareil. Comme tout le monde ici, je n'ai pas accès aux sources du firmware. Même si je le faisais, je ne pourrais rien faire, car je ne connais pas les détails des couches NWK et MAC.

@ebaauw
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518
Parlant précisément. J'ai inclus mes résultats avec 20 mailles E14 2.3.007 ici. Certaines fonctionnalités ont disparu et le rappel de scène gâche à peu près tout pendant 10 à 15 secondes dans ce groupe. Je ne sais pas si c'est uniquement lié au firmware ou lié au deconz. C'est ce que je voulais dire par le changement à gérer. Donc, pour le fonctionnement quotidien, je vois 2.3.007 comme impossible. Exemple d'utilisabilité donné: Un simple commutateur de rotation de scènes configuré dans phoscon ne fonctionne plus lorsqu'il n'est pas pressé avec précaution, ce qui signifie après une rotation de scène d'attendre. Alors que dans 1.x, tout est rapide et bien avec 2.3.x, il reste bloqué.

Merci, @manup ,
Bien que je pense que cela apportera une amélioration, que pensez-vous du micrologiciel DeConz ignorant les itinéraires enregistrés (en raison du routage crin-à-un)? En général, j'ai vu que les routes enregistrées sont beaucoup plus logiques que celles utilisées par le firmware DeConz.
Bien que je puisse imaginer que l'activation du routage source est un gros travail, le micrologiciel DeConz pourrait (devrait?) Toujours utiliser les informations du paquet d'enregistrement d'itinéraire pour mettre à jour le premier saut vers un périphérique. Peut-être simplement vérifier si le dernier saut vers le coordinateur correspond à ce qui est stocké dans la table de routage et sinon, invalider l'entrée dans la table de routage. Je ne sais pas s'il est correct de remplacer l'entrée par le dernier saut de la route enregistrée, car les périphériques en cours de route ignorent probablement les informations, mais au moins cela pourrait initier une nouvelle découverte de route pour ce nœud par le micrologiciel DeConz.
Que penses-tu de cela?

Hmm étrange, le firmware devrait déjà utiliser ces enregistrements de route pour établir de nouvelles routes, il faut vérifier le code ici, mais si ma mémoire me répond correctement, cela a été activé il y a quelque temps.

@manup , avez-vous trouvé le temps de regarder ça? Ce matin, j'ai trouvé une situation où j'ai fait du vélo électrique une lumière (IKEA) qui était à 4 sauts du coordinateur. D'une manière ou d'une autre, un routeur intermédiaire (également IKEA) a décidé qu'il ne connaissait plus l'itinéraire vers cette lumière. En fait, je vois la lumière faire son travail avec plaisir dans le routage pour d'autres lumières, rapporter l'état du lien et répondre à Network Address Request de deCONZ. Ce dernier se produit uniquement parce que ce sont des messages diffusés sur le réseau ..!
Cependant, le routeur entre les deux abandonne silencieusement toutes les trames de monodiffusion qu'il devrait acheminer vers cette lumière. Ce routeur ne devrait bien sûr pas les abandonner silencieusement, alors encore une fois, deCONZ devrait être robuste contre ce mauvais comportement.
En attendant, la lumière envoie également des messages d'enregistrement d'itinéraire à deCONZ, qui arrivent et sont ignorés par deCONZ.

Je pense qu'il devrait y avoir une logique qui devrait inciter deCONZ à reconsidérer ses routes dans ce cas. Surtout quand il détecte que les requêtes ZCL ne reçoivent pas de réponse. Ce qui à la fin conduit la lumière à être marquée comme zombie. La découverte qui suit le marquage en tant que zombie conduit en fait à une réponse du ligtht. Peut-être que lorsqu'une découverte pour un zombie est lancée, elle devrait également invalider les informations de route disponibles. Mais mieux encore, si déjà plus tôt la route est invalidée lorsque quelques requêtes ZCL ne reçoivent pas de réponse (probablement déjà sur la première ou la deuxième de celles-ci).

Que penses-tu de cela?

Ce nouveau firmware n'a pas résolu mon problème.

J'utilise un Raspbee sur un Pi séparé et un assistant domestique (fonctionnant sur un NUC) et j'ai appx. 25 lampes de commerce. Principalement GU10 utilisé par groupes de 3.

J'ai eu de gros problèmes avec des lumières uniques dans un groupe léger qui ne répondaient pas et avaient besoin d'un cycle d'alimentation pour revenir. Cela s'est produit à la fois avec Ikea FW v1 et après la mise à niveau des ampoules à 2.3.007.

La solution était de changer ma configuration de grouper les lumières dans HASS à la définition de groupes de lumières dans Phoscon et de référencer les groupes Phoscon comme des lumières uniques dans HASS. Après ce changement, je tourne sans problème depuis quelques mois.

Je veux pouvoir faire le regroupement dans HASS alors j'ai mis à niveau mon Raspbee vers 0x26340500 et Deconz vers 2.05.74 et j'ai changé ma configuration pour utiliser des groupes de lumière dans HASS. Après avoir exécuté cela pendant une semaine, des ampoules sont devenues périmées 3 ou 4 fois, et je reviens maintenant à l'utilisation des groupes Phoscon.

Je pense qu'il devrait y avoir une logique qui devrait inciter deCONZ à reconsidérer ses routes dans ce cas. Surtout quand il détecte que les requêtes ZCL ne reçoivent pas de réponse. Ce qui à la fin conduit la lumière à être marquée comme zombie. La découverte qui suit le marquage en tant que zombie conduit en fait à une réponse du ligtht. Peut-être que lorsqu'une découverte pour un zombie est lancée, elle devrait également invalider les informations de route disponibles. Mais mieux encore, si déjà plus tôt la route est invalidée lorsque quelques requêtes ZCL ne reçoivent pas de réponse (probablement déjà sur la première ou la deuxième de celles-ci).

Je suis toujours sur le nouveau firmware et je teste quelques choses, y compris les enregistrements d'itinéraire, j'espère le mettre en ligne cette semaine.

Que penses-tu de cela?

C'est un bon point, je dois vérifier le code du noyau et du plugin REST-API ici, car je pense que le firmware devrait déjà dégrader la "qualité" de la route lorsqu'aucun ACK de niveau APS n'est reçu. L'APS ACK est un indicateur qui est défini facultativement dans les demandes ZCL / APS et est souvent désactivé pour réduire le trafic réseau. Donc, une idée approximative est que nous devrions activer APS ACK si le plugin détecte que les demandes de monodiffusion entraînent des délais d'expiration.

Peut-être qu'une partie de cela est déjà en place, il faut vérifier le code.

Cependant, le routeur entre les deux abandonne silencieusement toutes les trames de monodiffusion qu'il devrait acheminer vers cette lumière. Ce routeur ne devrait bien sûr pas les abandonner silencieusement, alors encore une fois, deCONZ devrait être robuste contre ce mauvais comportement.

La lumière doit choisir une nouvelle route dès que la découverte d'une nouvelle route est déclenchée. L'objectif doit donc être de détecter le plus rapidement possible les routes interrompues (avec un peu de chance, l'APS ACK fera l'affaire) et de déclencher la découverte de routes.

La machine à états pour cela est déjà en place dans le noyau deCONZ (c'est ce qui conduit à la diffusion de la demande d'adresse NWK) cela fonctionne dans le cas de liaisons à un saut et pour les lumières qui prennent des routes en fonction des commandes entrantes (la réponse à la diffuser). La diffusion est agréable car elle respecte également les modifications apportées à l'adresse NWK car l'adresse MAC est incluse. J'essaierai d'envoyer une monodiffusion avec l'APS ACK activé comme prochaine étape au cas où aucune réponse ne serait reçue.

Malheureusement, hier, j'ai également dû redémarrer une ampoule IKEA E27 (blanc 1000LM, firmware v1). Il ne réagissait qu'aux commandes de groupe, mais pas aux commandes de monodiffusion. Semble que le problème n'est pas encore résolu :(

(et oui je suis sur v74 et le firmware beta pour RaspBee)

Voir les commentaires ci-dessus, les prochaines modifications pourraient aider à récupérer le routage.

Que penses-tu de cela?

C'est un bon point, je dois vérifier le code du noyau et du plugin REST-API ici, car je pense que le firmware devrait déjà dégrader la "qualité" de la route lorsqu'aucun ACK de niveau APS n'est reçu. L'APS ACK est un indicateur qui est défini facultativement dans les demandes ZCL / APS et est souvent désactivé pour réduire le trafic réseau. Donc, une idée approximative est que nous devrions activer APS ACK si le plugin détecte que les demandes de monodiffusion entraînent des délais d'expiration.

Peut-être qu'une partie de cela est déjà en place, il faut vérifier le code.

Il semble que même lorsque le bit de requête APS ACK est défini, deCONZ ne fait rien avec l'accusé de réception manquant (une seule tentative et puis rien ...)

BTW houtlamp 2 est celui qui dépose les paquets dirigés vers Tuin linksvoor 2

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

Cependant, le routeur entre les deux abandonne silencieusement toutes les trames de monodiffusion qu'il devrait acheminer vers cette lumière. Ce routeur ne devrait bien sûr pas les abandonner silencieusement, alors encore une fois, deCONZ devrait être robuste contre ce mauvais comportement.

La lumière doit choisir une nouvelle route dès que la découverte d'une nouvelle route est déclenchée. L'objectif doit donc être de détecter le plus rapidement possible les routes interrompues (avec un peu de chance, l'APS ACK fera l'affaire) et de déclencher la découverte de routes.

La machine à états pour cela est déjà en place dans le noyau deCONZ (c'est ce qui conduit à la diffusion de la demande d'adresse NWK) cela fonctionne dans le cas de liaisons à un saut et pour les lumières qui prennent des routes en fonction des commandes entrantes (la réponse à la diffuser). La diffusion est agréable car elle respecte également les modifications apportées à l'adresse NWK car l'adresse MAC est incluse. J'essaierai d'envoyer une monodiffusion avec l'APS ACK activé comme prochaine étape au cas où aucune réponse ne serait reçue.

En fait, le houtlamp 2 ne voit jamais de réponse à la diffusion address request . Les messages vers deCONZ sont acheminés via tuin linksvoor 3 , donc même si houtlamp 2 prendrait cette route, il n'en a jamais l'occasion. Ceci est à nouveau causé par le fait que deCONZ ne récupère pas le route record comme nouvelle route.

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]

Maintenant Tuin linksvoor 2 envoie une réponse à la diffusion network address request et réussit, mais l'APS ACK de deCONZ n'atteint jamais Tuin linksvoor 2 , car il est perdu de houtlamp 2 . Donc, il renvoie plusieurs fois avant d'abandonner. Cela aura de bonnes chances de gâcher Tuin linksvoor 2 .

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 + dernier fw + .74 ne joue pas à 100%.
Avait pas mal de succès / échecs. Cela semble mieux fonctionner avec 0,73 pour moi, mais pas à 100%.

Revenons donc à la planche à dessin. Ce n'est toujours pas 100% ok avec le nouveau (bêta) Conbee 1 fw.

Après quelques jours de fonctionnement avec .74 et 26340500 sur Conbee 1 sur Tradfir E14 avec le firmware 1.2.221 peut signaler que:

La lumière IKEA est devenue plus stable en termes d'abandon du réseau, même si je n'avais qu'une ampoule qui s'est perdue en 4 jours. J'ai également découvert que si vous insistez sur votre réseau zigbee exploité par deconz fonctionnant sur E14 fw 1.2.221. J'ai exécuté un script qui atténue une ampoule en envoyant des requêtes uniques avec bri changé chaque seconde. De cette manière, j'ai perdu 4 ampoules très rapidement. Mais qui veut ça de toute façon;)

Toujours non résolu:
Le problème et la préoccupation que j'ai toujours est que Tradfri FW 2.3.x ne fonctionne pas bien, ou n'est pas bien implémenté pour être utilisé avec deconz. C'est bien de rester à tradfri fw 1.2.x et de ne pas aller à zigbee 3.0. Mais il y aura un moment où il ne peut être évité. Ou les ampoules nouvellement déclassées, j'en ai peur.
J'ai découvert qu'un groupe de 2-3 ampoules ne montre pas trop ce problème en tant que groupe de 4-8 ampoules.
J'ai signalé ma découverte ici et je suis heureuse et reconnaissante si elle est ramassée. J'ai essayé de sensibiliser ici https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518
car je peux reproduire ce problème en faisant simplement clignoter toute mon ampoule sur 2.3.x et j'espère que vous pourrez le faire aussi.

En bout de ligne - cela fait une différence sur le firmware de tradfri utilisé et dont nous parlons. Il y a une énorme différence dans la convivialité, les problèmes rencontrés et le fonctionnement avec deconz. Alors que les fws 1.2.x sont plus probablement plus anciens et fonctionnent comme un charme à côté des abandons connus, 2.3.x n'a pas perdu sa convivialité comme décrit dans le problème soulevé. Je ne peux pas imaginer que je suis le seul à expérimenter cette différence dans les FW.

J'ai maintenant envoyé un e-mail au support dresden elektronik en allemand pour sensibiliser à cela, car j'ai compris que certains d'entre vous sont des passionnés de passe-temps comme @ebaauw l' a clairement indiqué dans un autre fil. Je pensais que la plupart des développeurs étaient des entrepreneurs dresden elektronik. Désolé pour cette idée fausse et merci pour vos contributions. Je suis curieux de connaître la réponse officielle maintenant.

Le firmware Conbee II est-il également corrigé maintenant? Je n'ai vu que Conbee I dans la version. Merci à tous pour votre travail acharné.

Cela est à nouveau dû au fait que deCONZ ne récupère pas l'enregistrement d'itinéraire comme nouvel itinéraire.

@djwlindenaar s'avère que je suis à blâmer ici, j'ai vérifié les validations du code Route Record dans le référentiel de la pile (ConBee I et RaspBee I). En 2018, j'avais ajouté un "correctif" (ou je le pensais) pour un problème similaire qui venait de désactiver la mise à jour de l'adresse de saut suivant sur un enregistrement de route entrante.

Si ma mémoire est bonne, le problème à l'époque était que nous avions un grand réseau mixte d'environ 150 nœuds et que les enregistrements d'itinéraire ne fonctionnaient apparemment pas correctement. Le nouveau chemin de retour ne fonctionnait pas correctement. Cependant, le code peut avoir fonctionné avec l'autre correction des codes d'erreur de la commande d'état NWK.

Je rétablis cela maintenant, donc l'enregistrement d'itinéraire devrait mettre à jour l'itinéraire vers le meilleur chemin.

J'adore ce paragraphe de la spécification Zigbee:

Un routeur ZigBee ou un coordinateur ZigBee peut maintenir une table de routage. Les informations qui doivent être stockées dans une entrée de table de routage ZigBee sont indiquées dans le Tableau 3-66. Le vieillissement et le retrait des entrées de table de routage afin de réclamer de nouveau l'espace table à partir d'entrées qui ne sont plus utilisées est une pratique recommandée; il est cependant hors de la portée de cette spécification.

Ce qui signifie essentiellement que chaque pile gère différemment le vieillissement d'itinéraire.

J'ai donc vérifié comment cela fonctionne dans notre cas. Dans Bitcloud Zigbee, les routes de la pile ont un "taux" de route, qui est initialement de 1.

1. Lors d'une transmission NWK réussie, le débit est incrémenté s'il est inférieur au maximum qui est
   (1 << 8) - 1 = 255
2. Sur une transmission NWK réussie, si le maximum de 255 est atteint, toutes les entrées de la table de routage sont "normalisées"
   rate = (rate >> 1) + 1 (effectivement divisé par 2, avec un minimum de 1)
3. En cas d'échec de la transmission NWK, le débit de l'entrée d'itinéraire associée est défini comme suit:
   rate -= (rate / 2) > 0 ? rate / 2 : 1
4. Sur trop de transmissions échouées, le taux passe à 0 et l'itinéraire est supprimé

Cela signifie qu'un lien supérieur se dégradera comme:

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

Par conséquent, il faut 8 commandes ayant échoué jusqu'à ce qu'une entrée soit supprimée et que la découverte soit redémarrée.
C'est tout à fait correct dans les réseaux normaux, surtout lorsqu'ils atteignent 50 .. 100 nœuds, une route ne doit pas être ignorée trop tôt.

Ce qui m'inquiète, c'est le point (2) car par exemple une route très fraîche ou non utilisée qui serait souvent dégradée par des nœuds très performants totalement indépendants avec de bonnes liaisons, par exemple une lumière Philips Hue qui est interrogée toutes les quelques secondes trigger (2) multiplie assez souvent cela par le nombre de lumières dans un grand réseau. Sans parler des mises à jour actives OTA.

Je pense qu'il est prudent de changer (2) pour ne pas dégrader (normaliser) toutes les entrées de route mais uniquement la route 255 supérieure liée à la transmission réussie. Cela devrait éviter de perdre des routes qui fonctionnaient bien mais qui n'étaient pas souvent utilisées et qui ont été supprimées lors de la première transmission NWK échouée.

Je vais créer un nouveau firmware avec ces changements demain, également un pour ConBee II, probablement la même chose ici.

Je rétablis cela maintenant, donc l'enregistrement d'itinéraire devrait mettre à jour l'itinéraire vers le meilleur chemin.

Ça a l'air bien. J'ai hâte de tester!

J'adore ce paragraphe de la spécification Zigbee:

Ouais, je suppose que ce genre de spécification nous donne du mal à faire coexister tous les fournisseurs. :sourire:

Dans Bitcloud Zigbee, les routes de la pile ont un "taux" de route, qui est initialement de 1.

Je ne comprends pas vraiment la logique de la règle 2. Cela semble une sorte de version pauvre du vieillissement. Ce qui fonctionne assez bien si tous les nœuds voient une quantité de trafic similaire, mais en effet, s'il est déséquilibré (ce que je pense est assez courant), cela ira mal.
J'ai remarqué que ZStack utilise un champ expiryTime dans sa table de routage, à côté d'un octet status .

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

Comment cela fonctionne-t-il réellement?
Si je ne me trompe pas, une transmission NWK échouée signifie en fait le saut suivant uniquement, puisque NWK ne vérifie que le MAC ACK 802.15.4. Donc, pour vérifier si la transmission de bout en bout est correcte, nous devons nous fier à APS ack. Est-ce exact? Cela fonctionne-t-il de cette façon dans BitCloud?
De plus: si le bit de demande d'accusé de réception dans la couche APS n'est pas défini, est-ce considéré comme une transmission réussie (puisqu'aucun accusé de réception n'est attendu) et est-ce que cela augmente le "débit" de cette entrée de route? Parce que si tel est le cas, nous pourrions nous tirer une balle dans le pied en ne demandant pas tout le temps la couche APS ACK.

S'il est uniquement basé sur des échecs NWK, cela n'aidera pas le cas où un routeur intermédiaire se comporte mal et nous devons ajouter une logique supplémentaire pour prendre en compte la couche APS ACK qui n'arrive pas. Probablement basé sur une logique similaire en place pour détecter les routeurs «zombies», mais en invalidant d'abord l'entrée de la table de routage pour cette route.

La version du micrologiciel 0x26350500 pour ConBee I et RaspBee I est disponible pour les tests.

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

• Comme 0x26340500, toutes les erreurs de route d'état NWK sont gérées
• Correction de la dégradation des routes déloyales (voir le point 2 sur https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment-596142584)
• Corriger les enregistrements d'itinéraire n'a pas mis à jour le prochain saut d'un itinéraire, notez que cela fonctionnera désormais, mais seulement si le coût de l'itinéraire actuel est plus élevé lorsque l'enregistrement d'itinéraire
• La correction des demandes APS ayant échoué avec l'APS ACK activé n'a pas dégradé l'itinéraire

Je regarde maintenant dans le code ConBee II pour voir si et où ces correctifs peuvent être appliqués. Ignorer 0x26520700 et 0x26530700 et baser cela sur le 0x264a0700 stable actuel.

Je ne comprends pas vraiment la logique de la règle 2. Cela semble une sorte de version pauvre du vieillissement. Ce qui fonctionne assez bien si tous les nœuds voient une quantité de trafic similaire, mais en effet, s'il est déséquilibré (ce que je pense est assez courant), cela ira mal.
J'ai remarqué que le ZStack utilise un champ expiryTime réel dans sa table de routage, à côté d'un octet d'état.

Tout à fait d'accord, cela est maintenant corrigé, de sorte que seul l'itinéraire d'une transmission réussie est normalisé lorsque le débit atteint le maximum. La manière de gérer cette minuterie expirée pourrait être une autre option, mais elle a ses propres pièges à grande échelle. Je pense que la méthode «taux» devrait fonctionner assez bien sans dépendre de la taille et du temps du réseau.

S'il est uniquement basé sur des échecs NWK, cela n'aidera pas le cas où un routeur intermédiaire se comporte mal et nous devons ajouter une logique supplémentaire pour prendre en compte la couche APS ACK qui n'arrive pas. Probablement basé sur une logique similaire en place pour détecter les routeurs «zombies», mais en invalidant d'abord l'entrée de la table de routage pour cette route.

Cela semblait être le cas et en effet, des routeurs qui se comportent mal, qui n'envoient pas de commandes d'état NWK avec des échecs de route, pourraient maintenir une route morte en vie. Ceci est maintenant corrigé dans 0x26350500 mais il repose sur les commandes activées par APS ACK. Ce qui devrait être bien et peut être contrôlé par deCONz et le plugin REST-API.

La version du micrologiciel 0x26350500 pour ConBee I et RaspBee I est disponible pour les tests.

Je l'ai flashé, en cours de test.

Ceci est maintenant corrigé dans 0x26350500 mais il repose sur les commandes activées par APS ACK.

Que faites-vous en réponse à un ACK manquant? Réduisez-vous de moitié la rate comme avec une transmission NWK échouée ou plus / différent? Parce que je pense qu'un APS ACK manquant devrait être considéré comme plus grave par rapport à une transmission NWK échouée. Sinon, encore une fois dans le cas d'un routeur qui se comporte mal, les transmissions NWK réussies peuvent augmenter le rate plus que les ACK APS manquants le réduisent.

Que faites-vous en réponse à un ACK manquant? Réduisez-vous de moitié la valeur du débit comme avec une transmission NWK échouée ou plus / différent? Parce que je pense qu'un APS ACK manquant devrait être considéré comme plus grave par rapport à une transmission NWK échouée. Sinon, toujours dans le cas d'un routeur qui se comporte mal, les transmissions NWK réussies peuvent augmenter le débit plus que les ACK APS manquants le réduisent.

J'ai pensé la même chose, voici ce qui se passe dans ce cas:

• Transmission NWK positive MAC ACK rate + 1
• Aucun APS ACK rate = rate / 4

Donc, le taux baisse assez rapidement, peut être un peu trop agressif et rate / 2 est suffisant, mais voyons comment cela fonctionne dans la pratique.

Agréable. Je vais l'exécuter et faire un rapport.

Actuellement également des tests de stress en envoyant des messages monodiffusion (OnOffwithLevel) à une lumière assez éloignée du maillage, toutes les quelques secondes.

Btw j'ai également changé le reste du code du plugin pour demander APS ACK dans tous les messages.

J'exécute Deconz sur un Rpi 3B + en utilisant Home Assistant
Actuellement en cours d'exécution 2.05.75 avec Conbee I et 26330500

Remarqué ce soir certaines lumières n'étaient pas allumées.
J'ai essayé de les activer manuellement, voir le journal ci-dessous.
Vérifié le maillage VNC, il fait partie du réseau maillé mais ne réagit à rien.
Ce nœud est un interrupteur de sortie marche / arrêt Tradfri.

Chose étrange ici:
_Je PEUX mettre l'interrupteur en marche lors de l'activation du groupe Deconz au lieu de l'interrupteur individuel ._

19: 23: 58: 979 délai d'envoi de la demande 57 dt 0 ms à 0x000D6FFFFEB1C9FF, ep: 0x01 cluster: 0x0004 onAir: 1
19: 24: 15: 744 Canal actuel 25
19: 24: 15: 776 Drapeaux du périphérique TTL 3920: 0x7
19: 24: 46: 764 0x000D6FFFFEB1C9FF erreur APSDE-DATA.confirm: 0xA7 sur la tâche
19: 25: 10: 547 Erreur 0x000D6FFFFEB1C9FF APSDE-DATA.confirm: 0xA7 sur la tâche
19: 25: 15: 749 Canal actuel 25
19: 25: 15: 782 Indicateurs TTL 3860 du périphérique: 0x7
19: 25: 33: 885 0x000D6FFFFEB1C9FF erreur APSDE-DATA.confirm: 0xA7 sur la tâche
19: 25: 49: 411 0x000D6FFFFEB1C9FF erreur APSDE-DATA.confirm: 0xA7 sur la tâche
19: 26: 12: 765 0x000D6FFFFEB1C9FF erreur APSDE-DATA.confirm: 0xA7 sur la tâche
19: 26: 12: 765 erreurs de transmission max. Pour le nœud 0x000D6FFFFEB1C9FF, vues pour la dernière fois par les voisins 25 s
19: 26: 15: 742 Canal actuel 25
19: 26: 15: 774 Drapeaux TTL 3800 du périphérique: 0x7
19: 26: 48: 221 0x000D6FFFFEB1C9FF erreur APSDE-DATA.confirm: 0xA7 sur la tâche
19: 26: 48: 221 erreurs de transmission max. Pour le nœud 0x000D6FFFFEB1C9FF, vues pour la dernière fois par les voisins 60 s
19: 27: 03: 845 état du nœud enregistré en 9 ms
19: 27: 33: 634 sync () en 29789 ms

Les derniers correctifs se trouvent dans 26350500 ...

@djwlindenaar Je

Jusqu'ici tout va bien. Je peux voir deCONZ changer d'itinéraires avec plaisir. :sourire:

Les derniers correctifs se trouvent dans 26350500 ...

Désolé, vous avez mal lu la version du firmware.
Je veux aider à tester, en utilisant le module complémentaire officiel Home Assistant Deconz, je ne sais pas comment mettre à jour celui-ci vers un firmware bêta. (les mises à jour officielles sont OTA)

Cher @manup , un statut sur la mise à jour de Conbee II FW?

@manup , on dirait qu'il n'y a pas d'action sur le Many-to-One Route Failure (0x0c) . Je m'attendrais à ce que deCONZ refasse un MTORR (sauf si un est déjà en cours). Je reçois ces messages régulièrement.

Command Frame: Network Status
    Command Identifier: Network Status (0x03)
    Status Code: Many-to-One Route Failure (0x0c)
    Destination: 0x499e[Tuin rechtsachter 2]

@manup , il semble que le route record soit toujours pas pris en charge par deCONZ. Par exemple:

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

La lumière Tuin linksvoor 2 envoie directement à deCONZ , mais le chemin de deCONZ passe par plusieurs sauts ...
Ce serait utile si vous pouviez donner un aperçu du processus de prise de décision dans deCONZ pour accepter oui / non l'itinéraire à partir du message route record .

--- a édité les éléments ci-dessous, car il y avait un défaut dans mon raisonnement. Maintenant, espérons que non: clin d'oeil: ---

Cela dit, l'itinéraire utilisé par deCONZ est en fait beaucoup plus fiable que la communication directe avec Tuin linksvoor 2 . Cela m'a amené à me poser des questions et à examiner le routage plusieurs-à-un. Je pense que la puissance d'émission du Raspbee n'est peut-être pas idéale ...
Voici mon raisonnement:

• Le routage plusieurs-à-un est basé sur la réception des émissions
• Contrairement à la gestion de route normale, le maximum des coûts de chemin entrants et sortants est pris comme coût du prochain saut
• Maintenant, si un routeur ou le coordinateur est bien meilleur en transmission (puissance TX élevée) qu'en réception (faible sensibilité RX), cela peut conduire à un routage plusieurs-à-un qui ne fonctionne pas très bien.

Un point connexe que j'ai remarqué est que deCONZ semble être (très) optimiste quant au coût entrant dans sa table de routage. Lorsque Tuin linksvoor 2 envoie directement un message à deCONZ , il faut de nombreuses tentatives, tout le temps. Maintenant, si je regarde dans la table de routage, je vois ce qui suit, et je ne m'attendrais pas à une transmission difficile à un coût entrant de 4. Notez que fondamentalement tous les éléments de la table de routage ont un coût d'entrée beaucoup plus faible que le coût sortant.

Link 4
    Address: 0x0ea5[Tuin linksvoor 2]
    .... .100 = Incoming Cost: 4
    .111 .... = Outgoing Cost: 7

Donc, si deCONZ était moins optimiste quant au coût entrant, nous pourrions voir un meilleur comportement d'itinéraire. Ou si nous augmentions la puissance TX pour être plus équilibrée (coût similaire pour les entrées et les sorties)
Ou si nous réduisions la puissance d'émission de deCONZ, je pense qu'il devra acheminer plus de sauts (le coût de 7 appareils disparaîtrait de la table de routage), mais il sera également plus facile de recevoir les messages entrants.

Liste totale du message d'état du lien deCONZ:

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

Désolé pour le retard. Statut: Nous travaillons toujours dur sur la nouvelle version et recherchons toujours les bogues dans le firmware qui semblent plus complexes que nous ne le pensions. Quelque chose dans la gestion nvram semble ne pas fonctionner. Nous cherchons également à résoudre les problèmes d'énumération / de démarrage USB.

Je publierai des mises à jour ici dès qu'elles seront disponibles.

Mise à jour: toujours aussi fort!

Je ne pense pas avoir jamais vu le réseau aussi stable. J'ai maintenant changé diverses règles pour utiliser la monodiffusion au lieu de groupes. Maintenant, pendant 2 semaines et 0 lumières IKEA ont disparu.

(J'espère que je ne le gâche pas maintenant)

Notez que j'ai changé le plugin REST pour demander un accusé de réception APS pour toutes les demandes.

Je vis également un réseau bien amélioré. Pas à 100% cependant. Il y a eu des ampoules occasionnelles qui n'ont pas répondu, mais lorsque j'ai modifié manuellement l'ampoule IKEA, cela a répondu. Je vois aussi que l'état de l'ampoule est maintenant comme l'état physique.
Cependant, l'une de mes ampoules Osram a eu un comportement irresponsable comme les ampoules Ikea avaient auparavant. Le positif est que ce n'est pas un comportement aussi sévère que l'ikea l'a fait.

J'espère que cela peut être confirmé par d'autres ou des découvertes identifiées.

J'utilise Conbee 1, avec FW 26350500 et Deconz 2.05.75.
C'est mon expérience des dernières semaines

• Fonctionne mieux mais pas à 100%
• Certaines de mes ampoules IKEA E27 TRÅDFRI E27 WS opale 980lm avec fw 2.3.007 ne parviennent parfois pas à répondre aux commandes OFF
• Je peux simplement essayer de les éteindre à nouveau et cela fonctionne généralement (pas besoin de redémarrer)

@djwlindenaar sympa! Votre correctif APS pour l'API REST est-il inclus dans la version .75? Juste pour que je sache si cela pourrait expliquer certaines différences dans les articles précédents ...

Non ce n'est pas. Je n'ai même pas créé de pull request pour cela. Avec cela, vous pouvez le construire vous-même. Je vais faire ça aujourd'hui ou demain.
Je peux également partager le plugin API de repos intégré, mais je n'ai que celui pour raspberry 3.

@tubalainen , je vais vérifier si cela peut être expliqué avec l'ack APS. De plus, je n'ai pas de lumières IKEA 2,3.

Il y a peut-être un problème avec le comportement de nouvelle tentative dans deCONZ. J'aurais besoin de faire une expérience pour cela ou peut-être que c'est déjà dans les journaux de reniflage.

Si vous pouvez renifler, il serait utile de sentir ce phénomène. Je peux vous aider à analyser si vous ne pouvez pas.

J'ai mis à jour mon réseau de production (RPi 3B +, stretch, RaspBee) à 2.05.74 et 0x26340500 hier. Semble stable, sauf pour les problèmes ci-dessous.
Je ne sais pas si cela est lié, mais l'itinéraire vers mon contrôleur de rideau lumi.curtain a été perdu ce matin. Les rapports du contrôleur atteindraient toujours la passerelle. L'itinéraire ne serait pas restauré lors du redémarrage du contrôleur. J'ai dû ouvrir le réseau et redémarrer le contrôleur avant que le coordinateur ne l'atteigne à nouveau.
De plus, une de mes vannes de radiateur Eurotronic Spirit était inaccessible par deCONZ après le démarrage de deCONZ, tout en envoyant des rapports. Le cycle d'alimentation du TRV l'a ramené, comme d'habitude.
Je n'ai pas eu l'occasion de faire une enquête approfondie cette fois, mais les deux appareils ont posé problème dès le début, présentant ces symptômes de temps en temps. Idem pour mon store IKEA Fyrtur. Je continuerai à surveiller la situation et à faire un rapport si je rencontre d'autres problèmes.

Il est très difficile d'enregistrer objectivement ces problèmes intermittents, mais j'ai l'impression que 0x26350500 a apporté des améliorations ici. Hormis les appareils mentionnés ci-dessus, mon réseau est très stable. Certains TRV sont devenus inaccessibles depuis la passerelle, mais surtout (seulement?) Après le redémarrage de deCONZ. Je ne pense pas que le FYRTUR ni le contrôleur de rideau soient devenus MIA ces trois dernières semaines.

Notez que j'ai changé le plugin REST pour demander un accusé de réception APS pour toutes les demandes.

J'ai les Acks APS activés dans les _ Paramètres réseau_ de l'interface graphique, mais je ne suis pas sûr que cela s'applique uniquement aux messages envoyés par l'interface graphique, ou également au plugin REST API.

Si vous souhaitez exécuter avec la requête d'extraction ci-dessus, vous pouvez également consulter mon fork et le construire: djwlindenaar / deconz-rest-plugin

@ebaauw , pour autant que je

J'ai un renifleur qui fonctionne en continu et je n'ai pas l'heure de l'horloge quand un problème se produit. Habituellement, avec ces informations, je peux trouver les paquets assez facilement ...

BTW, j'ai changé beaucoup de mes règles (en particulier celles qui se déclenchent souvent) en monodiffusion. Jusqu'à présent, cela fonctionne très bien. J'ai également utilisé une lampe IKEA en changeant continuellement la luminosité (toutes les 4 secondes environ) au cours des 2 dernières semaines. Celui-là est également toujours bien.

enfin ... je viens de remarquer quelque chose de génial dans mes journaux. J'ai constaté qu'aucune des lumières que j'ai allumées ne rapporterait leurs attributs. Je pensais que j'étais sur un autre bogue, mais ce n'était pas le cas, bien que d'une certaine manière je pense que nous pourrions vouloir considérer cela comme un bogue de toute façon.

Comme je l'ai mentionné, j'avais un script en cours d'exécution pour changer le niveau d'une lumière toutes les deux secondes. Penser que cela peut accélérer les problèmes avec les lumières IKEA. Il s'avère que cela réinitialise le compteur d->idleLastActivity , ce qui empêche toute tâche inactive d'être exécutée. Y compris la configuration du rapport d'attribut: rofl:

Êtes-vous en train de dire que les lumières IKEA perdent leurs fixations et leur configuration de rapport d'attribut après un cycle d'alimentation?!

On dirait que ... Ne devraient-ils pas ...?

Mon problème maintenant est que depuis que j'ai mis à niveau ma configuration à .75 et 50500, mon conteneur docker perd le Conbee au moins une fois par semaine. Le redémarrage du conteneur fait redémarrer les choses ... TRÈS ennuyeux

@djwlindenaar , non, je ne pense pas qu'ils devraient. La plupart des appareils que j'ai vus conservent ces paramètres dans une mémoire non volatile. Je suppose que la norme ZigBee laisse place à l'un ou l'autre comportement.

Bien que mes ampoules IKEA fonctionnent bien mieux maintenant, malheureusement, l'un de mes capteurs Xiaomi (capteur de température rond) ne répond plus après un certain temps. Je vais essayer de recueillir des preuves en reniflant dans les prochains jours.

J'utilise Conbee 1, avec FW 26350500 et Deconz 2.05.75.
C'est mon expérience des dernières semaines

• Fonctionne mieux mais pas à 100%
• Certaines de mes ampoules IKEA E27 TRÅDFRI E27 WS opale 980lm avec fw 2.3.007 ne parviennent parfois pas à répondre aux commandes OFF
• Je peux simplement essayer de les éteindre à nouveau et cela fonctionne généralement (pas besoin de redémarrer)

@tubalainen Salut, j'ai remarqué le comportement différent d'ikea avec le firmware 2.3.x par rapport à 1.2.x aussi. J'ai essayé d'y remédier mais je n'ai pas attiré l'attention. J'ai rétrogradé mes ampoules à 1.2.x et cela fonctionne comme un charme maintenant. Sur 2.3.x. Vous ne pouvez pas éteindre après un recalcul de scène pendant un certain temps. Normal marche / arrêt a fonctionné. Comportement étrange. Peut-être que vous voulez tester et contribuer ici. bravo https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518

Êtes-vous en train de dire que les lumières IKEA perdent leurs fixations et leur configuration de rapport d'attribut après un cycle d'alimentation?!

Malheureusement, ils perdent leurs liaisons après un cycle d'alimentation, le code a été adapté il y a quelque temps pour y remédier. Les liaisons et la configuration seront restaurées après la mise sous tension d'un voyant, également si aucun rapport n'est reçu pendant un certain temps, le processus démarrera pour les restaurer.

@realwax réduira à 1.2.x sur toutes mes ampoules E27 et fera un rapport. (prend du temps :)).

Hier, deux feux E27 (avec 2,3x FW) ne se sont pas éteints pendant la séquence du matin.

@tubalainen utilisez-vous des commandes de groupe ou des commandes de monodiffusion? (c'est-à-dire via l'API REST, définissez l'état via / groups / ou / lights /)

Je pense que tant que les lumières sont accessibles, les commandes de monodiffusion sont en fait plus fiables. Si une commande de diffusion de groupe est manquée d'une manière ou d'une autre, elle n'est pas réessayée. Les commandes monodiffusion sont réessayées plusieurs fois ou jusqu'à leur livraison.

@tubalainen utilisez-vous des commandes de groupe ou des commandes de monodiffusion? (c'est-à-dire via l'API REST, définissez l'état via / groups / ou / lights /)

Je pense que tant que les lumières sont accessibles, les commandes de monodiffusion sont en fait plus fiables. Si une commande de diffusion de groupe est manquée d'une manière ou d'une autre, elle n'est pas réessayée. Les commandes monodiffusion sont réessayées plusieurs fois ou jusqu'à leur livraison.

J'utilise Home Assistant et l'API RESt. Je ne sais pas ce que fait Home Assistant ...

Dans mon cas c'est iobroker avec plug in deconz et Phoscon ... Alors reste API. Les problèmes apparaissent lors de l'utilisation d'igroups. Un rappel de scène de groupe déclenche que le groupe ne peut pas être désactivé, ni changé rapidement vers d'autres réglages de scène de groupe ou désactivé correctement, en particulier jusqu'à 15 secondes après le rappel de scène. Il semble que deconz soit occupé avec la commande avant, ou les ampoules 2.3.x fw gèlent (ce dont je doute). Impossible de déboguer au niveau zigbee pour obtenir une meilleure compréhension. La fonction de regroupement de deconz est-elle une couche virtuelle qui est traduite en commandes uni cast ou est effectuée via les options de regroupement disponibles dans l'interface graphique / zigbee? En bout de ligne, j'utilise la fonction de groupe intégrée, sinon je devrais créer cette couche virtuelle dans iobroker et il n'y a aucune raison car la fonctionnalité de regroupement est bonne. Donc si c'est le regroupement ... Quelle est la différence car il semble 100% avec fw 1.2.x et non avec 2.3.x. Qu'est ce qui a changé? Est-ce Zigbee 2 pourquoi ils se comportent différemment.

@tubalainen Oui, c'est beaucoup de travail car vous devrez peut-être redémarrer de temps en temps ou rapprocher quelques ampoules. Je l'ai fait deux fois avec 20 e14 tradfri. Vous devriez voir une énorme amélioration. Avez-vous remarqué que vos ampoules avec 2.3..x ne s'allument pas doucement. (fondu) plus et 1.2.x faire?

MAIS les doigts croisés que plus peuvent le reproduire, donc ikeas fw 2.3.x sera utilisable en deconz car il y aura un moment où nous aurons besoin de mettre à jour. Ou remplacez les ampoules. Bien que zigbee 2 serait bien aussi.

Merci à tous pour vos efforts!

@realwax @djwlindenaar @manup

Hier soir, une lumière ne s'est pas éteinte comme il se doit (IKEA E27 avec fw 2.3.x). J'ai testé pour changer la luminosité de cette lumière qui ne s'éteignait pas et elle est passée instantanément au réglage de luminosité que j'ai choisi. Quelques instants après avoir changé la luminosité, la lumière a soudainement bien répondu à la commande d'arrêt.

J'ai personnellement changé toutes mes automatisations dans Home Assistant pour changer d'abord la luminosité, attendez 2 secondes, puis envoyez la commande d'arrêt.

Jusqu'à présent, taux de réussite de 100%.

J'espère que cela peut être un indice pour l'enquête.

EDIT: Ce sont toujours les lumières qui sont les plus éloignées de la coordination (le bâton Conbee) qui ne s'éteignent pas. (lumières qui, en raison de la nature de la bande de fréquences, doivent se mailler)

Hé les gens!

Je voulais juste parler de mes problèmes ...
Après avoir rencontré des problèmes de stabilité avec ma clé ConBee II, j'ai vérifié la version du firmware. C'était 26530700. J'ai ensuite rétrogradé à 264a0700, et après cela, aucune application ne peut voir le bâton. J'ai essayé HomeAssistant et deCONZ. Le système d'exploitation hôte identifie le bâton OK et GCFFlasher fonctionne.

Hé les gens!

Je voulais juste parler de mes problèmes ...
Après avoir rencontré des problèmes de stabilité avec ma clé ConBee II, j'ai vérifié la version du firmware. C'était 26530700. J'ai ensuite rétrogradé à 264a0700, et après cela, aucune application ne peut voir le bâton. J'ai essayé HomeAssistant et deCONZ. Le système d'exploitation hôte identifie le bâton OK et GCFFlasher fonctionne.

Après avoir rétrogradé à 26490700, tout semble fonctionner à nouveau ... Maillage Zigbee stable pendant 24 heures maintenant ...

Les mises à jour? Je veux vraiment passer toute ma maison à mon Conbee II mais pour le moment, il est très instable. Ma teinte fonctionne parfaitement, Conbee ii pas tellement 🥺

Mon expérience avec le dernier deCONZ .75 avec RaspBee FW 0x26350500 est très bonne jusqu'à présent.

Mes appareils:
Lampes 4xTradfri 980lu WS - FW 2.3.007
17xTradfri 1000lu WS lumières - FW 2.0.023
3xTradfri Plugs - FW 2.0.022
Télécommandes rondes 3xTradfri E1810 - FW 2.3.014
Capteurs 4xAqara THP

Trouvé un autre qui plante le firmware de l'ampoule IKEA. (et je pense que cela peut être corrigé dans deConz)

J'ai vu une lumière ne pas répondre ce matin. La dernière communication est illustrée ci-dessous.

Il semble que deConz reçoive la réponse d'appartenance au groupe, mais d'une manière ou d'une autre, l'APS ACK (accusant réception de la demande d'adhésion au groupe) envoyé par la lumière n'est pas reçu par deConz (je ne vois pas non plus un ACK MAC). En conséquence, deConz renvoie la demande. Cette requête a le même numéro dans la ZCL, ce qui plante le micrologiciel léger.

Je suppose que deConz pourrait considérer la demande comme acquittée dès que la réponse correspondante arrive et éviter de faire une autre demande. Droite? Existe-t-il une API pour le plugin qui peut être appelée pour annuler une demande? @manup?

Notez que ce bogue spécifique est également contourné en ne demandant pas l'APS ACK pour ces demandes, qui est la valeur par défaut dans le plugin API REST actuel.

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

Exécution de la v2.05.75 avec 0x26350500 depuis quelques semaines maintenant. Cela semble un peu plus stable que les versions précédentes, mais je perds encore occasionnellement la route vers mes TRV Eurotronic Spirit, mon store Fyrtur et mon contrôleur de rideau Xiaomi lumi.curtain . Ce dernier est un routeur; les autres sont des appareils finaux. Tous les TRV ont la même version de matériel / micrologiciel, mais certains sont plus souvent MIA que d'autres. Les symptômes sont cohérents: l'appareil continue d'envoyer des rapports au coordinateur, mais les commandes du coordinateur n'entraînent qu'une _Route Request_ sans réponse.

Actuellement en train de renifler et d'analyser le trafic pour le TRV qui disparaît le plus souvent. Les rapports parviennent au coordinateur en trois sauts, en utilisant deux lumières Hue en cours de route. J'ai également capturé une _Data Request_ du TRV à la première lumière en route, donc le TRV semble heureux que ce soit son parent. Les demandes de descripteur de correspondance du TRV pour le cluster OTAU restent sans réponse. Le parent signale la lumière suivante dans son _ Statut du lien_, mais pas dans le TRV (parce que c'est un périphérique final?).

Les messages _Link Quality Response_ affichent une table voisine de 20 entrées, mais la TRV n'en fait pas partie. Un capteur de porte Xiaomi (qui est stable depuis toujours) l'est. Curieusement, le coordinateur l'est aussi, mais le rapport du TRV au coordinateur a été relayé via un autre routeur (qui est également dans la table des voisins).
OK, maintenant le coordinateur est également inclus dans le _Link Status_ et le prochain rapport du TRV est transmis directement au coordinateur.

L'alimentation a fait redémarrer le TRV. Le TRV envoie une _Data Request_ MAC au (ancien) parent; le routeur répond avec une _Rejoin Response_ en passant l'ancienne adresse NWK du TRV comme nouvelle adresse. Le TRV diffuse alors le _Device Announcement_ (monodiffusion MAC au parent; le parent transmet en tant que diffusion MAC). Le TRV envoie une _End Device Timeout Request_ au parent; le parent envoie un _Update Device_ au coordinateur l'informant que le TRV a rejoint en toute sécurité. Le parent envoie désormais également une _Route Reply_ à la _Route Request_ du coordinateur. Dans la prochaine séquence _Link Quality Response_, le TRV est inclus.

Je vais continuer à faire fonctionner le renifleur, j'espère pour saisir le moment où le TRV disparaîtra à nouveau.

Sur une note peut-être liée: l'une de mes prises intelligentes innr SP120 pense toujours que c'est le parent du bouton Hue, que j'ai brièvement joint à mon réseau de production tout en ajoutant le support. Le bouton a depuis été connecté à mon réseau de test depuis quelques semaines maintenant, et j'ai redémarré la prise plusieurs fois. Dois-je réinitialiser la prise en usine pour lui faire oublier l'enfant perdu?

@manup , longtemps depuis toute mise à jour à la fois dans le code et dans les informations sur ce qui se passe. Pourriez-vous s'il vous plaît nous donner une mise à jour sur les progrès de vos équipes sur les problèmes de stabilité et si vous osez également un calendrier attendu.

J'ai trouvé un autre problème dans le comportement de routage de deConz.

Dans ce cas, deConz essaie d'acheminer le message vers Hal lamp via Tuin linksvoor 3 . Mais en regardant le rapport Link Status de Tuin linksvoor 3 il ne sait pas sur Hal lamp . Et apparemment, il ne sait pas non plus comment y accéder par le routage. Bien sûr, cette lumière (IKEA) devrait se comporter et répondre par un message d'échec, mais ce n'est pas le cas et nous ne pouvons pas changer cela.
Cependant, deConz conclut que le Hal lamp est un zombie sans aucune tentative de trouver une nouvelle route vers cette lumière. Je ne sais pas comment cela interagit avec le (nouveau) code de routage, mais d'une manière ou d'une autre, cela n'a pas dégradé cette route assez rapidement pour l'empêcher d'être signalée comme zombie. (BTW ce n'est vraiment pas, voir suivant ...)

Cela a provoqué un problème temporaire qui s'est résolu après quelques minutes (ce qui est bien sûr totalement inacceptable). Parce que le Hal lamp décide d'envoyer un rapport d'attribut, pour lequel il ne reçoit pas d'ACK APS et démarre donc un processus Route Request . Seulement maintenant, une fois que cela est terminé, deConz change sa route en Hal lamp et la communication reprend normalement.

Je me demande combien de temps cela aurait pris si la lumière n'avait pas décidé d'envoyer un message à deConz. (Notez que dans mon réseau, j'exécute les lumières IKEA avec des rapports d'attributs réguliers pour les clusters On / Off et Level toutes les 5 minutes)

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

Votre description ressemble à ce que je vis. J'ai un bien meilleur réseau (conbee 1) avec le dernier fw. Mais obtenez toujours des ampoules qui ne répondent pas qui, après un certain temps, redeviennent réactives.
Je n'exécute pas de commandes ou de paramètres extraordinaires que ceux fournis par Home Assistant et mon programme habituel pour l'ampoule. Bien que les ampoules intérieures changent pendant la journée (marche / arrêt ou luminosité) où mes ampoules extérieures ne changent que les heures des arbres par jour. Parfois, les ampoules qui ne répondent pas reviennent assez rapidement et si j'émets une commande, elles répondent. Rarement, mais cela arrive, cela prend beaucoup plus de temps ou je dois redémarrer.

@djwlindenaar excellent travail encore. Merci beaucoup! Partagez-vous vos recherches de bogues dans IKEA FW avec IKEA?

@djwlindenaar :

Bien sûr, cette lumière (IKEA) devrait se comporter et répondre par un message d'échec, mais ce n'est pas le cas et nous ne pouvons pas changer cela.

Eh bien, je n'ai pas. Peut-être que @manup peut commenter le taux de réussite de cette opération, car je pense qu'il a essayé de contacter IKEA.
De plus, je n'utilise pas leur dernier firmware.

Peut-être que contacter les laboratoires de silicium serait une meilleure idée, car c'est sur cela que repose le matériel IKEA. Je ne sais pas si les bugs proviennent du code Ember ou de la personnalisation IKEA ...

@djwlindenaar Vous pouvez également essayer de contacter via reddit: https://www.reddit.com/user/TRADFRI Ils sont assez actifs là-bas.

@manup Des nouvelles pour le firmware du Conbee II?

après avoir rétrogradé le firmware à 0x264a0700 je ne peux plus me connecter à Conbee II. J'ai essayé de passer à 0x264a0700 et certains firmwares très anciens également, le clignotement fonctionne bien mais ne peut pas se connecter. Des conseils sur la réinitialisation du stick Conbee II?

@manup des mises à jour? Dois-je chercher autre chose que deConz ou des travaux sont-ils en cours pour résoudre les problèmes? Merci de donner un signe de vie

Je souhaite juste que mon Conbee II fonctionne à nouveau après avoir essayé le firmware de test ...

@djwlindenaar Des mises à jour de votre part? Toujours un réseau stable avec vos correctifs?

C'est bien de voir que votre PR est fusionné par @manup :)

@djwlindenaar Des mises à jour de votre part? Toujours un réseau stable avec vos correctifs?

C'est bien de voir que votre PR est fusionné par @manup :)

@ JBS5 Je suis moyennement satisfait de la situation.

Cela s'est clairement amélioré pour mon réseau. Cependant, je vois encore les bugs dans les lumières IKEA déroutant parfois deCONZ.

Le point clé est que parfois un routeur IKEA supprime silencieusement des paquets pour un certain itinéraire. Cette suppression silencieuse est illégale, mais deCONZ devrait y réagir en trouvant une nouvelle route et ce n'est pas le cas.

Il semble que les modifications apportées au micrologiciel deCONZ améliorent la situation, mais il y a encore quelque chose à ajouter pour ces situations. Bien sûr, l'absence d'un ACK APS devrait immédiatement déclencher une nouvelle recherche d'itinéraire.

Notez que @manup a mentionné que le routage source pourrait résoudre le problème et je pense que cela est particulièrement vrai dans ce cas, car cela signifie que nous ne dépendons pas des routeurs du réseau sachant comment acheminer vers un nœud distant.

Je crois que le bug dans les lumières IKEA est le résultat du fait qu'une table ne peut pas contenir toutes les routes vers des nœuds distants. Supprimant ainsi silencieusement tout paquet dont il ne connaît pas l'itinéraire.

Merci @djwlindenaar.
Comme il y a quelque temps que @manup a commenté ici, avez-vous une idée si le routage source mentionné est quelque chose qui sera implémenté?

Il s'agit d'un changement qui doit se produire dans le firmware. Je ne suis pas affilié à deCONZ, donc je ne peux pas commenter la probabilité ...

@manup ?

Cela m'amène à envisager de m'éloigner de deCONZ pour mon réseau domestique ...

@djwlindenaar , quelles alternatives envisagez-vous? Je ne suis actuellement pas impressionné par la stabilité de mon Conbee II.

Il s'agit d'un changement qui doit se produire dans le firmware. Je ne suis pas affilié à deCONZ, donc je ne peux pas commenter la probabilité ...

@manup ?

Cela m'amène à envisager de m'éloigner de deCONZ pour mon réseau domestique ...

Zigbee2MQTT fait-il mieux cela ou ne le pensiez-vous pas avec l'alternative?

Ouais. C'est ça.

En fait, je ne sais pas si cela fait un meilleur travail. Notez que les firmwares utilisés sont fournis par les fabricants de puces. Ces firmwares ne sont pas open source. Donc, s'ils ont un problème de firmware, vous êtes probablement bloqué avec moins de support que deCONZ ...
En revanche, la configuration de ces firmwares est open source. En outre, ils prennent déjà en charge le routage source.

Le fabricant de puces ne fournit que le SDK, si vous le souhaitez, vous pouvez télécharger le SDK, la version d'essai de Simplicity Studio et compiler vous-même le firmware. Z2M fournit des correctifs des modifications apportées au firmware.

Bonjour ensemble,

Toutes mes excuses pour cela, voici le nouveau firmware pour ConBee II qui a porté tous les correctifs de routage du firmware AVR 0x26350500. De plus, il a amélioré le démarrage pour éviter que l'appareil ne devienne silencieux. (Nous testons toujours divers cas pour résoudre le problème de démarrage pour de bon).

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

Cette version fera probablement partie de la prochaine version deCONZ 2.05.76, les micrologiciels de la version 0x26350500 de ConBee I et RaspBee I seront augmentés pour être installés via le bouton de mise à jour.

Merci, @manup. J'ai installé cette version sur mon réseau de test et cela semble fonctionner. Au moins les appareils peuvent être contrôlés, contrairement aux sous 52 et 53. Le réseau de test est trop petit pour vérifier si cette version améliore le routage.

@manup deCONZ ne se connecte toujours pas à ConBee II, même après avoir flashé le nouveau firmware. Eu ce problème pendant un moment.

@manup J'ai essayé de le flasher plusieurs fois, mais continuez à recevoir cette erreur:

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.

Est-ce GCFFlasher 3.13?

Voici le journal de ma mise à jour:

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

Oui, c'était 3.13, cela fonctionne maintenant que j'ai redémarré le système complet. Bizarre, le simple fait de rebrancher le ConBee II n'a pas fonctionné, mais le redémarrage fonctionne.

En effet étrange, la vérification CRC se fait directement sur l'appareil, je me demande comment cela peut arriver.

@manup J'ai même essayé de faire clignoter l'ancien firmware (plusieurs versions) et un débit de 9600 bauds. Tous ont abouti à la même erreur CRC.

Heureux que cela fonctionne maintenant, merci! J'ai déjà vu un appareil problématique qui a rejoint le réseau immédiatement. J'espère donc que ce firmware résoudra certains problèmes :)

Heureux que cela fonctionne maintenant. Je viens juste de discuter avec les collèges du chargeur de démarrage. La version 2.05 provenait du premier lot de ConBee II en 2019 (environ 3500 pcs), cette version est un peu approximative dans certains cas. Depuis juillet 2019, nous expédions la version 2.07 avec quelques corrections à la gestion du chien de garde.

Il y a un nouveau bootloader 3.x en développement qui fait déjà partie de RaspBee II, il a une conception et un protocole beaucoup plus robustes pour résoudre les problèmes de la version 2.x.

Actuellement, nous ne mettons pas à jour le chargeur de démarrage ConBee II avec GCFFlasher. Nous n'avons pas déployé cela car il existe une possibilité subtile de brique le périphérique si la mise à jour du chargeur de démarrage est abandonnée au moment où la table vectorielle de démarrage est modifiée. Mais je pense que nous pouvons comprendre cela en utilisant le gestionnaire de fautes matérielles ARM. L'idée est que si la mise à jour du chargeur de démarrage échoue et que le gestionnaire de défauts matériels est déclenché, il peut vérifier si le chargeur de démarrage est valide et si cela échoue, il sautera dans l'application, où la mise à jour du chargeur de démarrage pourra être tentée à nouveau. Nous avons fait quelques tests avec le gestionnaire de défauts durs qui semblent prometteurs, mais cela prendra un certain temps avant qu'il ne soit prêt pour la publication publique.

salut

J'ai flashé avec le nouveau firmware aujourd'hui, mais je vois toujours des journaux comme:

Erreur 0x000D6FFFFE540E7C APSDE-DATA.confirm: 0xA7 sur la tâche

Est-ce lié?

0xA7 indique qu'un ACK APS n'a pas été fourni là où il aurait dû l'être. Je suppose que cela peut avoir diverses raisons.

Salut @manup ,

Re-bonjour,

J'ai toujours des problèmes où certaines lumières ne réagissent pas aux commandes (marche / arrêt / atténuation), et je ne sais vraiment pas pourquoi, je pensais que j'avais quelque chose à voir avec ce problème, mais maintenant je ne sais pas si c'est le cas?

Je reçois encore beaucoup d'erreurs comme celle que j'ai publiée il y a 4 jours.

nombre de codes
0xA7 29
0xAE 31
0xD0 1
0xE1 1
0xE9 14
total 76

J'ai 26 appareils affichant ces erreurs AUJOURD'HUI, il semble que cela se soit un peu empiré avec 0x26580700

Quelqu'un peut-il me dire si cela est lié à ce problème de routage? ou je devrais ouvrir un problème avec mon problème

Notez que cela ne semble se produire que lors de l'envoi de fx. "allumé" à ~ 20 lumières "en même temps"

Salut @manup ,

Salut @djwlindenaar oui absolument, je dois rattraper les commentaires de ce numéro au cours de la semaine. Si ma mémoire me sert bien, il y avait déjà d'autres idées pour améliorer les questions restantes.

Salut @djwlindenaar oui absolument, je dois rattraper les commentaires de ce numéro au cours de la semaine. Si ma mémoire me sert bien, il y avait déjà d'autres idées pour améliorer les questions restantes.

@manup , bien sûr, je pense que le problème clé est toujours que deCONZ est toujours têtu à conserver une route qui ne fonctionne pas.
Je crois que les messages du mauvais comportement et de la lumière affectée continuent d'arriver (via une autre route) et cela est mal interprété par le firmware comme si la route non fonctionnelle fonctionnait toujours. DeCONZ a également tendance à abandonner assez rapidement les demandes de couche APS si aucun ACK n'est reçu. Je pense qu'il devrait être plus persistant et / ou démarrer une découverte d'itinéraire dans le cadre du processus de nouvelle tentative.

Enfin, je suis maintenant convaincu que le routage source éliminerait le principal problème de mauvais comportement des routeurs. Donc, si vous pouviez mettre cela en œuvre, nous serions dans un bien meilleur endroit. Je suis prêt à aider / tester / déboguer ...

Salut @manup ,

Salut @djwlindenaar oui absolument, je dois rattraper les commentaires de ce numéro au cours de la semaine. Si ma mémoire me sert bien, il y avait déjà d'autres idées pour améliorer les questions restantes.

Salut Manup, je détourne peut-être ce fil, alors s'il vous plaît, ignorez-le. J'ai un Conbee ii sur Home Assistant et il fonctionnait très bien jusqu'à il y a environ un mois. À ce stade, tous mes capteurs Xiaomi deviendraient des automatisations de rupture peu fiables. J'ai des contrôleurs fls-pp de Dresde que j'ai depuis quelques années. Ceux-ci sont connectés à des bandes de LED et utilisés pour abandonner sporadiquement le réseau, forçant un redémarrage pour les réactiver. Je les ai finalement tous supprimés de mon réseau Conbee et immédiatement l'ensemble du réseau était stable. Je l'ai laissé quelques jours puis en ai réintroduit un qui a fonctionné pendant quelques heures, puis du jour au lendemain, mon réseau Zigbee a échoué et je n'ai pas pu remettre tous mes commutateurs / capteurs en ligne jusqu'à ce que j'éteigne le contrôleur de Dresde. Je ne sais pas pourquoi mais pour moi, l'utilisation des contrôleurs de Dresde brise maintenant mon réseau zigbee. Je ne suis qu'un novice à ce sujet, donc je ne sais pas si cela est utile / pertinent, mais je cherchais des commentaires à ce sujet et je suis tombé sur ce fil, alors j'ai pensé que je jetterais mon expérience dans le mélange au cas où. Pour l'instant, je les supprime simplement de mon réseau - cela ne vaut pas le mal de tête qu'ils me donnaient!
À votre santé

Salut @djwlindenaar oui absolument, je dois rattraper les commentaires de ce numéro au cours de la semaine. Si ma mémoire me sert bien, il y avait déjà d'autres idées pour améliorer les questions restantes.

@manup , bien sûr, je pense que le problème clé est toujours que deCONZ est toujours têtu à conserver une route qui ne fonctionne pas.
Je crois que les messages du mauvais comportement et de la lumière affectée continuent d'arriver (via une autre route) et cela est mal interprété par le firmware comme si la route non fonctionnelle fonctionnait toujours. DeCONZ a également tendance à abandonner assez rapidement les demandes de couche APS si aucun ACK n'est reçu. Je pense qu'il devrait être plus persistant et / ou démarrer une découverte d'itinéraire dans le cadre du processus de nouvelle tentative.

Enfin, je suis maintenant convaincu que le routage source éliminerait le principal problème de mauvais comportement des routeurs. Donc, si vous pouviez mettre cela en œuvre, nous serions dans un bien meilleur endroit. Je suis prêt à aider / tester / déboguer ...

J'ai décidé de passer à zigbee2mqtt en raison des problèmes de routage (le plus ennuyeux est la nécessité de réappairer Ikea / Xiaomi de temps en temps). Je publierai mes conclusions ici dans quelques semaines ...

Après avoir flashé le firmware 0x26350500 sur mon Conbee I (et mis à jour deCONZ vers 2.05.76) lundi dernier, malheureusement, un GU10 s'est déconnecté.

Dans VNC, c'est un peu gris:

Phoscon:

Est-il nécessaire de mettre sous tension toutes les lumières avant de profiter du correctif de routage dans la nouvelle version du firmware?

@ JBS5 , je ne pense pas qu'il soit nécessaire de
C'est probablement dû au fait que, bien qu'amélioré, nous ne sommes pas complètement à l'écart des problèmes de routage; voir mes articles précédents.

@djwlindenaar Merci. Je comprends.

Pour ce que ça vaut, car c'est un peu le même comportement qu'avec le firmware précédent:

Une fois que le GU10 a été marqué comme indisponible, il répondait toujours aux commandes de groupe. Après quelques jours, 2 appareils alimentés par batterie (capteur de mouvement Aqara et détecteur de fumée Xiaomi / Honeywell) ont également été déconnectés. Le GU10 répondait toujours aux commandes de groupe.

Après le redémarrage du GU10, les 2 appareils alimentés par batterie sont également revenus en ligne immédiatement.
Ainsi, après la mise hors ligne du GU10, il a fallu quelques jours pour qu'un appareil alimenté par batterie utilisant le GU10 spécifique comme routeur soit déconnecté.

@ JBS5 , oui, cela ressemble à un comportement typique. En fait, il n'y a rien de mal avec cette lumière GU10. C'est juste que deCONZ a perdu son moyen de communiquer directement avec lui. Après un certain temps, cela entraîne également la mise hors ligne de ses périphériques finaux, car ils ne reçoivent aucun retour de la part de deCONZ. Enfin, lorsque le GU10 est suffisamment privé de paquets réseau, il se déconnecte pour de vrai.

Probablement dans la phase où il répond toujours aux commandes de groupe, vous pourrez redémarrer un autre routeur, ce qui est apparemment bien, et le GU10 se rétablira. Cet autre routeur ne joue pas bien et deCONZ ne répond pas bien à la situation.
Alors ne vous fâchez pas contre le GU10;)

Salut @djwlindenaar oui absolument, je dois rattraper les commentaires de ce numéro au cours de la semaine. Si ma mémoire me sert bien, il y avait déjà d'autres idées pour améliorer les questions restantes.

@manup , bien sûr, je pense que le problème clé est toujours que deCONZ est toujours têtu à conserver une route qui ne fonctionne pas.

Hmm, les routes doivent être dégradées et abandonnées après plusieurs échecs de transmission. Le dernier micrologiciel se dégradera à chaque fois qu'une erreur est signalée dans la confirmation APS-DATA (comme une erreur de routage ou aucun APS-ACK reçu).

Je crois que les messages du mauvais comportement et de la lumière affectée continuent d'arriver (via une autre route) et cela est mal interprété par le firmware comme si la route non fonctionnelle fonctionnait toujours.

C'est un très bon indice, je vais le vérifier. cela expliquerait pourquoi les routes ne mourront pas. Je pense que la seule façon sensée d'évaluer une route devrait être basée sur des transmissions réussies.

DeCONZ a également tendance à abandonner assez rapidement les demandes de couche APS si aucun ACK n'est reçu. Je pense qu'il devrait être plus persistant et / ou démarrer une découverte d'itinéraire dans le cadre du processus de nouvelle tentative.

deCONZ ne fait aucune découverte de route, tout est géré par la pile Zigbee. Nous pouvons étendre l'API REST pour faire de nouvelles tentatives pour certaines commandes (comme les commandes de contrôle), mais c'est difficile.

La pile elle-même pourrait être configurée pour effectuer plusieurs tentatives APS jusqu'à abandon. Mais cela peut gâcher beaucoup de choses et bloquer la file d'attente pendant longtemps. Je pense qu'il est préférable de considérer cela plus finement dans l'API REST.

Enfin, je suis maintenant convaincu que le routage source éliminerait le principal problème de mauvais comportement des routeurs. Donc, si vous pouviez mettre cela en œuvre, nous serions dans un bien meilleur endroit. Je suis prêt à aider / tester / déboguer ...

En théorie, le routage source est le Saint Graal pour tout résoudre :)

Mais dans le monde réel, de nombreuses passerelles ne l'utilisent pas (est-ce qu'il y en a?), Ce qui signifie que la plupart des produits ne prennent pas en charge le routage source ou n'ont pas été testés avec. IMHO chances de le faire fonctionner dans des réseaux mixtes sont très faibles. Mais cela fait un moment que je n'ai pas comparé différentes passerelles à ce niveau. Il serait intéressant d'avoir un aperçu actuel sur quelles passerelles utilisent quelle approche de routage de nos jours.

Il serait intéressant d'avoir un aperçu actuel sur quelles passerelles utilisent quelle approche de routage de nos jours.

Heureux de vous aider à tester / renifler le pont Hue (génération 2 et génération 1), la passerelle innr, le hub IKEA et la passerelle OSRAM Lightly Home, mais j'ai besoin d'informations sur la configuration de test à utiliser (combien de routeurs, de périphériques finaux, de distances entre eux , ...) et ce qu'il faut rechercher.

Z-Stack FW est un exemple de FW qui offre / utilise le routage source et le recommande pour les grands réseaux. Mais j´ai aussi vu quelques commentaires selon lesquels cela ne fonctionne pas vraiment bien pour le CC2351 plus faible.

https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator

DeCONZ a également tendance à abandonner assez rapidement les demandes de couche APS si aucun ACK n'est reçu. Je pense qu'il devrait être plus persistant et / ou démarrer une découverte d'itinéraire dans le cadre du processus de nouvelle tentative.

deCONZ ne fait aucune découverte de route, tout est géré par la pile Zigbee. Nous pouvons étendre l'API REST pour faire de nouvelles tentatives pour certaines commandes (comme les commandes de contrôle), mais c'est difficile.

La pile elle-même pourrait être configurée pour effectuer plusieurs tentatives APS jusqu'à abandon. Mais cela peut gâcher beaucoup de choses et bloquer la file d'attente pendant longtemps. Je pense qu'il est préférable de considérer cela plus finement dans l'API REST.

La pile fait quelques tentatives, je me souviens qu'elle essaie trois fois, si je ne me trompe pas. Il me semble que vous pourriez ajouter un comportement dans ce morceau de code pour invalider la route associée et réessayer une ou deux fois. Ou peut-être que vous pouvez avoir un rappel dans la pile pour implémenter ce comportement. Cela devrait susciter une découverte d'itinéraire, non?

Enfin, je suis maintenant convaincu que le routage source éliminerait le principal problème de mauvais comportement des routeurs. Donc, si vous pouviez mettre cela en œuvre, nous serions dans un bien meilleur endroit. Je suis prêt à aider / tester / déboguer ...

En théorie, le routage source est le Saint Graal pour tout résoudre :)

Mais dans le monde réel, de nombreuses passerelles ne l'utilisent pas (est-ce qu'il y en a?), Ce qui signifie que la plupart des produits ne prennent pas en charge le routage source ou n'ont pas été testés avec. IMHO chances de le faire fonctionner dans des réseaux mixtes sont très faibles. Mais cela fait un moment que je n'ai pas comparé différentes passerelles à ce niveau. Il serait intéressant d'avoir un aperçu actuel sur quelles passerelles utilisent quelle approche de routage de nos jours.

Pour être honnête, je ne suis pas très préoccupé par ce problème. Le comportement des routeurs en cas de routage source est extrêmement simple. Surtout si vous le comparez au comportement requis pour effectuer eux-mêmes le routage. Fondamentalement, la seule chose que la couche NWK dans un routeur doit faire est de vérifier si le routage source est activé, de lire le saut suivant du paquet et de le remettre à la couche MAC. Pas de tables, pas de mémoire, rien à faire de mal. Je ne sais pas si le comportement de base est vérifié pour la certification zigbee, mais c'est bien sûr beaucoup plus simple et il y a beaucoup moins de risques de bogues que le routage normal.

Je m'attends à ce que peu de coordinateurs l'implémentent, car la complexité réside dans le firmware du coordinateur. De plus, très peu d'implémentations de zigbee (grand public) sont en fait concentrées sur les plus grands réseaux qui bénéficieraient de ce mode de routage.

Enfin, je dirais que c'est le meilleur mode de routage pour les réseaux mixtes, car le routage normal dépend des implémentations individuelles des routeurs et en particulier des indications de qualité de liaison mal spécifiées. Étant donné que le routage source est si simple (= faible risque de mauvaises implémentations), j'aurais confiance en cela avant le comportement de routage normal.

Donc ... cela dit, je suis prêt à le tester pour vous si vous pouviez fournir un firmware. Je suis sur un raspbee, mon renifleur est prêt à partir.

Enfin, je dirais que c'est le meilleur mode de routage pour les réseaux mixtes, car le routage normal dépend des implémentations individuelles des routeurs et en particulier des indications de qualité de liaison mal spécifiées. Étant donné que le routage source est si simple (= faible risque de mauvaises implémentations), j'aurais confiance en cela avant le comportement de routage normal.

KISS - a beaucoup de sens pour moi.

La pile fait quelques tentatives, je me souviens qu'elle essaie trois fois, si je ne me trompe pas. Il me semble que vous pourriez ajouter un comportement dans ce morceau de code pour invalider la route associée et réessayer une ou deux fois. Ou peut-être que vous pouvez avoir un rappel dans la pile pour implémenter ce comportement. Cela devrait susciter une découverte d'itinéraire, non?

Si je comprends bien le code qui se produit déjà, le problème est que les itinéraires semblent être maintenus en vie en raison d'autres facteurs (sous enquête).

Pour être honnête, je ne suis pas très préoccupé par ce problème. Le comportement des routeurs en cas de routage source est extrêmement simple. Surtout si vous le comparez au comportement requis pour effectuer eux-mêmes le routage. Fondamentalement, la seule chose que la couche NWK dans un routeur doit faire est de vérifier si le routage source est activé, de lire le saut suivant du paquet et de le remettre à la couche MAC. Pas de tables, pas de mémoire, rien à faire de mal. Je ne sais pas si le comportement de base est vérifié pour la certification zigbee, mais c'est bien sûr beaucoup plus simple et il y a beaucoup moins de risques de bogues que le routage normal.

Je ne peux parler que pour les produits basés sur BitCloud que j'ai apportés via la certification (ballasts FLS). Dans le processus de certification, ils n'ont jamais été testés pour le routage source. Je ne sais pas s'il était même activé dans la pile au moment de la compilation. Notez que la plupart des piles sont configurées pour être compilées avec les fonctionnalités minimales requises pour un espace sécurisé.

Mon expérience personnelle avec des fonctionnalités rarement utilisées / testées, aussi simples soient-elles en théorie, est qu'elles ont toujours des bogues. Par exemple, pour le FLS, nous avons dû corriger des tonnes de bogues dans l'exemple d'application de pile BitCloud. Je sais que Philips a également apporté de nombreuses améliorations à la pile BitCloud pour certains de ses produits.

Je m'attends à ce que peu de coordinateurs l'implémentent, car la complexité réside dans le firmware du coordinateur. De plus, très peu d'implémentations de zigbee (grand public) sont en fait concentrées sur les plus grands réseaux qui bénéficieraient de ce mode de routage.

La complexité doit être implémentée dans le plugin deCONZ REST-API ou dans un nouveau plugin de routeur, car le firmware n'a pas suffisamment d'informations sur la topologie du réseau dans son ensemble ni sur l'espace flash. Pour cela, le deCONZ::ApsDataRequest pourrait être étendu avec une option de route source sous la forme d'un std::vector<quint16> contenant les adresses nwk d'une route.

Je n'ai pas un bon aperçu de la complexité que cela apporte, qui est actuellement gérée par le routage du maillage. Les tâches suivantes doivent être considérées au minimum et à grande échelle:

• Requête récursive de la topologie du réseau (Mgmt_Lqi_req). C'est le plus simple, cela fonctionne déjà pour le routage de maillage et pourrait être adapté aux routes source.
• Les nœuds sont hors tension. Ici, une logique doit sélectionner des itinéraires alternatifs, qui peuvent également ne pas fonctionner si leurs liens sont également rompus.
• Les nœuds sont à nouveau sous tension.
• Nœuds modifiant l'adresse nwk.
• Les appareils finaux changent de parents.
• Les appareils finaux se joignent, dans les réseaux à sauts multiples, nous ne connaissons pas le parent sans interroger le réseau.

Ce que nous ne savons pas encore:

• Tous les routeurs prennent-ils en charge le routage source?
• Existe-t-il des passerelles commerciales qui utilisent le routage source? Ici, nous devons renifler le trafic et regarder les en-têtes NWK qui contiennent les routes source et ont des indicateurs respectifs définis.
• Pour les appareils prenant en charge le routage source, dans quelle mesure cela fonctionne-t-il?

Je ne peux parler que pour les produits basés sur BitCloud que j'ai apportés via la certification (ballasts FLS). Dans le processus de certification, ils n'ont jamais été testés pour le routage source. Je ne sais pas s'il était même activé dans la pile au moment de la compilation. Notez que la plupart des piles sont configurées pour être compilées avec les fonctionnalités minimales requises pour un espace sécurisé.

Je ne sais pas comment cela fonctionne, mais les piles ne sont-elles pas non plus certifiées?

Mon expérience personnelle avec des fonctionnalités rarement utilisées / testées, aussi simples soient-elles en théorie, est qu'elles ont toujours des bogues. Par exemple, pour le FLS, nous avons dû corriger des tonnes de bogues dans l'exemple d'application de pile BitCloud. Je sais que Philips a également apporté de nombreuses améliorations à la pile BitCloud pour certains de ses produits.

Je m'attends à ce que peu de coordinateurs l'implémentent, car la complexité réside dans le firmware du coordinateur. De plus, très peu d'implémentations de zigbee (grand public) sont en fait concentrées sur les plus grands réseaux qui bénéficieraient de ce mode de routage.

La complexité doit être implémentée dans le plugin deCONZ REST-API ou dans un nouveau plugin de routeur, car le firmware n'a pas suffisamment d'informations sur la topologie du réseau dans son ensemble ni sur l'espace flash. Pour cela, le deCONZ::ApsDataRequest pourrait être étendu avec une option de route source sous la forme d'un std::vector<quint16> contenant les adresses nwk d'une route.

Je ne comprends pas cette déclaration. Le routage source est entièrement géré au niveau NWK dans la pile. La pile bitcloud doit avoir un indicateur de temps de compilation (ou moins probablement d'exécution) pour activer le routage source. Il existe une table de routage source qui est tenue à jour par la pile, basée sur les messages Route Record qui sont déjà dans notre réseau en raison du MTORR envoyé par le coordinateur toutes les quelques minutes.

• Fondamentalement, pour chaque appareil du réseau, l'itinéraire vers le coordinateur est connu via les MTORR
• Le coordinateur connaît chaque itinéraire (complet) vers chaque appareil via les messages d'enregistrement d'itinéraire. Aucune analyse n'est nécessaire, juste un copier-coller du message RR dans la table de routage source

Voir la spécification zigbee chapitre 3.6.3.5.4 et chapitre 3.6.3.3

Je n'ai pas un bon aperçu de la complexité que cela apporte, qui est actuellement gérée par le routage du maillage. Les tâches suivantes doivent être considérées au minimum et à grande échelle:

* 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.

Je pense que tout cela est géré par la couche NWK à l'intérieur de la pile bitcloud. Cela devrait être aussi simple que d'ajuster certains indicateurs de compilation (similaire à l'activation du comportement MTOR)

Ce que nous ne savons pas encore:

* Do all routers support source routing?

Je m'y attendais, car cela fait partie de la spécification zigbee de base de la couche NWK. Je ne peux pas être certain, mais je n'ai vu aucune remarque selon laquelle la prise en charge du routage source est facultative. C'est similaire au comportement MTOR, que nous utilisons déjà dans notre réseau.

* 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.

Vous ne connaissez pas celui-ci, vous ne savez pas non plus ce que cela nous dira?

* For the devices which support source routing, how well does it work?

Si vous pouviez créer une version du firmware avec le routage source activé, nous apprendrons rapidement. Il ne devrait y avoir que quelques indicateurs de temps de compilation pour l'activer dans bitcloud.

De plus, Zigbee2MQTT l'a activé pour certains firmwares de coordination et je n'ai pas encore (après un rapide google) trouvé de problèmes avec des routeurs spécifiques ne fonctionnant pas bien avec le routage source activé.

Je ne sais pas comment cela fonctionne, mais les piles ne sont-elles pas non plus certifiées?

Oui, mais pendant la certification, des configurations spécifiques sont activées et peuvent ne pas être activées ultérieurement dans les produits.

Je ne comprends pas cette déclaration. Le routage source est entièrement géré au niveau NWK dans la pile. La pile bitcloud doit avoir un indicateur de temps de compilation (ou moins probablement d'exécution) pour activer le routage source. Il existe une table de routage source qui est tenue à jour par la pile, basée sur les messages Route Record qui sont déjà dans notre réseau en raison du MTORR envoyé par le coordinateur toutes les quelques minutes.

Fondamentalement, pour chaque appareil du réseau, l'itinéraire vers le coordinateur est connu via les MTORR
Le coordinateur connaît chaque itinéraire (complet) vers chaque appareil via les messages d'enregistrement d'itinéraire. Aucune analyse n'est nécessaire, juste un copier-coller du message RR dans la table de routage source

Voir la spécification zigbee chapitre 3.6.3.5.4 et chapitre 3.6.3.3

Ah tu as raison, idiot moi je l'ai mal interprété avec la découverte générale des nœuds (facepalm).
La pile peut en effet comprendre beaucoup de commandes d'enregistrement de route dues, mais je rencontre déjà un cas où aucune n'a été envoyée, voir ci-dessous.

Aujourd'hui, j'ai essayé de nombreuses configurations, il semble que le routage source fonctionne en quelque sorte, mais uniquement lorsque le routage maillé est désactivé et pour les périphériques qui envoient des commandes d'enregistrement d'itinéraire avant.

Mon capteur de mouvement Philips Hue pose des problèmes et envoie des demandes d'adresse NWK de diffusion pour obtenir l'adresse NWK de la passerelle. Dans ce cas, aucune trame d'enregistrement d'itinéraire n'a été envoyée à un prieuré (je pense à cause de la diffusion). Étant donné que le routage maillé a été désactivé, la passerelle n'a pas lancé de découverte d'itinéraire et la communication avec le capteur n'a donc pas été établie.

Lorsque le routage maillé est activé à côté du routage source, il semble que le routage source n'est plus utilisé, bien que les deux soient activés.

Je dois faire plus de tests, je pense que la découverte d'itinéraire de maillage devrait être empêchée lorsqu'il y a déjà des entrées d'enregistrement d'itinéraire dans le cache d'itinéraire. Le code est assez complexe, je dois creuser plus profondément ici.

deCONZ_ConBeeII_0x26600700_many2one.bin.zip

Voici le micrologiciel qui a à la fois le maillage et le routage source activés (taille de la table des enregistrements d'itinéraire de 32). Vous pouvez l'essayer mais comme mentionné dans mon plus petit routage de source réseau n'a pas été déclenché dans cette configuration.

Je suis sur Raspbee I, donc je ne peux pas tester celui-là. Pourriez-vous en créer un également?
Je me demande si nous pourrions contourner ce problème avec une sorte de route statique que nous pouvons télécharger sur le firmware au démarrage ou peut-être en fait sur la base d'autres informations.
De plus, avez-vous réparé cet appareil après la modification du routage source? Vous vous demandez si une interaction est nécessaire pour qu'un périphérique final reconnaisse MTOR et que le routage source est en cours d'utilisation. Bien sûr, ils ne reçoivent pas les messages MTOR diffusés lorsque leur récepteur est éteint.
BTW, j'ai vu fe mes appareils d'extrémité Xiaomi envoyer l'enregistrement d'itinéraire dans mon reniflement ...

J'ai conduit au-dessus du firmware pendant la nuit. Il semble que le routage source est également utilisé avec le routage maillé activé, mais très rarement. À partir de ca. 2 millions de paquets seulement <5 ont utilisé une route source.

Je suis sur Raspbee I, donc je ne peux pas tester celui-là. Pourriez-vous en créer un également?

Pas sûr, je dois vérifier l'autre configuration de pile utilisée par ConBee I et RaspBee I si cela est possible.

Je me demande si nous pourrions contourner ce problème avec une sorte de route statique que nous pouvons télécharger sur le firmware au démarrage ou peut-être en fait sur la base d'autres informations.

Oui, je pense qu'il devrait être possible d'injecter des routes dans le cache de routes d'une manière ou d'une autre. Mais quand nous revenons à mes préoccupations mentionnées ci-dessus pour maintenir les routes. Quoi qu'il en soit, à des fins de test et de réseaux fixes, cela fournirait un moyen utile de configurer le routage.

De plus, avez-vous réparé cet appareil après la modification du routage source? Vous vous demandez si une interaction est nécessaire pour qu'un périphérique final reconnaisse MTOR et que le routage source est en cours d'utilisation.

Non, je viens de mettre à jour le firmware, pas de réparation - les routes source ont été établies peu de temps après avoir reçu les commandes d'enregistrement de route.

BTW, j'ai vu fe mes appareils d'extrémité Xiaomi envoyer l'enregistrement d'itinéraire dans mon reniflement ...

IKEA semble s'intégrer ici aussi, j'aimerais faire plus de tests avec Philips et d'autres appareils de marque pour obtenir plus de détails sur la façon dont divers appareils peuvent être utilisés avec le routage source.

Je pourrais également intervenir pour tester si nous pouvons le faire fonctionner pour Raspbee.

J'ai conduit au-dessus du firmware pendant la nuit. Il semble que le routage source est également utilisé avec le routage maillé activé, mais très rarement. À partir de ca. 2 millions de paquets seulement <5 ont utilisé une route source.

Intéressant! Ce serait bien d'avoir un aperçu de la logique de prise de décision lorsqu'une route source est utilisée et si elle peut être influencée / réglée d'une manière ou d'une autre.

Je suis sur Raspbee I, donc je ne peux pas tester celui-là. Pourriez-vous en créer un également?

Pas sûr, je dois vérifier l'autre configuration de pile utilisée par ConBee I et RaspBee I si cela est possible.

Ce serait génial ...

Je me demande si nous pourrions contourner ce problème avec une sorte de route statique que nous pouvons télécharger sur le firmware au démarrage ou peut-être en fait sur la base d'autres informations.

Oui, je pense qu'il devrait être possible d'injecter des routes dans le cache de routes d'une manière ou d'une autre. Mais quand nous revenons à mes préoccupations mentionnées ci-dessus pour maintenir les routes. Quoi qu'il en soit, à des fins de test et de réseaux fixes, cela fournirait un moyen utile de configurer le routage.

D'accord

De plus, avez-vous réparé cet appareil après la modification du routage source? Vous vous demandez si une interaction est nécessaire pour qu'un périphérique final reconnaisse MTOR et que le routage source est en cours d'utilisation.

Non, je viens de mettre à jour le firmware, pas de réparation - les routes source ont été établies peu de temps après avoir reçu les commandes d'enregistrement de route.

Vous vous demandez si cela aiderait pour l'appareil Philips ...

Bonjour les gars, j'exécute le firmware du routage source Z2M depuis 24 heures (autorise seulement 5 connexions directes). J'ai ~ 35 appareils. Cela fonctionne bien mais j'ai remarqué que les appareils Hue ont besoin d'un cycle d'alimentation pour se reconnecter après que je suis passé du firmware par défaut au firmware SR. Ikea et Xiaomi se sont reconnectés automatiquement. Peut-être que cela peut expliquer certaines parties du comportement de Hue que vous voyez?

Salut,
J'ai retesté mon ampoule TRADFRI E14 WS opal 400lm avec le firmware ikea 2.3.050 et la dernière version bêta de deconz et le dernier firmware sur mon Conbee I. Je peux confirmer que les ampoules et la communication se sont améliorées. Le rappel de scène, l'activation / la désactivation, le fondu entrant et sortant fonctionnent désormais mieux, mais il reste un problème.

Les problèmes documentés ici # 2518 ont été pour la plupart résolus. Il semble que les commandes de groupe (hors de l'interface graphique phoscon) fonctionnent encore mieux. # 2518 fermé

J'ai pourtant remarqué que le changement de CT doit parfois être déclenché plus d'une fois pour réussir s'il est changé à la main et non à la scène.

Un nouveau problème # 2892 qui apparaît est que si dans un groupe une scène est rappelée et que toutes les ampoules appartenant sont allumées (en raison de la scène) et plus tard une autre scène dans ce groupe avec seulement quelques ampoules allumées (définies par scène) est rappelé, les ampoules "indésirables" qui devraient s'éteindre restent allumées.
De plus, si vous désactivez le groupe, seules les ampoules de scène actuellement définies s'éteignent et les autres de la scène précédente (scène précédente du groupe) restent allumées. Ils ont besoin de plusieurs commandes d'arrêt avant de partir.
Le problème est décrit ici, mais il est dans l'API à coup sûr car cela ne fait aucune différence si vous utilisez Phoscon ou l'API elle-même. https://github.com/dresden-elektronik/phoscon-app-beta/issues/52

note supplémentaire: utilisation de la dernière version d'ikea fw 2.3.050 au 20.5.2020

Version de lancement: 1.12.1
20 mai 2020
Nouvelles fonctionnalités et modifications des accessoires:
WS 1.0 (E14, E27, GU10) V-2.3.050.
Correction de l'état activé après la mise à niveau OTA.

Merci pour votre amélioration continue et le travail dépensé.

@manup , des nouvelles pour la version du firmware de la route source de conbee I? J'ai hâte de tester ça :)

@manup , des nouvelles pour la version du firmware de la route source de conbee I? J'ai hâte de tester ça :)

Ma première tentative pour l'activer s'est terminée par un horrible désordre d'erreur de compilation: / Je n'ai pas encore trouvé la cause et j'espère le faire compiler d'une manière ou d'une autre.

@manup , des nouvelles pour la version du firmware de la route source de conbee I? J'ai hâte de tester ça :)

Ma première tentative pour l'activer s'est terminée par un horrible désordre d'erreur de compilation: / Je n'ai pas encore trouvé la cause et j'espère le faire compiler d'une manière ou d'une autre.

Hmmmm ne sonne pas très bien ... @manup , j'aimerais beaucoup aider, mais je n'ai pas accès à ce code.

@manup , des progrès?

@manup , pssst! 😁

Ce problème a été automatiquement marqué comme obsolète car il n'a pas eu d'activité récente. Il sera fermé si aucune autre activité n'a lieu. Merci pour vos contributions.

Toujours en cours. @manup des progrès et / ou des

@djwlindenaar @ JBS5 J'ai demandé à @manup une mise à jour.

Oui, toujours un problème - même si beaucoup moins qu'avant.

Quelle est la dernière sur la question?

J'ai environ 20 GU10 à spectre blanc (première génération) connectés à un pont Hue et dans le cadre de la rationalisation de mon réseau zigbee, je voulais migrer tous mes appareils vers Deconz.

La teinte est assez stable mais les lumières sont toujours déconnectées de temps en temps (par exemple, une fois par semaine, une lumière est déconnectée). J'ai juste besoin de redémarrer les ampoules pour les ressusciter.

Deconz est-il plus ou moins stable?

Non Deconz n'est pas plus stable, j'ai aussi environ 40 lampes Ikea et parfois certaines se déconnectent

@salopette Je n'ai pas cette expérience. Pourriez-vous ouvrir un numéro distinct? Des journaux?

@Mimiix Ce problème concerne les lumières qui se déconnectent. Pourquoi ouvrir un nouveau numéro?

Pareil ici. Les lumières se déconnectent encore de temps en temps. Mais il s'est beaucoup amélioré avec le temps. Quand j'ai commencé à utiliser deCONZ en 2018, je devais faire fonctionner mes lampes ikea quotidiennement. Je rencontre le plus souvent ce problème avec un panneau FLOALT, mais c'est aussi la lumière la plus éloignée de mon Conbee Stick.

@ JBS5 Parce que nous ne savons rien de la configuration de cet utilisateur. Pas de version, pas de logs, pas d'informations sur l'installation. Nous ne sommes pas en mesure de déterminer si son problème est lié à cela.

L'ajout de commentaires sans aucune information n'aide pas cela dans un cas. C'est pourquoi je veux des problèmes séparés afin que nous ayons une meilleure vue d'ensemble.

Je demande une fois à @manup en privé d'examiner cela et de lui donner la priorité.

@djwlindenaar y a creusé profondément. Je doute que l'inspection d'une autre configuration d'utilisateurs puisse faire quoi que ce soit sur un problème qui semble exister en général avec les lampes ikea. Je préférerais me concentrer sur l’enquête existante plutôt qu’en commencer une autre.

Annonce générale:

Je viens de parler avec @manup en privé à ce sujet. Il m'a dit ce qui suit:

`` Que le firmware obtiendra une mise à jour en ce qui concerne les problèmes de routage, et que le nouveau réseau devrait, espérons-le, aider à recréer les problèmes (ce qui n'était pas possible auparavant).
Mon plan est que ce prochain micrologiciel soit disponible dans les 2 à 3 prochaines semaines.

Certains changements sont déjà effectués mais ne sont pas encore rendus publics.
''

Je vous tiendrai tous au courant.

Annonce générale:

Je viens de parler avec @manup en privé à ce sujet. Il m'a dit ce qui suit:

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.

Je vous tiendrai tous au courant.

3 semaines plus tard, une mise à jour à ce sujet?

@ JBS5 Pas encore 3 semaines. J'ai attendu le bot périmé ici;)

Pmed @manup ce matin encore. Vous avez la réponse suivante:

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.

J'ai demandé une ETA et il est dessus en ce moment.

@ JBS5 Pas encore 3 semaines. J'ai attendu le bot périmé ici;)

Pmed @manup ce matin encore. Vous avez la réponse suivante:

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.

J'ai demandé une ETA et il est dessus en ce moment.

Eh bien, vous avez fait une promesse à la communauté, donc c'est normal qu'ils vous tiennent à cette promesse, 21 jours / 7 jours = 3 semaines
alors c'est boiteux de se cacher derrière le stalebot alors que ce problème est déjà actif depuis février 2019. Lorsque vous voulez être le porte-parole de Dresde, agissez comme ça ou laissez juste @manup gérer ça :)

Alors, quelle est l'ETA maintenant les 2-3 semaines sont passées

@lubbertkramer Veuillez être raisonnable ici, le bot obsolète était une blague. La seule promesse faite précédemment par @Mimiix est de partager les mises à jour une fois que certaines sont disponibles, il est donc parfaitement valable de se renseigner sur l'état actuel. Maintenant, pour l'ETA, rien n'a été promis et je comprends qu'aucune ne le sera, car il s'agit de choses complexes. Comme je le sais quand on parle de choses désagréables, ce n'est malheureusement rien qui puisse être réglé en une journée, ne se montrer qu'après un temps considérable ou faire évoluer des effets secondaires imprévus.

Donc, dans ce sens, soyez patient et laissez les gars travailler dessus (c'est encore le temps des vacances d'ailleurs). Quand on parle de la prochaine version, c'est dans 1,5 semaines pour lever la main et demander des nouvelles.

@ JBS5 Pas encore 3 semaines. J'ai attendu le bot périmé ici;)

Pmed @manup ce matin encore. Vous avez la réponse suivante:

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.

J'ai demandé une ETA et il est dessus en ce moment.

Les problèmes de redémarrage ne sont pas liés à ce problème, je suppose?
Qu'en est-il des modifications de routage et des améliorations de débogage mentionnées? Ces améliorations de débogage sont-elles liées à ce problème?

Et ces changements de routage sont-ils basés sur les résultats de @djwlindenaar ou est-ce que @manup peut déjà être plus précis?

@lubbertkramer Veuillez être raisonnable ici, le bot obsolète était une blague. La seule promesse faite précédemment par @Mimiix est de partager les mises à jour une fois que certaines sont disponibles, il est donc parfaitement valable de se renseigner sur l'état actuel. Maintenant, pour l'ETA, rien n'a été promis et je comprends qu'aucune ne le sera, car il s'agit de choses complexes. Comme je le sais quand on parle de choses désagréables, ce n'est malheureusement rien qui puisse être réglé en une journée, ne se montrer qu'après un temps considérable ou faire évoluer des effets secondaires imprévus.

Donc, dans ce sens, soyez patient et laissez les gars travailler dessus (c'est encore le temps des vacances d'ailleurs). Quand on parle de la prochaine version, c'est dans 1,5 semaines pour lever la main et demander des nouvelles.

Je pense qu'il est plus que raisonnable de contraindre les gens à communiquer ou à faire des promesses sans faire de «blagues» quand 2-3 semaines se sont écoulées par 3 semaines sans suivi. Les utilisateurs qui ont beaucoup enquêté et ont répondu ici ont déjà évolué faute de suivi / communication.

Alors revenons sur la question, quelles sont les dernières informations sur ce problème?

@ JBS5 Pas encore 3 semaines. J'ai attendu le bot périmé ici;)

Pmed @manup ce matin encore. Vous avez la réponse suivante:

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.

J'ai demandé une ETA et il est dessus en ce moment.

Eh bien, vous avez fait une promesse à la communauté, donc c'est normal qu'ils vous tiennent à cette promesse, 21 jours / 7 jours = 3 semaines
alors c'est boiteux de se cacher derrière le stalebot alors que ce problème est déjà actif depuis février 2019. Lorsque vous voulez être le porte-parole de Dresde, agissez comme ça ou laissez juste @manup gérer ça :)

Alors, quelle est l'ETA maintenant les 2-3 semaines sont passées

Je n'ai aucun problème à laisser ce problème derrière moi lorsque vous agissez ainsi. Je ne suis en aucun cas un porte-parole, je tends le cou ici pour que les choses soient réglées car j'ai une connexion directe. Le bot obsolète que j'utilise pour suivre les problèmes et je reçois la notification. Je m'attends à ce que manup me revienne et si le délai est écoulé, le bot périmé m'aide à le rappeler.

Alors non, ce n'est pas «boiteux» de se cacher derrière. Si vous faisiez ce que j'ai fait pour la communauté, vous en sauriez mieux que cela. Aussi pour ajouter cela, ce n'est pas que je n'ai pas eu autre chose à faire dans la vie.

_Soyez le changement que vous voulez voir dans ce monde_

@ JBS5 Pas encore 3 semaines. J'ai attendu le bot périmé ici;)
Pmed @manup ce matin encore. Vous avez la réponse suivante:

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.

J'ai demandé une ETA et il est dessus en ce moment.

Eh bien, vous avez fait une promesse à la communauté, donc c'est normal qu'ils vous tiennent à cette promesse, 21 jours / 7 jours = 3 semaines
alors c'est boiteux de se cacher derrière le stalebot alors que ce problème est déjà actif depuis février 2019. Lorsque vous voulez être le porte-parole de Dresde, agissez comme ça ou laissez juste @manup gérer ça :)
Alors, quelle est l'ETA maintenant les 2-3 semaines sont passées

Je n'ai aucun problème à laisser ce problème derrière moi lorsque vous agissez ainsi. Je ne suis en aucun cas un porte-parole, je tends le cou ici pour que les choses soient réglées car j'ai une connexion directe. Le bot obsolète que j'utilise pour suivre les problèmes et je reçois la notification. Je m'attends à ce que manup me revienne et si le délai est écoulé, le bot périmé m'aide à le rappeler.

Alors non, ce n'est pas «boiteux» de se cacher derrière. Si vous faisiez ce que j'ai fait pour la communauté, vous en sauriez mieux que cela. Aussi pour ajouter cela, ce n'est pas que je n'ai pas eu autre chose à faire dans la vie.

_Soyez le changement que vous voulez voir dans ce monde_

Personne ne vous demande ni ne vous oblige à être l'intermédiaire en tant qu'utilisateur, donc encore une fois, au lieu de flamboyer et de changer le pouvoir des fleurs, laissez ce problème en tant que porte-parole ou revenez au problème et aux dernières informations.

Les 2-3 semaines que vous avez postées comme annonce générale se sont écoulées depuis plus de 3 semaines maintenant, alors quel est le suivi?

@ JBS5 Pas encore 3 semaines. J'ai attendu le bot périmé ici;)
Pmed @manup ce matin encore. Vous avez la réponse suivante:

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.

J'ai demandé une ETA et il est dessus en ce moment.

Eh bien, vous avez fait une promesse à la communauté, donc c'est normal qu'ils vous tiennent à cette promesse, 21 jours / 7 jours = 3 semaines
alors c'est boiteux de se cacher derrière le stalebot alors que ce problème est déjà actif depuis février 2019. Lorsque vous voulez être le porte-parole de Dresde, agissez comme ça ou laissez juste @manup gérer ça :)
Alors, quelle est l'ETA maintenant les 2-3 semaines sont passées

Je n'ai aucun problème à laisser ce problème derrière moi lorsque vous agissez ainsi. Je ne suis en aucun cas un porte-parole, je tends le cou ici pour que les choses soient réglées car j'ai une connexion directe. Le bot obsolète que j'utilise pour suivre les problèmes et je reçois la notification. Je m'attends à ce que manup me revienne et si le délai est écoulé, le bot périmé m'aide à le rappeler.
Alors non, ce n'est pas «boiteux» de se cacher derrière. Si vous faisiez ce que j'ai fait pour la communauté, vous en sauriez mieux que cela. Aussi pour ajouter cela, ce n'est pas que je n'ai pas eu autre chose à faire dans la vie.
_Soyez le changement que vous voulez voir dans ce monde_

Personne ne vous demande ni ne vous oblige à être l'intermédiaire en tant qu'utilisateur, donc encore une fois, au lieu de flamboyer et de changer le pouvoir des fleurs, laissez ce problème en tant que porte-parole ou revenez au problème et aux dernières informations.

Les 2-3 semaines que vous avez postées comme annonce générale se sont écoulées depuis plus de 3 semaines maintenant, alors quel est le suivi?

Tout ce que j'avais, c'est ce que j'ai mentionné. S'il vous plaît laissez-moi vous conseiller de garder vos émotions sous contrôle. Je comprends votre colère, mais le manque de respect n'aide pas. Je n'accepte aucune flambée ici. Gardez-le sur le sujet et le civil. J'explique simplement quels sont mes arguments et pourquoi je fais les choses comme je le fais.

Si vous souhaitez lancer un problème pour vous plaindre, soyez mon invité. Ne le faites pas dans ce numéro.

@ JBS5 Pas encore 3 semaines. J'ai attendu le bot périmé ici;)
Pmed @manup ce matin encore. Vous avez la réponse suivante:

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.

J'ai demandé une ETA et il est dessus en ce moment.

Eh bien, vous avez fait une promesse à la communauté, donc c'est normal qu'ils vous tiennent à cette promesse, 21 jours / 7 jours = 3 semaines
alors c'est boiteux de se cacher derrière le stalebot alors que ce problème est déjà actif depuis février 2019. Lorsque vous voulez être le porte-parole de Dresde, agissez comme ça ou laissez juste @manup gérer ça :)
Alors, quelle est l'ETA maintenant les 2-3 semaines sont passées

Je n'ai aucun problème à laisser ce problème derrière moi lorsque vous agissez ainsi. Je ne suis en aucun cas un porte-parole, je tends le cou ici pour que les choses soient réglées car j'ai une connexion directe. Le bot obsolète que j'utilise pour suivre les problèmes et je reçois la notification. Je m'attends à ce que manup me revienne et si le délai est écoulé, le bot périmé m'aide à le rappeler.
Alors non, ce n'est pas «boiteux» de se cacher derrière. Si vous faisiez ce que j'ai fait pour la communauté, vous en sauriez mieux que cela. Aussi pour ajouter cela, ce n'est pas que je n'ai pas eu autre chose à faire dans la vie.
_Soyez le changement que vous voulez voir dans ce monde_

Personne ne vous demande ni ne vous oblige à être l'intermédiaire en tant qu'utilisateur, donc encore une fois, au lieu de flamboyer et de changer le pouvoir des fleurs, laissez ce problème en tant que porte-parole ou revenez au problème et aux dernières informations.
Les 2-3 semaines que vous avez postées comme annonce générale se sont écoulées depuis plus de 3 semaines maintenant, alors quel est le suivi?

Tout ce que j'avais, c'est ce que j'ai mentionné. S'il vous plaît laissez-moi vous conseiller de garder vos émotions sous contrôle. Je comprends votre colère, mais le manque de respect n'aide pas. Je n'accepte aucune flambée ici. Gardez-le sur le sujet et le civil. J'explique simplement quels sont mes arguments et pourquoi je fais les choses comme je le fais.

Si vous souhaitez lancer un problème pour vous plaindre, soyez mon invité. Ne le faites pas dans ce numéro.

Le seul embarras dans ce problème est manup et Dresde n'est évidemment pas capable de résoudre ce problème. Conbee est un produit commercial et avec cela vient des responsabilités. C'est pourquoi beaucoup d'entre nous ont déjà quitté deCONZ / Conbee pour les puces TI et Z2M, qui fonctionnent parfaitement depuis.

@ JBS5 Pas encore 3 semaines. J'ai attendu le bot périmé ici;)
Pmed @manup ce matin encore. Vous avez la réponse suivante:

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.

J'ai demandé une ETA et il est dessus en ce moment.

Eh bien, vous avez fait une promesse à la communauté, donc c'est normal qu'ils vous tiennent à cette promesse, 21 jours / 7 jours = 3 semaines
alors c'est boiteux de se cacher derrière le stalebot alors que ce problème est déjà actif depuis février 2019. Lorsque vous voulez être le porte-parole de Dresde, agissez comme ça ou laissez juste @manup gérer ça :)
Alors, quelle est l'ETA maintenant les 2-3 semaines sont passées

Je n'ai aucun problème à laisser ce problème derrière moi lorsque vous agissez ainsi. Je ne suis en aucun cas un porte-parole, je tends le cou ici pour que les choses soient réglées car j'ai une connexion directe. Le bot obsolète que j'utilise pour suivre les problèmes et je reçois la notification. Je m'attends à ce que manup me revienne et si le délai est écoulé, le bot périmé m'aide à le rappeler.
Alors non, ce n'est pas «boiteux» de se cacher derrière. Si vous faisiez ce que j'ai fait pour la communauté, vous en sauriez mieux que cela. Aussi pour ajouter cela, ce n'est pas que je n'ai pas eu autre chose à faire dans la vie.
_Soyez le changement que vous voulez voir dans ce monde_

Personne ne vous demande ni ne vous oblige à être l'intermédiaire en tant qu'utilisateur, donc encore une fois, au lieu de flamboyer et de changer le pouvoir des fleurs, laissez ce problème en tant que porte-parole ou revenez au problème et aux dernières informations.
Les 2-3 semaines que vous avez postées comme annonce générale se sont écoulées depuis plus de 3 semaines maintenant, alors quel est le suivi?

Tout ce que j'avais, c'est ce que j'ai mentionné. S'il vous plaît laissez-moi vous conseiller de garder vos émotions sous contrôle. Je comprends votre colère, mais le manque de respect n'aide pas. Je n'accepte aucune flambée ici. Gardez-le sur le sujet et le civil. J'explique simplement quels sont mes arguments et pourquoi je fais les choses comme je le fais.

Si vous souhaitez lancer un problème pour vous plaindre, soyez mon invité. Ne le faites pas dans ce numéro.

Et encore une fois, vous ne répondez pas ou ne mettez pas à jour le statut qui est demandé plusieurs fois et la seule chose que vous faites est de passer à une discussion hors-sujet où vous auriez déjà pu donner une mise à jour comme demandé à la fin de chaque message. Vous vous vantez des connexions / invitations directes dans les réunions de développement, vous devriez donc être au courant de l'état de ce problème et pouvez mettre à jour tous les utilisateurs qui lisent ici.

Donc, encore une fois, postez une mise à jour ou arrêtez de publier hors-sujet, je suppose que c'est votre travail en tant que modérateur de la communauté au lieu de maintenir la discussion hors-sujet en vie :)

Annonce générale:

Je viens de parler avec @manup en privé à ce sujet. Il m'a dit ce qui suit:

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.

Je vous tiendrai tous au courant.

Les 2-3 semaines que vous avez publiées comme annonce générale se sont écoulées depuis plus de 3 semaines maintenant, alors quel est le suivi, à quoi pouvons-nous nous attendre?

Un nouveau reliese est sur le point d'arriver dans moins d'une semaine. Je suggère de rester calme
et attendez de voir ce que les nouveaux changements apporteront

J'ai beaucoup d'amis de métier qui travaillent sans problème depuis plus d'un an.
Récemment, j'ai commencé à avoir des problèmes avec une seule de mes lampes Tradfri
a commencé à tomber et à se connecter au maillage toutes les 15 minutes environ. 15 minutes
accessible, 15 min inaccessible. J'ai fait beaucoup de tests pour trouver le problème.
Devinez quoi ... les problèmes étaient-ils? Ce n'était pas deCONZ mais de mon WiFi
programme de répéteur un mis à nouveau dessus.

Ne soyez pas si sûr que les problèmes sont toujours liés à deCONZ, parfois ce n'est pas le cas.

Le dimanche 6 septembre 2020 11:38, lubbertkramer [email protected] a écrit:

@ JBS5 https://github.com/JBS5 Pas encore 3 semaines. Attendu le bot périmé
ici ;)
Pmed @manup https://github.com/manup ce matin encore. Avoir le
réponse suivante:

J'ai rampé dans le micrologiciel ces derniers jours pour enquêter sur les problèmes de redémarrage et trouvé quelques bugs désagréables.
Il contiendra également quelques changements de routage, espérons le sortir avec la prochaine version.

Les améliorations de débogage suivront après la prochaine version stable.

J'ai demandé une ETA et il est dessus en ce moment.

Eh bien, vous avez fait une promesse à la communauté, donc c'est normal qu'ils vous tiennent
à cette promesse, 21 jours / 7 jours = 3 semaines
alors c'est nul de se cacher derrière le stalebot quand ce problème est déjà
actif depuis février 2019. Quand vous voulez être le porte-parole de Dresde
agissez comme ça ou laissez juste @manup https://github.com/manup gérer ça :)
Alors, quelle est l'ETA maintenant les 2-3 semaines sont passées

Je n'ai aucun problème à laisser ce problème derrière moi lorsque vous agissez ainsi.
Je ne suis en aucun cas un porte-parole, je tends le cou ici pour obtenir des choses
trié car j'ai une connexion directe. Le bot obsolète que j'utilise pour suivre
problèmes et je reçois la notification. Je m'attends à ce que l'homme revienne vers moi et
si le délai est passé, le bot périmé m'aide à me rappeler.
Alors non, ce n'est pas «boiteux» de se cacher derrière. Si tu as fait ce que j'ai fait pour le
communauté, vous le sauriez mieux que cela. Aussi pour ajouter ça, ce n'est pas ça
Je n'ai pas eu autre chose à faire dans la vie.
Soyez le changement que vous voulez voir dans ce monde

Personne ne vous demande ni ne vous oblige à être l’intermédiaire en tant qu’utilisateur, donc encore une fois
au lieu de flamboyer et de changer le pouvoir des fleurs, laissez ce problème
porte-parole ou revenez au problème et aux dernières informations.
Les 2-3 semaines se sont écoulées que vous avez postées comme annonce générale par
plus de 3 semaines maintenant, alors quel est le suivi?

Tout ce que j'avais, c'est ce que j'ai mentionné. S'il vous plaît laissez-moi vous conseiller de garder votre
émotions sous contrôle. Je comprends ta colère, mais manque de respect
n'aide pas. Je n'accepte aucune flambée ici. Gardez-le sur le sujet et
civil. J'explique simplement quels sont mes arguments et pourquoi je fais les choses comme je le fais.

Si vous souhaitez lancer un problème pour vous plaindre, soyez mon invité. Ne le fais pas
faites-le dans ce numéro.

Et encore une fois, vous ne répondez pas ou ne mettez pas à jour le statut qui est demandé
plusieurs fois et la seule chose que vous faites est de passer à un hors-sujet
discussion où vous auriez déjà pu donner une mise à jour comme demandé à la fin
de chaque poste. Vous vous vantez des connexions / invitations directes dans
les réunions de développement, vous devriez donc être au courant de l'état de
ce problème et pourrait mettre à jour tous les utilisateurs de lecture ici.

Donc, encore une fois, postez une mise à jour ou arrêtez de publier hors sujet :)

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment-687726432 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AO4LI5G32N546L6GKHSHISLSENDABANCNFSM4GXPM2DA
.

@ morfei1 et @Mimiix La prochaine version devrait arriver dans environ 2 semaines si vous regardez comment la sortie fonctionne par DE ("15e" = peu avant d'être payé). Et ce n'est pas un mot si un correctif est en cours avec ou sans vacances.
Et est-ce que certains disent (et je l'ai souvent) comment le support officiel fonctionne alors que les clients ont de gros problèmes.
Off the record: ZHA sera dans 1 à 2 semaines de support officiel pour Silabs EZSP toutes les versions de leurs protocoles de pile, donc je pense qu'un Sonoff Zigbee Bridge ou Elelabs-ELU013 / ELR023 est mieux d'investir de l'argent et d'obtenir plus de puissance RF et SoC alors les produits DE et un meilleur soutien de la communauté.
Mais j'attends deCONZ REST-API version 2 avant de laisser tous les produits DE RIP.

@ JBS5 Pas encore 3 semaines. J'ai attendu le bot périmé ici;)
Pmed @manup ce matin encore. Vous avez la réponse suivante:

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.

J'ai demandé une ETA et il est dessus en ce moment.

Eh bien, vous avez fait une promesse à la communauté, donc c'est normal qu'ils vous tiennent à cette promesse, 21 jours / 7 jours = 3 semaines
alors c'est boiteux de se cacher derrière le stalebot alors que ce problème est déjà actif depuis février 2019. Lorsque vous voulez être le porte-parole de Dresde, agissez comme ça ou laissez juste @manup gérer ça :)
Alors, quelle est l'ETA maintenant les 2-3 semaines sont passées

Je n'ai aucun problème à laisser ce problème derrière moi lorsque vous agissez ainsi. Je ne suis en aucun cas un porte-parole, je tends le cou ici pour que les choses soient réglées car j'ai une connexion directe. Le bot obsolète que j'utilise pour suivre les problèmes et je reçois la notification. Je m'attends à ce que manup me revienne et si le délai est écoulé, le bot périmé m'aide à le rappeler.
Alors non, ce n'est pas «boiteux» de se cacher derrière. Si vous faisiez ce que j'ai fait pour la communauté, vous en sauriez mieux que cela. Aussi pour ajouter cela, ce n'est pas que je n'ai pas eu autre chose à faire dans la vie.
_Soyez le changement que vous voulez voir dans ce monde_

Personne ne vous demande ni ne vous oblige à être l'intermédiaire en tant qu'utilisateur, donc encore une fois, au lieu de flamboyer et de changer le pouvoir des fleurs, laissez ce problème en tant que porte-parole ou revenez au problème et aux dernières informations.
Les 2-3 semaines que vous avez postées comme annonce générale se sont écoulées depuis plus de 3 semaines maintenant, alors quel est le suivi?

Tout ce que j'avais, c'est ce que j'ai mentionné. S'il vous plaît laissez-moi vous conseiller de garder vos émotions sous contrôle. Je comprends votre colère, mais le manque de respect n'aide pas. Je n'accepte aucune flambée ici. Gardez-le sur le sujet et le civil. J'explique simplement quels sont mes arguments et pourquoi je fais les choses comme je le fais.
Si vous souhaitez lancer un problème pour vous plaindre, soyez mon invité. Ne le faites pas dans ce numéro.

Et encore une fois, vous ne répondez pas ou ne mettez pas à jour le statut qui est demandé plusieurs fois et la seule chose que vous faites est de passer à une discussion hors-sujet où vous auriez déjà pu donner une mise à jour comme demandé à la fin de chaque message. Vous vous vantez des connexions / invitations directes dans les réunions de développement, vous devriez donc être au courant de l'état de ce problème et pouvez mettre à jour tous les utilisateurs qui lisent ici.

Donc, encore une fois, postez une mise à jour ou arrêtez de publier hors-sujet, je suppose que c'est votre travail en tant que modérateur de la communauté au lieu de maintenir la discussion hors-sujet en vie :)

Annonce générale:
Je viens de parler avec @manup en privé à ce sujet. Il m'a dit ce qui suit:

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.

Je vous tiendrai tous au courant.

Les 2-3 semaines que vous avez publiées comme annonce générale se sont écoulées depuis plus de 3 semaines maintenant, alors quel est le suivi, à quoi pouvons-nous nous attendre?

Pour répondre directement à votre question: c'est ce que @manup m'a dit après que je lui ai posé à nouveau. Je ne peux forcer personne à faire quelque chose. Je vais demander à nouveau après le week-end.

Ce sera un dernier avertissement général sur vos commentaires. Le prochain commentaire hors sujet ici consiste à verrouiller ce problème jusqu'à ce qu'il y ait plus de nouvelles.

@ JBS5 Pas encore 3 semaines. J'ai attendu le bot périmé ici;)
Pmed @manup ce matin encore. Vous avez la réponse suivante:

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.

J'ai demandé une ETA et il est dessus en ce moment.

Eh bien, vous avez fait une promesse à la communauté, donc c'est normal qu'ils vous tiennent à cette promesse, 21 jours / 7 jours = 3 semaines
alors c'est boiteux de se cacher derrière le stalebot alors que ce problème est déjà actif depuis février 2019. Lorsque vous voulez être le porte-parole de Dresde, agissez comme ça ou laissez juste @manup gérer ça :)
Alors, quelle est l'ETA maintenant les 2-3 semaines sont passées

Je n'ai aucun problème à laisser ce problème derrière moi lorsque vous agissez ainsi. Je ne suis en aucun cas un porte-parole, je tends le cou ici pour que les choses soient réglées car j'ai une connexion directe. Le bot obsolète que j'utilise pour suivre les problèmes et je reçois la notification. Je m'attends à ce que manup me revienne et si le délai est écoulé, le bot périmé m'aide à le rappeler.
Alors non, ce n'est pas «boiteux» de se cacher derrière. Si vous faisiez ce que j'ai fait pour la communauté, vous en sauriez mieux que cela. Aussi pour ajouter cela, ce n'est pas que je n'ai pas eu autre chose à faire dans la vie.
_Soyez le changement que vous voulez voir dans ce monde_

Personne ne vous demande ni ne vous oblige à être l'intermédiaire en tant qu'utilisateur, donc encore une fois, au lieu de flamboyer et de changer le pouvoir des fleurs, laissez ce problème en tant que porte-parole ou revenez au problème et aux dernières informations.
Les 2-3 semaines que vous avez postées comme annonce générale se sont écoulées depuis plus de 3 semaines maintenant, alors quel est le suivi?

Tout ce que j'avais, c'est ce que j'ai mentionné. S'il vous plaît laissez-moi vous conseiller de garder vos émotions sous contrôle. Je comprends votre colère, mais le manque de respect n'aide pas. Je n'accepte aucune flambée ici. Gardez-le sur le sujet et le civil. J'explique simplement quels sont mes arguments et pourquoi je fais les choses comme je le fais.
Si vous souhaitez lancer un problème pour vous plaindre, soyez mon invité. Ne le faites pas dans ce numéro.

Et encore une fois, vous ne répondez pas ou ne mettez pas à jour le statut qui est demandé plusieurs fois et la seule chose que vous faites est de passer à une discussion hors-sujet où vous auriez déjà pu donner une mise à jour comme demandé à la fin de chaque message. Vous vous vantez des connexions / invitations directes dans les réunions de développement, vous devriez donc être au courant de l'état de ce problème et pouvez mettre à jour tous les utilisateurs qui lisent ici.
Donc, encore une fois, postez une mise à jour ou arrêtez de publier hors-sujet, je suppose que c'est votre travail en tant que modérateur de la communauté au lieu de maintenir la discussion hors-sujet en vie :)

Annonce générale:
Je viens de parler avec @manup en privé à ce sujet. Il m'a dit ce qui suit:

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.

Je vous tiendrai tous au courant.

Les 2-3 semaines que vous avez publiées comme annonce générale se sont écoulées depuis plus de 3 semaines maintenant, alors quel est le suivi, à quoi pouvons-nous nous attendre?

Pour répondre directement à votre question: c'est ce que @manup m'a dit après que je lui ai posé à nouveau. Je ne peux forcer personne à faire quelque chose. Je vais demander à nouveau après le week-end.

Ce sera un dernier avertissement général sur vos commentaires. Le prochain commentaire hors sujet ici consiste à verrouiller ce problème jusqu'à ce qu'il y ait plus de nouvelles.

C'est un peu une réponse, donc quand je lis correctement, nous pouvons nous attendre à une réponse plus détaillée plus tard cette semaine, car alors près de 4 semaines se sont écoulées au lieu des 2-3 que @manup avait communiqué par votre intermédiaire comme annonce générale que la mise à jour serait disponible

@Mimiix si vous voyez l'envie de fermer ce numéro qui est presque ouvert depuis deux ans avec beaucoup d'informations d'utilisateurs très solidaires et dévoués sans solution, je ne suis pas la personne qui peut vous retenir, c'est à vous en tant que communauté porte-parole :)

@lubbertkramer J'ai dit Lock, not close.

Et avec cela, je vais verrouiller ce problème. Je vais débloquer dans quelques jours ou lorsque Manuel a répondu ici.

Salut encore, suppose qu'il est plus que temps pour une mise à jour sur le problème.

Mais tout d'abord, si quelqu'un est à blâmer ici, c'est moi et seulement moi. Je comprends la frustration mais il n'y a pas de place pour être impoli ici envers @Mimiix , donc soyons civils, si ce n'était pas pour lui et tout ce qu'il a accompli pour cette communauté, je n'aurais pas le temps de faire avancer les choses dans le noyau deCONZ et le firmware et travaille sur des corrections de bogues et des améliorations. C'était plus facile dans le passé, mais comme tout cela a évolué comme un fou, les listes de tâches, les appels d'assistance et les e-mails ont également augmenté comme un fou, les bogues de la boucle de redémarrage étant mon enfer personnel. Merci aux modérateurs et à tous les formidables développeurs et contributeurs, les choses sont bien meilleures maintenant, pour s'attaquer à des problèmes plus profonds, un à la fois.

Mise à jour en cours

(Aperçu pour la prochaine version)

J'ai beaucoup testé le routage source et j'ai expérimenté les résultats de ce numéro et divers journaux de renifleurs. Passez beaucoup de temps à faire fonctionner le routage source "automatique" de manière fiable, en fonction des commandes Route Record entrantes. C'est essentiellement ce que font la plupart des implémentations avec le routage de sourcing - comme le firmware de routage source pour zigbee2mqtt. Cela fonctionne parfois, mais il semble y avoir une plus grande dynamique sur la façon / si une route source est choisie (et conservée) en fonction des valeurs LQI / RSSI qu'un saut d'enregistrement de route voit de ses voisins, dans les réseaux mixtes, c'est délicat parce que les différences dans la pile et le matériel. La qualité de la liaison peut également être assez dynamique si les gens se déplacent entre les nœuds et que les portes sont ouvertes et fermées, ce qui affecte malheureusement également le routage.

Par conséquent, j'ai expérimenté l'idée de configurer des routes sources fixes vers un nœud de destination. Dans de nombreux cas, seule une partie du réseau a des problèmes de routage, ici il peut être avantageux de spécifier une route source fixe où:

• Les routes sources peuvent être spécifiées en option par nœud.
• Chaque saut doit toujours être alimenté.
• Les positions de saut sur le chemin doivent être raisonnables. Dans certains cas, un utilisateur peut avoir un meilleur plan d'acheminement des paquets que ce que l'algorithme automatique est capable de comprendre.

Pour ce faire, le protocole du micrologiciel a été étendu pour fournir éventuellement une route source par requête APS. Il n'y a pas de limite sur le nombre de routes sources pouvant être configurées, le micrologiciel n'a besoin d'en garder que quelques-unes en mémoire pour les requêtes et l'ACK.

deCONZ détermine automatiquement si chaque saut de la route est accessible et utilise uniquement dans ce cas la route source.
Dans les coulisses, les routes sources sont configurées avec les adresses MAC des nœuds pour résister aux changements d'adresse NWK.

Créer un itinéraire source fixe

• Dans l'interface graphique deCONZ, sélectionnez tous les sauts tout en maintenant la touche CTRL (sélection multiple) à partir du coordinateur (source) jusqu'au nœud de destination. Important, il doit y avoir au moins un saut entre la source et la destination.
• Cliquez avec le bouton droit sur le nœud de destination pour ouvrir le menu contextuel.
• Sélectionnez "Ajouter une route source".

Cela créera la nouvelle route source, visualisée par la ligne bleuâtre, les marques d'extrémité rouges vers le nœud de destination.

(Dans les versions ultérieures, il sera possible de spécifier d'autres routes de secours, mais je dois trouver une bonne interface utilisateur pour cela.)

Pour supprimer une route source: Sélectionnez «Supprimer la route source» dans le menu contextuel du nœud de destination.

L'itinéraire sera utilisé pour la toute prochaine demande:

Cela fonctionne plutôt bien et permet l'écrasement manuel du routage si nécessaire, ce qui devrait également être pratique pour les tests.
Actuellement, cela ne fonctionne que lorsqu'il est configuré via GUI, mais il devrait être disponible via REST-API trop tard.

Cela va-t-il tout régler?

Peu probable, mais cela devrait améliorer le routage vers les destinations (le routage sur les nœuds lui-même ne peut pas être configuré). Notez que les routes sources fixes ne sont bonnes que pour les routeurs, car les périphériques finaux ont tendance à changer le parent et la route source ne fonctionnerait plus, dans ce cas, le routage source automatique pourrait mieux fonctionner.

Quand va-t-il sortir?

Bientôt, dans la prochaine version 2.05.81, j'ai les éléments suivants (plutôt légers) sur la liste des choses à faire pour la version:

• Stocker / restaurer les routes sources dans la base de données.
• Correction de la gestion du compteur de sécurité NWK pour corriger la sauvegarde entre différents ConBee / RaspBee et redémarrer le bug, rien ne fonctionne.
• Laissez GCFFlasher vérifier que le micrologiciel fonctionne après la mise à jour.

Donc, avec @manup sa réponse, une réponse a été donnée. Veuillez rester sur le sujet et sur le sujet.

Salut encore, suppose qu'il est plus que temps pour une mise à jour sur le problème.

Mise à jour en cours

(Aperçu pour la prochaine version)

J'ai beaucoup testé le routage source et j'ai expérimenté les résultats de ce numéro et divers journaux de renifleurs. Passez beaucoup de temps à faire fonctionner le routage source "automatique" de manière fiable, en fonction des commandes Route Record entrantes. C'est essentiellement ce que font la plupart des implémentations avec le routage de sourcing - comme le firmware de routage source pour zigbee2mqtt. Cela fonctionne parfois, mais il semble y avoir une plus grande dynamique sur la façon / si une route source est choisie (et conservée) en fonction des valeurs LQI / RSSI qu'un saut d'enregistrement de route voit de ses voisins, dans les réseaux mixtes, c'est délicat parce que les différences dans la pile et le matériel. La qualité de la liaison peut également être assez dynamique si les gens se déplacent entre les nœuds et que les portes sont ouvertes et fermées, ce qui affecte malheureusement également le routage.

Par conséquent, j'ai expérimenté l'idée de configurer des routes sources fixes vers un nœud de destination. Dans de nombreux cas, seule une partie du réseau a des problèmes de routage, ici il peut être avantageux de spécifier une route source fixe où:

• Les routes sources peuvent être spécifiées en option par nœud.
• Chaque saut doit toujours être alimenté.
• Les positions de saut sur le chemin doivent être raisonnables. Dans certains cas, un utilisateur peut avoir un meilleur plan d'acheminement des paquets que ce que l'algorithme automatique est capable de comprendre.

Pour ce faire, le protocole du micrologiciel a été étendu pour fournir éventuellement une route source par requête APS. Il n'y a pas de limite sur le nombre de routes sources pouvant être configurées, le micrologiciel n'a besoin d'en garder que quelques-unes en mémoire pour les requêtes et l'ACK.

deCONZ détermine automatiquement si chaque saut de la route est accessible et utilise uniquement dans ce cas la route source.
Dans les coulisses, les routes sources sont configurées avec les adresses MAC des nœuds pour résister aux changements d'adresse NWK.

Créer un itinéraire source fixe

• Dans l'interface graphique deCONZ, sélectionnez tous les sauts tout en maintenant la touche CTRL (sélection multiple) à partir du coordinateur (source) jusqu'au nœud de destination. Important, il doit y avoir au moins un saut entre la source et la destination.
• Cliquez avec le bouton droit sur le nœud de destination pour ouvrir le menu contextuel.
• Sélectionnez "Ajouter une route source".

Cela créera la nouvelle route source, visualisée par la ligne bleuâtre, les marques d'extrémité rouges vers le nœud de destination.

(Dans les versions ultérieures, il sera possible de spécifier d'autres routes de secours, mais je dois trouver une bonne interface utilisateur pour cela.)

Pour supprimer une route source: Sélectionnez «Supprimer la route source» dans le menu contextuel du nœud de destination.

L'itinéraire sera utilisé pour la toute prochaine demande:

Cela fonctionne plutôt bien et permet l'écrasement manuel du routage si nécessaire, ce qui devrait également être pratique pour les tests.
Actuellement, cela ne fonctionne que lorsqu'il est configuré via GUI, mais il devrait être disponible via REST-API trop tard.

Cela va-t-il tout régler?

Peu probable, mais cela devrait améliorer le routage vers les destinations (le routage sur les nœuds lui-même ne peut pas être configuré). Notez que les routes sources fixes ne sont bonnes que pour les routeurs, car les périphériques finaux ont tendance à changer le parent et la route source ne fonctionnerait plus, dans ce cas, le routage source automatique pourrait mieux fonctionner.

Quand va-t-il sortir?

Bientôt, dans la prochaine version 2.05.81, j'ai les éléments suivants (plutôt légers) sur la liste des choses à faire pour la version:

• Stocker / restaurer les routes sources dans la base de données.
• Correction de la gestion du compteur de sécurité NWK pour corriger la sauvegarde entre différents ConBee / RaspBee et redémarrer le bug, rien ne fonctionne.
• Laissez GCFFlasher vérifier que le micrologiciel fonctionne après la mise à jour.

Merci pour la réponse détaillée, je pense que beaucoup d'entre nous attendent une réponse comme ci-dessus en raison de tout le travail acharné que la communauté fait pour ce problème et que vous faites en tant que développeur.

Plusieurs questions de suivi que j'ai:

• Quand est-ce que ci-dessus sera disponible en tant que mise à jour en version bêta / stable?

• Y aura-t-il une différence dans la façon dont ci-dessus fonctionnera concernant conbee 1/2 et Raspbee ou est-ce que ce sera tout de même?

• Pour la mise à jour 2.05.81, vous mentionnez avoir des éléments plutôt (légers) sur la liste des tâches, quand pouvons-nous nous attendre à cette mise à jour (peut-être est-ce une idée d'ajouter une feuille de route à ce git?)

Salut @lubbertkramer

Je peux répondre numéro 1: la version 2.05.81 serait attendue le 15 du mois (Windows build quelques jours plus tard). Je l'ai placé lors d'une annonce plus tôt dans Discord, mais j'ai juste pensé que ce n'était pas le cas pour le Github. J'ajouterai cela au readme! Ma faute!

Edit: a fait une demande d'extraction du fichier readme.md. Je ne sais pas comment fonctionne le canal stable qui doit être clarifié un peu.

Y aura-t-il une différence dans la façon dont ci-dessus fonctionnera concernant conbee 1/2 et Raspbee ou est-ce que ce sera tout de même?

Cela devrait fonctionner de la même manière, j'ai maintenant porté le code sur RaspBee I / ConBee I et les routes sources y sont utilisées de la même manière.

J'ai actuellement un cas curieux où une prise de répéteur IKEA est vivante mais ne veut pas jouer avec le reste du réseau.
Les commandes qui lui sont envoyées (avec et sans routes source) sont ignorées en silence.

Le répéteur envoie ses trames d'état de liaison NWK, mais signale et liste de voisins vide:

Les commandes du coordinateur ainsi que d'un capteur OSRAM dont le répéteur est le parent sont ignorées. Le capteur, comme beaucoup d'appareils Xiaomi, n'essaye pas de trouver automatiquement un nouveau parent ... mauvaise situation:

Ce scénario fonctionne depuis deux jours maintenant, je n'ai pas trouvé de moyen de récupérer le répéteur. Peut-être qu'un cycle d'alimentation du répéteur résoudra le problème, mais je vais le garder comme ça pour l'instant pour voir s'il peut être résolu d'une manière ou d'une autre par voie aérienne.

Il y a un problème avec le répéteur USB Tradfri ou la prise Tradfri?

Dans ce cas, c'était la prise, je ne suis pas sûr que ce soit la dernière version, besoin de vérifier cela plus tard.

Est-il possible de vérifier? J'ai 3 prises Tradfri exécutant le dernier FW solide comme le roc depuis environ 1,5 an. Si je commence à avoir des problèmes avec eux avec la nouvelle version bêta, je dois retarder la mise à jour.

Merci!

Voici les données du cluster de base, notez que le problème s'est produit pour la première fois il y a deux jours dans mon réseau domestique qui n'avait pas le nouveau firmware à l'époque.

On dirait que vous êtes sur le dernier FW comme mes plugs. J'espère que ce sera le cas, à cause de l'ancien FW d'Ikea ​​...

La page Web avec le journal des modifications de tradfri est en panne, pour vérifier ce que le dernier FW a corrigé.

Les derniers fichiers du firmware sont maintenant en ligne:

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 et ConBee I

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

• Ceux-ci ont le routage source activé avec max. 32 routes sources, où les entrées les plus anciennes sont automatiquement remplacées par les plus récentes. Le montant sera probablement augmenté dans les versions ultérieures, mais devrait déjà bien fonctionner.
• S'il existe une route source et une entrée de route "normale", la route source est préférée. Ceci n'est pas standard mais semble mieux fonctionner.
• Le micrologiciel a des améliorations générales pour la robustesse du protocole série.
• ConBee II et RaspBee II ont obtenu une meilleure gestion du compteur de trames, pour atténuer les problèmes où, après un cycle d'alimentation, le réseau aurait pu sembler être perdu jusqu'à ce que le compteur de trames atteigne à nouveau son ancienne valeur.

@manup a - firmware pour ConBee J'ai laissé tomber version id de commande 0x0D ? Je ne reçois plus de réponse à cette commande

@Adminiuga @manup Informations sur le micrologiciel: veuillez utiliser # 3260.

Les derniers fichiers du firmware sont maintenant en ligne:

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 et ConBee I

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

• Ceux-ci ont le routage source activé avec max. 32 routes sources, où les entrées les plus anciennes sont automatiquement remplacées par les plus récentes. Le montant sera probablement augmenté dans les versions ultérieures, mais devrait déjà bien fonctionner.
• S'il existe une route source et une entrée de route "normale", la route source est préférée. Ceci n'est pas standard mais semble mieux fonctionner.
• Le micrologiciel a des améliorations générales pour la robustesse du protocole série.
• ConBee II et RaspBee II ont obtenu une meilleure gestion du compteur de trames, pour atténuer les problèmes où, après un cycle d'alimentation, le réseau aurait pu sembler être perdu jusqu'à ce que le compteur de trames atteigne à nouveau son ancienne valeur.

Comment flasher ce firmware (j'utilise l'image deCONZ Docker de marthoc)?

J'ai téléchargé le fichier (ConBee II) mais les instructions de mise à jour manuelle ne s'appliquent pas à l'image deCONZ Docker de marthoc et le guide de deCONZ de marthoc ne permet pas d'utiliser un firmware non inclus dans l'image (et ce fichier n'est pas répertorié Valide).

Comment flasher ce firmware (j'utilise l'image deCONZ Docker de marthoc)?

Je branche simplement le dongle USB sur un ordinateur portable Windows et je le fais à partir de là et de nouveau dans mon Synology NAS lorsque c'est fait.

Comment flasher ce firmware (j'utilise l'image deCONZ Docker de marthoc)?

Je branche simplement le dongle USB sur un ordinateur portable Windows et je le fais à partir de là et de nouveau dans mon Synology NAS lorsque c'est fait.

Existe-t-il un utilitaire Windows pour flasher le firmware? Si oui, pourriez-vous partager le lien?

Comment flasher ce firmware (j'utilise l'image deCONZ Docker de marthoc)?

Je branche simplement le dongle USB sur un ordinateur portable Windows et je le fais à partir de là et de nouveau dans mon Synology NAS lorsque c'est fait.

Existe-t-il un utilitaire Windows pour flasher le firmware? Si oui, pourriez-vous partager le lien?

https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Update-deCONZ-manually#update -in-windows

Par conséquent, j'ai expérimenté l'idée de configurer des routes sources fixes vers un nœud de destination. Dans de nombreux cas, seule une partie du réseau a des problèmes de routage, ici il peut être avantageux de spécifier une route source fixe où:

• Les routes sources peuvent être spécifiées en option par nœud.
• Chaque saut doit toujours être alimenté.
• Les positions de saut sur le chemin doivent être raisonnables. Dans certains cas, un utilisateur peut avoir un meilleur plan d'acheminement des paquets que ce que l'algorithme automatique est capable de comprendre.

Cela va-t-il tout régler?

Peu probable, mais cela devrait améliorer le routage vers les destinations (le routage sur les nœuds lui-même ne peut pas être configuré). Notez que les routes sources fixes ne sont bonnes que pour les routeurs, car les périphériques finaux ont tendance à changer le parent et la route source ne fonctionnerait plus, dans ce cas, le routage source automatique pourrait mieux fonctionner.

Juste pour clarifier ... ce nouveau firmware va-t-il corriger (ou au moins améliorer) la déconnexion aléatoire des appareils Ikea si je ne configure pas manuellement de nouvelles routes sources statiques? Ou le seul moyen de bénéficier de cette mise à jour est de définir manuellement les itinéraires de ces appareils qui ont tendance à perdre la connexion?

Sans réglage manuel des itinéraires, le routage automatique de la source a lieu si les appareils les promeuvent (comme le font les appareils IKEA).
Ainsi, par rapport à l'ancien firmware source, le routage sera utilisé pour ces appareils si une telle route est connue.

Si cela aide vraiment à rester ouvert, ce serait bien si quelqu'un qui avait régulièrement des problèmes avec l'ancien firmware pouvait signaler si quelque chose a changé.

Dans mes réseaux de test, le micrologiciel fonctionne assez bien et les routes sources sont souvent utilisées comme indiqué par les journaux de renifleur. Cela ne veut pas dire grand-chose puisque même sans routage source, mes réseaux étaient assez solides.

J'ai 21 lumières (4 - 980lu WS, 17 - 1000lu WS), 3 prises et 3 télécommandes rondes (5 boutons) d'Ikea. Tous sur les derniers FW Ikea. Je n'ai jamais connu d'instabilité avec eux depuis environ +1,5 an. Nighter avec l'une des versions précédentes de deCONZ ou FW, ni avec celle actuellement. Je cours stable .81 avec le dernier RaspBee FW 0x26370500, et je ne rencontre aucun problème pendant la dernière semaine d'utilisation.

Je suppose ... (peut-être que je n'ai pas tout à fait raison) Ikea n'a pas de problème général, mais est spécifique à la configuration. De nombreux facteurs peuvent affecter leur comportement et leurs performances dans deCONZ et en général.

Je pense que la plupart des problèmes sont survenus avec les lampes Ikea GU10. La stabilité s'était considérablement améliorée au fil du temps, mais c'était un gâchis fin 2018 lorsque j'ai commencé. J'ai dû mettre sous tension l'un des 30 GU10 toutes les deux semaines en moyenne pour la version / firmware des trois derniers mois.

Je pense que la plupart des problèmes sont survenus avec les lampes Ikea GU10. La stabilité s'était considérablement améliorée au fil du temps, mais c'était un gâchis fin 2018 lorsque j'ai commencé. J'ai dû mettre sous tension l'un des 30 GU10 toutes les deux semaines en moyenne pour la version / firmware des trois derniers mois.

Pourrait être. Le GU10 n'a pas reçu de mise à jour FW comme les autres lampes d'Ikea, pour autant que je sache. Récemment, nous en avons discuté dans les canaux Discord. Un utilisateur exécutant des lumières GU10 Ikea éprouve un tel comportement. Peu importe ce que nous avons essayé, rien ne semble résoudre ses problèmes. Il a même partagé avec nous qu'il avait acheté un hub Ikea Tradfri et qu'il avait également la même mauvaise expérience, même avec le hub Ikea et GU10 light / s.

Donc, je suppose que c'est une question de temps qu'Ikea ​​publie un nouveau FW pour ce type d'éclairage pour peut-être résoudre / résoudre ce problème ....

Je me demande si @djwlindenaar a déjà mis à jour le dernier deCONZ et le firmware et est capable de partager ses expériences? :)

En fait pas encore ... Je n'ai pas encore trouvé le temps de mettre à jour. De plus, je n'ai pas trouvé le temps de passer à z2mqtt, donc la bonne nouvelle est que je vais passer au nouveau firmware et s'il y a quelque chose à signaler, je le ferai.

Si cela aide vraiment à rester ouvert, ce serait bien si quelqu'un qui avait régulièrement des problèmes avec l'ancien firmware pouvait signaler si quelque chose a changé.

J'ai mis à jour le dernier firmware il y a 2 jours et depuis lors, l'un de mes interrupteurs muraux Xiaomi (ctrl_neutral2, 11-25-2017) a basculé de lui-même 3 fois. Je n'ai jamais eu un tel problème auparavant.

Il est connecté au coordinateur via une ampoule Tradfri E27 CWS au 1.3.009.

De plus, pas strictement lié à ce problème, mais je n'ai jamais réussi à obtenir une mise à jour OTA avec Deconz (conteneur communautaire).

J'ai les ampoules Tradfri:

• E27 CWS sur 1.3.009
• E14 W sur 1.2.214
• Gradateur sans fil sur 1.2.248
• 17 * GU10 WS sur 1.2.221

Je peux voir les fichiers Trafri OTA téléchargés mais rien ne se passe. Que devrais-je faire?

Pour référence, voici comment le conteneur démarre:

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 Ce n'est pas lié à ce problème ici afaik. Veuillez ouvrir un numéro séparé. Je pense que vous devriez publier dans le repo de la version Docker. https://github.com/marthoc/docker-deconz

Note de modération:

Avant que tout ne soit mélangé ici, j'aimerais définir une portée ici.

Tout ce qui concerne le problème d'origine: les lumières IKEA qui perdent parfois leur connexion sont autorisées dans ce problème.

Tout autre problème lié au firmware peut être posté ici

En fait pas encore ... Je n'ai pas encore trouvé le temps de mettre à jour. De plus, je n'ai pas trouvé le temps de passer à z2mqtt, donc la bonne nouvelle est que je vais passer au nouveau firmware et s'il y a quelque chose à signaler, je le ferai.

@ JBS5 , votre déclencheur a aidé;)

Je viens d'installer le firmware et le dernier deCONZ .deb. Jusqu'à présent, je peux confirmer que le routage de la source fonctionne, bien sûr, aucune conclusion sur la stabilité pour le moment. je te tiendrai au courant

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 Regardez comment le plugin OTA fonctionne https://github.com/dresden-elektronik/deconz-ota-plugin et met à jour vos appareils.
Désolé, mais c'est un problème de communication entre les appareils IKEA.

@ morfei1 @ peer69
Je peux confirmer que ce n'est pas seulement causé par les ampoules GU10. J'ai eu des problèmes de routage et de connexion perdue pendant longtemps sans GU10 dans mon système.

J'ai eu quelques problèmes initiaux après la sortie de .82 avec le nouveau firmware sur mon conbee 1.
Mais maintenant, après l'installation du maillage du réseau et quelques cycles d'alimentation, il est devenu solide ces derniers jours.

Aussi stupide que je suis, j'ai décidé de mettre à jour le dernier firmware (OTAU) sur toutes mes ampoules pour avoir une meilleure base de départ en cas de problèmes futurs. Souhaite moi bonne chance. Vous tiendrons au courant des progrès.

@tubalainen êtes-vous sur l'add-on HA?

@tubalainen êtes-vous sur l'add-on HA?

Non, j'utilise HA Core sur Debian dans docker - donc j'utilise également https://github.com/marthoc/docker-deconz stand-a-lone docker package. Ils utilisent tous les deux le fichier .deb fourni par dresten et doivent donc fonctionner de la même manière. Je ne sais pas si le plugin OTAU est inclus dans l'add-on deconz HA ....

je me suis contenté de partager mes observations jusqu'à présent;

Je n'ai que des problèmes avec mon Ikea GU-10 (23 d'entre eux), et j'utilise Home assistant, qui se connecte à deconz (docker) via le reste de l'API, et je peux voir HA déclencher les événements pour déconzer avec succès.

Quand j'utilise HA pour allumer, 17 ampoules, une par une (juste après l'autre) peut-être 3 des 17 dosnt s'allument, mais HA les considère comme allumées.
MAIS, si je fais un groupe en deconz. mettez toutes les lumières dans ce groupe et dites à HA d'allumer ce groupe, il n'y a pas encore eu de problèmes, toutes les lumières s'allument.

Utilisation du micrologiciel: 0x26650700 Je n'ai vu aucune amélioration (à part le fait que j'ai dû ré-appairer ces 17 ampoules pour une raison quelconque, et même après une nouvelle paire, j'ai eu les mêmes problèmes)

est-ce une limitation du reste-api peut-être?

@MartinTerp , si vous utilisez une seule commande pour chaque périphérique à la fois, plutôt qu'une commande à un groupe, cela échouera, peut-être pas à chaque fois, mais la plupart du temps, un périphérique aléatoire censé faire quelque chose ne le fera pas.

Ma solution de contournement pour cela est un délai de 5 secondes entre les commandes. Par exemple
Si je veux allumer les lumières de ma chambre à 23h00 à bri: 127 et ct: 454, et aussi dans mon couloir, je donne 5 secondes de retard pour l'une des pièces. Si je ne mets pas le délai, la commande complète échouera au hasard pour l'une des salles ou peut-être pour les deux. J'expérimente beaucoup avec ça. C'est quelque chose de similaire au bogue Ikea, il ne peut pas gérer la couleur et la luminosité du commutateur en même temps.

Je ne sais pas ce que c'est exactement, un bug deconz, une limitation zigbee en général ou un bug Ikea FW. C'est peut-être mon manque de connaissance du fonctionnement de zigbee, mais le délai de 5 secondes fonctionne toujours pour moi.

En règle générale, j'utilise toujours: sable aussi peu de commandes que possible à la fois ou utiliser un délai. Ainsi, vous gardez le canal propre.

Si vous avez besoin de changer plusieurs groupes / lumières à la fois, comme vous l'avez remarqué, il est toujours préférable de créer un nouveau groupe phoscon, d'inclure ces groupes de lumières et de leur envoyer une seule commande de groupe. Vous pouvez avoir de nombreux groupes différents comprenant la même lumière. Nous ne sommes pas limités à un seul groupe par lumière. Si vous n'aimez pas avoir beaucoup de groupes dans phoscon, alors le délai est votre meilleur ami.

@ morfei1 J'utilise une solution de contournement similaire et cela fonctionne la plupart du temps avec un délai de 5 secondes entre toutes les commandes.
@MartinTerp J'ai également eu ce problème avec d'autres appareils que les lampes IKEA-Tradfri, par exemple les Smart Plugs et les bandes lumineuses OSRAM. Je suppose que c'est possible même si le problème a été causé par un buggy Tradfri-Lights ne transmettant pas les commandes.

Mais ce n'est pas supposé être comme ça, n'est-ce pas?
au moment où le script les active 1 par 1 avec un délai de 1 seconde, il DEVRAIT être capable de gérer cela?

@ morfei1 @MartinTerp

J'avais aussi l'habitude d'utiliser des retards + que j'envoyais des commandes d'activation et de désactivation de l'assistant domestique deux fois par automatisation déclenchée.

J'ai maintenant supprimé les retards et les commandes de répétition depuis .82.

Je suis presque sûr qu'il n'est pas censé nécessiter un délai de 5 secondes. Je pense que ce n'était pas nécessaire avec une version antérieure, mais je ne parierais pas dessus puisque mon réseau s'est développé depuis. Peut-être que 82 (pas encore essayé avec un délai réduit) ou des versions futures amélioreront ce comportement.

@ morfei1 @githtz @tubalainen @martinterp

Pourrions-nous avoir une discussion sur la façon de mettre à jour les firmwares des appareils ailleurs?

On ne s'occupe pas de mettre à jour le firmware?

Quand je l'ai lu correctement, les problèmes d'envoi de plusieurs commandes, où tout ne passe pas, sont différents. C'est probablement plus un problème avec le planificateur de tâches.

Je suggérerais d'ouvrir un problème séparé pour cela comme "Toutes les lumières ne réagissent pas lors de l'envoi de commandes monodiffusion à plusieurs lumières".

Le problème ici concerne davantage le moment où les lumières sont complètement perdues et ne sont pas du tout accessibles, ce qui peut être lié au routage.

Rédigé par Mimiix

Rédigé par Mimiix

@inconsx @ ReX1983 Je pensais être clair sur https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment -696541484 et https://github.com/dresden-elektronik/deconz- rest-plugin / issues / 1261 # issuecomment -696046160

Veuillez vous en tenir à ces règles. Ouvrez des numéros séparés si vous le souhaitez.

Voici donc mes commentaires, j'ai mis à niveau vers le dernier firmware et l'api deconz. Je dirige mon réseau depuis HA.

J'ai environ 72 nœuds, la plupart sont des lampes IKEA GU10. Après la mise à niveau, j'ai remarqué deux GU10 différents qui "sont morts" deux jours différents, le seul moyen de le récupérer est de le redémarrer. Le GU10 utilise un appareil de 1.2.217 et 1.2.221. Je vais essayer de tous les mettre à niveau vers la même version.

Je n'ai que 4 GU10, je pense que ceux-ci proviennent de la première version publiée, fonctionnant sur la dernière version ota. Jamais eu de problème avec ceux-ci en termes d'accessibilité, juste mes scènes ont été gâchées après la mise à jour légère du firmware.

Je viens d'avoir une de mes ampoules IKEA TRADFRI E14 W op / ch 400lm Version 1.2.214 a cessé de répondre. Cette lampe a fait cela plusieurs fois et sur différents firmwares deconz. En ce moment, j'utilise deconz 26370500 et 2.05.82.

Je n'ai que 4 GU10, je pense que ceux-ci proviennent de la première version publiée, fonctionnant sur la dernière version ota. Jamais eu de problème avec ceux-ci en termes d'accessibilité, juste mes scènes ont été gâchées après la mise à jour légère du firmware.

Avez-vous constaté une amélioration de la stabilité avec ces ampoules GU10 après la mise à jour vers la 2.3.050? Je suis maintenant sur 0x26650700 et depuis la mise à jour vers 2.3.050 (de 17 ampoules), il semble que mon réseau soit beaucoup plus stable. Les appareils ne se déconnectent pas du jour au lendemain et mes boutons / commutateurs Aqara fonctionnent dès les premières tentatives. Il est maintenant 4 jours, si tôt pour le dire.

Je n'ai que 4 GU10, je pense que ce sont de la première version publiée

Il existe en fait une version plus économique d'IKEA GU10 (W uniquement). Ils n'ont jamais été mis à jour vers le logiciel 2.x et fonctionnent toujours sous 1.2.214. Et ce sont les plus problématiques. Personnellement, j'abandonne et maintenant ils fonctionnent bien avec le hub IKEA.

Je pense que @antonbo se rapproche du cours du problème.
IKEA utilise les mêmes images de micrologiciel avec un matériel différent (lecteurs PSU / LED) et ont des paramètres différents dans les "données utilisateur" pour différents matériels (et l'ID de modèle y est stocké). Ainsi, un micrologiciel peut fonctionner correctement sur un matériel (E14) et avoir des problèmes sur d'autres (GU10 / E27).
Une différence est que IKEA GW fonctionne en mode ZLL (sur Zigbee PRO) et ne tire pas l'état de l'appareil uniquement écouter les changements d'état que les appareils envoient sur le réseau (ala norme Zigbee PRO / ZB3) et les mélanger avec HUE et autres les fournisseurs dont le coordinateur extrait l'état des périphériques (comportement non ZB3) peuvent créer un désordre du réseau.
J'ai le plus ancien IKEA RGBW et un E27 Opal WW sur l'ancien firmware mis à jour (1.X) qui fonctionne correctement et un nouveau groupe de ZB3 GU10 WS qui fonctionne très bien. Mon épine dorsale est d'environ 10 prises IKEA qui maintiennent la communication réseau stable et mes capteurs Xioami fonctionnent bien avec tous.
Mon sentiment est qu'il n'y a pas un problème général plus HW et peut-être FW en combinaison avec la disposition du réseau et en évitant certains périphériques problématiques (comme OSRAM Outdoor Plug qui corrompe les paquets et perd des enfants tout le temps).

@manup Je peux seulement dire que pour mon système, le nouveau firmware a rendu les choses bien pires qu'avant. Que ce soit le routage source ou ce que c'est, j'ai maintenant chaque jour une ou deux ampoules bloquées et j'ai besoin d'un cycle d'alimentation. J'ai même vu l'une de mes ampoules Philips hue coincée mais cela n'a pas nécessité de cycle d'alimentation. Je ne sais pas si les problèmes sont maintenant causés par l'ancien micrologiciel que j'utilise, mais je ne peux pas non plus mettre à niveau car il est bloqué. :(

Je me demande si quelqu'un sait si le nouveau GU10 a toujours des problèmes ou s'il n'y a pas de problèmes? J'ai entendu des appareils plus récents exécuter zigbee 3.0, ma femme n'est pas contente de ces problèmes, donc je pourrais tous les changer si cela aide?

J'ai eu une lampe suspendue ce matin. Je pense que c'est l'un des plus récents.

La lumière n'a réagi à aucune commande, a été affichée comme étant hors ligne. Un cycle d'alimentation n'a pas résolu le problème. J'ai dû le réinitialiser et le rajouter au réseau.

@ JBS5 @djwlindenaar @lubbertkramer Des commentaires sur les derniers firmwares en comparaison avec ce problème?

Je peux ajouter que pendant 48 heures, je n'ai eu aucun problème sur ce que ce sujet traite et ce que j'ai vécu auparavant.

Cependant, vous devez ajouter les éléments suivants

• redémarrer le conteneur avec deconz tous les soirs
• déplacé le regroupement de Home-assistant vers deconz / phoscon pour gérer.

J'avais des ampoules moins réactives avant les changements ci-dessus bien qu'une meilleure expérience mais pas pour le moment.

@Mimiix , eh bien, il est un peu tôt pour le dire.

Ce qui m'ennuie, c'est que le réseau semble beaucoup plus lent. Le temps entre l'appui sur un bouton et l'allumage de la lumière (via une règle) est plus long qu'auparavant. Également allumer la lumière et changer la luminosité maintenant est un processus en deux étapes avec un certain temps entre les deux. J'ai encore besoin de regarder dans les journaux de reniflage pour vérifier ce qui cause cela. Cela n'a probablement rien à voir avec le changement du routage source, mais voilà.

J'avais une lumière qui ne répondait pas, mais je n'ai pas non plus analysé cette situation, donc difficile de dire ce qui s'est passé.

Mes ampoules E27 Ikea se sont arrêtées collectivement pour coopérer.
Jusqu'à présent, le cycle de puissance a fonctionné pour quelques-uns d'entre eux. 3 ne sont toujours pas de retour. Je suppose que je dois les rajouter ... :(

Micrologiciel: 26610700
La version: 2.05.84 / 14.9.2020
(Raspbee2)

@umrath Cela ne semble pas lié au problème abordé dans ce numéro. Veuillez ouvrir un numéro séparé :)

Le symptôme me ressemble beaucoup: les lampes ne répondent plus sans raison apparente.

Comme je viens de le dire: cela ne semble pas lié. veuillez ouvrir un numéro séparé. Nous pouvons toujours déterminer par la suite que cela est lié. Je garde un œil serré sur cette question.

Oui, je pense aussi que c'est lié. Après quelques mois sans bogue, hier, j'ai eu à nouveau le problème avec deux appareils, un (très ancien) IKEA E27 et le plus récent magasin IKEA, tous deux avec un firmware récent.

La seule chose que j'ai faite à l'époque était de transporter un store KADRILJ hors de portée et plus tard, mais cela n'a peut-être aucun rapport.

Lancer le renifleur montre le même problème:

• Les périphériques envoient toujours périodiquement des commandes NWK Link Status;
• Mais toujours avec une liste vide, il semble qu'ils ignorent tous les routeurs environnants;
• Ils ACK les commandes entrantes au niveau MAC;
• Ils réagissent aux demandes de balise et envoient un balise, mais c'est la seule «réponse» qu'ils donnent.

D'une manière ou d'une autre, il semble que la pile Zigbee sur les appareils IKEA plante en partie pour les couches NWK et APS et au-dessus ou peut-être que les tampons NWK entrants sont pleins et jamais libérés.

J'ai essayé de remettre les appareils en vie en envoyant:

• ZDP Quitte avec rejoindre;
• NWK Partez avec rejoindre (niveau inférieur).

Les deux sont ACKés au niveau MAC mais sont sinon ignorés.

J'ai ensuite essayé de simuler les commandes NWK Link Status du coordinateur avec une entrée valide qui indique que l'appareil a un coût de liaison entrant et sortant fonctionnel (3/3) dans l'espoir que l'appareil capte le coordinateur dans sa table voisine. ... n'a pas fonctionné non plus.

Malheureusement, il ne semble pas y avoir de moyen de contourner la situation après que cela se soit produit et que l'appareil IKEA entre dans cet état presque mort. En regardant à travers certains forums, le comportement peut être vu avec toutes sortes de passerelles et de piles Zigbee sous-jacentes. Ce qui est intéressant car, par exemple, le pont Hue ne fait pas de trucs fantaisie Zigbee comme l'interrogation de tables voisines ou de liaisons et de rapports et le bogue se produit toujours.

Ce que IKEA doit faire, c'est au moins implémenter un chien de garde qui vérifie que les composants NWK et APS fonctionnent toujours et laisse l'appareil déclencher le redémarrage du chien de garde. Cela ne résoudrait pas le bogue, mais cela garderait au moins l'appareil fonctionnel quand cela se produirait.

@manup Avez-vous l'ancien E27 one LL avec un cluster de diagnostic?
Peut-être que cela peut être intéressant de voir si quelque chose se passe avec les compteurs là-bas dans quelques semaines.
Il ne peut pas résoudre le problème, mais donne un soupçon de wot le firmware ne laiking.
Bonne observation et conclusions mande !!

Je pense que Silabs a un peu plus de recherche de bogues à faire pour l'un de ses plus gros clients ;-)

Salut, cela me trouble car depuis que je suis passé à Z2M en utilisant le ZZH il y a quelques mois, je n'ai pas vu ce problème. Il y a peut-être une autre variable dans l'équation. Ce serait formidable si quelqu'un d'autre qui a fait le même geste pouvait le confirmer.

@mvjt Utilisez -vous Rasp / CornBee avec Z2M ou un autre coordinateur?
Différentes piles de zigbee fonctionnent de différentes manières et peuvent avoir / créer des problèmes différents.

Edit: Désolé, je vois ZZH = nouveau coordinateur TI.
deCONZ NCP = Atmel / Microchip
Appareils IKEA / NCP = Sirlabs EFR32 / EZSP

Je peux confirmer que HA / ZHA / Zigpy / Bellows fonctionne très bien avec le module "Billy EZSP" = IKEA ICC-1-A en tant que coordinateur avec les routeurs IKEA et les périphériques finaux d'IKEA et Xiaomi et NO OSRAM ou les routeurs Xiaomi.

@MattWestb Oui, l'E27 a le cluster de diagnostic, mais je ne l'ai pas encore

Au moins dans le passé, le problème que je vois s'est produit également avec TI CC253X et à la fin du problème, le CC26X2R1 est mentionné, mais c'était l'état en janvier, il aurait pu s'améliorer entre-temps. https://github.com/Koenkk/zigbee2mqtt/issues/2032#issuecomment -547483373

Ce n'est peut-être pas un bogue Silabs en général, mais aussi des éléments personnalisés dans la couche d'application. Je pense que les appareils Hue récents utilisent également Silabs. Depuis le pont Hue, il existe au moins des versions TI et Microchip.

C'est une chose vraiment désagréable, dans de nombreux cas, le bogue peut ne pas se produire du tout ou seulement après quelques mois, dans d'autres réseaux, cela se produit à des intervalles beaucoup plus courts. Je suppose que la façon dont les réseaux fonctionnent est également importante et que les lumières qui sont régulièrement éteintes sont moins affectées.

@manup J'ai un scénario qui passe très bien sur votre "problème IKEA".
Si vous avez configuré votre réseau, il commence avec une clé réseau et le compteur de trames de sécurité commence à cocher. Si vous n'avez pas réformé le réseau ou roulé la clé de réseau pendant très longtemps, le compteur bloque parce qu'il arrive au maximum 0xFFFFFFFF (32 bits) et ne peut pas augmenter.
Ensuite, le périphérique jette toutes les données qui arrivent dans la couche zigbee car le compteur de trames est erroné mais la couche sous-réseau fonctionne toujours normalement.
Le problème je ne connais pas une méthode pour obtenir le statut du compteur de trames de sécurité des appareils. Je pense que ce n'est pas possible de le voir dans Wireshark (penser = ne pas savoir).

Ce qui indique cela, c'est que les premiers appareils couplés qui ne sont pas réinitialisés se bloquent plus rapidement.
Les nouveaux appareils couplés / réinitialisés fonctionnent plus longtemps avant que le compteur ne bloque.
Les commandes de Mutch à un appareil le rendent également plus rapide qu'un appareil qui n'est pas si «communicatif».

Il est recommandé de faire rouler la clé réseau régulièrement dans le réseau ZB3 pour la maintenir en sécurité, puis de réinitialiser également le compteur de trames de sécurité afin qu'il ne soit pas bloqué.
Quelques informations AN1233: Zigbee Security 2.1.6 Le compteur de trames de sécurité réseau.

C'est un brainstorming sauvage, mais cela peut être la façon dont le problème survient après une longue période de fonctionnement du réseau.

Un test essaie de faire rouler la clé réseau et le périphérique "vivant" fonctionnant bien pendant assez longtemps, mais celui qui est bloqué doit être réinitialisé / rejoint pour démarrer le compteur de trames de sécurité à partir de zéro.

Hrm, à peu près sûr que le roulement de la clé de réseau shr s va supprimer tous les xiaomis.

Faux à 200% sûr qu'ils ne se mettent pas à jour et quittent le réseau (les anciens sans ZB3) !!!

@Adminiuga Avez-vous essayé de faire rouler la clé réseau sur EZSP?
Je trouve ça intéressant du résultat !!!

Je n'ai pas essayé de rouler la clé réseau. En fait, il serait intéressant de savoir combien d'implémentations roulent la clé sur une base régulière.
Mais je peux confirmer que le changement de pan-id a de très fortes chances de chute de xiaomis, comme 4 chances sur 5

J'ai vu des tests de pénétration de sécurité qui reniflaient le pan-ID de la rue et y retournaient plusieurs fois avec quelques mois entre et non, le grand fournisseur de lumière (non nommé ici) ne roulait pas la clé du réseau après un an (Mariahilferstraße à Wien ) donc vous avez plus que probablement raison (agen).

Si et seulement si c'est le compteur de trames de sécurité qui cause le problème, alors il fait la même chose pour tous les vrais appareils zigbee 3, alors il est défini dans la "Base-Device-Behavior-Specification" et recommandé dans l'ancien LL mais très probablement pas sans zigbee PRO (anciens appareils HA et LL) ou appareils non certifiés (sans nom .... mi).
Alors il vaut mieux faire rouler manuellement les clés du réseau ou deux fois par an et ne pas avoir besoin de démolir la maison pour réinitialiser les appareils intégrés plus de fois dans la bouche, puis ils calent et reprennent la réinitialisation / la réintégration des anciens capteurs Xiaomi qui ne sont normalement pas intégré dans la structure de la maison et étant plus facile à réinitialiser (jointure normalement ouverte et appui sur le bouton et ils se connectent).
Menny "Chinese Zigbee 3" lance le "vieux" compteur de trames de sécurité après la réinitialisation de l'alimentation et en utilise un nouveau du premier paquet arrivant de ses voisins (avoir vu que le test des problèmes de tasmotas zigbee 3, puis le compteur NCP a été mal réinitialisé au redémarrage) donc ils ne sont que repower et ils sont de retour.

Nous avions également fait quelques tests l'année dernière, aucune passerelle ne faisait pivoter la clé réseau. Comme décrit dans la spécification, c'est le seul moyen de réinitialiser le compteur de trames de sécurité NWK lors de l'incrémentation du numéro de clé réseau. Je partage également des inquiétudes quant au fait que cela est pris en charge par tous les appareils, généralement des fonctionnalités qui ne sont presque jamais utilisées ne sont pas bien testées. J'espère vraiment que je me trompe ici et que cela fonctionne pour la plupart des appareils.

Dans tous les cas, la réinitialisation du compteur de trames est la plus importante pour la passerelle car elle a le plus grand nombre de commandes sortantes, de lumières et de capteurs devrait être bien pour les années à venir. Actuellement, ce n'est pas un problème, mais il le devient dans 2 à 3 ans lorsque le compteur de passerelle est atteint dans les réseaux plus importants. Pour cela, nous avons déjà prévu de vérifier si la rotation de la clé réseau ainsi que le numéro de clé et la réinitialisation du compteur de trames fonctionnent.

Quoi qu'il en soit, le problème ici est différent, les compteurs de trames de la passerelle et les voyants en état d'erreur sont toujours bons et assez faibles.

@djwlindenaar Je me demande si vous avez de nouvelles découvertes puisque vous êtes en mesure d'analyser techniquement vos résultats en plus de simplement signaler qu'une lampe est à nouveau hors ligne, comme je peux le faire. Vos résultats et vos idées sont grandement appréciés. :)

Eh bien, merci pour l'appréciation ... Pour être honnête, je ne suis pas entièrement satisfait de la stabilité actuelle du réseau. Il est tombé en panne depuis la mise à jour vers le dernier firmware deconz. Certaines lumières se sont déconnectées au cours des dernières semaines, alors que cela ne s'est pas produit pendant longtemps avant la mise à niveau. J'ai couru avec les correctifs qui permettent la création de rapports d'attributs réguliers pour les lumières IKEA, ce que je n'ai pas encore appliqué dans la situation actuelle

Bien que ce soit amusant d'analyser cela, c'est un passe-temps pour moi et mon temps est maintenant entièrement occupé par une rénovation de la maison. Je vais voir si je peux y consacrer un peu de temps ...

Eh bien, merci pour l'appréciation ... Pour être honnête, je ne suis pas entièrement satisfait de la stabilité actuelle du réseau. Il est tombé en panne depuis la mise à jour vers le dernier firmware deconz.

J'ai la même expérience négative. Maintenant, la plupart de mes appareils Xiaomi (principalement les interrupteurs muraux Aqara) se déconnectent fréquemment pendant la journée et retournent au travail après quelques minutes (je suppose que cela est dû au fait que les appareils Xiaomi redémarrent s'ils ne reçoivent pas de réponse à la demande du attributs du cluster Time du coordinateur).

La nouvelle version v2.5.88 pourrait améliorer la situation. Ici, la configuration des rapports IKEA a été lissée afin que les transitions d'état ne bombardent pas le réseau de rapports. Avant la transition d'état, chaque attribut était signalé à un rythme très rapide.

La nouvelle version v2.5.88 pourrait améliorer la situation. Ici, la configuration des rapports IKEA a été lissée afin que les transitions d'état ne bombardent pas le réseau de rapports. Avant la transition d'état, chaque attribut était signalé à un rythme très rapide.

Cela semble prometteur :) On / off est également une transition d'état, je suppose? Ou surtout des changements de luminosité ou de mode couleur?
Une version minimale du micrologiciel est-elle nécessaire / recommandée pour ce changement?

Seulement la luminosité et tous les attributs spécifiques à la couleur comme colorX, colorY et température de couleur.
Pour le firmware, je recommande toujours le dernier 0x26660700 (dans le cas de ConBee II et RaspBee II).

La nouvelle version v2.5.88 pourrait améliorer la situation. Ici, la configuration des rapports IKEA a été lissée afin que les transitions d'état ne bombardent pas le réseau de rapports. Avant la transition d'état, chaque attribut était signalé à un rythme très rapide.

@manup , je pense que cette mise à jour a également résolu les problèmes de stabilité avec les appareils Aqara. Merci

La nouvelle version v2.5.88 pourrait améliorer la situation. Ici, la configuration des rapports IKEA a été lissée afin que les transitions d'état ne bombardent pas le réseau de rapports. Avant la transition d'état, chaque attribut était signalé à un rythme très rapide.

@manup , je pense que cette mise à jour a également résolu les problèmes de stabilité avec les appareils Aqara. Merci

Malheureusement le problème (# 3605) est toujours là, je me suis précipité trop tôt pour tirer des conclusions