Problème changement d'état détecteur de porte

Ricou4064 · Août 30, 2022, 7:12

Bonjour,

J’ai plusieurs détecteurs de portes qui ne changent plus d’état. Il restent tout le temps à 0, comme si la porte était fermée.
A priori ils communiquent bien avec la box puisque je peux aller sur l’équipement et faire un test de commande d’état.

Savez vous pourquoi il y a ce bug et comment le corriger ?

Merci d’avance

Idaho947 · Août 30, 2022, 7:28

Quel est la marque du détecteur ? La commande test renvois juste la valeur enregistré sur la commande, pas sont état en temps réèl.

Ton capteur a du perdre la connexion avec le routeur et ne l’a pas retrouvé. Au hasard je dirais aqara ou tuya ?

Ricou4064 · Août 30, 2022, 9:14

Ok merci pour les infos.
Effectivement je vois que la date de dernière communication date de plusieurs jours

Fabricant : LUMI
Modèle : lumi.sensor_magnet.aq2

Idaho947 · Août 30, 2022, 9:27

Essaie de les réinclure a leur endroit. Mais c’est un problème connu avec ces capteurs.

Ricou4064 · Août 30, 2022, 9:55

ok merci je vais tenter ça.
Le plus embêtant c’est surtout de ne pas avoir l’information que le capteur a perdu la connexion…

Idaho947 · Août 30, 2022, 10:05

Normalement tu as un message dans le centre de message jeedom si le module est vu comme hors connexion par phoscon.

Ricou4064 · Août 30, 2022, 12:05

et non justement j’ai équipement dans le même cas et aucune info…

Idaho947 · Août 30, 2022, 12:16

tu as pas coché la case :

dans phoscon le capteur apparait comment ?

Ricou4064 · Août 30, 2022, 2:23

quand je vais sur les noeuds deconz effectivement il est NOK

k6_TV · Août 30, 2022, 7:34

Salut,

Perso pour pallier a ce genre de probleme (enfin, plutot etre averti qu’il y a un « couac »), j’ai fait un scenario programmé toutes les deux heures qui check la remontée d’infos des capteurs d’ouverture (j’ai fait la même pour les NUT (mais le check se fait au delà d’une semaine de non réponse car en déplacement pro assez souvent) et les capteurs de mouvements (check de 24 egalement) sur le même principe) :

D’abord je fais un check uniquement quand mon home mode est activé (donc quand je suis chez moi), je fais une variable « SeuilAlerteCapteurPorte » qui va réagir au dela de 86400 secondes => 24h quoi, ensuite je fais un refresh de tous les capteurs (petite pause de 30 secondes, le temps que toutes les valeurs soient remontées) ensuite je compare les valeurs de collecte des valeurs de « Température » et pas des ouvertures, car il se peut qu’une porte ne soit pas ouverte depuis plus de 24h.
Enfin j’envoi le rapport par Telegram a mon bot qui me fait une synthèse.

Au final, je peux me rendre compte très rapidement s’il y a un probleme de piles ou autre perte de connexion avec le relais Zigbee

J’espère que ca pourra t’aider dans de futures remontées d’erreurs (même si ca ne résoudra pas forcément pour l’instant ton soucis de capteurs…)

Emlivyo · Août 30, 2022, 7:47

Bonjour,

On est d’accord que ca revient à l’alerte communications proposée par jeedom ?

k6_TV · Août 30, 2022, 8:02

ben disons que j’ai pu constater avec regrets que la remontée des niveaux de batteries n’est pas très efficace (bcp d’appareils zigbee ne remontent pas correctement les piles, notamment les NUT et certains capteurs)… avec ce scenario je vais un peu plus loin que la simple vérification du niveau de pile mais de la continuité du dialogue avec les appareils, et puis je peux gérer des alertes par mail (ou par telegram dans mon cas)

Didier3L · Août 30, 2022, 8:46

Voir ici

Idaho947 · Août 31, 2022, 5:06

Normalement avec deconz il y a une alerte dans le centre de massagerie jeedom quand le module passe ko en liaison. Soit tu l’as pas vu soit le module est ko depuis le debut. Mais ça marche très bien.

Ricou4064 · Août 31, 2022, 5:57

Merci à tous pour toutes ces infos… faut que je prenne un peu de temps pour regarder tout ça…

Henri · Août 31, 2022, 6:52

Bonjour
Je suis totalement de l’avis de @k6_TV
Cette méthode est très puissante / sur cette base (la mesure de la dernière communication)
elle permet :

d’être averti en cas de coupure de courant (les modules arrêtent de communiquer brutalement…)
d’avoir des alertes répéter, avec des temps de détections tres court (par exemple j’ai 2 module z-wave réglé avec une communication toute les 2 minutes, apres 3 minutes sans com, je suis averti jusqu’a valider l’info. Cela sert pour la coupure de courant ou le brouillage de communication)
D’avoir des alertes selon des heures.
de pouvoir faire des graph de communication. Par exemple savoir si un module se met à trop discuter et ennuyer le réseau (ça m’est arrivé 2 fois, en z-wave, avec des prise Nodon, sans cela j’aurais cherché longtemps pourquoi le réseau était si lent) ou simplement tirer plus qu’attendu sur les piles car le temps de réveille c’est modifié tout seul (ça m’arrive régulièrement sur des vannes danfoss qui reprennent toute seul leurs réveille à 300 sec, quand je souhaite les avoir à 900)

Bref, ça complète se qui existe dans Jeedom en allant beaucoup plus loin.

Henri · Août 31, 2022, 7:34

Mini précision: Si tu veux avoir le temps de communication du module (et pas d’une valeur du module), il y a l’outil lastCommunication(#[Objet][Equipement]#) qui est tres bien.
Voici un extrait de mes tests de l’époque :

----- @ Log TEST : rad henri @ -----
@ Module seul :
timestamp =: #timestamp#
strtotime_collectdate =: strtotime(collectdate(#[Chambre Henri][Radiateur - Sud]#))
---- timestamp - strtotime_collectdate  =: round(#timestamp#-strtotime(collectdate(#[Chambre Henri][Radiateur - Sud]#)),0)
---- strtotime de collectdate - timestamp   =: round(strtotime(collectdate(#[Chambre Henri][Radiateur - Sud]#))-#timestamp#,0)
@
lastCommunication := lastCommunication(#[Chambre Henri][Radiateur - Sud]#)
date =: date(Y-m-d H:i:s)
time_diff avec last com =: time_diff(date(Y-m-d H:i:s),lastCommunication(#[Chambre Henri][Radiateur - Sud]#),s)
soit en heure / min / sec :
date('H:i:s',strtotime(lastCommunication(#[Chambre Henri][Radiateur - Sud]#))-strtotime(now))

En première / seconde partie, avec collectdate() / LastCommunication()

[2022-08-31 09:32:46][SCENARIO] Log : ----- @ Log TEST : rad henri @ -----
@ Module seul :
timestamp =: 1661931166
strtotime_collectdate =: 1661941966
---- timestamp - strtotime_collectdate  =: -10800
---- strtotime de collectdate - timestamp   =: 10800
@
lastCommunication := 2022-08-31 09:24:43
date =: 2022-08-31 09:32:46
time_diff avec last com =: 483
soit en heure / min / sec :
00:51:57
[2022-08-31 09:32:46][SCENARIO] Fin correcte du scénario