Category "Énergie et CVC"

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

Un éclairage DALI‑2 peut être « OK à la réception » et devenir difficile à maintenir quelques mois plus tard si l’exploitant ne dispose pas de la cartographie d’adressage, des groupes/scènes réellement programmés, et d’un inventaire vérifiable des produits installés (et de leur statut de certification).

Ce guide propose un dossier d’exploitation minimal (orienté remise / jour 2) pour un hôtel : il vise l’autonomie (dépannage, remplacement d’équipements, évolution de scènes), sans dépendre systématiquement du prestataire de mise en service.

Périmètre : lot éclairage DALI‑2 (drivers / capteurs / contrôleurs DALI, passerelles éventuelles). Les obligations réglementaires locales ne sont pas traitées ici : elles varient selon le projet et le cadre applicable.

Pourquoi un dossier d’exploitation DALI‑2 spécifique (et pas un DOE “papier” générique) ?

En DALI, l’exploitation quotidienne se fait rarement « luminaire par luminaire ». En pratique, l’hôtel travaille avec :

• des adresses (pour identifier un équipement précis),
• des groupes (zones fonctionnelles),
• des scènes (ambiances),
• et des déclencheurs (boutons, capteurs, horaires, intégration GTB/GRMS).

Si ces éléments ne sont pas documentés et sauvegardés, le système reste pilotable… mais devient fragile à maintenir : un simple remplacement de driver ou une modification d’ambiance peut entraîner des régressions, voire une reprogrammation complète.

Rappels utiles (pour cadrer vos livrables)

DALI‑2 : interopérabilité et certification (à vérifier sur une base publique)

DALI‑2 renvoie à des spécifications techniques et à un programme de certification opéré par la DALI Alliance (DiiA). Côté exploitant, le point clé est opérationnel : vous devez pouvoir recouper les références installées avec la base produits publique, et conserver une traçabilité suffisante pour éviter les confusions de versions.

Adresses, groupes, scènes : les limites “bus” à connaître (pour détecter un DOE incomplet)

Sans transformer votre remise en audit normatif, il est utile de connaître quelques repères décrits dans le DALI Quick Start Guide :

• les commandes peuvent être adressées à un équipement, à un groupe, ou en broadcast (diffusion),
• les scènes sont stockées au niveau des équipements d’éclairage (control gear) et rappelées par commande,
• la structuration adresses / groupes / scènes impose une discipline documentaire : si vos tableaux sont absents, l’exploitation devient dépendante.

Le dossier minimal à exiger à la remise : 4 blocs

Bloc A — Architecture “tel que construit” (as built)

Objectif : diagnostiquer vite (panne de segment, défaut d’alimentation, problème localisé), et isoler clairement ce qui relève du DALI et ce qui relève d’une intégration (GTB/GRMS, IP, passerelle).

À exiger (minimum) :

• Synoptique as built : lignes/bus DALI (par zone/étage), alimentation(s) de bus, application controller(s), passerelles éventuelles (ex. vers GTB/GRMS).
• Plan ou schéma de repérage terrain : coffrets/armoires, borniers, repères, correspondance “zone ↔ ligne/bus”.
• Topologie déclarée (étoile / ligne / mix) et points de segmentation (si applicable).

Recommandation projet : ajoutez une page « hypothèses d’installation » (ce qui a été retenu et pourquoi) plutôt qu’un simple schéma : c’est souvent ce qui fait gagner du temps en dépannage.

Bloc B — Inventaire des produits installés + preuve de certification

Objectif : remplacer sans régression, maîtriser le multi‑marques, et vérifier la conformité annoncée au marché.

À exiger (minimum) :

• Inventaire par bus / zone : drivers (control gear), capteurs et interfaces (input devices), contrôleurs DALI (control devices), alimentations de bus, passerelles.
• Pour chaque référence : marque, référence commerciale, rôle (control gear / control device / input device), localisation, quantité.
• Éléments d’identité permettant de confirmer qu’il s’agit bien du produit certifié listé dans la base DALI Alliance (ex. GTIN et informations associées lorsque disponibles côté produit/base).

Pièces justificatives (pragmatiques) :

• un export (CSV/PDF) de l’outil de mise en service/supervision montrant les équipements détectés,
• pour les références “critiques” (drivers principaux, contrôleur, capteurs) : lien vers la fiche correspondante dans la Product Database (ou un identifiant permettant de la retrouver sans ambiguïté).

Règle simple à écrire dans votre demande de remise : « Tout équipement présenté comme DALI‑2 certifié doit être retrouvable dans la Product Database. S’il ne l’est pas, il doit être explicitement identifié comme non certifié (ou hors périmètre de certification) dans l’inventaire. »

Bloc C — Adressage, groupes, scènes : la cartographie d’exploitation

Objectif : comprendre “qui pilote quoi”, modifier une ambiance, réadresser un équipement remplacé, et diagnostiquer les effets de bord (un bouton qui agit sur la mauvaise zone, une scène incomplète, etc.).

1) Table d’adressage (par bus)

À exiger : un tableau « adresse → équipement », lisible par l’exploitation, comprenant au minimum :

• adresses DALI et type d’équipement,
• zone/localisation (étage, secteur, local technique),
• désignation exploitation (noms compréhensibles),
• marque/référence (renvoi vers l’inventaire).

2) Table des groupes

À exiger : la liste des groupes, leur nom d’usage, et leurs membres (adresses). Sans cette table, vous ne pouvez pas reprendre proprement une logique “zone”.

3) Table des scènes (ambiances)

À exiger : la liste des scènes réellement utilisées, avec :

• nom d’usage (Accueil jour, Accueil nuit, Nettoyage…),
• zone/groupe concerné,
• déclencheur (bouton, horaire, GTB/GRMS…),
• résultat attendu (au minimum par groupe ; plus fin si votre programmation est plus fine).

4) Matrice “entrées → actions” (boutons/capteurs → groupes/scènes)

À exiger : une matrice qui relie chaque commande (bouton, capteur, contact) à l’action attendue : groupe ciblé, scène rappelée, temporisations/conditions utiles à l’exploitation et au support.

Bloc D — Sauvegardes, accès et restauration (anti-dépendance)

Objectif : ne pas être bloqué si un contrôleur tombe en panne, si un prestataire intervient sans traçabilité, ou si vous devez répliquer une configuration sur une zone similaire.

À exiger (minimum) :

• Fichier(s) projet natifs de l’application controller / outil de mise en service (format éditeur), plus la version logicielle utilisée.
• Exports lisibles (CSV/PDF) : inventaire détecté, adressage, groupes, scènes, matrice entrées→actions. (Il n’existe pas, à notre connaissance, un format universel unique “DOE DALI‑2” : contractualisez les formats acceptés sur votre projet.)
• Accès : comptes, niveaux de droits, adresses IP si applicable, procédure de remise/changement de mots de passe (à gérer selon vos règles IT).
• Procédure courte (et testée) : restauration du projet, remplacement d’un équipement, réintégration dans groupes/scènes, vérification du résultat.

Vérifications rapides le jour de la remise (orientées exploitation, pas “audit laboratoire”)

Vérifier que la logique groupes/scènes est documentée (sinon vous êtes dépendant)

Choisissez quelques zones représentatives (ex. un couloir, un lobby, un espace back‑of‑house) et vérifiez :

• qu’un groupe “zone” existe et correspond au terrain,
• qu’une ou deux scènes correspondent à une intention d’usage claire et reproductible,
• qu’un déclencheur (bouton/capteur/horaire) correspond à la matrice entrées→actions remise.

Si “ça marche” mais que les tables (adressage/groupes/scènes) ne sont pas remises, vous n’avez pas un dossier d’exploitation : vous avez une démonstration.

Vérifier l’inventaire et la certification sur un échantillon critique

Sur quelques références clés (drivers dominants, contrôleur, capteurs), recoupez :

• la référence exacte installée (marque + référence),
• sa présence dans la Product Database si elle est annoncée certifiée,
• et, si nécessaire, les éléments d’identité permettant d’éviter une confusion de variante/version.

Cette vérification est particulièrement utile en hôtellerie, où le stock de maintenance et les remplacements par lots font vite apparaître des “quasi‑équivalents” qui ne se comportent pas exactement pareil.

Modèles de tableaux (à copier-coller dans votre demande de remise)

Modèle 1 — Adressage (par bus)

