Bascule de 2 jeedom de openzwave vers zwave js/mqtt2 avec un seul broker mqtt : conflit de client id?

[Ds5]

Bonjour
Je cherche à migrer mes deux jeedom possédant chacun une clé zwave distincte de openzwave vers zwavejs. J’ai migré avec succès et de manière je trouve très facile (bravo pour le mode op) mon premier jeedom (rpi3b+, debian 10, jeedom v4.4.8.1). Utilisant déjà un broker mqtt pour ma vidéo surveillance avec frigate, j’ai utilisé pour mqtt2 naturellement le broker distant mqtt mosquitto sur mon NAS Synology (config mqtt manager en mode distant donc).
Lorsque j’ai du coup migré le second jeedom sur le même principe, tout a commencé à dérailler et j’ai vu les logs zwavejs se remplir d’erreur et les modules zwave des deux jeedom ne plus répondre.
Le 1er jeedom ayant parfaitement fonctionné 4j de suite et s’étant planté dès la migration du second, j’ai vite orientée mes recherches sur un conflit entre les deux : ayant pris soin au préalable de séparer les topics de chaque jeedom (zwaveServ1 au lieu de zwave défaut sur le 1er et zwaveServ2 sur le second), je ne voyais pas d’où cela venait. Grace à un conseil d’une autre personne (merci @ngrataloup ), j’ai vérifié si le souci ne venait pas de deux clients ID mqtt identiques. De ce que j’ai vu sur le broker mqtt via mqtt explorer ou dans les logs mosquitto sur le NAS, j’ai compris que les plugins MQTT Manager de chaque jeedom se présentait sur mon mosquitto du NAS avec le meme id qui doit être je pense « ZWAVE_GATEWAY-Jeedom ».
Du coup à chaque demande de l’un de mes jeedom, cela entre en conflit puisqu’il ne faut pas des ID similaires mais unique sur chaque abonné.
Je voulais donc voir comment indiquer/choisir un id mais je ne vois rien qui semble permettre cela dans la config MQTT Manager.
Pour contourner le problème et vérifier que c’était bien l’unique cause de mes soucis, j’ai donc choisi d’installer en local un broker mosquitto sur le second jeedom et de l’utiliser pour le plugin zwavejs sur la même machine : immédiatement tout a fonctionné parfaitement sur les deux zwave puisque les ID identiques se trouvent sur deux broker distincts.

Du coup ma question est la suivante :

• quelle pourrait être la solution pour utiliser un seul broker avec deux jeedom disposant de zwavejs ?
• au niveau configuration de mqtt2 ou zwavejs, existe-t-il un moyen de spécifier un client ID ou d’en faire générer un unique un peu comme sous jmqtt ?

J’ai fait une recherche dans les sujets existants sur les plugin mqtt2 et zwavejs, ou sur client id mais je n’ai rien trouvé, désolé par avance si j’ai mal cherché.

Merci pour votre éclairage.

[echo]

Bonjour

Côté Mqtt Manager il est noté dans la documentation du plugin :

donc je pense qu’il est possible d’avoir ce type de paramétrage:

Côté zwave je ne connais pas.

Cordialement

[Tonio16]

Salut

As-tu changé le client id entre les deux installations ?

[Mips]

Bonjour,

Question définition ce n’est pas le clientid dont on parle ici qui est probablement généré aléatoirement.
Et je ne suis pas certain que cette valeur ci va avoir un impact (p-e pour l’état général) mais c’est surtout le topic sur lequel les infos sont publiées (zwave) qui va causer le conflit je pense.

[ngrataloup]

Justement, d’après ce que j’ai compris, ces 2 ZwaveJS de 2 jeedom differents qui utilisent tous les 2 un mqtt manager en mode broker distant se presentent avec le clientId (et pas le topic !) ZWAVE_GATEWAY-Jeedom
Du coup, lorsque l’un se connecte, l’autre est deconnecté, un clientID devant etre unique sur un borker

La question est du coup pour @loic je pense, savoir si il peut confirmer que le clientID adressé dans une config ZwaveJS → Mqtt2 → Borker distant est bien toujours ZWAVE_GATEWAY-Jeedom, et si c’ets le cas, est-ce modifiable

Coté topic, je pense que les brokers gèrent très bien les mises à jour de même topics de différentes sources/clients, il ne doit pas y avoir de conflits de ce coté là

Norbert

[Loic]

Bonjour
Pour zwavejs je sais pas mais pour jeedom il y a bien de l’aléatoire dans le client id plugin-mqtt2/resources/mqtt2d/mqtt2d.js at beta · jeedom/plugin-mqtt2 · GitHub

[Mips]

@ngrataloup

ZWAVE_GATEWAY-Jeedom

C’est ce que je dis, c’est pas le clientid ca d’après moi

@ngrataloup

