Dysfonctionnement récurant plugin jMQTT

Plugins Protocole domotique
1

Bonjour à tous les jeedomiens

Mon installation : Rpi3 + SSD
avec RFLink, z-Wave, jMQTT et mySensors

J’ai un dysfonctionnement récurant de mon plugin jMQTT.
J’utilisait le plugin MQTT que j’ai remplacé par jMQTT dont on disait le plus grand bien pour la reconnaissance automatique des équipements.
Mal m’en a pris. Le plugin jMQTT se bloque systématiquement toutes les nuits vers 2h00.
N’ayant rien trouvé ni dans la documentation ni sur les fils de discussion de ce plugin, je me permets de vous soumettre mon problème.

Voici mes observations
dans le log jMQTT_deamon

En permanence toutes les 10 secondes

> [2021-10-17 19:01:50,782][ERROR]    : BrkId:  364 : Unexpected disconnection from broker!
> [2021-10-17 19:02:00,795][ERROR]    : BrkId:  364 : Unexpected disconnection from broker!
> [2021-10-17 19:02:10,809][ERROR]    : BrkId:  364 : Unexpected disconnection from broker!

Dans le log jMQTT

environ une quarantaine de fois / seconde

[2021-10-17 08:02:06]: on_mqtt_connect raised an Exception : Pas d'équipement avec l'id fourni (id=364)

et toutes les 10 secondes environ

> [2021-10-17 08:02:01]: on_mqtt_disconnect raised an Exception : Pas d'équipement avec l'id fourni (id=364)

Au niveau de la base de données

Dans la table eqLogis

> id	     name	logicalId	object_id	eqType_name	configuration
> 364   local                    null	         jMQTT	        {"type":"broker","createtime":"2021-10-16 18:11:46"}	0	1	null	null	[]	[]	9999	null	null	null

Dans la table configuration

id	name	configuration
364	local	{"type":"broker","createtime":"2021-10-16 18:11:46"}

Dans la table cmd la commande
SELECT * FROM cmd WHERE id=364
ne retourne aucune donnée

l’id 364 correspond au client broker MQTT avec la commande info status ayant comme topic jeedom/status
l’information status « Client MQTT » passent toutes les 5 secondes de OK à POK et inversement.

Capture-jMQTT
Capture-jMQTT756×144 8.68 KB

Je pense que la cause du dysfonctionnement pourrait se trouver là mais je ne suis pas parvenu à résoudre le problème.
J’ai désinstallé complètement le plugin jMQTT et perdu au passage tous mes équipements que j’ai du reparamétrer après leur inclusion automatique.
Le résultat est que le plugin se bloque toujours régulièrement toutes les nuits vers 2h00. Le plugin apparaît comme actif mais ne fonctionne pas. Je dois activer le bouton redémarrer pour que tout reparte.

Merci de vos lumières.

2

Bonjour, dans l’équipement du broker
onglet broker
Identifiant/ClientId
celuici doit être unique et different de tout autre

si 2 machine accède avec le même identifiant cela fait des déconnexions.

si tu n’est pas sur met jeedom123xyz de dans par exemple

1 « J'aime »
3

Bingo !
Merci beaucoup à toi Olive pour cette réponse rapide et efficace :+1: :smile:
Ça semble fonctionner parfaitement maintenant. J’attend la nuit prochaine pour confirmer la solution et vous informe dès demain du résultat.
Je pense que l’équipement « jeedom » de l’ancien broker MQTT était resté inscrit quelque part et fichait le bazar.
Ça pourra être utile à d’autres.

1 « J'aime »
4

Déception ce matin :thinking:
Le problème n’est que partiellement résolu, il n’y a plus de coupure en journée mais le blocage de nuit persiste et les messages :
on_mqtt_message raised an Exception : Pas d'équipement avec l'id fourni (id=364)
sont toujours présents le matin dans le log jMQTT.
Le log jMQTT_deamon est vide.
Je pense que le dysfonctionnement doit être provoqué au moment de l’archivage automatique des données. Déversement de history dans history_Arch puis backup.

