Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
All OFF
#1
Bonjour à tous,

Je me demandais comment les gens gèrent le All OFF ? Est-ce que ça se gère avec une scène, ou bien c'est faisable avec des GA ?
L'idée, c'est d'avoir dans mon cas pour commencer : 
  • Un bouton "local off" pour chaque pièce qui va principalement éteindre les quelques lumières.
  • Un bouton 'All Off' pour sortir de la maison qui va lui vraiment tout éteindre, baisser les volets roulants, couper l'eau, etc...
Merci d'avance pour vos retours.
Bon week-end,
Répondre
#2
(18/07/2020, 14:49:54)poukill a écrit : Bonjour à tous,

Je me demandais comment les gens gèrent le All OFF ? Est-ce que ça se gère avec une scène, ou bien c'est faisable avec des GA ?
L'idée, c'est d'avoir dans mon cas pour commencer : 
  • Un bouton "local off" pour chaque pièce qui va principalement éteindre les quelques lumières.
  • Un bouton 'All Off' pour sortir de la maison qui va lui vraiment tout éteindre, baisser les volets roulants, couper l'eau, etc...
Merci d'avance pour vos retours.
Bon week-end,

Je distingue deux types de logiques :
  1. un simple ordre d'extinction envoyé aux participants qu'on veut.
  2. un forçage en mode "éteint" (ou maison vide) qui doit être remis en mode "allumé" (ou maison occupée) pour revenir à la normale. La question qui se pose alors c'est qu'est ce passe lors du retour à la normale : rien ? retour à la situation initiale ? ça dépend des équipements ? Autre question : qu'est ce qui se passe si je tente d'allumer une lampe alors que la maison est sensée être inoccupée ? etc.
Tu vois que ce n'est pas du tout la même chose…

L'une et l'autre de ces deux logiques peuvent être appliquées à tes deux cas d'usage, même si on verrait plutôt la logique 1 pour ta première puce et la logique 2 pour la seconde (si tu as coupé l'eau, il faudra bien la remettre... Alors que pour les volets, c'est pas obligatoire : tu peux les fermer en partant et ne pas vouloir forcément qu'il s'ouvrent en revenant).

