Plugin MQTT Manager

Publié sur: Plugin MQTT Manager – Jeedom – Le Blog

Un plugin qui risque de devenir de plus en plus important/utilisé dans Jeedom car de nombreux plugins devraient s’appuyer dessus à l’avenir (quoi ? Zwave ?). Ce plugin permet de se connecter à un broker MQTT ou si vous n’en avez pas de l’installer, de le configurer et de s’y connecter. Attention pour l’installation du…

4 « J'aime »

Bonsoir.

Si je comprends bien, à l’avenir c’est broker et docker imposé pour tout ?
C’est une obligation d’aller sur cette voie ?

Merci

Rien n’est jamais obligé si tu veux mettre le brocker ailleurs ça sera possible bien sûr (c’est même déjà le cas) mais oui on se dirige vers du Mqtt.

2 « J'aime »

J’ai rien contre, je ne connais pas du tout, je demande qu’à apprendre.
Mais cela sera certainement plus complexe a gérer, sur les pi par exemple.
Et cela rajoute une ou deux couches de complexités en plus.
Il faudrait qu’une personne se dévoue pour expliquer de manière agricole, ce qu’est un broker, mqtt…

Merci de ta réponse en tout cas.

De manière agricole ? On fait ça comment ? :smile:

Sinon essaie de voir avec le tuto que j’avais fais normalement la partie consistant à décrire les différents composants et à quoi ils servent devrait aider.

3 « J'aime »

Hello,

A la lecture des dernières annonces officielles j’ai comme l’impression qu’on nous invite sans trop de précautions ou de pincettes à passer en V4.2 sans spécifier que c’est donc un passage du core en beta, dixit le blog :

Pour installer le plugin, il suffit juste être en Jeedom 4.2 ou plus

Sauf erreur la V4.2 Stable est encore dans les tuyaux, seul un passage du core en beta permettrait d’accéder à la V4.2 Beta … faut-il en conclure que c’est à ce jour suffisamment « safe » pour passer un jeedom de prod sur la V4.2 Beta ? ou les articles sont rédigés « depuis le futur » ?

Ca me démange de tester les nouvelles fonctionnalités de la 4.2 en prod mais je sais ce que peut donner une beta … mais d’un autre côté comme les articles du blog ne semble pas inciter plus que ça à la prudence je m’interroge donc …

1 « J'aime »

Je suis assez d’accord avec toi, la documentation pourrait indiquer que cette version est encore en bêta (mais ils devront à nouveau modifier la doc quand ce ne sera plus le cas et personne n’aime jouer de trop avec les docs).

Moi je te déconseille de passer en bêta 4.2 sauf à t’inscrire en tant que bêta testeur et à poster dans les parties adéquat de Community sous peine de voir quelques personnes ici grincer des dents si tu signal un problème :wink:.

1 « J'aime »

Bonjour,
Cela implique donc une transformation de tout les plugin type zwave ou zigbee ? Ou de nouveaux plugin officiel dédiés mqqt arriveront en parallèle de ceux existant ?
Si l’avenir de jeedom est le mqqt pourquoi ne pas l’intégrer nativement dans le core Jeedom ? ( Simple question ce n’est peut-être pas possible techniquement parlant).

1 « J'aime »

En //

Parce que tous le monde n’utilisera pas forcément du mqtt, et que via un plugin, sous jeedom en tous cas, c’est pas comme si c’était dans le core mais presque. De plus un plugin peut être monté dans un docker alors qu’une morceaux de core non …
Bien que à mon avis pour le peu qu’on utilise du zwave par exemple l’utilisation du mqtt sera obligatoire pour profiter d’un protocole Z-Wave à jour et basé sur le SDK officiel.

Tout ce qu’il faut espérer c’est qu’il sera possible de migrer les équipements entre l’ancien plugin z-wave et le nouveau facilement sans devoir refaire de l’inclusion ou des nouveaux équipements … mais ça c’est pas sur car pas évident.

3 « J'aime »

Oui je suis impatient concernant le zwave. Si j’ai bien compris la logique du mqqt , avec ma clef zwave, re-inclusions logiquement non, re-creation des équipements dans le nouveau plugin oui sauf si il arrive à faire un script permettant de transférer les équipements du plugin zwave actuelle vers le nouveau plugin zwave mqqt.

1 « J'aime »

