Conbee/Phoscon persistence des modification de configuration

Bonjour,
Tout d’abord merci pour ta réponse.
J’ai passé des heures à lire le forum concernant ce souci et je te confirme que moi non plus je ne vide pas mes cannettes de bière pour les reremplir avec la même bière.
Il y a 3 façons d’inclure ces capteurs avec combee2 deconz (depuis jeedom, depuis phoscon et depuis l’ancienne interface deconz), et je peux te garantir pour l’avoir fait plusieurs fois que l’inclusion ne donne pas le même résultat à chaque fois et ce résultat est TRES dépendant de l’interface utilisée pour l’inclure. Que ce soit étonnant c’est une chose mais c’est le cas. Sur un même capteur, à l’inclusion je n’ai pas toujours le même offset de T°, parfois l’info ne remonte pas du tout (je ne l’ai même pas dans Deconz), la présence pareil et la luminosité reste à zéro. En supprimant le capteur et en recommençant l’inclusion ça règle le pb, pas toujours du premier coup mais ça finit par fonctionner. Etonnant certes mais c’est comme ça.
Pour ce qui est de duration, déjà ce n’est pas 15 minutes mais 15s. Il s’agit de la persistance de l’information présence = 1 remontée par le capteur. Et clairement, pour avoir pisté les plantages et observé finement l’historique, en fonction de ton utlisation du capteur et de la fréquence de détection d’une présence, si le paramètre duration n’est pas « adapté » ça le met plus rapidement dans les choux. Et là pour le refaire communiquer, pas d’autre moyen que de le supprimer et le réinclure même si tu sembles en douter. Alors le réinclure c’est peut-être « encore pire » mais au moins il recommence à communiquer, l’autre solution consistait à le jeter par la fenêtre mais j’ai une âme un peu plus soucieuse de l’environnement.
Il y a 2 modifications évoquées sur le forum et rappelées plus haut :

  • fixer par un SC le paramètre duration. J’ai ce SC sous le coude, testé et il fonctionne chez moi mais je ne l’ai pas encore mis en place car je n’ai pas constaté de modification du paramètre pour le moment, et ce sur aucun de mes 4 capteurs.
  • faire la soudure entre les points 1 et 3 pour garder le capteur dans un mode de communication plus « assidu », et avant de faire une modification de carte, j’ai quand même bien observé le comportement de mon capteur, d’où la suppression puis réinclusion répétée.
    Maintenant, ayant testé beaucoup de choses, et ayant toujours des soucis de communication de mon capteur au bout d’une durée variant d’un à 3 jours voire plus, je tente la modification de carte en soudant le point 1 à 3. Pour moi il y avait des choses à tester avant. On ne sait jamais, une nouvelle version de ces capteurs aurait pu éviter la modif !..
    Pour ce qui est de presser le bouton toutes les secondes pour faciliter l’inclusion, c’est précisément ce que je fais et c’est ce qui me permet d’inclure les capteurs. Néanmoins, celui qui a eu la soudure semble s’inclure beaucoup plus facilement. Coïncidence ? Va savoir

Je précise que je n’ai pas réalisé l’opération de shunt pour régler un quelconque pb d’inclusion ou de température. J’ai 3 soucis bien distincts sur ces capteurs :

  • inclusion laborieuse avec toutes les informations brutes qui ne sont pas présentes
  • plantage total au bout de quelques heures ou jours, le capteur ne communique plus du tout
  • pb d’offset de température
    Le shunt c’est pour régler le second souci et le réglage de duration a aussi un impact.
    En relisant mon tout premier message, j’ai énuméré plusieurs choses et peut-être que ça a donné l’impression que je mélangeais tout… mais non :wink:

Salut Ninipapouille,

Je n’ai pas eu de souci d’inclusion de mon coté, en tout cas sur ces capteurs. J’ai eu bcp de pb avec les Heiman fumée, ou c’est juste n’importe quoi (note à moi même : faudrait que je réessaie depuis que j’ai mis le fw a jour de la conbee).

