Plugin jMQTT

[domotruc]

Bonjour Loic,
Regardes la doc, tout ceci est détaillé, accessible via le point d'interrogation en haut à droite lorsque tu es sous le plugin, ou via le lien donné sur le message en tête de ce fil.
Il n'y a pas besoin de créer un virtuel pour faire des essais, rends la commande visible, ainsi que l'équipement, et tu auras tout ce qu'il faut sur le dashboard.

[Loic74]

Yes sorry, j’ai publié ma question un peu vite, je suis justement en train de lire la doc...

Par contre ma question du virtuel reste valide.
Example: je crée un bouton virtuel qui quand cliqué publie sur le broker le json suivant: {“PompePiscine:on”}.
Donc quand je viens chercher depuis mon virtuel la commande “PiscineOn”, je ne comprends pas les champs Titre et Message. Ce n’est pas critique car ça fonctionne, c’est juste une question.

[edit] réponse simple à question bête: si le sous-type de la commande est de type MESSAGE alors effectivement il faudra renseigner un TITRE et un MESSAGE, sinon non.

[Loic74]

Juste une autre question:

dans la doc tu donnes un exemple de création de commande de type action qui prend en paramètre le tag #[home][boiler][hw_setpoint]#

Peux-tu me confirmer qu’un changement de valeur du tag #[home][boiler][hw_setpoint]# ne lance pas la commande et que la seule manière de lancer cette comnande est de l’appeler explicitement?
(Pas sur que je sois clair...)

[domotruc]

Juste une autre question:

dans la doc tu donnes un exemple de création de commande de type action qui prend en paramètre le tag #[home][boiler][hw_setpoint]#

Peux-tu me confirmer qu’un changement de valeur du tag #[home][boiler][hw_setpoint]# ne lance pas la commande et que la seule manière de lancer cette comnande est de l’appeler explicitement?
(Pas sur que je sois clair...)

Oui, je confirme, c'est le fonctionnement du core de Jeedom, commun à toutes les commandes.

[Loic74]

Ok merci Domotruc

[KipK]

Bonjour,



Petite question, est il possible d'avoir une commande mqtt avec un paramètre variable qui serait envoyé depuis un virtual ?
J'explique, j'ai des boutons en mode toggle. Je voudrais éviter de dupliquer chaque commande mqtt en mode ON et OFF.
Du coup dans mon virtual je teste l'état du switch, et j'envoie ou pas 0 ou 1 en appellant la commande "switch" de mon module jMQTT kivabien.
Sauf que je n'arrive pas à récupérer la valeur depuis le module et la renvoyer à Mosquito.

Sinon serait-il possible d'avoir comme c'est le cas pour le plugin virtual, la possibilité d'interpreter la commande "not(#[module][etat]#)" pour avoir l'inverse de la position courante. Ce qui permet directement depuis le module jmqtt de pouvoir envoyer l'inverse de l'état actuel du bouton.
J'avais fait cette modif en dur ds le plugin MQTT, mais si ca pouvait être en natif dans jMQTT ca m'arrange

Et u grand merci pour ce plugin.

[Loic74]

Salut, je tente une réponse:
Il me semble que la doc du plugin montre comment créer une commande qui prend un tag #[home][boiler][hw_setpoint]# en payload.
Ça répond à ton besoin?

[KipK]

