Illustration générée par IA — visuel conceptuel.
Dans un hôtel, la difficulté n’est pas seulement de piloter l’éclairage, le CVC ou les stores en KNX : c’est de rendre ces fonctions exploitables par la supervision/GTB, les outils énergie, la maintenance et, parfois, des applications tierces (dashboards, analytics, GMAO, etc.). Historiquement, cette passerelle se faisait souvent au moyen de mappings très spécifiques (adresses de groupe, conventions locales, passerelles propriétaires), difficiles à industrialiser d’un établissement à l’autre.
La KNX IoT Point API fait partie de KNX IoT : elle vise à standardiser la façon d’exposer et d’accéder à des « points » (valeurs capteurs/actionneurs, paramètres, diagnostics) via IP, avec une logique de découverte, de sécurité et de modèle de ressources plus cohérente que des intégrations ad hoc. L’enjeu, en hôtellerie, n’est pas de promettre une « intégration magique », mais de réduire la part d’ingénierie répétitive et de mieux cadrer ce qui devra être recetté (droits, réseau, sémantique, résilience).
KNX IoT Point API : l’idée (sans marketing)
La documentation KNX IoT présente la Point API Stack comme une cartographie des données applicatives KNX vers un modèle de ressources RESTful, avec des représentations CBOR/JSON, transportées sur CoAP/UDP sur IP. Elle inclut des blocs « Discovery », « Security », « S‑Mode » et l’accès read/write/subscribe à des propriétés de paramètres et de diagnostic (GET/PUT/Observe). (KNX IoT – Point API Stack)
Les fichiers de spécification et schémas OpenAPI de la Point API sont publiés sur schema.knx.org (Point API 1.0.0). (KNX Schema – Point API 1.0.0)
Où se place la Point API dans une architecture d’hôtel ?
Pour éviter les malentendus en conception, il faut distinguer le rôle “device” (exposer des ressources sur le réseau IP) et le rôle “système” (exposer une vision cohérente d’une installation, avec un modèle d’information).
Les briques KNX IoT à connaître (au bon niveau)
- KNX IoT Point API device : un équipement KNX IoT (Ethernet / Wi‑Fi / Thread) qui expose des ressources accessibles via la Point API. (KNX – KNX Technology)
- KNX IoT Router : une passerelle entre des segments KNX TP/RF/IPv4 et des équipements KNX IoT. (KNX – KNX Technology)
- KNX IoT API Server : selon KNX, il utilise le KNX Information Model (exporté nativement par ETS6) pour exposer une API standardisée à des tiers. (KNX – KNX Technology)
Dans un projet hôtel, ces rôles peuvent coexister : on peut exposer certains équipements via Point API, tout en structurant l’intégration « à l’échelle installation » via un serveur (selon l’architecture retenue, le périmètre et les produits disponibles).
Un point d’attention “exploitation” : qui est responsable du mapping ?
Même si l’API standardise la manière de dialoguer, il reste à contractualiser la qualité des données exposées : nommage, structuration par chambre/zone, diagnostics réellement disponibles, etc. Sur un hôtel, c’est typiquement ce qui détermine si la supervision est maintenable au jour 2 (extensions, remplacements, rénovations partielles).
Ce que la KNX IoT Point API standardise (et pourquoi ça aide une supervision)
La Point API Stack décrit plusieurs blocs qui parlent directement aux besoins d’une supervision/GTB ou d’une application tierce.
Découverte (discovery)
La documentation indique que les clients peuvent réaliser la découverte de ressources via CoAP unicast/multicast ou via mDNS (DNS‑SD), afin d’identifier les ressources (functional blocks, propriétés) exposées par un serveur. (KNX IoT – Discovery)
Implication projet : la découverte n’est pas qu’un détail technique. Elle dépend fortement de l’architecture réseau (routage inter‑VLAN, filtrage multicast, politiques IT) et doit donc être testée dans l’environnement réel de l’hôtel.
Lecture/écriture/abonnement sur des URIs (GET/PUT/Observe)
La Point API présente des propriétés paramètres et diagnostics accessibles via une URI unique : lecture (GET), écriture éventuelle (PUT), et abonnement (Observe) pour recevoir des changements. (KNX IoT – r/w/pub/sub)
Pour l’exploitation hôtelière, cela peut aider à rendre plus reproductibles :
- la lecture d’états utiles (occupation, défauts, températures, positions, etc.),
- l’écriture de consignes (consignes CVC, modes, scènes…),
- la remontée d’événements (changements d’état) vers une supervision,
- l’industrialisation de clients applicatifs (mêmes patterns d’accès, même logique de sécurité).
Réserve importante : le standard cadre l’accès, mais ne remplace pas le travail d’ingénierie sur la sélection des points, leur structuration, et la stratégie de droits (qui peut écrire quoi, où, et quand).
Communication de groupe (S‑Mode)
La documentation de la Stack rappelle le principe S‑Mode : une communication orientée messages pour la communication de groupe, configurée par l’outil de commissioning. (KNX IoT – Group Communication / S‑Mode)
Le prérequis n°1 en hôtellerie : cadrer l’architecture IT/OT (avant de parler API)
En pratique, la réussite d’une supervision via API dépend d’abord de l’architecture IT/OT et de l’exploitation. La Point API étant IP‑native (et la découverte pouvant s’appuyer sur des mécanismes multicast), le projet doit définir :
- la segmentation réseau (au minimum, séparation des réseaux invités et des réseaux techniques),
- les flux autorisés (pare‑feu) entre supervision/GTB et équipements exposant l’API,
- la gouvernance des accès distants (maintenance, intégrateurs, support),
- les règles de durcissement (comptes, certificats/jetons, rotation, révocation),
- la stratégie de mise à jour et la gestion des indisponibilités.
Pour cadrer cette couche « hôtel » avant de figer une intégration KNX IoT, deux lectures Domocasa sont souvent utiles :
- Architecture réseau IP d’un hôtel : cohabiter Wi‑Fi, IPTV, VoIP, CCTV et GRMS
- Cybersécurité d’un hôtel connecté : protéger GRMS, PMS, GTB et réseau
Modèle d’information KNX : la sémantique compte autant que la connectivité
KNX IoT s’appuie sur le Home and Building Electronic Systems Information Model (EN50090‑6‑2) : la documentation le décrit comme un schéma/vocabulaire pour représenter un graphe d’automatisation (devices, datapoints, locations et relations). (KNX IoT – Information Model)
Dans un hôtel, l’intérêt est très concret : vous ne voulez pas seulement « voir des valeurs », vous voulez pouvoir exploiter des ensembles de points par chambre, par étage, par usage, comparer plusieurs sites, ou encore alimenter des tableaux de bord énergie/maintenance sans réinventer des conventions à chaque projet.
Sur ce sujet « données/sémantique », l’article Domocasa suivant peut compléter la réflexion côté GTB :
Sécurité : ce que KNX IoT prévoit… et ce que le projet doit décider
La documentation de la Point API Stack indique qu’OSCORE (sécurité en couche applicative) sécurise les échanges CoAP, y compris la communication de groupe (S‑Mode) et l’accès aux propriétés paramètres/diagnostics. Elle mentionne aussi un usage optionnel de TLS/(D)TLS (chiffrement en couche transport) pendant le commissioning et l’enrôlement d’identité (LDevID), selon les profils retenus. (KNX IoT – Cybersecurity)
Contrôle d’accès : /auth/at et /auth/crts
La page « Device Access Control » détaille deux ressources structurantes :
- /auth/at : une liste de jetons d’accès (credentials + permission scopes)
- /auth/crts : une liste de certificats CA de confiance pour l’authentification (D)TLS
Elle précise aussi qu’un client MaC (Management & Commissioning Client) configure ces ressources pendant le commissioning, et que les scopes portent la logique « qui peut accéder à quoi ». (KNX IoT – Device Access Control)
Décisions à expliciter dans un hôtel (sinon, litige en recette)
- Lecture vs écriture : quelles applications ont le droit d’écrire des consignes (et lesquelles sont strictement en lecture) ?
- Périmètre : séparation « chambres / parties communes / locaux techniques » du point de vue droits, et pas seulement du point de vue supervision.
- Exploitation : qui gère la rotation/révocation des credentials, et comment est documentée la procédure (jour 2) ?
Limites et maturité : ce qui reste de l’ingénierie (et doit être recetté)
Un standard d’API n’implique pas un déploiement universel. Sur un hôtel, trois zones restent typiquement « projet » :
- Disponibilité réelle : quels équipements du lot supportent effectivement KNX IoT/Point API (et à quelles versions), et quel rôle joue le routeur/serveur dans l’architecture retenue.
- Qualité du mapping/sémantique : points exposés, structuration, cohérence des tags/relations, diagnostics disponibles.
- Comportement réseau : découverte (multicast/mDNS), résilience, reprise après redémarrage, et compatibilité avec les politiques IT (filtrage inter‑VLAN, restrictions multicast, etc.).
Versions : ne pas figer un CCTP sur une référence isolée
La page KNX « Downloads » liste plusieurs versions et un statut de maturité. Par exemple, elle indique que la Point API 1.0.0 est « outdated », et présente des entrées 1.1.0 avec des statuts « outdated » et « release » selon l’artefact. (KNX Support – KNX IoT Downloads)
Implication côté hôtel : au lieu d’exiger « KNX IoT » de manière générique, demandez au titulaire d’annoncer la version (API/stack) réellement supportée par les équipements proposés, puis validez l’intégration sur périmètre (pilot zone / PoC) avant généralisation.
Un rappel utile : KNX IoT est une trajectoire (pas un snapshot)
KNX rappelle, lors de la publication du KNX Standard v3.0, que les spécifications KNX IoT (3rd Party API et Point API) constituent un point de départ et sont susceptibles d’évoluer. (KNX – KNX Standard v3.0)
Plus récemment, KNX annonce aussi un alignement des spécifications de test KNX IoT (3rd Party API, Point API, Router) dans le cadre d’une version du standard (v3.0.5). (KNX – Standard v3.0.5)
Checklist de recette (orientée exploitation hôtelière)
Ci‑dessous, une checklist volontairement orientée tests réalisables. Elle ne remplace pas le plan de test GTB/GRMS global : elle cible la couche « API » et ses dépendances (réseau, droits, sémantique).
| Thème | Test à réaliser | Limite / point de vigilance |
|---|---|---|
| Découverte | Depuis la zone supervision/GTB, vérifier qu’un client retrouve les ressources attendues (selon l’architecture : CoAP unicast/multicast, mDNS). | Un réseau « fonctionnel » pour la bureautique peut bloquer multicast/mDNS ; il faut tester dans la segmentation cible. |
| Inventaire | Comparer la liste des équipements/points exposés avec le DOE attendu (chambres, zones, fonctions), et contrôler le nommage minimal utile exploitation. | Une API standard ne garantit pas la qualité de modélisation : c’est un livrable à contractualiser. |
| Lecture | Lire les valeurs critiques (états, températures, défauts) et valider la cohérence avec le terrain (pas seulement l’affichage). | Certains points peuvent dépendre de la logique locale (GRMS, contrôleurs, modes) : valider les cas d’usage réels (ménage, DND, inoccupé…). |
| Écriture | Écrire des consignes représentatives (modes, setpoints) et vérifier l’effet attendu, y compris en présence de verrouillages/modes locaux. | L’écriture doit être limitée aux rôles autorisés (sinon risque opérationnel). |
| Abonnement / événements | Tester Observe : détection de changements sur scénarios réalistes (occupation, scènes, cycles CVC) + comportement lors d’une coupure réseau et au retour. | Les performances perçues dépendent du réseau, du filtrage et de l’implémentation des clients (supervision). |
| Sécurité / droits | Vérifier qu’un accès non autorisé est refusé et que les scopes appliquent bien la séparation lecture/écriture et les périmètres (chambres vs communs vs technique). | Le contrôle s’appuie notamment sur /auth/at et /auth/crts (commissioning MaC) : il faut une procédure d’exploitation pour la rotation/révocation. |
| Exploitation | Simuler « jour 2 » : remplacement d’un équipement, ajout d’une chambre/zone, restauration après incident, et vérifier l’impact sur l’API et la supervision. | Sans procédure et livrables (comptes, accès, sauvegardes), l’API devient un point dur en exploitation. |
Où brancher la Point API dans l’hôtel : supervision, GTB, GRMS, PMS…
La Point API traite la couche « points techniques ». Mais dans un hôtel, les effets métier (arrivée, départ, ménage, DND, maintenance) impliquent souvent plusieurs systèmes (PMS, GRMS, GTB, contrôle d’accès…). Avant de connecter une application tierce « à KNX », clarifiez les responsabilités : qui décide, qui exécute, qui supervise, et quel est le mode dégradé si une interface tombe.
Pour poser ce cadre, vous pouvez vous appuyer sur : PMS, GRMS, GTB, serrures et contrôle d’accès : qui échange quoi dans un hôtel ?
Sources et documentation (références publiques)
- KNX Association – KNX Technology (section KNX IoT)
- KNX IoT Docs – What is the Point API Stack
- KNX IoT Docs – Device Access Control
- KNX IoT Docs – Information Model (EN50090‑6‑2)
- KNX Support – KNX IoT Downloads (versions/maturité)
- KNX Schema – KNX IoT Point API 1.0.0 (ReDoc)
- KNX News – KNX Standard v3.0 (IoT 3rd Party API & Point API)
- KNX News – KNX Standard v3.0.5
En résumé (et un conseil simple de maîtrise de risque)
La KNX IoT Point API est une brique intéressante quand l’objectif est de relier KNX à une supervision/GTB ou à des applications tierces en parlant API de manière plus standard, avec une sécurité et une découverte cadrées. Mais, en hôtellerie, le succès se joue surtout dans la recette : droits, réseau, sémantique et procédures jour 2.
Si vous préparez un projet (neuf, rénovation ou extension) et souhaitez cadrer une architecture d’intégration réaliste (périmètre, prérequis IT/OT, stratégie de recette), Domocasa peut intervenir en AMO technique pour transformer ces exigences en livrables projet et critères de réception.
