Ben comme la remontée de la batterie :« 01-0406.config::battery » j’ai fait une remontée de la durée à l’état haut : « 01-0406.config::duration ».
Après on en fait ce qu’on veux ! et dès qu’un changement de cette valeur est détecté on peut lancer le code qui le remet à la valeur désirée !
Après je pense qu’une exécution au démarrage est toujours nécessaire. A contrôler je peux pas là !
C’est plus clair ? 
(je suis pas super balaise en explications…)
pas Kon!! Grats! ça ne m’avait même pas traversé l’esprit et c’est beaucoup plus élégant
=> en plus ça va permettre de voir quand ça change!
Oui je comprends bien l’idée merci de monitorer le temps à l’état 1 (celui que l’on veut changer)
Je viens de vérifier chez moi et je n’ai pas ces commandes de battery et duration (je vais les rajouter c’est pas trop le pb) mais vous les trouvez ou ces infos supplémentaires ?
Salut Livyo
Dans les équipements deconz, dans le premier onglet, tu as le bouton configuration :
Dans la fenetre configuration, tu as le 2nd onglet « informations brutes », qui sont les données atteignabes dans jeedom (format json)
Tu verra tout en bas le « uniqueid », la fin de la chaine avec les tiret (« - ») par exemple 01-406, vont te permettre de construire le logicalid pour les commande que tu veux créer.
Une fois les infos prisent, tu vas dans les commandes, tu créer une commande
tu lui donne le nom que tu veux, choisit le bon type et dans logicalid tu rempli avec
"finde chaine avec le tiret du uniqueId".[chemin dans le json]::paramètre
ex ici chez moi les data brutes sont :
{
"33": {
"config": {
"battery": 100,
"on": true,
"reachable": true,
"temperature": 3000,
"tholddark": 12000,
"tholdoffset": 7000
},
"ep": 1,
"etag": "xxxxxxxxxxxxxxxx",
"manufacturername": "LUMI",
"modelid": "lumi.sensor_motion.aq2",
"name": "LightLevel 33",
"state": {
"dark": false,
"daylight": false,
"lastupdated": "2020-06-04T16:03:04",
"lightlevel": 13425,
"lux": 22
},
"swversion": "20170627",
"type": "ZHALightLevel",
"uniqueid": "XX:XX:XX:XX:XX-01-0400"
},
"34": {
"config": {
"battery": 100,
"duration": 10,
"on": true,
"reachable": true,
"temperature": 3000
},
"ep": 1,
"etag": "c74d83825cc228f0ebeb9d8813e22215",
"manufacturername": "LUMI",
"modelid": "lumi.sensor_motion.aq2",
"name": "Presence 34",
"state": {
"lastupdated": "2020-06-04T16:03:14",
"presence": false
},
"swversion": "20170627",
"type": "ZHAPresence",
"uniqueid": "XX:XX:XX:XX:XX--01-0406"
}
}
on voit que la duration est dans l’item 34 (les ref dans phoscon), dans la config, dont l’unique Id fini par 01-0406
=> le logical id à construire est :
01-0406.config::duration
pour la batterie, elle est présente dans le 33 et le 34 ce sera :
01-0406.config::battery
ou encore
01-0400.config::battery
tu peux avoir accès à toutes les infos qui sont là.
=> A noter que pour que la commande soit valorisée, il faut que l’info soit remonté/change par l’équipement, ce qui peut prendre un certaine temps (par ex la batterie sur ce type d’engin!)
Si tu as des équipement non standard, mais que le json est bien construit, tu peux créer les commande à la main!
Bon je viens de tester le code et ça à l’air de… fonctionner 
!! A voir dans le temps si cela reste bien toujours à la valeur désirée.
Je n’ai pas encore beaucoup de recul sur ce capteur mais est-il possible de le maintenir « réveillé » (toutes les heures, X heures…) car il me semble avoir lu qu’il pouvait « s’endormir »…
Merci
Salut Livyo
Jamais eu de pb avec une éventuelle veille des capteurs,
et franchement ce serait contre la nature d’un capteur de surveillance de se mettre en veille!
Oui ça serait dommage, du coup je vais vérifier à l’usage…
Je vais en mettre de partout de ces capteurs , si seulement ils pouvaient donner la température, ils auraient été parfaits !
Merci
ben ils donnent la température également, mais c’est loin d’être précis!
Il me semble qu’elle est toujours à 30° et c’est écrit « en dur » dans la config de l’équipement…
Et c’est @HugoVal11 qui dit ici que ce n’est pas exploitable (et dans un autre fil aussi il me semble):
@HugoVal11, tu confirmes ?
Merci
Oui, bon j’ai pas tout lu ^^, mais les information de températures des capteurs autre que des capteurs de température ne sont pas fiables, ils n’apparaissent même pas de mémoire sur l’appli Xiaomi.
Les infos sont la car présentes sur le hardware, mais aucune application ne s’en sert. Elle peuvent bouger, mais dans tout les cas inexploitables.
Alors pour apporter de l’eau au moulin, je m’étais posé la question de la pertinence de redondé la température.
J’ai un capteur de température (aqara) et un détecteur de mvt dans la même pièce. J’ai calibré le capt de température avec un thermomètre non connecté, et un peu celle du cpateur de mvt.
j’ai historisé un peu les deux températures :
en bleu le capteur de température, en orange celle par le capteur de présence. C’est quand même assez proche, même si pas ouf non plus!
bon on voit que ça ne s’update pas aussi souvent, y’a même quelques loupé,
mais quand même, pour certain usage c’est qd même suffisant (je remonte les temp. des couloir chez moi, même si peu d’intérêt)
Ben le pire étant celui d’ouverture de porte chez moi, surement a cause du cadre de la porte qui fait tampon, mais pour en avoir plusieurs, même situé au même endroit, tu peux avoir 5 degrés de différence.
Rien n’empêche de les utiliser, l’API les remonte, c’est cadeau ^^.
Gratuitement comme le dis @HugoVal11, je suis preneur d’une température comme affiche @Bben sauf que je reste autour de 30° et que je vois cette valeur écrite dans la config du module… 
Tu l’as calibré en mettant un offset à cette valeur par l’intermédiaire d’un virtuel ?
Avez-vous mis la case de config du module vide ? Moi j’ai ça:
Par rapport à tes quelques « loupés », serait-il possible de forcer le rafraîchissement des valeurs pour améliorer ça ?
Non, tu va dans la configuration de la commande température du capteur, onglet « configuration », et tu peux rentrer une formule de calcul.
Note : ça se met à jour avec une remontée de l’info
Bonjour,
Concernant la température, il faudrait que je mette un offset négatif de 8°, ça parait beaucoup non ?
Pour la duration, est-il possible dans le même code de mettre à jour plusieurs détecteurs ?
Oui ou je copie le code en dessous et je remplace l’ID… lol.
Bonsoir, je suie avec intérêt votre conversation, j’aimerai avoir plus de renseignement sur ce fichier json est t’il dans la box Jeedom ? dans la clé ConBee ? ou dans le capteur Aqara ? qui décide lors de l’appairage des valeurs qui y sont inscrites ? peut-on les modifies et les réinjecter.
Depuis quelques jours je cherche à comprendre son fonctionnement.
Sur 3 interrupteurs doubles Aqara lumi.sensor_86sw2 je me retrouve avec 3 fichiers json différant ?
est-ce normal ? si joint une capture d’écran,
Merci pour la personne qui pourrai éclairer ma lanterne.
Bonjour,
Je pense que tu n’es pas au bon endroit car ici il s’agit de capteurs de mouvement xiaomi avec clé combee 2, pour une problématique très spécifique. Les données brutes remontent les infos que transmet l’équipement. Donc dans ton cas s’il est branché différemment ou qu’à un instant T il n’est pas dans le même état, oui forcément tes 3 fichiers seront différents.
Bonjour,
j’ai le même souci, j’avais abandonné l’idée de m’en servir pour la température, mais avec un offset pourquoi pas. Les tests présentés précédemment m’ont convaincue et au final on n’a pas besoin partout d’une précision meilleur que le degré.
En ce qui me concerne, je viens de tenter l’opération de shunt des bornes 1et 3 car comme beaucoup je rencontre des soucis très aléatoires de communication de ces capteurs de mouvement. Après plusieurs suppressions/ réinclusions laborieuses en une semaine, je sature. On va voir ce que ça donne dans le temps. J’ai fixé duration à 15 et ça semble bien se passer sur 3 d’entre eux, le 4ème a eu sa soudure. Réinclusion beaucoup plus facile et rapide. Pour l’instant il fonctionne. A suivre.
Autre point de détail, étrangement, l’inclusion est impossible chez moi depuis Jeedom et très compliquée depuis l’interface Phoscon/Deconz où il finissent par être détectés mais 1 fois sur 2 sans l’info batterie et température. Si je lance la détection en même temps sur l’interface Phoscon/Deconz ET sur l’ancienne interface Deconz, alors j’ai toutes les informations et la température paraît plus proche de la vérité.
Mais j’ai pas compris, c’est que le rapport avec les problemes de communications et la soudure ou de réduire la « duration » ? Même avec une "duration de 15mn, ça ne changera rien ?
Pourquoi faire une suppression ? et encore pire pourquoi une re inclusion juste après (preuve que la suppression ne servait a rien) ? Moi je vide pas mes canettes de bières pour les re-remplir avec la même bière.
Le mode d’inclusion, n’a aucun impact sur la température affichée, et il n’y a qu’un seul mode possible, ou que tu le fasses, ce sera le même.
Pour une meilleure inclusion il suffit de l’empêcher de passer en veille, juste après la procédure, en pressant sur le bouton toute les secondes.
