Comment récupérer les date et heure de la dernière communication d'un capteur d'ouverture ou autre ?

[Tam]

Bonjour,
Je voudrais pouvoir récupérer l'horodatage de la dernière communication d'un élément Aqara pour pouvoir l'utiliser dans un scénario ou dans un script. Ça serait par exemple pour m'envoyer un mail quand un capteur n'a pas été vu depuis plus de x temps.
Quelqu'un pourrait-il me dire si c'est possible (ce dont je ne doute pas) et surtout par où chercher ?
Merci.

Tam

[lunarok]

un petite recherche sur le forum avant, car c'est assez générique et pas lié à xiaomi, exemple :
viewtopic.php?f=32&t=24977&p=457689&hil ... re#p457689

[Tam]

Super, merci !
Je t'assure pourtant que j'avais cherché longtemps mais que sur la partie Xiaomi.
Bon, faut dire aussi que je découvre depuis peu l'univers Jeedom...

[extrapitou]

Je rebondis sur ta question, pour approfondir.

J'ai remarqué qu'en faisant un collecdate sur la commande température d'un Aqara c'est moins fiable qu'un collectdate sur la commande batterie de ce même module. (J'ai l'impression que même si pas de remontée de T° car pas de variation, il remonte l'info batterie qd même)

C'est possible que chaque commande aie une collecdate différente ?



Envoyé de mon ONEPLUS A3010 en utilisant Tapatalk

[Tam]

Salut,
Pour avoir pas mal essayé depuis hier... Je pense que ce n'est pas un histoire de fiabilité. Le capteur d'ouverture (par exemple) semble n'envoyer les données d'ouverture/fermeture que s'il se passe quelque chose de ce côté. Par contre sans événement, il envoie à intervalle régulier une trame avec son niveau de batterie. Ça permet au système de vérifier que le capteur est toujours opérationnel et visible.
Du coup si tu fais un collectDate sur Ouverture tu récupères la date de la dernière trame avec l'info d'ouverture. Un collectDate sur Batterie te donne la date de la dernière communication tout court.

Tam

[Tam]

Salut,
Ça fait quelques jours que je joue avec collectDate et ça me permet de voir des trucs sympas comme par exemple que les capteurs d'ouverture rafraîchissent leur présence exactement toutes les heures. Ça me permet de déclencher une alerte lorsqu'un capteur fait le mort plus longtemps que la normale. D'ailleurs le protocole a beau être bidirectionnel, il y a quand même des trames qui se perdent de temps en temps. Dommage que le capteur ne sache pas mémoriser qu'il a été incapable de communiquer à un moment donné. Ça aurait été utile comme info.
Par contre je suis obligé de lancer mon scénario périodiquement et non pas sur réception d'une trame avec #[][][Pile Voltage]# car comme le niveau des piles varie peu, Jeedom ne détecte aucun changement et ne déclenche pas mon scénario à la réception de la trame.
Quelqu'un saurait-il comment déclencher un scénario même lorsque la trame dit que rien n'a changé ? Et même, comment historiser une valeur même si c'est la même que précédemment pour avoir une traçabilité de la communication ?

Tam

[Tam]

"Par contre je suis obligé de lancer mon scénario périodiquement et non pas sur réception d'une trame avec #[][][Pile Voltage]# car comme le niveau des piles varie peu, Jeedom ne détecte aucun changement et ne déclenche pas mon scénario à la réception de la trame.
Quelqu'un saurait-il comment déclencher un scénario même lorsque la trame dit que rien n'a changé ? Et même, comment historiser une valeur même si c'est la même que précédemment pour avoir une traçabilité de la communication ?"

Je me réponds à moi-même concernant le "filtrage" des déclenchements sur valeurs identiques: Il suffit de configurer le déclencheur en question en "toujours répéter" dans la rubrique "configuration avancée" et "Gestion de la répétition des valeurs".

Tam

[Tam]

Salut,
Heureux utilisateur de collectDate(), j'ai l'impression qu'il y a un bug depuis la dernière version de Jeedom (3.2.11).
En effet, j'ai mes alertes d'absence de communication Xiaomi qui s'affolent alors qu'elles fonctionnaient bien jusqu'à présent.
Comme on peut le voir sur ce screenshot, la date retournée par collectDate ne correspond pas à ce qu'on voit dans l'onglet Santé du Plugin Xiaomi.
Quelqu'un saurait quelle commande utiliser pour avoir la même date que celle du plugin ?
Merci.

Tam

collectDate.png (21.41 Kio) Consulté 6935 fois

[Seb82]

@Tam, j'ai le même soucis avec collectdate depuis une mise à jour, et sur des informations provenant de plugins différents.

J'ai fait un rapport de bug, on verra ce que ça donne : https://jeedom.atlassian.net/browse/JEE ... ted%20DESC

