L'éclairage connecté doit être spécifié comme un système d'exploitation complet, et non ajouté comme une fonctionnalité après la sélection des luminaires. Choisissez d’abord l’architecture, puis rattachez à cette architecture chaque luminaire, pilote, capteur, protocole de commande, passerelle, interface logicielle et essai de mise en service. Le niveau de connectivité approprié est le système le plus simple capable de fournir les séquences, l’intégration et la maintenabilité requises.
Choisissez l’architecture avant la liste des appareils
Les commandes autonomes peuvent convenir à une pièce ou à une zone simple dans laquelle des capteurs et interrupteurs locaux assurent le comportement requis. Les systèmes par pièce coordonnent plusieurs appareils et scènes sans nécessairement dépendre d’un réseau central. Les systèmes connectés à un réseau central peuvent prendre en charge la programmation horaire, la configuration à distance, la supervision, l’analyse et l’intégration aux systèmes du bâtiment, mais ils ajoutent aussi des obligations liées aux logiciels, aux comptes, au réseau, à la cybersécurité et au cycle de vie.
Le Département américain de l’énergie et le Pacific Northwest National Laboratory décrivent les systèmes d’éclairage connecté comme des plateformes pouvant combiner des capteurs en réseau, une connectivité Internet et des interfaces avec d’autres commandes du bâtiment. Ces capacités ne sont utiles que lorsque le projet comporte un cas d’usage défini et un responsable des données et responsabilités système qui en résultent.
Pour les bureaux, les commerces et les espaces publics, le solutions d’éclairage commercial et de vente au détail La page fournit le contexte d'application. La spécification du projet doit néanmoins indiquer quelles pièces et quelles décisions nécessitent réellement une connectivité.
Définir la limite entre driver et protocole
« Dimmable » ne constitue pas une spécification complète d’interface. Indiquez si la voie utilise une commutation, un contrôle de phase, 0–10 V, DALI, un protocole sans fil nommé ou une autre méthode définie. Consignez le modèle de pilote, la plage de variation, la courbe de commande, le comportement en veille, l’alimentation auxiliaire, la polarité du câblage, l’adressabilité et l’état de défaillance.
Le Guide de compatibilité du driver LED, de la gradation et de la commande explique pourquoi les seules étiquettes de protocole ne confirment pas un fonctionnement stable sur toute la plage. Testez la combinaison exacte de pilote, contrôleur, firmware et câblage prévue pour le projet.
Transformer les pièces en zones et séquences testables
Un plan de plafond réfléchi ou un tableau des pièces doit indiquer les luminaires commandés, les capteurs, les postes muraux et les limites des zones. Pour chaque zone, définissez le comportement en présence, en absence, à la lumière du jour, hors horaires, en dérogation manuelle, en urgence et en cas de perte de communication.
Évitez les formulations telles que « commande par lumière du jour lorsque requise » sans objectif ni réponse. Indiquez les hypothèses d’emplacement du capteur, la consigne ou la méthode de définition de l’objectif, le niveau minimal et maximal, le comportement de fondu, le délai, la durée de dérogation et l’interaction avec les programmations horaires. Lorsque la qualité visuelle est déterminante, le Guide UGR, CRI et scintillement aide à distinguer les métriques du luminaire et du driver de la séquence de commande.
Spécifier l’intégration et la propriété des données
Pour l’intégration à l’automatisation du bâtiment, identifiez l’interface, la passerelle, les points de données, la fréquence de mise à jour, la priorité des commandes et le comportement en cas de défaillance. Décidez si le système d’automatisation du bâtiment lit l’état de l’éclairage, envoie des commandes ou les deux. Désignez la partie responsable de chaque côté de l’interface et de l’essai de réception.
Le Département américain de l’énergie indique que l’interopérabilité de l’éclairage connecté a impliqué des API ainsi que des limites et des compromis. La disponibilité d’une API ne garantit pas que les points, autorisations, latences ou prises en charge du cycle de vie requis sont présents. Exigez la documentation exacte de l’interface et la version utilisées pour le projet.
Définir les responsabilités de cybersécurité et de compte
Le périmètre de sécurité doit suivre l’architecture sélectionnée. Un capteur autonome local présente une exposition différente de celle d’un réseau géré dans le cloud. Consignez la segmentation réseau, les rôles utilisateurs, la propriété de l’administration, le transfert des mots de passe et identifiants, la politique d’accès à distance, la responsabilité des mises à jour, la journalisation des événements, la sauvegarde et la planification de fin de service.
Ne laissez pas le compte enregistré au nom d’un installateur sans procédure de transfert. Définissez également ce qui se passe si un service cloud, une passerelle ou une connexion Internet est indisponible. La question n’est pas de savoir si le produit est qualifié de « sécurisé », mais si le projet peut identifier les responsables, les voies d’accès, les décisions de mise à jour et les étapes de reprise.
Mettre en service selon une matrice de réception
La mise en service doit reproduire les états spécifiés plutôt que de confirmer uniquement que les lampes s’allument. Testez au moins un point représentatif dans chaque zone et chaque exception susceptible de modifier sensiblement le fonctionnement.
| Zone d'acceptation | Action de test | Élément à consigner lors de la remise |
|---|---|---|
| Identité de l’appareil | Faire correspondre l’adresse, le modèle et l’emplacement physique | Nomenclature des appareils telle que construite |
| Fonctionnement de la zone | Déclencher chaque capteur, scène et programme | Niveau, temporisation et résultat observés |
| Variation | Tester les comportements minimum, maximum, de variation et d’arrêt | Combinaison driver/contrôleur et réglages |
| Intégration | Lire et commander les points BAS convenus | Version de l’interface, liste des points et résultat des exceptions |
| Mode de défaillance | Supprimer le réseau, la passerelle ou l’entrée capteur comme spécifié | État par défaut et comportement de récupération |
| Contrôle d’accès | Tester les rôles utilisateur et administrateur | Propriétaire du compte et enregistrement du transfert des identifiants |
Le Panneau LED RGB+CCT dimmable constitue une voie produit pertinente lorsque la sortie multicanale et la commande font partie du cahier des charges. Son utilisation dans un projet dépend toujours de la méthode de commande, de la configuration et des preuves approuvées pour ce projet.
Transformer la mise en service en une remise maintenable
Fournissez la liste des appareils telle que construite, le plan des zones, la séquence, l’export des réglages, les versions de firmware, les détails de la passerelle, les rôles administrateur, le dossier de formation et la procédure de remplacement. Confirmez si un pilote ou capteur de remplacement doit être réadressé et comment la configuration précédente est restaurée.
Utilisez la Présentation de l’usine et des capacités de fabrication de New Lights lors de l'alignement de la configuration des luminaires et des enregistrements de production, et le centre de téléchargement pour les fichiers produits actuellement publiés. La documentation produit et les réglages finaux du projet doivent rester distincts tout en étant liés.
Poser les questions de cycle de vie avant l’approbation
Confirmez qui assure le support du logiciel, pendant combien de temps les remplacements compatibles devraient rester disponibles, si les réglages peuvent être exportés, comment les mises à jour du firmware sont approuvées et ce qui se passe lorsqu’une passerelle ou un service est retiré. Évitez une conception qui ne peut assurer la séquence du jour d’ouverture que tant qu’un compte installateur reste actif.
Le même principe s’applique aux données de projet. Le guide de préparation des données pour le passeport numérique de produit de l’UE couvre une tâche réglementaire différente, mais sa méthode de contrôle d'identité et de révision est utile pour relier les appareils, le firmware, les documents et les dates d'effet.
Questions fréquemment posées
Chaque projet commercial a-t-il besoin d’un éclairage en réseau ?
Non. Utilisez une commande en réseau lorsque ses fonctions de programmation, de supervision, d’intégration ou de données répondent à une exigence définie du projet. Un système autonome ou par pièce peut être plus facile à mettre en service et à maintenir pour des espaces plus simples.
DALI ou 0–10 V garantissent-ils la compatibilité de variation ?
Non. Le protocole ou l'interface n'est qu'une limite. Confirmez ensemble le driver exact, le contrôleur, la plage de fonctionnement, le câblage, le firmware et le comportement requis.
Que doit contenir une remise de projet d’éclairage connecté ?
Incluez les identités des appareils, les cartes de zones, les séquences, les sauvegardes de réglages, les versions de firmware, les documents d'interface, les rôles utilisateurs, les identifiants, la formation et les procédures de remplacement ou de récupération.
Qui doit être propriétaire du compte cloud ou administrateur ?
Le projet doit désigner l'organisation responsable de l'exploitation et le processus de transfert avant réception. L'accès de l'installateur peut être maintenu uniquement dans le cadre d'un modèle de support et de sécurité convenu.
Rédiger la séquence de fonctionnement avant le bon de commande
Pour un appel d’offres RFQ d’éclairage connecté, contactez New Lights avec le tableau des pièces, les séquences requises, le protocole de commande, les types de luminaires, les points d’intégration, les contraintes réseau, les essais de mise en service et les exigences de transfert. Ces informations sont plus utiles que de demander un « éclairage intelligent » comme fonctionnalité non définie.
