@Bad
Bonjour,
Pour mémoire je suis en Jeedom v4.3.15 et jMQTT v2023-02-12 01:01:26
Dans l’onglet ‹ Commandes › d’un équipement quand je passe de la vue ‹ Classic › à la vue ‹ JSON ›, j’ai systématiquement la création, du moins l’affichage, de nouvelles commandes sans nom correspondant à des commandes existantes avec en plus l’option ‹ Afficher › cochée.
Par exemple ici pour les commandes ‹ action › et ‹ clic › :
jMQTT a beaucoup évolué, initialement (avant le mode Temps Réel) la seule façon pour « découvrir » de nouvelles commandes était de laisser le plugin ajouter automatiquement de nouvelles commandes, puis d’utiliser la vue JSON pour « découper » le JSON en « sous-commandes », et enfin de donner un nom à celles que l’on souhaitait conserver avant de sauvegarder.
La vue JSON est donc la vue « éclatée » de toutes les commandes possédant un payload JSON comme valeur, en prenant soin de conserver l’association des « sous-commandes » avec les commandes déjà existantes.
@Bad
Bonjour,
MERCI d’avoir pris le temps de m’expliquer. C’est plus clair maintenant. J’ai aussi relu la doc (au passage j’ai vu que tu avais complété la partie SSL avec les commandes de création des fichiers de certificat : c’est très bien BRAVO ).
Cependant, j’ai encore du mal avec le fait que le plugin affiche en mode JSON une ligne de commande avec un chemin JSON alors que cette commande existe déjà dans la vue Classic. Dans mon exemple ce sont les commandes action et click. N’y-a-t-il pas risque de doublon ?
Cordialement
oracle7
Stricto sensu (d’un point de vue du protocole MQTT) ces commandes sont différentes de celles « découpées », car elles sont sur des topics différents.
Je pense que ce sont SOIT des commandes info basées sur des commandes action que tu as déclarés plus bas (correspondant donc à l’ordre envoyé par jMQTT, et pas au retour d’état effectué par zigbee2mqtt), OU BIEN des commandes « en plus » créés par zigbee2mqtt pour récupérer les valeurs sans avoir besoin d’ouvrir le payload JSON.
Dans les deux cas, il n’y aura pas de souci de « doublon » tant que tu ne créés pas effectivement 2 commandes pour la même chose.
A noter que si les commandes que tu as créé en haut sont lié à l’ordre et pas à l’état, il est préférable d’utiliser celles du JSON qui sont le retour d’état. (Pour ça, pas besoin de créer une nouvelle commande et de déplacer l’historique et tout ce qui est lié, changé juste le topic et le jsonPath de ta commande existant)
Tu as raison, je crois bien que c’est cela en fait. Car les valeurs quelles prennent sont bien un retour d’état. Ce ne sont pas des commandes « infos » basées sur des commandes « action » car ces commandes non lisibles (/get) et non écrivables (/set) voir ici :
A toi de voir maintenant si tu souhaites garder les commandes actuelles ou passer sur celles dans le JSON.
En tout cas, pour jMQTT ça ne fait pas vraiment de différence. Dans le cas présent, tout mettre en JSON serait un poil plus efficace, car il y aurait moins d’échanges en MQTT, mais la consommation de ressources est presque la même et en soit c’est littéralement négligeable.
@Bad
Bonjour,
Encore Merci pour tes explications.
Au final comme cela marche comme cela, je suis ton conseil et ne change rien.
Je pense que tu peux clore le sujet.
Cordialement
oracle7
).
au message qui vous a permis de résoudre votre problème