Illustration générée par IA — visuel conceptuel.
En hôtellerie, un capteur de présence n’est pas seulement un “capteur” : c’est un point de contact direct avec l’expérience client (allumage trop agressif la nuit, extinction trop rapide, faux déclenchements) et un sujet d’exploitation (diagnostic, remplacement, stock, cohérence multi‑étages). La question utile n’est donc pas “quelle technologie est la meilleure ?” mais plutôt où placer la détection et où placer la logique pour que le système reste maintenable au jour 2.
Ce guide compare deux stratégies réalistes pour l’éclairage d’un hôtel :
- Capteurs de présence côté DALI‑2 (capteurs = “input devices” DALI‑2) avec une logique d’éclairage portée par un contrôleur DALI‑2, une passerelle ou une supervision.
- Présence/logiciel côté KNX (capteurs KNX + logique KNX) avec DALI utilisé comme sous‑système de pilotage des luminaires (souvent via passerelle KNX↔DALI).
La question qui change tout : où vit la logique, et qui saura dépanner ?
Dans un hôtel, la majorité des “irritants” ne viennent pas d’une panne franche du capteur, mais d’un ensemble capteur + règles + temporisations + modes d’exploitation :
- gestion jour/nuit (balises, niveaux doux, anti‑éblouissement),
- modes ménage et maintenance (forçages temporaires propres),
- priorités (DND, présence, commande manuelle, scénarios),
- comportements en mode dégradé (que se passe‑t‑il si une passerelle ou un contrôleur tombe ?).
Avant de choisir “DALI‑2” ou “KNX”, alignez-vous sur ce point : qui porte la logique d’éclairage (contrôleur DALI‑2, logique KNX, passerelle, supervision/GTB) et quel lot en est responsable en conception, recette et maintenance. Sur ce sujet d’architecture globale, vous pouvez aussi consulter Piloter l’éclairage d’un hôtel : KNX direct, DALI‑2 local ou DALI‑2 relié à la GTB — comment choisir sans complexifier.
Option A — Capteurs de présence en DALI‑2 : ce que DALI‑2 standardise (et ce que vous devez encore cadrer)
DALI‑2 “input devices” : ce que c’est, concrètement
La DALI Alliance présente les capteurs et autres dispositifs d’entrée comme des DALI‑2 input devices. Côté normalisation, un input device DALI‑2 s’appuie sur IEC 62386‑101 et IEC 62386‑103, puis implémente une ou plusieurs parties “applicatives” comme IEC 62386‑301 à 304 (par exemple : 62386‑303 pour les capteurs d’occupation/présence, 62386‑304 pour les capteurs de lumière). Référence : DALI Sensors and other input devices (DALI Alliance) ; Référence : DALI‑2 certification of sensors and input devices… (DALI Alliance / DiiA, PDF).
Trois détails ont un impact direct sur la conception et l’exploitation :
- Multi‑master : plusieurs input devices peuvent partager le bus DALI,
- Logique “événementielle” : ces devices sont normalement utilisés en mode event‑driven (avec possibilité de polling/périodique selon cas),
- “Instances” dans un même produit : la DALI Alliance indique qu’un produit peut contenir jusqu’à 32 instances sous une seule adresse (utile quand un même capteur regroupe présence + luminosité, ou plusieurs zones logiques). Référence : Technical details (DALI Alliance).
Si vous avez besoin de clarifier les périmètres (DALI‑2 vs D4i vs “DALI+”), vous pouvez aussi lire : DALI‑2, D4i et DALI+ : quelles différences pour l’éclairage intelligent ?.
Interopérabilité : pourquoi “DALI‑2 certifié” compte en maintenance
Pour l’exploitation, DALI‑2 n’est pas seulement un “protocole” : c’est un programme de certification. La DALI Alliance présente la certification DALI‑2 comme un processus s’appuyant sur des tests et une vérification des résultats, avec des produits référencés publiquement, afin de soutenir l’interopérabilité entre produits certifiés. Référence : DALI‑2 Certification Overview.
Ce point est directement exploitable en hôtellerie : pour limiter les remplacements “à risque”, vous pouvez exiger au CCTP des capteurs DALI‑2 certifiés et vérifier les références dans la base produits publique (DALI Alliance Product Database). La page DALI Alliance sur les capteurs précise aussi que les input devices (dont les capteurs) ont été ajoutés au programme DALI‑2 en mai 2019. Référence : DALI Sensors and other input devices.
Attention : DALI‑2 certifie un langage, pas votre “scénario hôtel”
Point de prudence essentiel : même avec des capteurs DALI‑2 certifiés, le comportement réel (temporisations, priorités, règles jour/nuit, modes ménage/DND, transitions) dépend de l’endroit où vous implémentez la logique : contrôleur DALI‑2, passerelle KNX↔DALI, superviseur/GTB ou contrôleur de chambre. Autrement dit, la certification est une base d’interopérabilité, mais elle ne remplace pas une recette fonctionnelle pensée pour l’hôtellerie.
Pour outiller la réception et éviter les litiges “interopérable sur le papier, irritant sur site”, vous pouvez compléter avec Réception d’un éclairage DALI‑2 en hôtel : comment vérifier l’interopérabilité et éviter les incompatibilités.
Option B — Présence et logique côté KNX : ce que vous achetez en gouvernance et en évolutivité
KNX : interopérabilité multi‑marques et “preuve” via certification
La KNX Association met en avant un écosystème multi‑fabricants, des dispositifs certifiés compatibles inter‑marques et l’usage d’ETS pour concevoir, mettre en service et gérer des projets KNX. Référence : KNX Technology (KNX Association).
Pour l’exploitation, la promesse utile n’est pas “on a mis du KNX” ; c’est :
- Produits certifiés (preuve multi‑marques),
- Projet ETS et gouvernance (documentation, sauvegardes, conventions),
- Capacité à faire évoluer des scénarios (sans “casser” des dépendances invisibles).
La page publique “Certified KNX Devices” présente les dispositifs certifiés comme compatibles multi‑marques et conçus pour fonctionner avec ETS (conception, mise en service, gestion). Référence : Certified KNX Devices.
Pour un rappel “socle” (utile en phase APS/PRO quand on doit expliquer le partage des rôles entre lots), voir aussi : KNX : le standard ouvert de la domotique et de l’immotique.
Le point de vigilance KNX en hôtel : l’outillage exploitation (ETS, DOE, procédures)
KNX peut rendre l’exploitation très robuste… si le projet est géré comme un actif : fichiers ETS à jour, stratégie de sauvegarde, règles de nommage, procédures de reprise, et droits d’accès remis à l’exploitant selon les modalités prévues. Sinon, le remplacement d’un capteur ou une retouche de logique devient vite “risquée” (peur de casser une adresse de groupe, une scène, un mode chambre).
Sur le livrable “exploitation”, vous pouvez aligner vos exigences avec DOE et maintenance d’un hôtel connecté : que faut-il remettre à l’exploitant ?. Et pour cadrer le maintien dans le temps (au-delà de la livraison), voir : Maintenance KNX : comment garantir qu’une installation restera maintenable dans 10 ou 15 ans ?.
Trois architectures hôtelières fréquentes (et leurs impacts maintenance)
Architecture 1 — Zone/chambre “autonome” en DALI‑2
Principe : capteurs DALI‑2 + logique portée par un contrôleur DALI‑2 (local) ; KNX/GTB récupère des états, des commandes ou des modes, selon l’intégration.
Atouts exploitation : une partie des fonctions d’éclairage peut rester locale (moins dépendante d’une intégration transverse). Les capteurs peuvent être “standardisables” si vous imposez du DALI‑2 certifié et vérifiable.
Vigilances : attention à la dépendance au contrôleur (outil de mise en service, export des paramètres, reprise en main par un tiers). C’est souvent là que se joue la maintenabilité réelle, plus que sur le capteur lui‑même.
Architecture 2 — Logique KNX, DALI cantonné au pilotage des luminaires (passerelle KNX↔DALI)
Principe : capteurs et règles en KNX ; DALI sert d’interface fine vers les drivers/luminaires.
Atouts exploitation : cohérence “bâtiment” (éclairage + autres usages) et scénarios de chambre plus faciles à orchestrer (selon le périmètre retenu).
Vigilances : la passerelle KNX↔DALI devient un composant critique (paramétrage, robustesse, comportement en mode dégradé). La maintenance doit savoir diagnostiquer et le DALI et le KNX, ou au minimum isoler rapidement “où est la faute”.
Architecture 3 — Hybride : capteurs DALI‑2 “terrain”, arbitrage “hôtel” centralisé
Principe : DALI‑2 remonte des événements de présence ; KNX/GTB arbitre les modes (jour/nuit, DND, ménage, énergie) et renvoie des ordres.
Atouts exploitation : compromis fréquent en rénovation (on capitalise sur l’existant DALI, tout en ajoutant une logique hôtelière transverse).
Vigilances : principal risque : double logique contradictoire (temporisations actives des deux côtés, règles qui se “battent”). Ce cas est typiquement à traiter par une matrice claire “qui décide / qui exécute”.
Comparatif orienté maintenance : ce qui change vraiment
| Critère d’exploitation | Capteurs DALI‑2 (input devices) | Présence/logique en KNX |
|---|---|---|
| Preuve d’interopérabilité à la réception | Exiger « DALI‑2 certified » et vérifier la référence dans la base produits DALI Alliance ; certification avec processus de tests et vérification des résultats. Source | Exiger des dispositifs certifiés ; la page KNX “Certified Devices” présente une compatibilité multi‑marques et un usage avec ETS. Source |
| Remplacement rapide d’un capteur (exploitation en cours) | Plutôt favorable si le capteur est standardisé (certifié, référence stockée) et si la logique associée n’est pas “opaque”. À cadrer : procédure de remplacement et de re‑commissioning (qui fait quoi, avec quel outil, et comment prouver le retour à l’état nominal). | Plutôt favorable si l’hôtel dispose du projet ETS à jour + conventions + procédure ; sinon le remplacement peut être freiné par la gouvernance (accès, sauvegardes, risque de non‑régression). |
| Diagnostic (où est la panne ? capteur, logique, passerelle, driver) | Le bus DALI donne des mécanismes utiles, mais le diagnostic dépend beaucoup des outils/contrôleurs choisis. Recommandation : prévoir des tests de recette “capteur → événement → action” et des logs côté contrôleur/supervision. | La logique peut être plus centralisée, mais l’exploitabilité dépend de la qualité du DOE et des outils (ETS et/ou supervision). L’architecture doit permettre d’isoler rapidement un défaut d’intégration KNX↔DALI si DALI est utilisé. |
| Évolutivité (extension par phases) | Souvent très efficace pour une rénovation “éclairage par zones”, en gardant une cohérence DALI‑2. Pour une approche rénovation, voir Rénover un éclairage DALI en hôtel : migrer vers DALI‑2. | Souvent très efficace quand on anticipe des scénarios transverses (modes chambre, intégrations). Le socle KNX reste pertinent si la gouvernance et les livrables sont cadrés. |
Grille de décision (questions à trancher avant de figer un CCTP)
- Qui transforme “présence/absence” en actions d’éclairage (contrôleur DALI‑2, logique KNX, passerelle, GTB) ?
- Mode nuit : quelle règle évite un allumage brutal (niveaux doux, rampes, balisage, conditions) ?
- Ménage / maintenance : comment forcer sans “oublier” le forçage (durée, retour automatique, indicateurs) ?
- Mode dégradé : que se passe‑t‑il si la passerelle / la supervision n’est pas disponible ?
- Remplacement : quelle stratégie de stock et de références “équivalentes” est réaliste pour l’exploitant ?
- DOE : quels éléments rendent l’installation reprenable (listes de références certifiées, exports, sauvegardes, procédures) ?
Pour limiter les faux allumages/extinctions (sujet très visible côté client), vous pouvez aussi consulter Détecteurs de présence : comment éviter les allumages et extinctions intempestifs ? (les principes de placement et de temporisation restent utiles, même si un hôtel impose des cas d’usage spécifiques).
Et pour cadrer la validation avant généralisation (étage, aile, puis tout l’établissement), une démarche de zone pilote reste très efficace : Chambre témoin hôtel : comment valider le GRMS, le CVC et l’éclairage avant le déploiement ?.
Recommandations pragmatiques (sans dogme)
- Si la priorité est le remplacement terrain et l’interopérabilité côté éclairage : une stratégie cohérente DALI‑2 (capteurs DALI‑2 certifiés + architecture de contrôle claire) peut simplifier le stock et les remplacements, à condition de cadrer la mise en service et la reprise.
- Si la priorité est l’orchestration hôtelière multi‑lots : placer la logique côté KNX (ou un contrôleur “cœur” clairement identifié) peut faciliter les scénarios, à condition de verrouiller les livrables et la gouvernance (ETS/DOE/procédures).
- Dans tous les cas : refusez l’ambiguïté “double logique”. Une seule couche doit arbitrer les priorités, et l’autre exécuter.
Ce que vous pouvez exiger à la réception (orienté exploitation)
- Preuve de certification : références DALI‑2 certifiées vérifiables dans la base publique, et/ou dispositifs KNX certifiés (selon architecture).
- Recette anti‑irritants : une matrice de tests en conditions réelles (jour/nuit, circulation, sanitaires, chambre, ménage) avec critères de validation fonctionnels.
- DOE exploitable : liste des références, architecture “où vit la logique”, sauvegardes et exports nécessaires, procédure de remplacement d’un capteur et de retour à l’état nominal.
Sources et documentation (références primaires)
- DALI Alliance — DALI Sensors and other input devices
- DALI Alliance — DALI‑2 certification overview
- DALI Alliance — DALI‑2 certification status (Allowed Parts…)
- DALI Alliance (DiiA) — Press release (June 27, 2019) : DALI‑2 certification of sensors and input devices…
- DiiA — Technical note : Changes to IEC 62386 enabling DALI‑2 certification
- KNX Association — KNX Specifications
- KNX — Certified Devices (compatibilité multi‑marques, ETS)
Besoin d’aide sur votre cas hôtel (neuf ou rénovation) ? Le plus efficace est de partir d’une zone type (chambre, couloir, sanitaire) et de formaliser : où vit la logique, quelles priorités, et quels tests de réception garantiront le confort et la maintenabilité.