Bus	Adresse	Type	Zone	Désignation exploitation	Marque / Référence	Remarques
DALI-A	…	Control gear / Control device / Input device	…	…	…	…

Modèle 2 — Groupes

Bus	Groupe	Nom du groupe	Membres (adresses)	Usage
DALI-A	…	…	…	Zone / Ménage / Maintenance / Autre

Modèle 3 — Scènes

Bus	Zone / Groupe	Scène	Nom d’usage	Déclencheur	Résultat attendu
DALI-A	…	…	…	Bouton / Horaire / GTB	…

Modèle 4 — Entrées → Actions

Commande (device/instance)	Localisation	Évènement	Action (groupe/scène)	Temporisations / conditions	Comment tester
…	…	Appui / Présence / Absence…	…	…	…

À relier à vos autres livrables “hôtel” (pour éviter les angles morts)

Ce dossier d’exploitation DALI‑2 ne remplace pas vos documents d’exploitation transverses (réseau, supervision, organisation maintenance). Pour une approche DOE “jour 2” plus globale, voir : DOE et maintenance d’un hôtel connecté : que faut-il remettre à l’exploitant ?

Et si votre enjeu est de valider l’interopérabilité (preuves, tests de réception, réduction du risque multi‑marques), 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.

Conclusion

Un bon dossier d’exploitation DALI‑2 pour un hôtel tient en quatre blocs simples : as built, inventaire vérifiable (avec statut de certification quand il est revendiqué), cartographie adresses/groupes/scènes, et sauvegardes + procédures de restauration. C’est ce socle qui vous évite de “tout reprogrammer” au premier remplacement, et qui protège votre exploitation contre la dépendance à un outil ou à un prestataire unique.

Si vous le souhaitez, Domocasa peut vous aider à transformer cette checklist en liste de livrables contractuels (formats, responsabilités, critères de réception) adaptée à votre architecture (DALI‑2 local, intégration KNX/GTB/GRMS, supervision).

Sources et documentation

• DALI Alliance (DiiA) — DALI Quick Start Guide (Version 1.1, April 2023)
• DALI Alliance — DALI‑2 certification status
• DALI Alliance — Product Database (API / accès public)

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é.

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.

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

D4i en hôtellerie : partir des “données luminaire”, sans sur‑promettre

Dans un hôtel, l’éclairage est partout (chambres, circulations, restaurants, back‑of‑house). Pourtant, la vraie difficulté commence souvent après la réception de chantier : inventorier ce qui a été réellement posé, remplacer vite ce qui tombe en panne, documenter les variantes (optique, température de couleur, finitions), et comprendre les dérives (surconsommation, défauts récurrents, erreurs de paramétrage).

D4i (DALI for IoT) est parfois présenté comme une brique “IoT‑ready”. C’est utile… à condition de bien distinguer :

• ce que la certification D4i garantit côté luminaire/driver (présence de certaines capacités de données et d’alimentation),
• ce qui dépend du système (collecte, passerelles, supervision/GTB/GRMS, historisation, alertes, ticketing, exports, cybersécurité).

Ce guide traduit D4i en exigences d’exploitation “jour 2” réellement actionnables en hôtellerie : diagnostic, inventaire et énergie — et encadre clairement les limites, notamment sur la “maintenance prédictive”.

Comprendre D4i : ce que c’est (et ce que ce n’est pas)

D4i = une extension de la certification DALI‑2

La DALI Alliance présente D4i comme une extension du programme de certification DALI‑2, orientée “luminaire connecté”, avec un socle d’exigences obligatoires (dont les smart data).

Traduction opérationnelle côté maîtrise d’ouvrage / exploitation hôtelière :

• DALI‑2 vise l’interopérabilité de produits certifiés, mais certaines capacités de “data” peuvent être optionnelles selon les équipements.
• D4i impose un socle minimal de données côté driver, ce qui facilite l’inventaire et le diagnostic si la collecte est prévue.

Pour clarifier le vocabulaire (DALI‑2 / D4i / DALI+), vous pouvez aussi lire : différences entre DALI‑2, D4i et DALI+.

D4i facilite l’intégration sur luminaire… mais ne remplace pas la supervision

D4i aide à standardiser l’intégration de “devices” sur ou dans le luminaire (capteurs, interface de communication), notamment via des exigences d’alimentation et de comportement. Mais D4i ne dit pas, à lui seul :

• quel protocole bâtiment ou quelle interface vous utiliserez (GTB, GRMS, supervision),
• comment les alertes seront définies, acquittées et historisées,
• comment vous transformerez un défaut en ticket GMAO, en intervention et en preuve de résolution.

En pratique : D4i normalise des données “au plus près du luminaire”. La valeur en exploitation dépend de l’architecture de collecte et de supervision.

Quelles données D4i sont réellement exploitables ?

Le point clé, côté exploitation : D4i rend obligatoires des familles de données normalisées dans le driver, issues des spécifications DALI Data :

• Luminaire Data : informations “asset” (identité, caractéristiques),
• Energy Data : énergie/puissance (selon ce que le driver implémente),
• Diagnostics Data : compteurs et états utiles au dépannage.

Attention : les pages de synthèse indiquent aussi que certains champs restent optionnels selon la spécification détaillée et le produit. Cela doit être cadré dans votre consultation si vous visez un usage précis (inventaire, indicateurs énergie, règles d’alerting).

Famille de données (DALI Data)	À quoi ça sert en hôtellerie	Limites à cadrer (projet / supervision / marché)
Luminaire Data (Part 251)	inventaire “as‑built” fiable (variantes, références), DOE numérique plus maintenable, standardisation multi‑sites (chaîne hôtelière).	les champs peuvent être supportés mais mal renseignés : exiger un encodage réel, prévoir une méthode d’export exploitable (et répétable).
Energy Data (Part 252)	indicateurs énergie par zone/groupe, détection de dérives (usage atypique), corrélation avec occupation/horaire (si données disponibles côté hôtel).	ne pas confondre avec du comptage “réglementaire” : usage exploitation, qualité, granularité, et exploitation dépendent de l’historisation et des règles côté système.
Diagnostics Data (Part 253)	déclenchement d’alertes avant plainte client (défauts explicites), aide au diagnostic (driver vs source vs module), maintenance basée sur compteurs simples (heures, démarrages) sans promettre de prédiction.	tous les champs ne sont pas forcément présents selon produits : lister vos besoins, le ticketing/GMAO reste un lot système (et non une “fonction D4i”).

Part 251 (Luminaire Data) : l’inventaire “as‑built” au niveau luminaire

Cette famille regroupe des informations utiles à l’asset management. Les exemples cités par la DALI Alliance incluent notamment des caractéristiques luminaire (ex. informations de flux, CCT/CRI, etc.).

Ce que vous pouvez raisonnablement exiger en hôtellerie :

• des champs réellement renseignés (pas seulement “supportés”),
• une convention de nommage/variantes (même référence commerciale, optiques ou températures de couleur différentes),
• une méthode de lecture/export intégrable au DOE (CSV/JSON, ou export supervision).

Pour replacer ces exigences dans une logique DOE, voir aussi : DOE et maintenance d’un hôtel connecté : que faut‑il remettre à l’exploitant ?

Part 252 (Energy Data) : utile pour piloter, comparer, détecter

La DALI Alliance cite des catégories telles que active energy/power, apparent energy/power et load‑side energy/power, en précisant que certaines informations sont optionnelles selon les spécifications détaillées.

Ce que ça change (si vous historisez) :

• suivi énergie par zones (étage, aile, restaurant, BOH),
• comparaison entre zones “équivalentes” (détection de dérives),
• dialogue plus factuel entre maintenance, exploitation et direction (sans sur‑ingénierie).

Point de vigilance : D4i porte sur la capacité à reporter des données. La valeur dépend ensuite de votre collecte, de votre fréquence d’échantillonnage, de votre historisation, et des règles d’analyse retenues (supervision/GTB/BI).

Part 253 (Diagnostics & Maintenance) : le diagnostic devient industrialisable

La DALI Alliance indique que des informations de diagnostic peuvent inclure des conditions de défaillance et des compteurs (ex. temps de fonctionnement, compteur de démarrages, informations électriques/thermiques), tout en précisant que certaines informations sont optionnelles selon la spécification détaillée.

Usages hôtellerie :

