Bonjour à tous,
j'écris un 2ème sujet concernant les boutons poussoirs/interrupteurs
car je me pose BEAUCOUP de questions (phase débutant oblige). J'ai lu
les différents sujets dans les archives mais il y a certains points
que j'ai du mal à comprendre sans manipuler et surtout sans
expérience. Je fais vous exposer ma compréhension sur le sujet et mes
questions.
Je pense avoir compris le fonctionnement 1 interrupteur / 1 lumière
allumée (par exemple).
Base de cet exemple pédagogique : http://www.domo-energie.com/fr/page.asp?Id=33
Mais qu'en est-il lorsque l'on souhaite commander la même lumière (ou
volet roulant...) avec plusieurs interrupteurs simples ou
interrupteurs multi-fonctions (capteurs)?
Mes questions :
1) Exemple : comment réaliser un va et vient (2 capteurs ou plus) ?
Par exemple, quand j'arrive dans une pièce, je veux allumer avec le
bouton poussoir A (ON) et quand je quitte la pièce, je veux éteindre
avec un autre bouton poussoir B (OFF). Je ne sais pas si quand je fais
ON sur le BP A, le BP B va savoir qu'il faut envoyer OFF sur sa trame
en destination de l'actionneur (et inversement !).
Ma compréhension et mes questions :
Je pense que dans ce cas de figure pour une programmation simple, il
est indispensable de gérer l'action ON et OFF sur 2 touches distinctes
(sans "mémoire du capteur") afin ne pas avoir à gérer l'objet
indication d'état (fonction rocker sur capteur).
Me confirmez-vous cela s'il vous plaît?
Si l'on souhaite utiliser la fonction toggle, la programmation est
alors plus complexe car je pense que l'objet indication d'état
("mémoire" du capteur) joue un rôle, mais comment? En le mettant dans
la même adresse de groupe? Pourquoi tous les interrupteurs des
différentes marques ne proposent-ils pas cet objet (afin de le lier
sous ETS)? Je m'explique : l'application liée au WKT316 de HAGER
possède cet objet, mais le poussoir triple de Siemens (5WG1223-2AB11
ou UP223 triple) ne l'a pas, ainsi que le ARTEC double (MTN626299) ou
le double-poussoir de chez Jung (2072.02LED).
Je suppose que cet objet se trouve peut-être sur les modèles multi-
fonctions plus évolués (et donc plus cher)?
Et là vous me dites que je n'ai rien compris...LOL....et que je n'ai
plus qu'à revoir ma théorie KNX....
2) Tous les interrupteurs permettent-ils de réaliser une commutation
sur une seule touche (dans le cas d'un capteur et d'une lumière)? Je
suppose que les fonctions de base (commutation/variation/VR) sont à
peu près gérés de la même manière par tous les constructeurs? De même
pour l'appui court et l'appui long?
Y-a t'il d'autres objets (autre que l'indication d'état)
indispensables à disposer sur un interrupteur?
3) Enfin, quelle est la différence entre interrupteur et commutateur
s'il vous plaît?
Fonctions présentes chez Schneider. Pour moi, je dirai que c'est la
même chose.
De même que la fonction télérupteur de HAGER est une fonction Toggle
ou commutateur, suis-je dans le vrai??
Merci par avance pour votre aide!
Spiffou.
Nicolas Garnier
Unregistered
Bonjour,
je suis désolé, je ne répond pas aux questions, mais je profite du
message de spiffou pour poser exactement la même question, légèrement
modifiée:
> 2) Tous les interrupteurs permettent-ils de réaliser une commutation
> sur une seule touche (dans le cas d'un capteur et d'une lumière)? Je
> suppose que les fonctions de base (commutation/variation/VR) sont à
> peu près gérés de la même manière par tous les constructeurs? De même
> pour l'appui court et l'appui long?
J'ai un bouton poussoir de chez Gira (088127) (les allemands disent
"1-fach", mais il y a 2 touches) qui a besoin d'un coupleur de bus. Le
choix du coupleur de bus influe-t-il sur les fonctionnalités
accessibles aux touches ? C'est à dire, si je veux utiliser les deux
touches pour commander deux points lumineux différents (commutation
sur une seule touche comme l'évoque spiffou, mode "inverseur"), est-ce
possible avec n'importe quel coupleur de bus (y compris ceux indiquant
"1-fach") ?
J'ai bien trouvé cela:
http://www.domo-energie.com/fr/Page.asp?Id=141
mais tous les coupleurs de bus offrent-ils ces possibilités ? (Je ne
peux pas encore jouer avec ETS)
Comme vous l'avez compris, je ne parle malheureusement pas la langue
de Goethe... et je suis très troublé par le "1-fach = 2 boutons"...
On 14 août, 19:53, spiffou <spiffo...@gmail.com> wrote:
> Mais qu'en est-il lorsque l'on souhaite commander la même lumière (ou
> volet roulant...) avec plusieurs interrupteurs simples
C'est une question d'association dans les GA et de setting des Flags
dans ETS
> 1) Exemple : comment réaliser un va et vient (2 capteurs ou plus) ?
c'est le cas classique de la cage d'escalier
cfr ci-dessus
> Je pense que dans ce cas de figure pour une programmation simple, il
> est indispensable de gérer l'action ON et OFF sur 2 touches distinctes
> (sans "mémoire du capteur") afin ne pas avoir à gérer l'objet
> indication d'état (fonction rocker sur capteur).
Perso, c'est ce que j'ai fait, mais je ne vois pas d'objection à
programmer le BP en toggle, à essayer
> Si l'on souhaite utiliser la fonction toggle, la programmation est
> alors plus complexe car je pense que l'objet indication d'état
> ("mémoire" du capteur) joue un rôle, mais comment?
L'objet indication d'état fait partie de ***l'actuator***, pas du
capteur !
L'actuator "sait" s'il est ON ou OFF
> En le mettant dans la même adresse de groupe?
Surtout pas.
Classiquement pour le TOR, on fait:
un GA avec tout les BP et une porte de l'actuator
un GA avec le statut de l'actuator (qui peut par exemple commander la
LED du BP ou une icône dynamique dans la Visu.
Cette manière de faire a un avantage, si le DJ en amont saute, tu le
vois à la LED du BP (pas allumé). La commande a bien été lancée, mais
pas exécutée. A contrario, si tu avais mis le statut de la LED du BP
sur l'action du BP, la LED serais ON et la lampe Off ! chouette !
> ainsi que le ARTEC double (MTN626299)
Ma maison est équipée de Merten Artec 622644 (4xBP), ils ont tous une
LED, commandée soit par l'action du BP (pas une bonne idée) ou par le
statut de l'actuator (cfr plus haut)
> ....et que je n'ai plus qu'à revoir ma théorie KNX....
amha, çà ne peut pas faire de tort
> 2) Tous les interrupteurs permettent-ils de réaliser une commutation
> sur une seule touche
Comment veux tu répondre à cette question !
Il faut télécharger la db, importer dans ETS et essayer
Les applications que je connais (Hager, Merten, Berker) permettent le
choix On/Off ou toggle, mais çà n'est pas "Tous les interrupteurs .."
> 3) Enfin, quelle est la différence entre interrupteur et commutateur
> Fonctions présentes chez Schneider. Pour moi, je dirai que c'est la
> même chose.
Pour moi aussi.
Faut pas oublier que Schneider a traduit la doc de Merten (et ils ont
changé le Manufacturer ID par la même occasion, belle valeur ajoutée,
merci :-(( )
On 14 août, 20:31, Nicolas Garnier <n.b.garn...@gmail.com> wrote:
> J'ai un bouton poussoir de chez Gira (088127) (les allemands disent
> "1-fach", mais il y a 2 touches) qui a besoin d'un coupleur de bus. Le
> choix du coupleur de bus influe-t-il sur les fonctionnalités
> accessibles aux touches ?
En principe, non.
Les fonctionnalités sont déterminées par l'application chargée dans le
device.
Quand tu regardes l'offre d'un fabriquant, il n'y a que 2-3 types de
BCU.
Chez Merten 1-fach, 2-fach, 4-fach ont le même BCU (BCU1)
Les applications plus évoluées ont besoin d'un BCU de type 2 (ou plus)
> si je veux utiliser les deux
> touches pour commander deux points lumineux différents (commutation
> sur une seule touche comme l'évoque spiffou, mode "inverseur"), est-ce
> possible avec n'importe quel coupleur de bus (y compris ceux indiquant
> "1-fach")
cfr plus haut
Je ne connais pas le Gira, mais je crois bien que oui
D'abord paramètrer le BP en toggle
ensuite associer l'object A du BP avec un GA1 pour la lampe L1
et associer l'object B du BP avec un GA2 pour la lampe L2
> Je ne peux pas encore jouer avec ETS
et qu'est ce qui t'empêche ?
tu n'as pas de PC avec une connexion Internet pour downloader la
version démo ?
> et je suis très troublé par le "1-fach = 2 boutons"...
ils emploient le mot "fach" ou "gang" (comme en anglais)
Donc un BP "4-fach" ou "4-gang" a 4 rangées de 2 boutons
Dans certains pays, les utilisateurs préfèrent programmer une rangée
du BP en On/Off (c'est mon cas), d'autres les programment en toggle.
Merci encore une fois pour tes explications!
> C'est une question d'association dans les GA et de setting des Flags
> dans ETS
Ok! Les settings sont à paramétrer dans certains cas et dans d'autres
à laisser par défaut.
> L'objet indication d'état fait partie de ***l'actuator***, pas du
> capteur !
> L'actuator "sait" s'il est ON ou OFF
Ok, j'ai fait une grosse confusion et cela explique ma réponse dans un
autre sujet (avis sur ma future installation) où je fais la même
confusion!
Cette erreur m'a été induite par l'objet indication d'état sous ETS du
BP Hager WKT306. J'ai cru que cet objet était important.
Par contre, j'ai clairement compris que l'objet important sur les
actionneurs est "retour d'information".
J'essaierai le mode Toggle et ferai un retour sur ce point.
> Ma maison est équipée de Merten Artec 622644 (4xBP)
Je ne connaissais pas ce BP, je viens de le trouver sur le site de
Merten et non sur Schneider France.
C'est comme certains composants Hager typique Allemagne.
Merci de l'info, je vais l'étudier mais j'aime bien le principe des
boutons qui s'allument.
> Les applications que je connais (Hager, Merten, Berker) permettent le
> choix On/Off ou toggle, mais çà n'est pas "Tous les interrupteurs .."
Merci de ce retour et çà répond à ma question.
Spiffou
On 16 août, 11:44, spiffou <spiffo...@gmail.com> wrote:
> j'aime bien le principe des boutons qui s'allument.
Perso, c'est ce qui m'a séduit.
Au risque de me faire incendier par les défenseurs des BP mécaniques
avec entrée binaire (nettement moins cher), je ne conçois pas la
domotique sans ces petits "features" qui augment le confort et
facilitent la vie.
exemple d'effet collatéral:
si dans une chambre tu as un quad BP,
dont 1/2 est/sont dédicacés à l'éclairage de la chambre
dont 2 autres commandent l'éclairage palier, couloir, escalier
tu peux voir si ces lampes sont restées allumées, sans te lever
autre exemple d'effet collatéral:
au repos, les BP sont légèrement illuminés par un halo vert, ce qui
permet de les localiser dans le noir (cette fonction peut être
désactivée dans ETS)
en service, les BP sont illuminés par un halo rouge.
marc.assin wrote:
> > j'aime bien le principe des boutons qui s'allument.
>
> Perso, c'est ce qui m'a séduit.
Entièrement d'accord, c'est vraiment dommage de s'en priver pour une
économie négligeable par rapport au coût total.
De plus le voyant est généralement contrôlé indépendamment de la
fonction du bouton. J'ai un poussoir à côté de la porte d'entrée dont
le voyant est un OU logique de tous les éclairages du logement. Et ce
poussoir envoie la commande d'extinction générale, évidemment.
> autre exemple d'effet collatéral:
> au repos, les BP sont légèrement illuminés par un halo vert, ce qui
> permet de les localiser dans le noir (cette fonction peut être
> désactivée dans ETS)
Encore plus fort : Les Hager WKT ont une étiquette rétro-éclairée,
dont l'éclairage peut être commandé par le bus. Dans les chambres je
les fais allumer par les détecteurs de mouvement. Non seulement ça
permet de les localiser, mais ça éclaire aussi suffisamment pour
circuler la nuit sans allumer le plafonnier.
> Comme vous l'avez compris, je ne parle malheureusement pas la langue
> de Goethe... et je suis très troublé par le "1-fach = 2 boutons"...
Une manière de comprendre est de voir le bouton comme un organe qui va
commander tout, pas seulement du ON/OFF de lumiere. L'interrupteur
pour store "standard" a deux boutons: un pour monter, un pour
descendre. C'est également une option relativement ergonomique pour un
variateur: plus fort et moins fort.
Il y a également le cas de la scène: "tout éteindre" est un exemple,
mais on peut en imaginer d'autres: "manger" qui allume la lumiere sur
la table, varie ce spot a 50%, baisse les stores, etc etc. La commande
d'une scène est impulsionnelle: on "appelle" la scène d'un appui sur
le bouton. Si on appuie de nouveau, on n'"éteint" pas la scène, on la
rappelle.
Le "bouton" KNX (fach, ou gang) est fait pour pouvoir implémenter
toutes ces sortes de boutons physiques.
Alors bien entendu avec des appuis plus ou moins longs sur un "demi"
bouton (au sens KNX) tu peux t'en sortir, mais c'est pas top facile
pour un store par exemple.
Il faut également penser à l'avenir car un des avantages de KNX c'est
sa flexibilité dans le temps, surtout par exemple dans une chambre
d'enfant qui grandit. J'ai tout planifié au début avec 1-fach == 1
bouton, en me disant que si par la suite j'avais besoin, je pouvais
toujours "gagner un bouton" en le divisant en deux (ce qui est
arrivé).
Fred
> 1) Exemple : comment réaliser un va et vient (2 capteurs ou plus) ?
> Par exemple, quand j'arrive dans une pièce, je veux allumer avec le
> bouton poussoir A (ON) et quand je quitte la pièce, je veux éteindre
> avec un autre bouton poussoir B (OFF). Je ne sais pas si quand je fais
> ON sur le BP A, le BP B va savoir qu'il faut envoyer OFF sur sa trame
> en destination de l'actionneur (et inversement !).
Il sait. Tu confonds deux notions: la logique de commande et la
logique de retour d'état. Cette derniere est discutée dans les
messages précédents:
Certains actionneurs proposent un objet de retour d'état qui indique
l'état de la sortie en question. L'actionneur veille à ce que l'état
transmis (de manière automatique et asynchrone par l'actuateur,
parfois de maniere repetitive (configurable)) sur le bus soit juste.
Certains interrupteurs proposent une entrée pour un tel objet de
retour d'état qui, en général, controle une LED sur l'interrupteur.
L'utilité du bignou est brillement exposée dans les messages
précédents. Pour que ca marche il faut une GA "retour d'état lampe X",
distincte de la GA "commande lampe X" (et selon les cas, il faut avoir
configuré l'interrupteur de manière idoine).
Mais TOUS les interrupteurs conservent en mémoire l'état de "commande
lampe X" - ils sont capables d'envoyer un telegramme sur cette GA pour
commander la lampe, mais ils écoutent également les messages qui
passent. Donc deux interrupteurs sans retour d'état configures en
toggle sur une meme GA, ca marche. Le second "voit" le message "lampe
X on" passer et "sait" qu'il doit envoyer "lampe X off".
Donc:
* Pas besoin d'option "retour d'etat" sur les interrupteurs pour faire
marcher un va et viens. L'interrupteur conserve dans tous les cas
l'état de l'objet (la lampe) au moyen des telegrammes de commande sur
le bus.
* L'option "retour d'etat" permet de modifier cette valeur dans
l'interrupteur, et permet de gérer les cas ou l'état de l'objet change
sans message sur le bus (par exemple en cas de forcage, commande
locale, etc).
Fred
fred wrote:
> Mais TOUS les interrupteurs conservent en mémoire l'état de "commande
> lampe X" - ils sont capables d'envoyer un telegramme sur cette GA pour
> commander la lampe, mais ils écoutent également les messages qui
> passent. Donc deux interrupteurs sans retour d'état configures en
> toggle sur une meme GA, ca marche. Le second "voit" le message "lampe
> X on" passer et "sait" qu'il doit envoyer "lampe X off".
Euh... avec les interrupteurs de quel constructeur ?
Si je me souviens bien, avec mes poussoirs Hager WKT, ça ne marche pas
comme ça. Il faut impérativement connecter la GA de retour d'état (ou
la GA de commande, dans les cas simples) sur l'entrée "status
indication" de l'interrupteur, sinon le va-et-vient ne fonctionne pas.
À ma connaissance, cette entrée "status indication" ne sert qu'à ça.
D'ailleurs elle n'est visible dans ETS que si le poussoir est
configuré en mode "télérupteur" (et pas si il est configuré en mode
"on/off"). Le voyant, lui, est commandé par une entrée dédiée
complètement indépendante.
Mathieu Gallissot
Unregistered
Alors, le bouton poussoir à deux group objects dans une application On/Off :
un datapoint de commande, et un datapoint de status.
- le datapoint de commande sert à commander l'actionneur, avec deux choix,
on ou off.
- le datapoint de status permet de connaître l'état de la sortie de
l'actionneur, on ou off.
Selon les modèles, le datapoint de status permet d'allumer ou non une led
sur l'interrupteur, reportant ainsi l'état de la sortie commandée.
En ce qui concerne l'application "toggle", ou "bascule", il faut absolument
que le datapoint status soit configuré. Le bouton pousoir va ainsi inverser
le status et l'envoyer en commande. Il n'y a pas de "magie" avec une lecture
sur le datapoint de commande, c'est contraire à la norme KNX, et à la
logique de groupe (car une voie d'actionneur peut être pilotée sur plusieurs
adresses de groupe, mais on ne peut avoir qu'un seul status). Donc fred, je
pense pas que tu ais fournit la bonne explication.
Pascal, en utilisant la même adresse de groupe pour la commande et le
status, ça marche, sauf si ton actionneur à plusieurs adresses de groupes en
entrée.
Pour plus d'info, pour ceux qui ont accès à la norme, on peut consulter le
S12 avec le channel E-Mode correspondant à cette application ou le
fonctionnal block "toggle".
2009/8/17 Pascal <pb115290@pabr.org>
>
> fred wrote:
> > Mais TOUS les interrupteurs conservent en mémoire l'état de "commande
> > lampe X" - ils sont capables d'envoyer un telegramme sur cette GA pour
> > commander la lampe, mais ils écoutent également les messages qui
> > passent. Donc deux interrupteurs sans retour d'état configures en
> > toggle sur une meme GA, ca marche. Le second "voit" le message "lampe
> > X on" passer et "sait" qu'il doit envoyer "lampe X off".
>
> Euh... avec les interrupteurs de quel constructeur ?
>
> Si je me souviens bien, avec mes poussoirs Hager WKT, ça ne marche pas
> comme ça. Il faut impérativement connecter la GA de retour d'état (ou
> la GA de commande, dans les cas simples) sur l'entrée "status
> indication" de l'interrupteur, sinon le va-et-vient ne fonctionne pas.
>
> À ma connaissance, cette entrée "status indication" ne sert qu'à ça.
> D'ailleurs elle n'est visible dans ETS que si le poussoir est
> configuré en mode "télérupteur" (et pas si il est configuré en mode
> "on/off"). Le voyant, lui, est commandé par une entrée dédiée
> complètement indépendante.
>
Mathieu Gallissot wrote:
> Pascal, en utilisant la même adresse de groupe pour la commande et le
> status, ça marche, sauf si ton actionneur à plusieurs adresses de groupes en
> entrée.
Oui, c'est ma solution (1) dans l'autre discussion récente sur le
sujet.
Et si l'actionneur est commandé par plusieurs AG, il suffit de toutes
les connecter à l'entrée "status" de chaque interrupteur, et ça marche
aussi. Par exemple mes actionneurs ont souvent deux AG en entrées,
une pour la commande individuelle et une pour l'extinction générale,
et je connecte les deux aux entrées "status" des interrupteurs.
Je dois simplement veiller à ce que le flag "S" soit sur l'AG
individuelle, afin que les appareils n'émettent pas sur l'AG
d'extinction générale lorsqu'une visu interroge leur état. Mais quand
on en arrive à devoir débugger ce genre de chose, il est peut-être
temps de séparer les AG de commande et de retour d'état, comme tu le
préconisais...
Mathieu Gallissot
Unregistered
Oui oui, ça marche, mais c'est un 'hack' typique du S-Mode, pas vraiment
dans les règles.
Tu peut pas garantir que ça marche avec tous les produits. Par exemple,
certains produits merten vérifient leur config au redémarrage (après coupure
de courant), si celle-ci est inconsistante (adresses de groupe identique en
entrée et en sortie), elle est effacée.
2009/8/17 Pascal <pb115290@pabr.org>
>
> Mathieu Gallissot wrote:
> > Pascal, en utilisant la même adresse de groupe pour la commande et le
> > status, ça marche, sauf si ton actionneur à plusieurs adresses de groupes
> en
> > entrée.
>
> Oui, c'est ma solution (1) dans l'autre discussion récente sur le
> sujet.
>
> Et si l'actionneur est commandé par plusieurs AG, il suffit de toutes
> les connecter à l'entrée "status" de chaque interrupteur, et ça marche
> aussi. Par exemple mes actionneurs ont souvent deux AG en entrées,
> une pour la commande individuelle et une pour l'extinction générale,
> et je connecte les deux aux entrées "status" des interrupteurs.
>
> Je dois simplement veiller à ce que le flag "S" soit sur l'AG
> individuelle, afin que les appareils n'émettent pas sur l'AG
> d'extinction générale lorsqu'une visu interroge leur état. Mais quand
> on en arrive à devoir débugger ce genre de chose, il est peut-être
> temps de séparer les AG de commande et de retour d'état, comme tu le
> préconisais...
>
Merci pour vos réponses.
> > Je ne peux pas encore jouer avec ETS
>
> et qu'est ce qui t'empêche ?
> tu n'as pas de PC avec une connexion Internet pour downloader la
> version démo ?
Je n'ai plus de Windows pour l'instant, et Wine sous Linux et Darwine
sous MacOs n'aiment pas vraiment ETS... juste à cause de son
utilisation d'Internet Explorer, grrrr.
J'ai hâte d'explorer ETS et de comprendre comment assigner une adresse
de groupe par bouton, ça me rassurera.
On 16 août, 23:50, fred <frederic.thomas...@gmail.com> wrote:
> > Comme vous l'avez compris, je ne parle malheureusement pas la langue
> > de Goethe... et je suis très troublé par le "1-fach = 2 boutons"...
>
> Une manière de comprendre est de voir le bouton comme un organe qui va
> commander tout, pas seulement du ON/OFF de lumiere. L'interrupteur
> pour store "standard" a deux boutons: un pour monter, un pour
> descendre. C'est également une option relativement ergonomique pour un
> variateur: plus fort et moins fort.
Oui, très juste.
J'ai en fait commencé par m'intéresser aux boutons poussoirs Kallysta
de chez Hager, et ils comptent les boutons directement (ex : 4
entrées, 6 entrées...), puis je suis tombé sur les sites allemands
(via ebay), et là, c'était un poil différent.
> Alors bien entendu avec des appuis plus ou moins longs sur un "demi"
> bouton (au sens KNX) tu peux t'en sortir, mais c'est pas top facile
> pour un store par exemple.
Tout à fait d'accord !
> Il faut également penser à l'avenir car un des avantages de KNX c'est
> sa flexibilité dans le temps, surtout par exemple dans une chambre
> d'enfant qui grandit. J'ai tout planifié au début avec 1-fach == 1
> bouton, en me disant que si par la suite j'avais besoin, je pouvais
> toujours "gagner un bouton" en le divisant en deux (ce qui est
> arrivé).
J'aime aussi cette idée d'avoir un peu de réserve, mais (c'est un goût
personnel) appuyer sur le même bouton pour allumer et éteindre un
point lumineux me semble plus séduisant (pas pour les volets roulants,
c'est sûr).
N.
> > Mais TOUS les interrupteurs conservent en mémoire l'état de "commande
> > lampe X" - ils sont capables d'envoyer un telegramme sur cette GA pour
> > commander la lampe, mais ils écoutent également les messages qui
> > passent. Donc deux interrupteurs sans retour d'état configures en
> > toggle sur une meme GA, ca marche. Le second "voit" le message "lampe
> > X on" passer et "sait" qu'il doit envoyer "lampe X off".
>
> Euh... avec les interrupteurs de quel constructeur ?
>
> Si je me souviens bien, avec mes poussoirs Hager WKT, ça ne marche pas
> comme ça. Il faut impérativement connecter la GA de retour d'état (ou
Tu as raison, en voulant simplifier j'ai commis une erreur 
Si l'interrupteur dispose d'une entree "retour d'état", il faut
impérativement la "cabler" dans un GA approprié, effectivement. Je
voulais dire que tous les interrupteurs, qu'ils disposent ou pas d'une
entrée "retour d'état", étaient capables de faire du va et viens (ce
qui était la question originale de spiffou).
> En ce qui concerne l'application "toggle", ou "bascule", il faut absolument
> que le datapoint status soit configuré. Le bouton pousoir va ainsi inverser
> le status et l'envoyer en commande. Il n'y a pas de "magie" avec une lecture
> sur le datapoint de commande, c'est contraire à la norme KNX, et à la
> logique de groupe (car une voie d'actionneur peut être pilotée sur plusieurs
> adresses de groupe, mais on ne peut avoir qu'un seul status). Donc fred, je
> pense pas que tu ais fournit la bonne explication.
(a) Nous parlons justement d'un cas ou l'interrupteur ne propose PAS
le fameux datapoint status. Ca existe, j'en ai. J'ai également des
actionneurs sans status. La question originale est: quid si cet objet
n'est pas la ?
(b) Tout objet avec flag W se voit modifié si un télégramme write
passe sur le bus pour le changer. C'est du copié collé de l'aide de
ETS. "magie" ?
Mes interrupteurs Gira ont tous le flag W sur le datapoint de
commande, même ceux qui ont un datapoint status. De mémoire c'est la
même chose sur les Berker et sur les Siemens de la démo que j'ai
analysé en 2002.
© Pour ton cas, il suffit de mettre le datapoint de commande de
l'interrupteurs dans TOUS les groupes de l'actionneur, mais de ne le
faire envoyer que sur son groupe principal (sending). Ainsi, l'état
interne de l'interrupteur sera correct (sauf pour cas compliqué comme
forçages, etc).
Fred
Mathieu Gallissot
Unregistered
(a) Si l'objet status n'est pas là (ce qui est de plus en plus rare), et
bien la norme est claire, on ne fait pas de "toggle".
(b) C'est de la logique dans les adresses de groupe, pas dans l'application.
© Oui, mais dans ce cas, comment je fait avec ma supervision ?
Tout est toujours possible, comme tu l'as démontré. Mais KNX est une norme,
et les applications sont définies dans le cadre de "l'interworking". Dans ce
cas, il y a une application "sans status", et une "avec status". La
possibilité de faire du toggle n'est possible que lorsque l'objet "status"
est configuré (dixit la norme). Si on sort de ces définitions, on risque de
perdre l'interopérabilité (comme tu le cite avec le forçage).
2009/8/18 fred <frederic.thomas.ch@gmail.com>
>
> > En ce qui concerne l'application "toggle", ou "bascule", il faut
> absolument
> > que le datapoint status soit configuré. Le bouton pousoir va ainsi
> inverser
> > le status et l'envoyer en commande. Il n'y a pas de "magie" avec une
> lecture
> > sur le datapoint de commande, c'est contraire à la norme KNX, et à la
> > logique de groupe (car une voie d'actionneur peut être pilotée sur
> plusieurs
> > adresses de groupe, mais on ne peut avoir qu'un seul status). Donc fred,
> je
> > pense pas que tu ais fournit la bonne explication.
>
> (a) Nous parlons justement d'un cas ou l'interrupteur ne propose PAS
> le fameux datapoint status. Ca existe, j'en ai. J'ai également des
> actionneurs sans status. La question originale est: quid si cet objet
> n'est pas la ?
>
> (b) Tout objet avec flag W se voit modifié si un télégramme write
> passe sur le bus pour le changer. C'est du copié collé de l'aide de
> ETS. "magie" ?
> Mes interrupteurs Gira ont tous le flag W sur le datapoint de
> commande, même ceux qui ont un datapoint status. De mémoire c'est la
> même chose sur les Berker et sur les Siemens de la démo que j'ai
> analysé en 2002.
>
> © Pour ton cas, il suffit de mettre le datapoint de commande de
> l'interrupteurs dans TOUS les groupes de l'actionneur, mais de ne le
> faire envoyer que sur son groupe principal (sending). Ainsi, l'état
> interne de l'interrupteur sera correct (sauf pour cas compliqué comme
> forçages, etc).
>
> Fred
A ma connaissance, seul les boutons Hager disposent d'un objet "retour
d'état", c'est dû à la possibilité de les paramétrer via TX100.
Chez les autres fabricants, il n'y en a pas besoin, il suffit de
mettre l'adresse de groupe "état" renvoyée par l'actionneur, en 2nde
adresse sur l'objet de commande du bouton concerné (flag Ecriture et
Transmission activé). Cela met à jour l'objet de communication, très
utile en cas de commande groupés ou de scènes, pour ne pas avoir à
appuyer 2 fois sur un bouton.
@+
On 18 août, 09:19, Mathieu Gallissot
<mathieu.gallis...@googlemail.com> wrote:
> (a) Si l'objet status n'est pas là (ce qui est de plus en plus rare), et
> bien la norme est claire, on ne fait pas de "toggle".
> (b) C'est de la logique dans les adresses de groupe, pas dans l'application.
> © Oui, mais dans ce cas, comment je fait avec ma supervision ?
>
> Tout est toujours possible, comme tu l'as démontré. Mais KNX est une norme,
> et les applications sont définies dans le cadre de "l'interworking". Dans ce
> cas, il y a une application "sans status", et une "avec status". La
> possibilité de faire du toggle n'est possible que lorsque l'objet "status"
> est configuré (dixit la norme). Si on sort de ces définitions, on risque de
> perdre l'interopérabilité (comme tu le cite avec le forçage).
>
> 2009/8/18 fred <frederic.thomas...@gmail.com>
>
>
>
> > > En ce qui concerne l'application "toggle", ou "bascule", il faut
> > absolument
> > > que le datapoint status soit configuré. Le bouton pousoir va ainsi
> > inverser
> > > le status et l'envoyer en commande. Il n'y a pas de "magie" avec une
> > lecture
> > > sur le datapoint de commande, c'est contraire à la norme KNX, et à la
> > > logique de groupe (car une voie d'actionneur peut être pilotée sur
> > plusieurs
> > > adresses de groupe, mais on ne peut avoir qu'un seul status). Donc fred,
> > je
> > > pense pas que tu ais fournit la bonne explication.
>
> > (a) Nous parlons justement d'un cas ou l'interrupteur ne propose PAS
> > le fameux datapoint status. Ca existe, j'en ai. J'ai également des
> > actionneurs sans status. La question originale est: quid si cet objet
> > n'est pas la ?
>
> > (b) Tout objet avec flag W se voit modifié si un télégramme write
> > passe sur le bus pour le changer. C'est du copié collé de l'aide de
> > ETS. "magie" ?
> > Mes interrupteurs Gira ont tous le flag W sur le datapoint de
> > commande, même ceux qui ont un datapoint status. De mémoire c'est la
> > même chose sur les Berker et sur les Siemens de la démo que j'ai
> > analysé en 2002.
>
> > © Pour ton cas, il suffit de mettre le datapoint de commande de
> > l'interrupteurs dans TOUS les groupes de l'actionneur, mais de ne le
> > faire envoyer que sur son groupe principal (sending). Ainsi, l'état
> > interne de l'interrupteur sera correct (sauf pour cas compliqué comme
> > forçages, etc).
>
> > Fred
> (a) Si l'objet status n'est pas là (ce qui est de plus en plus rare), et
> bien la norme est claire, on ne fait pas de "toggle".
Je ne comprends pas ca de la norme. La section qui definit le
fonctional block toggle est dans S7 qui est introduit par:
"These Functional Blocks shall be used only for implementation of Easy
Configuration mode devices.
These Functional Block specifications shall not be used for any other
goal; in particular, no
implementation for S-Mode or A-Mode devices shall be based on these
specifications. "
Avec ETS, on est en S-Mode.
> (b) C'est de la logique dans les adresses de groupe, pas dans l'application.
Moui. Et ca sert à quoi?
La norme dit:
"[..] the (local) application sees the bus as a limited set of Group
objects; these correspond to those
Datapoints, which are of direct relevance to it. Put simply, each
Communication Object appears to its
application as a local variable with supporting attributes. Not
surprisingly, the variable holds the value
received from, or to be sent to the bus. Via the attributes, a default
handler on top of the node’s
communication stack can inform the application that the corresponding
value has been updated; vice
versa, the application can request the stack to send a value."
(Vol3 Part 1 Chapter 1, $ 4.2)
> © Oui, mais dans ce cas, comment je fait avec ma supervision ?
Dans ce modele, une visu qui fait du READ n'est pas supporté, non. Une
visu qui fait comme un device (qui cache la valeur, comme linknx le
fait je crois) marche. Et le TOGGLE, aussi.
Fred
Mathieu Gallissot
Unregistered
Oooops, ça m'apprendra à pas lire l'intro des docs. Bon, au moins, pour les
WKT d'Hager, c'est clair, idem pour les autres produits E+S.
Je comprenais (jusqu'ici) l'aspect de la norme de normaliser autant les
applications que le format de données échangées, ce qui n'est effectivement
pas le cas en S-Mode.
2009/8/18 fred <frederic.thomas.ch@gmail.com>
>
> > (a) Si l'objet status n'est pas là (ce qui est de plus en plus rare), et
> > bien la norme est claire, on ne fait pas de "toggle".
>
> Je ne comprends pas ca de la norme. La section qui definit le
> fonctional block toggle est dans S7 qui est introduit par:
>
> "These Functional Blocks shall be used only for implementation of Easy
> Configuration mode devices.
> These Functional Block specifications shall not be used for any other
> goal; in particular, no
> implementation for S-Mode or A-Mode devices shall be based on these
> specifications. "
>
> Avec ETS, on est en S-Mode.
>
> > (b) C'est de la logique dans les adresses de groupe, pas dans
> l'application.
>
> Moui. Et ca sert à quoi?
> La norme dit:
>
> "[..] the (local) application sees the bus as a limited set of Group
> objects; these correspond to those
> Datapoints, which are of direct relevance to it. Put simply, each
> Communication Object appears to its
> application as a local variable with supporting attributes. Not
> surprisingly, the variable holds the value
> received from, or to be sent to the bus. Via the attributes, a default
> handler on top of the node’s
> communication stack can inform the application that the corresponding
> value has been updated; vice
> versa, the application can request the stack to send a value."
> (Vol3 Part 1 Chapter 1, $ 4.2)
>
> > © Oui, mais dans ce cas, comment je fait avec ma supervision ?
>
> Dans ce modele, une visu qui fait du READ n'est pas supporté, non. Une
> visu qui fait comme un device (qui cache la valeur, comme linknx le
> fait je crois) marche. Et le TOGGLE, aussi.
>
> Fred
>
>
> Je comprenais (jusqu'ici) l'aspect de la norme de normaliser autant les
> applications que le format de données échangées, ce qui n'est effectivement
> pas le cas en S-Mode.
Il y a trop de hacks déployés en S-Mode pour la lumiere pour
normaliser d'un coup 
Et la norme a "raison": avec un retour, c'est mieux!
Bonjour Spiffou,
J'ai eu le même problème que toi pour la gestion de 2 inters (2
positions et non un BP) et une sortie, afin de câbler au mieux un va
et vient.
La solution la plus simple, reste d'intégrer un bloc logique OU
Exclusif (pour rappel sur un OU Exclusif, si les 2 entrées sont à 1,
la sortie passe à 0)
- affecte les 2 inters en ON/OFF sur les 2 entrées du OU Exclusif
- utilise la sortie de ton OU Exclusif pour faire un ON/OFF sur ta
sortie lampe en question.
Cela fonctionne trés bien chez moi, et plus de problème de retour
d'état, de coupure de courant (car la position reste la même après le
retour du courant).
|
