Une passerelle KNX relie deux univers de protocoles. On en déduit rapidement que les produits utilisant la même combinaison de protocoles sont largement interchangeables. Or, c’est justement le contraire qui est vrai, notamment pour DALI et Modbus. 

Les différences décisives ne résident souvent pas dans la connexion physique, mais dans le modèle d’application, les types d’appareils pris en charge, les structures de données et la manière dont celles-ci sont mappées sur KNX.

DALI-2 étend l'univers normalisé au-delà des appareillages classiques pour inclure des dispositifs de contrôle. Parmi ceux-ci figurent les contrôleurs d'application et les dispositifs d'entrée. Les dispositifs d'entrée peuvent, par exemple, détecter la présence, mesurer la luminosité ou enregistrer des pressions sur des boutons, et communiquent généralement en mode événementiel en tant que participants multi-maîtres.

La mention « passerelle DALI-2 » n'est donc pas suffisante. La passerelle doit-elle se contenter de commander des appareils DALI-2 ou doit-elle fonctionner elle-même comme contrôleur d’application et intégrer en outre des périphériques d’entrée ? Cette distinction est essentielle pour les projets utilisant des capteurs DALI-2.

Le contrôleur d’application multi-maître disponible dans la gamme Inyx prend par exemple en charge, outre les ballasts, des détecteurs de mouvement DALI-2 conformes aux normes, des capteurs de luminosité et des interfaces de boutons-poussoirs.

Il en va de même pour Colour Control et Tunable White. La prise en charge de DT8 garantit dans un premier temps que les fonctions DALI correspondantes peuvent être activées. Pour l’intégration KNX, ce qui importe toutefois, c’est la manière dont la passerelle reproduit ces fonctions via des objets de communication et des paramètres. 

Une passerelle DALI à deux canaux de la gamme Inyx prend par exemple en charge la température de couleur DT8 via des objets de 2 octets et fournit en outre des informations d’état, le nombre d’heures de fonctionnement, les erreurs liées aux lampes ou aux ballasts électroniques, ainsi que les valeurs de diagnostic du bus DALI.

Ainsi, un projet qui nécessite uniquement la fonction « Tunable White » peut se contenter d’exigences différentes de celles d’une installation dans laquelle des états de fonctionnement et d’erreur détaillés doivent être intégrés dans un système de surveillance de niveau supérieur.

Avec Modbus, l'accent n'est pas mis sur les types d'appareils, mais sur le modèle de données de l'appareil tiers. La spécification Modbus définit les codes de fonction et les accès aux registres, mais ne précise pas la signification concrète que les fabricants attribuent à leurs registres.

Pour l'intégration, il faut donc connaître :

• Quels registres contiennent les valeurs requises ?
• Quels registres sont lisibles ou modifiables ?
• Quel type de données est utilisé ?
• Combien de registres la valeur occupe-t-elle ?
• Quelle est l'échelle prévue ?
• Quelle notation d'adresse la documentation du fabricant utilise-t-elle ?

L’adressage, en particulier, est une source d’erreurs classique. Les télégrammes Modbus fonctionnent avec des adresses relatives, à base zéro, tandis que les documentations des fabricants utilisent souvent des numéros de registre absolus, tels que 40001.

Une « erreur de décalage » apparente peut donc simplement résulter de représentations différentes d’une même adresse.

Chaque registre Modbus est composé de 16 bits. Les types de données plus volumineux doivent être répartis sur plusieurs registres. Un nombre à virgule flottante de 32 bits nécessite donc deux registres contigus.

Pour une passerelle KNX, il est donc important de savoir quels types de données son application prend directement en charge et comment ceux-ci peuvent être mappés sur les types de points de données KNX. Une passerelle dotée de 250 canaux n’est pas automatiquement plus adaptée qu’une autre disposant de 32 points de données si le plus petit appareil reproduit fidèlement les structures de données requises.

 Inyx propose par exemple aussi bien une passerelle RS485 paramétrable via ETS avec 32 points de données librement évolutifs qu’une passerelle KNX/Modbus-RTU avec 250 canaux configurables, une fonction maître/esclave et des logiques supplémentaires.

La question pertinente n’est donc pas « Combien de points de données ? », mais quels points de données, dans quelle structure et avec quelle fonction ?

Cela revêt une importance encore plus grande pour les fonctions d'écriture. Le fait qu'une valeur de consigne figure, par exemple, dans la documentation Modbus ne signifie pas automatiquement qu'elle puisse être modifiée via Modbus.

Ce sont les codes de fonction pris en charge et le modèle de registre concret de l’appareil tiers qui déterminent quelles valeurs peuvent être écrites. Une passerelle KNX ne peut pas générer de possibilité de réglage que l’appareil connecté n’offre pas lui-même. 

Lors d’une intégration, il faut donc toujours prendre en compte la chaîne complète : Fonction KNX souhaitée → valeur requise du système tiers → possibilité d’accès → type de données → mappage de la passerelle.

Que ce soit pour DALI ou pour Modbus, le même problème se pose : la simple mention du protocole est trop vague pour permettre un choix éclairé. Ce qui importe, ce sont les rôles, les types d'appareils, les structures de données, les objets de communication et les fonctions de diagnostic pris en charge par la passerelle en question.

C’est précisément pour cette raison qu’il vaut la peine de comparer les applications avant même la phase de spécification – et non pas seulement lors de la mise en service.