27/10/2007, 17:51:48
Ah, Jean-François ! tu retournes le couteau dans la plaie (tu as peut-
être lu la saga des BP Merten, status feedback et BCU 1 ? )
> lorsque la temporisation éteint, le poussoir n'est pas informé et son état interne >reste à "ON".
En effet, c'est un des cas de figure "incohérent" (j'en mentionne un
autre plus bas)
>2) On assigne une première addresse de groupe au poussoir et à
l'actuateur, ensuite une autre addresse de groupe au retour de status
et au poussoir.
Je pense que c'est la manière la plus orthodoxe d'avoir un feedback
valable, à condition que le matos le permette.
>Quelle méthode utilisez vous?
En tant que débutant, j'ai utilisé la première :-)
Puis, un "pro" m'a rapidement fait comprendre que çà ne tient pas la
route :-( (credit: BVO).
Exemple très concret (non, ce n'est pas "tiré par les cheveux", et
oui, çà m'est arrivé récemment) qui illustre l'inconvénient de la
première méthode.
Un BP commande une lampe.
Feedback sur le BP.
Au moment d'appuyer sur le BP, paf, la lampe (petit spot hallogène de
150W)
claque et fait sauter le DJ en amont.
Le BP dit que la lampe est allumée, malchance hein ;-)
Dans le cas de la seconde méthode, l'actuator est incapable de donner
son feedback, le BP reste éteint, ce qui réflète la situation réelle.
Même si on trouve mon exemple un peu "extrème", je vois d'autres cas
de figure du même style, où qq chose s'est passé en amont de
l'actuator (phase manquante en triphasé, DJ diff de tête déclenché,
actuator foutu). Perso, çà m'a convaincu, je ne vois aucun avantage de
la première méthode, j'ai complètement revu mon projet.
> j'ai utilisé la première méthode car elle me paraît plus simple
Boaf, à peine
> Ou alors peut-être que certains actuateurs ne permettent pas d'assigner
la même adresse à l'objet de commande et de status...
Je ne connais pas ce cas de figure.
Par contre, ce qui m'irrite au plus haut point, c'est le manque de
status feedback de la part de l'actuator. J'en ai encore fait les
frais récemment avec un actuator Merten 8x10A, flambant neuf, où seul
le canal A a le status :-( (grrrr)
Oui, on va encore me dire qu'il fallait bien évaluer l'application
avant d'acheter, c'est comme aller chez le boucher, lui demander un
steak de 50gr, voir s'il est bon avant de lui acheter les 100gr.
> Pour faire une fonction centrale qui éteint tout
Perso, pas encore fait, mais les "good practices" voudrais qu'on ne
confie pas de fonctions vitales au HS, donc je vais opter pour le #2
>2) vous ajoutez l'adresse de groupe de la fonction all-off comme
>seconde addresse sur tous les objets de communication que vous voulez
>éteindre de manière centrale.
PS: à propos de status, et d'actuator qui n'ont pas de feedback, le HS
a une option bien pratique, la "watch address" (çà consiste à tricher
un peu, mais permet de rester cohérent avec l'architecture du projet).
La "watch address" est en fait une nouvelle GA créé pour la cause et
qui est piloté par un autre objet au choix, par exemple:
0/6/21 lampe X1 ON,
0/6/22 status lampe X1 (bien que l'actuator n'a PAS de feedback sur la
porte employée)
être lu la saga des BP Merten, status feedback et BCU 1 ? )
> lorsque la temporisation éteint, le poussoir n'est pas informé et son état interne >reste à "ON".
En effet, c'est un des cas de figure "incohérent" (j'en mentionne un
autre plus bas)
>2) On assigne une première addresse de groupe au poussoir et à
l'actuateur, ensuite une autre addresse de groupe au retour de status
et au poussoir.
Je pense que c'est la manière la plus orthodoxe d'avoir un feedback
valable, à condition que le matos le permette.
>Quelle méthode utilisez vous?
En tant que débutant, j'ai utilisé la première :-)
Puis, un "pro" m'a rapidement fait comprendre que çà ne tient pas la
route :-( (credit: BVO).
Exemple très concret (non, ce n'est pas "tiré par les cheveux", et
oui, çà m'est arrivé récemment) qui illustre l'inconvénient de la
première méthode.
Un BP commande une lampe.
Feedback sur le BP.
Au moment d'appuyer sur le BP, paf, la lampe (petit spot hallogène de
150W)
claque et fait sauter le DJ en amont.
Le BP dit que la lampe est allumée, malchance hein ;-)
Dans le cas de la seconde méthode, l'actuator est incapable de donner
son feedback, le BP reste éteint, ce qui réflète la situation réelle.
Même si on trouve mon exemple un peu "extrème", je vois d'autres cas
de figure du même style, où qq chose s'est passé en amont de
l'actuator (phase manquante en triphasé, DJ diff de tête déclenché,
actuator foutu). Perso, çà m'a convaincu, je ne vois aucun avantage de
la première méthode, j'ai complètement revu mon projet.
> j'ai utilisé la première méthode car elle me paraît plus simple
Boaf, à peine
> Ou alors peut-être que certains actuateurs ne permettent pas d'assigner
la même adresse à l'objet de commande et de status...
Je ne connais pas ce cas de figure.
Par contre, ce qui m'irrite au plus haut point, c'est le manque de
status feedback de la part de l'actuator. J'en ai encore fait les
frais récemment avec un actuator Merten 8x10A, flambant neuf, où seul
le canal A a le status :-( (grrrr)
Oui, on va encore me dire qu'il fallait bien évaluer l'application
avant d'acheter, c'est comme aller chez le boucher, lui demander un
steak de 50gr, voir s'il est bon avant de lui acheter les 100gr.
> Pour faire une fonction centrale qui éteint tout
Perso, pas encore fait, mais les "good practices" voudrais qu'on ne
confie pas de fonctions vitales au HS, donc je vais opter pour le #2
>2) vous ajoutez l'adresse de groupe de la fonction all-off comme
>seconde addresse sur tous les objets de communication que vous voulez
>éteindre de manière centrale.
PS: à propos de status, et d'actuator qui n'ont pas de feedback, le HS
a une option bien pratique, la "watch address" (çà consiste à tricher
un peu, mais permet de rester cohérent avec l'architecture du projet).
La "watch address" est en fait une nouvelle GA créé pour la cause et
qui est piloté par un autre objet au choix, par exemple:
0/6/21 lampe X1 ON,
0/6/22 status lampe X1 (bien que l'actuator n'a PAS de feedback sur la
porte employée)