Intégration protocolaire
Intégration KNX
Comment les adresses de groupe KNX, les passerelles et les types de points de données sont mappés dans une plateforme de bâtiment, testés et remis sans perdre le contrôle local.
Ce qu’est KNX et où il est utilisé
KNX est une norme ouverte de contrôle du bâtiment construite autour d’un bus à paire torsadée, avec des extensions pour IP, la radiofréquence et le courant porteur. Elle est courante en Europe et largement utilisée pour l’éclairage, les stores, le contrôle des pièces, les actionneurs CVC et la détection de présence. Les appareils sont mis en service individuellement : chacun possède un programme d’application, des paramètres et des adresses de groupe. Le bus est décentralisé, si bien qu’un bouton-poussoir peut déclencher un variateur sans contrôleur central. Cette résilience locale est l’une des raisons pour lesquelles KNX perdure longtemps après le départ de l’installateur d’origine. C’est d’abord un bus de terrain, pas un système IP. Le projet d’intégration doit le respecter : le bus conserve son comportement local, et la plateforme ajoute une supervision plutôt qu’une dépendance. Référence protocolaire : une ligne prend en charge jusqu’à 64 appareils de bus et une zone jusqu’à 15 lignes, et le bus est alimenté séparément des alimentations propres aux appareils. Ces limites déterminent l’emplacement des coupleurs, des répéteurs et de la capacité de réserve. Un bus sain au niveau du terrain peut néanmoins être mal documenté, et c’est la documentation que le projet suivant hérite.
- Éclairage, gradation et contrôle des scènes
- Stores et automatisation de façade
- Contrôle des pièces, actionneurs CVC et présence
- Europe et projets à spécifications multi-fournisseurs
- Limites de bus planifiées avant l’intégration
Voies d’intégration et choix de la passerelle
Trois voies courantes existent. Une interface ou passerelle KNX raccorde le bus à la plateforme via IP et expose les adresses de groupe comme des points lisibles et inscriptibles. Un routeur IP KNX fait de même au niveau réseau et peut couvrir plusieurs lignes. Un port KNX natif est possible lorsque le contrôleur le prend en charge. La voie choisie détermine la capacité, la latence et les diagnostics. Demandez combien d’adresses de groupe la passerelle peut exposer, si elle prend en charge le tunnelling ou le routage, combien de connexions simultanées elle autorise et ce qui se passe en cas de défaillance du bus ou du réseau IP. Pour une grande installation, segmentez le bus et placez les routeurs de manière réfléchie plutôt que d’étendre une seule ligne. Une passerelle est une infrastructure : prévoyez une réserve, une adresse fixe et une procédure de remplacement documentée. Le tunnelling est pratique pour un superviseur unique ; le routage est préférable lorsque plusieurs clients ont besoin du bus simultanément. Consignez quelles lignes se trouvent derrière quel coupleur ; une panne sur une ligne ne doit pas obliger à ouvrir tout le tableau.
- Passerelle ou interface KNX via IP
- Routeur IP KNX pour installations plus grandes ou segmentées
- Port KNX natif lorsque disponible
- Capacité, latence et basculement confirmés avant conception
De l’adresse de groupe au point de plateforme
Un point KNX n’est pas seulement une adresse. Le registre de mapping doit inclure l’adresse de groupe, le type de point de données, l’unité, l’échelle, le sens de lecture/écriture, l’appareil propriétaire et la fonction desservie. Un objet d’un bit peut être un état, une commande ou un déclencheur de scène ; le registre doit préciser lequel. Les types de points de données portent la mise à l’échelle : une valeur d’un octet peut être un pourcentage, une valeur de deux octets peut être une température en dixièmes de degré. Les indicateurs de lecture et d’écriture ne sont pas interchangeables, et une adresse d’état doit être distincte d’une adresse de commande. Le nommage doit suivre une norme de bâtiment plutôt que les initiales de l’installateur. La liste de points est le contrat entre le programmeur KNX et l’ingénieur de la plateforme. Testez un échantillon de chaque type de point de données plutôt que de supposer qu’un exemple fonctionnel couvre les autres. Lorsqu’une adresse de groupe est écrite par deux systèmes, le projet a besoin d’une règle d’arbitrage et d’un propriétaire unique. Une adresse de groupe utilisée à la fois pour la commande et l’état est une cause fréquente d’oscillation.
- Adresse de groupe et type de point de données
- Sens de lecture/écriture et propriété
- Unité, mise à l’échelle et plage technique
- Convention de nommage et règle d’arbitrage
Nommage des points et registre de mapping
Le nommage des points doit être lisible à 03 h 00. Utilisez une structure fixe : bâtiment, étage, pièce ou système, appareil, fonction et type de signal. Conservez l’adresse de groupe KNX dans le registre, pas nécessairement dans le nom visible ; l’opérateur a besoin de la fonction, l’ingénieur de l’adresse. Le registre de mapping doit être exportable, car il sera comparé au projet ETS, à l’export de la passerelle et à la base de données de la plateforme. Chaque point doit indiquer son type de point de données, son unité, son échelle, son sens, sa limite d’alarme et son propriétaire. Lorsqu’un point est calculé ou combiné, consignez les entrées. Une convention de nommage n’est utile que si elle est appliquée ; ajoutez une étape de revue avant de figer la liste de points. Évitez les noms qui encodent une condition temporaire, comme un étage qui sera renommé ou un locataire qui déménagera. Évitez les abréviations que seul un installateur comprend. Le registre doit aussi mentionner l’adresse d’appareil ETS, afin qu’une trace de bus puisse être reliée à un appareil.
- Structure fixe lisible sans le plan
- Adresse de groupe dans le registre, fonction dans le nom
- Registre de mapping exportable
- Revue avant le gel de la liste de points
Tests et mise en service
Testez d’abord le bus, puis la passerelle, puis la plateforme. Sur le bus, vérifiez l’alimentation des appareils, les coupleurs de ligne, la communication par adresses de groupe et le rappel de scènes. Sur la passerelle, vérifiez la découverte, l’export d’adresses, le comportement en lecture et en écriture, ainsi que la reconnexion après une interruption réseau. Sur la plateforme, vérifiez que chaque point mappé affiche la bonne valeur, la bonne unité et le bon état, et qu’une commande atteint l’appareil de terrain. Testez le chemin de défaillance : déconnectez la passerelle et vérifiez que les fonctions KNX locales continuent. Consignez le résultat en regard de la liste de points, et non dans un carnet séparé. Un point qui apparaît dans une arborescence de navigation n’est pas mis en service tant qu’il n’a pas été lu, écrit et observé. Incluez un contrôle de charge du bus : une interrogation intensive peut faire paraître peu fiable une installation saine. Incluez un redémarrage de la passerelle et un redémarrage de la plateforme ; le comportement de reprise fait partie de la fonction. Testez le bus plateforme déconnectée, puis plateforme connectée ; les deux états comptent.
- Santé du bus, coupleurs et trafic d’adresses de groupe
- Découverte de la passerelle, lecture/écriture et reconnexion
- Valeur, unité et état de la plateforme par point
- Fonctionnement local avec la passerelle hors ligne
- Tests de redémarrage et de reprise
Limites, réception et responsabilités
KNX est robuste au niveau du terrain, mais il a ses limites. La bande passante du bus est partagée ; une interrogation intensive est donc une mauvaise conception. Le désordre des adresses de groupe est courant dans les installations anciennes et doit être nettoyé avant l’intégration. Certains appareils n’exposent que des objets limités, et certains fabricants utilisent leurs propres extensions. KNX Secure exige une gestion de clés que la plateforme doit prendre en charge. La règle pratique est simple : gardez le contrôle de terrain sur le terrain, gardez la logique inter-systèmes dans la plateforme, et documentez la frontière. L’intégration doit rendre le bus plus lisible, non le masquer. Le dossier de réception doit inclure le projet ETS ou un export d’adresses, le registre de mapping, la configuration de la passerelle et les procès-verbaux de tests. La responsabilité du bus reste celle de l’installateur KNX ; la responsabilité du mapping incombe à l’intégrateur. Inscrivez cette répartition dans le contrat, en particulier pour les modifications après réception. Un futur aménagement ajoutera des appareils ; laissez-lui des plages d’adresses et de la capacité de passerelle. Un petit stock de réserve de coupleurs, d’alimentations et de bornes de bus évite un déplacement supplémentaire.
- Éviter l’interrogation lorsque la communication événementielle fonctionne
- Nettoyer et documenter les adresses de groupe existantes
- Confirmer la prise en charge de KNX Secure avant conception
- Maintenir le contrôle local indépendant de la plateforme
- Laisser de la marge d’adresses et de capacité de passerelle
Planification de l’intégration KNX
14 rows| Élément | À confirmer | Pourquoi c’est important |
|---|---|---|
| Support de bus | Paire torsadée, IP, radio ou mixte | Détermine la passerelle et la topologie |
| Structure des lignes et des zones | Coupleurs, alimentations, capacité de réserve | Évite la surcharge et simplifie le diagnostic |
| Limites d’appareils | Référence protocolaire : 64 appareils par ligne, 15 lignes par zone | Détermine l’emplacement des coupleurs et des répéteurs |
| Schéma d’adressage de groupe | Nommage, plages, propriété | Rend le mapping et les modifications futures possibles |
| Types de points de données | Type, unité, mise à l’échelle | Évite les valeurs et commandes erronées |
| Indicateurs de lecture/écriture | Séparation commande/état | Évite les boucles de rétroaction et les écritures conflictuelles |
| Capacité de la passerelle | Nombre d’adresses, tunnelling ou routage, clients | Fixe la limite d’intégration |
| Droits de lecture/écriture | Qui peut écrire chaque adresse | Évite les commandes conflictuelles |
| Scènes et horaires | Où ils résident et qui en est propriétaire | Évite la duplication de logique |
| KNX Secure | Gestion des clés et prise en charge par les appareils | Influe sur la mise en service et le choix de la plateforme |
| Diagnostics | Moniteur de bus, journaux de passerelle, événements de plateforme | Raccourcit la recherche de pannes |
| Charge du bus | Fréquence d’interrogation et trafic événementiel | Maintient une réponse prévisible |
| Procès-verbaux de tests | Adresse, type de point de données et résultat observé | Prouve chaque point mappé |
| Réception | Projet ETS, export d’adresses, liste de points | Maintient le système maintenable |
Images du projet
3 images
Questions fréquentes
01Peut-on intégrer une installation KNX existante ?
Généralement oui, si le bus est sain et si les adresses de groupe peuvent être lues. L’audit doit confirmer l’alimentation des appareils, les coupleurs, la disponibilité du projet ETS et la documentation des adresses.
02Avons-nous besoin du projet ETS d’origine ?
Cela aide. Sans lui, les paramètres des appareils et les adresses de groupe peuvent encore être lisibles, mais les modifications deviennent risquées. Un projet ETS manquant est un constat à résoudre avant l’intégration, non un détail à découvrir lors de la mise en service.
03Loxone et KNX peuvent-ils partager le contrôle ?
Oui. Le projet définit quel système détient chaque adresse de groupe et comment les conflits sont résolus. Une répartition courante consiste à utiliser KNX pour les appareils de terrain et Loxone pour la logique inter-systèmes et les vues opérateur.
04L’intégration KNX nécessite-t-elle une passerelle ?
Elle nécessite une interface entre le bus KNX et la plateforme. Il peut s’agir d’une passerelle, d’un routeur IP ou d’un port KNX natif, selon le contrôleur et l’installation.
05Combien d’adresses de groupe peuvent être intégrées ?
Cela dépend de la passerelle et du contrôleur, et non d’une limite fixe de la plateforme. La conception doit confirmer le nombre d’adresses, la fréquence de mise à jour et les diagnostics avant de figer la liste de points.
06Peut-on conserver les scènes KNX ?
Oui. Les scènes peuvent rester dans les appareils KNX ou être transférées vers la plateforme, mais pas dans les deux sans propriétaire clairement défini. La duplication de la logique de scènes est une cause fréquente de comportements incohérents.
07Que se passe-t-il si la plateforme passe hors ligne ?
Les appareils KNX doivent poursuivre leurs fonctions locales : boutons-poussoirs, variateurs, actionneurs de stores et contrôles de pièce. La logique inter-systèmes s’arrête jusqu’au retour de la plateforme. Ce mode de défaillance doit être testé et expliqué à l’opérateur.
08KNX convient-il aux hôtels ?
KNX est courant dans les cahiers des charges des chambres d’hôtel, en particulier en Europe. Il convient bien à l’éclairage, aux stores et au contrôle des pièces ; la logique PMS et énergie se situe généralement au-dessus.
Étape suivante
Apportez-nous le bâtiment.
Indiquez le type de bâtiment, les systèmes concernés et le résultat dont vous avez besoin. Nous tracerons le chemin le plus court vers un système opérationnel.