• déclencher des tickets sur des défauts explicites (et non sur une simple baisse “ressentie”),
• orienter l’intervention (quoi remplacer, où, avec quelle variante),
• mettre en place des règles simples de maintenance (par seuils ou tendances) sans appeler cela “prédictif”.

Les prérequis D4i qui comptent pour le “jour 2”

Côté drivers : données obligatoires, et exigences d’alimentation

La DALI Alliance indique que, pour les drivers D4i, les Parts DALI Data 251/252/253 deviennent obligatoires. Elle indique également, côté alimentation, une exigence obligatoire autour de Part 250 (Integrated Bus Power Supply), tandis que Part 150 (AUX Power Supply) est présentée comme optionnelle sur la page de synthèse D4i.

Interprétation “marché hôtel” : si vous prévoyez d’ajouter des devices sur luminaire (capteurs, communication), vous devez vérifier dès la conception quel mode d’alimentation est retenu (bus / auxiliaire), et surtout s’il est compatible avec les devices choisis et leur intégration système.

Côté “control devices” montés luminaire : ce que cela implique pour la collecte

La DALI Alliance indique aussi qu’un “control device” D4i (monté dans ou sur le luminaire) relève d’exigences dédiées (notamment Part 351), avec des classes/types, des contraintes de consommation et un mécanisme de priorité.

Le piège courant : acheter “D4i” comme une propriété du luminaire, sans spécifier le chemin complet jusqu’à la supervision. Résultat : des données existent dans les drivers, mais aucune collecte centralisée n’est réellement mise en service, ou l’export n’est pas exploitable.

À traduire en exigences :

• décrire l’architecture cible de collecte (contrôleurs, passerelles, supervision),
• décrire l’export attendu (inventaire + diagnostic + énergie),
• décrire le scénario d’exploitation (alertes, acquittement, ticket, preuves).

La base produits DiiA : un garde‑fou achats et réception

La DALI Alliance indique que les produits D4i certifiés sont listés dans la Product Database, et que des produits non listés ne doivent pas être considérés comme certifiés D4i (la compatibilité fonctionnelle, elle, se vérifie au cas par cas).

Elle précise aussi que la validité de la certification est liée à une identité produit (marque, GTIN, versions firmware/hardware, ID), et que ces informations peuvent être lues depuis une memory bank (voir DALI Alliance — Product Database).

Point crucial : “D4i” n’est pas une promesse uniforme, c’est une vérification de références et versions

En hôtellerie (notamment en rénovation et en multi‑sites), c’est un point clé pour limiter les surprises :

• un produit “proche” d’un modèle certifié n’est pas un produit certifié,
• une version firmware/hardware différente peut changer le comportement réel (interopérabilité, données réellement exposées, bugs, etc.),
• la preuve doit pouvoir se relier à la base, et à l’identification produit en réception.

Attention utile en consultation : les luminaires ne sont pas “certifiés D4i” au sens strict

La DALI Alliance indique que la certification des luminaires n’est pas offerte, tout en autorisant l’usage de la marque D4i sur des luminaires qui respectent des exigences de marque et d’usage. Conséquence côté projet : si un luminaire est présenté comme “D4i”, sécurisez la traçabilité en demandant les références exactes (drivers et, le cas échéant, control devices) et leur présence dans la Product Database.

Transformer D4i en exigences d’exploitation (hôtellerie)

Ci‑dessous, une grille d’exigences typiques orientées “jour 2”, à adapter selon votre périmètre (neuf/rénovation, chambres vs espaces publics, intégration GRMS/GTB, niveau de supervision attendu).

Exigences “inventaire & DOE exploitable”

• Références vérifiables : exiger que les composants annoncés (drivers / control devices) soient vérifiables dans la base produits DiiA, avec une correspondance claire sur les versions.
• Encodage réel de Luminaire Data : exiger non seulement la compatibilité, mais l’encodage effectif des champs utiles à votre exploitation (variantes, caractéristiques, identification).
• Export de réception : exiger un export structuré reliant : localisation (zone/pièce), adresse/identité logique, identifiants produits (selon ce qui est disponible), et données utiles au DOE.

Pour une approche “exigences de données” formalisées et vérifiables, voir : exiger (et vérifier) les bonnes données à la livraison avec buildingSMART IDS.

Exigences “diagnostic & maintenance”

• Lecture & historisation : préciser quelles données seront lues, à quelle fréquence, où elles sont historisées (supervision, GTB, outil tiers) et comment elles s’exportent.
• Règles d’alerting : définir les événements qui déclenchent une alerte exploitable (et éviter les alertes non actionnables).
• Ticketing : définir qui reçoit quoi, comment l’équipe acquitte, et comment la preuve de correction est conservée (processus, pas seulement technologie).

Exigences “énergie” (sans confusion comptage/contrôle)

• Périmètre clair : énergie d’éclairage pour pilotage et comparaison (exploitation), pas une promesse de comptage certifié.
• Indicateurs réalistes : tendances, comparaisons et alertes (zone qui dérive), plutôt que promesse d’optimisation automatique.

Recette de réception : ne pas confondre “compatible” et “exploitable”

En hôtellerie, une recette est souvent ce qui transforme une option technique en résultat réel. Pour cadrer l’interopérabilité et éviter les incompatibilités, voir : réception d’un éclairage DALI‑2 en hôtel : comment vérifier l’interopérabilité.

Maintenance “prédictive” : ce que D4i aide à faire… et ce qu’il ne garantit pas

La DALI Alliance cite des cas d’usage possibles (monitoring, asset management, predictive maintenance…) ; en projet, il faut lire cela comme des potentialités rendues possibles par la disponibilité de données et par l’intégration de devices — pas comme une fonction automatiquement livrée par le simple fait d’acheter “D4i”.

Ce que D4i apporte concrètement

• un socle de données structurées (inventaire, énergie, diagnostic) au niveau driver,
• un cadre d’intégration pour devices montés luminaire,
• une base plus solide pour standardiser des exigences multi‑marques.

Ce qu’il faut en plus pour parler de “prédiction”

• des historiques propres et exploitables (durée, continuité, qualité),
• des règles (seuils/tendances) ou des modèles (statistique/ML) dont les limites sont connues,
• une intégration GMAO (tickets, stocks, SLA) et un process d’exploitation robuste,
• un cadrage clair des responsabilités (qui corrige quoi, dans quel délai, avec quelle preuve).

Recommandation de cadrage : contractualisez d’abord un périmètre “diagnostic + inventaire + énergie” réellement livrable, puis traitez la prédiction comme un lot optionnel, conditionné par la qualité des données effectivement collectées.

Méthode simple avant d’acheter “D4i” pour un hôtel

1. Valider les références : vérifier dans la base produits DiiA les composants annoncés (drivers, control devices) et leurs identités/versions.
2. Demander un export type : exiger un exemple d’export d’inventaire et de diagnostic (format, champs, cohérence) sur une zone pilote.
3. Tester sur zone témoin : une zone représentative (chambre, couloir, espace public) avec vos scénarios d’exploitation (alertes, acquittement, export, ticket).
4. Écrire noir sur blanc ce qui doit être “renseigné” (Luminaire Data) et ce qui doit être “collecté + historisé + exportable” (Energy/Diagnostics).

Conclusion

D4i est particulièrement intéressant en hôtellerie quand on l’utilise comme un outil de fiabilisation du “jour 2” : inventaire, diagnostic, lecture énergie. La certification donne un socle (données normalisées et exigences d’intégration) — mais la valeur dépend de votre capacité à spécifier les champs attendus, vérifier les références/versions dans la base produits, et industrialiser la collecte et le ticketing.

Si vous souhaitez cadrer un lot éclairage “exploitable” (marché, recette, DOE, supervision), Domocasa peut vous aider à transformer ces principes en exigences projet, adaptées à votre architecture (GRMS/GTB/supervision) et à vos contraintes d’exploitation.

Sources et documentation

• DALI Alliance — D4i
• DALI Alliance — DALI Data (Luminaire / Energy / Diagnostics)
• DALI Alliance — D4i certification
• DALI Alliance — billet D4i (contexte)
• DALI Alliance — Product Database (principes de validité de certification : identité/versions, lecture via memory bank)
• DiiA / DALI Alliance — base produits (API)

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

