Plugin jMQTT

[meute]

Merci, c'est top !

[StephC]

Bonjour,

J'envisage la modification du fonctionnement du plugin suivante:

• Supprimer la case parseJSON sur les commandes information;

• Décoder systématiquement les payload JSON jusqu'au niveau le plus bas et ne pas stoker les niveaux JSON intermédiaires.

Ceci afin:

• De simplifier l'usage du plugin;

• De ne pas être pollué par des commandes intermédiaires qui ne servent à rien (du moins je pense);

• Réduire la charge CPU du plugin.

Est-ce que l'un d'entre vous:

• Utilise ces niveaux intermédiaires?

• Y voit un inconvénient?

Stéphane

[meute]

Hello,

Difficile à dire, pour mon usage aujourd'hui seul le dernier niveau m’intéresse mais qui sait, peut-être qu'un jour j'aurais un équipement qui enverra un json avec des données utiles aussi aux niveaux intermédiaires.

[poluket]

ou un compromis. le parsing se fait automatiquement et les niveaux intermédiaires et supérieurs restent mais sont désactives. en cas de besoin on les réactive. comme cela ca allège la charge et via une couleur spécifique, il est facile d'identifier ceux désactivés ...

en tout cas, super plugin

[mycev]

Bonjour,
Pour moi, cela fonctionne bien. L'idée de cercler de rouge un équipement dont l'ajout des commandes est actif est une bonne chose (merci d'avoir mis à jour la notice en simultané, ce n'est malheureusement pas toujours le cas sur d'autres plugins...)

Comme pour Meute, difficile de dire si la suppression de la case "Parse json" pourrait poser un problème. Cela étant, la présence de cette case permet dans le cas de l'ajout automatique de limiter la création de commande et, une fois récupérés les json, on peut alors désactiver la création de commande automatique et ne créer que le la commande qui nous intéresse.
J'utilise des modules sonoff avec le firmware tasmota et j'ai l'impression que je me retrouverais avec une quantité de commande très importante en mode ajout automatique (je viens de tester et je passe de 6 à 16 commandes crées automatiquement avec un simple S20...)
Juste une question, dans la la table "santé" du plugin, à quoi correspond la colonne Statut ? J'ai plusieurs modules dont je sais pertinemment qu'ils sont débranchés depuis plusieurs jours et pourtant leur statut est "OK". Utilises-tu la fonction "keep alive" ?
Ne serait-il pas intéressant (même si ce n'est pas toujours fiable) d'ajouter une colonne pour le LWT (Last Will and Testament) ?

[StephC]

Bonjour mycev,

Comme pour Meute, difficile de dire si la suppression de la case "Parse json" pourrait poser un problème. Cela étant, la présence de cette case permet dans le cas de l'ajout automatique de limiter la création de commande et, une fois récupérés les json, on peut alors désactiver la création de commande automatique et ne créer que le la commande qui nous intéresse.

Je ne comprend pas la fin de la phrase, comment t'y prendrais-tu? Aujourd'hui tel que c'est fait, si l'on décoche l'ajout automatique de commandes et que l'on supprime un niveau intermédiaire de parsing JSON, alors les niveaux inférieurs ne seront plus mis à jour.

J'utilise des modules sonoff avec le firmware tasmota et j'ai l'impression que je me retrouverais avec une quantité de commande très importante en mode ajout automatique (je viens de tester et je passe de 6 à 16 commandes crées automatiquement avec un simple S20...)

Je comprend que ces modules sont verbeux et que tu n'utilises qu'un sous-ensemble d'information. Ce qui milite pour ne pas supprimer parseJSON.

Juste une question, dans la la table "santé" du plugin, à quoi correspond la colonne Statut ? J'ai plusieurs modules dont je sais pertinemment qu'ils sont débranchés depuis plusieurs jours et pourtant leur statut est "OK". Utilises-tu la fonction "keep alive" ?

Je n'avais pas regardé ce point encore. A rien en fait... Le Status n'est pas géré et la table affiche OK par défaut... Le keep alive serait plutôt un statut de niveau plugin puisqu'il regarde la communication avec le broker. Faudrait peut-être définir un timeout sur la communication, propre à chaque équipement.

Ne serait-il pas intéressant (même si ce n'est pas toujours fiable) d'ajouter une colonne pour le LWT (Last Will and Testament) ?

Dans ce cas il faudrait connaître le topic sous lequel l'équipement envoi son LWT. Donc rajouter un champ de saisi dans la page de configuration de l'équipement et souscrire à ce topic. J'imagine que la payload pourrait être du JSON.
As-tu des exemples?

Stéphane

[mycev]

Bonjour,

mycev a écrit : ↑
Hier, 19:54
Comme pour Meute, difficile de dire si la suppression de la case "Parse json" pourrait poser un problème. Cela étant, la présence de cette case permet dans le cas de l'ajout automatique de limiter la création de commande et, une fois récupérés les json, on peut alors désactiver la création de commande automatique et ne créer que le la commande qui nous intéresse.

Je ne comprend pas la fin de la phrase, comment t'y prendrais-tu? Aujourd'hui tel que c'est fait, si l'on décoche l'ajout automatique de commandes et que l'on supprime un niveau intermédiaire de parsing JSON, alors les niveaux inférieurs ne seront plus mis à jour.

J'aurais créé une commande de type "info" avec le topic "sonoff_06/tele/INFO1{Version}" par exemple, sachant que le json récupéré avec le topic "sonoff_06/tele/INFO1" est "{"Module":"S20 Socket","Version":"5.11.1","FallbackTopic":"DVES_128AF3","GroupTopic":"sonoffs"}"... Mais l'architecture fait-elle que cela ne fonctionnerait pas ?

Cela étant, je viens de me rendre compte que l'on ne peut que créer des commande de type action
J'ai l'habitude du plugin zWave ou tout est en lecture/écriture : on peut donc choisir lors de la création manuelle le type de la commande souhaitée et renseigner les champs en fonction des besoins...
Y a-t-il une bonne raison (en dehors du fait que MQTT était comme cela au moment du fork ) pour empêcher l'écriture des types (appelés dans le plugin "sous-type") de commande et la modification des topics ?

Je n'avais pas regardé ce point encore. A rien en fait... Le Status n'est pas géré et la table affiche OK par défaut... Le keep alive serait plutôt un statut de niveau plugin puisqu'il regarde la communication avec le broker. Faudrait peut-être définir un timeout sur la communication, propre à chaque équipement.

En fait, en creusant un peu, le LWT serait intéressant dans le sens ou il est envoyé par le broker qui gère lui même le keep-alive avec les clients :

When will a broker send the LWT message?
According to the MQTT 3.1.1 specification the broker will distribute the LWT of a client in the following cases:
An I/O error or network failure is detected by the server.
The client fails to communicate within the Keep Alive time.
The client closes the network connection without sending a DISCONNECT packet first.
The server closes the network connection because of a protocol error.
We will hear more about the Keep Alive time in the next post. (source hivemq.com )

Dans ce cas il faudrait connaître le topic sous lequel l'équipement envoi son LWT. Donc rajouter un champ de saisi dans la page de configuration de l'équipement et souscrire à ce topic. J'imagine que la payload pourrait être du JSON.
As-tu des exemples?

Avec le firmware Tasmota, les sonoff utilisent le topic complet '(topic de l'équipment)/tele/LWT' sans json (juste 'Online' ou 'Offline'). Malheureusement, le topic complet semble différent sur d'autres équipements (je ne parle pas du topic le plus élevé bien sûr... Le nombre de topic level est même différent). Seul le topic 'LWT' à la fin d'un topic complet semble être une constante... Ne peut-il pas être détecté 'en dur' ?

[meute]

Y a-t-il une bonne raison (en dehors du fait que MQTT était comme cela au moment du fork ) pour empêcher l'écriture des types (appelés dans le plugin "sous-type") de commande et la modification des topics ?

L'argument de Lunarok sur le fait que les topic info ne puissent être créés qu'automatiquement était : "Un bon domoticien est un domoticien fainéant", et le fork a été fait sur ça ...

Perso je suis pas tout à fait d'accord, certain domoticien peuvent être fainéants mais malgré tout vouloir avoir le contrôle sur ce qu'ils font ...
Ensuite si c'était pour des questions de temps de dev à passer sur un plugin gratuit c'est une autre histoire ...
Je ne comprend pas qu'il le soit d'ailleurs, pour moi ce plugin méritait d'être payant, il est quand même super utile pour beaucoup.
Et le fork de StephC est occupé de prendre un chemin un cran au-dessus ce qui justifierait encore plus sa rémunération.

[StephC]

Bonsoir,
Je vais essayer de répondre aux différents points.

Y a-t-il une bonne raison (en dehors du fait que MQTT était comme cela au moment du fork ) pour empêcher l'écriture des types (appelés dans le plugin "sous-type") de commande et la modification des topics ?

Les raisons que je vois sont:

• Simplicité d'utilisation (ne pas perdre les utilisateurs non experts)

• La simplicité côté développement: faudra s'assurer qu'il n'y ait pas d'incohérences entre le topic saisi et le topic de haut niveau de l'équipement

Rien d'insurmontable toutefois... je sais que meute est également intéressé, je vais y songer...

En fait, en creusant un peu, le LWT serait intéressant dans le sens ou il est envoyé par le broker qui gère lui même le keep-alive avec les clients.

Il y a déjà la santé du plugin (Analyse->Santé) qui vérifie l'accès au port IP du broker et couvre certainement la grande majorité des pannes.

Avec le firmware Tasmota, les sonoff utilisent le topic complet '(topic de l'équipment)/tele/LWT' sans json (juste 'Online' ou 'Offline'). Malheureusement, le topic complet semble différent sur d'autres équipements (je ne parle pas du topic le plus élevé bien sûr... Le nombre de topic level est même différent). Seul le topic 'LWT' à la fin d'un topic complet semble être une constante... Ne peut-il pas être détecté 'en dur' ?

La spécification MQTT ne spécifie pas le topic LWT, difficile donc d'envisager le détecter en dur. On pourrait imaginer une case à cocher LWT, à charge de l'utilisateur de la cocher. Pas sûr que le jeu en vaille la chandelle. D'autant qu'on peut déjà configurer une alerte via les paramètres avancées d'une commande (le bouton aux 3 engrenages sur chaque commande).

Ensuite si c'était pour des questions de temps de dev à passer sur un plugin gratuit c'est une autre histoire ...
Je ne comprend pas qu'il le soit d'ailleurs, pour moi ce plugin méritait d'être payant, il est quand même super utile pour beaucoup.
Et le fork de StephC est occupé de prendre un chemin un cran au-dessus ce qui justifierait encore plus sa rémunération.

Je prends le compliment avec plaisir, merci. Mais je préfère que le plugin reste gratuit et ne pas me sentir redevable.

Stéphane

[mycev]

Bonsoir,

Les raisons que je vois sont:

Simplicité d'utilisation (ne pas perdre les utilisateurs non experts)

La simplicité côté développement: faudra s'assurer qu'il n'y ait pas d'incohérences entre le topic saisi et le topic de haut niveau de l'équipement

Rien d'insurmontable toutefois... je sais que meute est également intéressé, je vais y songer...

Je comprends, mais n'est-il pas possible de pouvoir concilier les deux ? Je suis d'accord que dans la majorité des cas, les utilisateurs vont utiliser la configuration automatique et, même si les infos sont en écriture, il ne vont pas y toucher.
Après, tant que les éventuelles incohérences ne sont pas de nature à planter le plugin, ce n'est pas trop grave : Si l'on considère par exemple le plugin zWave, je ne pense pas qu'il y ai des contrôles particulier de cohérences sur les valeurs saisies (en tout cas, je n'en ai pas détecté même en mettant n'importe quoi sur mon jeedom de test, en dehors bien sûr de la gestion d'erreur réalisée par le démon... mais j'imagine que Mosquito saura le faire également ?)
Pour essayer de finir de te convaincre (après, promis, j'arrête), j'ai été amené à changer le "topic de souscription" pour un équipement : je n'ai pas réussi à modifier les topics des infos alors que c'est indispensable J'ai du recréer les commandes, ce n'est pas trop grave... Sauf si elles sont utilisées dans des scénarios (ou ailleurs)
Merci d'y songer...

Il y a déjà la santé du plugin (Analyse->Santé) qui vérifie l'accès au port IP du broker et couvre certainement la grande majorité des pannes.

Soit, mais dans ce cas, impossible de voir qu'un périphérique a été débranché (par exemple). Il serait peut-être judicieux dans ce cas de retirer (si cela est possible) la colonne Status si l'info affichée est trompeuse ?

D'autant qu'on peut déjà configurer une alerte via les paramètres avancées d'une commande (le bouton aux 3 engrenages sur chaque commande).

C'est une bonne idée ! Je viens de tester et ça fonctionne ! Bon, dans un sens seulement car si cela passe bien en warning quand le payload du topic LWT est Offline, l'équipement ne repasse pas en vert lorsque le payload repasse à Online (mais là, il faut que je regarde du côté du core de Jeedom je pense...)
Bon c'est vrai quand même qu'une page de status qui gèrerait un Topic LWT pour l'équipement serait un plus... Mais certes pas indispensable.

Je prends le compliment avec plaisir, merci. Mais je préfère que le plugin reste gratuit et ne pas me sentir redevable.

Je te comprend, vu l'attitude de certains sur le forum qui considèrent que parce qu'ils ont payé quelques euros un plugin sur le market, ils peuvent être très exigeants... oubliant même parfois que Jeedom est gratuit (et open source) !
En tout cas, merci pour le travail réalisé !

[macdeux]

Bonjour,
J'ai installé jmqtt en suivant les explications de meute et tout est ok...
Dans le topic "global/updatecheck" j'ai le message "version 3.1 available, broadcast.csv: different version available, memory.csv: different version available" alors que j'ai pris la version 3.1 sur le git.
Es-ce qu'il y a une mise à jour a faire et comment ?
Merci du coup de main et bonne journée.

[meute]

Hello,

Non, d'après ce que j'ai lu sur ce sujet sur le git ebusd ces messages sont "erronés" et il ne faut pas en tenir compte, j'ai les mêmes.

Mais ces message sont des topics qui proviennent de ebusd et pas de JMQTT, JMQTT n'a rien à voir là dedans, il serait donc mieux d'en discuter ailleurs que dans le post de JMQTT

[StephC]

Bonjour,
Nouvelle version ce matin, comme d'habitude voir le changelog https://github.com/domotruc/jMQTT/blob/ ... g.asciidoc.
La modification principale est l'activation du mode ajout automatique d'équipements qui se fait maintenant par un bouton d'inclusion et se désactive automatiquement après 2 à 3 min.
Stéphane

[StephC]

@meute, @mycev: je n'oublie pas les discussions ci-dessus, je vais formaliser les évolutions discutées via des issues sur github pour implémentation.

[mycev]

Merci, bonne idée pour le mode inclusion !
Ca permet de la cohérence avec les autres plugins comme RFXcom ou Zwave

[kalon33]

Bonsoir,

Tout d'abord merci beaucoup pour ce plugin, qui m'a permis d'ajouter facilement mes nodes LoRaWAN TTN via MQTT dans Jeedom.

Une question cependant: est-il possible d'ajouter des commandes d'info facilement ? Si oui, comment ? En effet, j'ai une erreur comme quoi je créé une commande en doublon lors de l'utilisation de ParseJSON, et comme je n'ai besoin que d'une partie des variables du JSON à parser, autant l'ajouter à la main...


Merci d'avance !

[StephC]

Bonjour,
Ce n'est pas possible aujourd'hui. Mais c'est une demande récurrente, je l'implementerai donc. Difficile de donner une date, suis pas mal chargé en ce moment.

[kalon33]

OK super, pas de souci je patienterais

Y'a t-il possibilité de simplifier la récupération de coordonnées GPS depuis les données fournies dans un topic? Par exemple, ajouter un menu pour mapper le JSON à un objet geoloc ou localisation et trajets (comme dans le plugin XeeCloud)? Ca serait pas mal pour gérer le positionnement d'objets (par exemple, de nodes LoRaWAN, mais on peut imaginer toutes sortes d'objets communiquant via MQTT)...

Par exemple, faire du mapping 1 à 1 pour Altitude, Longitude, Latitude (identifier ces éléments dans les variables de l'objet à la main, pour renvoyer "automatiquement" les infos au plugin adapté) et/ou prendre en charge un JSON du genre

Code : Tout sélectionner

{"altitude":xx,"latitude":yy.yyyy,"longitude":z.zzzz}

Merci d'avance

[mixman68]

Bonjour,

Comment pouvons nous nous connecter à un broker externe en HTTPS ou en Websocket ?

ça ne semble pas supporté

[mixman68]

Hello

J'ai reussi à résoudre moi même le soucis

J'ai tout bêtement créé un bridge dans /etc/mosquitto/conf.d avec le paramètre bridge_capath