BACnet, Modbus, KNX : quel protocole choisir en GTB et automatisme du bâtiment ?

Dans une installation moderne de bâtiment, les équipements techniques ne fonctionnent plus chacun dans leur coin.

Une centrale de traitement d'air, une pompe à chaleur, un compteur d'énergie, un variateur de vitesse ou une vanne motorisée doivent échanger des informations avec l'automate et la supervision. C'est le rôle des protocoles de communication.

En automatisme du bâtiment, trois noms reviennent en permanence : BACnet, Modbus et KNX. Et à chaque projet, la même question revient : lequel choisir ?

La réponse courte est qu'elle est mal posée. Ces trois protocoles ne se concurrencent pas vraiment : ils occupent trois niveaux différents de l'installation et cohabitent dans la quasi-totalité des bâtiments tertiaires. Choisir entre eux revient souvent à choisir entre un tournevis, une perceuse et une clé dynamométrique.

La vraie question est donc : quel protocole à quel endroit, et comment les faire dialoguer sans créer une usine à gaz ?

Cet article répond à ça. Nous allons voir le fonctionnement réel de chaque protocole, leurs forces et leurs limites concrètes, une méthode de choix en sept étapes, les pièges des passerelles, et ce que la cybersécurité change à l'équation aujourd'hui.

Pourquoi les protocoles sont importants dans le bâtiment ?

Avant de comparer BACnet, Modbus et KNX, il faut comprendre pourquoi les protocoles sont indispensables.

Dans un bâtiment technique, on retrouve beaucoup d’équipements différents.

On peut avoir :

• une centrale de traitement d’air ;
• une pompe à chaleur ;
• une chaudière ;
• un groupe froid ;
• des compteurs électriques ;
• des compteurs d’eau ;
• des compteurs thermiques ;
• des variateurs de vitesse ;
• des pompes ;
• des ventilateurs ;
• des sondes de température ;
• des sondes CO₂ ;
• des vannes motorisées ;
• des clapets coupe-feu ;
• des thermostats d’ambiance ;
• des commandes d’éclairage ;
• des stores motorisés ;
• une GTB ;
• des automates programmables.

Tous ces équipements doivent parfois communiquer ensemble.

Sans protocole commun, chaque équipement parlerait son propre langage.

La GTB ne pourrait pas comprendre les valeurs envoyées par un compteur.

Un automate ne pourrait pas récupérer correctement l’état d’un variateur.

Un système de supervision ne pourrait pas afficher les défauts, les alarmes ou les consommations.

Un protocole sert donc à organiser la communication.

On peut comparer cela à une langue.

Si deux personnes parlent la même langue, elles peuvent se comprendre.

Si deux équipements utilisent le même protocole, ils peuvent échanger des données.

Mais attention : utiliser le même protocole ne suffit pas toujours.

Il faut aussi que les adresses soient correctement configurées, que les objets ou registres soient bien déclarés, que la vitesse de communication soit correcte, que le câblage soit bon et que la logique d’intégration soit claire.

C’est pour cela qu’un protocole n’est pas seulement un mot écrit dans une fiche technique.

C’est un choix important dans la conception, l’intégration, la mise en service et la maintenance d’un bâtiment.

À quoi sert vraiment un protocole de communication en GTB ?

Un protocole, c'est une langue commune. Si deux équipements la parlent, ils peuvent échanger des données.

Mais parler la même langue ne suffit pas : encore faut-il que les adresses soient cohérentes, que les objets ou les registres soient correctement déclarés, que la vitesse de communication corresponde et que le câblage soit propre.

Un protocole n'est donc pas une ligne dans une fiche technique, c'est une décision d'architecture qui engage toute la vie du bâtiment.

Concrètement, un protocole permet trois choses :

Il peut permettre de lire des valeurs.

Par exemple :

• température ambiante ;
• température extérieure ;
• température de soufflage ;
• taux de CO₂ ;
• pression ;
• humidité ;
• consommation électrique ;
• énergie thermique ;
• vitesse ventilateur ;
• position vanne ;
• état marche/arrêt ;
• défaut équipement.

Il peut aussi permettre d’envoyer des commandes.

Par exemple :

• ordre marche/arrêt ;
• consigne de température ;
• consigne de vitesse ;
• ouverture de vanne ;
• commande de registre ;
• reset défaut ;
• activation d’un mode horaire ;
• passage confort/réduit ;
• demande chauffage ;
• demande refroidissement.

Enfin, il peut permettre de superviser une installation, c'est-à-dire afficher, historiser, alarmer et analyser.

Donc, lorsqu’on choisit un protocole, il faut se demander :

• Quelles informations doivent réellement circuler ?
• Qui commande quoi, et avec quelle priorité ?
• Qui supervise, et sous quelle forme ?
• Quel système est maître de la communication ?

