Absence de retour d'état Read depuis mise à jour de fin aout 2026

[thomaspascal]

Bonjour à tous,

Je suis sur Jeedom 4.6.1 sur Debian 12.

Voilà mes paramètres du plugin:

J’utilise le plugin EIB - KNX (eibd) en version stable depuis de nombreuses années. Depuis la dernière mise à jour de fin aout, j’ai un problème, j’arrive à piloter mes équipements KNX depuis Jeedom, mais si je les commande depuis un équipement KNX, je n’ai plus de retour d’état sur Jeedom.

Quand je redémarre le plugin, je retrouve cela dans les logs de Jeedom, et cela concerne la plupart de mes équipements.

J’ai donc réinstallé les dépendances, et redémarrer le plugin, et retrouvé apriori mes retours d’état au bout d’un certain temps.

Mais avec un re-start du plugin, j’ai de nouveau une avalanche de ces messages et plus les retours d’état.

C’est encore trop tôt pour le confirmer, mais j’ai l’impression que je perds les lectures de temps en temps. Quelqu’un aurait une idée? Une piste de recherche?

Merci à vous

[thienell]

Bonsoir, décoche le filtre

[thomaspascal]

Bonjour,

J’ai décoché le paramètre “Filtre serveur KNX”, sauvegardé et (re)démarré le plugin, mais c’est pareil, toujours cette liste d’info dans les logs jeedom (27 dans mon cas), au rythme d’un toutes les 5 secondes. Par contre, j’ai l’impression que la réinstallation des dépendances que j’ai faite hier a réglé mon problème de retour d’état qui ne marchait plus.

A noter que j’ai toujours eu ces erreurs log read depuis l’origine de mon installation, il y a plusieurs années, mais je n’en avais que 3. Il semble en fait que celles que j’avais sont les 3 premières des 27 que j’ai maintenant. Qu’est-ce qui à changer dans la version pour avoir cela ?

[mika-nt28]

Peux tu mettre les logs en mode débug pour que ça cause un peu plus

Rien a changé sur le read donc très surpris

[thomaspascal]

Bonjour @mika-nt28,

Voilà le log en debug des premières minutes après un redémarrage du plugin. Pendant toute cette séquence, je n’ai aucun retour d’état de mes équipements.

Je pense finalement que le problème a peut-être toujours existé chez moi, mais qu’auparavant le plugin ne remontait que les 3 premiers Read : Aucune réponse. Depuis la mise à jour, il en remonte beaucoup plus.

Sais-tu ce qui a changé dans la sélection des commandes auxquelles le plugin applique un Read au démarrage ?

Finalement, la mise à jour a peut-être simplement mis en évidence un problème déjà présent sur mon installation, que j’avais jusqu’ici ignoré en pensant à un défaut de 3 équipements parmi la centaine que compte mon installation.

Aurais-tu une idée de ce qui pourrait provoquer ces erreurs chez moi et, surtout, l’absence de tout retour d’état pendant cette phase de démarrage ?

J’ai pensé un moment que cette phase d’initialisation était liée à l’option « Initialiser », que j’ai cochée sur la majorité de mes équipements, comme sur l’exemple ci-dessous.

Pour faire un essai, j’ai donc entrepris de décocher cette option sur ma centaine d’équipements, puis de redémarrer le plugin. Mal m’en a pris : le log s’est alors rempli de milliers d’erreurs de ce type :

[2026-09-24 00:33:00][DEBUG] [Moniteur Bus][Erreur] Type de data non pris en charge par le plugin (0.0.0 - 0/0/0)

J’ai obtenu un fichier de log de près de 500 Mo en moins de 5 minutes, au point de saturer mon Jeedom et de le rendre quasiment inexploitable. J’ai donc remis les options « Initialiser » comme elles étaient.

Autre constat qui est peut-être lié : mon switch a redémarré, ce qui a provoqué pendant quelques instants la perte de la liaison Ethernet avec mon interface KNX/IP.

Lorsque le réseau est revenu, je n’avais plus aucune remontée d’état KNX dans Jeedom, alors que la communication réseau était de nouveau opérationnelle. Les remontées n’ont repris qu’après avoir relancé le plugin.

Est-ce que le Bus Monitor est censé se reconnecter automatiquement à KNXd après une perte temporaire de la passerelle KNX/IP ? Je me demande si, après ce type de coupure, le démon peut rester affiché comme opérationnel alors que le Bus Monitor ne reçoit plus les télégrammes.

Merci pour ton aide,

Pascal

eibd.txt (40,6 Ko)

[thomaspascal]

Personne ne rencontre ce problème? Une idée pour me débarrasser des problèmes?

[thienell]

Bonjour, tu as un soucis de configuration…

Tu ne peux pas avoir le même GAD pour une info et des actions, tu as quoi dans ETS correspondant a ton exemple cité ?

Et le dpt de l’info doit être “state” également

[thomaspascal]

Bonjour @thienell,

Merci pour ton retour.

Pour préciser la configuration, j’ai programmé moi-même cette installation avec ETS il y a plus de 20 ans. Je n’ai malheureusement plus ETS aujourd’hui, mais j’ai conservé l’édition complète des paramètres et de la topologie de l’installation. Je joins les 4 pages concernant cet exemple.

