A oui après c’est peut pas linéaire le calcul des piles (ce qui paraît pas déconnant non plus)
Merci pour ce retour plus constructif que la précédente réponse.
Au passage je n’ai jamais dit que >80% était poubelle mais que « j’ai cru voir… »
Je ne vois pas la valeur >100% erronée mais plutôt calculée différemment de celle par la gateway du coup ce qui me dérange un peu c’est le fait que le même capteur « renvoi » (les méthodes de calcul sont différentes plutôt) des valeurs en % différentes.
Je cherche juste à harmoniser tous les renvois de batterie en fonction des différents plugin 
mais ça à l’air plus compliqué que je ne le pensais et très certainement bien au delà de mes compétence de débutant 
Oui je sais que tu ne l’a pas dit, mais tu n’a pas rêvé, je l’ai lu aussi, et ce genre d’affirmations non factuelles erronée faite avec tan d’aplomb me fatigue, car elles induisent en erreur les débutants bêtement …
Et comme j’ai une preuve que c’est faux j’en profite 
Apres honnêtement il n’est pas « anormal » qu’il y ai des différence entre produit Xiaomi, car il faut savoir ils ne fabrique rien ou presque rien. C’est une marque « rebranding » qui font appel a des usine tierces pour la construction de leur matériels. Par exemple les capteur de température Aqara et Mijia, sont en faite 2 usines distinct.
C’est pourquoi si Aqara fournit un % de batterie et une tension, mais que Xiaomi n’utilise que la tension et fait son propre calcul, le résultat va forcement différer.
En explorant le Json brut on regarder les ids de la commande :
Et ensuite, j’ai tenter de bidouiller le fichier .Json (Zigbee/Core/Config/Device) de mon capteur de température avec :
,
{
"name": "Batterie",
"type": "info",
"subtype": "numeric",
"isVisible": 1,
"isHistorized": 0,
"logicalId": "1::1::32",
"unite" : "%",
"generic_type": "BATTERY",
"configuration" : {
"calculValueOffset":"(((#value# *10 ) - 280) /20 ) * 100"
}
}
Mais bon ca ne crée pas de nouvelle commande en plus malgré la relance du démon.
J’ai tenté de faire un calcul en % entre 2.8V et 3V pour respectivement 0-100%
Edit : j’avais mal nommé le « name », ca semble fonctionner j’attends la 1ere remonter pour voir i cela fonctionne. si c’est le cas @Lysopaiine tu n’aura qu’a reprendre ca et remplacer 280, pas le voltage que tu souhaite pour le 0% (2.8v dans mon exemple)
Edit2: pas de remontée pour le moment
Bonjour,
Tu ne peux pas avoir les batteries dans une commandes c’est pas possible si c’est le cluster de batterie jeedom l’attrape et le traite en interne et passe a la suite.
@Lysopaiine, j’ai trouvé un truc, mais c’est vraiment de la bidouille et ca sautera a la 1ere Maj.
Tous les jour a minuit, Zigbee, va check les attributs de tous les équipement. Si il trouve l’attribut batterie en % il l’utilise, sinon il va chercher l’attribut batterie en Volts. Donc en toute logique tu peux inverser ces conditions.
Cela se passe dans /plugins/zigbee/core/class/zigbee.class.php
Ligne 201 à 212 remplacer :
if(self::getAttribute($endpoint_id,1,33,$device) != null){
$zigbee->batteryStatus(self::getAttribute($endpoint_id,1,33,$device));
}else if(self::getAttribute($endpoint_id,1,32,$device) != null && self::getAttribute($endpoint_id,1,32,$device) > 0){
$battery_voltage = self::getAttribute($endpoint_id,1,32,$device);
if(is_array($zigbee->getConfiguration('maxBatteryVoltage',0)) || $battery_voltage > $zigbee->getConfiguration('maxBatteryVoltage',0)){
$zigbee->setConfiguration('maxBatteryVoltage',$battery_voltage);
$zigbee->save();
}
if($zigbee->getConfiguration('maxBatteryVoltage',0) != 0){
$zigbee->batteryStatus($battery_voltage/$zigbee->getConfiguration('maxBatteryVoltage',0) * 100);
}
}
Par
if(self::getAttribute($endpoint_id,1,32,$device) != null && self::getAttribute($endpoint_id,1,32,$device) > 0){
$battery_voltage = self::getAttribute($endpoint_id,1,32,$device);
if(is_array($zigbee->getConfiguration('maxBatteryVoltage',0)) || $battery_voltage > $zigbee->getConfiguration('maxBatteryVoltage',0)){
$zigbee->setConfiguration('maxBatteryVoltage',$battery_voltage);
$zigbee->save();
}
if($zigbee->getConfiguration('maxBatteryVoltage',0) != 0){
$zigbee->batteryStatus($battery_voltage/$zigbee->getConfiguration('maxBatteryVoltage',0) * 100);
}
}else if(self::getAttribute($endpoint_id,1,33,$device) != null){
$zigbee->batteryStatus(self::getAttribute($endpoint_id,1,33,$device));
}
Fondamentalement rien ne change, juste Jeedom traite en 1er la tension de la pile, puis a défaut le pourcentage fournis, même si je doute que le cas existe, donc cela prendra toujours le voltage.
Le problème de cette méthode, et je pense que c’est pour cela que @loic traite les info dans l’autre sens, le % est fournis par le capteur, le voltage aussi, mais son affichage en % n’est qu’une interprétation fait en prenant en compte comme tension maximum référence (et oui toute les pile neuve n’ont pas la même tension) la tension maximum connu, c’est a dire la plus grande relevé, et donc comme il n’y en avait pas avant la manipe, ta tension max sera celle actuel, et donc par ce fait tous tes capteurs seront a 100% de batterie.
C’est bien pour cela que @loic utilise en priorité l’autre valeur, bien plus fiable, c’est aussi pour cela que tu a un bouton pour signaler a jeedom que tu a changer les piles.
Libre a toi de faire cette modif ou pas, mais moi a titre perso, je reste sur la version de @loic
sinon il y a pas moyen de faire un virtuel ou autre ? avec le getAttribute($endpoint_id,1,32,$device) ou 33, comme avec :
Je voulais me faire une page sur mon design avec les batteries, et je suis bien embêté…
Surement mais je n’ai malheureusement pas de temps pour vous faire tout un tuto la dessus.
@skillix Bonjour, je pense qu’il y a eu beaucoup de mauvaise compréhension entre nous 3 avec Loic sur mon message « …<80%… » mais bon ce n’est pas grave on ne va pas faire des paver pour des justifications à la con qui au final de font pas avancer le réel sujet 
Je te remercie d’avoir pris le temps pour moi (et d’autres certainement) d’avoir étudié la chose en profondeur.
Ce que j’en retiens d’une manière très rapide c’est que « c’est la merde » 
Au final les infos batteries qui sont remontées dans Jeedom sont toutes correctes et c’est le principal, c’est juste dommage que ces remontées soient différentes en fonction de l’éventuel constructeur, plugin etc…
c’est pour ca qu’il y a des normes, mais certain chies dessus alors c’est la merde ^^
rien que sur une norme grand publique, le wifi certain ne les respecte pas et c’est pour ca que je dois avoir 2 réseau chez moi, un normal sécurisé, et un spécial appareil chinois qui refuse ma clé wep de 62 caractère avec caractères spéciaux 
Apres c’est le prix a payer pour avoir des imports moins cher^^
Hello,
je viens pour rajouter mes logs concernant des Aqara WXKG02LM :
[2021-05-11 12:53:35][INFO] : [00:15:8d:00:01:63:97:32][listener.attribute_updated] Received an attribute update 65281=b'\x01!\xd1\x0b\x03(\x15\x04!\xa8\x13\x05!r\x00\x06$\x01\x00\x00\x00\x00
!<=' on cluster 0
[2021-05-11 12:53:35][DEBUG] : 00:15:8d:00:01:63:97:32 - Attribute report. attribute_id: [65281] value: [{'battery_voltage_mV': 3025, 'temperature': 21, 'X-attrib-4': 5032, 'X-attrib-5': 114, 'X-attrib-6': 1, 'path': 15676}]
[2021-05-11 12:53:35][INFO] : [00:15:8d:00:01:63:97:32][listener.attribute_updated] Received an attribute update 32=30.2 on cluster 1
[2021-05-11 12:53:35][DEBUG] : [0x437c:1:0x0001] Voltage mV: [Min]:2820 < [RAW]:3025 < [Max]:3100, Battery Percent: 73.0
[2021-05-11 12:53:35][INFO] : [00:15:8d:00:01:63:97:32][listener.attribute_updated] Received an attribute update 33=146 on cluster 1
[2021-05-11 13:06:03][INFO] : [00:15:8d:00:01:2a:37:0e][listener.attribute_updated] Received an attribute update 65281=b'\x01!\xbd\x0b\x03(\x1a\x04!\xa8\x13\x05!3\x00\x06$\x01\x00\x00\x00\x00
!"m' on cluster 0
[2021-05-11 13:06:03][DEBUG] : 00:15:8d:00:01:2a:37:0e - Attribute report. attribute_id: [65281] value: [{'battery_voltage_mV': 3005, 'temperature': 26, 'X-attrib-4': 5032, 'X-attrib-5': 51, 'X-attrib-6': 1, 'path': 27938}]
[2021-05-11 13:06:03][INFO] : [00:15:8d:00:01:2a:37:0e][listener.attribute_updated] Received an attribute update 32=30.1 on cluster 1
[2021-05-11 13:06:03][DEBUG] : [0x287c:1:0x0001] Voltage mV: [Min]:2820 < [RAW]:3005 < [Max]:3100, Battery Percent: 66.0
[2021-05-11 13:06:03][INFO] : [00:15:8d:00:01:2a:37:0e][listener.attribute_updated] Received an attribute update 33=132 on cluster 1
La question ne se porte pas sur le calcul du pourcentage, mais bien de la valeur qu’on update.
Dans les 2 cas, on update le double de la valeur reçue, pourquoi ?
(j’attends de voir la trame concernant ma télécommande ikea 5 boutons)
(Update __init__.py · Ultraboss77/zha-device-handlers@5a10c86 · GitHub)
Le pourcentage de la batterie n’est pas issue du lecture d’information mais calculé à partir de l’information voltage (INFO) et de valeurs mini et maxi possible (DEBUG).
Quand on regarde dans le code de fonctionnement du plugin abeille, c’est bien un calcul et pas une lecture d’information.
Je ne dis pas le contraire, mais je pointe des bouts de codes qui montrent clairement que le calcul du pourcentage est doublé volontairement. Pour quelle raison, ça ??
Dans le Plugin Zigbee, Loic récupère l’attribut de pourcentage de batterie mais qui je ne sais pas pourquoi donne des valeurs supérieur à 100. La raison ?? quel est la base des valeurs dans la norme Zigbee et comment les constructeurs des capteurs le gère ??
Certains de mes capteurs comme des HEIMAN remontent des valeurs à 200 avec pile neuve, des Xiaomi avec pile neuve entre 170 et 180, Ikea avec pile neuve entre 130 et 140.
Les autres plugins ne récupère pas l’attribut du pourcentage surement pour le faite que les valeurs sont supérieur à 100 et peut être variable suivant le fabricant du capteur et préfère faire un calcul par rapport au voltage de la pile. C’est une bonne solution aussi, mais qui rajoute un tout petit peu de charge multiplié par le nombre de capteurs et cela plusieurs fois dans la journée.
Par contre je crois que Loic préfère récupérer l’attribut en ne tenant pas compte de ce qui est supérieur à 100% et qu’une seule fois par jour pour simplifier le code et alléger la charge du système.
Je sais aussi que en passant du plugin Abeille à Zigbee, mon système avait sa charge système journalière qui avait baissée (je ne me rappel plus les proportions, mais c’était visible sur les courbes)
Bonjour,
De ce que j’ai compris si la pile doit faire 3v et que en vrai elle fait 3.3 ben c’est au dessus des 100%. Après chaque fabricant a sa propre formule de calcul mais en gros si le fabricant fournis un % alors faut le prendre.
Loïc, effectivement les valeurs brutes des attributs peuvent être supérieur à 100 car le voltage de la pile est très variable en fonction des fabricants de piles et en plus chaque fabricants de capteurs fait sa propre gestion de ce pourcentage…
Ça surprend souvent les utilisateurs du plugin quand ils regardent les valeurs remontées par le capteur et celle de la page batterie de Jeedom surtout quand il viennent de plugin qui eux font un calcul sur le voltage.
Par contre je suis tout à fait d’accord avec le principe de récupérer l’attribut de pourcentage qui est présent et de prendre en compte que jusqu’à 100 maximum pour plus de visibilité dans la page batterie de Jeedom et éviter au plugin de faire des calculs.
En plus, depuis que j’utilise le plugin Zigbee à ses débuts en bêta, j’ai pas eu de mauvaise surprise sur la gestion des piles de mes capteurs. (Sauf avec les télécommandes 5 boutons Ikea qui mangeait les piles à toute vitesse avant le correctif du poll control 
)
Les formules de calcul pour remonter un pourcentage à partir de la valeur du voltage sont décrites dans certains fichiers quirks. Mais il y a bien des valeurs min et max pour les borner.
Il n’y a pas de logique à remonter un pourcentage doublé alors que le message debug est divisé par 2.
C’est la formule de base qui est erronée.
/usr/local/lib/python3.7/dist-packages/zhaquirks/xiaomi/init.py
/usr/local/lib/python3.7/dist-packages/zhaquirks/init.py
Avec Loic on s’est déjà pris bien la tête sur le sujet ^^ et j’ai pas envie de refaire le débat il suffi de lire les ancien message, mais n’oubliez pas que dans les valeur des fabriquant, il y a aussi de pris en compte la température.
exemple, une pile neuve a 3.3v peut avoir 2.9v (ou moins) a -20 degrés.
1 « J'aime »
Bonsoir,
J’ai bien compris que le calcul est différent selon les constructeurs, mais quid de plugins ?
Même module (RTCGQ11LM) vu par Xiaomihome et Zigbee 
Bonjour
Certain module ne remonte pas un % de batterie mais juste un voltage. Le souci c’est que Jeedom ne connais pas le voltage max pour chaque module il prends donc le voltage maximum renvoyé par le module depuis sont inclusion pour le calcul. En gros si tu inclus un module avec une batterie pas a 50% jeedom considérera que c’est 100% jusqu’au changement de pile
Bonjour,
J’ai volontairement indiqué la tension nominale de la batterie, ne serait-il pas possible de pouvoir prendre en compte cette information ?