Logique d'adressage de groupe

[Hadrieng]

Bonjour à tous,

Je ne parviens pas à trouver un fil de discussion qui compare les différentes approches d'adressage GA (je n'ai sans doute pas trouver tous les fils qui traitent du sujet donc n'hésitez pas à mettre les liens dans les réponses !)

Je suis notamment tombé sur cet article KNX : https://www.knx.org/knx-fr/newsroom/fr/n...oupes-KNX/

J'ai l'impression que la plupart du temps une logique fonctionnelle est conseillée pour le résidentiel. J'avoue que j'ai un peu du mal à comprendre la raison.

Je suis peut-être un cas particulier mais la plupart des adresses de groupe dans mon cas sont liées au contrôle de l'éclairage (variation, TW, RGBW, scénario nuit, etc.) Avec une logique fonctionnelle, le groupe 1// (éclairage) est très dense alors que seuls 3 ou 4 des 30 autres groupes principaux sont non vides et dans tous les cas très peu remplis. La plupart des adresses sont donc inutilisées.

Quelle logique avez-vous suivie ? Quels retours d'expérience ?

Dans mon cas, j'ai réfléchi à 2 scénarios
Scen1 :
- Groupe principal : fonction principale (éclairage, chauffage, etc.)
- Groupe intermédiaire : zone de la maison
- Sous-groupe : pièce et sous-fonction

Scen2 : 
- Groupe principal : pièce de la maison avec numéro de l'étage (0x : RDC, 1x : R+1, 2x : R+2, 3x : extérieur)
- Groupe intermédiaire : fonction principale (éclairage, chauffage, etc.)
- Sous-groupe : sous-fonction

