je confirme qu’en 1.1.251 et suivantes je n’ai pas d’équipement.
voici la réf de l’alim Siemens 5WG1 125-1AB22 bon elle a une 12 années !
sinon comment voir si le bus redémarre ? car sur les logs Eibd je ne vois pas ligne qui indique cela ?
pour décocher initialisation sur les commandes états c’est bien du côté plugin Jeedom qu’il faut le faire et pas dans ETS ?
Case initialisation à décocher…
Pour l’alim, au pire tu coupe le 230v qui l’alimente et tu regarde si le symptôme est le même quand tu rallume l’alim ?
Ou alors, c’est la passerelle qui déconne, puisque en KNX tout fonctionne: tu perd la connexion au bus, le demon EIB relance toutes les initialisations des états des équipements (si la case est cochée)
Thiery
Bonjour @thienell et tous mes voeux pour cette nouvelle année.
Un grand merci pour ton aide.
Par acquis de conscience j’ai remonté une ancienne machine virtuelle avec Jeedom 4.4.19 donc juste avant la mise à jour vers la 4.5 et miracle pas de problème de Read permanent sur le tag initialisation et uniquement les trames normales lorsqu’il se produit quelque chose, donc je n’ai apparemment pas de souci sur mon alim, ni sur la passerelle. Il se passe bien quelque chose en passant à la 4.5 mais quoi c’est un mystère ? je pense q’il doit y avoir un petit souci avec le plugin Eibd, je ne vois que ça.
Meilleur voeux pour toi aussi,
Bon ben, il n’y a que @mika-nt28 qui pourrait t’aiguiller alors si ça bug en 4.5…!
Sinon, en attendant, décoche les cases initialisation.
Thierry
Salut,
J’espère que @mika-nt28 va trouver une solution car je ne peux pas utiliser la 4.4.19 en prod à cause du bug du changement d’année et la 4.5.2 me fait des lenteurs. Puis décocher le flag Initialiser c’est un peu galère j’ai pratiquement 100 commandes 
Dans tous les cas un grand merci pour ton aide.
Bonne journée.
1 « J'aime »
Bonjour @thienell
j’ai peut-être une piste à mon souci. en relisant le post suivant Lien j’ai vu que le moniteur de BUS se coupe dés qu’il ne se passe rien sur le bus pendant 60 secondes. C’est apparemment ce qui se passe chez moi. @AlexDelm a résolu son pb en modifiant le HearBeat à 50 secondes de sa passerelle Zennio mais moi je ne peux pas faire cela car j’ai une Siemens et il n’y a pas ce paramètre.
Maintenant pourquoi sur la V4.4.19 on n’a pas ce souci et que l’on ça sur la V4.5 ?? J’ai lu quelque part que la V4.5 était plus rapide en exécution que les versions précédentes, est-cela qui joue ?
Ensuite pourquoi certains ont le souci et pas d’autres ? je pense que cela provient du traffic KNX. chez moi le traffic étant léger, par moment je n’ai pas de communication pendant plus de 60s donc le bus s’arrête. Chez d’autres le traffic étant plus intense le bus ne s’arrête pas.
@mika-nt28 semble occupé et ne voit pas mes messages mais s’il passe par là ça serait bien qu’il voit ce qu’il peut modifier dans le plugin pour remédier à cela, merci.
En attendant j’ai essayé de mettre une commande cyclique sur un détecteur pour faire du traffic sur le bus mais on ne peut pas descendre sous 1 mn. C’est mieux mais pas concluant alors j’ai mis une 2ème commande cyclique sur un autre détecteur c’est encore mieux mais il arrive encore de temps en temps que le bus soit inoccupé pendant 1mn. Que puis-je faire d’autre ?
Merci pour l’aide.
1 « J'aime »
Agit plutôt sur l’équipement dans ets6, regarde si il y en a un qui a la fonction hearthbet ou un truc comme ça et active le…
Thierry
Ok merci je vais essayer ça 
Salut,
j’ai trouvé un équipement qui a un heartbeat et j’ai crée un GA qui envoi un état toutes les 50s et miracle plus de saturation sur le bus KNX. Donc je confirme, c’est bien un timeout du plugin qui si pas d’activité sur le bus pendant 1mn ça l’arrête puis il redémarre d’où l’initialisation.
Si @mika-nt28 pouvait voir ce post ou quelqu’un d’autre comme @Poluket ou autre qui peut agir sur ce plugin et faire une modif car ce souci est apparu avec la V4.5 jeedom. Ca serait mieux de faire un correctif plutôt que de faire une bidouille sur un équipement comme j’ai fait. D’autant plus que je ne suis pas le seul @AlexDelm a le même souci et il doit y en avoir d’autre depuis la dernière version.
Merci encore et bonne journée.
1 « J'aime »
Bonjour,
Tout d’abord tous mes vœux pour cette nouvelle année.
Je tien à m’excuser de mon absence ces derniers mois, j’ai saturé de boulot et plus une minute pour m’occuper de la domotique et jeedom.
Pour en revenir à votre problème, si je comprends bien, il y a un arrêt du démon lorsque trop d’attente.
Est-ce que dans le delta de configuration y a que la mise a jour de jeedom ou un mise a jour php?
Côté jeedom sur cette version est ce qu’il y a une fonction sur les démon qui peut faire cela
oui il y a un redémarrage du bus moniteur donc du démon si c’est la même chose, si pas d’activité sur le bus pendant plus d’une minute apparemment.
En effet le problème est survenu lors du passage jeedom de la V4.4.19 à la 4.5 et en même temps je suis passé de Debian 11 vers 12.
Je ne le gère pas dans le plugin.
Il faudrait même l’interdit pour ce plugin.
Je regarderai les options
Ce n’est pas une fonctionnalité d’un plugin mais du core.
Si paramétré (ce qui n’est pas le cas par défaut), le core vérifie dans les eqLogic du plugin en question qui ont un lastCommunication que ce dernier date bien d’il y a moins de X minutes (celles paramétrées dans la case à cocher).
Dans le cas contraire il redémarre le daemon du plugin, si la case à cocher en question l’est.
Pourquoi vouloir l’interdire sur ce plugin ?
Certes si c’est paramétré n’importe comment ça peut générer des problèmes mais dans le cas contraire c’est un moyen de surveillance natif efficace.
Tu peux en dire un peu plus sur ce que tu as fait ?
Et des copies d’écran de ce que tu as vu ?
@jackouille j’ai peut être trouver un défaut.
Je reste effectivement le bus lorsque la data est non valide. En cas d’aucune valeur ça doit entrer dans ce cas
Je vais voir pour patch ça.
Par contre ça n’a rien a voir avec la version de jeedom.
Le core de jeedom est il plus rapide sur cette version qui ferait bloquer le démon
A tu un moyen de checker si le problème est bien résolu
oui j’ai lu sur le forum que jeedom 4.5 était plus rapide que les versions précédentes. Le code a été optimisé. Ca pourrait être une explication du pourquoi on a le pb en 4.5 et pas en 4.4.19
Je confirme que ma solution de contournement fonctionne et je peux vérifier si tu fais une modif sur le plugin, j’enleverrai ma solution pour vérifier que ta modif fonctionne.
comme il arrive que sur mon bus knx j’ai des périodes de 2 ou 3mn sans dialogue, sans trame, le bus moniteur (démon si j’ai bien compris) redémarre dans ce cas. Ce qui provoque l’Initialisation de tous mes équiments KNX, ce qui sature le bus pendant quelques mn.
Pour éviter cela j’ai choisi un équipement KNX qui m’a permis avec sa configuration Heartbeat d’envoyer régulièrement un GA toutes les 50 secondes et miracle plus de redémarrage du bus moniteur et plus de saturation du bus.
Ok merci pour les précisions.
Mais du coup plutôt que de faire des hypothèses, est ce que tu peux regarder si tu as paramétré quelque chose au niveau du hearthbeat du plugin dans jeedom comme indiqué dans mon message de tout à l’heure ?
Est ce que tu as regardé dans les logs du plugin si tu avais quelque chose ?
En particulier « Attention le plugin xxx n’a pas reçu de message depuis … »
non je n’ai rien paramétré au niveau du plugin
Je n’ai pas de message comme « Attention le plugin xxx n’a pas reçu de message depuis … » dans les logs du plugin. J’ai ça quand le démon redémarre
[2026-01-04 11:15:02][DEBUG] [Moniteur Bus]
[2026-01-04 11:15:02][INFO] [Moniteur Bus] Deconnexion a EIBD sur le serveur 127.0.0.1:6720
[2026-01-04 11:15:02][DEBUG] [Moniteur Bus] Lancement du Bus Monitor
[2026-01-04 11:15:02][DEBUG] [Moniteur Bus] Connexion a EIBD sur le serveur 127.0.0.1:6720
[2026-01-04 11:15:02][DEBUG] [Moniteur Bus] Initialisation de valeur des objets KNX
sinon les messages habituels lorsqu’un équipement dialogue sur le bus, des Write et des Read avec les réponses.
[2026-01-04 11:21:27][DEBUG] [Terrasse][L61 Cabanon][Etat] : Décodage de la valeur avec le DPT :1.001
[2026-01-04 11:21:27][INFO] [Terrasse][L61 Cabanon][Etat] : Mise à jour de la valeur : 1
[2026-01-04 11:21:27][DEBUG] [Terrasse][V34 Store][Hauteur] : Décodage de la valeur avec le DPT :5.001
[2026-01-04 11:21:27][DEBUG] La commande sera inversée
[2026-01-04 11:21:27][INFO] [Terrasse][V34 Store][Hauteur] : Mise à jour de la valeur : 100%
[2026-01-04 11:21:28][DEBUG] [WC Etage][L170 WC 2][Etat] : Décodage de la valeur avec le DPT :1.001
[2026-01-04 11:21:28][INFO] [WC Etage][L170 WC 2][Etat] : Mise à jour de la valeur : 0
[2026-01-04 11:21:28][DEBUG] [WC Etage][L170 WC 2][Etat] : Décodage de la valeur avec le DPT :1.001
[2026-01-04 11:21:28][INFO] [WC Etage][L170 WC 2][Etat] : Mise à jour de la valeur : 0
[2026-01-04 11:21:28][DEBUG] [WC RDC][L90 WC1][Etat] : Décodage de la valeur avec le DPT :1.001
[2026-01-04 11:21:28][INFO] [WC RDC][L90 WC1][Etat] : Mise à jour de la valeur : 0
[2026-01-04 11:21:28][DEBUG] [WC RDC][L90 WC1][Etat] : Décodage de la valeur avec le DPT :1.001
[2026-01-04 11:21:28][INFO] [WC RDC][L90 WC1][Etat] : Mise à jour de la valeur : 0
[2026-01-04 11:22:02][DEBUG] [Entrée][D10 Porte entrée][valeur][Read] Interrogation du bus
[2026-01-04 11:22:02][DEBUG] [Entrée][D10 Porte entrée][valeur] : Décodage de la valeur avec le DPT :1.009
[2026-01-04 11:22:02][INFO] [Entrée][D10 Porte entrée][valeur] : Mise à jour de la valeur : 1