Par précaution j’ai changé au niveau du brocker :
nom par défaut de « local » en « localbroker’
le nom de la commande « status » en « status2 »
Au niveau de l’équipement jeedom :
le nom « jeedom » en « jeedom3 »
et le nom de la commande « status » en status3 »
image
Au niveau MQTT explorer j’ai ceci
image
Il apparaît toujours le topic « jeedom » malgré le fait d’avoir relancer le service mosquitto
La suite demain.

5

Vu que tu as le problème régulièrement, c’est interessant.
As-tu pu determiner à quelle heure et à quelle fréquence le problème se produit?
La difficulté pour debugger ce soucis, c’est la reproductibilité. Quand ne sait pas reproduire un problème, c’est difficile.

6

Merci Domochip
Depuis que j’ai applique les conseils d’Olive les déconnexions et reconnexion ont disparu. Par contre le blocage nocturne se produit toujours. La dernière information inscrite dans l’historique est horodatée à 2h00 toutes les nuits.
Comme expliqué précédemment je pense que le blocage est déclenché par les opérations automatiques (archivage et backup) mais que le blocage effectif se manifeste avec du retard (saturation du plugin ou autre phénomène)
J’ai un doute aussi sur le fait que le plugin MQTT était installé avant jMQTT et qu’il est possible d’avoir des informations de l’ancien plugin qui persistent et mettent le bazar.
Je reste en observation et vous informe dès que j’ai du nouveau.

7

Je tente une nouvelle manipulation dans la base de données avec l’outil adminer.
La table egLogic comporte bien un enregistrement portant l’id 364 mais le champ logicalid est vide.
J’ai donc modifié cet enregistrement en ajoutant l’information logicalid = « jeedom/# » comme ci-dessous

image
image1253×64 16.1 KB

Pour l’instant il n’y a aucune incidence sur le fonctionnement.
Résultat demain matin.

8

Quel type d’archivage et sauvegarde fais-tu?

9

Sauvegarde Backup automatique en local puis copie hebdomadaire manuelle sur un autre support.

Je suis toujours en recherche de solution à mon problème. J’ai installé un jedom test tout neuf sur une seconde plateforme. j’y ai ajouté le seul plugin jMQTT que j’ai paramétré pour utiliser le brocker Mosquitto de mon jeedom initial. Tout fonctionne comme une horloge Comtoise.
J’a comparé les différences dans les paramètres du broker et me suis aperçu que le champ Topic de la commande status était vide sur mon jeedom initial alors qu’elle est bien renseignée avec « jeedom/status » dans le jeedom test.
La modification directe depuis l’interface jeedom étant impossible, j’ai utilisé l’outil Adminer et pour modifier directement l’enregistrement correspondant avec le topic « jeedom123xyz/status » relevé dans MQTT Explorer.
Je crains que ce soit mon dernier atout avant désinstallation de jMQTT pour remettre le plugin initial MQTT.
Resultat demain matin.

10

Toujours pas d’amélioration. Demain je vais réinstaller le plugin MQTT, sans le mettre en mode inclusion, à coté de jMQTT pour voir ce qui se passe.

11

Bonjour @tautin25,

Le contenu du champ Topic de la commande « status » du Broker est directement lié au champ de configuration « Identifiant/ClientId » du Broker.
Dans le code, ce topic est toujours regénéré à partir de l’Id et non de la commande elle même.

Si tu as essayé de mettre « jeedom123xyz » comme « Identifiant/ClientId » sur ton Broker, et que le champ « status » ne se met pas à jour tout seul avec la valeur « jeedom123xyz/status ».
Alors c’est que ton équipement Broker jMQTT est « cassé », ça à pu se produire quand tu as changé la commande en status2/status3/etc ou fait des « manipulation dans la base de données ».
Désactive le Broker, crée en un nouveau (ne le clone pas), associe tous tes équipements à ce nouveau Broker et lance le. Tu dois retrouver le fonctionnement attendu.

Et tiens moi au courant :wink:
Bad

12