Le Scen2 me semble beaucoup plus fluide. Je trouve plus aisée d'imaginer des scènes par pièce, notamment sur l'éclairage et l'organisation des adresses de groupe sur cette logique me semble plus naturelle.
Par ailleurs, ça laisse suffisamment de plages d'adresse sur l'éclairage pour avoir une logique de numérotation des sous-groupes cohérente (ex. //1 commutation, etc.)

Je n'ai jamais vu cette logique d'adressage donc je me dis que je passe peut-être à coté de quelque chose qui m'échappe d'où ma demande de vos retours d'expérience. 

Merci !

[Scorpio5]

Pour ma part je préfère avoir la même pièce dans le même groupe principal,   qui correspond en général à l'étage..

Quant tu depanne ou autre, cet chiant de changer de Gp a chaque fois..

Donc l'étage en gp,
Avec les 7 RI je met :
0commun
1 lum
2 lum statut
3store
4 store statut
5, 6 et 7, chauffage (ou autre technique présente)
.
Je fait généralement de grande bâtiment,
Les adresses en 1, sont copiee en 2, avec la mention statut,
Pour une clarté si projet, en depannage et autre, pas besoin de reflechir,   si t'allume en 3/1/13,  t'aura le statut en 3/2/13

Toujours la même logique,
On/off, varié, %,  ou j'ai juste à rajouté statut derrière quant je copie, et remplacer varié par trigger (pour les détecteurs)

Même principe pour les stores, sauf qu'il y a 4 adresse, et 4 statut..

C'est ma métologie, qui a fait ces preuves depuis le temps,
Avec toujours des nom d'adresse le plus court possible, pour l'affichage dans le moniteurs de groupe..   Juste le nom, ou le numéro de la pièce suffit, qu'on puisse filtré par la suite rapidement.

Mieux c'esr conçu, plus tu gagne du temps par la suite

[kiofu]

Bonjour,
la vraie question est : avez vous besoin de réplicabilité de votre méthode d'adressage ?

Pour l'éclairage et les volets, je suis la méthode classique ;
Ecl = principal, median : On/Off - Re - Varitation % - Viariation % RE - Variation +/-
Volat = principal, médian : M/D - Stop - Position...

Je fais correspondre mon plan avec mon adresse de groupe : donc si dans ma cuisine, ma suspension est repéré ECL1 alors 1/1/1 pour allumer, 1/2/1 On/Off RE, 1/3/1 variation %, 1/4/1 variation % RE et 1/5/1 Variation +/-

Pour les thermostats , je regarde les objets de l’appareil. je les copie à la suite comme ils viennent selon mon paramétrage. La différence ce fera sur le groupe médian. donc 1/ Thermostat, 1/1 Th Cuisine, 1/2 Th Salon. et les objets des thermostats ont les mêmes numéros.

C'est plus facile a mettre en œuvre quand on utiise Excel et l’importation de CSV.
Le copiè coller est super pratique de ETS vers Excel et vice versa

[Polo46]

CC

KNX swiss a édité un document en ce sens : https://www.knx.ch/wAssets/docs/publikat...ES-Web.pdf

Là où ça se complique dans la structure à 3 niveaux, c'est qu'auparavant tu pouvais faire un groupe principal "éclairage" et y mettre plusieurs médians ; le basic étant ON OFF et IE ON OFF. Mais maintenant avec le RGBWW, ça nécessite d'avoir bien davantage de médians si tu veux attribuer le même suffixe à une lampe.

Perso je pense que tout dépend de la taille du projet : si tu as plus de 256 lampes à contrôler, ce que je viens d'écrire précédemment n'est pas adapté.

@kiofu : A se demander d'ailleurs si un jour, l'adresse cible du télégramme ne sera pas codée en 3 octets pour augmenter le nombre de groupes médians. Pas impossible vu l'association KNX a déjà pondu le DPT 270.1200 sur 20 octets, dont personne, à ma connaissance, ne sait comment il sera transmis sur le bus...

[kiofu]

CC

KNX swiss a édité un document en ce sens : https://www.knx.ch/wAssets/docs/publikat...ES-Web.pdf

Là où ça se complique dans la structure à 3 niveaux, c'est qu'auparavant tu pouvais faire un groupe principal "éclairage" et y mettre plusieurs médians ; le basic étant ON OFF et IE ON OFF. Mais maintenant avec le RGBWW, ça nécessite d'avoir bien davantage de médians si tu veux attribuer le même suffixe à une lampe.

Perso je pense que tout dépend de la taille du projet : si tu as plus de 256 lampes à contrôler, ce que je viens d'écrire précédemment n'est pas adapté.

@kiofu : A se demander d'ailleurs si un jour, l'adresse cible du télégramme ne sera pas codée en 3 octets pour augmenter le nombre de groupes médians. Pas impossible vu l'association KNX a déjà pondu le DPT 270.1200 sur 20 octets, dont personne, à ma connaissance, ne sait comment il sera transmis sur le bus...

Salut,
Il me semble qu'avec les produit de dernière générations, tu peux aller en adresse 31 en principale de mémoire. Cela laisse de quoi faire.
Merci pour le liens de KNX swiss, c'est un peu leurs méthodologie que j'utilise et je n'arrivai plus a mettre la main dessus.

A plus de 256 éclairages, je pense séparer en 2 groupes principaux.
Mais perso je n'ai jamais atteint ce nombre. Je ne sais pas si avec les routeurs il est possible de faire 2 bâtiments sur le même principe d'adressage. et ne filtrer que les adresses centrales.
Il me semble que c'est possible.


Le rgb, rgbw, rgbww et tunable white, je le traite a part avec une adresse principale en fonction des driver. Car tous n'ont pas les même caractéristiques, notamment sur les séquence et les messages d'erreurs.
Et leurs nombre est généralement inférieur aux autres luminaires.
J’essaie juste d'adapter la nomenclature de mon plan afin de m'y retrouver sur les adresses. La méthodologie (corrélation plan / nommage adresse) de KNX swiss a ce sujet est top.


Mais le tout c'est de faire en sorte de s'y retrouver quand on y replongera le nez dans 8/10 ou 15 ans.
Je fais des noms d'adresse de groupe à rallonge afin de m'y retrouver plus facilement et de pouvoir aussi filtrer plus facilement en cas de recherche avec le moniteur de groupe.

[Polo46]

CC

KNX swiss a édité un document en ce sens : https://www.knx.ch/wAssets/docs/publikat...ES-Web.pdf

Là où ça se complique dans la structure à 3 niveaux, c'est qu'auparavant tu pouvais faire un groupe principal "éclairage" et y mettre plusieurs médians ; le basic étant ON OFF et IE ON OFF. Mais maintenant avec le RGBWW, ça nécessite d'avoir bien davantage de médians si tu veux attribuer le même suffixe à une lampe.

Perso je pense que tout dépend de la taille du projet : si tu as plus de 256 lampes à contrôler, ce que je viens d'écrire précédemment n'est pas adapté.

@kiofu : A se demander d'ailleurs si un jour, l'adresse cible du télégramme ne sera pas codée en 3 octets pour augmenter le nombre de groupes médians. Pas impossible vu l'association KNX a déjà pondu le DPT 270.1200 sur 20 octets, dont personne, à ma connaissance, ne sait comment il sera transmis sur le bus...

Salut,
Il me semble qu'avec les produit de dernière générations, tu peux aller en adresse 31 en principale de mémoire. Cela laisse de quoi faire.
Merci pour le liens de KNX swiss, c'est un peu leurs méthodologie que j'utilise et je n'arrivai plus a mettre la main dessus.

A plus de 256 éclairages, je pense séparer en 2 groupes principaux.
Mais perso je n'ai jamais atteint ce nombre. Je ne sais pas si avec les routeurs il est possible de faire 2 bâtiments sur le même principe d'adressage. et ne filtrer que les adresses centrales.
Il me semble que c'est possible.


Le rgb, rgbw, rgbww et tunable white, je le traite a part avec une adresse principale en fonction des driver. Car tous n'ont pas les même caractéristiques, notamment sur les séquence et les messages d'erreurs.
Et leurs nombre est généralement inférieur aux autres luminaires.
J’essaie juste d'adapter la nomenclature de mon plan afin de m'y retrouver sur les adresses. La méthodologie (corrélation plan / nommage adresse) de KNX swiss a ce sujet est top.


Mais le tout c'est de faire en sorte de s'y retrouver quand on y replongera le nez dans 8/10 ou 15 ans.
Je fais des noms d'adresse de groupe à rallonge afin de m'y retrouver plus facilement et de pouvoir aussi filtrer plus facilement en cas de recherche avec le moniteur de groupe.

Re,
Tout à fait d'accord avec toi. Au delà de la structure d'adressage retenue, il est fondamental d'en conserver son plan sur un tableur ou un PDF car la logique d'un projet peut s'opposer à celle d'un autre.

Tu soulèves le sujet des alims et drivers LED. Perso j'ai utilisé les alims de Meanwell dont j'ai intégré la pupart des GAD dans les groupes éclairage. 
Mais on aurait aussi pu la rajouter au groupe qui contient toutes les alims, à commencer par la PS/CH. Du coup, j'ai créé des groupes spécifiques dont le suffixe se rapporte à l'AI du participant, au lieu de le rattacher à sa fonction. 
Ce n'est pas sans poser un problème d'organisation dans l'adressage, je m'explique : Tu veux par exemple remonter dans une supervision les temps de fonctionnement. Dans un éclairage LED, tu vas donc avoir celui de l'alim, du driver, du canal R, du canal G, etc. Si tu ajoutes à cela les différents besoin de maintenance qui peuvent être remontés (court-circuit, surchauffe, absence tension...), ca devient vite un casse tête dans l'organisation du projet, d'autant qu'on ne dispose que de 8 groupes médians, là ou 16 seraient plus confortables dans une structure 3 niveaux.

Si tu as une meilleure idée que la mienne...

[kiofu]

Tu soulèves le sujet des alims et drivers LED. Perso j'ai utilisé les alims de Meanwell dont j'ai intégré la pupart des GAD dans les groupes éclairage. 
Mais on aurait aussi pu la rajouter au groupe qui contient toutes les alims, à commencer par la PS/CH. Du coup, j'ai créé des groupes spécifiques dont le suffixe se rapporte à l'AI du participant, au lieu de le rattacher à sa fonction. 
Ce n'est pas sans poser un problème d'organisation dans l'adressage, je m'explique : Tu veux par exemple remonter dans une supervision les temps de fonctionnement. Dans un éclairage LED, tu vas donc avoir celui de l'alim, du driver, du canal R, du canal G, etc. Si tu ajoutes à cela les différents besoin de maintenance qui peuvent être remontés (court-circuit, surchauffe, absence tension...), ca devient vite un casse tête dans l'organisation du projet, d'autant qu'on ne dispose que de 8 groupes médians, là ou 16 seraient plus confortables dans une structure 3 niveaux.

Si tu as une meilleure idée que la mienne...

Pour les drivers Leds, les thermostasts, les stations météos, etc...
Bref, pour tout ce qui n'est pas éclairage on/off et var claissique et volets,les adresses sont en fonction du participant.

Pour ton driver meanwell par exemple, je créer les adresse à la suite des objets de groupes que je vais utiliser.
Donc 9 (ou autre) : driver Meawell, 9/1 : driver salon - 9/2 : driver cuisine,etc... donc si l'objet défaut est en 10eme position, alors en 9/1/10 et 9/2/10 j'ai l'adresse du défaut pour respectivement le salon et la cuisine.

Quand je passe sur un superviseur, c'est plus intuitif de s'y retrouver de cette manière. Pour certains,comme Domovea, je fait une copie et modifie au collage un seul chiffre.

J'ai aussi une adresse médian "divers" dans mon pricipale "éclairage", et je vais des décalage de 100 adresses pour sauter des paramètres.
pour de la variation simple de dali j'ai 1/7/1 défaut, 1/7/101 défaut lampe, 1/7/201 défaut driver
En vérité je n'ai pas vraiment de convention type, je m'adapte au projet, avec l'export en csv et le plugin "extented copy" j'arrive rapidement à dupliquer ma logique.


C'est le plus simple dans ma logique 

[Hadrieng]

Merci à tous pour vos retours !

Ca m'a permis d'avancer dans ma réflexion. J'ai imaginé un schéma d'adressage avec lequel je me sens à l'aise en piochant dans vos différentes idées. Je pense faire :
Groupes principaux :
Dizaine :
0x : RDC
1x : R+1
2x : R+2
3x : extérieur et annexe
Unité :
x0 : réserve scènes globales
x1-x6 : pièces de vie (un groupe principal par pièce de vie)
x7 : circulations
x8 : sanitaires
x9 : pièces techniques

Groupes médians :
1 : éclairage
2 : éclairage statut (avec la logique de Scorpio5 de copier les adresses)
3 : stores et ouvrants (porte sectionnelle, entrée, etc.)
4 : stores et ouvrants statut
5 : chauffage
6 : chauffage statut
7 : capteurs et technique (alarme, DP, détecteurs d'ouverture, luminosité, météo, etc.)
-> Incertain sur la pertinence de séparer stores et chauffage en 2 groupes (commandes et statut) car il y a assez peu de GA nécessaires mais ça reste cohérent par rapport à l'éclairage

Sous-groupes :
Dépend des cas : attribution par zone de pièce (ex. groupe de lumière, scènes globales, pièce pour les sanitaires et pièces techniques, etc.) et sous-fonctions

Je vais miser sur cette logique d'adressage en espérant qu'elle soit suffisamment lisible et évolutive, sauf grosse mise en garde de votre part !

[traxs]

Bonjour,

Je me permets d'intervenir car votre logique n'est, a mon sens, pas très évolutive. En utilisant le groupe principal pour diviser votre bâtiment, vous mettez une grosse restriction d'evolution. Cette idée de structurer selon les étages et type de pièces est bienvenu dans les sous-groupes sous forme de reservation: 0-50 caves, 51-150 rdc, etc. Réalisez vos plages suivants vos besoins.
Les groupes médiants sont les objets que l'on retrouve sur un participants. Par exemple, avec mes screens, j'exploite 15 objets differents (mediants), donc reparti derrière 2 groupes principaux. Le tout pour 15 screens (sous groupes).
J'applique cette logique pour les grandes familles ou la répétition est généralisée : eclairages, prise commandées, volets, chauffage.
Ensuite, certains participants sont unique ou simplement 2, comme une station météo ou une porte de garage/portail. Dans ce cas, j'inverse en plaçant les objets de ce participants dans les sous groupes et le participants est en groupe mediant derrière un groupe principal comme automatisme pour la porte de garage ou meteo/air/température pour la station météo. Il en est de meme pour mon alim ou ma passerelle IP. Gp = systèmes; mediants = participants (alim, passerelle, etc); sous-groupes = objets

Le conseil d'avoir un tableur Excel en plus du projet ets est très très pertinent. Cela permet de faire des imports/export de GA rapidement et d'ajouter des commentaires afin d'avoir une vue globale et une navigation rapide autre que dans ETS.

Je tiens a préciser que j'applique cela pour une maison résidentiel et non un bâtiment a plusieurs etages.
Quand on fouille dans les doc technique, on prend un malin plaisir a remonter les objets des participants dans une supervision, mais attention a la surcharge du bus. N'oubliez pas de régler vos tempo et la manière d'acquisitionner les infos sur le bus!

[Polo46]

Re,

Je vais certainement faire hurler mes confrères intégrateurs, mais je voudrais ici évoquer une autre possibilité de structurer un projet :

Comme chacun le sait :
- La plus courante est à 3 niveaux ; la dernière utilisable est 31/7/255
- La seconde est à 2 niveaux ; (modifiable dans le détail du projet), dernière GAD 31/2047
- La 3° est la libre mais n'est plus possible depuis ETS6.3, (voir https://support.knx.org/hc/fr/articles/1...veau-libre)

Quelque soit le niveau choisi, on sera toujours limité à 65536 (2^16) adresses différentes.

Ce nombre est divisible par tranches de bits. Il est donc parfaitement possible, d'un point de vue purement technique, de le structurer de la façon suivante, si ça paraît important pour l'intégrateur :
- 2 premiers bits (4 valeurs) correspondent à l'étage du bâtiment
- 4 bits (16 valeurs) aux fonctions principales (éclairage, volets, maintenance, etc)
- 4 bits (16 valeurs) pour les fonctions secondaires, (on/off, RGB, IE, blocage...)
- les 6 derniers bits (64 valeurs) pour le participant.

Réaliser ce principe d'adressage sur 4 niveaux est impossible avec ETS, mais possible avec Excel où une partie du tableau doit être consacrée à la traduction d'un adressage 4 en 3 ou 2 niveaux

Un exemple :

- 2° étage,
- volets (groupe 9),
- montée/descente (sous-groupe 1),
- VR chambre 6

enverra le télégramme 0xA446, soit 1010 0100 0100 0110 qui se traduit par l'adresse 20/4/70 (ou 42054 en feu structure libre)

Bien évidemment, cette façon de procéder est absolument aberrante et imbuvable dans un projet ETS, même si elle présente un avantage en matière de sécurité puisqu'il est plus intuitif de trouver une fonction à l'adresse 1/1/2 qu'à 20/4/70 ! Par contre, dans Excel, ça marche bien !

[Hadrieng]

Polo46
J'aime cette approche puriste et extrêmement flexible !
Je prépare de toute façon mes adresses sur Excel. Le seul bémol que je vois est la maintenance et visibilité dans ETS. Ca oblige à reprendre systématiquement l'Excel pour les correspondances d'adresses...

traxs
Merci pour le retour. C'est effectivement une logique qui se tient également. Je me sens moins à l'aise avec une organisation par fonction plutôt que par zone mais je suppose qu'il s'agit plus de sensibilité personnelle. Je trouve plus facile d'imaginer les scénarios par pièces que par fonction. C'est-à-dire : on cuisine, que se passe-t-il dans la pièce en terme de chauffage, luminosité, ventilation, etc. On allume le poêle, que se passe-t-il dans le salon, etc. Et donc une logique descendante consistant à regarder la pièce puis les fonctions (médians) et le détail de chaque fonction pour la pièce...
Cependant il faut peut-être que l'idée fasse son chemin et que je me projette dans cette organisation d'adressage.

2 questions :
- Pourquoi pensez-vous que l'adressage que j'avais envisagé entraine une grosse restriction d'évolution ? Auriez-vous un exemple concret svp ? Celà me permettrait de me projeter dans les besoins futurs que je n'anticipe pas, ce projet étant mon premier projet KNX.
- Avez-vous des exemples de groupes principaux ? En terme d'évolutivité, que se passe-t-il si pour une raison ou une autre un appareil fait dépasser les 7 adresses du médian et implique la création d'un nouveau groupe principal, n'y a-t-il pas un risque que le groupe principal se retrouve décalé à la fin ? Ou peut-être que ce scénario n'a pas de raison de se produire...

Merci d'avance !

[traxs]

Voici un autre sujet ancien qui traite un peu le sujet de plan d'adressage. Il y a 2 Excel a télécharger. Je me suis basé la dessus pour comprendre les GA et débuter mon installation:
https://www.knx-fr.com/showthread.php?ti...ntion+2010

Je comprends votre point de vue de réfléchir par scénarios et par pièce. Il est clair que les "scenes" comme on les appelles en KNX, c'est très attrayant dans le sens où sur l'appui d'un simple bouton, on pilote un ensemble de fonctions: "soiree chill" avec eclairage tamisé, chauffage +1°C, musique detente qui demarre ou la tv, les volets qui se ferme. Ou un bouton, soiree entre amis, bref... Mais avant de faire ce genre de chose, je trouve qu'il faut se concentrer sur chaque fonction indépendamment et donc les ranger par famille de fonction. Les scènes sont, selon moi, un groupe principal, mediants et ss-groupe: gp= scènes, gm= quotidienne, ssg= salon ou scènes, demande, full off, etc.

En knx, une "sortie" peut etre écrite a plusieurs endroits, cad dans différents groupe d'adresse. Exemple: eclairage en toggle dans eclairage/on-off/eclairage cuisine et ce meme eclairage cuisine en Off dans scene/demande/full off.
Une "entree", un appui sur un BP pour faire simple, ne peut etre écrit qu'à un seul endroit. Si l'objet du BP est écrit a un second endroit, il perd son flag S. Cela est toutefois bien utile dans le cas d'allumage multiple afin d'eviter le "double appui" pour allumer un eclairage. L'objet du BP sans flags S s'informe de l'état de la lampe. Certains BP on un objet indication d'état et donc pas nécessaire d'utiliser 2x l'objet et de s'embrouiller avec les flags. Je pense etre moins clair sur cette partie, mais recherche double appui sur le forum. 
Bon amusement dans l'élaboration de vos GA !

[Polo46]

Re,
@hadrieng, j'attire également ton attention sur le fait que la littérature du protocole KNX compte 454 types de DPT. Fais donc en conséquent l'inventaire de ceux que tu vas utiliser si ça peut t'aider. Certains appareils sont gourmands en GAD, la station météo Elsner sun tracer pro peut en utiliser jusqu'à 1838...
Perso j'ai crée un groupe principal dédié uniquement aux mesures avec des groupes médians dédiés : mesures thermiques, électriques, temporelles, luminosité, etc. Pour prendre les temporelles, par exemple, tu peux te retrouver dans un même groupe médian avec des longueurs différentes. Par exemple la combinaison date et heure sera codée en 8 octets, d'autres telles le temps de fonctionnement d'un relais en 2 ou 4 octets.
Est-ce la bonne architecture ? Je n'en sais rien. Mais c'est une façon comme une autre de procéder.

[Kevlille]

Hello

Je suis actuellement sur une architecture basée sur les fonctions mais je me pose la question de partir sur une autre organisation.

Personne n'est parti sur l'organisation suivante?

Main Group: pièces plutôt qu'étage (cela laisse 32 pièces possibles)
Middle Group: fonctions principales (lumières, chauffage...)
Group Address: fonctions secondaires (SW, DIM, FB...)

[Polo46]

Hello

Je suis actuellement sur une architecture basée sur les fonctions mais je me pose la question de partir sur une autre organisation.

Personne n'est parti sur l'organisation suivante?

Main Group: pièces plutôt qu'étage (cela laisse 32 pièces possibles)
Middle Group: fonctions principales (lumières, chauffage...)
Group Address: fonctions secondaires (SW, DIM, FB...)

CC,

Non moi jamais.
Pour une raison simple : un actionneur se trouve dans le tableau électrique situé généralement dans une pièce technique (sauf cas particuliers). Donc ton adresse de groupe qui qui va partir du module d'entrée dans une chambre sera liée à un participant situé dans une autre pièce.
L'avantage de la domotique est de pouvoir interagir entre les appareils. Auquel cas, dans quel groupe placerais-tu une fonction scène ou une commande groupée qui piloterait plusieurs appareils ?
La répartition par pièces se monte dans la partie "bâtiments" du projet ETS, ou bien dans une supervision. Pas vraiment dans la structure des GAD. Même si d'un point de vue technique ça fonctionne aussi...

[Kevlille]

Pour une raison simple : un actionneur se trouve dans le tableau électrique situé généralement dans une pièce technique (sauf cas particuliers). Donc ton adresse de groupe qui qui va partir du module d'entrée dans une chambre sera liée à un participant situé dans une autre pièce.

Hello

C'est aussi le cas dans le cas d'un plan d'adressage basé sur les étages, non? Cela ne pose pas de souci, ou alors je n'ai pas bien compris ta remarque.

[Hadrieng]

@traxs
Merci, c'est très claire et très logique.
A la réflexion, je pense qu'un autre élément qui me perturbe est le nombre de groupes possibles dans chaque groupe. En claire :
- Groupe principal : 31 -> Correspond globalement bien au nombre de pièces/groupes de pièces/extérieur/capteurs dans une résidence (plus me semble-t-il qu'au nombre de famille de fonctions qui sont moins d'une dizaine au total)
- Groupe médian : 7 -> Correspond bien au nombre de groupe de fonctions en résidentiel (si on factorise quelques éléments transverses comme les capteurs dans un groupe principal dédié)
Il est assez étonnant d'avoir cette répartition ETS d'ailleurs 31/7. Je serais curieux de connaitre la raison de ce choix architecturale.

@polo46
Concernant les mesures, j'avais imaginé un groupe, médian dédié pour chaque pièce (groupe 7) et utiliser le groupe 7 du groupe principal annexe et extérieur (30 et 31) pour les capteurs transversaux comme une station météo) mais effectivement s'il peut y avoir besoin de 1838 GA (!!) alors ça ne suffit pas.

@Kevlille
C'est plus ou moins l'approche que j'avais imaginée (cf. mon post) mais c'est peut-être une approche intuitive pour un néophyte mais pas forcément adaptée lorsqu'on a un peu d'expérience. C'est ce que j'essaie de jauger.

[Scorpio5]

Quelque soit le niveau choisi, on sera toujours limité à 65536 (2^16) adresses différentes.

Ce nombre est divisible par tranches de bits. Il est donc parfaitement possible, d'un point de vue purement technique, de le structurer de la façon suivante, si ça paraît important pour l'intégrateur :
- 2 premiers bits (4 valeurs) correspondent à l'étage du bâtiment
- 4 bits (16 valeurs) aux fonctions principales (éclairage, volets, maintenance, etc)
- 4 bits (16 valeurs) pour les fonctions secondaires, (on/off, RGB, IE, blocage...)
- les 6 derniers bits (64 valeurs) pour le participant.

Réaliser ce principe d'adressage sur 4 niveaux est impossible avec ETS, mais possible avec Excel où une partie du tableau doit être consacrée à la traduction d'un adressage 4 en 3 ou 2 niveaux

Bien évidemment, cette façon de procéder est absolument aberrante et imbuvable dans un projet ETS, même si elle présente un avantage en matière de sécurité puisqu'il est plus intuitif de trouver une fonction à l'adresse 1/1/2 qu'à 20/4/70 ! Par contre, dans Excel, ça marche bien !

Salut

effectivement approche bien particulière, qui pourrit avoir du sens si elle serait native a KNX..
car très compliquer a dépannée, avec le moniteur de groupe, tu complexifie la manœuvre, obligé d'avoir ton fichier Excel pour traduire,
ou pour rajouté des adresses...

sur un projet privé pourquoi pas, mais sur du pro, en bâtiment industriel, c'est un killer projet ça..
impossible a reprendre par un autre intégrateur....


même si je trouve l’approche intéressante, j'espère que tu l'applique pas trop dans des projet pro ^^

[Scorpio5]

CC

KNX swiss a édité un document en ce sens : https://www.knx.ch/wAssets/docs/publikat...ES-Web.pdf

joli ce "nouveau" fichier de KNX Swiss, j'ignorait son existance...
ça explique bien les nouvelles topologie sur les laim 1280mA^^

par contre leur façon de nomer les adresses de groupe est imbuvable ..
LG_E01_01 ON/OFF

moi je préfère mettre le numéro de pièce en premier, la lettre d'allumage (unique par étage), puis la fonction
031 B On/Off

ça me parait plus clair, et moins de place ^^


---

c'est un peu la base de KNX, chacun est libre de faire ce qui le veut, là ou ça ce complexifie, c'est quant on reprend le projet d'un client, conçu par un autre :p

[Polo46]

Quelque soit le niveau choisi, on sera toujours limité à 65536 (2^16) adresses différentes.

Ce nombre est divisible par tranches de bits. Il est donc parfaitement possible, d'un point de vue purement technique, de le structurer de la façon suivante, si ça paraît important pour l'intégrateur :
- 2 premiers bits (4 valeurs) correspondent à l'étage du bâtiment
- 4 bits (16 valeurs) aux fonctions principales (éclairage, volets, maintenance, etc)
- 4 bits (16 valeurs) pour les fonctions secondaires, (on/off, RGB, IE, blocage...)
- les 6 derniers bits (64 valeurs) pour le participant.

Réaliser ce principe d'adressage sur 4 niveaux est impossible avec ETS, mais possible avec Excel où une partie du tableau doit être consacrée à la traduction d'un adressage 4 en 3 ou 2 niveaux

Bien évidemment, cette façon de procéder est absolument aberrante et imbuvable dans un projet ETS, même si elle présente un avantage en matière de sécurité puisqu'il est plus intuitif de trouver une fonction à l'adresse 1/1/2 qu'à 20/4/70 ! Par contre, dans Excel, ça marche bien !

Salut

effectivement approche bien particulière, qui pourrit avoir du sens si elle serait native a KNX..
car très compliquer a dépannée, avec le moniteur de groupe, tu complexifie la manœuvre, obligé d'avoir ton fichier Excel pour traduire,
ou pour rajouté des adresses...

sur un projet privé pourquoi pas, mais sur du pro, en bâtiment industriel, c'est un killer projet ça..
impossible a reprendre par un autre intégrateur....


même si je trouve l’approche intéressante, j'espère que tu l'applique pas trop dans des projet pro ^^

Re,
Bien sûr, je n'ai jamais appliqué cette solution, ni à titre privé, ni à titre pro, c'était juste une idée d'approche par rapport à la problématique posée.
Parce que comme tu le dis fort justement, il est fondamental que tu puisses t'y retrouver au niveau logique sur une installation que j'aurais initiée. Et inversement !
On est des intégrateurs, pas des TXA100 

[Polo46]

Pour une raison simple : un actionneur se trouve dans le tableau électrique situé généralement dans une pièce technique (sauf cas particuliers). Donc ton adresse de groupe qui qui va partir du module d'entrée dans une chambre sera liée à un participant situé dans une autre pièce.

Hello

C'est aussi le cas dans le cas d'un plan d'adressage basé sur les étages, non? Cela ne pose pas de souci, ou alors je n'ai pas bien compris ta remarque.

Re,

Je veux dire que si tu raisonnes par étage, comment vas-tu adresser une fonction inhérente à module du tableau électrique (alimentation, maintenance...) ? A une scène qui commande des éclairages aussi bien du RDC qu'aux autres étages ? Aux valeurs renvoyées par une station météo ? A une cage d'escaliers ?
C'est à mon sens possible pour un projet basique, bien plus difficile pour une programmation plus avancée.

[Polo46]

CC

KNX swiss a édité un document en ce sens : https://www.knx.ch/wAssets/docs/publikat...ES-Web.pdf

joli ce "nouveau" fichier de KNX Swiss, j'ignorait son existance...
ça explique bien les nouvelles topologie sur les laim 1280mA^^

par contre leur façon de nomer les adresses de groupe est imbuvable ..
LG_E01_01 ON/OFF

moi je préfère mettre le numéro de pièce en premier, la lettre d'allumage (unique par étage), puis la fonction
031 B On/Off

ça me parait plus clair, et moins de place ^^


---

c'est un peu la base de KNX, chacun est libre de faire ce qui le veut, là ou ça ce complexifie, c'est quant on reprend le projet d'un client, conçu par un autre :p

La convention KNX swiss peut être adaptée à certains projets, moins à d'autres. Pareil pour la tienne ou la mienne.
Ce que je retiens surtout, (et on semble tous d'accord sur ce point) c'est qu'il est fondamental de l'expliquer dans un support adjacent (tableur, plan maison, schéma bâtiment, etc.)