En rénovation hôtelière, l’éclairage est rarement un “lot isolé”. On cherche souvent à étendre (quelques chambres, un étage, un restaurant), à remplacer progressivement des luminaires/drivers, et à ajouter des capteurs — sans immobiliser l’exploitation. Dans ce contexte, la question “DALI vs DALI‑2” revient vite, surtout lorsqu’on doit faire cohabiter un existant hétérogène et des équipements neufs annoncés “interopérables”.

Ce guide propose une méthode de décision (conserver / migrer / segmenter) et une checklist chantier pour éviter les mauvaises surprises : contrôleurs, capteurs, alimentation bus, topologie, adressage, recette en zone témoin. Les points normatifs (IEC 62386) sont cités comme limites et références : la compatibilité réelle reste toujours “produit + version + mise en service”.

Bien nommer ce que vous avez (pour éviter les malentendus)

DALI (le protocole)

DALI (Digital Addressable Lighting Interface) est un protocole standardisé de communication numérique bidirectionnelle pour le contrôle d’éclairage, structuré par la norme internationale IEC 62386 (multi‑parties) et complété par des spécifications et un programme de certification portés par la DALI Alliance (DiiA). Pour un rappel “fonctionnement” orienté exploitation, vous pouvez aussi lire : DALI : comment fonctionne l’éclairage professionnel intelligent ?

« DALI version‑1 » (souvent appelé “DALI‑1” sur le terrain)

La DALI Alliance décrit DALI version‑1 comme une version plus ancienne du protocole qui, historiquement, couvrait principalement les control gear (drivers/ballasts), et ne définissait pas de la même manière (ou pas du tout, selon les cas) un cadre complet et testable pour les control devices (contrôleurs d’application, capteurs, boutons…) ainsi que certains éléments d’écosystème (dont l’alimentation de bus) dans l’approche “version‑1”. Référence : DALI Alliance — DALI / DALI‑2 comparison.

DALI‑2 (à comprendre comme un “cadre + tests”, pas comme un slogan)

DALI‑2 est présenté par la DALI Alliance comme un programme de certification s’appuyant sur la version la plus récente du protocole, visant une meilleure interopérabilité multi‑fabricants grâce à des procédures de tests plus détaillées et une vérification des résultats. Référence : DALI Alliance — DALI / DALI‑2 comparison. Pour clarifier les termes associés (DALI‑2, D4i, DALI+), voir aussi : DALI‑2, D4i et DALI+ : quelles différences pour l’éclairage intelligent ?

Ce qui change avec DALI‑2 (et pourquoi c’est critique en rénovation d’hôtel)

Interopérabilité : le changement se voit surtout côté “contrôle”

En rénovation, il est fréquent de trouver des drivers “DALI” qui semblent se comporter correctement, mais un contrôle plus fragile ou plus “à la marque” dès qu’on ajoute des capteurs, des boutons, des scénarios, ou des passerelles. La DALI Alliance met justement en avant que DALI‑2 élargit le périmètre et vise une interopérabilité multi‑fabricants améliorée via la certification (tests détaillés et résultats vérifiés). Référence : DALI / DALI‑2 comparison.

Révision IEC 62386 (2014) : amélioration de l’interopérabilité et rétrocompatibilité

Un point important pour décider “conserver vs migrer” : la DALI Alliance documente qu’une révision majeure d’IEC 62386 (en 2014) a eu pour objectifs d’améliorer l’interopérabilité, combler des lacunes et standardiser des control devices, tout en maintenant la compatibilité ascendante (backwards compatibility). Référence : DiiA — Changes to IEC 62386 enabling DALI‑2 (PDF).

À traduire en langage chantier : “rétrocompatible” ne veut pas dire “tout marchera en mélangeant n’importe quoi”. Cela signifie plutôt que l’évolution du standard a été pensée pour ne pas casser le parc au niveau protocolaire, tout en ajoutant des clarifications (timings, comportements attendus, cas limites) susceptibles d’exposer des équipements historiquement “tolérants” mais non stricts.

Capteurs DALI‑2 : des “Parts” dédiées et certifiables

La DALI Alliance indique que des input devices (ex. boutons, capteurs) sont spécifiés par des parties dédiées (notamment Parties 301 à 304 selon les familles de dispositifs) et que la certification DALI‑2 peut s’appliquer à des produits implémentant une ou plusieurs de ces parties. Référence : DALI Alliance — Sensors et, pour la vue “statut/parts”, DALI‑2 status.

Méthode de décision (rénovation/extension) : conserver, migrer, ou segmenter

La bonne stratégie dépend rarement d’un choix “religieux” DALI vs DALI‑2. Elle dépend de ce que vous changez réellement et de ce que vous devez garantir en exploitation (continuité de service, maintenabilité, multi‑marques, remplacements au fil de l’eau).

Cas A — Vous remplacez surtout des luminaires/drivers, sans ajouter de capteurs ni logique avancée

Vous pouvez souvent conserver l’existant si le contrôleur reste en place et si vous verrouillez les risques “bus” (alimentation, câblage, distances, adressage). Cela correspond à des rénovations “à l’identique amélioré” (par exemple remplacement de luminaires en chambres, sans refonte de la logique).

Points à sécuriser systématiquement (référence : DALI Quick Start Guide (PDF)) :

• Alimentation du bus : le bus DALI doit être alimenté pour communiquer (le guide décrit une tension typique de bus), avec des alimentations pouvant aller jusqu’à une limite de courant indiquée.
• Budget courant : l’alimentation doit couvrir la consommation cumulée des équipements présents sur le bus.
• Topologie et distances : le guide décrit un bus 2 fils, des topologies possibles (chaîne/étoile/mix), l’interdiction d’une boucle fermée, et donne des recommandations de câble et de distance maximale “entre les deux appareils les plus éloignés”.

Décision pratique : si vous gardez le même contrôleur et que vous ne changez pas le “système de contrôle” (capteurs/logiciels/scènes), concentrez l’effort sur la stabilité électrique et topologique du bus, puis sur la recette fonctionnelle minimale (variation, scènes, retours d’état utiles).

Cas B — Vous voulez ajouter/standardiser des capteurs et des contrôleurs en multi‑marques

La migration vers DALI‑2 devient généralement l’option la plus maîtrisable, parce que DALI‑2 encadre (et cherche à certifier) des control devices (capteurs, boutons, contrôleurs), alors que DALI version‑1 ne les couvrait pas dans le même cadre. Référence : DALI / DALI‑2 comparison.

En hôtellerie, ce cas arrive typiquement lors de :

• rénovation chambre par chambre (ajout d’occupation, scénarios ménage/DND/MUR selon l’architecture),
• rénovation des circulations (présence + asservissement),
• standardisation maintenance (remplacements plus simples, moins de dépendances “propriétaires”).

Conseil de méthode : traitez le sujet comme une chaîne “capteurs → contrôleur → gear”, pas comme une simple compatibilité de drivers.

Cas C — Vous étendez l’installation et vous devez faire cohabiter “ancien + neuf”

L’approche la plus pragmatique, surtout quand l’hôtel ne peut pas s’arrêter, consiste à :

1. Conserver temporairement un segment existant (pour limiter l’impact sur l’exploitation),
2. déployer un segment rénové “propre” (souvent en DALI‑2 sur la partie contrôleurs/capteurs),
3. planifier un raccordement/une convergence seulement après validation en zone pilote.

Attention : l’extension “au fil de l’eau” force parfois la segmentation (plusieurs bus, plusieurs contrôleurs, passerelles). Le DALI Quick Start Guide rappelle notamment une capacité d’adressage par bus (distinguant gear et control devices), qui devient vite un point bloquant quand on ajoute des capteurs et des boutons bus‑powered.

Les pièges les plus fréquents au chantier (et comment les éviter)

Confondre “compatible DALI” et “interopérable”

La DALI Alliance oppose explicitement l’ambition d’interopérabilité de DALI‑2 (tests plus complets, résultats vérifiés) et les limites historiques d’une approche “version‑1” au périmètre plus restreint. Référence : DALI / DALI‑2 comparison.

Action projet (recommandation) : sur les nouveaux lots (contrôleurs, capteurs, alimentations de bus, passerelles), exigez des références identifiables et vérifiables, et surtout prévoyez une recette en zone pilote. Sur ce point, vous pouvez compléter avec notre article orienté réception : Réception d’un éclairage DALI‑2 en hôtel : vérifier l’interopérabilité.

Sous‑dimensionner (ou mal gérer) l’alimentation de bus

