jMQTT et gestion du payload

Plugins Protocole domotique
1

Bonjour à tous.

Je me suis lancé dans l’idée de domotiser la machine à laver et le séche-linge à l’aide des capteurs de vibration Aquara… L’idée c’est de ce dire que si au moins 1 vibration pendant x minutes => c’est le début du cycle (ou la continuité) et qui si ensuite plus de rien pendant Y minutes, c’est que le cycle est terminé.

J’ai donc installé une clé cc2531, zigbee2mqtt, jMQTT… ça communique et j’ai bien les payload, ainsi que les infos qui se mettent à jour :

[2020-04-14 12:33:58][INFO] : -> zigbee2mqtt|MachineALaver {"battery":100,"voltage":3005,"linkquality":28,"sensitivity":"high","strength":26,"action":"vibration"}

[2020-04-14 13:13:26][INFO] : -> zigbee2mqtt|SecheLinge {"battery":100,"voltage":3015,"linkquality":63,"sensitivity":"high","strength":12,"action":"vibration"}

Donc pour la détection de début de cycle, ça s’annonce bien, même si j’ai l’impression que ça ne remonte pas très souvent, y compris avec la répétition forcée des valeurs.

Par contre, là où c’est moins simple c’est quand le cycle est terminé : le payload est plus « court » et l’info « action » qui indique quel événement est détecté, n’existe pas … Ce qui fait que l’info dans le virtuel n’est pas mis à jour

[2020-04-14 12:33:58][INFO] : -> MachineALaverMQTT|MachineALaver {"battery":100,"voltage":3005,"linkquality":73,"sensitivity":"high","strength":26}
[2020-04-14 12:33:58][INFO] : valeur de la commande MachineALaverMQTT|Action non trouvée
[2020-04-14 12:33:58][INFO] : -> MachineALaverMQTT|Battery 100
[2020-04-14 12:33:58][INFO] : -> MachineALaverMQTT|LinkQuality 73
[2020-04-14 12:33:58][INFO] : -> MachineALaverMQTT|Voltage 3005


[2020-04-14 12:58:49][INFO] : -> SecheLingeMQTT|MachineALaver {"battery":100,"voltage":3015,"linkquality":70,"sensitivity":"high","strength":12}
[2020-04-14 12:58:49][INFO] : valeur de la commande SecheLingeMQTT|Action non trouvée
[2020-04-14 12:58:49][INFO] : -> SecheLingeMQTT|Battery 100
[2020-04-14 12:58:49][INFO] : -> SecheLingeMQTT|LinkQuality 70
[2020-04-14 12:58:49][INFO] : -> SecheLingeMQTT|Voltage 3015

Et donc ça conserve l’ancienne valeur dans l’info du virtuel associé et donc je ne sais pas détecter facilement que c’est fini ! Sauf à faire en plus une vérification de la dernière date de collecte de l’info

Certains d’entre vous ont-il rencontré ce genre de problématique ?
C’est une « volonté » du plugin jMQTT de ne pas mettre à jour ou c’est un principe du protocole ?
Pour info => should never occur

        catch (Exception $e) {
            // Should never occur
            $this->getEqLogic()->log('info', 'valeur de la commande ' . $this->getLogName() . ' non trouvée');
        }

C’est pareil avec Abeille ou MQTT (tout court) ?
Si c’est normal, comment vous avez contourné le problème ?

A vous lire

2

Bonjour,
A première vue c’est l’info ‹ action › qui est absente du payload, quand il n’y a pas de détection de vibration.
alors oui c’est moins simple mais :
-Si vous passer par le retour d’état de l’info ‹ action ›, ça changera de valeur quand il n’y auras plus de action = « vibration ».
-Ou sinon plutôt voir avec la valeur de ‹ strength › qui à l’air de varier avec la ‹ force › de la vibration.
Désolé je n’ai pas encore ce type de capteur pour aller plus loin.