[winhex]

moi j'utilise valuedate depuis la v3

tous comme jeedom avec le widget qui calcul le temps de changement d'État

regarder le tooltip " pop up lorsqu'on pointe la souris dessus"

(valeur du .. / collecté le ...)
valuedate / collecdate

si on modifie en toujours répéter

[Tam]

@Seb82: Merci pour ta réponse et ton intervention. La réponse vient de tomber et malheureusement elle n'est pas très satisfaisante:

Loïc a ajouté un commentaire - Il y a 3 heures
Bonjour,
En faite c'est normal c'est pour éviter de trop charger jeedom, en cas de changement de date de collect sans changement de la valeur nous ne mettons plus a jour l'interface.

Du coup plus de différence entre collectDate et valueDate alors que dernière communication et dernier changement d'état n'ont pas du tout le même usage.
Un idée sur une solution/fonction alternative pour récupérer la date de dernière communication ?
C'est possible puisque dans la synthèse santé du plugin elle apparaît.

@windex: Il ne se passe rien quand je passe mon pointeur sur la date de dernière communication du rapport de santé.

Tam

[Seb82]

Je ne sais pas quoi penser. Peut-être qu'il y a confusion. J'avais déjà ouvert un ticket il y a un moment sur le sujet de la mise à jour de collectdate qui ne faisait pas en temps réel: https://jeedom.atlassian.net/browse/JEED-590
Et effectivement là je peux comprendre la réponse que ce soit pour ne pas surcharger l'interface, parce que ça voulait dire en permanence des mises à jour des widgets pour pas grand chose. Par contre, ça fonctionnait quand même lorsqu'on rechargeait la page.

Là, dans tous les cas collectDate ne fonctionne plus, et c'est très dommage.