Le dimensionnement et la configuration de l’alimentation de bus sont des causes classiques de comportements instables (détection intermittente, pertes de commandes, commissioning difficile). Le DALI Quick Start Guide fournit des ordres de grandeur et des limites (tension typique, courant maximal par bus, recommandations de mise en œuvre).

• Comptez les équipements et leur consommation bus (y compris capteurs/boutons alimentés par le bus).
• Vérifiez qu’il n’y a pas de “sur‑ajout” d’alimentations en parallèle lors de remplacements partiels (réutilisation + ajout sans re‑cadrage).
• Anticipez qu’un remplacement “fonctionnel” peut changer la consommation bus (par exemple ajout d’input devices bus‑powered).

Topologie : étoile/chaîne possibles, boucle fermée à éviter

En rénovation, une boucle fermée apparaît vite (reprises, dérivations, raccordements non documentés). Le guide DALI décrit des topologies possibles et indique d’éviter la boucle fermée. Référence : DALI Quick Start Guide.

Action projet : exigez un as built (plan “tel que construit”) du bus et prévoyez un contrôle avant réception (instrumentation / testeur / validation par l’intégrateur selon l’outillage disponible).

Distances : l’écart “entre extrêmes” compte en étoile

Le guide DALI donne une recommandation de distance maximale entre les deux appareils les plus éloignés, sous hypothèses (section câble / courant d’alimentation). Référence : DALI Quick Start Guide.

À retenir : en hôtel, une distribution en étoile depuis une gaine technique peut avoir beaucoup de câble “au total” tout en respectant la contrainte “entre extrêmes”. Ce n’est pas intuitif, donc cela mérite un contrôle explicite sur plan.

Adressage : l’extension peut saturer “en silence”

Le DALI Quick Start Guide rappelle une capacité d’adresses par bus, en distinguant gear et control devices. En rénovation/extension, l’ajout de capteurs et de boutons peut faire exploser le besoin d’adresses plus vite que prévu.

• Faites un inventaire d’adresses (ce qui existe réellement, pas seulement ce qui est sur plan).
• Réservez une marge pour les phases futures et les pièces de rechange.
• Si nécessaire, segmentez (plusieurs bus) plutôt que “forcer” l’ajout sur un bus déjà dense.

Checklist de migration DALI “historique” → DALI‑2 (spécial rénovation hôtelière)

Audit terrain (avant de lancer les commandes)

1. Cartographier les bus (zones, longueurs, topologies, points de dérivation).
2. Inventorier : alimentations de bus, contrôleurs, capteurs/boutons, drivers (marque/modèle/référence).
3. Relever : adressage réellement utilisé (gear + control devices) et marge disponible (référence : DALI Quick Start Guide).
4. Vérifier : budget courant bus (dimensionnement, cohérence des alimentations, marge) (référence : DALI Quick Start Guide).
5. Classer les zones selon criticité exploitation (circulations, zones publiques, back‑office, pièces techniques, zones ouvertes tard / tôt), et poser une stratégie de bascule (plages horaires, phasage, modes dégradés).

Stratégie de migration (dans l’ordre du risque)

• Priorité contrôle (contrôleur + capteurs) : c’est souvent là que les incompatibilités se révèlent, et c’est l’axe où DALI‑2 apporte un cadre de certification. Références : Comparison, DALI‑2 status, Sensors.
• Priorité stabilité bus (alimentation + topologie) : dimensionnement, absence de boucle, distances recommandées, cohérence des reprises (référence : DALI Quick Start Guide).
• Priorité remplacement progressif (drivers/luminaires) : à condition de figer les critères de recette (variation, scènes, comportements de reprise) et de documenter les références réellement installées.

Recette en zone pilote (puis généralisation)

En hôtel, une “zone pilote” peut être un étage, un couloir, ou une chambre témoin techniquement représentative. La logique est la même que pour d’autres lots technologiques hôteliers : tester une expérience complète avant de la reproduire. Voir aussi : Chambre témoin hôtel : valider GRMS, CVC et éclairage.

Scénarios à tester (exemples) : adaptez à votre exploitation et à votre architecture (GRMS/GTB éventuelle, procédures ménage, zones communes).

• présence → allumage / absence → extinction ou veille,
• scènes (accueil, lecture, nuit, ménage, circulation),
• commande manuelle + reprise par l’automatisme,
• comportement en cas de micro‑coupures et remises sous tension (la documentation DiiA sur l’évolution IEC 62386 évoque des clarifications liées à l’alimentation et aux timings, à confronter à vos équipements réels). Référence : Changes to IEC 62386 enabling DALI‑2 (PDF).

Limite à annoncer : ces tests valident un périmètre (vos références, vos versions, vos réglages). Ils ne remplacent pas une preuve générique “ça marchera toujours” si vous changez de produits plus tard.

Cas particulier hôtellerie : continuité de service, remplacements “au fil de l’eau” et maintenabilité

Dans un hôtel, la rénovation d’éclairage se confronte à trois réalités opérationnelles :

• Continuité de service : on ne coupe pas facilement des zones (chambres, circulations, espaces communs).
• Remplacements progressifs : un stock de pièces, des changements de marques, et des “petites améliorations” s’étalent dans le temps.
• Maintenabilité (jour 2) : si le contrôle est trop spécifique, chaque remplacement devient une mini‑ingénierie.

Une stratégie DALI‑2 bien cadrée ne supprime pas ces contraintes, mais aide à les rendre pilotables si vous exigez (1) un périmètre clair, (2) une recette, (3) une documentation exploitable (DOE).

Plus largement, si votre rénovation est multi‑lots (réseau, GTB, GRMS, etc.), vous pouvez replacer l’éclairage dans une méthode globale de rénovation hôtel : Rénover la technologie d’un hôtel existant sans refaire tout le bâtiment.

Ce qu’il faut écrire clairement dans vos pièces (CCTP / méthode / DOE)

Dire explicitement de quoi vous parlez (gear vs control devices, parts, zones)

Évitez les formulations “DALI compatible” sans périmètre. Préférez une définition opérationnelle : quels types de produits (drivers, capteurs, contrôleurs, alimentations), quelles fonctions (variation, scènes, retours), et quelles zones. Les pages DALI Alliance relatives au statut DALI‑2 renvoient également à une logique de “Parts” et de références associées. Référence : DALI‑2 status.

Ne pas sur‑promettre l’interopérabilité sans recette

DALI‑2 est conçu pour améliorer l’interopérabilité via certification, mais la réussite chantier dépend d’une recette adaptée à votre exploitation et à vos équipements réels. Référence : DALI / DALI‑2 comparison. Pour une démarche de contrôle, appuyez‑vous sur une recette de réception (zone pilote, preuves, tests) plutôt que sur une simple déclaration produit. Voir : Réception d’un éclairage DALI‑2 en hôtel.

Prévoir le “jour 2” : adressage, plans, procédures de remplacement

Un hôtel vit et évolue. Documentez au minimum : plans de bus as built, segmentation, règles d’adressage, sauvegardes/export de configuration quand c’est possible, et procédure de remplacement d’un driver ou d’un capteur (qui fait quoi, avec quel outillage, dans quels délais).

Résumé décisionnel (lecture en une minute)

• Si vous remplacez surtout des drivers/luminaires et conservez le contrôleur, vous pouvez souvent rester proche de l’existant, à condition de verrouiller alimentation bus, topologie, distances et adressage (référence : DALI Quick Start Guide).
• Si vous ajoutez des capteurs et/ou vous mélangez les marques côté contrôle, DALI‑2 est généralement la trajectoire la plus robuste car il encadre et cherche à certifier les control devices (références : Comparison, Sensors, Status).
• Dans un hôtel, migrez par segments, validez une zone pilote (étage/couloir/chambre témoin) et gardez de la marge (adresses, courant bus) pour les étapes intermédiaires.

Sources et documentation (références publiques)

• DALI Alliance — DALI / DALI‑2 comparison
• DiiA — Changes to IEC 62386 enabling DALI‑2 (PDF)
• DALI Alliance — DALI Quick Start Guide (public, PDF)
• DALI Alliance — DALI‑2 status (Parts / certification scope)
• DALI Alliance — Sensors / input devices

Si vous préparez une rénovation d’éclairage DALI en hôtel et que vous voulez sécuriser la trajectoire (conserver, segmenter, migrer), l’enjeu n’est pas seulement “quel protocole”, mais quels tests, quelles preuves, et quels livrables pour que l’exploitation puisse vivre avec le système.

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