La logique 1, moi, je l'ai implémentée avec une adresse de groupe que j'associe à tous les objets d'entrée des actionneurs concernés, mais également aux objets de sortie des boutons poussoir qui les commandent (en mode Toggle). Ça permet au bouton de savoir que le luminaire qu'il commande est éteint et donc de renvoyer le bon ordre la prochaine fois qu'on les presse (toujours l'histoire des doubles appuis).
Tu pourrais aussi utiliser une scène, ça reviendrait un peu au même (pour éviter les doubles appuis, il faudra que les retours retours d'état aient bien été configurés)

La logique 2, elle passe plus par l'utilisation d'une fonction de forçage au niveau des participants. Et c'est sur ces participants que tu choisiras ce qui se passe à la fin du forçage.
Répondre
#3
Bonjour
cas 1, tu peux faire avec une AG et BP envoie un OFF
cas 2 c'est par scène, à moins de faire qu'un OFF "lumière"
Répondre
#4
Que ce soit le Cas 1 ou 2 , si il n'y a qu'une fonction OFF a effectuer , des GA suffisent largement.
KNX Partner Base / Avancé

Ma boite de MP est pleine, merci de créé un post si vous avez une question, cela profitera a tout le monde.
Répondre
#5
Merci @Dibou, c'est très clair.
@fabric24 & @filou merci

Je vois qu'effectivement je peux tenter de gérer le max de choses avec les GA, je suis en train de tester pour voir ce que ça donne. Je vais essayer de garder les scènes quand je peux vraiment plus faire autrement.
Répondre
#6
Salut à tous,
Depuis quelques mois dans la maison, tout roule pas trop mal. Quelques retours d'états mal configurés au début que l'on corrige au fur et à mesure, mais globalement le KNX c'est top ! Smile
En ce qui concerne le All OFF, j'ai pas encore réussi à faire qqch de satisfaisant depuis mon interrupteur Jung F40.

Déjà, je voudrais protéger le All OFF avec un appui long, pour être sûr de pas appuyer là par erreur (adulte et surtout enfants).
Sur le F40, l'appui long je le gère avec "Store" qui envoie une commande "BAS", mais du coup les volets descendent, mais les lumières s'allument....

Bref, comment mettre tous les "data type" d'accord sur ce qu'il faut faire ? Les pulse doivent lancer leur pulse, les switchs doivent aller à false, les volets doivent descendre, etc... Il faut passer par une fonction logique ou pas ?
Répondre
#7
(10/12/2020, 18:43:28)poukill a écrit : Bref, comment mettre tous les "data type" d'accord sur ce qu'il faut faire ? Les pulse doivent lancer leur pulse, les switchs doivent aller à false, les volets doivent descendre, etc... Il faut passer par une fonction logique ou pas ?

Ah là, je pense que tu ne coupes pas à passer par un intermédiaire (ou alors il faudrait utiliser une scène), parce que les objets associés à une adresse de groupe ont forcément un seul et même type (ici binaire) et s'ils n'ont pas la même logique (ce qui revient à dire qu'ils ont des DatapointType différents) tu cours au devant de problèmes tels que celui que tu rencontres.
  • pour le DTP_Switch 1.001 (on/off) : 0 = off et 1 = on
  • mais pour le DTP_UpDown 1.008 : 0 = Up et 1 = down
Même si sur certains participants on peut inverser la logique de commande (par exemple dire à un actionneur qu'il s'ouvre avec un On et se ferme avec un off), ça ne me paraît pas très opportun d'aller le faire car tu risques de te créer des problèmes en chaine (il faudra également inverser chaque commande (sauf celles qui font un toggle)) et tu vas ajouter une complexité pas possible à la lisibilité de ton installation.
donc :
  • soit tu reviens aux scènes (c'est un peu fait pour ça les scènes...) ou une fonction de blocage
  • soit tu passes par une fonction logique qui inverse le bit, i.e. convertir le Down (1) en un Off (0) et le renvoie en aval à une adresse de groupe (à créer) reliée aux luminaires
Répondre
#8
Yes Dibou, c'est clair. J'ai encore jamais joué ni avec les scènes, ni avec mon module logique ABB pour le moment... C'est le moment d'y passer en effet.
Répondre
#9
D'après ce que j'ai lu sur ce forum, je vais partir sur le module logique ABB qui va distribuer plusieurs GA à partir d'une GA ALL OFF. Ca m'a l'air dans l'esprit, et facile à lire. Smile
Répondre
#10
(10/12/2020, 22:24:18)poukill a écrit : D'après ce que j'ai lu sur ce forum, je vais partir sur le module logique ABB qui va distribuer plusieurs GA à partir d'une GA ALL OFF. Ca m'a l'air dans l'esprit, et facile à lire. Smile

En fait, ce que tu t’apprêtes à faire c'est une fonction scène finalement, mais « à l'ancienne », c'est dire assurée, non pas par les participants finaux, mais par un module intermédiaire spécialisé, qui transforme un ordre unique (ici ton AllOff) en une multitude d'ordres différents, envoyés sur différentes GA. Ton module logique ABB, si c'est un LM/S1.1, sait faire ça ; cf. § 5.2.6 du manuel.
Répondre
#11
(11/12/2020, 05:49:38)Dibou a écrit :
(10/12/2020, 22:24:18)poukill a écrit : D'après ce que j'ai lu sur ce forum, je vais partir sur le module logique ABB qui va distribuer plusieurs GA à partir d'une GA ALL OFF. Ca m'a l'air dans l'esprit, et facile à lire. Smile

En fait, ce que tu t’apprêtes à faire c'est une fonction scène finalement, mais « à l'ancienne », c'est dire assurée, non pas par les participants finaux, mais par un module intermédiaire spécialisé, qui transforme un ordre unique (ici ton AllOff) en une multitude d'ordres différents, envoyés sur différentes GA. Ton module logique ABB, si c'est un LM/S1.1, sait faire ça ; cf. § 5.2.6 du manuel.

Mon module logique c'est un ABB ABA/S 1.2.1
Mais je suppose que c'est pas très différent.
Répondre
#12
Normalement les actionneurs qui savent gérer les scènes te proposent à la programmation de définir l'état que doit prendre l'actionneur lors de l'appel d'une scène. C'est en tous cas comme ça que les actionneurs Hager fonctionnent.

Toujours à la progra, je défini pour chaque sortie le nombre de scènes (8,16,32,34) et pour chacune des scènes ce que dois faire l'actionneur (ON ou OFF, % de diming, position du volet, ......) et il ne reste plus qu'à renseigner la GA de scène dans les objets. On a donc pas besoin de se préoccuper du type de DPT utilisé pour chaque sortie de l'actionneur.
De cette manière il suffit simplement d'appeler la scène par un BP ou un superviseur.
Le perfectionnement de soi et l'accession à sa légende personnelle passe obligatoirement par le partage de son savoir et de son expérience avec les profanes en demande d'initiation. (R. Bach)
Répondre
#13
(11/12/2020, 07:36:57)poukill a écrit : Mon module logique c'est un ABB ABA/S 1.2.1
Mais je suppose que c'est pas très différent.

https://search.abb.com/library/Download....ion=Launch

Ouh, il est plus balaise celui-là, mais à l'inverse, il n'a pas l'air d'intégrer de simple fonction scène comme le vieux de 2004...
Qu'à cela ne tienne : tu peux juste mettre un bloc fonctionnel NON (§ 7.10.8) et tu auras déjà réglé ton histoire de volet qui monte au lieu de descendre.
Après tu peux aller bien plus loin et t'amuser à faire tout ce que tu veux avec ce truc-là... Faut juste pas avoir peur de mettre les mains « dedans » et aimer la logique !
Répondre
#14
Ca marche avec la fonction logique de mon ABB ABA/S1.2.1.
Je vais essayer de le faire avec une scène, mais mon problème que le F40 propose les scènes, mais pas sur appui long a priori... Du coup, si c'est vrai, il faudra en plus de la logique de toute façon.
Répondre
#15
(11/12/2020, 07:40:04)pollux06 a écrit : Normalement les actionneurs qui savent gérer les scènes te proposent à la programmation de définir l'état que doit prendre l'actionneur lors de l'appel d'une scène. C'est en tous cas comme ça que les actionneurs Hager fonctionnent.

Toujours à la progra, je défini pour chaque sortie le nombre de scènes (8,16,32,34) et pour chacune des scènes ce que dois faire l'actionneur (ON ou OFF, % de diming, position du volet, ......) et il ne reste plus qu'à renseigner la GA de scène dans les objets. On a donc pas besoin de se préoccuper du type de DPT utilisé pour chaque sortie de l'actionneur.
De cette manière il suffit simplement d'appeler la scène par un BP ou un superviseur.
D'accord Pollux. Je viens de regarder, mes actionneurs MDT peuvent par sortie seulement, réagir à des scènes.
Par contre, ça me semble tout de même pas très "modulaire". Imaginons que tu veuilles définir deux scénarios quasi identiques, à une sortie près... Concrètement : un ALL Off avec Alarme et un ALL Off sans alarme. Du coup avec ton système de scènes, tu te retrouves à programmer plusieurs fois l'intégralité de tes sorties d'actionneurs pour deux scènes différentes qui finalement vont faire presque la même chose non ?

Avec le module logique et des GA, j'ai l'impression que ça va mieux. Par exemple j'ai défini des GA qui sont des sous-groupes:
  • ALL lumières
  • ALL PC
  • ALL Volets
  • Alarme
  • ...

Ensuite, dans le ABB ABAS/1.2.1 je créé des chemins différents, mais en réutilisant les GA groupées...

Bon, je cogite toujours hein, je suis pas sûr de moi. C'est pas évident quand c'est la première fois de voir ce qu'il faut faire pour maintenir facilement la maison.
Répondre
#16
(11/12/2020, 17:29:13)poukill a écrit : Ca marche avec la fonction logique de mon ABB ABA/S1.2.1.
Je vais essayer de le faire avec une scène, mais mon problème que le F40 propose les scènes, mais pas sur appui long a priori... Du coup, si c'est vrai, il faudra en plus de la logique de toute façon.

J'ai aussi des F40. En plus d'utiliser les actionneurs qui supportent les scenes, tu peux aussi utiliser la logique interne de scène de l'interupteur (de mémoire 10 scènes, 10 sorties).

Pour appeler une scène tu peux aussi simplement envoyer son numéro via une valeur 1byte (valeur de la scène -1, donc pour appeler la scène 5 tu dois envoyer une valeur 4 via l'objet 1 byte). Je pense qu'il doit être possible avec le F40 d'envoyer une valeur 1 byte sur un appuis long, mais je n'ai plus toutes les fonctionnalités en tête.
Répondre
#17
Bonsoir,

Perso, avec le ABA 1.2.1, j'ai juste créer une variable d'entrée Maison Occupé/Inoccupé sur 1 bit (1 = occupé/ 0 = vide) qui est adressé par un bouton à la sortie de la maison (mais peut aussi etre envoyé par n'importe quel autre element envoyant une donnée 1 bit).
Le ABA 1.2.1 , sur changement de la valeur de cette variable en 0, déclenche un certain nombre de fonction suivant la période (exemple : fermé les volets automatiquement à la tombée de la nuit, ou instantannément, changement mode chauffage, eteindre lumiere, verrouiller alarme, etc.... --> bref tu choisi ce que tu veux).
Pour le retour, le bouton (je rentre) envoie 1 et déclenche un scenario qui est programmé dans le ABA 1.2.1 (exemple : si il fait nuit dehors, il n'ouvre pas les volets mais allume les pièces principales, etc....).

L'avantage du ABA 1.2.1 est qu'il est tres visuel, donc facile a programmer (et tu as un mode simulation).
Juste un piege, si une variable d'entrée n'est pas renseigné (par une valeur KNX ou autre) alors alors que le module attend une valeur, la fonction programmé ne marche pas.
Répondre
#18
(11/12/2020, 21:15:52)poukill a écrit : Concrètement : un ALL Off avec Alarme et un ALL Off sans alarme. Du coup avec ton système de scènes, tu te retrouves à programmer plusieurs fois l'intégralité de tes sorties d'actionneurs pour deux scènes différentes qui finalement vont faire presque la même chose non ?

Oui, mais ne pas oublier que ce qui fait la robustesse du KNX c'est la décentralisation de l'intelligence.
Tu dois effectivement programmer l'effet de chaque scène dans chaque module de sortie. Mais, une fois que c'est fait, si un de composants disparaît (que ce soit un émetteur ou un récepteur), tout le reste continuera à fonctionner.

Avec un module logique par lequel tout passe, le raisonnement ci-dessus tiens toujours SAUF pour le module logique lui-même : s'il disparaît, tout s'effondre / plus rien ne marche. Toute l'intelligence est concentrée dans celui-ci.
Après, je ne dis pas que c'est pas bien de passer par un module logique, je rappelle juste que c'est plus sensible et que pour certains usage, il faut y prêter attention…
Répondre
#19
(14/12/2020, 20:24:55)Dibou a écrit :
(11/12/2020, 21:15:52)poukill a écrit : Concrètement : un ALL Off avec Alarme et un ALL Off sans alarme. Du coup avec ton système de scènes, tu te retrouves à programmer plusieurs fois l'intégralité de tes sorties d'actionneurs pour deux scènes différentes qui finalement vont faire presque la même chose non ?

Oui, mais ne pas oublier que ce qui fait la robustesse du KNX c'est la décentralisation de l'intelligence.
Tu dois effectivement programmer l'effet de chaque scène dans chaque module de sortie. Mais, une fois que c'est fait, si un de composants disparaît (que ce soit un émetteur ou un récepteur), tout le reste continuera à fonctionner.
Sauf si c'est le participant qui émet le télégramme !  Tongue

Avec un module logique par lequel tout passe, le raisonnement ci-dessus tiens toujours SAUF pour le module logique lui-même : s'il disparaît, tout s'effondre / plus rien ne marche. Toute l'intelligence est concentrée dans celui-ci.
Après, je ne dis pas que c'est pas bien de passer par un module logique, je rappelle juste que c'est plus sensible et que pour certains usage, il faut y prêter attention…

Ta remarque est pertinente mais en dehors des scènes, certaines fonctions ne peuvent être assurées que par un contrôleur logique évolué donc pas de choix possible !
Concernant les scènes c'est complètement illisible dans ETS une fois implémentée à moins d'annexer une documentation au projet.
Ensuite un participant KNX n'a pas la fragilité d'un superviseur ou autre PC.
Répondre
#20
Ca me rassure un peu ta réponse Ives, parce que j'ai vraiment le feeling que ça simplifie la compréhension du projet la programmation visuelle du module logique ABA. Avec les scènes, on perd un peu la trace de qui fait quoi.
Merci pour tous vos feedbacks, c'est très apprécié.
Répondre


Atteindre :


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