Merci de ton aide Bad
J’ai donc désactivé l’ancien broker « localbroker » et j’ai ajouté le nouveau « brockerlocal2 » que j’ai simplement activé. La commande « status » c’est ajoutée automatiquement ainsi que tous les équipements qui sont maintenant automatiquement connectés à ce nouveau broker.
Voir ci-dessous.
image
Résultat demain
Cordialement

13

Ce n’est pas normal que ton nouveau broker soit en Orange
Peux-tu vérifier qu’il est bien en vert et que c’était un pb d’affichage ?
Sinon nous donner des logs ?

Merci

14

En effet le log jMQTT_daemon comporte des erreurs répétitives

[2021-10-26 17:50:45,136][ERROR]    : BrkId:  372 : Unexpected disconnection from broker!
[2021-10-26 17:50:55,150][ERROR]    : BrkId:  372 : Unexpected disconnection from broker!
[2021-10-26 17:51:05,168][ERROR]    : BrkId:  372 : Unexpected disconnection from broker!
[2021-10-26 17:51:15,181][ERROR]    : BrkId:  372 : Unexpected disconnection from broker!

et passe du vert à lorange en alternance. Mes yeux légèrement daltoniens ditiguent difficilement la nuance sur une si petite surface :roll_eyes:
372 est l’ID du nouveau broker « brockerlocal2 »

1 « J'aime »
15

Tu peux vérifier que l’« Identifiant/ClientId » n’est pas utilisé ailleurs ?

16

trouvé valeur par défaut changée en jeedombis puis raz du log qui reste vide à présent avec le point coloré qui me semble vert en permanence :+1:
Il faut donc se méfier des informations renseignées en automatique en cas de dysfonctionnement.
J’attends un peu plus longtemps pour confirmation.
Ne serait il pas plus simple et plus voyant de changer toute la couleur de l’objet à la place de ce minuscule point de couleur ou de décaler les les 3 couleurs vert-orange-rouge à la manière d’un feu tricolore de signalisation. J’ai connu une personne qui disait à propos des feux tricolores « quand c’est allumé en haut, je m’arrête » :rofl:

17

Pas d’amélioration ce matin. Rien dans le log jMQTT_daemeon mais log jMQTT saturé.
Extrait avec les derniers messages au moment ou j’ai relancé le plugin

[2021-10-27 07:50:05]: on_mqtt_message raised an Exception : Pas d'équipement avec l'id fourni (id=372)
[2021-10-27 07:50:06]: on_mqtt_disconnect raised an Exception : Pas d'équipement avec l'id fourni (id=372)
[2021-10-27 07:50:06]: on_daemon_disconnect raised an Exception : Pas d'équipement avec l'id fourni (id=372)
[2021-10-27 07:50:07]: Erreur sur la fonction deamon_start du plugin : Vous devez attendre au moins 45 secondes entre deux lancements du démon. Dernier lancement : 2021-10-27 07:50:06

372 est l’id du nouveau broker « brokerlocal2 »

18

Hello @tautin25,

Tu confirmes que les messages que tu as en boucle à partir de ~2h, jusqu’au redémarrage du plugin, contiennent Pas d'équipement avec l'id fourni (id=372) ?

On en a discuté avec Domochip et on pense avoir une piste en rapport avec la BdD.
Quand tu parles de « Sauvegarde Backup automatique en local », tu utilises le système de backup par défaut de Jeedom ou une surcouche à toi ?
Sais-tu quelle taille fait la backup de la DB MySQL et combien de temps dure le backup de la BdD ?

Merci

19

Malheureusement la purge automatique du log jMQTT a supprimé les premiers messages. Je ne connais donc pas l’heure du premier et peut être d’autres qui ont précédé le blocage.
Dans la configuration systeme le nom maxi d’evenements est a 500 ce qui me donne un historique de 11 minutes. Il faudrait que je l’augmente 30000 ou que je mette le réveil à 2h du mat !!!
Quand je parle de backup j’utilise le backup par defaut de Jeedom. le fichier zip généré fait aujourd’hui 81.3Mo
Je viens de lancer manuellement une nouvelle sauvegarde qui a duré 1 minute.

20

Pas de plantage jMQTT suite à la backup manuelle ?