Ma configuration
1 - Raspberry Pi4B 4 Go - Raspbian GNU/Linux 10 (buster) 32bits (armv7l)
Jeedom version Stable 4.2.7
Plugin Virtual Stable 2022-01-31 01:16:25
Plugin jMQTT : version Stable 2022-01-31 09:24:40
2 - Raspberry Pi4B 8 Go - Debian GNU/Linux 10 (buster) 64 bits (aarch64)
Jeedom version Stable 4.2.7
Plugin Virtual Stable 2022-01-31 01:16:25
Plugin jMQTT : version Stable 2022-01-31 09:24:40
Bonjour,
J’ai attendu de passer en version Jeedom Stable 4.2.7 pour écrire ce message mais le soucis existait déjà en version Stable 4.1.28 avec le plugin jMQTT en version Stable précédente.
Je transmet les paramètres de la Téléinfo de mon compteur Linky de mon RPI4B1 vers mon RPi4B2 via MQTT.
J’utilise le plugin jMQTT sur les deux RPi avec le broker Mosquitto en local sur RPi4B1.
Comme montré sur les copies d’écran (voir ci-dessous), il y a un soucis de « Parsing JSON » lorsque le contenu, pourtant en format STRING à l’origine comporte des « Leading Zero ».
La String est issue d’une valeur Info dans un Virtual.
Si le mot envoyé n’est pas une String, c’est un comportement qui est attendu mais en String, il ne devrait pas y avoir de problème. D’ailleurs, ca fonctionne si j’envois directement une String de la forme ‘0000’ par jMQTT.
J’ignore si une conversion cachée est réalisée dans le core Jeedom, dans le plugin Virtual ou dans le plugin jMQTT mais je n’ai pas réussi à résoudre ce problème (quotes, double-quotes, etc, …).
De l’aide ? Une idée ?
Merci d’avance.
Virtual
jMQTT RPi4B1 (emetteur)
jMQTT RPi4B2 (recepteur)
Rectificatif a mon message précédent.
Suite à la migration en Jeedom 4.2.7, je n’avais pas remarqué que le broker était OFFLINE.
Du coup, le comportement est maintenant différent mais toujous non satisfaisant.
Les JSON sont bien parsés mais c’est parce que les « leading zeros » ont été supprimés !!!
Voir nouvelle copie d’écran ci dessous.
jMQTT RPI4B2 (recepteur)
Maintenant, je penche vraiment pour un problème de changement de format String → ? dans le plugin jMQTT.
Suis-je le seul a rencontrer ce soucis de vouloir transmettre un mot commencant par un ou des zeros ?
Bonsoir,
et si tu entoure ceci avec des double quotes ?
"value":"#[Energy][Linky A203 Standard Mode][CRENEAU1]#"
Bonsoir et merci pour la suggestion.
Mais cela ne change rien car #[Energy][Linky A203 Standard Mode][CRENEAU1]# n’est déja plus reconnu comme une chaine de caractères a ce moment.
Les ‹ leading zero › ont déja été retirés.
Faudrait suivre l’info pour voir a quel moment la string devient int, la commande tester sur ton virtuel CRENEAU1 renvoie bien 0630 ?
Oui, la commande tester sur le virtuel renvoie bien 0630.
Après, il n’y a pas moyen de savoir ou la String devient un nombre.
Je pense qu’il y a un problème dans le code du plugin jMQTT mais seul le développeur pourrait nous éclairer la dessus.
J’espère une réponse de sa part.
Serait-il possible d’avoir une capture d’écran d’un MQTT Explorer.
Perso, je n’ai pas bien compris où est le virtual? etc.
C’est un truc genre ? :
teleinfo → virtual → jMQTT → Broker → jMQTT
C’est étonnant car j’arrive pas a reproduire j’ai la même config (version jmqtt, virtuel, jeedom):
Virtuel : (2022-01-31 01:16:25)
* l’encadrer c’est pour les tests
Jmqtt : (2022-01-31 09:24:40)
Je reçoi bien 0634 et non 634 
Bonsoir,
Oui, la chaine est bien :
teleinfo → virtual → jMQTT1 → Broker1 → jMQTT2
Avec MQTT Explorer, on voit que le mot transmis à jMQTT2 n’est déja plus une String.
tu as bien mis les quote " sur #[Energy][Linky A203 Standard Mode][CRENEAU1]# dans ton pub. auto ?
Oui, si j’envoie cela :
{"name":"CRENEAU1","value":"#[Energy][Linky A203 Standard Mode][CRENEAU1]#","unit":"","label":#[Energy][Linky A203 Standard Mode][CRENEAU1 Label]#}
ca ne change rien.
Je reçois 0 au lieu de 0000
Et si j’envoie cela :
{"name":"CRENEAU1","value":"0000","unit":"","label":#[Energy][Linky A203 Standard Mode][CRENEAU1 Label]#}
Je recois bien 0000 (sur MQTT Explorer egalement).
Je pense avoir trouvé, c’est ton CRENEAU1 Label qui a l’air de gêner le payload, essai en le supprimant de l’équation.
Remplacer CRENEAU1 Label par « Essai » dans l’équation ne change rien.
Par ailleurs, je viens de faire un test en partant d’une Info nouvelle créé dans un Virtual Test.
Sa valeur « 0123456789 ».
Envoyée avec un nouvel equipement jMQTT.
… même réponse.
MQTT Explorer reçoit 123456789 …
Etonnant quand même, voici les payload que je fait lors de mes test avec
valeur = "01420"CRENEAU1 Label = Creneau Horaire #4
Payload 1 :
{"name":"CRENEAU1","value":"#[Aucun][test_Eridani78][CRENEAU1]#","unit":"","label":#[Aucun][test_Eridani78][CRENEAU1 Label]#}
Résultat :
value = 142
Payload 2 :
{"name":"CRENEAU1","value":"#[Aucun][test_Eridani78][CRENEAU1]#","unit":""}
Résultat :
value = 0142
Oui cela devient très étonnant.
Pour ton info, et pour ne pas surcharger le débat, je n’ai pas parlé des autres variables transmises (comme le numéro du compteur par exemple) qui n’ont pas de # dans la payload et qui sont également tronquées des « leading zeros ».
Je ne crois pas que la présence du # dans la payload pose soucis et en le supprimant de mon coté, cela ne change rien …
Autre piste :
pour que ce payload passe :
{"name":"CRENEAU1","value":"#[Aucun][test_Eridani78][CRENEAU1]#","unit":"","label1":"#[Aucun][test_Eridani78][CRENEAU1 Label]#"}
J’ai été désactiver « Quote automatique » dans la config Jeedom (Equipement).
Oh ! C’est interessant.
Mais j’ignore ou je peux désactiver « Quote automatique ».
Ca se trouve ou exactement ?
Bon, chez moi, cela ne change rien a mon info test qui arrive sans le zero.
Je crois qu’il serait sage d’attendre le retour de @Domochip qui j’espère trouveras peut être quelque chose au niveau du code (ou alors il y a un gros truc que nous n’avons pas vu ???).
En tout cas, merci mille fois de ton aide.
Bonne nuit
