Éclairage “constant” en hôtel : comment le spécifier et le valider en réception sans variations désagréables (DALI‑2 et intégrations)

Illustration générée par IA — visuel conceptuel.

En hôtellerie, un “maintien d’éclairement” (souvent appelé constant light control ou daylight compensation) est utile… à condition qu’il reste invisible pour le client. Un réglage trop réactif peut créer des micro-variations, un effet de “pompage” ou une reprise d’automatisme ressentie comme intrusive. À l’inverse, un réglage bien cadré améliore le confort en journée, notamment près des façades, sans dégrader l’expérience.

Ce guide propose une méthode orientée réception : quoi écrire dans la spécification (comportements attendus), quoi exiger comme livrables (paramètres et responsabilités), et comment valider sur site avec des tests simples mais sérieux, en DALI‑2 et en intégration (KNX/GTB).

Ce que “constant light” veut dire côté expérience client (et pourquoi c’est différent d’un objectif “énergie”)

En hôtel, on ne cherche pas un “lux constant” au sens mathématique. On cherche un résultat de confort :

• Pas de variations perceptibles lors des changements lents de lumière du jour (nuages, déplacement du soleil, stores ajustés).
• Pas d’oscillation (montée/descente répétitive) ni de “marches” visibles.
• Priorité à l’intention utilisateur : si le client dimme ou lance une scène, l’automatisme ne doit pas “reprendre la main” de façon incompréhensible.

Conclusion pratique : une bonne spécification décrit des règles de comportement (bande de stabilité, vitesse de correction, priorités manuel/auto, conditions d’activation) et pas uniquement une consigne lumineuse.

DALI‑2 : ce qui est standardisé… et ce qui ne l’est pas (à ne pas confondre)

Certification DALI‑2 : une base utile, mais pas une garantie de confort “constant light”

La DALI Alliance (DiiA) présente DALI‑2 comme un périmètre structuré par un programme de certification, avec des Test Specifications dérivées de parties pertinentes d’IEC 62386 (ou de spécifications DiiA), une vérification par la DiiA, et une base publique permettant de vérifier le statut des produits. Source : DALI Alliance — DALI‑2.

Côté projet hôtel, cela se traduit par un réflexe simple : exiger des références certifiées et les vérifier, puis faire une recette chantier orientée usage (car la certification ne remplace pas un test de confort en situation).

Où se trouve “l’intelligence” du maintien d’éclairement ? Souvent dans le contrôleur applicatif (pas dans le driver)

La DALI Alliance décrit les application controllers comme le “cerveau” du système : ils utilisent des informations de diverses sources, prennent des décisions, et envoient les commandes au control gear. Source : DALI Alliance — Control devices.

Conséquence directe : deux installations annoncées “DALI‑2” peuvent avoir un confort constant light très différent, car l’algorithme et les paramètres dépendent du contrôleur (et, en intégration, parfois d’une passerelle ou d’une GTB).

Capteurs DALI‑2 (Part 304) : ce que la DALI Alliance met en avant

La DALI Alliance regroupe les capteurs et input devices dans les Parts 301 à 304, et décrit notamment la Part 304 (Light sensors) : mesure de l’illuminance, hystérésis programmable (pour limiter le trafic), événements périodiques optionnels. Source : DALI Alliance — Sensors and input devices.

Point important pour la réception : l’hystérésis et le mode de remontée (événementiel, périodique, polling) sont des leviers concrets pour éviter des corrections trop fréquentes… mais ce n’est pas “automatique” : cela dépend aussi du contrôleur et de sa logique.

Support des capteurs : tous les contrôleurs ne se comportent pas pareil

La DALI Alliance indique que tous les application controllers ne supportent pas forcément l’usage des input devices, et que certains exploitent des event messages tandis que d’autres utilisent du polling, notamment pour des mesures lentes comme le niveau lumineux. Source : DALI Alliance — Tech note “instance types”.

Pour un hôtel, c’est un point contractuel : vous ne “réceptionnez” pas un concept. Vous réceptionnez un comportement obtenu avec une combinaison précise : capteur + contrôleur (ou passerelle) + paramétrage.

Architectures typiques en hôtel : où se ferme la boucle constant light (à figer avant la recette)

En pratique, vous rencontrerez souvent ces familles d’architectures :

