Batterie Ok, j’ai les avais inversé hier pour tester.
Pas de bip toutes les 10s, ni aucun bip d’ailleurs.
Quand il a sonner, j’ai appuyé sur le bouton, et pas fait attention de ce qui s’est passer après.
Mais une dizaine de seconde après il repassait à Smoke 0.
Hier j’ai tester de lui souffler de la chaleur (avec mini décapeur) pour voir si c’était lié. Aucun résultat…
Edit : Nouveau Test
Détecteur en veille, Smoke = 0
Vapotage, Smoke = 2 + bip + Led clignotement rapide
Appuie sur bouton, stop bip, Led clignote toutes les 10s, Smoke =2
Le temps que la fumée se dissipe, Smoke = 0, Led tjs en clignotement 10s.
J’ai aussi changer la tempo du wake up à 300s pour voir si le 254 est lié à l’actualisation.
@Mips : quel est l’intérêt, ici, de mettre Smoke (113/1/4) en binaire ? Vu qu’il peut prendre plusieurs valeurs, 0, 2 et 254.
La détection semble uniquement modifier la valeur de Smoke. 0 (ou 254…) quand il n’y a pas de fumée et 2 quand il y en a.
J’ai donc adapté mes scénarios en fonction de ça.
Maintenant, c’est clair que ça semble bizarre quand même. Cette commande n’est pas présente par défaut, il faut la créer soit-même. Il y a par défaut par contre la valeur Fumée (Sensor), en 48/1/0, mais qui semble inactive. Et qui n’apparaît même pas non plus sur le widget. Un bug dans cette version du firmware ?
Bon pendant toute la semaine le smoke était à 0 et samedi matin à 00h24 passage à 254 sans raison particulière.
Au vu du délai assez long, je ne vais rien toucher et attendre le week end prochain pour voir si le smoke change de valeur.
A suivre…
Bonjour à tous,
Cela fait 3 semaines que je me bas avec ce module.
Smoke passe à 254 aléatoirement (20h à 5 jours).
J’ai constaté que le pourcentage de la batterie est passé de 98 à 88 en 45 mn quand smoke est à 254.
Quand le Smoke est à 254, la détection de fumée fonctionne.
Je continu mes tests …
Merci à tous pour vos informations.
Et bien depuis un mois que je les ai remis en place avec les scénarios adaptés, ils ne sont pas repassés à 254… alors qu’ils l’étaient avant. Donc de mon côté, rien de neuf .
Je viens vous voir sur ces détecteurs qui semble bien fonctionner avec les paramètres changés à la main après inclusion.
Par contre il reste à « Détection de fumée » combien de temps ?
Car pendant le test il reste juste une seconde et retombe tout de suite à 0
Ok j’espérais un peu mais j’ai pas appuyer trop longtemps car cela casse les oreilles et Madame rouspète.
Mais je vais tenter plus longtemps aujourd’hui pendant son absence
Le retour Smoke ne peut pas être binaire (boolean) comme selon le guide la valeur peut être 0x00, 0x01 ou 0x02. C’est par ailleurs bizarre, que les valeurs sont données en XBM mais soit. Le binaire (boolean) ne peut en principe avoir 0 et 1. Le retour 254 semble indiquer que le vrai format est byte (octet 0…255) donc quand la précision de la transformation numérique fait basculé le valeur résultant sous 0, la valeur résultant se trouvera dans l’autre bout de l’échelle. Tout cela pour dire que le problème est probablement le format binaire (boolean) de Smoke qui n’est pas correcte.
C’est ca, ensuite dans la formule de calcul il faut mettre #value#==2 pour avoir l’info binaire
et c’est donc bien une commande info binaire à garder sur l’équipement, plus facile pour les widgets etc
Le 254 apparait chez moi après un redémarrage du démon et que le détecteur n’a envoyer aucune info, un peut comme si c’était l’état « inconnu »
PS: il est quasi 23h et celui avec la croix est le seul détecteur que je n’ai pas encore testé via le bouton / gaz et son statut est à 1 par défaut (constat identique sur chaque détecteur fraichement installé) …
Question : au vu des remontées de certaines personnes dans ce fil, comment tracer le changement d’état de la valeur smoke ? car je sais historiser les changements de valeurs de commandes mais c’est tout.
Enfin, et c’est là où je ne comprend plus rien, perso quand je teste mes detecteurs avec le bouton ou un gaz dédié au test, la valeur de la commande Fumée passe à 1 et non 2 comme j’ai pu lire plus haut au sujet de la valeur smoke. Soit j’ai raté un truc, soit je ne comprends pas pourquoi la valeur smoke pourrait retourner la valeur 2 et la commande Fumée, me retourner la valeur 1 ?! J’en reviens à ma question précédente, si je pouvais logguer (ou consulter les changements qqpart) les valeurs de smoke, j’en saurai plus je pense.
Bonjour,
Aucun bug nul part.
Les commandes batteries ne sont pas créés car cela ne sert à rien vu que c’est intégré au menu analyses>équipements. C’est comme cela pour énormément d’équipement.
Les commandes ne sont mises à jour avec les valeurs que lorsqu’une valeur remonte donc c’est normal qu’elle ne soit pas initialisé.
Une exclusion/inclusion ne sert qu’à inclue le module au contrôleur, rien d’autre. Donc il faut arrêter d’exclure / inclure à tout va pour le moindre pseudo problème.
Il y a une différence de concept entre les valeurs zwave et les commandes info de jeedom.
Les premières sont interprétées dans les deuxièmes.
« Smoke » est une des valeurs du module, qui vaut 0,2 (et parfois 254). C’est un byte.
« Fumée » est la commande de l’équipement correspondante qui est une info binaire (selon la config et les termes jeedom).
Relisez les posts précédents et vous auriez trouvé toutes ces infos. Surtout mon message précédent pour vérifier la config de votre commande fumée.
la raison pour laquelle j’ai exclu le module c’est que la première fois, le détail du fabricant n’était pas listé …
Je ne crois pas avoir le réponse à ma question : est-il possible d’historiser le valeur smoke pour voir qd elle change d’état et quelle valeur elle prend…
Et j’insiste, ici le module est inclus mais la « négociation » n’est pas terminée (état « probe »), cela peut arriver par exemple si le module a été inclus trop loin du contrôleur.
Il faut alors réveiller le module et éventuellement utiliser l’action « Rafraichir les actions du noeud »; une nouvelle inclusion va forcément relancer ce process aussi mais c’est utiliser « un canon pour tuer une mouche ».
Votre question n’est pas clair, mais soit si je devine: oui c’est possible, créez simplement une commande (numérique si vous voulez toutes les valeurs de « smoke » ce que je devine) correspondante à la valeur que vous voulez (avec la bonne class/index/instance) et cochez la case « historiser » sur celle-ci.
Action déjà faite mais n’avait rien donnée qq heures plus tard ^^
La question est totalement en rapport avec les différents échanges du présent sujet.
A quoi bon recréer une commande que j’ai déjà ?! surtout si elle n’est pas interprétée de la même manière versus les valeurs Zwave (selon tes dires plus haut).
Yep, idem après 24h d’utilisation, sur mes 5 détecteurs, le premier installé vient de se réveiller (c’était planifié pour 20h17) et smoke est passé à 254, donc la commande associée est passée à 1.
je vais partir sur la même conf que toi, ça me parait cohérent
[EDIT du 28/01/21 16h59]
Nickel @yostral
J’ai appliqué les mêmes réglages que toi + testé via gaz cet apm et c’est OK via les scénarios et commandes adaptées !
.
