Statut hors ligne pour antennes distantes

Bonjour,

Ma configuration :
Jeedom (à jour) installé sur RPI4B avec Debian 11 bullseye
En remplacement du plugin BLEA (qui est désactivé actuellement) j’ai installé les plugins TGW et MQTT manager sachant que j’ai déjà par ailleurs aussi le plugin jMQTT qui fonctionne parfaitement avec Zigbee2MQTT et Z-Wave JS.
Mon serveur MQTTS est sous Mosquitto sur un INTEL-NUC déporté.


image

Coté MQTT Manager j’ai ceci :

Coté TGW j’ai ceci :

Une antenne locale TGW installée sur le RPI-Jeedom qui, elle, fonctionne parfaitement :


et elle remonte bien des données vues par MQTT Explorer :

Coté antennes distantes TGW : ce sont des RPI Zero W avec Debian 11 Bullseye (clean install) et uniquement une clé USB Bluetooth sur chacun d’eux et une connexion WiFi.
Elles sont toutes les trois configurées de la même façon (à l’@IP du RPI0 et de l’adaptateur, près !) tel que :


L’utilisateur « jeedom » de connexion est bien dans le groupe sudoers.

Mon problème :
Aucune des antennes distantes ne passent au statut « OnLine ». Je récupère systématiquement ce message d’erreur dans le log « tgw_xxxxx » :


qui d’une part se répète indéfiniment et qui d’autre part, semble indiquer un problème de connexion mqtt et de création de de socket. A moins que ce ne soit un problème Python, je ne saurai dire …
Nota : le log « tgw_xxxxx_update » lui, ne présente pas d’anomalies.

Du coup, je sèche … :cry:
J’en fais donc appel votre l’expertise pour SVP BV m’indiquer une solution à ce problème. En espérant que je vous aurai fourni assez d’éléments d’analyse.
D’avance MERCI de vos réponses avisées.
Cordialement
oracle7 :wink:

Bonjour,

Les logs dans un Texte préformaté c’est plus lisible et ca me permet de recopier le message d’erreur qui n’a pas été vu ou compris.


Juste au dessus de la ligne en erreur, selon moi cela veut dire que les pi ne savent pas résoudre INTEL-NUC et donc ils ne savent pas se connecter au broker mqtt

@Mips
Bonjour,
Merci pour votre réponse rapide.
Je remet les logs dans un bon format :

Log mqttd : vide

Log mqtt2d : après avoir remplacé dans la configuration de connexion au broker, le host INTEL-NUC par son @IP locale (bien le fichier /etc/hosts contienne par ailleurs une ligne de conversion/association d’@IP/HOST : 192.168.2.60 INTEL-NUC).
Donc avec la configuration au broker du type mqtt://192.168.2.60:1883, finalement les RPI des antennes externes se connectent bien maintenant au broker. Elles passent bien « EnLigne » et renvoient bien des données (confirmé avec MQTT Explorer).
Il reste toutefois un message bizarre « body-parser » dans le Log mqtt2d :

[2024-07-07 18:37:10] ERROR  : Reconnection to mqtt server
[2024-07-07 18:37:11] ERROR  : Reconnection to mqtt server
[2024-07-07 18:37:12] ERROR  : Reconnection to mqtt server
Sun, 07 Jul 2024 18:37:13 GMT body-parser deprecated undefined extended: provide extended option at jeedom/jeedom.js:168:31

Votre avis ?

Dans le cas de l’antenne locale qui dès le début de l’installation fonctionnait très bien (à la réflexion ce qui est étonnant ???) avec une connexion du type mqtts://INTEL-NUC:8883 (mqtt en mode sécurisé), je l’ai reconfiguée en mqtt://192.168.2.60:1883 et elle est aussi passée « EnLigne » :

Du coup, c’est bon aussi pour les antennes distantes, par exemple :

AU FINAL, mon problème venait de la configuration de la connexion au broker dans MQTT Manager.

Je ferais toutefois les remarques suivantes, qui mériteraient à mon sens une évolution du plugin MQTT Manager (avis au développeur, si vous pouviez SVP lui faire remonter l’information) :

  1. On devrait pouvoir spécifier un nom littéral pour le HOST en lieu et place de son @IP (bien évidemment pour cela il faut que la correspondance @IP - HOST soit aussi mentionnée dans le fichier /etc/hosts !!!).

  2. Il est étonnant que le plugin MQTT Manager de gère pas les connexions en mode mqtt sécurisé (mqtts) - même si le popup de configuration semble permettre cela - comme le fait par exemple le plugin jMQTT :

On devrait pouvoir saisir les informations de sécurité liées aux certificats SSL associés à ce mode sécurisé.
C’est à mon humble avis d’autant plus important lorsque le broker est installé sur un site distant, ceci afin de sécuriser la transmission de données de bout en bout. Maintenant ce que j’en dit …

Cordialement
oracle7 :wink:

Chez moi je travail avec les noms d’hôtes et pas les ip, tout fonctionne bien (autant avec mqtt2 qui n’est absolument pas le sujet, qu’avec theengsgateway) mais comme je disais il faut que la résolution de nom fonctionne mais c’est donc à vous de configurer cela comme il faut sur votre réseau.