Dans les doc, les descriptifs des deux fonctions sont les mêmes (je ne sais pas si c'était le cas avant), par contre les exemples renvoient deux choses différentes.

Bref, si c'est un choix entériné, ça va être nettement plus compliqué pour surveiller s'il y a un problème de remontée d'information.

[fredisere]

bonjour,
L'alerte communication dans la configuration avancée de l'équipement, ne répond -elle pas à votre besoin ?
Certes, ça ne remonte pas la date et heure de la dernière com, mais au moins on est alerté quand ça ne communique plus, et on peut retrouver l'info exacte avec la fonction santé du plugin,

[Tam]

@fredisere: Merci pour ta proposition mais collectDate me servait à détecter une élément ne communiquant plus mais surtout à détecter une communication ayant échouée. En effet, un capteur d'ouverture Aqara remonte une trame de présence de vie au bout 3630 secondes depuis la dernière communication si aucun événement n'est détecté. En mesurant le délai entre 2 collectDate, je pouvais détecter qu'une trame d'ouverture ou fermeture s'était perdue entre-temps ce qui arrive assez souvent avec un capteur un peu éloigné.
J'espère qu'une solution va être proposée ou qu'un retour en arrière est possible...

[barbo77]

Bonjour
j'ai relu le message de Loic, il dit bien que CollectDate est mis à jour (en base)... en cas de changement de date de collect sans changement de la valeur nous ne mettons plus a jour l'interface.
Seule l'interface ne serait pas mise à jour
Cordialement

[TaG]

Hello,

Je suis sacrément embêté par cette modification et n'ai pas la même lecture que toi @barbo77.

J'ai un scénario de monitoring de tous mes équipements dit importants et sur pile (mouvement/ portes / nut / etc).

J'ai des alertes car problème de communication, je fais le tour tout est ok.
Je check sur chaque capteurs deux informations si c'est justifié.
La je n'ai que les capteurs de mouvement Xiaomi et le détecteur de gaz xiaomi qui me pose problème.

Je vérifie dernier mouvement et dernière remontée de batterie.
Mais en l'état, le dernier mouvement est bien renvoyé et mis à jour car changement de valeur (0 ou 1).
La batterie n'est pas mises à jour par contre.

Voici ma définition de variable :




Voici mon test IF :

Code : Tout sélectionner

(#timestamp# - strtotime(collectdate(#[Chambre d'amis][Capteur_Mouvement_Ch_Amis][Mouvement]#))) > variable(SeuilAlerteMouvement) OR  (#timestamp# - strtotime(collectdate(#[Chambre d'amis][Capteur_Mouvement_Ch_Amis][Batterie]#))) > variable(SeuilAlerteBatterie)

Voici le résultat d'une comparaison pour la batterie dans le testeur d'expression :


Forcément, ça m'alerte vu que la comparaison est supérieure au seuil déclaré dans mon scénario.


Je fais un refresh avant chaque lancement du scénario via la commande refresh de chaque capteur xiaomi pour être à jour et éviter ce phénomène.
La valeur de batterie est bien récupérée, mais non mise à jour dans jeedom et ça n'est pas qu'une simple interface non mises à jour à mon sens :

Code : Tout sélectionner

[2018-08-17 11:42:56][DEBUG] : Send to jeedom : {u'devices': {u'aquara_158d00014d520e': {'short_id': 420, 'cmd': u'report', 'source': '192.168.1.230', 'token': '', 'sid': u'158d00014d520e', 'model': u'motion', 'data': {u'no_motion': u'120'}}}}
[2018-08-17 11:43:56][DEBUG] : {u'model': u'motion', u'cmd': u'report', u'data': u'{"no_motion":"180"}', u'short_id': 420, u'sid': u'158d00014d520e'}
[2018-08-17 11:43:56][DEBUG] : Send to jeedom : {u'devices': {u'aquara_158d00014d520e': {'short_id': 420, 'cmd': u'report', 'source': '192.168.1.230', 'token': '', 'sid': u'158d00014d520e', 'model': u'motion', 'data': {u'no_motion': u'180'}}}}
[2018-08-17 11:45:38][DEBUG] : Message read from socket: {"apikey":"MaClefaMoi","type":"aquara","model":"read","cmd":"refresh","dest":"IP.XX.XX.XX","password":"MonPassword","sidG":"f0b429cc70b6","sid":"158d00014d520e"}
[2018-08-17 11:45:39][DEBUG] : executing {u'apikey': u'MaClefAMoi', u'dest': u'IP.XX.XX.XX', u'cmd': u'refresh', u'sid': u'158d00014d520e', u'model': u'read', u'password': u'MonPass', u'type': u'aquara', u'sidG': u'f0b429cc70b6'}
[2018-08-17 11:45:39][DEBUG] : {u'model': u'motion', u'cmd': u'read_ack', u'data': u'{"voltage":3015}', u'short_id': 420, u'sid': u'158d00014d520e'}
[2018-08-17 11:45:39][DEBUG] : Send to jeedom : {u'devices': {u'aquara_158d00014d520e': {'short_id': 420, 'cmd': u'read_ack', 'source': '192.168.1.230', 'token': '', 'sid': u'158d00014d520e', 'model': u'motion', 'data': {u'voltage': 3015}}}}

Et le rendu coté capteur pour la commande batterie :




Et pour le capteur de gaz, je n'ai aucune autre solution, il faudrait que je fasse un coup de gaz dans le vide tous les jours pour être sur qu'il communique...

Est-ce qu'une correction est prévue? Merci

[Seb82]

Pour ma part, je suis d'accord avec barbo77 dans le sens où le message de Loïc parle effectivement uniquement d'une mise à jour de l'interface, ce qui fait pensait que la date de collect est quand même mise à jour.

D'ailleurs, j'ai pu constater que sur un bouton remonté par le plugin Xiaomi Home de type "string" cela fonctionne comme le montre l'image ci-dessous. Et cela met même à jour la page ouverte sans besoin de la recharger.



Par contre, sur une information de type string remontée par le plugin MQTT, cela ne fonctionne pas, il faut effectivement qu'il y ait changement de la valeur pour que collecDate change.

Mon sentiment, c'est que comme j'avais déjà ouvert un (autre) rapport de bug qui concernait effectivement la mise à jour de l'interface, peut-être qu'il y a eu une interprétation erronée de ce que j'ai remonté après, je ne sais pas.

Ce qui serait bien je pense, c'est quelqu'un ouvre un autre rapport de bug en exposant bien son problème et le lien de cette discussion, et demande spécifiquement si la fonction collectDate est effectivement complètement abandonnée (ce qui ne semble pas transparaître ne serait-ce parce que les widgets auraient été mis à jour), ou bien si on est finalement juste face à un bug.

[Tam]

Salut,
J'ai donc ouvert un ticket à ce sujet:
https://jeedom.atlassian.net/browse/JEED-657
Croisons les doigts ou mieux, votez pour cette demande !

Tam

[Seb82]

Je viens de regarder la réponse du ticket, et c'est plutôt une bonne nouvelle : "Il y a effectivement un soucis qui sera corrigé dans la version 3.3.x. Merci pour le retour."

Plus qu'à attendre la version 3.3.x mais au moins ce sera corrigé.

[minscof]

En attendant la correction sur le fonction collectDate, je reviens sur la différence entre le champ date de dernière communication positionné au niveau de l'équipement et la fonction collectDate qui concerne une commande. Dans certains cas, il semble donc que l'ensemble des commandes d'un même équipement n'ont pas la même collectDate, du coup, je ne vois pas de moyen simple de déterminer la date de dernière communication d'un équipement sans contrôler la collectDate de toutes les commandes de cet équipement.

Y a t il un moyen simple d'accéder à cette information affichée au niveau de l'équipement dans l'interface Jeedom ?