Comme évoqué succinctement ici, il y a aujourd’hui 3 plugins dans Jeedom permettant de discuter avec un ou des Broker MQTT, chacun avec ses avantages et ses forces.
Chacun propose d’installer à sa façon mosquitto en local et souvent c’est l’utilisateur qui fini par « casser » son Broker local en réinstallant mosquitto avec un autre plugin ou en désinstallant le plugin qui le gérait. Donc il faudrait une façon de se mettre d’accord sur qui configure et maintient le Broker local.
Le plus simple serait juste de renseigner dans la config du Core le plugin qui « tiens » mosquitto et les paramètres de connexion, afin que les autres plugins puissent souscrire à ce Broker, mais ça pose d’autres problèmes, par exemple lors de la suppression du plugin qui gère mosquitto.
Etant donné que de plus en plus de plugins vont s’appuyer sur MQTT et souvent le Broker local, mon avis est plutôt que c’est au Core Jeedom de gérer l’installation et la configuration de ce Broker, ainsi que partager les paramètres nécessaires aux plugins souhaitant s’y connecter. Qu’en pensez-vous ?
Normalement le plugin MQTT Manager est justement venu gérer ce problème, celui-ci n’a réellement que comme fonction d’interfacer des plugins avec un MQTT (De mon ressentis).
Je l’utilise déjà pour un de mes plugin en fin de dev et il est déjà en cours de reflexions sur le suivant
Si le plugin est déjà installé, tu peux lui demander ses informations de connection pour le passer à un Deamon (De mon côté daikinToMQTT) avec cete fonction : $mqttInfos = mqtt2::getFormatedInfos();
par contre, pas d’accord sur le fait de mettre cela dans le core; le core ne doit pas être responsable de ce genre de détails amha, lui il gère les équipements et les plugins (et les scénarios etc) et les plugins sont là pour gérer les connexions;
donc même avis que @Thibaut_T => plugin-mqtt2 et c’est bien le but de ce plugin
En plus de permettre de récupérer les infos de connexions, un plugin peut aussi souscrire auprès de mqtt2 à un topic et être rappelé (par mqtt2) si nouveau message arrive; cf.
mqtt2::addPluginTopic($_plugin, $_topic)
et il faut avoir une méthode handleMqttMessage dans ton plugin pour le « callback »
pareil dans l’autre sens, il est très simple de publier une info sur mqtt depuis ton plugin via une méthode de mqtt2 sans devoir s’occuper de la couche connexion au broker; cf.
mqtt2::publish($_topic, $_message)
Si tu ne veux pas avoir mqtt2 en dépendances dans jmqtt alors tu pourrais aussi décider de juste demander les infos de connexions « manuellement » et l’utilisateur installe son broker où et comme il veut (avec l’aide de mqtt2 s’il veut ou pas)
Merci pour vos réponses, je sais bien que l’une des fonctionnalités de MQTT Manager est de permettre à d’autres plugins de venir consommer du MQTT via son Broker. J’ai vu les différentes fonctions pour récupérer les informations du Broker déclaré et de recevoir/envoyer des payloads en provenance de ce Broker.
Mais l’unique Broker de MQTT Manager peut être un mosquitto installé et utilisé en local ou en docker, ou bien un Broker tiers/distant.
Or l’une des particularités de jMQTT est de gérer différents Broker.
Et un nombre important d’utilisateurs ont choisi jMQTT justement pour pouvoir se connecter à mosquitto en local en même temps qu’à d’autres Broker distants ou Cloud (Azure, AWS, HiveMQ, etc).
Ma question concerne directement l’installation et la configuration de mosquitto directement sur le système, et plus particulièrement l’harmonisation des fichiers de configuration, des chemins et de certaines fonctions, dans le but d’éviter les erreurs au moment de l’installation d’un plugin proposant l’installation de mosquitto en local.
Par exemple : MQTT Manager modifie le service systemd de mosquitto pour pointer sur un fichier de configuration présent dans le répertoire data du plugin, pourquoi ne pas utiliser le répertoire data à la racine de Jeedom ? Si tous les plugins utilisaient le même chemin pour ce fichier, il y aurait déjà moins de problèmes à l’installation, non ?
Ou alors à travers un plugin « Broker MQTT Local », non dépendant de Docker, sur lequel qui tous les plugins MQTT pourraient (comprendre devraient) s’appuyer pour l’utilisation d’un broker local ?
Je ne suis pas très fan de la proposition qui consiste à faire installer mosquitto via MQTT Manager, car la charge système engendrée par l’installation de Docker est importante, surtout pour les utilisateurs qui souhaitent un Jeedom léger et uniquement dédié à consommer du MQTT.
J’ai eu encore 4 cas récemment d’utilisateur à cheval entre plusieurs plugin (mqtt, mqtt2, Zlinker et jMQTT).
Pouvons-nous essayer de trouver une fonction statique identique à implémenter dans la classe principale de tous nos plugins ?
Ce serait bien qu’elle retourne les paramètres utilisés par le broker et s’il est installé par le plugin ou externe (ou docker).
J’ai implémenté dans la version stable actuelle de jMQTT un mécanisme qui permet d’identifier qui a (probablement) installé Mosquitto.
Mais ce serait plus pertinent si :
une clé de config était positionnée dans la config globale,
ou méthode statique sur les plugin qui installent Mosquitto permettait de savoir si le plugin l’a installé,
ou que la « signature » de chaque plugin soit claire au niveau des fichiers de config Mosquitto modifiés (jMQTT crée le fichier /etc/mosquitto/conf.d/jMQTT.conf ; mqtt2 modifie le fichier /lib/systemd/system/mosquitto.service ; etc)
