Au cœur d'un protocole: KNX explique en long et en largeZ

une tache ne represente qu'une part minime de la communication total

Nous entrons au cœur du système pour décortiquer tout ce qui fait un proto­cole. Notre choix s'est porté sur KNX, mais les grandes lignes s'appliquent aussi à d'autres protocoles.

SystEme ouvert et dEcentralisE

Plus vraiment besoin de présenter KNX. Cependant, nous voudrions revenir sur deux caractéristiques importantes de KNX, parce qu'elles sont importantes pour le développement de la communication. La première est qu'il s'agit d'un système ouvert: il n'est pas lié à un seul fabricant, toute entreprise peut concevoir autant de composants KNX qu'elle le veut et les faire certifier. La deuxième caractéristique est la structure décentralisée. Chaque composant a l'intelligence nécessaire pour fonctionner dans un système KNX. Il peut donc recevoir et traiter les messages lui-même.

.

methodes de communication

Le support de communication peut varier dans le cas de KNX:

• KNX TP (Twisted Pair – câble bus traditionnel). C'était le premier moyen de communication sur lequel des messages KNX ont pu être envoyés, à une vitesse de transfert des données de 9.600 bit/s.

• KNX PL (Power Line – via le réseau 230 V) Vitesse de 1.200 bit/s.

