A lire tous vos commentaires, j’ai réinstallé les dépendances (2 fois) et redémarrer 2 fois mon Rpi, mais en vain.
Qu’a tu dans les log
Bonsoir Mika, rien de spécial, j’ai déjà un peu épluché les logs.
Le log des updates semblent s’être déroulé correctement.
Le log eibd en mode debug annonce le démarrage du démon. On voit aussi que lorsque j’interroge une variable, on voit la trace qui reste sans réponse (dans tous les cas je vois la requête arriver côté log de ma passerelle mais rien en retour.
Tu pensais à quels logs en particulier ?
Et ça c’est le log côté passerelle KNX où on voit bien le READ arriver et la réponse qui n’arrive pas au jeedom. De plus les trame WRITE sur le bus KNX qu’on voit côté passerelle KNX ne sont pas captées par le bus monitor du plugin Jeedom :
J’ai redémarrer plusieurs fois oui 
Tout démarre de mon côté, en mode routing ou tunneling. Les logs sont OK mais la trame WRITE sur le bus n’est plus lu et n’apparait pas dans le bus monitor.
À tu essayé le reboot
Bonjour,
Meme chose ici, le demon ne demarre plus, et quand il semble demarrer a la suite de changement de Type de passerelle mode NAT<-> tunneling, il continue de lire depuis le cache.
Le log quand il ne demarre plus:
0004|[2022-04-09 10:11:02]DEBUG : [Moniteur Bus] KNXd est arrété
0005|[2022-04-09 10:11:02]DEBUG : Lancement du Bus Monitor
0006|[2022-04-09 10:11:02]DEBUG : Connexion a EIBD sur le serveur 127.0.0.1:6720
0007|[2022-04-09 10:11:03]DEBUG : [Moniteur Bus] KNXd est arrété
0008|[2022-04-09 10:11:04]DEBUG : [Moniteur Bus] KNXd est arrété
0009|[2022-04-09 10:11:06]DEBUG : [Moniteur Bus] KNXd est arrété
J’etais en IPTN quand ca fonctionnait avant la mise a jour, et j’ai essaye de reinstaller plusieurs fois, soit tout le systeme, soit juste le plugin, soit les dependances, rien a faire il lit toujours depuis le cache.
Comment vide-t-on ou desactive-t-on le cache?
Merci de votre aide 
Idem même en injectant une sauvegarde de plusieurs mois en arrière … étrange…
Voici comment j’ai résolu le problème avec un passerelle Siemens N148/22 et un Jeedom Smart:
Puis Reboot
[EDIT]
Sur certains équipements « Lumière », plus de retour d’état. Je devais faire un « READ » sur la commande info. J’ai constaté que sur ces commandes le flag « Lecture » était coché au lieu du « Ecriture » (impossible de savoir l’origine de ce changement).
Pour corriger le flag, j’ai recréé la commande info et c’est rentré dans l’ordre.
[EDIT du 23 avril]
Les MàJ du plugin eibd sont faites (version 2022-04-15 06:05:35)
2 semaines sans problème.
Bonsoir à tous,
Gregory, nouvel utilisateur sur Jeedom.
Installation : Jeedom Delta, KNX Hager cablé, Passerelle TYF120.
Je vais suivre ce sujet car je suis dans le même cas que vous.
Après avoir coupé la VM de la freebox où se trouve Jeedom, je n’ai plus de retour d’état automatique (je suis obligé d’appuyer sur read dans l’équipement pour le màj dans le dashboard)
J’ai réussi à refaire marcher le retour d’état en :
- Passant à la version EIBD beta mais cela ne marchait toujours pas.
- Puis dans la configuration, j’ai changé le type de passerelle en IPTN, mais le Demon ne se lancait pas
puis revenu en IPT, et la cela remarche…
Je pense que cela ne marchera plus si je coupe Jeedom.
Pas mieux pour moi.
Dans les logs j’ai un drop Syslog de mon Rpi qui héberge jeedom, j’ai un drop packet lorsque je déclenche un read. L’adresse KNX 15.15.255 est celle que j’ai mis sur mon équipement Jeedom KNX et est configurée sur ma passerelle Comfoway KNX.
Le log suivant est généré lorsque je fait un READ dans jeedom d’une valeur sur mon bus (READ de la valeur 6/1/12) - désolé de la taille du log mais c’est le log de la commande seule.
Apr 10 23:18:26 : jeedom: Layer 8 [ 8:systemd_/systemd 1656.821] New Connection
Apr 10 23:18:26 : jeedom: Layer 8 [61:systemd_/CConn 1656.821] ClientConnection Init
Apr 10 23:18:26 : jeedom: Layer 3 [61:systemd_/CConn 1656.821] Allocate 0.0.4
Apr 10 23:18:26 : jeedom: Layer 7 [62:systemd_@0.0.4/Group 1656.821] OpenGroup
Apr 10 23:18:26 : jeedom: Layer 4 [64:systemd_/TGr 1656.821] OpenGroup 6/1/12 RW
Apr 10 23:18:26 : jeedom: Layer 7 [62:systemd_@0.0.4/Group 1656.822] OpenGroup complete
Apr 10 23:18:26 : jeedom: Layer 3 [63:systemd_/ConnS 1656.822] registerLink: 63:systemd__63
Apr 10 23:18:26 : jeedom: Layer 3 [63:systemd_/ConnS 1656.822] Start: cfg:systemd_
Apr 10 23:18:26 : jeedom: Layer 5 [63:systemd_/ConnS 1656.822] down => >up
Apr 10 23:18:26 : jeedom: Layer 5 [63:systemd_/ConnS 1656.822] Starting
Apr 10 23:18:26 : jeedom: Layer 5 [63:systemd_/ConnS 1656.822] >up => up
Apr 10 23:18:26 : jeedom: Layer 4 [63:systemd_/ConnS 1656.822] link state changed: up
Apr 10 23:18:26 : jeedom: Layer 5 [63:systemd_/ConnS 1656.822] Started
Apr 10 23:18:26 : jeedom: Layer 4 [63:systemd_/ConnS 1656.822] link state changed: up
Apr 10 23:18:26 : jeedom: Layer 4 [ 1:main 1656.822] check start
Apr 10 23:18:26 : jeedom: Layer 4 [ 1:main 1656.822] check end: want_up 1 some 1>1 all 0>1, going 0 up 5 down 0
Apr 10 23:18:26 : jeedom: Layer 7 [61:systemd_/CConn 1656.822] recv Group(002): 00 00
Apr 10 23:18:26 : jeedom: Layer 4 [64:systemd_/TGr 1656.822] Recv Group T_Data_Group A_GroupValue_Read
Apr 10 23:18:26 : jeedom: Layer 8 [63:systemd_/ConnS 1656.823] found addr 0.0.4
Apr 10 23:18:26 : jeedom: Layer 6 [16:B.gateway/Conn 1656.823] sending, send_more clear
Apr 10 23:18:26 : jeedom: Layer 6 [16:B.gateway/Conn 1656.823] sendNext called, send_more set
Apr 10 23:18:26 : jeedom: Layer 6 [ 1:main 1656.823] sending set
Apr 10 23:18:26 : jeedom: Layer 6 [31:systemd_/ConnS 1656.823] sending, send_more clear
Apr 10 23:18:26 : jeedom: Layer 7 [29:systemd_/CConn 1656.823] Recv(002): 00 00
Apr 10 23:18:26 : jeedom: Layer 6 [31:systemd_/ConnS 1656.823] sendNext called, send_more set
Apr 10 23:18:26 : jeedom: Layer 6 [ 1:main 1656.823] sending set
Apr 10 23:18:26 : jeedom: Layer 6 [ 8:systemd_/systemd 1656.823] is OK
Apr 10 23:18:26 : jeedom: Layer 6 [22:server/Server 1656.823] is OK
Apr 10 23:18:26 : jeedom: Layer 6 [ 4:systemd_/systemd 1656.823] is OK
Apr 10 23:18:26 : jeedom: Layer 6 [63:systemd_/ConnS 1656.823] is OK
Apr 10 23:18:26 : jeedom: Layer 6 [12:A.unix/local 1656.823] is OK
Apr 10 23:18:26 : jeedom: Layer 6 [16:B.gateway/Conn 1656.823] is OK
Apr 10 23:18:26 : jeedom: Layer 6 [31:systemd_/ConnS 1656.823] is OK
Apr 10 23:18:26 : jeedom: Layer 6 [ 1:main 1656.823] OK
Apr 10 23:18:26 : jeedom: Layer 6 [ 2:main/L 1656.823] OK L
Apr 10 23:18:26 : jeedom: Layer 2 [19:C.pace/B.gateway 1656.828] out 1/2: delay for 0.012 sec
Apr 10 23:18:26 : jeedom: Layer 2 [19:C.pace/B.gateway 1656.841] delay done
**Apr 10 23:18:28 : jeedom: Layer 5 [18:single/B.gateway 1658.664] drop packet from 15.15.255**
Apr 10 23:18:31 : jeedom: Layer 8 [61:systemd_/CConn 1661.828] ClientConnection 0.0.4 closing
Apr 10 23:18:31 : jeedom: Layer 3 [ 1:main 1661.828] Release 0.0.4
Apr 10 23:18:31 : jeedom: Layer 3 [63:systemd_/ConnS 1661.828] unregisterLink: systemd__63
Apr 10 23:18:31 : jeedom: Layer 8 [61:systemd_/CConn 1661.828] Exiting
Apr 10 23:18:31 : jeedom: Layer 7 [61:systemd_/CConn 1661.828] CloseGroup
Apr 10 23:18:31 : jeedom: Layer 4 [64:systemd_/TGr 1661.828] CloseGroup
Apr 10 23:18:31 : jeedom: Layer 4 [ 1:main 1661.829] check start
Apr 10 23:18:31 : jeedom: Layer 4 [ 1:main 1661.829] check end: want_up 1 some 1>1 all 1>1, going 0 up 5 down 0
J’ai l’impression que vous êtes tous sur rpi non ?
Salut
Pour ma part je suis sur smart
et j ai semaine dernière deux plantages âpres des MAJ de plugin
Le premier un simple reboot a fait refonctionner le KNX
Le deuxième samedi soir j’ai du faire plusieurs reboot ,
redémarrer les dépendances et ça a fini par refonctionner …
Yes, sur un pi4
Après vérification
Ce type en tunneling Nat, il n’est pas a utiliser car il exige des paramètres que je n’est pas encore ajouté a la configuration du plugin.
Avez-vous vraiment besoin de natté la passerelle ?
Je pense qu non vue le fonctionnement en ipt simple
Attention les adresses physiques données pour jeedom (plage adresse physique saisie +1 + nombre de connexions) doivent être des adresses libre non utilisée et attribué uniquement au fonctionnement de jeedom
De mon côté j’ai 2 VM jeedom sous Ubuntu. L’application de la dernière mise à jour empêche le démarrage du démon.
Le redémarrage n’a rien changé, de même que la réinstallation des dépendances et le recherche à nouveau de la passerelle. Le démon ne démarre pas.
Je pense que je me suis mal exprimé. L’adresse KNX 15.15.255 est celle configurée sur ma passerelle Comfoway. Et donc c’est celle-ci que j’indique quand sur l’équipement créé dans Jeedom (là où le commentaire indique que cette adresse n’est pas forcément utile - deuxième ligne de paramètrage de l’équipement après son nom). Cela fonctionnait avant la mise à jour.
Le drop packet d’une adresse KNX est bizarre non ?
Pour résumer ma situation (pour info rien a changé dans la config d’avant mise à jour du plugin) :
Côté Jeedom :
- démon KNX en mode Tunnelign OK
- Dépendances OK
- log syslog sur un READ manuel : drop packet
- rien sur le busmonitor de jeedom dans le plugin
Côté passerelle :
- le READ est vu sur le monitoring de la passerelle Comfoway
- On voit le RESPONSE
- jeedom ne voit rien
Je suis dispo pour donner plus d’infos.
Ok j’ai eu un doute
Ok c’est le souci si Jeedom ne vois pas passe les trames
Pour le moment je cherche pourquoi on a tous des problèmes différents (moi mes trame se répète)
Est-ce possible de me faire une connexion sur ton jeedom pour que je puisse analyser le problème
ma petite pierre a l’édifice, je me trouve aussi dans une situaton similaire, tout fonctionne mais après un certain temps, le retour d’état ne fonctionne plus (je suis sur la dernière version stable). si tu as besoin d’un acces, dit moi, je viens de mettre les logs en Debug, on verra s’il y a qqch
apres le plantage, j’ai ceci:
[2022-04-11 22:42:05][DEBUG] : [Moniteur Bus] Type de data non prise en charge par la plugin (0.0.0 - 0/0/0)
[2022-04-11 22:42:05][DEBUG] : [Moniteur Bus] Type de data non prise en charge par la plugin (0.0.0 - 0/0/0)
[2022-04-11 22:42:05][DEBUG] : [Moniteur Bus] Type de data non prise en charge par la plugin (0.0.0 - 0/0/0)
autre chose, j’ai eu une notification de jeedom me disant qu’il ne reste que 10 % d’espace disque. j’ai fait un roolback (VM) pour la nuit, je pourrais p-e encore regarder demain.
apres le roolback, j’en suis loin des 90%
Filesystem Size Used Avail Use% Mounted on
udev 984M 0 984M 0% /dev
tmpfs 200M 21M 179M 11% /run
/dev/sda1 30G 12G 17G 40% /
tmpfs 998M 0 998M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 998M 0 998M 0% /sys/fs/cgroup
tmpfs 256M 7.5M 249M 3% /tmp/jeedom
est ce que le log du deamon saturerait?
Bonjour,
Avant la mise à jour du 31 mars, j’utilisais déjà knxd (et pas eibd) avec systemd sur le même système (rpi3 sous debian) que jeedom et le plugin knx.
Ma procédure d’installation est documentée ici.
On peut y voir que KNXD est configuré pour utiliser un adaptateur USB série pour communiquer avec le réseau KNX de la maison. Le RPi fait donc office de passerelle IP/KNX (un peu comme les boitier Jeedom Atlas Pro).
Tout fonctionnait : easyknx sur le mobile, ETS sur le pc et jeedom dans le navigateur 
.
Depuis la mise à jour du 31 mars: le plugin écrase ma configuration en remplaçant par un fichier /etc/knx.ini mais sans possibilité de préciser l’utilisation d’un port série 
.
Si l’interface du plugin doit permettre de configurer le démon, elle doit permettre de configurer l’IP de la passerelle et le port tpuart. Or il n’y a qu’un champ à remplir.
Quand je rétablie la configuration en refaisant ma procédure, tout le monde (easyknx, ETS et jeedom) retrouvent le réseau KNX. Mais jeedom ne voit pas les retours d’état 
.
Comme je ne sais pas où trouver le code source versionné (git ?), difficile de dire ce qui a sauté entre la version précédente et cette version.
setop
PS: malgré les soucis rencontrés récemment, merci mille fois @mika-nt28 
pour le travail accompli sur cet indispensable plugin
Tu veux dire que j’ai oublié le port série
Tu peux poster ton knxd.ini
Ca fonctionnait chez toi justement c’est la cause de tout çà
@setop j’ai regardé rapidement dans la configuration de knxd avec le fichier ini
Ils ont changé de nom, ce n’ai plus TPUARTS mais TPUART.
J’ai poussé une mise à jour en stable