En hôtellerie, l’éclairage de sécurité est un sujet « exploitation » avant d’être un sujet « technologie ». Le besoin terrain est simple : pouvoir déclencher des tests, récupérer des résultats, et remonter vite les défauts (équipement, batterie, bloc d’urgence…) sans dépendre d’opérations manuelles longues, dispersées et difficiles à prouver.

DALI Emergency est l’extension DALI qui vise précisément l’intégration de l’éclairage de sécurité dans un système de contrôle numérique, avec des mécanismes d’automatisation des tests et de reporting exploitables, y compris via une supervision/GTB selon l’architecture retenue. (DALI Alliance — DALI Emergency)

Note de cadrage importante (Maroc / ERP / assurance) : cet article décrit ce que DALI Emergency permet techniquement et ce qu’un exploitant peut raisonnablement exiger en conception et en recette. Les obligations (périodicité, nature des essais, forme des rapports, conservation des preuves, etc.) dépendent du projet et du cadre applicable. La DALI Alliance rappelle seulement que des tests périodiques sont requis dans de nombreux pays et que l’éclairage de sécurité est régi par des réglementations. (source)

À qui sert DALI Emergency (côté exploitation hôtelière) ?

DALI Emergency s’adresse aux projets où l’on veut :

• industrialiser les tests (planification, traçabilité, réduction des passages manuels),
• centraliser les résultats (au moins dans un contrôleur, idéalement dans une supervision si le site en dispose),
• accélérer le diagnostic (identifier une zone, un appareil, un état, un défaut récurrent),
• préparer l’exploitation (preuves de recette, transfert maintenance, continuité de service).

En complément, si vous êtes en phase de réception DALI au sens large (interopérabilité, cohérence DALI‑2, livrables, méthode de tests), vous pouvez aussi lire : Réception d’un éclairage DALI‑2 en hôtel : comment vérifier l’interopérabilité et éviter les incompatibilités.

DALI Emergency en clair : ce que couvre le standard

Le périmètre mis en avant : l’éclairage de sécurité « self-contained »

La DALI Alliance met en avant le cas self‑contained, où la batterie est intégrée au luminaire (ou associée au luminaire). C’est un périmètre important à expliciter dès le CCTP, car les attentes et les interfaces diffèrent selon le type de solution d’éclairage de sécurité retenue. (DALI Alliance — DALI Emergency)

DT1 / IEC 62386‑202 : identifier la “famille” DALI concernée

Côté DALI, le contrôle gear d’urgence pour le self‑contained correspond à IEC 62386 Part 202, également identifié comme Device Type 1 (DT1). (DALI Emergency) (Tech Note — Device Types)

Traduction « exploitation » : demander “DALI Emergency” de façon générique est insuffisant. Pour cadrer un lot et éviter les malentendus, on cherche au minimum à relier la fonction attendue (tests/reporting) à un périmètre de device type / part identifié.

DALI‑2 Emergency : interopérabilité et certification

La DALI Alliance indique que la certification DALI‑2 Emergency est ouverte pour le contrôle gear d’éclairage de sécurité self‑contained, sur la base de l’IEC 62386‑202. (DALI Alliance — DALI Emergency)

Si vous souhaitez replacer DALI‑2 dans l’ensemble des termes DALI (DALI‑2 / D4i / DALI+), voir : DALI‑2, D4i et DALI+ : quelles différences pour l’éclairage intelligent ?.

Automatiser les tests : ce que vous pouvez exiger “fonctionnellement”

La DALI Alliance précise que DALI permet d’automatiser des tests pour l’éclairage de sécurité self‑contained, avec déclenchement par commandes DALI ou via un timer optionnel (selon l’implémentation). (DALI Alliance — DALI Emergency)

Ce que ça veut dire, concrètement, dans un hôtel

Pour éviter les recettes ambiguës (“ça marche”) et les dérives en exploitation (“on ne sait pas prouver”), on peut formuler des exigences orientées résultats, indépendantes des marques :

• Plan de tests : quels tests sont prévus dans votre projet (et sur quelles zones), qui les lance (contrôleur / maintenance / supervision), et comment on évite un impact sur l’exploitation (ex. séquencement par zones).
• Traçabilité : existence d’un journal des tests lancés et de leurs résultats (dans le contrôleur et/ou dans un outil de supervision).
• Exportabilité : capacité à exporter les preuves (fichier, extraction, ou mécanisme équivalent) afin que l’exploitant ne soit pas prisonnier d’un PC de mise en service ou d’une compétence rare.
• Mode dégradé : que se passe‑t‑il si la supervision est indisponible ? Les tests restent‑ils exécutables et les preuves récupérables a posteriori ?

Ce cadrage n’impose pas une forme réglementaire : il garantit simplement que les essais ne sont pas « perdus » et qu’une équipe exploitation peut opérer le système dans la durée.

Remonter les défauts : supervision et diagnostic “praticables”

La page DALI Emergency évoque l’intérêt d’intégration avec des systèmes de gestion du bâtiment (GTB/BMS), qui peuvent accéder aux capacités de contrôle et d’interrogation DALI, incluant tests automatisés et reporting. (DALI Alliance — DALI Emergency)

Point d’attention : la DALI Alliance ne décrit pas, sur cette page, un protocole unique côté GTB (BACnet, Modbus, API, etc.). L’enjeu projet est donc de définir, puis de recetter, la chaîne complète : DALI ↔ contrôleur ↔ passerelle ↔ supervision ↔ export des preuves.

Interopérabilité : vérifier que le contrôleur “comprend” ce qu’il a sur le bus

Un bon diagnostic commence par une capacité simple : savoir identifier les équipements et leurs capacités réelles sur le bus.

La DALI Alliance rappelle que les device types concernent les parties control gear (Parts 2xx), et qu’un contrôleur peut vérifier la capacité d’un équipement via la commande QUERY DEVICE TYPE. (DALI Alliance — Tech Note “Device types”)

Exigence exploitable à écrire et à recetter :

• obtenir une liste d’inventaire par ligne DALI (adresses, localisation, capacité détectée),
• pouvoir relier un événement ou un défaut à un repérage terrain (plans / nomenclature / étiquetage),
• éviter les architectures où seuls l’intégrateur ou un logiciel propriétaire permettent de “relire” l’installation.

Spécifier correctement : “DALI‑2 certifié” ne veut pas dire “tout est certifié”

La DALI Alliance explique que la certification DALI‑2 repose sur des tests créés et maintenus par l’Alliance, dérivés de parties IEC 62386 et/ou de spécifications DiiA ; et que la possibilité de certifier dépend de l’inclusion d’une Part dans les séquences de test. (DALI Alliance — DALI‑2 certification status)

Ce que l’exploitant peut exiger sans entrer dans les détails normatifs

• Matériel d’urgence DALI‑2 Emergency certifié pour le périmètre self‑contained (DT1 / IEC 62386‑202), et pas seulement “compatible”. (DALI Alliance — DALI Emergency)
• Références exactes (marque, modèle, firmware si applicable) et périmètre revendiqué (ce qui est certifié, ce qui ne l’est pas).
• Dossier d’exploitation : qui déclenche les tests, où sont stockés les logs, comment on exporte, qui reçoit les alertes, comment on accuse réception et on suit les actions correctives.

Limite volontaire de ce guide : avec les seules pages DALI Alliance citées ci‑dessus, on ne peut pas établir ici la liste exhaustive des commandes/paramètres de test ni un format standard unique de rapport. Ce point se traite au niveau (i) documentation de l’outil/contrôleur choisi, et/ou (ii) documentation fabricant des équipements, et (iii) cahier de recette spécifique au projet.

Structurer une recette orientée “preuves” (modèle hôtel)

L’objectif est de sortir d’une recette “on allume / ça marche” pour obtenir un dossier exploitable sur plusieurs années : inventaire, repérage, logs, et démonstration que la chaîne de supervision (si elle existe) remonte des informations utilisables.

Pré‑recette documentaire (avant essais)

À demander avant toute mise en service :

