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) |
|
|
| Energy Data (Part 252) |
|
|
| Diagnostics Data (Part 253) |
|
|
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
- Valider les références : vérifier dans la base produits DiiA les composants annoncés (drivers, control devices) et leurs identités/versions.
- Demander un export type : exiger un exemple d’export d’inventaire et de diagnostic (format, champs, cohérence) sur une zone pilote.
- Tester sur zone témoin : une zone représentative (chambre, couloir, espace public) avec vos scénarios d’exploitation (alertes, acquittement, export, ticket).
- É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)