Ces questions sont essentielles car un projet qui ne répond pas à ces quatre questions produira une installation qui communique beaucoup et qui ne sert à rien.

Les trois niveaux d'une architecture GTB

Toute installation d'automatisme du bâtiment se lit sur trois niveaux. C'est le modèle mental le plus utile du métier, et il suffit à lui seul à éliminer deux protocoles sur trois dans la plupart des cas.

Niveau 1 — Le terrain

C'est le monde physique : sondes de température et de CO₂, détecteurs de présence, servomoteurs de vannes et de registres, variateurs de vitesse, compteurs, groupes froid, pompes à chaleur. Ce niveau produit et consomme des données brutes, sans logique ni intelligence : une sonde envoie une valeur, un servomoteur reçoit une position.

Protocoles dominants : Modbus RTU, M-Bus pour le comptage, et les liaisons analogiques classiques 0-10 V et 4-20 mA.

Niveau 2 — L'automatisme

C'est le niveau des DDC, les automates de GTB. Ils exécutent la logique : loi d'eau, cascade de générateurs, séquences de CTA, optimisation de démarrage, gestion des alarmes. Ils ont besoin d'échanger des informations structurées entre eux : pas seulement des valeurs, mais des états, des alarmes, des programmes horaires et des historiques.

Protocole dominant : BACnet, en MS/TP ou en IP.

Niveau 3 — La supervision

Poste opérateur, serveur web, tableau de bord énergétique, hyperviseur multi-sites. Ce niveau consomme des données sémantiques : il doit savoir que tel point est la température de soufflage de la CTA 3 du bâtiment B, pas seulement que le registre 40127 vaut 187.

Protocoles dominants : BACnet/IP, BACnet/SC, et de plus en plus OPC UA ou MQTT vers le système d'information.

Et KNX ?

KNX occupe une position à part : il couvre le terrain et l'automatisme du niveau local, à l'échelle d'un local ou d'un étage. Un bouton poussoir KNX parle directement à l'actionneur, sans passer par un automate central. Dans une architecture complète, KNX gère le confort terminal et remonte vers la GTB par une passerelle.

BACnet : le protocole très utilisé en GTB et CVC

BACnet, pour Building Automation and Control Network, est l’un des protocoles les plus utilisés dans le bâtiment, notamment en GTB, GTC, HVAC et régulation CVC.

Il a été conçu pour l’automatisation et le contrôle des bâtiments.

BACnet n’est pas seulement un protocole industriel généraliste. Il a été pensé pour les besoins du bâtiment : chauffage, ventilation, climatisation, éclairage, alarmes, compteurs, supervision, automates et équipements techniques.

On retrouve souvent BACnet dans :

• les centrales de traitement d’air ;
• les groupes froids ;
• les chaudières ;
• les pompes à chaleur ;
• les automates CVC ;
• les régulateurs de zone ;
• les systèmes de supervision ;
• les GTB ;
• les compteurs ;
• les équipements multitechniques.

Aujourd’hui, on parle très souvent de BACnet/IP.

BACnet/IP utilise un réseau IP, donc un réseau informatique Ethernet.

Cela facilite l’intégration avec les systèmes modernes de supervision.

On peut aussi rencontrer BACnet MS/TP, qui fonctionne sur un bus série, souvent en RS-485.

Dans beaucoup de bâtiments, on peut trouver les deux :

• BACnet/IP pour la supervision, les automates principaux et les liaisons réseau ;
• BACnet MS/TP pour certains régulateurs de terrain.

Comment fonctionne BACnet simplement ?

BACnet fonctionne avec une logique d’objets.

Cela veut dire que les informations sont organisées sous forme d’objets standardisés.

Par exemple, une température peut être représentée comme une entrée analogique.

Un ordre marche/arrêt peut être représenté comme une sortie binaire.

Une consigne peut être une valeur analogique.

Un défaut peut être un état binaire.

Cette logique d’objets rend BACnet intéressant pour la GTB.

La supervision peut découvrir ou lire les points d’un équipement BACnet et les afficher sous forme de valeurs compréhensibles.

Exemples de points BACnet :

• température extérieure ;
• température soufflage CTA ;
• défaut ventilateur ;
• ordre marche CTA ;
• consigne température ;
• alarme filtre encrassé ;
• position registre ;
• vitesse ventilateur ;
• demande chaud ;
• demande froid.

BACnet est donc très adapté lorsqu’on veut intégrer des équipements de bâtiment dans une supervision.

C’est pour cela qu’on le retrouve souvent dans les projets de GTB.

Avantages de BACnet

BACnet possède plusieurs avantages importants.

D’abord, il est très adapté au bâtiment.

Ensuite, il permet une intégration structurée avec les systèmes GTB.

De plus, il est largement utilisé dans le CVC, ce qui facilite l’intégration des CTA, groupes froids, chaudières, pompes à chaleur et automates.

