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)
- Les équipements d’urgence self‑contained sont‑ils DALI‑2 Emergency certifiés (DT1 / IEC 62386‑202) ? (source)
- Comment les tests sont‑ils planifiés : commandes DALI, timer optionnel, supervision ? (source)
- Où sont stockées les preuves horodatées (journaux) et comment les exporte‑t‑on ?
- Comment la solution identifie les capacités des équipements (ex. device type / interrogation) et produit un inventaire exploitable ? (source)
- 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.
