je suis à la recherche de détecteurs de fumées compatibles zigbee vers conbeeII.
J’ai bien vu les « Smart Smoke Sensor Heiman HS1SA » et équivalent zipato, mais je ne les trouve que sur AliExpress, et je n’ai eu que des mauvaise surprise avec eux (a contrario d’autres vendeur chinois).
Je suis preneur de toute ref, raisonnable dans son prix, si possible de revendeur en france ou européen, voire même d’occaz.
Merci!
Ben
[edit] -----------------
J’ai pu recenser :
ZSDR-850 (lien)
qui ressemble qd même beaucoup au Heiman
Je me suis finalement décidé à passer par AE… et ça s’est bien passé, une première!
Bref j’ai mes Heiman HS1SA, et j’ai quelques bizarreries :
1/ j’ai du appairer directement dans phoscon pour avoir la remontée de l’alarme
quand je passe par le plugin jeedom, j’arrive a appairer, mais je n’ai pas la remontée de l’alarme.
2/ je n’ai pas la remontée de la batterie, ni du status « reachable », ni du paramètre tampered !?
Si je refait une inclusion, ils peuvent parfois apparaitre, mais je perd la remontée de l’alarme fumée… ce qui est pour le moins emmerant…
Et depuis maintenant une 15aines de jours, toujours pas de remonté de ces status. Les autres équipement zigbee la remonte en générale l’info sur 24H.
3/si je change le nom de la commande de base (Fumée 01-500) dans l’équipement,… je perd la remontée de l’info ?? je ne vois pas comment ça peut être corrélé, mais testé plusieurs fois, et j’ai du supprimer et réinclure le module
4/ les détecteur remonte bien dans l’API (IP:8484/api/apikey/sensors), mais ne sont pas visibles dans phoscon. problème retrouvé sur le net
pour info : jeedom v4.0.58 / plugin DeconZ du 2020-07-02 01:00:15 / ConbeeII v 2.05.71 / 17/11/2019 FW 264A0700
Si qqu’un a des indices, j’ai peur de ne pas voir un détecteur qui tombe…!
j’ai par contre les poil des aisselles qui flageolles à l’idée de mettre à jour le fw de la conbee, car tout le reste fonctionne à merveille! (j’ai bien vu ds la release 2.05.75 :" Add binding / attribute reporting for various Heiman devices 5f60db", est ce que ça va changer énorme?)
Ne confonds pas mise à jour du firmware (qui n’est pas 2.05.75) et mise à jour de l’api deCONZ (qui est bien en 2.05.77 en version stable).
Cette dernière peut être mise à jour depuis Jeedom depuis la page de configuration du plug in Deconz (installation) ou depuis la page des mises à Jour des plug in Jeedom (conseillé) . Attention à bien cliquer là où il faut et pas ailleurs. La clef Conbee n’est pas concernée par cette mise à jour. Aucuns risques sur cette MAJ standard vu de Jeedom.
Pour le firmware de la ConBee2 il ne faut pas y toucher depuis Jeedom mais le faire en lignes de commande (aucun risque à condition d’être un poil rigoureux) soit sous Win10 soit sous Debian. Il y a de nombreux posts sur ce forum pour cela (voir la synthèse faite par @akenad sur ce sujet)
Bonjour Yves,
Merci, j’ai lu la demande sur le git (plusieurs fois!), il y a aussi la #984 et quelques article pour des système domotique.
Ok merci pour la version de l’api, comme tout est noté dans une page « gateway », difficile de voir qui est à qui.
=> le plugin DeconZ est à jour, mais à priori pas l’api => dans la page de gestion du plugin je doit relancer « installation DeconZ local » ?
(J’avoue que je suis tout autant rassuré que pour le fw de la gw, vu le nbre de pb remonté ici. [edit] ok, vu l’edit de ton message, je pense que je vais commencer par là)
pas de pb pour les ligne de commande, a peu près tout ce qui tourne chez moi à une distrib debian, mais si je plante le zigbee je perds 80 % de mon installation. => cette étape attendra le retour de congé histoire de reposer le waf avant l’attaque.
=> le plugin DeconZ est à jour, mais à priori pas l’api => dans la page de gestion du plugin je doit relancer « installation DeconZ local » ?
Yes c’est cela même. Une fois la maj effectuée il faudra redémarrer le démon. Je préconise avant toute mise à jour (recommandation générale et non spécifique) de faire une sauvegarde Jeedom ET une sauvegarde de la configuration et de la topologie du réseau Zigbee depuis Phoscon (back up de la configuration suivi du téléchargement qqpart bien au chaud comme un stick USB par exemple)
Les detecteurs de fumées sont visible via l’api donc dans jeedom mais pas dans phoscon.
Tu peux aussi mettre a jour le firmware en allant sur phoscon/gateway et cliquer sur le bouton si il te le propose (il y aura un message qui te dira si le firmware est a jour ou pas en fonction de ta version de deconz), la ligne de commande est en cas de problemes.
La mise à jour du firmware dans sa version up to date n’est proposable que depuis la version 2.05.77 Phoscon à minima. Donc la première étape est de faire la mise à jour de deCONZ (Phoscon). Sur les versions antérieures de deconz (Phoscon), c’est le firmware 264A0700 qui reste proposé.
Ben c’est normal, ca évite qu’une personne utilise un firmware trop récent sur une version de deconz trop vielle. Si Phoscon ne te propose pas de nouveaux firmwares, tu n’as pas a y toucher, sauf si tu as des problemes.
J’ai attendu pour voir la remontée spontannée, et y’a des truc qui remontent, mais bizarrement, pas tous les mêmes :
en rouge, ce qui n’est pas remonté depuis le changement (sauf le tampered),
Globalement ce qui remonte vient de l’ensemble « config » du json, mais ce qui est ds « state » n’a pas été mis à jour depuis mes dernier tests d’activation.
pour info la config :
Bonjour.
Sur l’exemple de Json que tu montres on voit que l’équipement a bien été vu sur le réseau récemment mais par contre il n’a pas updaté ses informations depuis le 12 juillet visiblement ce qui serait possible si rien n’avait changé au niveau de la détection mais qui n’est pas normal si tu as fait des tests de déclenchement.
As tu tenté de récupérer les informations directement depuis REST Api sous Firefox par exemple ?
Cette interface réalise à peu près la même chose que ce que fait Jeedom mais en commande directe « asynchrone » plutôt que sur évènement (websocket).
Si dans la base il n’y a pas d’infos rafraichies cela veut dire que le capteur ne les remonte pas où qu’elles ne sont pas correctement reçues par la clef ConBee2.Il faudra passer par deCONZ pour aller plus avant dans le diagnostic du capteur .
Dans le cas contraire c’est qu’il y a un pb de rafraichissement des données entre Jeedom et la base. Un nettoyage des caches Jeedom (et du navigateur tant qu’on y est) devrait remédier à ce dernier cas.
Salut,
Oui, c’est ce que j’ai supposé, mais ça pourrait remonter régulièrement, difficile de savoir si l’info « lowBatt » est fiable du coup (vu comment l’info battery l’est déjà).
J’ai pu faire les tests sans réveiller toute la famille.
=> à la simulation du déclenchement, ça remonte bien les infos dans state
=> bien que remonté lors de la simu de déclenchement, le tampered ne change pas d’état, bien qu’il y ait à priori un contacteur (j’ai pas démonté, mais il y a un ergot avec un ressort).
Ce qui m’étonne, c’est la remonté dans config.
Par exemple pour le 1ère ligne, le « Batt » qui est le config::battery a bien été mis à jour (variable valorisé), mais pas le « On » ni le « reachable » (qui lui vient de phoscon et pas du device à priori).
Ben non justement, le « On » es bien a true dans le json, mais à priori n’a pas été updaté avec les autres (eg batterie pour le 1er) étant donné que la variable dans l’équipement n’a pas été valorisé, du coup par défaut, vide/null=> false,
idem pour le reachable
Normalement au démarrage le plugin récupère toute les infos (de la même manière que toi le noeud).
Ensuite il ne met a jour que les valeurs qui lui reviennent par le websocket, si rien de bouge, il ne reçoit rien, et ne met rien a jour.
Mais c’est une vision de l’esprit, mettre a jour implique la notion de changement, on ne met pas a jour une variable « on »= « true » avec la valeur « true », car elle est deja a jour.
Il peut y avoir des notifications automatiques comme pour les batteries, mais c’est pas une obligation.