BACnet permet aussi de gérer des objets, des alarmes, des états, des consignes et des valeurs analogiques.

Avec BACnet/IP, il devient plus simple de connecter les équipements au réseau informatique du bâtiment.

On peut donc retenir que BACnet est très intéressant lorsque le projet concerne :

• une supervision GTB ;
• plusieurs automates CVC ;
• des équipements HVAC complexes ;
• des besoins d’interopérabilité ;
• des données structurées ;
• des alarmes ;
• des historiques ;
• une architecture bâtiment moderne.

Limites de BACnet

BACnet est puissant, mais il n’est pas magique.

La première limite est l’intégration.

Même si un équipement est annoncé “BACnet”, il faut vérifier quels points sont réellement disponibles.

Un fabricant peut exposer beaucoup de points, ou seulement quelques informations.

Il faut donc demander une liste de points BACnet.

Cette liste est parfois appelée liste d’objets, mapping, points list ou table d’intégration.

Deuxième limite : le paramétrage.

Adresse réseau, instance device, objets, noms de points, unités, priorités de commande, droits d’écriture : tout cela doit être correctement configuré.

Troisième limite : les compétences.

Pour intégrer BACnet proprement, il faut comprendre la logique des objets, les adresses IP, les réseaux, les instances, les points, les commandes et parfois les priorités.

Enfin, il faut faire attention à la cybersécurité, surtout avec BACnet/IP.

Un équipement connecté sur un réseau IP doit être correctement isolé, protégé et documenté.

Modbus : le protocole simple et très répandu

Modbus est un protocole très utilisé dans l’industrie et dans le bâtiment.

Il est connu pour sa simplicité.

On le retrouve dans énormément d’équipements techniques :

• compteurs électriques ;
• compteurs d’énergie ;
• variateurs de vitesse ;
• pompes ;
• onduleurs ;
• régulateurs ;
• chaudières ;
• pompes à chaleur ;
• capteurs ;
• automates ;
• systèmes de mesure ;
• équipements industriels.

En CVC et GTB, Modbus est souvent utilisé pour récupérer des données simples.

Par exemple :

• consommation électrique ;
• puissance instantanée ;
• température ;
• pression ;
• état de défaut ;
• vitesse ;
• fréquence variateur ;
• ordre marche/arrêt ;
• consigne.

Il existe principalement deux formes très courantes :

• Modbus RTU ;
• Modbus TCP.

Modbus RTU fonctionne souvent sur un bus série RS-485.

Modbus TCP fonctionne sur réseau Ethernet/IP.

Comment fonctionne Modbus simplement ?

Modbus fonctionne avec une logique de registres.

Un équipement contient des adresses de registres.

Chaque registre contient une valeur.

Par exemple :

• registre 40001 = température ;
• registre 40002 = consigne ;
• registre 40003 = état marche ;
• registre 40004 = défaut ;
• registre 40005 = puissance ;
• registre 40006 = énergie consommée.

Ces adresses sont données dans la documentation fabricant.

Pour intégrer un équipement Modbus, il faut donc avoir la table de registres.

Cette table indique :

• l’adresse du registre ;
• le type de donnée ;
• l’unité ;
• le facteur de conversion ;
• le sens de lecture ou d’écriture ;
• le format de la valeur ;
• parfois le mot de poids fort et le mot de poids faible.

C’est un point essentiel.

Sans table Modbus, on ne peut pas intégrer correctement l’équipement.

Avantages de Modbus

Le grand avantage de Modbus est sa simplicité.

Il est facile à comprendre dans son principe.

Il est aussi très répandu.

Beaucoup de fabricants proposent une interface Modbus, surtout pour les compteurs, variateurs, régulateurs et équipements techniques.

Ce protocole est souvent un bon choix lorsque l’on veut :

• lire des données de compteur ;
• intégrer un variateur ;
• récupérer des mesures ;
• commander simplement un équipement ;
• connecter un appareil technique à un automate ;
• faire une intégration simple et économique.

Modbus RTU est pratique pour les réseaux de terrain avec plusieurs équipements sur un bus RS-485.

Modbus TCP est pratique lorsqu’on veut utiliser un réseau Ethernet.

Limites de Modbus

La principale limite de Modbus est qu’il est moins “parlant” que BACnet.

Avec BACnet, les objets peuvent déjà être structurés avec des noms et des types.

Avec Modbus, on travaille surtout avec des registres.

Si la documentation est mauvaise, l’intégration devient difficile.

Il faut savoir quelle adresse correspond à quelle valeur.

Il faut aussi gérer les formats.

Par exemple, une température peut être stockée sous forme d’entier avec un facteur 10.

Cela veut dire qu’une valeur brute de 215 peut représenter 21,5 °C.

Si l’intégrateur ne lit pas correctement la documentation, l’affichage dans la GTB sera faux.

