Encore un sujet sur ce problème depuis le passage à KNXD… il me manque eibd, 5 ans sans erreur ^^ tu aurais pas le zip de la dernière maj avant passage knxd ^^
bref, j’ai lu tous les topics sur le sujet, j’ai fais les purges de knxd, je suis passé en béta, j’ai relancé les dépendances… bref testé pas mal de trucs avant de demandé à l’aide…
Le daemon ce lance bien, mais je n’ai pas de réponse à mes read. je vois passer la demande et le retour sur ETS mais jeedom me reponds null.
J’étais sur une passerelle siemens, et je fais actuellement mes tests avec la passerelle d’un ami, une mdt, mais aucun changement.
J’ai désactivé le mode tunneling, mais aucun changement, bref je sais plus trop quoi faire ^^
Merci de votre aide,
je suis sur jeedom dernière version et sur eibd en beta.
Pas de problème chez moi, c’est donc certainement un souci avec ta configuration.
Peux tu mettre un sceenshot d’une configuration Jeedom te posant problème et les même gad côté ets
Si tu as un retour null c’est qu’aucun équipement ne répond à la requête de jeedom
Aucun rapport avec la passerelle, du moins j’en vois pas puisqu’il doivent tous respecter la norme knx
Peut importe comment jeedom se connecte c’est ton device knx qui ne répond pas .
Et la différence est plutôt une question de sécurité
pour la sauvegarde, j’ai un délai de retention trop court et j’ai déjà plus…
J’ai aucune adresse depuis jeedom qui réponds au READ, mais la réponse est bien envoyé sur le bus par l’actuateur. (cf capture)
car avant ce facheux épisode si j’avais null, c’est quand j’avais oublié de positionner correctement mon R dans ETS
Si je la vois passer, mais elle met super longtemps à arriver, + de 2 secondes, du coup l’état de ma commande fonctionne avec tester, mais pas sur le read
Ok merci c’est ce que je voulais regarder.
Par contre dans ton screenshots on ne voit ni le read ninla réponse
J’ai mis un timeout pour protéger les Jeedom qui ne réponde pas
Je ne trouve aucune piste de ton probleme, mais a mon avis c’est bien chez toi qu’il y a un soucis car normalement le bus monitor fait la différence entre chaque type de message Write / Read / Reponse ce qui n’a pas l’aire d’etre la cas chez toi mais bien chez moi
La copie d’écran était un on/off depuis ETS. il me semble
voici un capture depuis un read jeedom, aujourd’hui la commande réponds, mais délai très long.
C’est étrange ce délai, je vais regarder ce que j’ai mis en timeout de la fonction
Dans tous les cas même si tu as a un retour null le bus monitor vois la réponse et la traitera
sacré histoire qd même