Mesures luminosité erronées sur capteurs Aqara

[díadeluz]

Bonjour,

Depuis quelque temps mes 13 détecteurs de mouvement / capteurs de luminosité Aqara renvoient systématiquement des valeurs de luminosité qu’eedomus affiche comme « 1 lux ».

Je soupçonne qu’un bug a été introduit récemment dans l’eedomus dans la conversion valeur brute -> valeur affichée.

Pour info, des utilisateurs HA ont, en mai 2020, fait état d’affichages des valeurs capteurs Aqara compris entre zéro et un et qu’il convenait de calibrer pour obtenir des lux (cf. https://community.openhab.org/t/correctly-calculate-lux-values-at-xiaomi-aqara-motion-sensors-illuminance-channel/98603)

Rencontrez-vous ce problème ?

Bonne journée.

[Tonio]

Pareil pour moi: 1 lux fixe (ou 0 lux).

[díadeluz]

Merci, Tonio.
Tickets #871166 et #2159 transmis à l’équipe de développement.

Nouveau ticket ce jour : #949668

Bonjour,
Ce ticket fait suite aux tickets #2159 et #871166 auxquels je n’ai pas de retour.
Avez-vous pris en compte ma demande relative au changement intervenu il y a une ou deux semaines sur les luminosités mesurées par capteurs Aqara que l’eedomus affiche maintenant systématiquement comme « 1 lux » ?
Merci de me tenir au courant.

[díadeluz]

Réponse du support le 17/03 (quand même !) :

Le calcul de la luminosité en LUX a été revu pour coller à la norme Zigbee, le précédent calcul étant incorrect.
Manifestement Xiaomi n'implémente pas correctement cette mesure, nous vous laissons faire un essai en multipliant par 1000 et en soustrayant 1000 à la valeur mesurée.

Le souci c’est que la correction linéaire ax+b se fait (dans les paramètres avancés) à partir de la valeur *calculée* par eedomus (1 sur tous mes capteurs) et non sur la valeur remontée par le capteur.

Résultat, avec la correction recommandée, tous mes affichages de luminosité sont à 1*1000-1000 = 0

Bref, ce n’est pas gagné !

[díadeluz]

Réponse du support ce jour (22/03) :

nous avons appliqué une modification afin que l'arrondi se fasse après la correction et non avant, ce qui devrait permettre d'avoir des valeurs plus cohérentes pour ce périphérique (qui hélas, comme avec d'autres périphérique Chinois, prend quelques libertés avec la norme Zigbee)

Je ne sais pas trop de quel « arrondi » ils parlent mais bon, on semble enfin avancer vers quelque chose d’utilisable, même si ce ne sont pas des lux


Bonne journée.

[klaushomelive]

Quel jeu de mot !
Pour les arrondis je pourrais imaginer ceci:
3,4arrondi=3 + 3,4arrondi=3 + 3,4arrondi=3 + 3,4arrondi=3 = 12 [arrondi avant]
3,4 + 3,4 + 3,4 + 3,4 = 13,6arrondi=14 [arrondi après]

[díadeluz]

Suite de l’histoire :

Ticket #149401
Les valeurs renvoyées sont toujours inutilisables (valeurs de lux négatives élevées et positives faibles) malgré la correction que vous m’avez conseillée et l’arrondi que vous y avez ajouté.
Je vous joins un PDF exposant le problème et sa solution selon la communauté HAB.

Et le pdf :

Soit un capteur de luminance suivant la norme Zigbee.
Si R est la valeur renvoyée par le capteur et M est la valeur en Lux de la mesure correspondante, alors R = 10000 * log10 (M+1) où :
M vaut 0x0000 lorsque la luminance est trop faible pour être mesurée, M varie entre 0x0001 et 0xfffe codant pour 1 Lux à 3.576 MLux et M vaut 0xffff lorsque la mesure est invalide.

Afin d’afficher une mesure M, il est donc nécessaire qu’un système recevant la valeur correspondante R applique la transformation suivante : M = 10^(R/10000 – 1)
C’est probablement ce que vous aviez codé dans l’eedomus pour coller à la norme Zigbee.

MAIS dans le cas des capteurs de luminance Aqara qui ne suivent que de façon approximative la norme Zigbee, le capteur envoie directement au système la mesure en lux et il ne faut pas la transformer pour afficher la mesure : MAquara = RAquara

C’est donc directement la valeur renvoyée par le capteur qu’il faut que l’eedomus affiche.
Source : https://github.com/openhab/org.openhab.binding.zigbee/issues/573

À suivre !

[díadeluz]

Message de l’équipe de dev ce jour :

Nous avons implémenté un patch qui garde la valeur "telle quelle" pour ce périphérique.

Le résultat m’a l’air OK. A confirmer sur la gamme des lux possibles.

Bonne journée.

[Ne6O]

Bonjour

De mon côté malgré le patch j'ai toujours la valeur 1 ou 0. D'ailleurs j'ai aussi le même probleme avec les peripheriques de suivi de consommation qui renvoit 1...Xiaomi n'a pas dû changer quoique ce soit à ces périphériques...
De ton côté tout est ok ?

Merci

[díadeluz]

Salut Ne6O,

Oui de mon côté tout est OK côté luminosité Aqara avec le patch renvoyant directement la valeur du capteur. Je n’ai pas de compteurs de consommation.

Apparemment XiaoMi n’avait rien changé à ses capteurs, c’était bien l’équipe de dev eedomus qui avait changé de façon erronée la méthode de calcul des valeurs à afficher. Apparemment ils ne savaient pas que ces capteurs renvoyaient directement des lux.

Peut-être te faut-il rebooter ta box pour qu’elle prenne en compte le patch ?

Si ça ne fonctionne toujours pas, je te suggère de contacter l’équipe de dev en faisant référence au ticket #149401 et leur dire que chez toi le patch ne fonctionne pas et en mentionnant le cas des compteurs de consommation.

Bonne journée.

[Ne6O]

Super merci de ton retour. Je vais tenter un reboot mais ma box dit que je suis à jour. Dans le même temps j'ai créé un ticket a l'équipe en liaison avec ton ticket. Pour la conso je pense que c'est le même problème.

[díadeluz]

OK Ne6O, tiens nous au courant stp.

[sssseeeebbbb]

Bonjour.
nouveau sur la communauté.
j'ai le même problème avec mes capteur Aqara, les lux sont bloqués sur 1. comment vérifier le fameux patch? et que faire d'autre sinon?
merci pour votre aide

[díadeluz]

que faire d'autre sinon?

Bonjour,

Le mieux est encore d'envoyer une demande au support. Tu peux faire référence au ticket #149401 que l'équipe de dev avait traité par patch (dont j'ignore le processus de diffusion à tous les utilisateurs).

Bonne journée.