Relance mqtt2 pour deblocage coommunication Zigbee

Bonjour a tous,

J’ouvre donc un nouveau post pour le probleme que je rencontre

J’ai une install Jeedom avec Zigbee avec pas mal d’equipements Zigbee qui fonctionne parfaitement chez moi.

Le but de ce post est d’expliquer ce qu’il se passe sur une install Jeedom que j’ai fait pour un ami. Meme distrib, meme version Jeedom, meme clé USB Jeedom (SONOFF), tout est quasi pareil puisque je me suis basé sur mon install que j’ai depuis de nombreuses années
La SEULE différence evidente entre les 2 install, c’est que je suis en electrique (donc fil pilote via module relai Zigbee) et lui est en chauffage au gaz (donc des tetes thermostatiques Zigbee)
On utilise les memes plugins et j’en ai meme un peu plus
Le fait est que dans son install, de facon « aleatoire », il n’y a plus de moyen de piloter ces tetes thermostatiques ce qui, ,comme tu peux l’imaginer, est plus genant surtout vu la température actuelle
mqtt2 et z2m etaient en Gestion Auto donc normalement devraient se relancer tout seul
Or ce n’etait pas le cas
A force de recherche et de tests, en arretant mqtt2 et en le relancant, j’ai reussi a contourner le probleme, et lorsque je detecte un probleme potentiel (ecart entre commande Jeedom et retour tetes), je relance ce mqqt2
Maintenant, je ne sais pas ce qu’il se passe vraiment, mais ca resoud le probleme
Pour info, dans un de mes posts ci dessous j’avais reussi a capturer une erreur juste avant le blocage

j’ai fait un scenario qui permet d’automatiser ce redemarrage de mqtt2
A priori, c’est bien cette erreur qui me plante, car le scenario redemarre le plugin 4 minutes apres un blocage potentiel

les tetes thermostatiques que nous utilisons :
image

Nous avons mis a jour OTA toutes les tetes dès que nous les avons branché (et non sans mal)

Des idées ?
Merci

infos complémentaire ici Creation automatique d'ID? :

Bonjour
Zigbee2mqtt n’est pas connecté à jeedom mais à la clef d’un coté et à mosquitto de l’autre. Le soucis n’est donc pas côté jeedom.

La relance de Mqtt2 par contre relance mosquitto et c’est sûrement ça qui corrige. Les log mosquitto ne sont pas dans jeedom il faut donc en ssh aller les chercher et voir si le soucis vient bien de lui et pourquoi.

Re @Loic

Peux tu me donner le chemin d’acces pour les logs mosquitto ? ou ca se trouve facilement sur Internet ?
Je vais voir pour les recuperer et regarder ca

Là comme ça je sais pas peut etre dans /var/log ou dans le service la faut regarder sur internet

@loic, @Bad

Malgré tout, le log que j’ai reussi a avoir montre un « timeout » qui est a l’origine de l’arret de la comm, et ce log je l’ai trouvé dans Jeedom

Peut il y avoir un lien avec Mosquitto a ce niveau ? Ca correspond ?
Cela peut vouloir dire que le service mosquitto s’est arrete ?
Quel est l’origine de ce « timeout » ?

Quand je vais detecter un blocage de comm, j’irai voir l’etat de ce service Mosquitto pour verifier l’hypothese

Comme dit c’est soit avec la clef soit avec Mqtt vu que la log est pas complète pas moyen d’en dire plus

Le firmware de ta clé est-il à jour ?
As-tu mis en place les quelques précos habituelles (rallonge USB, alim externe avec un hub usb) ?

Norbert

Bonjour,

Dans la configuration du plugin mqtt2,
ajouter les lignes suivantes dans Paramètres Mosquitto :

log_dest file /var/log/mosquitto/mosquitto.log
log_type debug
log_timestamp true
log_timestamp_format %Y-%m-%dT%H:%M:%S

Cliquer « Sauvegarder » puis cliquer « Installer Mosquitto »
(prend en compte les modifications dans /var/www/html/plugins/mqtt2/data/mosquitto.conf).

pour voir l’état du service mosquitto,

Aller dans :
Réglages > Système > Configuration > OS/DB > Administration système > Ouvrir
taper commande :

sudo systemctl status mosquitto

