J’utilise avec bonheur le plugin officiel MQTT Manager ; avec un mosquitto installé localement et géré par le plugin MQTT Manager.
Pour le moment, seul le plugin officiel zwavejs est abonné.
J’ai créé des équipements dans MQTT Manager, et j’utilise aussi le plugin ZigbeeLinker qui s’appuie directment sur ce broker local.
Pour des raisons de sécurité, les ports TCP d’accès au broker local ne sont accessibles que du réseau local.
Jusque la, tout va bien.
Par ailleurs, j’administre (pour un club) des systèmes raspberry distants qui ne font pas partie de mon réseau local.
Je souhaite pouvoir faire remonter à jeedom des informations non sensibles, afin de les historiser : température, charge, débit réseau, …
Je ne souhaite pas que les raspberry distants puissent communiquer directement avec mon système jeedom, et réciproquement.
J’envisage d’utiliser un broker MQTT public, comme HiveMQ, qui servirait d’intermédiaire.
Problème : MQTT Manager ne peut se connecter qu’à un broker MQTT ; à priori, je ne vois pas comment faire avec.
J’envisage de faire tourner un cron sur la machine qui supporte jeedom (odroid c4) afin d’interroger régulièrement le broker distant, et d’alimenter un virtuel jeedom.
Je saurais faire, mais ce n’est peut-être pas la meilleure solution …
Si tu souhaites utiliser un broker mqtt public tu peux utiliser le plugin jmqtt pour le chercher les infos sur ce broker public.
Si tu ne souhaites pas publier sur Internet des ports de ton mosquitto (ce qui est compréhensible) mais que ton SSH est accessible par Internet, tu peux aussi monter un tunnel SSH entre ton raspberry et ton Jeedom et paramétrer directement ton raspberry pour attaquer ton mqtt local sur ton Jeedom.
Si tu as un exemple de paramétrage, je suis preneur. J’ai essayer pendant plusieurs soirées de mettre en place le mode bridge entre 2 mosquitos qui tournent sur 2 mqtt managers, mais sans succès !
Oui. Mais ca m’embete quand même d’utilise 2 plugins pour gérer du mqtt …
Et je souhaite conserver le plugin officiel.
Oui, j’avais envisagé. Mais je souhaite que les systèmes soient complètement indépendants : pas de connexion directe, pas de compte de connexion, …
Pour le moment, je gère les raspberry distants, qui appartiennent à une association. Ca ne durera pas éternellement, peut-être que dans un an, quelqu’un d’autre s’en chargera ; je souhaite le moins de lien entre les systèmes liées à des associations externes, et mon installation odroid - jeedom.
Utiliser un serveur mqtt public permet de bien dissocier les deux environnements. Ce ne sont pas des données sensibles, et on peut en perdre quelques unes sans que ca pose problème ; ca ne me gene pas trop de passer par un intermédiaire.
Je ne connaissais pas ; ca semble intéressant. Je vais regarder.
Si j’avance la dessus, je vous fais un retour.
Sinon, pas de projet coté plugin MQTT Manager pour permettre ‹ nativement › ce type de fonctionnement ?
# =========================================================
# Bridges
# =========================================================
connection NAME_TODO
address TODO_IP:TODO_PORT
# Recuperation du remote PREFFIX/REMOTETOPIC/# pour l'envoyer dans LOCAL_TOPIC/ (ici un sens seulement du au in)
topic REMOTETOPIC/# in 0 LOCAL_TOPIC/ PREFFIX/
cleansession true
notifications false
remote_clientid broker0
remote_username TODO
remote_password TODO
local_username TODO
local_password TODO
start_type automatic
#Si TLS
try_private true
bridge_insecure true
bridge_cafile TODO
bridge_tls_version tlsv1.3
Super, merci.
Tu avait ajouté ce bridge à la conf du mosquitto ‹ de prod ›, ou tu avais créé une instance spécifique de mosquitto dédiée à la fonction bridge ?
J’allais tester la seconde option, mais si ca fonctionne avec le mosquitto géré par MQTT Manager, c’est plus simple
Je viens de me créer un compte chez HiveMQ, je commence les tests. La connexion se fait en TLS
Pour les tests avec mosquitto_sub ou mosquitto_pub , il faut rajouter le certificat (option --cafile) dans la ligne de commande
Moi mon mosquitto est deporté mais ca marchera sans soucis avec celui de jeedom par contre j’ai bien galeré car ca log pas grand chose quand ca marche pas et pas testé avec hivemq c’était un mosquitto déporté.
J’ai fait qqs essais, avec le mosquitto géré par MQTT Manager ; pas de succès pour le moment, mais je ne déespère pas.
J’ai un doute pour faire la mise à jour du mosquitto.conf : faut-il le faire directement dans le fichier /var/www/html/plugins/mqtt2/core/class/…/…/data/mosquitto.conf , ou bien depuis l’interface de conf du plugin MQTT Manager ?
Si je rajoute des paramètres dans la conf du plugin, et que je sauvegarde, ca ne rale pas, mais le fichier de conf n’est pas modifié.
Ce qui fait que j’ai une divergence entre les paramètres mosquitto indiqués dans le plugin, et le fichier de conf.
Même après un redémarrage complet de jeedom
Bonjour,
De mémoire c’est dans la doc (et j’ai du donné aussi ici) il faut modifier dans l’interface jeedom sauvegarder et relancer l’installation local de mosquitto.
Pour quelqu’un qui souhaitait une indépendance totale entre les deux brokers, il est bizarre de choisir la solution du bridge.
Sur une mauvaise configuration, tu risques d’avoir tes données personnelles sur le broker public.
Ce n’est pas dans la doc, mais dans l’interface de conf, le ‹ ? ›, comme signalé par @i-magin ; j’avais lu la doc et le ‹ ? ›, mais de travers pour ce dernier. Désolé.
Ce que je veux, c’est que les systèmes d’extrémité ne communiquent pas entre-eux :
. ports à ouvrir : c’est pour la sécu d’accès aux systèmes (blocage routeur et iptables)
. compte à partager : je ne veux pas créer sur mon système jeedom ou mon système externe de compte spécifique à cela. Parce que, potentiellement, d’autres personnes auront accès à ce système externe.
le broker public ne fera transiter que des données provenant des périphériques externes, qui ne sont pas sensibles ; te que dans le sens la.
Coté conf, il y a plusieurs niveau pour limiter les risques :
coté HiveMQ, 2 comptes de connexion :
. un pour l’extérieur, qui n’a que le droit de publish
. un pour le bridge mosquitto, qui n’a que le droit de subscribe
. si plusieurs périphériques externes, un compte par périphérique
. on pourait même limiter chaque compte à un topic particulier (ACL). Je vais peut-être le faire pour les comptes réservés à l’extérieur.
coté mosquitto, la directive ‹ topic › permet :
. d’une part, de limiter le sens de propagation des infos. Dans mon cas, de HiveMQ vers jeedom
. d’autre part, de fixer les topics des 2 cotés
. on pourrait aussi, je crois, limiter le topic utilisé pour le compte concerné (ACL) ; je ne vais pas faire
Bref, même en faisant l’impasse sur la limitation de type ACL, je ne vois pas pourquoi des données internes à mon système domotique pourraient être récupérées avec l’utilisation de HiveMQ (qui ne génère lui aucune connexion).
Il faudrait une cascade de défaillances.
En outre, la connexion mqtt vers HiveMQ se fait en TLS, et les clients valideront le certificat, donc pas de ‹ man in the middle › ; qui de toute manière ne permettrait que de récupérer des infos que j’estime non sensibles
Bon, yapuka. Je vous tiendrais au courant de l’avancement du projet …
Et encore merci de vos remarques et conseils
Le bridge mosquitto - hivemq fonctionne comme prévu ; merci @Loic .
Depuis le Rpi distant, j’envoie au broker hivemq dans le topic LFEZ/OGN/# , et je retrouve l’info dans le mosquitto local sous le topic HiveMQ/LFEZ/OGN/
Avec un compte hivemq dédié à cet usage et pour ce Rpi, qui ne peut écrire que dans le topic LFEZ/OGN/#
Il ne me reste plus qu’a faire le nécessaire coté Rpi pour préparer et automatiser l’envoi, et coté jeedom pour traiter.
Je gère d’autre petites choses similaires par ailleurs ; sur des systèmes où potentiellement d’autres personnes peuvent se connecter. Ce mode de fonctionnement me satisfait pleinement.
Je joins l’extrait de conf du mosquitto relative à la conf du bridge ; c’est à peu près la même que celle de @Loic.
J’ai déposé le certificat permettant de valider le TLS avec hivemq dans /etc/mosquitto/ca_certificates/ ; ca permet de le rendre également dispo pour les clients mosquitto_sub et mosquitto_pub
J’attends quelques jours pour valider tout cela, et clore le sujet
### Bridge connection ###
connection hivemq
address exxxxxxxx.s2.eu.hivemq.cloud:8883
# Recuperation dans HiveMQ du remote LFEZ/OGN/#, pour deposer localement dans HiveMQ/LFEZ/OGN/
# ici, uniquement dans le sens HiveMQ vers local (pamametre in) et QOS 0
topic OGN/# in 0 HiveMQ/LFEZ/ LFEZ/
cleansession true
notifications false
remote_username xxxxxx
remote_password xxxxxxx
try_private false
# bridge_insecure true
bridge_capath /etc/mosquitto/ca_certificates/
# bridge_tls_version tlsv1.3
Ca y est, la chaine fonctionne, … sauf que je coince coté mqtt manager, sans comprendre pourquoi.
Dans mqtt explorer, je vois bien le message mqtt suivant arriver, dans le topic HiveMQ/LFEZ/OGN/state : {"lastboot":"lundi 17 07 2023 18:35:27","loadaverage":"0.05"}
J’ai créé un équipement (actif, visible), avec le topic HiveMQ/LFEZ/OGN, et les commandes correspondantes ; par exemple :
boot, de type info - autre, et en paramètre state/lastboot
Rien n’arrive, la commande n’est pas mise à jour.
Dans la log du plugin, en mode débug, j’ai ceci : [2023-07-18 16:01:30]DEBUG : Message reçu sans prise en charge par un plugin : {"HiveMQ":{"LFEZ":{"OGN":{"state":{"lastboot":"lundi 17 07 2023 18:35:27","loadaverage":"0.05"}}}}}
Ce message n’est pas suivi d’un message du genre « … mise à jour de la valeur … » comme je peux l’avoir pour d’autres équipements.
J’avais également essayé d’activer dans l’équipement l’option ‹ Activer l’analyse des valeurs pour la création simplifiée des commandes ›, puis le bouton ‹ Découverte › après avoir généré une requete ; pas mieux.
Si la solution vous parait triviale, je suis preneur ; sinon, comme je suis un peu hors sujet, je crée une autre demande dans le community
Ca marche tout de suite, en mettant le topic de l’équipement à HiveMQ/LFEZ, et la commande à OGN/state/lastboot
Je suis à nouveau fautif : dans la doc du plugin, il est bien spécifié qu’on doit se limiter à 2 niveaux …
J’ai zappé, car cette info est donnée dans la section ‹ configuration du plugin ›, pour le topic racine jeedom, et pas dans la configuration des équipements.
Peut-être qu’un point d’interrogation sur le champ de saisie de cette information pourrait limiter les erreur ?
Du coup, je vais changer le topic de l’équipement en HiveMQ_LFEZ/OGN (donc, modifier le bridge), et remettre state/lastboot pour la commande : j’aurais potentiellement d’autres équipements sous HiveMQ_LFEZ
Encore merci à toi, @Loic, pour l’aide et le boulot dans ce plugin et jeedom en général ; et aux autres membres qui m’ont apporté de l’aide.
Je vais clore ce sujet, tout fonctionne parfaitement comme je le souhaitais.
