Bonjour à tous, @mika-nt28,
je n’ai pas d’autre titre à proposer car c’est vraiment la réalité.
Voici la situation. J’avais un jeedom qui tournait sur un pi3B sous docker depuis des années mais comme certains plugins n’acceptent pas la configuration sous docker, et que je n’en avais plus vraiment besoin, j’ai décidé de dédier ce pi3b uniquement à Jeedom. J’ai donc fait une installation tout neuve et toute propre avant de récuperer ma config jeedom à partir d’une sauvegarde. J’ai du faire quelques ajustement sur certains plugins mais pas EIBD si ce n’est que depuis c’est le plugin EIBD qui vit sa propre vie sans rien y comprendre. Alors je m’explique, j’ai un thermostat dans chaque piece et des vannes de chauffage electriques, et les consignes de température et de mode de chauffage, changent parfois sans raison, mais à une fréquence telle que le lecteur de bus est saturé, sans compter que la maison n’est pas à la température voulue. C’est au niveau du serveur du démon que ca a l’air de bugger. Car c’est de ses adresse IP que les commandes multiples sont lancées (1.1.72 et 1.1.73) Bizarrement ca ne touche que les commandes de chauffages. La saturation du bus empêchent l’actualisation des états de l’installation. Je suspecte éventuellement le plugins agenda, qui commande le change de consigne selon l’heure de la journée, bien que je ne trouve aucune similitude dans les moments où cela survient. Lorsque je désactive dans le plugin eibd les équipements des thermostats, la partie knx est stable et réagit correctement, ca vient donc bien du plugin. J’ai aussi essayer de modifier les flags, mais ca n’a pas l’air d’avoir d’effets.
au final, la memoire du pi est saturee et c’est tout jeedom qui ralentit et je dois le redemarer
Question, y a t il moyen de trouver ce qui lance la commande au démon ?
Si quelqu’un a une piste ou une idee, je suis prenneur
C’est logique que ce soit parfois, un trame arrive, jeedom la reçois et comme la case transmettre est cochée, il va renvoyer le même message sur le bus. Il suffit qu’un appareil y réponde et tu as une boucle.
Si jamais cela n’a pas résolu ton problème, essaye de désactiver tous les modules /commandes knx ds le plugin et puis tu les réactives au fur et. Mesure jusqu’à trouer le coupable.
Regarde aussi le moniteur de bus au moment du problème. Tu devrais identifier les commandes qui posent problème
J’ai bridé le plugin pour que justement il ne boucle pas
Si l’état a transmettre vien du bus, le plugin ignore le flag Transmettre et n’écoute pas les mise a jour de l’état.
Je pense que l’on est bien dans se cas.
Dans tous les cas si les flag ne sont pas bien configurer le plugin ne fonctionnera pas bien et le point de départ de l’analyse sera toujours de bien réfléchir et de bien comprendre les flag. chose qui n’est pas facile je l’accorde mais que je n’ai pas réinventer.
Il est vrai que le flag transmettre est un peut détourner pour les options d’automatisme.
bonsoir, j’ai cherché pour quelle raison j avais coché le flag « transmettre », et je me suis rappelé que suite à la réinstallation de jeedom et du backup, jeedom ne changeait plus les consignes de températures. J’ai donc cherché avec le flag, et pour cela que je les ai changé. Pour l’instant, tout semble répondre correctement, j’ai continué à faire place nette notamment en mettant non à écriture /lecture cyclique qui chargeait aussi le bus.
Ca fait des années que j’utilise ton plugin sans problème, et le problème est survenu après la réinstallation. Peut-être ai je été trop impatient et n’ai je pas laissé le temps au système de se stabiliser de part lui même. je pense qu’on va pouvoir clotûrer ce post. Par contre je vais sans doute en ouvrir un autre pour clarifier l’utilisation des flags (en mettant des exemples précis qui pourront peut être compléter le doc du plugin( qui a bien évoluée aussi et qui pourra servir à tout le monde.
et qui pourra servir à tout le monde.