Premier test : Quel résultat obtiens-tu lorsque tu cliques sur le bouton « Tester » de la commande CRENEAU1 sur ton equipement virtuel?
Réponse A : 0
Réponse B : 0000
Est-ce votre dernier mot?
Bonjour,
Tester sur l’info CRENEAU1 me renvoit 0000.
Tu ne reproduis pas le problème chez toi ?
Si tu ne l’as pas déja fait je te suggère de tester la manip suivante toute simple :
Une info dans un Virtual de type « Autre » et valeur :
"0123"
Envoi d’une commande via jMQTT avec une payload JSON de type
{"valeur":#[virtualName][infoValue]#}
Et reception dans MQTT Explorer
De mon coté, je reçois : 123 alors que je devrais recevoir 0123
Voilà ce qui marche chez moi :
1 Virtuel nommé « testLeadingZeroVirt » avec cette commande :
1 jMQTT ayant une commande action :
et lorsque je clique sur « Tester » :
Donc si je reprend ton exemple, il faut mettre des double-quote autour de la valeur :
{"valeur":"#[virtualName][infoValue]#"}
OUI, je confirme que dans l’exemple et en mettant des double-quotes autour de la valeur, cela donne bien le résultat attendu (dans l’exemple 0000).
Par contre, en revenant dans mon cas concret, je constate les comportements suivants :
Infos Virtual
#[Energy][Linky A203 Standard Mode][CRENEAU1]# = "0000"
#[Energy][Linky A203 Standard Mode][CRENEAU1 Label]# = "Creneau Horaire #1"
Payload Cas 1
{"name":"CRENEAU1","value":"#[Energy][Linky A203 Standard Mode][CRENEAU1]#","unit":"","label":#[Energy][Linky A203 Standard Mode][CRENEAU1 Label]#}
Result
Payload Cas 2
{"name":"CRENEAU1","value":"#[Energy][Linky A203 Standard Mode][CRENEAU1]#","unit":"","label":"#[Energy][Linky A203 Standard Mode][CRENEAU1 Label]#"}
Result
Payload Cas 3
{"name":"CRENEAU1","value":"#[Energy][Linky A203 Standard Mode][CRENEAU1]#","unit":"","label":"TOTO"}
Result
En résumé :
Si le contenu d’une variable String contient un caractère comme #, ou ° par exemple, le transfert n’est pas correct.
Dans le Cas 1, malgré les double-quotes sur la valeur, elle n’est pas correctement transmise.
Dans le Cas 2, il y a apparition de caractères \ et pas de parsing JSON 
J’ignore si cela est un fonctionnement attendu.
Ton avis ?
Si j’utilise MQTT Explorer pour publier une payload, ca semble passer correctement …
C’est questionnant
J’ai mis à jour mon virtuel avec le label en plus :
-
Coté jMQTT, j’ai mis d’abord :
avec comme resultat :
Ca, c’est OK
-
second test : rajout de la commande Label contenant le #
resultat :
Ca c’est PAS OK
Maintenant, voilà ce qui se passe sous le capot :
Le code en question fait appel à une fonction du Core :
jeedom::evaluateExpression
J’ai mis du log autour pour voir (jMQTTCmd.class.php line 208) :
- Cas 1
0000|[2022-02-01 11:42:16]INFO : request before : '{"name":"CRENEAU1","value":"#1464#","test":"coucou"}'
0001|[2022-02-01 11:42:16]INFO : request after : array ( 'name' => 'CRENEAU1', 'value' => '0000', 'test' => 'coucou', )
On voit que l’on passe une chaine de texte à la fonction et elle nous retourne un array…
Au début du publish(), on regarde si le payload est un array et on l’encode en JSON :
Donc ca marche quand même
- Cas 2
0000|[2022-02-01 11:52:59]INFO : request before : '{"name":"CRENEAU1","value":"#1464#","label":"#1466#"}'
0001|[2022-02-01 11:52:59]INFO : request after : '{"name":"CRENEAU1","value":"0000","label":"\"Creneau Horaire #1\"}'
On voit que l’on passe une chaine de texte à la fonction et elle nous retourne la chaine de texte erronée
Le problème viens du Core de Jeedom.
Par le passé, nous avons déjà palié à ces comportements, mais dans le dernier cas, le JSON retourné étant incorrect, je ne vois pas de solution coté jMQTT.
Merci @Domochip pour ta réponse,
Cette analyse documentée est interressante.
Si tout cela se confirme et vu l’importance grandissante des échanges via MQTT, il me semble qu’il va être nécessaire de trouver une solution car comme c’est souvent rappelé « MQTT est agnostique quand aux données ».
Est-ce qu’il serait possible d’interroger l’équipe en charge du core Jeedom (peut être @Loic) pour voir ce qu’il serait possible de faire ?
C’est quand même super limitatif pour Jeedom de ne pas pouvoir transmettre des Strings au minimum utilsant utf-8 via MQTT.
#Contournement 
As-tu besoin du Virtuel au final?
En mettant cette valeur sur la commande jMQTT, ca passe :
{"name":"CRENEAU1","value":"substr(#[Aucun][WTeleInfo][PJOURFplus1]#,0,4)","label":"Creneau Horaire #1"}
Merci pour l’idée de contournement.
MAIS,
Je me suis lancé dans un chantier de passage de la plupart des échanges dans mon système via MQTT.
Sous la suggestion de @Loic d’ailleurs dans un post qu’il doit être facile de retrouver sur ce forum.
https://community.jeedom.com/t/plugin-mqtt-manager/71546
Je pense que c’est effectivement une excellente idée mais je ne me vois pas être obligé de ‹ bricoler › mes payloads pour que tout cela fonctionne.
L’utilisation de Virtuals dans Jeedom est essentiel et basique.
Vu la roadmap des system domotique-MQTT, je pense qu’il serait raisonnable d’essayer de rendre le système Jeedom robuste aux échanges MQTT.
Enfin, c’est mon humble avis … 
Je ne comprend pas.
jMQTT n’est pas développé par @Loic ni les équipes Jeedom.
La perche à déjà été tendue vers eux s’ils souhaitent un coup de main pour developper un plugin officiel MQTT. Nous n’avons pas eu de retour pour le moment car le temps leur manque.
Je ne sais pas ce que veux dire l’expression : « rendre le système Jeedom robuste aux échanges MQTT ».
Peux-tu me la détailler?
Désolé de ne pas être très clair mais peut être ai-je moi-même mal compris de mon coté.
Oui, le plugin jMQTT n’est pas développé par l’équipe Jeedom.
Mais j’avais compris dans ton analyse que tu faisais appel à une fonction du core Jeedom.
Finalement, la question est alors :
Est-ce que le résultat renvoyé par la fonction du core est un attendu ou est-ce qu’il est erroné ?
De mon coté, je ne sais pas dire mais quel est ton avis ?
Après, si le plugin jMQTT doit être rendu robuste et donc pouvoir transmettre des payloads sans leur apporter de modification (à l’image du logiciel MQTT Manager), peut être faudrait-il développer la fonction pour éviter de faire appel à la fonction du core ?
Je ne pourrais certainement pas t’aider car mes compétences PHP sont limitées mais c’est peut être la solution ?
Il me semble qu’un plugin MQTT « Robuste » doit se comporter au minimum comme MQTT Manager.
Cela ne semble pas être le cas pour le moment même si jMQTT est déja super utile et convivial comme on les aime chez les Jeedom users 
Merci mille fois pour ton support dans tous les cas … 
1 « J'aime »
Pour moi, il est erroné. Une des difficultés est qu’il n’y a pas de documentation concernant les fonctions du Core. Nous nous contentons donc de prendre exemple sur l’utilisation qui est faite dans les plugins officiels.
Je ne peux donc pas confirmer que ce n’est pas le resultat attendu…
C’est ces points que je ne comprend pas bien. Il me parraissent contradictoires.
- transmettre des payloads sans leur apporter de modification : Donc le cas que tu rencontres avec une reference à une autre commande ne serait plus possible?
- (à l’image du logiciel MQTT Manager) : De mon point de vue, les plugins « MQTT Manager » et « MQTT » sont robustes, oui, car ils sont simples.Mais, pour moi, ils manquent de fonctionnalités, ce qui les rend peu conviviaux et pas très utilisables.
- développer la fonction pour éviter de faire appel à la fonction du core : refaire (peut-être) la même chose que le Core n’est pas interessant et réduit la maintenabilité sur la durée.
C’est-à-dire ? Quel est le comportement de MQTT Manager qu’il faut reproduire?
Hello,
pour info c’est ce cas la qui peut être résolu en décochant l’option « quotes automatique » dans la config Jeedom, mais c’est pas la meilleur solution,
Ensuite autre contournement qui fonctionne chez moi :
Virtuel :
jmqtt :
{"name":"CRENEAU1","value":"#[Aucun][test_Eridani78][CRENEAU1]#","unit":"","label1":str_replace('"','','#[Aucun][test_Eridani78][CRENEAU1 Label]#')}
@Domochip & @Phpvarious ,
Pour les String avec ‹ leading zero ›, il semble que remplacer les double-quote par des simple-quote règle les problèmes 
{"name":"CRENEAU1","value":'#[Energy][Linky A203 Standard Mode][CRENEAU1]#',"unit":"","label":#[Energy][Linky A203 Standard Mode][CRENEAU1 Label]#}
Tout ca pour ca !!!
Mais du coup, tu n’avais pas répondu à cette question : As-tu besoin du Virtuel?
L’utilises-tu ailleurs ou pour l’afficher?
Oui, bien sur que j’ai besoin du Virtual.
Par principe, toutes mes infos capteurs (teleinfo, sondes, etc, …) arrivent sur un virtuel dédié.
L’équivalent d’un Driver sous Windows. Si tu changes un capteur (même modèle après panne ou modèle différent après évolution), tu n’as qu’un seul endroit à modifier et non pas partout dans Jeedom
OK, je vois, tu as ajouté une couche d’abstraction en utilisant les virtual.
Je comprend la démarche mais elle est déconseillée par Jeedom.
cf : Documentation Jeedom
Il ne me semble pas que je déroge aux bonnes pratiques Jeedom.
La doc dit :
- créer un équipement alimenté par une source externe à Jeedom (Zibase, IPX800, etc…),
Pour un système robuste (j’utilise ce terme de nouveau), je pense qu’il est imperatif de dissocier l’info physique de l’info numérique.
Exemple :
Ma sonde temperature exterieure envoie l’info physique ‹ Temp. Sonde Ext. ›
Je place Temp. Sonde Ext. dans un virtuel avec l’info Temp. Ext.
Dans mon systeme, je ne compte plus tous les endroits ou cette valeur est utilisée ou affichée.
Si demain je change de sonde, il est facile de voir ce qu’il y a a faire pour retrouver un fonctionnement correct.
Je parlais de cette partie juste en-dessous :
Perso, je ne les utilise que pour des macro et faire des input sur l’interface (genre la présence)
Oui mais je maintiens
En tout cas, un grand merci à vous @Domochip , @Phpvarious pour votre support et vos interventions.
Je pense que ce post nous aura permis de progresser sur l’utilisation du plugin jMQTT et du protocole en général.
Quand on regarde sur le web, les string avec leading zero ont fait couler pas mal d’encre semble t-il.
Je trouve quand même étrange qu’il n’y ai pas eu d’autres interventions pour signaler le même type de soucis. Du coup je me questionne.
Je vais fermer ce post.
A une autre fois … Bye