• DALI‑2 local : capteurs DALI‑2 (ex. Part 304) + application controller DALI‑2 qui calcule et envoie les corrections aux drivers.
• DALI‑2 avec supervision / GTB : la GTB impose des modes/scènes/horaires, mais la boucle constant light peut rester locale… ou être déplacée (à clarifier).
• KNX ↔ DALI‑2 via passerelle : l’intégration KNX/DALI‑2 existe (exemple de passerelle cataloguée côté KNX). Source : knx.org — exemple de gateway KNX/DALI‑2. En revanche, les fonctions exactes (présence d’une régulation interne, paramètres accessibles, priorités, comportement en cas de commandes concurrentes) dépendent du modèle et de son application.

À écrire noir sur blanc dans la spécification : qui calcule la correction constant light ?

• le contrôleur DALI‑2 ?
• la passerelle KNX/DALI‑2 ?
• une logique GTB/supervision ?

Tant que ce point n’est pas figé, les tests de réception resteront ambigus (et la responsabilité du confort aussi).

Comment spécifier un maintien d’éclairement “hôtel-compatible” (sans sur-promettre)

1) Délimiter où le constant light est souhaitable… et où il est risqué

Le maintien d’éclairement est généralement plus simple à justifier (et à stabiliser) dans des espaces en journée et où l’on attend une ambiance fonctionnelle :

• lobby, accueil, circulations éclairées par la façade ;
• salles de réunion, zones de travail back-of-house ;
• restaurants en configuration “jour”.

Il est plus délicat dans les ambiances où l’on cherche une intention lumineuse “scène” :

• chambre client (surtout soirée/nuit) ;
• spa, ambiances “détente” ;
• scènes “dîner”, “coucher”, etc.

Bon réflexe projet : en chambre, traiter le constant light comme une fonction conditionnelle (état “jour”, “ménage”, “lecture en journée”…) plutôt que comme un automatisme permanent.

2) Décrire le comportement attendu (les “règles”) plutôt qu’un setpoint isolé

Au lieu d’exiger uniquement “maintien d’éclairement”, décrivez des règles testables :

• Bande de stabilité : accepter une zone de confort autour d’une référence (la largeur exacte est un choix de projet à valider en zone témoin). Une bande trop étroite pousse à la correction permanente.
• Vitesse de correction : correction automatique progressive (fondu), sans marches visibles.
• Fréquence de correction perceptible : éviter les micro-ajustements continus (critère à formaliser en réception par observation + mesures).
• Priorités : manuel et scènes (client, ménage, nuit) priment selon une matrice de priorités écrite.
• Conditions d’activation : quand le constant light est actif (modes/états), quand il est suspendu.
• Garde-fous : limites mini/maxi, comportements en cas de capteur indisponible ou valeurs incohérentes.

3) Exiger la liste des paramètres réellement disponibles (contrôleur/passerelle), et pas une liste “supposée”

Sans présumer de fonctions universelles (elles varient selon contrôleur/passerelle), vous pouvez exiger que l’offre fournisse, pour la zone témoin, une fiche paramètres listant ce qui est réellement réglable, où cela se règle, et qui en est responsable. Typiquement :

• référence/consigne de régulation par zone (si la boucle existe) ;
• hystérésis / bande morte (côté capteur Part 304 et/ou côté contrôleur) ;
• mécanisme de remontée (événementiel, périodique, polling) et sa cadence de lecture/rapport (si applicable) ;
• temps de transition (fondu) pour les corrections automatiques ;
• règles de priorité et temporisation de reprise après action manuelle ;
• valeurs plancher/plafond imposées à la régulation.

Recette / réception : protocole de tests orienté confort (pas seulement “ça répond”)

La logique est la même que pour une chambre témoin : on valide l’expérience et les comportements avant de déployer. (Voir aussi : Chambre témoin hôtel : comment valider le GRMS, le CVC et l’éclairage avant le déploiement ?.)

Pré-recette documentaire (avant essais)

• Schéma d’architecture : bus DALI, contrôleur applicatif, capteurs, éventuelle passerelle KNX/GTB.
• Liste des références : drivers/luminaires, capteurs, contrôleur(s), passerelle(s), avec statut DALI‑2 certifié quand applicable (à vérifier dans la base publique DALI‑2). DALI Alliance — DALI‑2.
• Responsabilités : qui calcule la correction, qui applique les priorités, où sont stockés les paramètres, qui a la main sur la mise en service.

Tests terrain : une grille simple, reproductible et documentée