Ce ne sont que 2 pistes, mais si ça peut vous aider…
J’ai aussi trouvé ça :
https://www.ca-sert-a-quoi.com/articles/domotique/test-et-cas-dutilisation-du-capteur-de-vibration-xiaomi-aqara/#jp-carousel-6535.

Bonne journée

3

Merci PanoLyon pour ces pistes :

  • Le retour d’état ne semble pas vraiment fonctionner, comme de toute manière la commande « action » n’est pas mise à jour du tout… ça ne déclenche pas d’événement dans jeedom.

  • J’ai pas l’impression que la valeur strech soit en lien avec la force du « mouvement » … J’ai pas noté de lien systématique, entre un petit et un grand mouvement du capteur, la valeur est globalement stable. Je pense que c’est plus en lien avec la puissance du signal zigbee

Finalement, il y a une solution « simple », simplement faire une regex sur le contenu du payload complet directement dans l’équipement global, j’ai pas besoin d’une valeur numérique

urlencode(#[Le salon][zigbee2mqtt][MachineALaver]#) matches "/.*vibration.*/i"

urlencode, c’est uniquement pour éviter de se prendre la tête avec le format du json…

Au premier message avec vibration ça passe bien à 1 …; Dès réception d’un payload réduit, ça repasse à 0.
J’ai plus qu’ à déterminer les fréquences de réveil des capteurs dans le genre :

  • Valeur 1 pendant 2 périodes => cycle en cours
  • Valeur 1 pendant 1 période => faux positif, genre on ouvre la porte, on vire le linge et on s’en va.
  • Valeur 0 pendant 1 ou 2 périodes => fin du cycle

ça suppose aussi que ce soit pas un capteur qui remonte une info toutes les 3 heures en phase de non activité…

4

Bonjour @naboleo
Merci pour l’information.

Le retour d’état ne semble pas vraiment fonctionner, comme de toute manière la commande « action » n’est pas mise à jour du tout… ça ne déclenche pas d’événement dans Jeedom.

C’est vraiment étrange car avec le contact de porte le payload JSON remonte régulièrement et complet.
J’ai tout comme vous clé cc2531, zigbee2mqtt, jMQTT jeedom v4.
Son fonctionnement doit pas être le même …
:thinking:

bonne journée

5

Bonjour @PanoLyon

Sur le capteur Aquara, le payload prends différents formats :
Une partie fixe, en sortie de veille (entre 50 et 70 min… genre un tirage aléatoire 1h =/- 10 min) ou avec un événement

'{"battery":100,"voltage":3005,"linkquality":125,"strength":6}'

Lors d’événements (avec en plus des info batterie/voltage, link etc), on trouve

'{XXXXXXXXXXX, "action":"vibration"}'
'{XXXXXXXXXXX, "action":"tilt","angle":13}'
'{XXXXXXXXXXX, "angle_x":-2,"angle_y":-5,"angle_z":84,"angle_x_absolute":92,"angle_y_absolute":95}'

J’ai même aperçu un « fall » que je n’arrive pas facilement à reproduire

'{XXXXXXXXXXX, "action":"fall"}'

Bref, ça à l’air d’être son fonctionnement normal. Je ne trouve pas d’erreur dans les log du broker non plus… Un ancien sujet va également dans ce sens
https://forum.jeedom.com/viewtopic.php?t=44585&start=80

Toujours est-il que je devrai pouvoir m’en sortir…
mqtt

6

Merci pour toutes ces infos.
En effet mon contact de porte est plutôt calme quand il n’a ‹ rien a dire › mais il est vrai qu’il est moins ‹ riche › en information, le payload est fixe :
{« battery »:86,« voltage »:2975,« contact »:false,« linkquality »:0}
Pour le rafraichissement je mesure une période fixe de 50 minutes, hors événement.

Dans tout les cas je vois avec plaisir que votre information est fiable …

7

Au passage je viens de voir que la dernière modification du code porte justement sur cette non mise à jour de la valeur

8

Kool ça devrait vite s’arranger alors :crossed_fingers: