jMQTT et commande message

[m.georgein]

Bonjour

J’utilise actuellement jMQTT avec IotLink et des commandes de type :

Je cherche à rendre ‹ paramétrable › ces commandes en les passant en type ‹ message › pour leur envoyer la « valeur » en paramètre.

Pour l’instant je passe par une commande info virtuelle, mais c’est lourd et pas très élégant

Quelqu’un à une idée ? solution ?

[Bad]

Si tu veux utiliser le type « message », tu peux simplement le selectionner dans le champ déroulant :

Et après utiliser #title# et #message# dans le corps du payload, comme d’habitude.

C’est ce que tu souhaites faire ?

Bad

[m.georgein]

Oui, c’est ce que je voudrais faire, mais en mettant #message# ou #title# (entouré ou non de {} ou de ‹  ›) cela ne fonctionne pas chez moi.

Je dois merder qq part dans la syntaxe, peux tu me donner le contenu exact du champ de la colonne valeur (à tourner trop longtemps autour d’un truc on devient aveugle )

Autre précision, la chaine que je cherche à envoyer et du type

'["^{ESC}","CHROME.EXE","{ENTER}"]'

ca coince peut être au niveau json ?

[Bad]

Probablement un problème de json oui.

Passe tout jmqtt en debut ou regarde ce que tu reçois effectivement sur le topic quand tu fais l’envoi.

[m.georgein]

C’est assez incompréhensible, je te joins trois exemple :

• Le premier fonctionne nickel
• Le deuxième qui référence une commande virtuelle initialisé avec le même contenu fonctionne aussi très bien
• Le troisième est KO, rien n’arrive dans MQTT explorer en envoyant le même contenu, par contre si j’envoie une valeur numérique elle arrive bien dans MQTT explorer.

Je pense donc que l problème est dans l’interprétation du json via la commande ‹ message ›

Petite précision : le remplacement auto des quotes des paramètres Jeedom est sur ‹ non ›

Une idée de contournement ???

[Bison]

Salut, tu es sûr quelle version de Jeedom ?

Bad demandait à ce que tu passes le plugin en debug pour voir dans les logs ce qu’il envoie puis dans mqtt explorer ce qui est reçu.

[m.georgein]

Problème résolu pour moi, en fait la transpo json ne supporte pas les crochets (exemple […] )

Jeedom les remplace systématiquement par [ #eqLogic# ] (visible dans MQTT explorer

Donc il faut les prescrire des commandes message

Le contournement est de les mettre dans la colonne valeur de jMQTT :

[ #message# ]

Je pense malheureusement que nous n’avons pas fini de nous heurter à cette couche de transpo de json par Jeedom

[Bad]

Hello @m.georgein,

Peux-tu stp me montrer ce que tu fais exactement coté jMQTT et ce que tu obtiens comme message sur le Broker ?
C’est vraiment important que j’ai plus de détails, car il y a un vrai changement de fonctionnement dans le Core en v4.2 depuis ces 2 commits c6887fd & 430f004

Maintenant jeedom::evaluateExpression() est en mesure de retourner une valeur de type Array (notamment dans le cas du passage d’un tableau json en $_input).

Avant les commits :

public static function evaluateExpression($_input, $_scenario = null) {
	try {
		$_input = scenarioExpression::setTags($_input, $_scenario, true);
		$result = evaluate($_input);
		if (is_bool($result) || is_numeric($result)) {
			return $result;
		}
		return $_input;
	} catch (Exception $exc) {
		return $_input;
	}
}

Après les commits :

public static function evaluateExpression($_input, $_scenario = null) {
	try {
		return evaluate(scenarioExpression::setTags($_input, $_scenario, true));
	} catch (Exception $exc) {
		return $_input;
	}
}

C’est profitable pour jMQTT avec l’exemple de configuration suivant :

#513# → cmd info qui récup le champ « state » du tableau json dans le topic « dummy/set »
#514# → cmd action on doit envoyer au topic « dummy/set » exactement le texte {"state":"ON"}
#515# → cmd action off doit envoyer au topic « dummy/set » exactement le texte {"state":"OFF"}
#516# → cmd action toggle doit envoyer au topic « dummy/set » le texte {"state":0} ou {"state":1}

Avant la v4.2.2 :

• les commandes #514# et #515# envoyaient bien ce qu’elles devaient → OK
• la commande #516# envoyait {"state":1-0} ou {"state":1-1} → NOK, impossible à gérer

Après la v4.2.2 (en l’état) :

• les commandes #514# et #515# envoient {'state':'ON'} ou {'state':'OFF'} → NOK
• la commande #516# envoie {'state':0} ou {'state':1} → NOK, mais gérable

Suite au patch en préparation pour remettre un coup de json_encode les array en v4.2.2 :

• les commandes #514# et #515# envoient bien ce qu’elles devaient → OK
• la commande #516# envoie bien {"state":0} ou {"state":1} → OK

Donc c’est un changement positif, mais il peut poser problème si l’appelant n’a pas prévu les cas où autre chose que bool/int/string lui serait renvoyé.
Selon moi, la sérialisation devrait être réalisée dans le core pour encadrer les types retournés.

Bad

[m.georgein]

OK,

Pour résumer,

Avec le message (à remarquer les crochets [ ] )

["^{ESC}","CHROME.EXE","{ENTER}"]

En envoyant

#message#

MqttExplorer me renvoie

[ #eqLogic# ]

---

---

---

Avec le message ( SANS les crochets [ ] )

"^{ESC}","CHROME.EXE","{ENTER}"

En envoyant ( En ajoutant les crochets [ ] )

[ #message# ]

MqttExplorer me renvoie

["^{ESC}","CHROME.EXE","{ENTER}"]

Si tu as besoin d’autres précisions ou tests n’hésite pas

[Bad]

Ok, noté, merci pour el retour !