Je ne reçois plus automatiquement les retours d’état du bus KNX dans Jeedom, et ce depuis le 17/01/2026 en soirée. Un redémarrage du Démon le 17/01 en soirée a résolu le problème pour +/- 24Hr. Ce soir, le 18/01, le même phénomène se produit:
je peux actionner des participants du bus KNX (lampes, prises commandées, portail, etc) depuis Jeedom ou Jeedom Connect mais l’état n’est pas actualisé: la lumière s’allume et s’éteint correctement mais l’icône liée à l’état ne change pas.
Lorsque, dans l’équipement KNX configuré dans Jeedom, je clique sur le bouton « read » associé à la commande « état » de ma lampe, l’icône est mise à jour dans Jeedom et Jeedom Connect. Je joins la config de mon équipement KNX pour la lumière de l’îlot de cuisine à titre d’exemple.
Lorsque j’actionne un interrupteur physique de mon bus KNX, la lumière s’allume et s’éteint normalement et la LED de l’interrupteur s’allume et s’éteint aussi, signe que les télégrammes d’action et d’état sont bien générés dans KNS (et confirmés par ETS).
De même, lorsque des interrupteurs KNX entraînent des actions dans Jeedom, les télégrammes générés dans KNX et visibles dans ETS ne traversent pas l’interface vers Jeedom sauf en cas de lecture forcée depuis Jeedom
Mes configurations Jeedom et KNX sont inchangées depuis des mois et je n’effectue dans Jeedom que les màj proposées par le système. Les dernières en dates sont le core en 4.5.2 le 12/01 et EIB à la même date.
Je joins également une copie d’écran de ma config EIB et d’un extrait du log du Démon.
Face à ce problème, j’ai pour la première fois ouvert le moniteur de bus: je n’y vois aucun trafic alors que mes commandent passent correctement de Jeedom à KNX, et que les « read » exécutés dans Jeedom reçoivent bien les valeurs d’état transmis par KNX.
On verra pour combien de temps.
RAS du côté KNX, le bus se porte bien et l’analyse du moniteur de bus ne montre rien de particulier.
Tout conseil reste évidemment le bienvenu si quelque chose cloche dans ma config…
Bonne journée à toues et tous,
Marc
Mise à jour du 19/01 à 17h30:
A nouveau plus de communication de KNX vers Jeedom. L’autre direction fonctionne correctement. J’ai redémarré la box, le switch et Jeedom, et tout fonctionne de nouveau. J’ai activé le log en debug. A ce sujet, je ne sais pas quoi faire du heartbeat et de l’option redémarrer le Démon, je n’ai rien trouvé dans la Doc alors je n’ai pas touché.
J’ai exactement le même soucis et les mêmes symptomes. Pour ma part, c’est arrivé suite à la mise à jour du plugin EIB - KNX.
D’autres personnes affectées?
Bonsoir et merci pour votre réponse.
Je ne suis pas sûr de comprendre le problème de la trame vide.
J’ai redémarré Jeedom, ma box et mon switch aujourdh’ui après-midi et tout tourne depuis quelques heures maintenant. J’ai donc un log du démon « fonctionnel » (capture d’écran, c’est trop « volatile » pour un copier/coller), de même que le log debug EIBD:
Après redémarrage, j’ai désactivé le filtre serveur et la visibilité du serveur dans la config avancée du démon car ces options ne semblaient pas utiles dans mon cas.
Lorsque je reperdrai la connection KNX → Jeedom, je tâcherai d’extraire le log du démon et les dernières lignes du debug EIBD.
Même problème qui est apparu avec la dernière mise à jour 2026-01-09. En attendant une résolution, j’ai configuré le heartbeat à 5min et cocher la case redémarrer le démon pour éviter de figer l’installation. Chez moi lors du problème, les valeurs depuis KNX ne remontent plus mais l’envoie des commandes depuis jeedom restent fonctionnelles.
J’ai essayé de capturer des logs du problème mais j’ai rien vu de très parlant. eibd.txt (3,9 Mo)
je ne maîtrise pas vraiment les fonctions heartbeat et redémarrage du daemon. Je ne les ai pas (encore) cochées car, à mon sens,
le hearbeat envoie un keepalive plutôt qu’il n’écoute s’il y a du trafic; or, le trafic passe bien de Jeedom vers KNX et les reads Jeedom sont acquittés par KNX et les heartbeats risquent donc d’être acquittés. Je ne sais donc pas si le heartbeat détectera que l’interface ne fonctionne plus que dans 1 sens.
Concernant le redémarrage, il me semble que le statut du daemon était encore sur OK lorsque j’avais des problèmes. Je ne suis pas sûr que le daemon fera un autodémarrage si son statut ne passe pas à NOK.
Depuis mon dernier reboot de la box, du switch et de Jeedom hier à 17h39, EIBD tourne sans problème pour plus de 24 heures…
Dans tous les cas, je suis très intéressé par le résultat de vos tests!
Je ne sais pas dire ce qui bloque malheureusement, des fois le démon tient 1 jour, des fois plusieurs heures, des fois 15min. J’ai le sentiment que c’est assez aléatoire et je n’ai pas l’impression que c’est un évènement spécifique qui le bloque.
Le hearthbeat de jeedom vérifie que pour tous les équipements du plugin pour lequel il est activé, il y a bien une date de dernière communication inférieure au délai paramétré.
Merci pour vos contributions, j’ai appris pas mal de choses!
En ce qui me concerne, un redémarrage de Jeedom a amélioré la situation: plus de plantage depuis le 19 janvier. Les plantages m’ont également poussé à me pencher sur tous les paramètres de configuration KNX, que j’ai adaptés de la sorte en fonction de ma propre topologie:
j’ai décoché toutes les options « mise à jour » et « initialiser » dans mes objets KNX, et j’ai désactivé toutes les lectures cycliques (sauf pour mon portail)
j’ai désactivé le filtrage serveur, la visibilité du serveur et le routing dans la config avancée du démon
Un autre point que je ne comprends pas. Dans le moniteur de bus, je vois une suite de READ toutes les 2 minutes vers une partie de mes équipements, principalement des lumières et un volet: Bus_Mon.txt (1,2 Ko)
Or, ces READ n’apparaissent pas dans le Log EIBD (alors que ma lecture cyclique vers mon portail s’y trouve): EIBD_Log.txt (835 Octets)
Une idée?
J’ai configuré un « Délai max entre 2 messages » sur la mesure de puissance EDF, suite au post d’Aurel. Concernant le statut du démon lors des plantages: mon premier réflexe a été de jeter une bille sur le panneau de config du plugin et un NOK m’aurait sûrement frappé mais je me trompe peut-être.
@ wesker68 et AlexDms: tenez-moi au courant de vos solutions ou trouvailles!
Nouveau plantage.
Pour Aurel, je confirme que le statut du Daemon est toujours au vert. D’ailleurs, le log semble tourner normalement alors que je n’ai plus aucun retour de KNX vers Jeedom, sauf pour les réponses à mes reads.
Pourquoi? Les images donnent souvent des logs tronqués, impossible de cherche le texte d’une image, parfois elles sont illisible.
Fichiers: beaucoup ne les ouvrent pas, pas de recherche, formatage moche sans intervention supplémentaire.
Super pour le tuto mais mon log EIBD faisait 5 gigaoctets et jeedom ne l’affichait plus. Le seul moyen pour moins d’en extraire « le moment du plantage » comme demandé est de l’ouvrir dans un éditeur externe (notepad++) qui ne fait malheureusement pas de belle mise en page. Au fait, pourquoi 5 Giga? parce que le log se rempli de milliers de lignes par seconde lorsque EIBD plante… D’ailleurs, après le redémarrage d’hier soir, j’ai un log de 10giga sur moins de 10 heures en magasin dont j’extrairai les lignes importantes (combien?) dès que j’aurai une heure devant moi…
De même le log du Daemon est tellement volatile que le copier-coller ne fonctionne pas: le texte sélectionné a changé et est désélectionné avant d’avoir eu le temps de cliquer sur Ctrl-C. Mais je prends évidemment bonne note de tout cela et compte vraiment m’appliquer dans l’avenir car les . Voici ce que Copilot a pu lire en accédant à la page, je ne crois pas pouvoir faire beaucoup mieux.
Je confirme encore une fois que, pour le daemon et malgré le plantage KNX → Jeedom, le statut et la config sont OK dans le panneau de config.
En attendant, je redémarre Jeedom.
Nouveau plantage.
Ce qui marche: programmer un timeout dans un objet KNX qui transmet souvent (dans mon cas la puissance EDF consommée par ma maison) afin de générer un message si c’est configuré dans l’onglet Logs/action sur alertes. C’est ce qui m’a averti du problème.
on peut le faire comme ça:
Cela a certainement une utilité mais pas dans le cas qui nous occupe car le démon reste OK malgré le problème.
Voici le log EIDB complet: la panne est survenue à 22:16:00 (ligne 292). Après cela, l’interface génère environ 10.000 (dix mille) lignes de log par seconde complète (soit à partir de 22:16:01): 260124_debug.txt (504,4 Ko)
Pas étonnant que les logs de quelques heures dépassent le giga…
Si d’autres que moi ont ce problème, qu’ils se manifestent. Sinon, je compte simplement reclaquer une image de la VM prise à une date antérieure à la MàJ du plugin.
Comme je l’indiquais dans mon précédent message l’objectif n’est pas de regarder si le daemon est lancé mais de vérifier si il met a jour des équipements jeedom.
Par exemple avec un seuil de 15 minutes, jeedom va vérifier la date de dernière communication de tous les équipements de ce plugin et vérifier qu’au moins l’un d’entre eux a bien communiqué ces 15 dernières minutes.
Il aurait donc été intéressant de voir si dans ton dernier cas la date de dernière communication avait été mise a jour ou pas …
Je pense qu’une valeur a 2 minutes est trop faible pour être efficace
Les données que mes équipements KNX ne génèrent pas automatiquement sont pollées depuis jeedom à un cycle de 1min (le portail et la porte sectionnelle du garage, pour des raisons de sécurité) ou 5 min (les valeurs d’énergie consommée). En me basant sur les mesures de puissance, je considérais que 2 minutes sans télégrammes était déjà signe d’un souci. Je suis ton conseil et passe à 15min mais je coupe le log (15min = 900min = 9.000.000 lignes de log avant un potentiel redémarrage du daemon).
Je te tiens au courant!
Nouvelle info sur le comportement du plugin planté (bon, ça ne casse pas 3 pattes à un canard, mais soit): Voir les logs ETS et Jeedom ci-dessous.
A 0750Hr, avec le plugin planté, j’ai cliqué 4 fois sur la tuile de la lumière de l’îlot de cuisine dans mon dashboard. La lumière s’allume au premier clic mais la tuile ne passe pas à « lumière allumée ». Logiquement, KNX répond par un retour d’état à la première commande mais ce retour n’arrive pas dans Jeedom. Par conséquent, mon objet « pense » que la lampe est toujours éteinte et continue à envoyer des ON à chaque clic pour essayer de l’allumer. Pas moyen, donc, d’éteindre cette lumière depuis le dashbord. Le seul moyen de l’éteindre (à part bien sûr utiliser l’interrupteur mural…) est de « tester » la commande OFF dans l’objet. Je l’ai fait à 0751Hr avec le plugin planté et KNX à réagit en éteignant la lumière et en renvoyant le nouvel état OFF. Cela peut paraître futile mais si je suis loin de la maison et que j’actionne une commande depuis mon smartphone via Jeedom Connect alors que le plugin est planté, cette commande est irréversible. Log_Jeedom.txt (1,3 Ko) Log_ETS.txt (904 Octets)
Mes questions naïves restent donc - qu’est-ce qui plante le bus KNX? - pourquoi 10.000 lignes de log par seconde que la désactivation du Log EIBD n’arrête pas? - pourquoi exécuter une commande en cliquant sur une tuile du dashboard n’a pas le même effet que « tester » cette commande dans la config de l’objet?
Quelques remarques:
le heartbeat à 15min et l’option redémarrage n’ont aucun effet dans ce cas-ci
le niveau de Log EIBD configuré dans le plugin est « aucun ». pourtant, le log EIBD dépasse à nouveau les HUIT gigas en moins de 4 heures.
l’ouverture de la page Analyse/Logs puis l’ouverture du Log EIBD mettent chacun plusieurs minutes à s’ouvrir, soit à cause de la taille du Log EIBD, soit à cause de l’avalanche de 10.000 lignes de Log par seconde générée par EIBD. Je pense que cela deviendra problématique si je ne suis pas en mesure de redémarrer le plugin rapidement.
la fenêtre Log EIBD n’affiche rien (idem si on y accède depuis le plugin KNX). Probablement à cause de la taille, ce qui m’empêche de faire de jolis copier/coller.
le seul moyen de le traîter est de le télécharger et retrouver son chemin dans les millions de lignes générées.
Si je regarde maintenant le Log « Event », les commandes cycliques (1min et 5min) que j’ai configurées dans certains de mes objets sont exécutées par Jeedom et les réponses du bus KNX sont reçues normalement: les valeurs changent… Par contre, les commandes exécutées depuis les tuiles du dashboard ou Jeedom Connect n’ont jamais de retour d’état.
Je redémarre le plugin.
J’ai déjà testé le redémarrage du plugin, de Jeedom, de la box, du switch; la config du heartbeat; l’option redémarrage automatique; aucune de ces solutions n’est pérenne dans mon cas. Si je n’ai pas de nouvelles pistes à explorer avant l’apéro du soir, je compte claquer dans ma VM une image antérieure à la MàJ du plugin KNX.
Merci en tout cas pour vos contributions et bon dimanche
J’ai appliqué une modification sur la beta.
Dans le démon je surveille les erreurs de knxd qui doit permettre de s’assurer que l’on est bien connecté
A confirmer si cela ressoude vos problème
Bonjour,
Problème depuis mise a jour du 09/01/2026, faite ce matin.
Plus de retours d’info KNX, moniteur de bus ne fonctionne pas et plus de log.
Y a t’il possibilité de revenir sur la version précédente qui fonctionnait bien?
Merci