• Schéma d’architecture : lignes DALI, contrôleurs, alimentations de bus, passerelles éventuelles vers GTB/BMS.
• Inventaire : liste des équipements d’urgence par zone (circulations, escaliers, issues, locaux techniques…), avec repérage terrain.
• Correspondance adresse ↔ localisation : un plan et une nomenclature qui permettent d’intervenir sans ambiguïté.
• Procédure d’exploitation : qui exécute les tests, quand, comment les preuves sont conservées et comment un défaut est traité (workflow).

Pour élargir à la logique “livrables exploitant” (au‑delà du seul éclairage), voir : DOE et maintenance d’un hôtel connecté : que faut-il remettre à l’exploitant ?.

Recette fonctionnelle (sur site)

Tests typiques (à adapter au projet et au contrôleur retenu) :

• Capacités détectées : vérifier que le contrôleur identifie correctement les équipements pertinents (logique device type / interrogation). (Tech Note — Device Types)
• Déclenchement de tests : démontrer que les tests peuvent être lancés via commandes DALI et/ou via un timer optionnel si la solution s’appuie dessus. (DALI Emergency)
• Collecte des résultats : s’assurer que le résultat est bien enregistré (journal consultable), qu’il est relié à un repérage (zone/appareil), et qu’il est récupérable (export).

Recette de supervision (si GTB / BMS / supervision technique)

Si le projet prévoit une supervision, il est utile de recetter :

• la présence des objets attendus (états, défauts, résultats de tests) dans la supervision,
• la cohérence de nommage (repérage terrain),
• les droits et rôles (qui acquitte, qui modifie la planification),
• le comportement en cas de rupture de communication (alarme, file d’attente, reprise).

La DALI Alliance souligne l’intérêt de l’intégration GTB/BMS autour du contrôle, de l’interrogation, des tests automatisés et du reporting, sans imposer sur cette page un mode d’intégration unique. (DALI Emergency)

Checklist “exploitation” : ce que l’hôtel doit obtenir à la livraison

• Périmètre clair : self‑contained, et identification DT1 / IEC 62386‑202 côté équipements concernés. (DALI Emergency)
• Automatisation des tests démontrée : commandes DALI et/ou timer optionnel selon la solution, avec un scénario exploitable (planification, séquencement). (source)
• Journalisation et preuves : résultats consultables, traçables, exportables (au moins depuis l’outil principal de gestion/contrôle).
• Inventaire + repérage : plans et nomenclature, correspondance adresse ↔ localisation.
• Interopérabilité cadrée : revendications de certification DALI‑2 situées correctement (tests/Parts), avec références précises. (DALI‑2 certification status)

Questions à poser (courtes, actionnables)

1. Les équipements d’urgence self‑contained sont‑ils DALI‑2 Emergency certifiés (DT1 / IEC 62386‑202) ? (source)
2. Comment les tests sont‑ils planifiés : commandes DALI, timer optionnel, supervision ? (source)
3. Où sont stockées les preuves horodatées (journaux) et comment les exporte‑t‑on ?
4. Comment la solution identifie les capacités des équipements (ex. device type / interrogation) et produit un inventaire exploitable ? (source)
5. Si une GTB/BMS existe : quelles informations remontent réellement (états, défauts, résultats) et via quelle chaîne d’intégration ? (source)

Conclusion : viser une installation “testable et prouvable”

Dans un hôtel, la différence entre un éclairage de sécurité « installé » et un éclairage de sécurité « exploitable » se joue souvent sur des détails de méthode : inventaire, repérage, planification, export des logs et recette de la supervision. DALI Emergency fournit un cadre technique pour automatiser les tests et remonter des informations ; à vous (MOA, AMO, exploitant, BE) de transformer ces capacités en preuves et en process contractuels.

Si vous préparez une réception ou une rénovation, Domocasa peut vous aider à cadrer une recette orientée exploitation (livrables, responsabilités, tests et modes dégradés) en complément des exigences de sécurité propres à votre projet.

Sources et documentation

• DALI Alliance — DALI Emergency
• DALI Alliance — DALI‑2 certification status
• DALI Alliance — Tech Note “Device Types”

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

Objectif : vous donner une recette de réception (preuves à exiger + vérifications + tests terrain) pour confirmer qu’un lot annoncé « DALI‑2 » est réellement interopérable et maintenable en exploitation hôtelière, sans dépendre d’un seul fabricant.

Périmètre volontairement strict : éclairage DALI‑2 (drivers / ballasts, capteurs, contrôleurs DALI, alimentations de bus, passerelles DALI). On ne traite pas ici le GRMS/GTB/KNX/BACnet, sauf si votre architecture impose une interface (dans ce cas, la recette DALI‑2 reste valable mais doit être complétée par une recette d’intégration).

Pour un rappel sur les concepts DALI côté exploitation, voir : DALI : comment fonctionne l’éclairage professionnel intelligent ?. Et pour clarifier les termes « DALI‑2 / D4i / DALI+ » : DALI‑2, D4i et DALI+ : quelles différences pour l’éclairage intelligent ?.

Ce que DALI‑2 « garantit »… et ce que vous devez encore prouver en réception

La DALI Alliance (DiiA) indique opérer un programme de certification DALI‑2 « indépendamment vérifié », destiné à démontrer la conformité de produits aux spécifications DALI‑2. Les tests s’appuient sur des DALI‑2 Test Specifications dérivées de parties d’IEC 62386 et/ou de spécifications DiiA. Les produits qui complètent le processus de certification peuvent utiliser les marques DALI‑2 (logos/wordmarks) selon les règles DiiA. Source : DALI Alliance — DALI‑2 certification.

Traduction “exploitation hôtel” : la certification est une base utile, mais elle ne remplace pas une recette de chantier (tests fonctionnels, cohérence des références réellement posées, procédure de remplacement, sauvegarde/restore de configuration, etc.). Votre réception doit donc faire deux choses :

• Prouver que les composants livrés correspondent bien à des produits certifiés (traçabilité).
• Démontrer que l’installation se comporte correctement dans vos usages hôteliers (tests terrain).

Preuve n°1 à exiger : une traçabilité “composant par composant” (pas seulement “DALI‑2” dans un CCTP)

Le livrable attendu (format opérateur)

Demandez au titulaire/intégrateur une liste « as delivered » (tableur) qui couvre tous les composants DALI : drivers/ballasts, capteurs/entrées, contrôleur(s) DALI, alimentations de bus, répéteurs, passerelles DALI, etc. Pour chaque ligne, exigez :

• Marque (celle visible sur l’étiquette/produit).
• Référence commerciale exacte.
• Rôle (driver/control gear, control device, application controller, bus power supply…).
• Lien vers l’entrée correspondante dans la Product Database DiiA (ou capture datée + URL).
• Statut : DALI‑2 Certified (oui/non), D4i Certified (oui/non).
• DALI Parts déclarées (information présente dans la base produits).

Pourquoi c’est crucial : la DiiA explique que sa Product Database contient les composants DALI‑2 et D4i certifiés (et des produits DALI « version 1 » enregistrés). Source : DALI Alliance — Product Database (API publique).

Point d’attention “luminaires” (souvent source de malentendu)

La DiiA indique explicitement qu’elle n’opère pas de programme de certification pour les luminaires. En revanche, elle décrit comment les marques/logos DALI‑2 peuvent s’appliquer aux luminaires lorsque les composants DALI qu’ils contiennent sont certifiés et listés. Source : DALI Alliance — DALI luminaires.

Conclusion réception : ne recevez pas « un luminaire DALI‑2 » comme une promesse vague. Recevez une liste de composants identifiés (drivers, capteurs, etc.) et une preuve base DiiA pour chacun.

Vérifier la certification dans la base produits DiiA (méthode simple, reproductible)

Où vérifier

La DiiA met à disposition une Product Database publique, qui expose notamment des informations telles que le statut DALI‑2 Certified (oui/non), D4i Certified (oui/non) et les DALI Parts. Source : Product Database DiiA.

La procédure de contrôle (à faire pour chaque référence critique)

1. Retrouver la référence exacte dans la base (attention aux variantes et suffixes de référence).
2. Vérifier que le statut attendu est bien « DALI‑2 Certified » (et/ou « D4i Certified » si vous l’exigez au marché).
3. Contrôler les DALI Parts annoncées : elles doivent être cohérentes avec la fonction attendue (driver, capteur, contrôleur…).
4. Archiver une preuve datée (PDF/print avec URL et date de consultation), à intégrer au DOE.

