Bonjour,
En discutant avec plusieures personnes différentes du problème de
retour de status, j'ai remarqué qu'il y avait différentes manière de
le faire en pratique. Prenons un example:
J'ai un éclairage d'escalier temporisé avec plusieurs boutons
poussoirs. Si les bourons poussoirs envoient toujours un message "ON"
sur le bus quand on appuie dessus, pas de problème, pas besoin de
retour de status (sauf éventuellement pour une visu mais oublions là
pour garder le problème simple). Si par contre les boutons poussoirs
sont en mode "toggle" (bascule), une première pression permet
d'allumer et une deuxième permet d'éteidre. Si on laisse allumé, ça
s'éteint tout seul avec la temporisation. Dans ce cas, on à un
problème de retour de status puisque le bouton poussoir retient l'état
actuel dans une variable interne pour pouvoir basculer dans l'état
inverse si on appuie dessus. Mais lorsque la temporisation éteint, le
poussoir n'est pas informé et son état interne reste à "ON". Dans ce
cas, si on appuie dessus, il enverra un "OFF" alors que la lumière est
déjà éteinte et rien ne se passe...
Pour résoudre ce problème, il existe sur beaucoup d'actuateurs
(malheureusement pas tous) des objets de communication de "status"
qui transmettent la valeur de sortie lorsqu'elle change. C'est ici que
je vois 2 manières différentes de procéder:
1) On assigne la même addresse de groupe à l'objet de communication du
poussoir, de l'actuateur et du retour de status.
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. Dans ce cas, le poussoir a 2 addresses sur le même
objet de communication. Seule la première sera utilisée par le
poussoir pour envoyer de l'information, la seconde servant à recevoir
le retour de status
Quelle méthode utilisez vous? La première, la seconde ou encore une
autre?
Quels sont les avantages / limitations de l'une ou l'autre?
Chez moi j'ai utilisé la première méthode car elle me paraît plus
simple mais elle à peut-être des limitations que je ne connaît pas. Ou
alors peut-être que certains actuateurs ne permettent pas d'assigner
la même adresse à l'objet de commande et de status...
Question subsidiaire: Pour faire une fonction centrale qui éteint
tout, vous utilisez:
1) des fonctions logiques (intégrées aux actuateurs ou en module
séparé, voire homeserver)
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.
Pour mon install, j'utilise une combinaison des deux systèmes. Pour
les lumières, solution 1, pour les thermostats, j'attaque l'objet
"ouverture de fenêtre" avec comme seconde adresse celle de la fonction
all-off, ce qui me permet de couper tous les thermostats d'un coup. Le
seul problème, (qui n'en est pas vraiment un puisqu'on ne le voit
qu'en sniffant ce qui se passe sur le bus) c'est que quand je fait une
lecture de la valeur de la fonction all-off, tous les objets
"ouverture de fenêtre" y répondent avec leur addresse de groupe
principale, c'est normal, ou alors c'est un bug?
Bav,
Jean-François
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)
Bonsoir,
Voici mon retour d'expérience:
STATUS
>Quelle méthode utilisez vous? La première, la seconde ou encore une autre?
Désormais, je programme en utilisant systématiquement deux adresses de
groupe (ta méthode #2). Je l’ai fait depuis qu'un changement de
version logicielle de mes switchs (ABB) leur a donné un retour de
status systématiquement disponible pour chaque sortie :-)
En avantages
- Le majeur : Le status renvoyé par l’actuator est obligatoirement le
plus juste puisque seul l’actuator connaît la vraie position du relai
de sortie.
- En corolaire, lorsque le switch dispose d’une commande manuelle, le
status est aussi transmis lors d’une manœuvre du relai à la main.
C’est plutôt imparable.
- Ceci permet d’utiliser plusieurs adresses de groupe pour commander
le même actuator et conserver sans problème une visualisation juste de
l’état. Et tout pareil lorsque la commande est déclenchée via une «
scène ».
- Cela permet d’être très clair avec les flags Read => Pas de Read
pour la commande Switch et Read pour le Status. C’est très confortable
pour les superviseurs qui sont assurés lors du scan de démarrage de
récupérer des états fiables.
Comme inconvénients :
- Le flux du bus est multiplié par deux (tout message de changement
d’état ON/OFF est doublé d’un status). Donc à prendre en compte dans
l’analyse de charge.
- Les adresses de groupe sont doublées, ce qui peut faire atteindre
très vite les limites de certaines licences (Ex Serveur OPC de la
Konnex)
Nota : J’ai été confronté à certains interrupteurs qui ne disposent
pas de messages spécifiques permettant de piloter les LED séparément
des boutons (versions avec des BCU1 notamment). Pour ces
interrupteurs, la LED reflètait l’état d’un des boutons, par exemple
l’état du bouton ON. Dans de tels cas, je colle l’adresse de groupe du
status sur l’objet de communication ON en plus de l’adresse de
commande ON, en prenant garde à la mettre en seconde position (pour le
Send). Je ne sais pas si c’est très clean, mais j’ai observé que cela
fonctionne bien.
> Pour faire une fonction centrale qui éteint tout,
J’utilise volontiers les scènes. Ceci limite le nombre d’adresses de
groupe. Par exemple Scène « Nuit » => Les actuators de lampes la
reçoivent et sont programmés pour s’éteindre. Cela sépare les
fonctions et rend la programmation plus lisible pour la maintenance,
quoique... Quand au status, en étant programmé via sa propre adresse,
il est bien transmis.
Sinon je crée une adresse de groupe spécifique dans la quelle je colle
tous les ON ou OFF concernés avec les inter concernés. (Ex : Eclairage
de la chambre = agir sur 3 prises séparées à partir de plusieurs
points).
Nota : Dans le cas de fonctions centrales, comme avec la chambre et
ses 3 prises, il est difficile de déterminer un status ! Une solution
riche pourrait consister à envoyer les 3 status des actuators dans une
porte NOT-AND dont la sortie dirait OFF si tout le monde a son status
OFF. Je ne suis pas allé jusque là .
Régis
Je pense que seul les BP Hager ont des objets "Indication d'Etat"
lorsque le BP est en "Toggle". Hager a mis cette fonction pour la
compatibilité avec le mode Easy TX100.
Tous les autres fabricants ne mettent pas d'objet IE sur les entrées
Toggle car la solution n°2 existe.
La seconde adresse de groupe (sans le S "send") sur un objet d'entrée
permet de changer la valeur de la variable interne. C'est la solution
donnée par tous les fabricants KNX.
Personnellement j'utilise toujours le même plan d'adressage à 2
niveaux. Exemple 6/1 (cmd eclairage 1), 6/2 (cmd eclairage 2), 6/201
(IE eclairage 1), 6/202 (IE eclairage 2)..... et je ne me pose pas la
question de savoir si il faut ou non une indication d'état, je la met,
elle fait partie du paramétrage de base.
Concernant les commandes groupées, si elles gèrent le même type de
sortie (ex : éclairage), je n'utilise pas les scènes, mais des
adresses de groupes de commande On/Off supplémentaires. Et justement
pour des problèmes de status, je préconise de mettre 2 fonctions On et
Off distinctes sur 1 (appui court / appui long) ou 2 boutons (encore +
simple).
On 27 oct, 20:52, Régis <regis.reb...@free.fr> wrote:
> Bonsoir,
>
> Voici mon retour d'expérience:
>
> STATUS
>
> >Quelle méthode utilisez vous? La première, la seconde ou encore une autre?
>
> Désormais, je programme en utilisant systématiquement deux adresses de
> groupe (ta méthode #2). Je l’ai fait depuis qu'un changement de
> version logicielle de mes switchs (ABB) leur a donné un retour de
> status systématiquement disponible pour chaque sortie :-)
>
> En avantages
>
> - Le majeur : Le status renvoyé par l’actuator est obligatoirement le
> plus juste puisque seul l’actuator connaît la vraie position du relai
> de sortie.
>
> - En corolaire, lorsque le switch dispose d’une commande manuelle, le
> status est aussi transmis lors d’une manœuvre du relai à la main.
> C’est plutôt imparable.
>
> - Ceci permet d’utiliser plusieurs adresses de groupe pour commander
> le même actuator et conserver sans problème une visualisation juste de
> l’état. Et tout pareil lorsque la commande est déclenchée via une «
> scène ».
>
> - Cela permet d’être très clair avec les flags Read => Pas de Read
> pour la commande Switch et Read pour le Status. C’est très confortable
> pour les superviseurs qui sont assurés lors du scan de démarrage de
> récupérer des états fiables.
>
> Comme inconvénients :
>
> - Le flux du bus est multiplié par deux (tout message de changement
> d’état ON/OFF est doublé d’un status). Donc à prendre en compte dans
> l’analyse de charge.
>
> - Les adresses de groupe sont doublées, ce qui peut faire atteindre
> très vite les limites de certaines licences (Ex Serveur OPC de la
> Konnex)
>
> Nota : J’ai été confronté à certains interrupteurs qui ne disposent
> pas de messages spécifiques permettant de piloter les LED séparément
> des boutons (versions avec des BCU1 notamment). Pour ces
> interrupteurs, la LED reflètait l’état d’un des boutons, par exemple
> l’état du bouton ON. Dans de tels cas, je colle l’adresse de groupe du
> status sur l’objet de communication ON en plus de l’adresse de
> commande ON, en prenant garde à la mettre en seconde position (pour le
> Send). Je ne sais pas si c’est très clean, mais j’ai observé que cela
> fonctionne bien.
>
> > Pour faire une fonction centrale qui éteint tout,
>
> J’utilise volontiers les scènes. Ceci limite le nombre d’adresses de
> groupe. Par exemple Scène « Nuit » => Les actuators de lampes la
> reçoivent et sont programmés pour s’éteindre. Cela sépare les
> fonctions et rend la programmation plus lisible pour la maintenance,
> quoique... Quand au status, en étant programmé via sa propre adresse,
> il est bien transmis.
>
> Sinon je crée une adresse de groupe spécifique dans la quelle je colle
> tous les ON ou OFF concernés avec les inter concernés. (Ex : Eclairage
> de la chambre = agir sur 3 prises séparées à partir de plusieurs
> points).
>
> Nota : Dans le cas de fonctions centrales, comme avec la chambre et
> ses 3 prises, il est difficile de déterminer un status ! Une solution
> riche pourrait consister à envoyer les 3 status des actuators dans une
> porte NOT-AND dont la sortie dirait OFF si tout le monde a son status
> OFF. Je ne suis pas allé jusque là .
>
> Régis
On 29 oct, 16:30, mickg <mickael.gaut...@wanadoo.fr> wrote:
> Je pense que seul les BP Hager ont des objets "Indication d'Etat"
> lorsque le BP est en "Toggle". Hager a mis cette fonction pour la
> compatibilité avec le mode Easy TX100.
> Tous les autres fabricants ne mettent pas d'objet IE sur les entrées
> Toggle car la solution n°2 existe.
Sur les boutons poussoirs Merten System design MULTIFONCTION (les 6227
et 6228, uniquement sur BCU2) il y a aussi moyen d'avoir un objet
séparé pour les leds de statut.
En complément: Celà est aussi possible pour des boutons Siemens (Ex
Bouton poussoir de la série DELTA à 4 boutons, Ref 20 S4 Rocker
(BCU2) 907602), à condition de les équiper d'un BCU 2 et d'utiliser
le programme correspondant (ie "20 S4 Rocker (BCU2) 907602" pour
l'exemple pré-cité). Ce programme ajoute un objet de communication
"LED xxx / Status" pilotable séparément de la commande
On 30 oct, 12:08, keldo <kelderm...@ibelgique.com> wrote:
> On 29 oct, 16:30, mickg <mickael.gaut...@wanadoo.fr> wrote:
>
> > Je pense que seul les BP Hager ont des objets "Indication d'Etat"
> > lorsque le BP est en "Toggle". Hager a mis cette fonction pour la
> > compatibilité avec le mode Easy TX100.
> > Tous les autres fabricants ne mettent pas d'objet IE sur les entrées
> > Toggle car la solution n°2 existe.
>
> Sur les boutons poussoirs Merten System design MULTIFONCTION (les 6227
> et 6228, uniquement sur BCU2) il y a aussi moyen d'avoir un objet
> séparé pour les leds de statut.
|