• KNX RF (Radio Frequency – émission d'ondes radio). Via la fréquence 868.3 MHz.

• KNXNet/IP (via Ethernet, Bluetooth, wi-fi)
  Aujourd'hui, on constate une évolution au profit du système KNX IoT, afin d'uniformiser la méthode de travail au sein du secteur IT. La structure simple et claire des adresses et des actions dans KNXNet/IP est un peu un obstacle pour les programmeurs de logiciels, car l'intégration entre KNX et les applications basées sur Internet est du coup plus difficile. Le message du système KNX est conditionné par KNXnet/IP dans un télégramme IP. En fait, aucune valeur n'est ajoutée aux données. Mais aujourd'hui, cette approche – dans le contexte de la cybersécurité – n'est plus suffisante. Ceci découle du fait que la connexion entre le système KNX et l'Internet externe est de plus en plus directe aujourd'hui, alors qu'auparavant, elle se faisait principalement via le réseau LAN. En outre, il faut aussi prendre en compte l'évolution importante vers les commandes depuis tablettes et smartphones. Les spécialistes IT qui développent le logiciel pour ces appareils, préfèrent HTTP, Websockets et JavaScript. Le protocole IP/UDP (User Datagram Protocol) lié au système KNX dans le KNX IoT est remplacé par un mode de communication de type IP. En soi, la méthode de communication n'affecte pas le contenu (appelé 'charge utile') d'un télégramme KNX, mais affecte la structure de la surcharge (les informations supplémentaires qui sont envoyées avec lui). Un télégramme a donc une apparence différente, mais son contenu reste le même.

  

structure d'un message

Le cœur d'un télégramme KNX est l'information qui contient la commande d'un appareil. Ces données sont formées par le champ 'Charge utile'. Mais le simple envoi de la charge utile ne suffit pas. Des informations telles que l'identité du destinataire et de l'expéditeur, le type de message concerné, la durée de l'information, certaines priorités, ... doivent également être incluses dans un télégramme.

INFORMATION DU STANDARD
La KNX Association définit dans un télégramme les caractéristiques indépendantes du fabricant auxquelles la commande doit répondre. De cette façon, il n'y a pas de problèmes de compatibilité entre les différents fournisseurs. Ce standard de communication s'appelle EIB Interworking Standard, en abrégé la EIS. Voici la liste des télégrammes et de leur contenu (voir tableau). 

Il est possible d'ajouter jusqu'à sept champs supplémentaires contenant des informations autour de la charge utile.
A savoir (par ordre de structure):

• Le champ de commande a une longueur de 8 bits et contient à son tour trois types d'infor­mations: informations sur le type télégramme, sur le statut de répétition et sur la priorité donnée au message.

• L’adresse source se compose de 16 bits et indique l'adresse individuelle que le message envoie.
  L'adresse cible a également une longueur de 16 bits et détermine à quelle adresse la charge utile est destinée. Un appareil KNX ne traite la charge utile d'un télégramme reçu que s'il est également adressé par ce télégramme.

• Le type d'adresse se compose de 1 bit (0/1) et indique le type de communication.

• Le nombre de sauts permet d'éviter l'envoi des télégrammes multicast en boucles sans fin à travers un réseau KNX, même en cas d'erreurs topologiques.

• La longueur du télégramme peut paraître anodine, mais elle permet au dispositif de détecter exactement où se trouve la charge utile dans le télégramme.

• La charge utile comprend les données complètes avec la commande concrète pour le destinataire (interrupteur ouvert/fermé, indiquer l'état de la vanne X, ...).

• Enfin, la somme de contrôle permet le contrôle final de parité.

Selon le type de communi­cation, des informations supplémentaires sont ajoutées, telles que la version utilisée pour un système KNXnet/IP ou l'état de la batterie pour un système KNX RF.

deroulement

structure de l'adresse

Dans le logiciel ETS, il est possible de définir la structure des adresses physiques et l'attribution des adresses de groupe pour la liaison des composants. Chaque participant au bus a sa propre adresse, la structure l'utilise pour envoyer les télégrammes. Ceci permet à une entrée d'envoyer un télégramme à plusieurs sorties et à une sortie de répondre à plusieurs entrées. Une adresse physique est structurée comme suit: adresse=zone.ligne.produit = par exemple 15.15.255.

Attribution des fonctions

Après avoir attribué les adresses physiques, les fonctions doivent être définies pour chaque produit. Cela signifie que, pour chaque sortie et chaque entrée, il faut choisir quelle fonction sera exécutée. Ce sont des actions très concrètes: on/off, gradation, up/down.

envoi

Dans un système de bus, un télégramme ne peut être envoyé que si aucun autre télégramme n'est en cours de transfert à ce moment. Pour éviter les problèmes, chaque appareil sur le bus 'écoute' les informations de transfert de données dans le bus. Si deux appareils veulent envoyer un télégramme en même temps, l'appareil A enverra une parité '0'. A ce moment, le dispositif B veut envoyer un '1', mais détecte le 0 du dispositif A. B est alors obligé de reporter sa communication et de donner priorité à A. Une fois la communication terminée, une nouvelle tentative est faite par B. C'est un exemple très simple, mais dans la pratique, la priorité en cas de conflits entre télégrammes peut être déterminée dans le champ de contrôle. Si cette priorité est fixe, mais que deux télégrammes ont le même niveau, c'est la structure de l'adresse qui détermine qui passe en premier (0, puis 1). Cette méthode s'applique au système KNX TP, les autres méthodes de communication ont un procédé adapté.

accuse de reception

Après réception du télégramme, les participants signalent la réception correcte en envoyant un accusé de réception. Par 'accusé de réception', on n'entend pas forcément une réponse positive. Les confirmations possibles sont:

• Accusé de réception positif = LL_ACK: le message a été reçu, l'expéditeur des télégrammes ne répète pas le télégramme.

• Accusé de réception négatif = LL_NAK ou LL_BUSY: le message n'a pas été bien reçu ou n'a pu être reçu. L'expéditeur du télégramme répète le télégramme trois fois.

• Non (réaction): l'expéditeur du télégramme répète le télégramme trois fois. Après ces tentatives, le système expéditeur arrête son action.

Le cycle peut alors recommencer avec une nouvelle commande.

et a l'avenir?

La montée en puissance de l'IdO et les consommateurs qui souhaitent de plus en plus passer aux smartphones et aux tablettes pour contrôler leur installation, nécessitent également d'adapter les protocoles domotiques. Les spécialistes en informatique qui développent le logiciel pour ces appareils, préfèrent les plates-formes HTTP, Websockets et JavaScript. Le système KNX a répondu à cela il y a quelques années avec KNX IP, mais cette méthode ne convenait plus, car il s'agissait seulement d'un reconditionnement du protocole KNX dans une enveloppe IP. C'est pourquoi ils ont lancé une plate-forme KNX IoT l'année dernière, remplaçant le protocole IP/UDP (User Datagram Protocol) lié au système KNX par un mode de communication de type IP exclusivement.