Autre limite : la communication Modbus RTU demande un bon respect du câblage, de la vitesse, de la parité, du nombre d’esclaves, des adresses et de la terminaison de bus.

Une seule erreur peut provoquer une communication instable.

Enfin, Modbus est souvent moins riche pour les fonctions avancées de GTB, les alarmes structurées ou les objets bâtiment complexes.

KNX : le protocole très utilisé pour l’automatisation des pièces

KNX est un protocole très présent dans le bâtiment, surtout pour l’automatisation des pièces.

On le retrouve souvent dans :

• l’éclairage ;
• les stores ;
• les commandes murales ;
• les détecteurs de présence ;
• les thermostats d’ambiance ;
• les sondes de température ;
• les actionneurs de vannes ;
• les modules de sortie ;
• les scénarios ;
• les fonctions de confort ;
• la gestion de pièces ;
• certaines fonctions de chauffage et climatisation locale.

KNX est très utilisé dans le résidentiel haut de gamme, les hôtels, les bureaux, les écoles, les bâtiments tertiaires et les espaces où l’on veut gérer finement les fonctions pièce par pièce.

Quand on parle de KNX, on pense souvent au bus KNX TP.

TP signifie twisted pair, donc une paire torsadée.

On peut aussi rencontrer KNX/IP pour relier le réseau KNX à une supervision, une passerelle ou une infrastructure IP.

Comment fonctionne KNX simplement ?

KNX fonctionne avec une logique d’adresses de groupe.

Les participants KNX échangent des télégrammes sur le bus.

Un bouton, un capteur ou un thermostat peut envoyer une information sur une adresse de groupe.

Un actionneur, un relais, un module de sortie ou un servomoteur peut écouter cette adresse et réagir.

Exemple simple avec l’éclairage :

Un bouton mural envoie un ordre sur une adresse de groupe.

Le module d’éclairage reçoit cet ordre.

La lampe s’allume ou s’éteint.

Exemple avec une pièce :

Un thermostat mesure la température ambiante.

Il envoie une demande de chauffage.

Un actionneur de vanne reçoit cette information.

La vanne s’ouvre ou se ferme selon le besoin.

KNX est donc très adapté pour les fonctions locales de bâtiment.

Il est particulièrement intéressant lorsque plusieurs équipements d’une même pièce doivent fonctionner ensemble.

Avantages de KNX

KNX est très fort pour l’automatisation des espaces.

Il permet de gérer de manière structurée :

• éclairage ;
• stores ;
• présence ;
• température ambiante ;
• commandes murales ;
• scénarios ;
• confort utilisateur ;
• zones ;
• pièces ;
• chambres d’hôtel ;
• salles de réunion.

Un avantage important de KNX est son écosystème.

Il existe de nombreux fabricants et beaucoup de produits compatibles.

Cela permet de construire des systèmes avec des composants de marques différentes, à condition de respecter la logique KNX et de programmer correctement l’installation.

KNX est aussi très apprécié pour sa fiabilité dans les installations bien conçues.

Les participants communiquent sur le bus et les fonctions locales peuvent continuer à fonctionner sans dépendre complètement d’un serveur central, selon l’architecture choisie.

Limites de KNX

KNX demande une vraie compétence de paramétrage.

On ne câble pas simplement les équipements pour que tout fonctionne automatiquement.

Il faut créer un projet, définir la topologie, ajouter les participants, paramétrer les fonctions, créer les adresses de groupe et télécharger la configuration dans les appareils.

Le logiciel le plus connu pour cela est ETS.

Une autre limite est le coût.

Certains composants KNX peuvent être plus coûteux que des solutions plus simples.

Il faut donc réserver KNX aux projets où sa valeur est réelle : confort, flexibilité, scénarios, automatisation pièce, évolutivité et intégration multimarque.

Enfin, KNX n’est pas toujours le meilleur choix pour intégrer des équipements techniques lourds comme des groupes froids, grosses CTA ou compteurs industriels.

Dans ces cas, BACnet ou Modbus sont souvent plus adaptés.

BACnet, Modbus, KNX : comparaison simple

Voici un tableau simple pour comparer les trois protocoles.

Quel protocole choisir pour une GTB ?

Pour une GTB, BACnet est souvent le protocole le plus naturel.

Pourquoi ?

Parce qu’il a été conçu pour l’automatisation du bâtiment.

Il permet d’intégrer des automates, des équipements CVC, des alarmes, des états, des consignes et des valeurs de manière structurée.

Dans un projet GTB, on peut donc choisir BACnet pour :

• les automates de régulation CVC ;
• les centrales de traitement d’air ;
• les groupes froids ;
• les chaudières ;
• les pompes à chaleur ;
• les sous-stations ;
• certains compteurs ;
• les équipements techniques importants.

Cependant, cela ne veut pas dire que toute l’installation doit être en BACnet.

Une GTB peut très bien communiquer avec plusieurs protocoles.

Elle peut par exemple intégrer :

• des automates en BACnet/IP ;
• des compteurs en Modbus RTU ;
• des variateurs en Modbus TCP ;
• des zones KNX via une passerelle KNX/IP.

Dans la pratique, un bâtiment moderne utilise souvent plusieurs protocoles en même temps.

La vraie question n’est donc pas toujours : “quel protocole choisir pour tout le bâtiment ?”

La vraie question est plutôt :

quel protocole choisir pour chaque usage ?

Quel protocole choisir pour les compteurs d’énergie ?

Pour les compteurs d’énergie, Modbus est très fréquent.

On retrouve beaucoup de compteurs électriques, thermiques ou techniques avec une communication Modbus RTU ou Modbus TCP.

Modbus est adapté, car un compteur fournit souvent des données numériques simples :

• énergie consommée ;
• puissance instantanée ;
• tension ;
• courant ;
• facteur de puissance ;
• index ;
• température ;
• débit ;
• volume.

La GTB ou l’automate lit ces valeurs dans les registres.

Dans certains bâtiments, on peut aussi trouver du M-Bus pour les compteurs, mais ce n’est pas le sujet principal de cet article.

Pour simplifier :

pour les compteurs, Modbus est très souvent un bon choix.

Mais il faut toujours vérifier la documentation, les adresses de registres, le format des données et les unités.

Quel protocole choisir pour les CTA et équipements CVC ?

Pour les CTA, groupes froids, pompes à chaleur et chaudières, BACnet est souvent très intéressant.

Pourquoi ?

Parce que ces équipements ont souvent beaucoup d’informations à échanger.

Une CTA peut transmettre :

• état marche/arrêt ;
• défaut général ;
• défaut ventilateur ;
• température soufflage ;
• température reprise ;
• température extérieure ;
• pression filtre ;
• consigne température ;
• vitesse ventilateur ;
• position registre ;
• mode de fonctionnement ;
• alarme antigel ;
• demande chaud ;
• demande froid.

BACnet permet de structurer ces points de manière assez claire.

Cependant, certains fabricants proposent aussi Modbus.

Dans ce cas, il faut regarder la richesse de l’intégration.

Si Modbus donne seulement trois informations, alors que BACnet donne cinquante points utiles, BACnet sera probablement plus adapté.

En revanche, si l’objectif est simplement de récupérer un état marche, un défaut et une consigne, Modbus peut suffire.

Quel protocole choisir pour l’éclairage, les stores et les pièces ?

Pour les fonctions de pièce, KNX est souvent très adapté.

Par exemple, dans une salle de réunion, on peut vouloir gérer :

• éclairage ;
• variation lumineuse ;
• stores ;
• présence ;
• température ;
• commande murale ;
• scénario réunion ;
• scénario projection ;
• scénario absence ;
• confort utilisateur.

KNX est très fort dans ce type de logique.

Il permet de relier des capteurs, boutons, actionneurs et thermostats dans une architecture cohérente.

Ensuite, si l’on veut remonter certaines informations vers la GTB, on peut utiliser une passerelle KNX/IP ou une intégration spécifique.

La GTB pourra par exemple récupérer :

• état éclairage ;
• défaut ;
• température ambiante ;
• consigne ;
• présence ;
• position store ;
• mode occupation.

Pour les pièces, KNX est donc souvent un excellent choix.

Quel protocole choisir pour un variateur de vitesse ?

Pour un variateur de vitesse, Modbus est très fréquent.

On peut l’utiliser pour lire :

• fréquence actuelle ;
• vitesse ;
• courant moteur ;
• état marche ;
• défaut ;
• code défaut ;
• ordre marche ;
• consigne de fréquence.

Modbus RTU ou Modbus TCP peuvent convenir selon l’équipement et l’architecture.

Cependant, certains variateurs peuvent aussi être intégrés en BACnet ou avec d’autres protocoles.

Le choix dépend du système de régulation.

Si le variateur est directement lié à un automate CVC en armoire, Modbus peut être simple et efficace.

Si le variateur fait partie d’une architecture GTB plus globale et que le fabricant propose une intégration BACnet riche, BACnet peut aussi être intéressant.

Exemple d’architecture simple dans un bâtiment

Prenons un bâtiment tertiaire avec bureaux.

On peut avoir l’architecture suivante :

• GTB principale en BACnet/IP ;
• automates CVC en BACnet/IP ;
• CTA en BACnet/IP ;
• compteurs électriques en Modbus RTU ;
• variateurs de ventilation en Modbus TCP ;
• éclairage et stores en KNX ;
• passerelle KNX/IP vers la GTB ;
• sondes CO₂ raccordées directement aux automates ;
• vannes motorisées commandées en 0-10 V.

