Problème de télégrammes GroupValueRead non acquités après le redémarrage du daemon EIBD

Bonjour à tous,
Je remarque que ce problème, qui aurait du être résolu (selon le log de la version du 03/06/2021), persiste …
J’ai beaucoup de GroupValueRead qui portent le flag NAK (Not Acknowledge), probablement à cause du nombre d’émission de télégrammes toujours non espacés.
La version installée c’est celle du 08/06/2021.
Ce même problème persiste pour les GroupValueWrite, dans un scénario, si vous envoyez une séquence de commandes vers le KNX: c’est le même problème …
Je sais on n’est qu’à 9600 baud donc il faut être patient, mais le protocole KNX suppose une écoute sur le bus pour réémettre un nouveau télégramme qu’après un ACQ du précédent …
Je suppose que c’est bien cela qui est fait mais alors pourquoi ces problèmes ?
Merci d’avance pour vos réponses.

Bonjour

Quel temps a tu programmé entre les 2 emissions?

Bien vu, merci. J’ai mis 500 ms maintenant.

J’ai tout de même encore une question : pourquoi les Read du Jeedom sont toujours doublés ? Le premier Read est non acquitté et seulement le deuxième est bon ? (malgré 0,5 s entre les télégrammes et la charge du bus à 1,2%) L’espacement entre les read est de 50 ms:
image
image

Il faudrait voir ce qui de passe en //. Si le module knx ne répond pas assez rapidement au read, c’est p-e la cause

Si tu as autorisé plusieurs connexion sur jeedom (>2) alors jeedom utilisera plusieur Thread
A 1.2% de charge je ne vois pas pourquoi tu as ses soucis que je ne constate pas chez moi

D’ailleur c’est etrange que se soit doublé, le plugin ne repete pas les commande peux tu mettre un screen de ta configuration Jeedom d’ equipement qui fait une repétition

Il a activé le moniteur de bus sur ets, tu peux avoir jusqu’à 3 tentatives avec le même read au niveau du bus alors que jeedom n’a fait qu’une requête. C’est le principe du bus knx

Bien sur que on voit beaucoup de choses par le moniteur ETS et heureusement qu’on dispose d’un moyen de trace … C’est d’ailleurs grâce à ça qu’on voit que d’autres produits en faisant un read ne font pas plusieurs mêmes commandes … En même temps on voit que c’est la même therad qui a lancé deux fois le même read car les adresses physiques sont les mêmes. On voit bien la rotation entre les threads donc ça fonctionne bien … S’il n’y a pas d’acquittement ce que: soit la trame n’est pas complète et elle se fait « jeter », soit , par le principe on envoi 2 reads … Ce problème survient tout le temps au moment de la modification d’un équipement jeedom et de sa sauvegarde : pour se synchroniser il lance les reads … (pour info : je suis instructeur KNX et intégrateur dépuis 2003 :relieved:)