Astuce “exploitation” : faites cette vérification avant la mise en service finale. C’est à ce moment qu’un remplacement de référence (ou une correction de commande) coûte le moins cher.

Le point critique : la certification vaut pour un produit identifié (marque / versions / identifiants)

La Product Database contient un avertissement important : l’information concerne le produit spécifique qui a été testé et la validité est liée à la cohérence entre marque, GTIN, versions firmware/hardware et un ID unique (ces éléments sont présentés comme lisibles via la memory bank 0). Source : avertissements Product Database DiiA.

Comment l’exploiter en réception (sans faire de “test de labo”)

• À la livraison : photos d’étiquettes (marque + référence) et cohérence avec la liste « as delivered ».
• À la mise en service : demandez une exportation des informations disponibles via l’outil de commissioning / contrôleur DALI (et, si l’outil le permet, lecture des informations d’identification). Archivez l’export dans le DOE.
• En maintenance : formalisez une règle simple : toute pièce remplacée doit être strictement équivalente (même identité produit) ou, à défaut, être elle aussi identifiée comme certifiée dans la base DiiA pour la marque effectivement apposée.

Important : ces contrôles doivent être réalisés par des intervenants qualifiés et dans le respect des règles de sécurité électrique du site. Le but ici est la traçabilité et la maintenabilité, pas d’encourager des manipulations improvisées.

Cas à haut risque en hôtel : logos, OEM/ODM et rebranding

La DiiA rappelle que les marques (DALI, DALI‑2, D4i, etc.) sont des marques de la DiiA et que leur usage est encadré. La page « Trademarks and Logos » décrit aussi des points de vigilance pour les situations OEM/ODM et rebranding. Source : DALI Alliance — Trademarks and Logos.

Test opérateur très simple

Si la marque affichée sur le produit (ou sur l’étiquette) ne correspond pas à ce que vous trouvez dans la Product Database, vous êtes dans une zone de risque : demandez une clarification écrite et un alignement (références, marque, preuve base DiiA), ou un remplacement.

Recette terrain : tests d’acceptation “interopérabilité & maintenance” (sans banc de conformité)

Les tests ci-dessous sont des tests d’acceptation projet orientés exploitation. Ils ne prétendent pas reproduire les tests de certification DALI‑2 opérés par la DiiA. L’objectif est de prouver que, dans votre hôtel, l’installation est utilisable et maintenable.

Jeu de tests minimum par zone type

Définissez des zones représentatives (par exemple : chambre type, circulation d’étage, hall, salle de réunion, back‑of‑house) puis validez, pour chaque zone :

• Commande de base : allumage/extinction, variation, comportement cohérent sur l’ensemble des charges.
• Groupes : un groupe commande toutes les charges attendues, et uniquement elles.
• Scènes : rappel de scènes et cohérence après coupure/retour secteur (test à planifier pour ne pas impacter l’exploitation).
• Entrées (si prévues) : capteurs de présence/luminosité, boutons, priorités, temporisations selon vos règles d’exploitation.
• Diagnostic : sur un échantillon encadré, simuler une indisponibilité d’un composant (selon procédure intégrateur) et vérifier que : (a) le reste du bus continue de fonctionner, (b) l’anomalie est identifiable (au minimum par zone/ligne), (c) la remise en état est documentée.

Le test “maintenabilité” qui révèle les mauvaises surprises

Sur une ou deux zones pilotes (avant généralisation) :

• Faites remplacer un driver ou un capteur par une référence identique (même marque/réf).
• Vérifiez que l’intervention est réaliste en conditions d’hôtel : réadressage limité, récupération des groupes/scènes, procédure claire, pas besoin de reprogrammer tout un étage pour une panne isolée.

Si ce test est difficile en “zone pilote”, il sera coûteux et risqué une fois l’hôtel en exploitation.

Les preuves à exiger au DOE (pour éviter le “DALI‑2 en théorie”)

En hôtellerie, un DOE exploitable fait souvent la différence entre une installation “qui marche à la livraison” et une installation “maintenable sur la durée”. Pour cadrer le sujet DOE côté hôtel, vous pouvez aussi lire : DOE et maintenance d’un hôtel connecté : que faut-il remettre à l’exploitant ?.

Pack de preuves “alignées DiiA”

• Exports/prints (datés) des entrées Product Database pour les composants majeurs, avec statut DALI‑2/D4i et DALI Parts. Source : Product Database DiiA.
• Une note de réception qui rappelle le principe : la certification s’applique au produit testé et à son identité (marque/GTIN/versions/ID) tel qu’indiqué par la DiiA, et qui décrit comment le chantier a figé cette identité (photos, exports, liste as delivered, etc.). Source : avertissements Product Database DiiA.

Pack “exploitation” recommandé (pour le jour 2)

• Schémas « as built » : topologie par zone/étage, repérage des lignes/bus, repérage des alimentations de bus et contrôleurs.
• Table d’adressage : adresses DALI, groupes, scènes, logique des capteurs (et les conventions de nommage).
• Sauvegardes de configuration : fichiers/projets de commissioning, versions logicielles, procédure de restauration.
• Procédure de remplacement : pas à pas (ce que l’équipe maintenance doit faire et ce qu’elle ne doit pas faire).
• Liste des références “pièces de rechange” compatibles (avec preuve DiiA quand applicable).

Faut-il exiger des tests de conformité officiels (ProbitLab2) en réception ?

La DiiA explique que les tests de conformité DALI‑2/D4i s’appuient sur des équipements ProbitLab / ProbitLab2 et le logiciel ProbitBench (Lichtvision Engineering), et indique que le support ProbitLab a cessé au 29 février 2024 et que ProbitLab2 est requis pour les tests DALI. Source : DALI Alliance — Testing for DALI‑2 compliance.

Lecture “exploitation hôtel” : vous n’êtes généralement pas censé acheter un banc de conformité pour réceptionner un chantier. En revanche, vous êtes en droit d’exiger : (a) des composants réellement certifiés (preuve base DiiA), (b) une recette terrain documentée, (c) un DOE qui rend l’éclairage maintenable.

Que faire si un composant n’est pas certifié DALI‑2 (ou si la “Part” n’est pas disponible)

La DiiA publie aussi un statut des « DALI‑2 Parts » indiquant que les tests sont dérivés de parties IEC 62386 ou de spécifications DiiA, et qu’une « Part » qui n’est pas incluse dans les séquences de test ne peut pas être certifiée tant qu’elle n’est pas libérée. Source : DALI Alliance — DALI‑2 certification status.

Conduite à tenir en réception :

• Si votre marché exige “certifié DALI‑2”, demandez un alignement produit (référence alternative certifiée) ou une dérogation formalisée (acceptée par la maîtrise d’ouvrage) avec risques clairement explicités (interopérabilité, maintenance, dépendance fournisseur).
• Si le projet accepte un mélange (cas fréquent en rénovation/extension), documentez-le clairement dans le DOE et renforcez les tests terrain et la stratégie pièces de rechange.

Conclusion : la recette DALI‑2 qui protège l’exploitant hôtelier

• Ne recevez pas un mot (« DALI‑2 ») : recevez une liste de composants et une preuve dans la Product Database.
• Figez l’identité des produits installés (marque/référence et, si disponible via l’outil, informations d’identification) : c’est directement lié à la logique de validité rappelée dans la base DiiA.
• Testez des usages (zones types) et testez le remplacement : c’est le meilleur indicateur de maintenabilité.
• Archivez des preuves datées dans le DOE : elles sont déterminantes quand il faut remplacer, étendre ou arbitrer un litige.

Si vous préparez une pré‑ouverture ou une réception multi‑lots, notre checklist globale peut servir de trame, à compléter avec cette recette DALI‑2 : Pré‑ouverture d’un hôtel : la checklist technique des systèmes courant faible.

Besoin d’un appui méthodologique (documents à exiger, plan de tests, DOE exploitable) pour votre hôtel au Maroc ? Domocasa peut vous aider à cadrer une recette orientée exploitation, sans surcharger le projet.

Sources et documentation (consultables)

• DALI Alliance (DiiA) — DALI‑2 certification
• DALI Alliance (DiiA) — DALI‑2 certification status / Parts
• DALI Alliance (DiiA) — Product Database (accès public)
• DALI Alliance (DiiA) — Testing for DALI‑2 compliance
• DALI Alliance (DiiA) — Trademarks and Logos
• DALI Alliance (DiiA) — DALI luminaires