Pour l’éclairage de l’atelier, l’adresse de groupe 3/0/6 est volontairement utilisée aussi bien en écriture qu’en lecture.

Côté commande, j’ai une interface Legrand 4 entrées (0.0.42). Deux de ses entrées, C et D, sont affectées à 3/0/6 et envoient les ordres Marche/Arrêt/Télérupteur sur cette adresse. On retrouve bien dans les paramètres les deux objets en C-WTU-, 1 bit, sur 3/0/6.

Côté sortie, j’ai un actionneur Legrand 8 sorties (0.0.20). Sa sortie 7, qui commande l’éclairage de l’atelier, est également affectée à 3/0/6. Cet objet est déclaré CRWTU-, 1 bit. Il possède donc notamment le flag Lecture R.

C’est pour cette raison que, dans Jeedom, j’utilise également 3/0/6 pour les commandes On/Off et pour l’information Etat : Jeedom écrit 0 ou 1 sur cette adresse pour commander la sortie et peut également lire cette même adresse pour récupérer l’état de l’objet de sortie.

Cette configuration fonctionne ainsi depuis de nombreuses années.

Concernant ta remarque sur le DPT de l’info qui devrait être State plutôt que Switch, peux-tu m’expliquer ce que cela changerait dans ce cas précis ? Dans les paramètres ETS que j’ai conservés, les objets liés à 3/0/6 apparaissent simplement en 1 bit. Je n’ai malheureusement plus ETS pour aller vérifier davantage le sous-type qui avait été défini à l’époque.

Est-ce que, compte tenu de ces paramètres et notamment du flag R présent sur l’objet de sortie 3/0/6, tu considères toujours qu’il faudrait impérativement séparer le GAD de commande et le GAD d’état ?

Merci pour tes explications.

Topo.pdf (125,8 Ko)

[thienell]

Bonsoir, pour une commande, c’est normal que tu ai écriture pour l’un et lecture pour l’autre, mais l’actionneur doit envoyer l’état également et ce, sur un GAD différent a l’interrupteur pour que celui ci connaisse l’état de la sortie…

Qu’est ce que tu as en 8/3/0 (dans le pdf) ?

Quel version d’ ETS tu avais?

A-tu toujours le fichier .knxproj ?

Je t’ai envoyé un MP

Thierry

[thomaspascal]

Bonjour,

Merci pour ton retour.

En 8/3/0, j’ai la Coupure générale de l’éclairage. Cette adresse agit notamment sur le même objet de sortie que 3/0/6 pour l’atelier. Elle me permet de couper plusieurs éclairages par une commande générale (mise en route de l’alarme par exemple).

Concernant ETS, l’installation a été programmée à l’origine il y a plus de 20 ans, donc avec une ancienne version d’ETS. J’ai ensuite repris le projet sous ETS5. Le fichier .knxproj que j’ai conservé a été exporté avec ETS 5.7.1398.39605.

Et oui, bonne nouvelle, j’ai toujours le fichier .knxproj.

Pour 3/0/6, le projet confirme que trois objets y sont associés (j’ai analysé le fichier knxproj avec Codex ChapGPT) :

• l’entrée C de l’interface 0.0.42, en C-WTU- ;

• l’entrée D de cette même interface, en C-WTU- ;

• la sortie 7 de l’actionneur 0.0.20, en CRWTU-.

Sur cette sortie, le flag de lecture a bien été activé dans le projet. C’est donc cet objet de sortie que je lis sur 3/0/6 pour connaître sa valeur.

Je comprends ton explication sur le principe d’un GAD séparé pour le retour d’état. Mais dans mon ancienne programmation, je n’avais justement pas créé de GAD de retour d’état distinct : j’avais rendu l’objet de commutation de l’actionneur lisible et je récupérais son état de cette manière. En même temps, en 2006, je n’imaginais même pas les possibilités d’une domotique comme Jeedom…

[thienell]

Tu confonds le read de l’équipement et le read de jeedom,:

le 1er sert à lire la “commande” envoyée sur le bus à l’adresse 3/0/6 et le second sert à lire l’état de l’équipement (lumière prises etc…) à l’adresse que tu n’as pas .

un petit tour ici pour te rafraichir les neurones KNX: Log in to the site

Tu t’inscris pour suivre le basic, j’ai commencé par ça avant de prendre ETS5 pour comprendre le principe.

J’ai modifié le lien en MP, c’est bon, si tu veux, envoie moi le fichier proj en MP

[thomaspascal]

Merci, je comprends mieux ce que tu voulais dire.

Effectivement, nous ne parlions pas exactement de la même chose. Dans mon installation, je n’ai pas créé à l’époque de GAD séparé pour un objet de retour d’état de la sortie, et je ne sais même pas si cela était possible avec mes équipements de 2006.

En même temps, jusqu’en 2020, le système était totalement autonome. Ce n’est qu’à ce moment-là que j’ai installé Jeedom et le plugin.

Il me reste par contre à comprendre mon problème initial : pourquoi les Read Jeedom sur ces objets lisibles ne répondent pratiquement pas pendant le début du démarrage du plugin, puis se mettent ensuite à répondre normalement. C’est surtout ce comportement qui m’avait amené à ouvrir le sujet.

Merci pour le lien, je vais regarder.

[thomaspascal]

Bonjour @mika-nt28

Aucune idée de l’origine de ces erreurs au démarrage ?