Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
Nouveau projet, KNX maintenant ou plus tard ?
(23/08/2019, 09:25:25)lolilol a écrit : Hello,

bon j'ai réussi a trouver le problème, mais j'ai besoin d'explication car je ne trouve pas cela très normal.

La situation problématique :
US/4.2 --> appuis court --> GA 1 --> valeur : inverser
US/4.2 --> appuis long --> GA 2 --> valeur : arret

commutateur --> GA 1 et GA 2.

Situation qui règle le soucis :
US/4.2 --> appuis court --> GA 1 --> valeur : inverser + GA 2 en écoute
US/4.2 --> appuis long --> GA 2 --> valeur : arret

commutateur --> GA 1 et GA 2.

Heu… c'est pas super limpide ta présentation

Quand tu écris "commutateur --> GA 1 et GA 2", tu veux dire que les GA1 et GA2 sont liées à un seul et même objet (celui de commande) de ton actionneur de commutation ?

Dans ce cas, je ne vois pas pourquoi tu utilises 2 GA. Une seule suffirait pour la commande.
Par contre, comme te l'a dit pollux06, utiliser une autre GA pour le retour d'état serait bienvenu.

Pour la faire brève : les retour d'état, c'est pas toujours indispensable, mais il est toujours préférable d'en mettre un, ça évite les problèmes futurs.

Si je reprends à la base, ce que tu veux, c'est qu'un appui court inverse l'état de ta lampe et qu'un appui long l'éteigne.
Si c'est bien ça, voilà ce que je ferais (je fais virtuellement la manip en parallèle sur un US/U12.2 et un SA/S8.6.1 donc les termes pourraient être différents) :
  • Je crée 2 adresses de groupe : une GA1 « CommandeOn/Off », et une GA2 « EtatOn/Off » (toutes deux de type DPT1.001 switch)
  • Sur l'US/U :
    • je paramètre un canal en capteur de commutation, avec distinction appui long / appui court puis avec court = INVERSER et long = ARRÊT. Par contre, en bas, je choisis un seul objet de communication pour "actionnement long resp. court" (pas la peine d'en mettre 2, car il seront associés aux mêmes GA)
    • Je lie l'objet Commande (unique, donc) aux GA1 et GA2, mais mettant bien GA1 en premier (si nécessaire en faisant bouton de gauche sur la GA1 et en choissant « définir l'envoi »).
    • je mets un DPT 1.001 à l'objet (par perfectionnisme)
    • Comme flag de cet objet, j'active C, W, T et U (le U c'est carrément du zèle)
  • Sur l'actionneur de commande tout ou rien :
    • Sur le canal choisi, j'active le retour d'état. Sur mon SA/S, le retour d'état est forcément actif, mais sur certain actionneurs, il faut l'activer dans les paramètres (pour éviter d'avoir par défaut des tonnes d'objets potentiellement inutilisés). Ce qui est sûr, c'est qu'il faut avoir a minima sur le canal un objet "Commutation" et un objet "Télégr. d'état Commutation".
    • je mets ces 2 objets aussi en DPT1.001 switch (perfectionnisme, quant tu nous tiens…)
    • pour les flags, sur l'objet Commutation, j'active C, R, W et sur l'objet retour d'état, j'active C, R et T
    • je lie l'objet Commutation à la GA1 et l'objet état à la GA2.
Et c'est fini.

Quelques commentaires :
  • l'idée c'est bien que, grâce à la GA2 et son flag W, on est sûr que l'objet Commande de l'US/U est à jour de l'état réel de la lampe. Quand tu actionneras le bouton, ça changera l'état de cet objet (selon appui long ou court) en partant d'une situation qui est forcément la vraie situation. Comme le flag T est actif, cet état sera transmis à la GA1 (et c'est pour ça que c'est important que ce soit la GA1 l'adresse d'envoi). L'actionneur recevra ce télégramme sur son objet Commutation (grâce au flag W actif), agira selon le télégramme, puis mettra à jour son objet d'état en conséquence. Comme cet objet a le flag T actif, ça va générer un télégramme sur la GA2 correspondant à l'état de la lampe, télégramme qui sera reçu par l'objet commande de l'US/S. Fin de l'histoire, la boucle est bouclée.
  • Comme déjà dit, si la config devait juste se limiter aux deux participants ci-dessus, le retour d'état sur la GA2 ne sert à rien, mais c'est plutôt sain de le prévoir vis-à-vis d'extensions futures. En l'occurrence : si jamais l'actionneur changeait l'état de sa sortie pour quelque autre raison que le fait d'avoir reçu un télégramme via la GA1 sur son objet Commutation (ex : un forçage, une commande via une autre GA...) et bien l'Objet Commande de l'US/U, lui, n'aurait aucune raison de le savoir et donc resterait dans son état antérieur, potentiellement différent de l'état réel de la sortie, ce qui pourrait conduire à ce qu'un premier appui bref d'inversion n'ait pas d'effet (l'appui long, lui aura toujours l'effet OFF escompté).
  • Mes choix pour les flags R et U sont discutables... de toute façon, là encore, ça ne servira qu'éventuellement plus tard.
Répondre


Messages dans ce sujet
RE: Nouveau projet, KNX maintenant ou plus tard ? - par Dibou - 24/08/2019, 08:15:04

Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)