Je vais y aller de mon post sur le même plugin que l’on trouve à maintes reprises sur le forum.
Je perds régulièrement des noeuds sur ce protocole.
Je ne pense pas que le plugin soit impliqué puisqu’il sont déclarés également comme « unreachable » sur Phoscon.
Je pensais que cela pouvait être dû à la distance entre clé et périphériques, du coup, j’ai ajouté une prise Osram au mileu de la maison.
Le problème c’est que cette prise, après quelques jours, est également déclarée « unreachable » et donc tous les périphériques qui étaient perdus sont de nouveau perdus.
Je vous joins les logs si ça vous éclaire, moi je ne sais plus où regarder.
Je ne vais tout de même pas ajouter une prise à côté de l’autre prise pour que le système se durcisse.
A moins qu’il n’y ait une contre-indication avec OSRAM.
Bonjour,
C’est quelques chose de récurrent et je ne pense pas que ca soit toujours un vrai probleme en gros deconz declare que le node est unreachable si pas de nouvelle de celui-ci de plus de X heures. Dès que le noeud renvoi une information il repassera en ok.
Je suis toujours en train de confirmer cette theorie une fois bien stable je ferais bien sur un changement sur l’interface pour ne plus induire les utilisateurs en erreur.
Merci de ton retour.
J’entends bien ce que tu dis mais lorsque j’envoie une commande sur la prise, je me fait jeter.
Je peux demander l’état de la prise mais ni on ni off.
A ben c’est pas le meme cas que chez moi alors… je peux pas aider malheureusement la faut voir avec deconz je pense (verifie avant le firmware et version de deconz avant)
Alors qu’une demande d’état me renvoie 0 sans message d’erreur.
Si tu n’as pas d’autres idées, je vais échanger la prise. Comme je n’avais besoin que d’un répéteur, je l’ai acheté en reconditionné chez A**n.
Peut-être a-t-elle un problème.
Ok, alors je vais demander un retour pour voir si ça marche mieux avec une autre.
A titre d’information, si tu utilises un wall plug, peux-tu me dire lequel?
Vu mon usage, je ne voudrais pas prendre quelque chose de non testé dans Jeedom.
Merci encore
Désolé je n’ai pas de module actif encore sur deconz j’ai que des capteurs. J’ai bien recu des actionneurs mais j’ai pas encore eu le temps d’ouvrir le carton…
Il y a effectivement une contre indication pour OSRAM.
Je peux retrouver le post qui en parle si vraiment ça t’intéresse, mais ici tu as les tests fait avec la zigate en bas de la page http://kiwihc16.free.fr/Radio.html.
Pour faire court le probleme ne vient pas d’Osram mais de Xiaomi, même si c’est Xiaomi qui deconnecte et pas Osram.
Ça m’intéresse mais je n’ai pas de Zigate mais une ConBee 2.
Je veux bien lire ce post si tu le trouves.
J’ai cherché sans rien trouvé. Je vais rechercher sur OSRAM, je n’avais pas pensé que le problème pouvait venir de la prise.
De fait, je l’ai retourné pour prendre une Hue à la place sans aucune certitude.
Merci
Effectivement, c’est surprenant.
Je dirais même que c’est juste pas possible.
D’après l’article, sur Zigbee, il n’y aurait pas d’interopérabilité entre les différentes marques.
Une prise OSRAM, ne pourrait pas servir de routeur à du Xiaomi par exemple.
Si c’est vrai, j’abandonne ce protocole. J’espère que ce n’est pas avéré.
@mich0111 si tu ne veux pas de probleme c’est Xiaomi qui faut abandonner, pas Osram. J’ai beau réfléchir en probleme « inter-marques » c’est les seuls que j’ai en mémoire. Mais le cas Osram/ikea n’a jamais été signalé sur le github de deconz.
Alors c’est pas pour Osram EU, mais c’est surement le même probleme (sachant que ça a pu changer avec les derniers firmwares)
A bug was recently discovered where some Zigbee 3.0 routers ask end-devices to rejoin if they time out in their neighbour table. The Xiaomi end-devices don’t implement that correctly and will just leave the network and repairing them to the network is required.
Currently known routers which have this problem are:
OSRAM US Sylvania plug
Müller Licht tint lights
Note the bug is in the Xiaomi devices not the routers. As a workaround I suggest powering off all problematic devices during pairing so that the Xiaomi devices select a « working » parent device.
Je veux bien, mais abandonner Xiaomi revient à abandonner zigbee.
Ce sont eux qui ont le plus de capteurs quand même.
Et certains ne sont disponibles que chez eux.
Alors quelle autre option?
Justement non, c’est la le probleme, eux c’est pas du zigbee.
Le point fort du zigbee c’est le maillage, ça supprime tout les problemes de portée ou de connexion, avec des capteurs Xiaomi, tu n’as rien de tout ca, autant prendre du 433 mhz.
Surtout que ce doit etre eux qui ont le plus de comportements bizarres au niveau de la norme Zigbee.
Tout leur capteurs existent dans d’autres marques a part le vibration et le cube.
Xiaomi n’est pas un probleme, j’en ai aussi, aucun probleme avec, mais j’ai un vrai réseau zigbee derriere (4 marques différentes en routeur dont les prises Osram)
Bon ok, je vais voir. @olive m’a recommandé de prendre une Zigate.
Cela devrait m’éviter les problèmes de maillage et me permettre de conserver mes aqara.
Zigate / conbee / zigbee2mqtt ça fonctionnera pareil, c’est pas pour rien que le premier lien vient du plugin zigate « abeille »
Et pour info sur le papier la conbee a une meilleure portée que la zigate, donc tu as peu de chance d’avoir mieux. Tu as essayé de brancher la conbee au bout d"un cable USB ?
Si tu n’as que du Xiaomi, la meilleure solution pour toi c’est leur passerelle.