* mosquitto.service - Mosquitto MQTT Broker
     Loaded: loaded (/lib/systemd/system/mosquitto.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2024-01-10 23:25:06 CET; 4min 52s ago
       Docs: man:mosquitto.conf(5)
             man:mosquitto(8)
    Process: 244635 ExecStartPre=/bin/mkdir -m 740 -p /var/log/mosquitto (code=exited, status=0/SUCCESS)
    Process: 244637 ExecStartPre=/bin/chown mosquitto /var/log/mosquitto (code=exited, status=0/SUCCESS)
    Process: 244638 ExecStartPre=/bin/mkdir -m 740 -p /run/mosquitto (code=exited, status=0/SUCCESS)
    Process: 244639 ExecStartPre=/bin/chown mosquitto /run/mosquitto (code=exited, status=0/SUCCESS)
   Main PID: 244640 (mosquitto)
      Tasks: 1 (limit: 4462)
     Memory: 1.2M
        CPU: 265ms
     CGroup: /system.slice/mosquitto.service
             `-244640 /usr/sbin/mosquitto -c /var/www/html/plugins/mqtt2/core/class/../../data/mosquitto.conf

Jan 10 23:25:06 rockpi-4b systemd[1]: Starting Mosquitto MQTT Broker...
Jan 10 23:25:06 rockpi-4b systemd[1]: Started Mosquitto MQTT Broker.

akenad :slight_smile:

Bjr @akenad

Super. Merci. Je n’avais meme pas remarqué que c’etait le fichier de conf de mosquitto qui s’affichait :slight_smile:
Je fais tout ca et je reviens vers vous avec les data

Merci

@ngrataloup, oui le firmware est a jour. Mise a jour via Jeedom . Meme clé meme version que mon Jeedom perso
La clé USB est directement raccordée sur un des ports USB du PC. Pour rappel/info, l’install etait avant sur RPi et nous avions le meme souci
La clé USB de mon install est aussi directement sur un des ports USB du PC et aucun souci (meme clé)
Pour les rallonges USB, je ne suis pas fan. Travaillant dans l’informatique industrielle, j’ai tellement eu de souci avec ces rallonges que je ne prefere pas en mettre.
Maintenant mettre un HUB USB alimenté , c’est a essayer pourquoi pas
Merci en tout cas du retour

Peut être que la clef zigbee a un défaut tout simplement

Peut etre aussi, pourquoi pas

Si on change la clé, il n’est pas necessaire de tout reappairer ?

Ca dépend j’ai jamais vraiment tester mais c’est une chance sur deux je dirais. Si tu changes de modele marque c’est sur que oui sinon ya une chance qu’au démarrage la clef accepte de le faire (si le fabricant a bien prévu ce cas).

Aie !!!
Vu les problemes que nous avons eu, nous avons commence par le plugin Zigbee, puis JeeZigbee, puis de nouveau Zigbee car ca ne fonctionnait pas top avec Zigbee, puis de nouveau JeeZigbee
Tout ca sur l’ancien matos, avant de changer l unite centrale
Et a chaque fois on a tout reappairé !! Ca commence a faire :frowning:
On va y reflechir alors :slight_smile:

Ce qui est sur : plugin jeezigbee, le plugin zigbee est mort. Pour le reapairage oui c’est penible malheureusement c’est le protocole qui veut ca.

Attention il ne faut surtout pas que le plugin zigbee tourne quand tu lances le plugin jeezigbee.

Non non tkt. Le module Zigbee est maintenant desinstallé

Ca tourne pas trop mal avec JeeZigbee malgré les quelques redemarrages de temps en temps, et avec le scenario de relance, et malgré les ID qui s’incrementent , ca tourne bien le reste du temps
Ca le fait tout de meme :slight_smile:

Faudrait tester la beta pour les commandes qui s’incremente si ca ne resoud pas le soucis je continuerais de creuser.

Oui oui je vais tester ca

Bjr @Loic, si j’ai bien compris, il y a tout de meme des risques a passer en BETA ?
Je viens d’en discuter avec la personne qui a ce Jeedom, et il n’est pas très chaud , surtout en ce moment qu’il fait bien froid

Issu du site Jeedom :
Attention Le downgrade de version est totalement déconseillé et peut rendre Jeedom totalement inopérant. Par exemple, updater de Beta v4.2 vers Stable v4.1 ne doit pas être fait ! Dans ce cas, la meilleure solution est d’attendre la future version Stable de l’actuelle Beta, puis remettre la configuration de Jeedom en version Stable, et faire une mise à jour manuelle. De même un backup d’une version ultérieure ne doit pas être restauré sur une version antérieure (par exemple backup 4.2 sur Core 4.1).

Si c’est ca, on attendra la version stable pour tester
Dsl

Bonjour,
Je sais pas quoi te dire, si ca s’appelle beta c’est pas pour rien si c’était sans risque alors ca sera une version stable pas beta…