Test	Objectif	Comment faire (principe)	Limites / points de vigilance
Variation lente “jour”	Vérifier l’absence de pompage lors des variations lentes de lumière du jour	Mettre la zone en mode où le constant light est actif, puis faire varier lentement l’apport de jour (stores/voilage) et observer si des corrections deviennent perceptibles	Le résultat dépend fortement de l’implantation capteur/luminaires ; documenter la configuration exacte du test
Seuil / hystérésis	Éviter la correction “au moindre changement”	Créer de petites perturbations (ombres partielles, store légèrement ajusté) et vérifier que le système ne “chasse” pas	Si micro-variations : revoir hystérésis/bande morte et/ou stratégie de lecture (événement/périodique/polling) et/ou vitesse de correction
Interaction client	Vérifier la priorité au manuel et aux scènes	Tester dimming manuel, activation de scènes, changement de mode (jour/soir/nuit/ménage) et observer reprise de l’automatisme	Ne pas tester “en laboratoire” : tester avec l’interface client réelle (commandes, scénario d’usage)
Implantation capteur	Détecter boucles instables dues à reflets / “capteur qui voit le luminaire”	Tester plusieurs positions de stores, vérifier l’influence de reflets (miroirs, surfaces brillantes) et la cohérence des corrections	Une instabilité peut être un problème d’implantation/calibration plutôt qu’un problème protocolaire

Mesure et acceptation : garder une part “confort” mais la rendre traçable

La réception ne se limite pas à “c’est à peu près bon” :

• Utilisez un luxmètre comme instrument de trace (sans prétendre à une métrologie de laboratoire) : même emplacement, mêmes conditions, relevés horodatés.
• Tenez un journal d’observation : corrections visibles (oui/non), oscillation (oui/non), reprise intrusive après action manuelle (oui/non), etc.
• Adossez l’acceptation à la spécification comportementale (bande de stabilité, vitesse de correction, priorités), définie et validée en zone témoin.

Ce qu’il faut explicitement ne pas promettre (pour éviter les litiges en réception)

• “DALI‑2 garantit un constant light parfait” : non. DALI‑2 structure l’interopérabilité et la certification, mais l’algorithme et le paramétrage (côté application controller / intégration) restent déterminants. DALI Alliance — DALI‑2 et Control devices.
• “Une passerelle KNX/DALI‑2 fera forcément X” : non. Une fiche catalogue atteste l’existence de l’intégration, pas les détails de comportement. Exemple knx.org — gateway KNX/DALI‑2.
• “Le capteur suffit” : non. La DALI Alliance rappelle que les contrôleurs peuvent exploiter les capteurs de manière différente (événements, polling, périodicité), et tous ne supportent pas forcément les input devices. Tech note “instance types”.

Livrables recommandés pour une exploitation hôtelière maintenable

Au-delà de la réception, un constant light “confort” doit rester maintenable au jour 2 (remplacement d’un capteur, changement d’affectation, rénovation partielle). Demandez que le DOE inclue :

• la fiche paramètres par zone (réglages, priorités, modes, et où ils sont configurés) ;
• la description d’architecture (qui calcule la boucle, quelles dépendances en intégration) ;
• les scénarios d’usage (jour/soir/nuit/ménage) et leur logique ;
• une procédure de retour à un état de référence (réinitialisation de paramètres, restauration).

Sur la logique DOE/exploitation : DOE et maintenance d’un hôtel connecté : que faut-il remettre à l’exploitant ?.

Pour aller plus loin (guides Domocasa liés)

• Réception d’un éclairage DALI‑2 en hôtel : vérifier l’interopérabilité et éviter les incompatibilités
• DALI : comment fonctionne l’éclairage professionnel intelligent ?
• Rénover un éclairage DALI en hôtel : ce qui change avec DALI‑2 et comment migrer

Sources et documentation (références techniques consultées)

• DALI Alliance — DALI‑2 (programme de certification et base produits)
• DALI Alliance — Control devices (rôle des application controllers)
• DALI Alliance — Sensors and other input devices (Parts 301–304, Part 304)
• DALI Alliance — Tech note “instance types” (support des input devices, event/polling)
• DiiA — Changes to IEC 62386 enabling DALI‑2 (note PDF)
• KNX Association — exemple de passerelle KNX/DALI‑2 (fiche device)

Besoin d’un cadrage CCTP + protocole de recette sur une zone témoin (chambre, lobby, restaurant) avant déploiement ? Domocasa peut vous accompagner sur la définition des comportements attendus, la matrice de priorités et les tests d’acceptation.