DeconZ, Ajouter une Info avec logicalid

Bonjour à tous

[Jeedom v4.032 / Deconz v3.3.28 / RPI 3B+ sous buster / RFXcomm / Conbee II]

J’ai une télécommande Tradfri/Ikea ronde 5 boutons.
Appairement (Apairage?) Ok, j’ai bien la commande button reconnue et fonctionnelle (logicalid 01-1000.state::buttonevent).
Le visuel de l’équipement est un bouton poussoir lambda.

Je n’ai pas d’autre commande.
Je cherche donc à récupérer le niveau de batterie et si l’appareil est joignable.

Je créé donc 2 infos avec pour logicalId :

  • pour la batterie : 01-1000.config::battery
  • pour le reachable :01-1000.config::reachable

Dans le menu équipement j’ai bien la batterie qui remonte.
Dans le reseau Deconz → noeuds, j’ai bien la telecommande et le json info montre bien les valeurs de ces variables.

J’ai créé la commande batterie hier. Quand j’ai testé la commande dans l’équipement (bouton « tester ») : résultat : rien

ce matin, miracle, l’info est valorisé et j’ai bien la remonté jusque dans mon info du niveau de batterie.
Je viens de créer la commande reachable du coup. Je test => rien ne ressort, je verrai bien demain.

=> Ma question est : pourquoi cette latence? le json descriptif info est bien complet, la valeur est bien remonté dans jeedom, pourquoi est ce que je n’arrive pas à la lire dans la commande?

Je vous remercie d’éclairer mon ignorance sur le fonctionnement du core!

J’avais la même chose sur des capteurs Xiaomi.

Il me semble que c’est une histoire de rapport du côté de Deconz / Phoscon qui n’est fait que toutes les quelques heures.

Et côté core Jeedom, la philosophie c’est en gros de mettre à jour les commandes lorsqu’une nouvelle info arrive.

Franchement, ce n’est pas gênant pour une niveau de batterie qui ne varie pas très vite. Pour les Xiaomi, je crois qu’on peut le forcer en faisant un appui court sur le bouton servant à appairer. Et pour reachable, c’est sûrement mis à jour lorsque l’info change => il suffit d’écarte loin le capteur pour tester.

Bonjour @seb821
Merci de ta réponse,
J’ai bien compris que tout n’est pas remonté en permanence. et effectivement pas gênant pour un niveau de batterie!

Le truc c’est que je vois que les infos me semblent disponibles dans jeedom (menu des équipement et ds plugins deconz → reseau deconz ->Noeuds → info de l’équipement).

ce que je me demande, c’est pourquoi la lecture de ces info est asynchrone?

Au final ce n’est pas vraiment un problème, mais une info sur le fonctionnement interne, pour ne pas m’exciter plus tard sur autre chose de similaire, et comprendre un peu comment fonctionne jeedom.

C’est asynchrone a cause du fonctionnement zigbee. Rien a voir avec le plugin jeedom.
Ce serait possible avec les appareils alimentés mais non fait a cause de ceux sur batteries.
Les appareils sur batterie se mettent en veille, et ne répondent plus aux commandes, donc tu ne peut pas leur demander le niveau de batterie, c’est eux qui decident de te l’envoyer quand ils en ont envie.

Pour le reachable, c’est le plugin deconz (pas celui de jeedom) qui décide, c’est a partir d’un certain temps sans réponse du capteur, celui la passe en reachable = false.

Merci HugoVal11

Je pensais que la commande info permettait juste de lire le json stocké (et visible) dans jeedom, pas qu’il allait envoyer une requête à l’équipement…

=> Du coup l’info existe en multiplicate dans l’écosystème (?)

Juste pour être sur d’être compris :

si je regarde :

j’ai bien :

de même dans :


j’ai
pb%20lecture%20asynchrone-05

mais quand je créé la commande et que je la test j’ai :

Après un certain temps, la variable se valorise, donc probablement quand l’appareil sort de veille et transmet ses infos.

Donc j’en déduit que lorsque l’appareil sort de veille, il envoie ses info, deconz les reçoit et redistribue aux variables qui y sont abonnées?
=> les variable n’interrogent pas Deconz, mais sont valorisées par lui?

J’ai bon?

Encore merci

B

Alors je n’ai pas regardé le code de jeedom, mais oui, il y a des valeurs stockées dans jeedom (état des lampes par exemples, ou niveau batterie) et d’autres (ainsi que les mêmes) dans deconz (le JSON vient de la).
En cas de modification deconz envoi une information via websocket (tu peux la voir dans les logs), et ça permet a jeedom de mettre a jour les premières valeurs (jeedom reçoit les infos comme l’état des lampes ou le niveau des batterie).
Tu peux aussi utiliser les commandes pour aller lire le JSON dans deconz, tu auras les valeurs mémorisées dans deconz.

Mais si l’etat des lampes change (plus ou moins) en direct, l’état des batteries n’est mit a jour que quand le reseau zigbee lache les infos.
Donc pas de notification via websocket, donc deconz ne change pas ses valeurs mémorisées, tu peux aller lire les valeurs toi-même dans le JSON de deconz, mais tu auras les mêmes, car si les valeurs avaient été modifiées, il y aurait eu une notification.

L’info vient du reseau zigbee, deconz la stocke dans le json, si il y a une modification il prévient jeedom de mettre a jour ses informations. Jeedom choisit les infos qu’il veut mémoriser ou pas et a la possibilité de les redemander a la demande.

Pour les batteries, tu as regardé dans anaylse/équipement ?