brokers gèrent très bien les mises à jour de même topics de différentes sources/clients, il ne doit pas y avoir de conflits de ce coté

Oui le problème n’est pas le broker ou mqtt mais 2 instances de zwavejs avec deux contrôleurs différents qui recoivent des infos sur tous les équipements donc aussi ceux qui ne leur sont pas liés.
Potentiellement avec des nodeid identique car 2 réseau zwave ; ca va etre la le conflit

[Ds5]

Bonjour et merci à ceux qui ont formulé qques éléments de réponses.
Je confirme ce que réexpliquait @ngrataloup : mon souci est bien dans le nom/identifiant du client qui se connecte à mqtt avec un user/passe que j’ai spécifié. Si je vous mets les logs de mosquitto je vois ceci, sachant que mes deux serveurs sont en IP .36 (le 1er qui a fonctionné impec tout seul) et .37 (le second qui était ko et rendait ko le 1er tant que j’attaquais le même broker) :

1719931511: Client ZWAVE_GATEWAY-Jeedom already connected, closing old connection.
1719931511: New client connected from 192.168.1.37:35034 as ZWAVE_GATEWAY-Jeedom (p2, c1, k60, u'xxxxxxxxxx').
1719931512: New connection from 192.168.1.36:41380 on port 1883.
1719931512: Client ZWAVE_GATEWAY-Jeedom already connected, closing old connection.
1719931512: New client connected from 192.168.1.36:41380 as ZWAVE_GATEWAY-Jeedom (p2, c1, k60, u'pierrexxxxxx').
1719931513: New connection from 192.168.1.37:35036 on port 1883.
1719931513: Client ZWAVE_GATEWAY-Jeedom already connected, closing old connection.
1719931513: New client connected from 192.168.1.37:35036 as ZWAVE_GATEWAY-Jeedom (p2, c1, k60, u'pierrexxxxxx').
1719931514: New connection from 192.168.1.36:41386 on port 1883.
1719931514: Client ZWAVE_GATEWAY-Jeedom already connected, closing old connection.
1719931514: New client connected from 192.168.1.36:41386 as ZWAVE_GATEWAY-Jeedom (p2, c1, k60, u'pierrexxxxx').
1719931515: New connection from 192.168.1.37:35038 on port 1883.

Le souci que je voyais c’était le même identifiant « as ZWAVE_GATEWAY-Jeedom » venant un coup du serveur en .36 et un coup de celui en .37 et entre les deux, « connexion existe serveur 1 », donc « connexion fermée serveur 1 » puis « réouverte serveur 2 » et ensuite l’inverse

edit : je n’ai pas conservé des logs ko du démon zwavejsd mais c’était de ce type là :
"Error: write EPIPE\n at WriteWrap.afterWrite [as oncomplete] (net.js:788:14)"
donc en gros le démon ne parvient pas à écrire dans mon interprétation ce qui est logique si sa connexion est sans cesse cassée par l’autre serveur

pour @echo : concernant les user/passe de connexion à mosquitto sur mon NAS, j’ai mis partout les mêmes et cela ne posait pas prb lorsque jMqtt et le 1er ZWave JS tournaient ensemble. C’est aussi ces login passe que je prends pour regarder les topics avec mqtt-explorer depuis mon PC et la encore ca ne casse rien.

pour @Tonio16 : je n’ai pas mis de client Id distinct entre mes deux serveurs car justement je ne vois pas comment faire cela dans la config des plugin (mqtt visiblement en génère un tout seul unique, zwave js ne propose rien a ce niveau mais le constat c’est que à l’arrivée celui que je vois passer en log n’est pas unique comme si zwave Js imposait le sien)

pour @Mips au niveau des topic, mon serveur 1 a dans la config ZwaveJS « zwaveJeeS2 » et le deuxième « zwaveJeeS3 » => en regardant avec mqtt explorer j’avais bien vu les deux sujets, et donc pas de conflit car deux modules avec l’id 2 par ex dans mes deux réseaux zwave arrivaient bien dans des sujets différents

au global et question terminologie, ce que je vois en XXX dans le log mosquitto derrière « IP:port as XXXX », c’est quoi ? un client Id ? autre ? c’est en tout cas ce qui m’apparait poser problème

Désolé si j’emploie de manière inapproprié le mauvais terme mqtt

Je peux tjs mettre des captures écrans de mes configs mais j’ai modifié peu de champ :