J’ai parfois des capteurs qui déconnectent du réseau (pas ceux ci d’ailleurs, mais par contre les inter zemimart sortent souvent, enfin certains!!),
pour ne pas perdre la config qui va derrière tu peux essaie de juste les ré inclure sans les exclurent
=> ça te permet de ne pas recréer les commandes, et donc les interactions que tu pourrais avoir derrière

Sinon, as tu des équipement sur secteur (pour le maillage)?
=> pour tester, si tu change de place ton détecteur (carrément dans une autre maille de ton réseau), est ce qu’il sort toujours?

J’ai ma conbee sur un hub alimenté, et relativement déporté, et j’ai un réseau assez bien maillé et plutôt stable (env. 50aine de modules toutes marques).

Je n’ai pas constaté de modification sur l’offset de température à appliquer en réincluant le capteur, le seul truc c’est que je le réchauffe un max en le manipulant.
Après, mes détecteurs sont en hauteur et au dessus des portes, selon les moment de la journée j’ai des delta significatif entre le détecteur et un autre capteur dédié dans la pièce …

Salut Bben,
A vrai dire ce qui me gène le plus c’est ce décrochage des capteurs sans raison apparente, à la limite la température c’est bonus si ça fonctionne ! Pour ce point précis, il faut que je prenne le temps de comparer avec précision avec mes Xiaomi de température qui fonctionnent parfaitement.
Pour le maillage, logiquement je devrais pas être trop mal, il y a 2 équipements secteurs dans la même pièce dont un à environ 4 m du capteur. A noter que ça m’est même arrivé avec deux capteurs en test sur la table de salon à 2m d’une Hue… et à présent ils sont plus loin mais tiennent pour l’instant. C’est assez incompréhensible…
Je teste la modif hard sur un qui merdouillait dur, on va voir si le fait de forcer la communication par ce biais règle le souci. Je ne manquerai pas de poster des news pour aider les suivants :wink:
Merci à toi pour cette réponse constructive :slight_smile: :slight_smile: :stuck_out_tongue:

J’essaierai la prochaine fois de réinclure sans supprimer, effectivement si ça évite de perdre les liens et que ça fonctionne… c’est tout bénef !
Pour précision, ma Combee est directement sur le NUC qui supporte Jeedom et il y a 2 hue entre la clé et le capteur qui pose souci ces derniers jours. Je suis encore en phase de test sur les 3 autres aussi car leur acquisition est très récente. En termes de capteurs je n’ai que du Xiaomi pour l’instant mais pour ceux de mouvement je suis mitigée, pas sûr que j’en rachète. D’un autre côté, j’ai regardé les ikea mais les avis mentionnent le même type de soucis, du coup j’aimerais bien faire fonctionner les xiaomi correctement :wink:

Un truc intéressant à faire, un fois ton réseau stabilisé, c’est d’aller voir comment il est maillé sur le gui deconz (windoz).

J’ai eu quelque surprise chez moi.

Ok, merci pour le tuyau, je vais regarder ça !

Bon, connexion via ultravnc pour voir le maillage, tout est connecté nickel, pas de surprise particulière, les ampoules secteur font bien répéteur. Pas de souci particulier a priori. A voir dans le temps :wink:

Ce que je voulais dire avec les bières, c’est pourquoi le supprimer avant ? yen a plein qui font comme ça, jamais compris ce qui pouvait passer par leur têtes …

Pareil pour les 15 mn, et j’ai bien dis minutes, que tu régles « duration » a 15s ou 15 minutes (sur un capteur trafiqué, sinon c’est 90s mini), ça ne changera rien, c’est géré en interne par deconz, aucun impact sur le capteur.

La température sur ces capteurs ne sert a rien, pas du tout fiable, et les valeurs peuvent mettre 1 h a arriver. Ça ne sert a rien de faire 10 inclusions jusqu’à avoir la valeur que tu veux.

Attention les xiaomi ne se déplacent pas dans le maillage (enfin pas seul).

Apres je te laisse faire tes tests, mais jeedom envoi la même commande que phoscon pour le permit join, je veux bien que tu ais des résultats différents, mais je ne prendrais pas ça pour une logique.