pas vraiment. Il faudrait en fait que le plugin interprète le tag "not()" des expressions jeedom ( ie not(#[home][boiler][etat]#) ) pour résoudre mon soucis.

Sur le plugin MQTT, dans le MQTT/core/class/MQTT.Class.php j'avais ajouté ça à la fonction execute() pour palier au soucis, mais c'est pas très propre dans la méthode

Code : Tout sélectionner

//check if result needs to be inverted
	  $invert = false;
	  if (0 === strpos($request, 'not(#')) {
		  
		  $invert = true;
		  $request = str_replace('not(#', '#', $request);
		  $request = str_replace('#)', '#', $request);
	  }

	  $request = jeedom::evaluateExpression($request);
      if ($invert == true) {
		  //invert boolean result
		  $request ^= 1;

Je n'ai pas trouvé pourquoi c'est interprété dans le plugin virtual et pas dans MQTT et jMQTT, ni trouvé où ca se passe dans le code du Core de Jeedom

[domotruc]

Bonsoir KipK,
Es-tu si sûr que celà que ca marche pour un virtuel?...
Je viens de faire l'essai suivant.

Création du virtuel Test:

virtuel.png (56.7 Kio) Consulté 1684 fois

Création de la commande suivante dans un équipement jMQTT:

jmqtt.png (15.31 Kio) Consulté 1684 fois

Clic sur la commande off du virtuel
Vérification de la valeur status: 0 => OK
Vérification de la valeur notStatus: 1 => OK
Clic sur le Tester associée à la commande jMQTT
Un client écoutant tous les messages sur le broker voit la commande:

Code : Tout sélectionner

2018-05-31 21:37:57.521 /test/cmd 1

=> OK

Clic sur la commande on du virtuel
Vérification de la valeur status: 1 => OK
Vérification de la valeur notStatus: vide => NOK
Clic sur le Tester associée à la commande jMQTT
Un client écoutant tous les messages sur le broker voit la commande:

Code : Tout sélectionner

2018-05-31 21:37:57.521 /test/cmd (null)

=> NOK : le null signifie qu'il n'y a pas de payload => même résultat que le virtuel.

J'ai l'impression qu'il y a un souci dans la routine evaluate du core... je vais creuser.

[KipK]

Bizarre ça, tu ne t'es pas trompé dans la commande jMQTT?

Sur ton visuel tu appelles not(#[test][inter][status]#) au lieu de #[test][inter][notStatus]# c'est voulu ?

Sinon si tu mets le champs info status en binary au lieu de default ?


Ca n'explique pas ça qd même:
>Vérification de la valeur notStatus: vide => NOK

[domotruc]

Bizarre ça, tu ne t'es pas trompé dans la commande jMQTT?

Sur ton visuel tu appelles not(#[test][inter][status]#) au lieu de #[test][inter][notStatus]#

Ben, j'ai compris que tu souhaites avoir le not côté jMQTT. Ou alors je n'ai pas compris ce que tu veux faire.

[KipK]

oups j'étais en train d'éditer mon message précédent.

Sisi c'est bien ça, mais je pensais que tu testais le 'not' coté virtual uniquement .

Je vais regarder ça de plus prêt aussi. Comme j'utilise ma rustine, je suis peut être passé à coté d'un bug sur le core.

[domotruc]

Le problème vient de la fonction evaluate dans core/php/utils.inc.php. En ajoutant les traces suivantes:

Code : Tout sélectionner

        try {
                log::add('expression', 'info', 'expr=' . $expr);
                $ret = $GLOBALS['ExpressionLanguage']->evaluate($expr);
                log::add('expression', 'info', 'ret=' . $ret );
		return $GLOBALS['ExpressionLanguage']->evaluate($expr);
	} catch (Exception $e) {
		  log::add('expression', 'info', '[Parser 1] Expression : ' . $_string . ' tranformé en ' . $expr . ' => ' . $e->getMessage());
	}

je constate que la fonction $GLOBALS['ExpressionLanguage']->evaluate retourne bien 1 sur not(0) mais retourne chaîne vide sur not(1).
Cette fonction provient du composant ExpressionLanguage de l'environnement Symfony.
Il est donc buggé !

Le contournement est de faire le not autrement. J'ai essayé ! : idem. Par contre l'expression #[Test][Inter][status]# == 1 ? 0 : 1 marche bien : le broker mosquitto voit bien les bonnes valeurs 0 ou 1.

[KipK]

Bien vu Domotruc.

Bizarrement, je viens de reproduire ton test, et notStatus se met bien à jours dans les 2 cas dans mon virtual.
Par contre dans jMQTT la commande avec not(#[...][status]#) envoie bien 1 en payload si status = 0, mais comme toi est vide si status = 1

Je suis sous PHP7 ( 7.0.30-1~dotdeb+8.1 ) , dernière version stable de jeedom.

et merci pour le tip du "

Code : Tout sélectionner

== 1 ? 0 : 1

" je n'y avais même pas pensé. Je vais pouvoir migrer tout mon bousin sur ton plugin maintenant.

[Loic74]

Salut,

Je cherche un moyen de détecter quand le broker Mosquitto est planté et/ou arrêté.
J'ai remarqué dans les logs de jMQTT que celui-ci ping le broker toutes les minutes. J'imagine que c'est pour le keep-alive du client jMQTT?

Comme je le comprends, si le client jMQTT arrête de pinger le broker, ce dernier va publier le LWT "offline" sur le topic jeedom/status, c'est bien cela? Le topic jeedom/status est bien pratique et je m'en sert depuis NodeRed pour détecter si Jeedom est en rade et me prévenir par Télégram le cas échéant.

Par contre est-il possible de remonter dans le plugin jMQTT une commande info par exemple sur le status du broker ("ok" s'il répond aux pings, sinon "NOK")?

Merci

Loic

[domotruc]

Je cherche un moyen de détecter quand le broker Mosquitto est planté et/ou arrêté.
J'ai remarqué dans les logs de jMQTT que celui-ci ping le broker toutes les minutes. J'imagine que c'est pour le keep-alive du client jMQTT?

Exact

Comme je le comprends, si le client jMQTT arrête de pinger le broker, ce dernier va publier le LWT "offline" sur le topic jeedom/status, c'est bien cela? Le topic jeedom/status est bien pratique et je m'en sert depuis NodeRed pour détecter si Jeedom est en rade et me prévenir par Télégram le cas échéant.

Oui c'est ça.

Par contre est-il possible de remonter dans le plugin jMQTT une commande info par exemple sur le status du broker ("ok" s'il répond aux pings, sinon "NOK")?

Pas à ma connaissance directement.
Toutefois, si le broker tombe, le démon JMQTT va tomber également et logguer une erreur dans le log jMQTT. Tu peux faire remonter les erreurs dans le panneau des messages en activant l'option dans le panneau Logs du menu Configuration. Et également être notifié, via Telegram dans l’exemple ci-dessous:

message.png (19.29 Kio) Consulté 1630 fois

Si tu as un équipement qui publie des messages à fréquence régulière, tu peux aussi faire un scénario qui vérifie la date de la dernière acquisition. Je peux t'envoyer un exemple si tu le souhaites.

Enfin, je pourrais ajouter une commande broker dans l'équipement jeedom qui remonte le status du broker (online / offline) en gérant les exceptions renvoyées par la librairie Mosquitto lorsque la connexion tombe ou ne peut être établie. Je crée une fiche d'évolution sur GitHub pour en garder trace.

[Loic74]

Salut et merci pour le retour.

Si tu as un équipement qui publie des messages à fréquence régulière, tu peux aussi faire un scénario qui vérifie la date de la dernière acquisition. Je peux t'envoyer un exemple si tu le souhaites

Je veux bien ton exemple car je dois également mettre cela en place, cela me fera gagner du temps.

Pour expliquer ce que je veux faire:

j'ai des capteurs radio qui contrôlent le niveau de rivières et qui m'avertissent en cas de crue.
La "chaîne de mesure" est la suivante: capteur radio -> TTN -> NodeRed -> Broker Mosquitto - > Jeedom
Le problème est que si un des éléments de la chaîne de mesure tombe en rade, je ne suis plus prévenu en cas de crues et je ne sais même pas que cela ne fonctionne plus sauf à vérifier de manière manuelle si tout tourne rond.
Donc je cherche à mettre en place un système d'alerte automatique via Telegram en cas de panne pour chaque élément de la chaîne de mesure. Pour l'instant voila ce que je prévois:

- capteur radio et TTN: si tombent en panne, je suis prévenu soit via le LWT du capteur (si pris en charge par le capteur) soit via Jeedom qui ne reçoit plus de mesures régulières (ton exemple que tu peux me fournir)

- Broker Mosquitto: si tombe en panne, la commande info que tu prévois d'intégrer dans le plugin me donnerait cette info de manière simple

- Jeedom: si tombe en panne, le topic jeedom/status accessible depuis NodeRed me permet d'avoir l'info et de m'envoyer un message Telegram depuis NodeRed

Merci bien pour le support et le très bon plugin

Loic

[Loic74]

Et l'API MQTT m’intéresse également donc je veux bien tester si besoin de testeurs

[domotruc]

Salut et merci pour le retour.

Si tu as un équipement qui publie des messages à fréquence régulière, tu peux aussi faire un scénario qui vérifie la date de la dernière acquisition. Je peux t'envoyer un exemple si tu le souhaites

Je veux bien ton exemple car je dois également mettre cela en place, cela me fera gagner du temps.

Voici:

scenario.png (110.77 Kio) Consulté 1616 fois

Quelques explications:
* Ma chaudière envoie la donnée heures_bruleur toutes les 90s. Je teste que la dernière acquisition n'est pas plus vieille que 120s.
* Le scénario s'appelle Monitoring chaudière, il est exécuté toutes les 10min.
* Pour limiter le nombre de message quand la communication est perdue, je désactive le scénario et le réactive 60min après.

[Loic74]

Super merci bien.
Remarques/questions:

1/ ce scénario n'est-il pas affecté par les récents changements de comportement de la fonction A dans la dernière version de Jeedom (viewtopic.php?f=32&t=36864&hilit=comportement)?

2/ pour la répétition des messages, pourquoi ne pas simplement désactiver la répétition du scénario?

3/ Au sujet du topic jeedom/status et son utilisation depuis NodeRed pour vérifier que Jeedom est ok, j'ai l'impression que tant que Jeedom est en rade (eg. si je redémarre jeedom), le broker publie toutes les minutes le LWT "offline" et donc Telegram m'envoie un message toutes les minutes pendant tout le temps du redémarrage. Je ne comprends pas pourquoi.