• dans mqtt Manager j’ai juste choisi « Broker distant » / renseigné le user/passe que je prends pour me connecter avec mqtt explorer, jmqtt / le reste est en valeur défaut y compris le topic racine « jeedom » (car je n’ai pas compris dans le cas de swave JS q’il était utilisé puisqu’il n’appairait nulle par dans mqtt explorer si je regarde ce qui est posté sur mon broker mosquitto central / je n’ai pas coché « Transmettre tous les evts » car hormis Zwave je n’utilise pas mqtt pour le reste (j’ai compris que cette option servait à cela et n’était pas utile pour ZWAVE JS)
• dans Zwave JS, idem très peu de modif , uniquement le prefix MQTT

@Mips pourquoi dis tu que les instances ZWavejs vont recevoir des infos sur tous les équipements ? Si chaque zwave s’est abonné au topic zwave1 pour le premeir et zwave2 pour le second, moi je me disais que chacun n’allait recevoir des infos que sur son sujet non ? si j’ai une info pour un module nodeid=1 sur topic zwave1, le serveur 2 abonné à zwave2 ne va rien recevoir donc pas de conflit ?

[ngrataloup]

@Ds5

au global et question terminologie, ce que je vois en XXX dans le log mosquitto derrière « IP:port as XXXX », c’est quoi ? un client Id ? autre ? c’est en tout cas ce qui m’apparait poser problème

C’est bien ca, le XXX est le clientID et il doit etre UNIQUE. Le symptome est exactement ce que tu décris, deconnexion du serveur 1 pour reconnexion au serveur 2 puis reconnexioin du server 1, …

[ngrataloup]

et pour aller plus loin, dans la doc zwaveJS, il « semble » (pas très clair) que le clientID utilisé soit ZWAVE_GATEWAY-<mqtt_name>
Question … ou se trouve ce mqtt_name
Si on continue dans la doc : Z-Wave JS UI
…peut-etre voir si en modifiant le champ name de la section MQTT, ca ne modifie pas le clientID, d’autant qu’il est indiqué :

MQTT
Name: A unique name that identifies the Gateway.

ce qui revient à avoir un clientID unique

Si tu as accès à Z-Wave JS UI pour tester la modif …

[Ds5]

ah bien vu @ngrataloup pas pensé à aller voir la doc directement de ZWave UI d’autant que par défaut ce n’est pas forcément indiqué d’aller modifier des choses ici. De ce que je vois dans la section MQTT cela correspond parfaitement à ce qui est vu dans les logs. Voici en effet ce que j’ai pour mon premier seveur (qui se nomme JeeS2) :

En changeant le Name en JeedomServ1 par exemple je devrais générer des noms de client mqtt différents sur mes deux serveurs. Je viens de changer celui du premier serveur, et après relance des démons ca a l’air ok si je ping mes modules et je ne vois pas apparaitre d’erreur en log démon zwavejs. Je vais aller vérifier dans les logs mosquito si on voit bien apparaitre le changement. Si c’est ok je testerai alors la manipulation sur le second serveur que je rebasculerai sur le broker distant central.

[Ds5]

Je me réponds à moi même : en allant modifier la config ZwaveUI dans Mqtt name et en mettant JeedomSrv1 par exemple je vois bien dans le log le nom changer et passer à ZWAVE_GATEWAY-JeedomSrv1. En revanche j’ai ensuite relancé le démon et cela s’est remis à la valeur initiale.

En regardant dans le code de « zwavejs.class.php » je vois à la ligne 153 :

  $settings['mqtt']['name'] = 'Jeedom';

donc ce paramètre est bien à cette valeur sans possibilité de la modifier via la config. Pour voir si je règle mon conflit entre les deux serveurs, il faudrait donc que je modifie cela je pense sur chacun des serveurs en commençant par vérifier que si je fais cela sur le 1er, je vois bien la valeur rester si relance démon et que cela n’altère pas le fonctionnement Zwave. Si c’est bon je pourrai alors tester sur le second serveur que je remettrai sur le broker central

[Ds5]

Bonjour. J’ai finalement testé la configuration suivante :

• modification sur chaque serveur du name Jeedom par JeedomSrv1 en lignes 153 et 897 dans « zwavejs.class.php » :

$settings['mqtt']['name'] = 'JeedomServ1';
et
mqtt2::publish(config::byKey('prefix', _CLASS* , 'zwave') . '/_CLIENTS/ZWAVE_GATEWAY-JeedomServ1/api/' . $_api_name . '/set', $_args);

• bascule à nouveau sur le broker distant du second jeedom donc le mosquitto central sur mon NAS
• relance des deux démons ZwaveJS

Je n’ai pas l’erreur EPIPE du début, les infos remontent correctement sur les deux jeedom et les logs mosquitto ne mentionnent plus de déconnexion/connexion en alternance depuis chaque serveur. La valeur dans le name mqtt forcée unique me permet donc de m’en sortir.

je ne sais pas trop vers qui renvoyer la remarque sur le plugin zwavejs et si le fait de rendre paramétrable ce champ name serait une bonne idée. Pour moi oui en tout cas car à chaque maj plugin je devrais modifier.

merci à @ngrataloup de m’avoir mis sur la piste du name!