29/10/2007, 16:30:57
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
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