Et encore pour info la soudure ne change que le temps de « mise en veille » hardware (pas celle gérée par deconz) du capteur après une détection, aucun autre impact.

Salut HugoVal11,

Ça me semblait plus propre de supprimer pour réinclure, mais c’est peut-être une erreur. Je testerai sans supprimer la prochaine fois et je verrai bien. Si ça fonctionne effectivement ça permet de conserver les liens vers les commandes derrière et c’est pas négligeable.

La modification de duration a clairement un impact sur le comportement du capteur. J’ai fait des tests, en modifiant duration dans le plugin deconz qui y donne accès, et sur un capteur non modifié. J’ai des différences très nettes de comportement. On retrouve ce paramètre dans les données brutes. Je ne sais pas s’il est géré par Deconz exclusivement ou si c’est un paramètres interne du capteur mais j’ai constaté un impact sur l’arrêt de communication du capteur. En clair ce que j’ai constaté c’est que plus le capteur est sollicité et plus il faut monter le paramètre duration sion le capteur est dans les choux en l’espace d’une heure ou 2. J’ai testé avec un paramètre à 1s, 5s, 15s et 90s. Sachant qu’au delà çane me convient vraiment pas car il pilote une lumière et en même temps affiche sur la tablette domotique où est la personne dans la maison. En 90s tu as le temps de faire toutes les pièces et tu es signalé partout si l’information persiste 90s. Peut-être que je n’ai pas eu le bon raisonnement mais aujourd’hui ce sont les déductions que j’ai faites de mes tests.

Effectivement pour la T° je te rejoins, l’actualisation n’est pas fréquente et je considère que c’est bonus car je ne pensais pas qu’ils la donnaient. Ceci dit s’il peut fonctionner, pour une pièce du type véranda, la précision au degré actualisée toutes les heures me suffit et je mettrai mon capteur précis au centième ailleurs (encore que le centième me semble illusoire). Je n’ai pas refait d’inclusion exprès, je l’ai refaite quand je n’avais plus la présence (fonction de base du capteur) et j’ai constaté que d’une inclusion sur l’autre espacées de quelques minutes, sans toucher au capteur, je peux avoir 6 degrés de différence…

Le fait que les Xiaomi ne se déplacent pas dans le maillage seuls, alors ça c’est une info qu’elle est bonne ! Je l’ai faite à moins de 3 m de l’endroit définitif don peu de risque que ça ait beaucoup impacté la com, mais ça explique ce que l’on peut lire jusque dans leur notice, les inclure à l’endroit définitif de pose. Ok compris. Question du coup : quelle est la bonne méthode pour les déplacer dans le maillage si ça s’avère nécessaire où si un jour une hue arrive juste à côté? J’ai cru lire que refaire une inclusion ne change rien. Vrai ?

D’accord avec toi, pour les commandes jeedom/phoscon. Je ne m’explique pas cette différence mais pourtant… Même entre la nouvelle et l’ancienne interface phoscon/deconz le comportement du capteur en retour est différent. J’obtiens les meilleurs résultats à l’inclusion en laçant les deux simultanément. Peut-être tout simplement parce que le capteur reçoit plus de commandes identiques…

La soudure j’ai bien compris à quoi ça sert. Mon capteur entre dans un état de veille qui n’est pas celui de deconz car dans Deconz je n’ai plus rien dans les données brutes et plus aucune communication. C’est bien mon capteur qui n’envoie plus aucune trame et c’est bien cet état de veille lié au matériel que je veux supprimer :wink: Pour l’instant le capteur modifié hier fonctionne sans aucun souci.

Alors Xiaomi et la maillage, on pourrait écrire un roman sur ça.
Je n’ai jamais testé ça sur mon réseau, mais de faire une pression courte sur le bouton (en plus de le réveiller) lui permet de se déplacer dans le réseau.
Donc en théorie en cas de grosse modif il suffirait de refaire une petite pression pour le remettre en place. Problème, comme tu le dis, même une re-inclusion juste a coté d’une lampe, ne le fera pas forcement utiliser cette lampe, par contre si vraiment son ancien parent n’est plus joignable, cette manip lui permettra d’en choisir un autre.

1 « J'aime »

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.