Dans cet exemple, aucun protocole ne fait tout.

Chaque protocole est utilisé là où il est le plus pertinent.

BACnet assure la supervision et la coordination CVC.

Modbus remonte des données techniques simples.

KNX gère les fonctions de confort dans les pièces.

C’est souvent cette approche mixte qui est la plus réaliste.

BACnet ou Modbus : lequel choisir ?

La comparaison BACnet vs Modbus revient très souvent.

Pour simplifier :

BACnet est souvent meilleur pour la GTB et le CVC structuré.

Modbus est souvent meilleur pour une communication simple avec des équipements techniques.

Choisissez BACnet si vous avez besoin :

• d’une intégration GTB propre ;
• de nombreux points ;
• d’objets nommés ;
• d’états, alarmes et consignes ;
• d’une supervision CVC ;
• d’une architecture bâtiment moderne.

Choisissez Modbus si vous avez besoin :

• de lire des registres simples ;
• d’intégrer des compteurs ;
• de communiquer avec des variateurs ;
• d’échanger quelques valeurs ;
• de garder une solution simple ;
• d’utiliser un protocole largement disponible.

Mais attention : la qualité d’intégration dépend aussi du fabricant.

Un bon Modbus bien documenté peut être plus utile qu’un mauvais BACnet pauvre en points.

Il faut donc toujours demander la liste des points disponibles.

BACnet ou KNX : lequel choisir ?

Les deux ne répondent pas exactement au même besoin.

BACnet est très orienté GTB, CVC et supervision.

KNX est très orienté automatisation de pièce.

Choisissez BACnet pour :

• CTA ;
• chaudières ;
• groupes froids ;
• automates ;
• GTB ;
• supervision ;
• équipements CVC principaux.

Choisissez KNX pour :

• éclairage ;
• stores ;
• commandes murales ;
• détecteurs de présence ;
• thermostats d’ambiance ;
• scénarios de pièce ;
• confort utilisateur.

Dans un bâtiment, les deux peuvent coexister.

Par exemple, une GTB peut piloter le CVC en BACnet et récupérer des informations de pièces en KNX via une passerelle.

Modbus ou KNX : lequel choisir ?

Ces deux protocoles sont très différents.

Modbus est très utile pour lire ou écrire des valeurs dans des équipements techniques.

KNX est beaucoup plus orienté fonctions de bâtiment et confort local.

Choisissez Modbus pour :

• compteurs ;
• variateurs ;
• pompes ;
• régulateurs ;
• équipements techniques ;
• mesures simples ;
• communication machine.

Choisissez KNX pour :

• boutons ;
• éclairage ;
• stores ;
• ambiance ;
• présence ;
• scénarios ;
• automatisation de pièce.

Un compteur électrique en Modbus est logique.

Un bouton mural en KNX est logique.

L’inverse n’est pas toujours impossible, mais ce n’est pas forcément le meilleur choix.

Les passerelles entre BACnet, Modbus et KNX

Dans les bâtiments réels, on utilise souvent des passerelles.

Une passerelle permet de faire communiquer deux mondes différents.

Par exemple :

• passerelle Modbus vers BACnet ;
• passerelle KNX vers BACnet ;
• passerelle KNX/IP ;
• automate qui lit du Modbus et expose les données en BACnet ;
• supervision qui intègre plusieurs protocoles directement.

Les passerelles sont très utiles, mais elles doivent être utilisées avec méthode.

Il faut définir clairement :

• quels points sont échangés ;
• dans quel sens circule l’information ;
• quelles valeurs sont en lecture seule ;
• quelles valeurs sont commandables ;
• quelles unités sont utilisées ;
• quels noms de points seront affichés ;
• comment les alarmes sont traitées ;
• qui est responsable du mapping.

Une mauvaise passerelle peut créer beaucoup de problèmes.

Par exemple, une valeur peut être mal convertie, une unité peut être fausse, une commande peut être inversée ou un défaut peut ne pas remonter correctement.

Il faut donc documenter le mapping.

Les erreurs fréquentes à éviter

Erreur n°1 : choisir un protocole parce qu’il est connu

Ce n’est pas parce que BACnet est très utilisé qu’il faut l’utiliser partout.

Ce n’est pas parce que Modbus est simple qu’il suffit toujours.

Et aussi ce n’est pas parce que KNX est puissant dans les pièces qu’il est adapté à tous les équipements techniques.

Le choix doit partir du besoin.

Erreur n°2 : oublier de demander la liste des points

Avant d’intégrer un équipement, demandez toujours :

• liste BACnet ;
• table Modbus ;
• adresses de groupe KNX ;
• documentation de communication ;
• droits de lecture et d’écriture ;
• unités ;
• formats ;
• limites d’intégration.

Sans cette documentation, la mise en service peut devenir très difficile.

