Je ne fais que de citer ce qui est écrit sur le site 
(Perso, je n’ai pas testé : j’avais changé le firmware de ma Conbee II pour un trop récent, et pas l’intention/les moyens de downgrader. J’ai donc tout changé et refait de zéro !).
J’ai deux installations en ZigbeeLinker et Conbee II à jour avec le dernier firmware et je n’ai pas ce genre de problème.
Après ce qui est récurent avec le Zigbee c’est que si ton réseau a trop d’équipements de mauvaise qualité il devient instable.
Bonsoir Loïc,
oui, la commande passe en vert dans l’écran « commandes » de l’équipement.
Je viens de refaire le test avec un interrupteur double Aqara.
Je vois les commandes « left » ou « right » et je les répètent. La commande et l’haure de dernière communication passe au vert mais les scénarios ne sont pas déclenchés.
1 « J'aime »
As tu quand même vérifier la répétition ?
1 « J'aime »
Donc ni le plugin ni jeedom n’a de problème.
Le soucis est la config que vous avez faite (probablement dû à un manque de connaissance, rien de grave on est ici pour apprendre) ou votre scénario
Deux fois que loic pose la question => config avancée de la commande, répétition de valeur. Faites une capture d’écran pour être sur que vous avez compris de quoi on parle
1 « J'aime »
Ah ok, je n’avais pas compris
La répétition est à « Non » sur cette action (je ne l’ai pas changée, je suppose que c’est pas défaut).
Par ailleurs le scénario est en mode provoqué sur l’action du bouton.
Il ne se déclenche pas toujours, c’est ce qui m’intrigue. Cela marche parfois mais je ne sais pas dire pourquoi il ne se déclenche pas de manière systématique.
C est tipique la répétitions de valeur.
Tous les poussoirs, porte, telecommande doivent ettr sur oui
Autrement tu n as de changement uniquement si l info change de nom
Regarde la commande state ou contact dans configuration
Merci. Avec la répétition à Oui, ça à l’air de mieux fonctionner en effet.
Mais alors pourquoi ne pas le mettre par défaut sur ce type d’équipement ?
Quoi qu’il en soit, je viens de le faire sur tous les interrupteurs / boutons / capteur d’ouverture.
Parceque c’est plus consommateur de ressource puisque tu multiplies les remontées d’info et les l’historique si tu en as. Ce qui n’est pas la politique de jeedom pour lequel il faut plutôt optimiser ces facteurs. Donc à l’utilisateur de les paramétrer au cas par cas.
De mémoire, il me semble que sur ZigbeeLinker le développeur l’avait activé par défaut (au moins sur les actionneurs).
S’il est connu que cela génère des problèmes d’exécution des scénario, je ne comprends pas ce choix. Je vais finir par regretter ma migration depuis Zigbeelinker.
Oui je confirme, dans zigbeelinker,c’est activé par défaut pour les boutons aqara et seulement pour ces boutons pas pour les autres équipements aqara
Je me suis fait piéger également
Bonjour
Ce n’est pas actif car je n’ai pas moyen de savoir si il faut l’activer ou non, tout est générique pour pas que vous soyez dépendant de nous pour le support de nouveau module. En contrepartie l’intégration ne peut malheureusement pas être parfaite… Et non l’activer par défaut partout serait une catastrophe niveau performance.
A noter quand même que dans la prochaine stable ce défaut sera en partie corrigé avec la répétition active sur les commandes ayant pour nom button.
1 « J'aime »
Ok, merci Loïc.
de mon côté je l’ai aussi fait sur les détecteurs d’ouverture de porte Aqara et la commande s’appelle « contact ».
à priori c’est pas nécessaire sur un détecteur => pourquoi l’avez-vous fait? pas certain que vous ayez compris le principe.
cela ne doit être fait que si la valeur de la commande reste toujours présente (pas de retour d’état) et toujours la même et qu’elle est renvoyée (en cas de d’appui multiple par exemple);
un détecteur d’ouverture qui en principe passe de 0 à 1 (ou close à open), il n’y a pas de répétition… une porte ne va pas être « ouverte » puis de nouveau « ouverte »
En principe il y a aussi un retour d’état sur les bouton, du coup je ne comprends pas bien ce que signifie la répétition.
Pour ma part, j’avais des ouvertures/fermetures mal prises en compte et j’ai l’impression (peut-être fausse) que cela améliore la fiabilité de l’info.
Bonjour
C’est a mettre à oui que si l’équipement renvoi 2 fois la même valeur successivement. En gros une télécommande si tu appuie 2 fois sur le bouton 1 va renvoyer 2 fois btn 1 press par exemple. Jeedom par défaut ignore le 2eme appui il faut donc activer la répétition des valeurs. Une porte si elle est ouverte peut pas être ouverte a nouveau avant d’être fermée donc pas besoin de le mettre.
Pas tous. Les monostables n’ont pas de retour d’état, juste l’état quand tu appuies.
Pour les bistables, il y a peut-etre un retour d’état mais j’ai aucun dispositif qui me vient en tête, sauf un dispositif mécanique qui serait branché sur un module, donc non concerné.
Antoine
Non, il n’y a pas un retour à un état « null »
si la télécommande faisait:
- « btn 1 press » lors de l’appui
- et « aucun » après 1s (lorsque le bouton est laché)
alors il y aurait « retour à un état stable » et jeedom pourrait détecter que le bouton a été appuyé une seconde fois 30s plus tard
ok merci pour l’explication
Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.