Bonjour,
J’ai une question concernant cette partie:

Citation « Transmettre tous les événements des commandes » : permet de demander à Jeedom d’envoyer toutes les informations venant de toutes les commandes Jeedom sur MQTT

Cela veut bien dire que tout les info de jeedom vont être envoyés sur le broker et récupérable.
Genre si j’ai un page html avec mqtt connecté dessus je verrai tout les éléments de mon jeedom?
( enfaite j’aimerai remplacer les commande via api pour refresh certaines info que j’affiche sur des html sur d’autres serveur :slight_smile: )

Merci.

Oui c’est exactement ca comme le dit l’intitulé ca transmets tout (attention jeedom 4.2 obligatoire sinon ca marche pas)

2 « J'aime »

Et donc la 4.2 est-elle safe à utiliser en prod ou tu conseille d’attendre la stable ?

Petit Question @Loic
Pour ceux qui ont déjà un plugin du type JMQTT avec Mosquito en local, doit-on réinstaller Mosquito ( je vois bien que oui sur l’installation !)
@+Dom

Non c’est une beta donc c’est par définition as stable

Non tu n’es pas obligé tu peux soit demander au plugin d’installer mosquitto soit le connecter à mosquitto existant

Bjr,…
J’ai essayé d’installer en distant ou en local, problème sur « demon » et dépendance « NOK »
Mosquitto s’installe sans erreur, création user: key « OK »

Pas d'erreur sur les dépendances !

`+ echo ‹ *Begin of package installation ›
*Begin of package installation

  • touch /tmp/jeedom_install_in_progress_mqtt2
  • echo 1
  • echo 2
  • sudo apt update
    WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
    Atteint :1 Index of /debian buster InRelease
    Atteint :2 Index of linux/debian/ buster InRelease
    Atteint :3 Index of /raspbian buster InRelease
    Atteint :4 Index of /node_14.x/ buster InRelease
    Lecture des listes de paquets…
    Construction de l’arbre des dépendances…
    Lecture des informations d’état…
    Tous les paquets sont à jour.
  • echo 3
  • echo 4
  • rm /tmp/jeedom_install_in_progress_mqtt2
  • echo ‹ *End of package installation ›
    *End of package installation`
"Mais message dans log Mqtt2d :connect ECONNREFUSED 127.0.0.1:8883
[2021-12-03 10:20:43][INFO] : Start dysond
[2021-12-03 10:20:43][INFO] : Log level on  : debug
[2021-12-03 10:20:43][INFO] : Socket port : 55035
[2021-12-03 10:20:43][INFO] : MQTT : mqtts://127.0.0.1:8883
[2021-12-03 10:20:43][INFO] : Username : jeedom
[2021-12-03 10:20:43][INFO] : Password : FUJF"j'ai masqué le reste"
[2021-12-03 10:20:43][INFO] : PID file : /tmp/jeedom/mqtt2/deamon.pid
[2021-12-03 10:20:43][INFO] : Apikey : BT"j'ai masqué le reste"
[2021-12-03 10:20:43][INFO] : Callback : http://127.0.0.1:80/plugins/mqtt2/core/php/jeeMqtt2.php
[2021-12-03 10:20:43][INFO] : Cycle : 0.3
[2021-12-03 10:20:43][INFO] : Client key : /var/www/html/plugins/mqtt2/data/ssl/client.key
[2021-12-03 10:20:43][INFO] : Client crt : /var/www/html/plugins/mqtt2/data/ssl/client.crt
[2021-12-03 10:20:43][INFO] : CA : /var/www/html/plugins/mqtt2/data/ssl/ca.crt
[2021-12-03 10:20:44][INFO] : Connect to mqtt server
(node:24089) [DEP0123] DeprecationWarning: Setting the TLS ServerName to an IP address is not permitted by RFC 6066. This will be ignored in a future version.
(Use `node --trace-deprecation ...` to show where the warning was created)
[2021-12-03 10:20:44][DEBUG] : HTTP listen on 127.0.0.1 port : 55035 started
[2021-12-03 10:20:44][ERROR] : Error on connection to mqtt server : Error: connect ECONNREFUSED 127.0.0.1:8883

Je vais voir pour faire installation sur système « clean » !

Tu es bien en jeedom 4.2 ?

Oui sur la 4.2.5 sur mon RPI de test …