Erreur n°3 : confondre protocole et régulation

Un protocole permet de communiquer.

Mais il ne remplace pas une bonne régulation.

Une CTA peut être en BACnet, mais mal régulée.

Un compteur peut être en Modbus, mais mal exploité.

Une pièce peut être en KNX, mais mal paramétrée.

Le protocole transporte l’information.

La régulation décide comment utiliser cette information.

Erreur n°4 : négliger le câblage

Modbus RTU et BACnet MS/TP demandent un câblage correct.

KNX TP demande aussi une topologie respectée.

Une mauvaise terminaison, une inversion de polarité, une mauvaise adresse ou une vitesse incorrecte peuvent provoquer des défauts de communication.

Erreur n°5 : tout faire remonter à la GTB sans logique

Il ne sert à rien de remonter 500 points si personne ne les utilise.

Il vaut mieux remonter les bons points :

• états importants ;
• défauts ;
• consignes ;
• mesures utiles ;
• alarmes exploitables ;
• consommations ;
• tendances nécessaires.

Une bonne intégration est une intégration lisible, documentée et utile.

Erreur n°6 : oublier la maintenance

Un protocole doit être maintenable.

L’exploitant doit pouvoir comprendre :

• quel équipement communique ;
• sur quel bus ;
• avec quelle adresse ;
• quels points sont disponibles ;
• où se trouve la documentation ;
• comment diagnostiquer une panne.

Un système mal documenté devient rapidement difficile à maintenir.

Méthode simple pour choisir le bon protocole

Voici une méthode simple en 7 étapes.

Étape 1 : identifier l’équipement

Est-ce une CTA, un compteur, un variateur, une vanne, un thermostat, une commande murale, une chaudière, une pompe à chaleur ou un automate ?

Le type d’équipement oriente déjà le choix.

Étape 2 : définir les données nécessaires

Listez les informations à lire ou à écrire.

Par exemple :

• marche/arrêt ;
• défaut ;
• température ;
• consigne ;
• énergie ;
• vitesse ;
• position ;
• alarme ;
• mode de fonctionnement.

Étape 3 : regarder les protocoles disponibles

Vérifiez la fiche technique de l’équipement.

Certains équipements proposent seulement Modbus.

D’autres proposent BACnet, Modbus et parfois d’autres protocoles.

Les produits KNX doivent être prévus pour fonctionner dans une architecture KNX.

Étape 4 : vérifier la supervision

La GTB accepte-t-elle BACnet/IP ?

Peut-elle lire du Modbus TCP ?

Faut-il une passerelle ?

Le système de supervision est un élément important dans le choix.

Étape 5 : vérifier la distance et le câblage

Le choix peut dépendre du terrain.

Un bus RS-485, un réseau Ethernet ou un bus KNX TP ne se câblent pas de la même manière.

Il faut anticiper les distances, la topologie, les alimentations et les contraintes d’installation.

Étape 6 : penser à la maintenance

Le protocole choisi doit être compréhensible par les équipes qui exploiteront le bâtiment.

Une solution trop complexe peut devenir un problème si personne ne sait la maintenir.

Étape 7 : documenter le mapping

Quel que soit le protocole choisi, il faut documenter :

• les adresses ;
• les points ;
• les unités ;
• les noms ;
• les droits de commande ;
• les alarmes ;
• les conversions ;
• les passerelles.

C’est indispensable pour une installation professionnelle.

Tableau de choix rapide

Exemple concret : une CTA raccordée à une GTB

Imaginons une centrale de traitement d’air.

La GTB doit afficher :

• état marche ;
• défaut général ;
• température de soufflage ;
• température de reprise ;
• température extérieure ;
• encrassement filtre ;
• vitesse ventilateur ;
• position registre ;
• demande chaud ;
• demande froid ;
• consigne température.

Dans ce cas, BACnet est souvent très adapté.

Il permet une intégration claire et structurée.

Cependant, si la CTA ne propose que Modbus, l’intégration reste possible.

Il faudra simplement récupérer la table de registres et mapper les valeurs dans la GTB.

Le bon choix dépend donc aussi de ce que le fabricant propose réellement.

Exemple concret : compteurs d’énergie dans un bâtiment tertiaire

Dans un bâtiment tertiaire, on veut suivre les consommations.

On installe plusieurs compteurs électriques.

Chaque compteur fournit :

• énergie active ;
• puissance instantanée ;
• tension ;
• courant ;
• fréquence ;
• facteur de puissance.

Ces données sont souvent disponibles en Modbus.

La GTB ou un automate peut lire régulièrement les registres et enregistrer les valeurs.

Dans ce cas, Modbus est généralement suffisant et efficace.

Il faut surtout faire attention aux unités, aux facteurs de conversion et aux index cumulés.

Exemple concret : salle de réunion avec éclairage, stores et présence

