Bonjour, une fois de plus, le switch « chaufferie-bruleur » qui aurait dû se mettre sur « on » à 05h00 ce matin n’a rien fait. Pourtant dans les log du scénario « Horloge bruleur hiver », il s’est bien exécuté. Je suspecte le couple JeeZibee et MQTTManager de me faire des soucis. En particulier le dernier.
J’ai aussi souvent besoin, pour activer l’alarme, d’appuyer plusieurs fois sur le bouton des zappettes qui fonctionnent aussi en Zigbee (p.ex. « Zapette001 »).
Pouvez-vous m’indiquer les points à vérifier, en particulier dans ces deux plugins.
1’000 mercis.
Informations Jeedom Luna
Core : 4.4.19 (master)
DNS Jeedom Luna : oui
Plugin : MQTT Manager
Version : 2024-11-26 01:20:08 (stable)
Statut Démon : Démarré - (2024-12-26 17:25:12)
Salut
Page santé jeedom et les logs des deux plugins quand il y a un souci.
Mais si chaufferie, j’imagine que ce module est un peu isolé/loin et peut-être entouré de parties métalliques.
J’ai mis en place un scénario qui redémarre la Luna chaque matin à 05h05 et le souci s’est envolé. Mais ce n’est pas la bonne méthode, c’est cacher la m… au chat.
Du coup j’ai neutralisé ce scénario de redémarrage et la prochaine fois que je me réveille au froid, je pioche les logs.
Pour la liaison, c’est vrai, il y a plein de ferraille partout, mais le LQI est de 156, car il y a 5 mètres à vol d’oiseau (à travers une dalle et un mur) entre le module Nodon et la Luna.
Ca y est, la commande à 21h30 pour stopper le switch « chaufferie-bruleur » a été simplement zappée. Le log du z2md présente un retard dans le timestamp de 1heure (bizarre?). Donc recherche de ce qui se passe vers 20h30 dans le log, mais je ne vois rien. Je te charge le log. Le module en question a l’adresse « 0x6c5cb1fffe8742cd ».
…je rencontre souvent ce soucis avec mes têtes thermostatiques.
Soit l’instruction d’un scénario ne passe pas. Soit parfois je dois cliquer deux fois pour faire exécuter une modification de consigne (ou autres) .
j’ai éliminés les pistes suivantes :
les têtes, car ce ne sont jamais les mêmes et j’ai différentes marques
la qualités des liaisons, car même celles qui sont à proximité présente ces anomalies
les scénarios : car ils sont bien executé d’après les logs
les clics car j’ai bien l’instruction qui part dans les logs
Par ailleurs j’ai deux box, une Luna en Z2m/ESZP et une Atlas en Zigbelinker/ConbeeII
=> Aucun problème sur l’Atlas. Et les rares fois une un device n’accuse pas réception de 'l’instruction j’ai une notification dans le centre ad hoc. Ce qui n’est pas le cas dans Z2m…
Donc il me reste deux pistes :
La Luna/ESZP qui presente quelques dysfonctionnement
Z2m qui fait des siennes
=> je vais basculer en Zigbeelinker d’ici demain pour voir
mes solutions temporaires :
redémarrer le demon de Z2m et/ou si cela n’as pas suffit redémarrer Zigbee2mqtt
fréquence presque tous les jours
je partage ton point de vue.
Mais ce qui me gène avec Z2m ce sont l’absences de retour. C’est à dire de messages lorsque l’instructions n’est pas délivré ou exécuté…
donc juste une migration, si j’y arrive sans avoir à réappareillé) vers zigbeelinker pour voir …
Ça ne répond pas au fond du problème mais pour ces cas qui peuvent arriver je conseille d’ajouter dna sle scénario une boucle de contrôle (ou dans un autre scénario qui tourne à côté) : « tant que l’état a pas changé de valeur relancer la commande de changement d’état dans 10s » (+notif si toujours pas fait au bout de x tentatives)
, donc retour sur Z2m avec la sauvegarde