Utilisant JMQTT depuis quelques temps et en mode « tout doit y passer », j’ai déjà migré le zigbee, le zwave et le rflink sur du MQTT.
Côté Zigbee, j’utilise pour l’instant le mosquito installé sur la même VM que Zigbee2MQTT.
Pour Zwave, j’utilise ZwaveJsUi qui balance ses évenements vers une VM dédiée a moquito.
Idem pour RFLink, avec une Mega + Wemos D1 Mini qui balance en MQTT sur ma VM dédiée « mosquito ».
J’ai du coup dans JMQTT deux brokers : un avec que du zigbee, et un avec un mélange de zwave et de rflink. Sachant qu’a terme je projettai de configurer ZwaveJSUI sur ma VM « Mosquito ».
Y-a-t-il moyen de créer un broker en filtrant la source ? j’ai vu le client-id, pas testé, mais je ne suis pas sur que le projet côté RFlink balance un client-id (rien vu dans les paramètres).
Autre moyen ? possibilité de créer un tag/catégorie au niveau de chaque équipement dans le plugin JMQTT qui créérait des sous-catégories ?
(et me dite pas qu’il faut forcément un mosquitto par source ca me parait overkill, ou alors moyen sur un mosquito de créer plusieurs canaux/ports …?)
J’ai de mon côté un broker au sens jMQTT par type de matériel (tasmota, Shelly, frigate, …), qui pointent tous vers le même mosquito avec des user différents
Chaque équipement se connecte au serveur en mosquito avec le user correspondant.
Pour aller plus loin, mais je ne l’ai pas fait, tu peux mettre en place un système d’ACL côté mosquito pour limiter les accès à tel type de topic en fonction de user
Yes vu, en effet la solution est clairement côté config mosquitto, je suis en train de mettre cela en place. Du coup même listener mais user différents suffisant ? j’étais parti sur des couples listener/user dédiés, mais pas nécessaire en effet. A voir si besoin d’utiliser l’option use_username_as_clientid [ true | false ] . je vais tester en empirique
Merci.
Bonsoir,
C’est quoi l’intérêt de plusieurs users sur le meme broker MQTT ? ( c’est pas une critique , c’est une question )
Sur mon broker j’ai ça classé par « famille »
Juste de ne pas mettre le meme login/pwd partout. Le jour ou je decide de changer le pwd MQTT des shellies, je peux le faire.
J’a un couple user/pwd shellies/azertyuiopp que je renseigne dans les shellies et dans dans le broker jMQTT qui gère les shelly
idem pour frigate, pour les tasmotas, …
d’accord merci
D’avoir tout en mqtt sur un broker proxmox , les périphériques répondent beaucoup plus vite , ça a vraiment changé chez moi, par rapport en local avec jeedom sur mon PI.
De mon côté j’ai fait des users différents, pour les dongle ET pour les brokers jmqtt. Avec option d’utiliser le login en tant que client-id pour éviter toute déconnexion.
Je constatait en effet très rapidement des brokers qui faisaient la valse du connecté/pas connecté…
Néanmoins je ne suis pas satisfait, ca ne cloisonne pas les messages par canaux comme j’aurais souhaité faire, j’ai 3 brokers, avec des équipements associés aux bons brokers, mais dans la pratique, les 3 brokers peuvent récupérer n’importe quel message de n’importe quel gateway…
Et ca me parait fébrile, ce matin je pouvais tester un temps réél sur chaque broker, filtré sur son préfix respectif (zwave/#, zigbee2mqtt/#, rflink/#) mais ce soir le temps réel fait du on/off perpétuel même si les brokers semblent stables …
Bref il faut que je creuse encore, mais les éléments fonctionnent, c’est déjà ça
Edit: j’ai enlevé totallement cette histoire de user as cliend-id, et renseigné zéro client id, ca causait plus de problème qu’autre chose. A mon avis le temps réel créée une souscription en // de la souscription des objets ce qui fait que tout se mord la queue. Par défaut si on ne fourni aucun client-id, mosquitto en génère un aléatoire …
Oui, mais le jour où ton Shelly est compromis, tu n’as qu’à changer le pwd des Shelly
Je n’ai pas constaté de charge supplémentaire. Ce qui est à mon avis surtout important, c’est de ne pas avoir de topics racine trop génériques dans les équipements (et encore même pas sûr vu les perfs de mosquitto)
De classer dans l’interface jmqtt les équipements par type. D’avoir des « blocs » d’équipements.
Oui, ça ne change pas grand chose d’avoir un seul user pour tous les brokers jMQTT ou d’avoir des users différents
ben pas sûr. typiquement j’avais laissé un conteneur snap zwavejsui pas désactivé sur un raspberry pi en plus de ma vm zwavejsui lxc proxmox. (Impossible de faire tourner zwavejsui sur rasp 3B+, elle plante systématiquement, pas compris, pas insisté).
Les deux conteneurs se connectaient avec le même user.
J’avais des hit & miss sur les envois de commande zwave depuis jeedom, je comprenais pas. Dans les logs mosquitto j’ai vu que deux adresse ip se connectaient avec le même user ==> a chaque fois ca fermait la connexion de l’un et vice versa. C’est ce qui expliquait mes loupés.
Donc je persiste à croire que des users différents c’est plus propre et clean.
Après le même user depuis la même machine mais avec n brokers, ca pose peut être pas de problèmes, mais à vérifier dans les logs mosquitto… Tout dépends si ce sont des connections TCP dédiées pour chaque broker … et comment mosquitto gère ça.
Oui c’est mosquitto hebergé sur un docker, c’est la vue mqtt explorer sur pc que tu vois.
Aprés en configurant les brokers distants dans chaque plugin, j’ai mis un nom different
A voir je vais pas reproduire le cas mais il est possible que c’est parceque j’étais avec l’option de configuration « use login as cliend-id » dans mosquitto. Du coup en effet bim.
Bon du coup si quelqu’un est intéressé par la question posée dans ce thread, la solution pour séparer les éléments de techno différentes (quand on approche la centaine on aime bien ranger ) c’est de créer plusieurs brokers sur jmqtt, tout simplement
Attention que chaque broker sur le plugin-jmqtt (on devrait dire client-broker) ait chacun un client-id différent car ils seront tous sur le même broker.
ca me parait overkill, ou alors moyen sur un mosquito de créer plusieurs canaux/ports …?)