Dans une salle de réunion, on veut gérer le confort.

On peut avoir :

• détecteur de présence ;
• boutons muraux ;
• variation d’éclairage ;
• commande de stores ;
• thermostat ;
• scénario présentation ;
• scénario réunion ;
• scénario absence.

Ici, KNX est souvent très pertinent.

Il permet de créer des fonctions locales efficaces.

Ensuite, certaines informations peuvent remonter vers la GTB :

• présence ;
• température ;
• état éclairage ;
• position stores ;
• mode occupation.

La GTB n’a pas forcément besoin de commander chaque détail en permanence.

Elle peut superviser et coordonner.

Résumé simple à retenir

Pour faire simple :

BACnet = GTB, CVC, supervision et équipements bâtiment structurés.

Modbus = compteurs, variateurs, équipements techniques et échanges simples.

KNX = éclairage, stores, commandes, thermostats et automatisation des pièces.

Mais dans un vrai projet, il ne faut pas opposer ces protocoles.

Il faut les utiliser intelligemment.

Un bâtiment moderne peut très bien utiliser BACnet, Modbus et KNX en même temps.

L’important est que l’architecture soit claire, documentée et exploitable.

FAQ : BACnet, Modbus, KNX

Quelle est la différence entre BACnet, Modbus et KNX ?

BACnet est surtout utilisé pour la GTB, le CVC et la supervision. Modbus est très utilisé pour les compteurs, variateurs et équipements techniques. KNX est surtout utilisé pour l’automatisation des pièces, l’éclairage, les stores et les commandes murales.

Quel protocole choisir pour une GTB ?

Pour une GTB, BACnet/IP est souvent le choix le plus adapté, surtout pour intégrer des automates, CTA, chaudières, groupes froids et équipements CVC.

Quel protocole choisir pour des compteurs d’énergie ?

Modbus RTU ou Modbus TCP est très souvent utilisé pour les compteurs d’énergie, car il permet de lire simplement des index, puissances, tensions, courants et consommations.

Quel protocole choisir pour l’éclairage et les stores ?

KNX est très adapté pour l’éclairage, les stores, les boutons muraux, les détecteurs de présence, les thermostats et les scénarios de pièce.

BACnet est-il meilleur que Modbus ?

Pas toujours. BACnet est souvent plus adapté à la GTB et aux équipements CVC complexes. Modbus est souvent plus simple et très efficace pour lire des données techniques dans des compteurs ou variateurs.

KNX peut-il communiquer avec une GTB ?

Oui. On peut utiliser une passerelle KNX/IP ou KNX-BACnet pour remonter certaines informations KNX vers une GTB.

Peut-on utiliser plusieurs protocoles dans le même bâtiment ?

Oui. C’est même très courant. Un bâtiment peut utiliser BACnet pour le CVC, Modbus pour les compteurs et KNX pour l’automatisation des pièces.

Quel est le protocole le plus simple ?

Modbus est souvent considéré comme le plus simple dans son principe, car il repose sur des registres. Mais une bonne documentation reste indispensable.

Quel est le protocole le plus adapté au CVC ?

BACnet est souvent le plus adapté au CVC et à la GTB, surtout lorsque l’on veut superviser beaucoup de points et structurer les informations.

Quelle est l’erreur la plus fréquente ?

L’erreur la plus fréquente est de choisir un protocole sans définir les points à échanger. Avant de choisir, il faut toujours lister les données nécessaires et demander la documentation de communication.

Conclusion

BACnet, Modbus et KNX sont trois protocoles essentiels en automatisme du bâtiment.

Ils sont souvent cités ensemble, mais ils ne répondent pas au même besoin.

BACnet est très adapté à la GTB, au CVC, aux automates et aux équipements de bâtiment complexes.

Modbus est simple, très répandu et efficace pour intégrer des compteurs, variateurs, pompes, régulateurs ou équipements techniques.

KNX est excellent pour l’automatisation des pièces, l’éclairage, les stores, les thermostats, les commandes murales et les scénarios de confort.

Le meilleur protocole n’est donc pas celui qui est le plus connu.

Le meilleur protocole est celui qui répond au besoin du projet.

Pour choisir correctement, il faut regarder l’équipement, les données à échanger, la supervision, le câblage, la maintenance, le coût et la documentation disponible.

Dans beaucoup de bâtiments, la meilleure solution est une architecture mixte.

BACnet pour la GTB et le CVC.

Modbus pour les compteurs et équipements techniques.

KNX pour les fonctions de pièce.

La phrase à retenir est simple :

BACnet supervise, Modbus échange des données techniques, KNX automatise les pièces.

Si vous comprenez cette logique, vous pourrez beaucoup mieux lire les architectures GTB, comprendre les schémas de communication et choisir le bon protocole pour vos projets en automatisme du bâtiment.