Una instalación conectada no es automáticamente una instalación mejor. Puede aportar regulación, datos, supervisión y capacidad de adaptación; también puede sumar gateways, licencias, dependencias, actualizaciones y una superficie de riesgo que nadie había presupuestado.
La pregunta correcta no es “¿qué protocolo podemos añadir?”, sino “qué problema queremos resolver, cómo lo mediremos y quién lo operará?”. Primero el problema y la métrica. Después, la conectividad que haga falta.
1. La conexión no es el resultado
“Smart lighting”, “IoT” o “iluminación conectada” agrupan soluciones muy distintas. Una instalación puede tener:
- regulación local sin red;
- sensores que actúan sobre un grupo de luminarias;
- control digital direccionable;
- datos de energía o diagnóstico;
- conexión a una plataforma de supervisión;
- integración con un BMS del edificio.
Cada nivel resuelve problemas diferentes. Conectar más dispositivos no mejora por sí mismo el confort, la eficiencia o el mantenimiento. Si nadie usa el dato, si la regulación no está bien configurada o si el sistema no tiene soporte, la conexión se convierte en complejidad operativa.
2. Empezá por el problema y la métrica
Antes de hablar de DALI, D4i o IoT, escribí el problema en una frase verificable:
- “Hay espacios que cambian de uso y necesitamos adaptar escenas sin recablear.”
- “No sabemos qué luminarias fallan y las inspecciones son costosas.”
- “La iluminación queda encendida cuando el espacio está vacío.”
- “El edificio necesita coordinar iluminación, ocupación y horarios con otros sistemas.”
- “El propietario necesita un inventario mantenible, no solo una lista de equipos.”
Después elegí una métrica y una línea de partida. Según el caso, puede ser tiempo de intervención, porcentaje de incidencias localizadas, horas de funcionamiento, consumo medido, cumplimiento de niveles de iluminación, número de cambios de configuración o tiempo de puesta en marcha.
La métrica no tiene que ser espectacular. Tiene que poder medirse antes y después, con el mismo alcance y las mismas condiciones. Si no existe línea de base, una promesa de retorno es solo una hipótesis.
3. Qué añade realmente la conectividad
Una arquitectura conectada suele añadir más que un cable o una radio:
- Campo: luminarias, drivers, sensores, pulsadores y dispositivos de emergencia.
- Control: reglas, escenas, horarios, grupos, direccionamiento y lógica.
- Transporte: bus, red IP, radio, gateway o una combinación.
- Software: herramienta de commissioning, interfaz, servidor, licencia o servicio.
- Operación: inventario, usuarios, permisos, soporte, copias, actualizaciones y respuesta ante fallos.
El beneficio debe justificar este conjunto. Un sensor que reduce horas de encendido puede ser útil, pero solo si está correctamente ubicado, configurado y mantenido. Un dato de diagnóstico puede ayudar, pero solo si alguien recibe la alerta, tiene un repuesto y puede intervenir.
La conectividad también puede cambiar responsabilidades. El instalador quizá ya no entrega solo una instalación eléctrica: puede tener que documentar direcciones, escenas, firmware y pruebas. El responsable de mantenimiento puede necesitar una herramienta y permisos. El propietario puede quedar dependiendo de un proveedor o de una plataforma.
4. DALI, D4i, IoT y BMS no significan lo mismo
DALI: comunicación y control de iluminación
DALI es un sistema digital para controlar y consultar equipos de iluminación. La etiqueta no define por sí sola la topología completa, el controlador, las funciones disponibles ni la puesta en marcha.
DALI-2 añade un programa de certificación y un marco más amplio de dispositivos. Para un proyecto, la pregunta útil es qué funciones están implementadas en el equipo exacto y qué dispositivos necesita la arquitectura.
D4i: datos normalizados dentro de DALI-2
La DALI Alliance describe D4i como una extensión de DALI-2. Sus drivers certificados incorporan requisitos relacionados con alimentación y capacidades de datos; las Partes 251, 252 y 253 se orientan, respectivamente, a datos de luminaria, energía y diagnóstico.
Eso habilita casos como inventario, monitorización y mantenimiento basado en información. No demuestra que el edificio vaya a ahorrar, que el diagnóstico sea suficiente para predecir una avería o que una plataforma concreta interprete todos los datos. Hay que verificar driver, dispositivos, controlador, gateway, software y funciones efectivamente disponibles.
IoT: una arquitectura, no una prestación única
IoT puede incluir sensores, conectividad IP o inalámbrica, servicios remotos, APIs y analítica. La palabra describe un enfoque de sistemas conectados, no un resultado de iluminación. Una red IoT sin propietario del dato, política de actualizaciones o plan de continuidad es una dependencia, no una estrategia.
Como referencia de arquitectura, la documentación oficial de DISMART 2.0 presenta una solución concreta con sensores, comunicación inalámbrica, gateway, DALI/DALI-2 y gestión conectada. Es un ejemplo de cómo un fabricante organiza su sistema, no una prueba de que esas funciones estén disponibles en cualquier producto, sean interoperables con cualquier BMS o produzcan un retorno determinado.
BMS: integración con el edificio
Un BMS puede coordinar iluminación con climatización, persianas, ocupación, alarmas u horarios. Esa integración puede tener sentido cuando existe una operación conjunta y un responsable del sistema. También puede complicar el diagnóstico: un problema de luz puede originarse en el driver, el bus, el gateway, la red, la lógica del BMS o un permiso.
BACnet International explica que la certificación o el listado BTL aporta evidencia sobre una implementación BACnet concreta. No prueba que todas las funciones del sistema subyacente sean interoperables. Verificá modelo, firmware, perfil, servicios, PICS, gateway y prueba de aceptación.
5. Cuándo la complejidad está justificada
La conectividad suele estar mejor justificada cuando coinciden varias condiciones:
-
el edificio o espacio cambia de configuración con frecuencia;
-
hay muchas zonas y la operación manual es repetitiva;
-
el acceso de mantenimiento es difícil o costoso;
-
se necesita registrar energía, activos o incidencias;
-
existe un equipo responsable de operar y mantener el sistema;
-
las funciones necesarias están documentadas y se pueden probar;
-
hay un modo seguro y útil de seguir funcionando si falla la red;
-
el coste de instalación y operación se compara con un escenario sencillo.
Escenario hipotético — flexibilidad
Un espacio de trabajo reorganiza salas con frecuencia. Una solución con escenas y sensores podría reducir visitas para reconfigurar grupos. Pero el beneficio depende de que el personal pueda modificar esas escenas, de que las direcciones estén documentadas y de que el sistema siga siendo operable cuando cambie el proveedor.
La conectividad está justificada si se mide el tiempo de reconfiguración y se asigna a alguien la responsabilidad. No está justificada solo porque el catálogo diga “flexible”.
Escenario hipotético — mantenimiento
Una instalación en altura tiene un coste importante de acceso. Los datos de estado podrían ayudar a priorizar inspecciones. Antes de afirmarlo, hay que comprobar qué fallos detecta el sistema, con qué latencia, quién recibe la alerta y si existen repuestos.
El dato puede reducir incertidumbre. No elimina el fallo, el acceso ni el trabajo de sustitución.
6. Cuándo estamos complicando sin necesidad
Hay señales de sobreingeniería:
- se elige el protocolo antes de definir una función;
- se incorporan datos que nadie va a consultar;
- se promete ahorro sin medición ni línea de base;
- el gateway es imprescindible, pero nadie es su propietario;
- la licencia, la nube o el firmware no tienen condiciones claras;
- el sistema requiere una puesta en marcha que no aparece en el presupuesto;
- no existe fallback local o manual;
- se necesita un experto externo para una operación cotidiana;
- la integración con BMS duplica funciones que ya resolvía el control local.
En esos casos, una solución más sencilla puede ser más robusta. “Sencilla” no significa sin criterio: puede incluir regulación, sensores, horarios y una documentación correcta, sin añadir una plataforma que el proyecto no necesita.
7. Interoperabilidad: pedí pruebas, no etiquetas
La interoperabilidad se demuestra en una combinación concreta de equipos y funciones. Para revisarla, pedí:
| Pregunta | Evidencia |
|---|---|
| ¿Qué equipo comunica? | modelo, revisión de hardware y firmware |
| ¿Qué funciones ejecuta? | matriz de funciones y límites documentados |
| ¿Con qué se integra? | controlador, gateway, perfiles y servicios |
| ¿Quién lo ha probado? | certificación, listado o ensayo aplicable |
| ¿Cómo se pone en marcha? | herramienta, procedimiento y criterios de aceptación |
| ¿Qué pasa si falla? | comportamiento local, manual y recuperación |
| ¿Quién lo mantiene? | propietario, soporte, actualizaciones y repuestos |
No generalices desde una prueba de laboratorio o desde un único fabricante. Una certificación puede demostrar algo concreto sobre un producto; no sustituye la prueba del conjunto ni garantiza una experiencia operativa completa.
8. Ciberseguridad y continuidad desde el pliego
Cuando la iluminación se conecta a la red corporativa, a un BMS o a servicios remotos, deja de ser solo una instalación de campo. CISA trata los sistemas de gestión de edificios como parte del entorno de tecnología operacional y recomienda prácticas como eliminar exposición innecesaria a Internet, sustituir credenciales por defecto, segmentar redes, proteger el acceso remoto y gestionar parches de forma consciente con el entorno OT.
NIST propone capacidades de seguridad para dispositivos IoT que incluyen identificación, configuración autorizada, protección de datos, control de interfaces, actualización segura y conocimiento del estado de ciberseguridad.
Para un proyecto de iluminación, eso se traduce en preguntas concretas:
- ¿Qué activos existen y dónde están conectados?
- ¿Quién puede cambiar escenas, firmware o permisos?
- ¿Hay credenciales individuales y registro de accesos?
- ¿La red de iluminación está segmentada?
- ¿Cómo se actualiza un gateway sin perder la configuración?
- ¿Qué soporte recibe el producto cuando termina la licencia?
- ¿La iluminación sigue funcionando si cae la red, el servidor o la nube?
- ¿Quién responde ante un incidente?
La ciberseguridad no es una certificación que se marca una vez. Es una responsabilidad compartida durante el ciclo de vida.
9. Cómo medir el retorno sin vender humo
El retorno puede incluir energía, mantenimiento, flexibilidad, continuidad o información. No sumes beneficios sin demostrar que pertenecen al proyecto.
Definí, para cada caso:
- escenario base sin conectividad adicional;
- inversión completa: equipos, gateways, licencias, diseño, instalación y commissioning;
- coste recurrente: soporte, conectividad, actualizaciones y operación;
- métrica de resultado y método de medición;
- periodo de análisis y supuestos;
- riesgos, exclusiones y sensibilidad;
- responsable de mantener el resultado.
El DOE señala que la facilidad de configuración, la puesta en marcha, el uso y el mantenimiento pueden limitar el rendimiento de los controles. Sus guías de evaluación no reducen el análisis al ahorro energético: también consideran instalación, configuración, desempeño de iluminación y resultados para ocupantes.
Un retorno puede ser positivo en un edificio con uso variable y mantenimiento costoso, y no justificar una plataforma en un espacio pequeño con uso estable. No hay una cifra universal que resuelva ambos casos.
Checklist: requisito primero, tecnología después
Antes de especificar una instalación conectada, comprobá:
- El problema está escrito y tiene una métrica.
- Existe una línea de base o se explica cómo se obtendrá.
- Se comparó una alternativa sencilla.
- Las funciones requeridas están asignadas a dispositivos concretos.
- La interoperabilidad se verificará con modelos y versiones identificados.
- El commissioning, la formación y la documentación están presupuestados.
- Hay propietario del sistema, de los datos y de las credenciales.
- Se conocen licencias, soporte, actualizaciones y fin de vida.
- Existe un modo de operación local o fallback.
- La red, el acceso remoto y la respuesta a incidentes están definidos.
- El retorno se calcula con hipótesis visibles y no con una promesa genérica.
Conectar solo lo que puedas operar y medir
La iluminación conectada aporta valor cuando convierte una necesidad real en una capacidad operable y medible. Puede ayudar a adaptar espacios, reducir trabajo repetitivo, localizar incidencias o integrar la iluminación en una estrategia de edificio.
También puede añadir coste, dependencia y riesgo. DALI, D4i, IoT y BMS son herramientas y capas distintas; ninguna reemplaza el diseño, la puesta en marcha, la seguridad ni el mantenimiento.
La decisión profesional es menos brillante que una demo, pero más útil: definir el problema, establecer la métrica, comparar la complejidad, probar la arquitectura y dejar por escrito quién se hace cargo. Si la conectividad no mejora una decisión concreta, probablemente no es valor. Es solo otra cosa que mantener.
Fuentes consultadas
- DALI Alliance, D4i, extensión de DALI-2 con requisitos de alimentación y datos normalizados para luminarias inteligentes: dali-alliance.org/d4i, consultado el 30 de agosto de 2026.
- DALI Alliance, Luminaire, Energy & Diagnostics Data, Partes 251, 252 y 253 y sus capacidades de datos: dali-alliance.org/dali/data.html, consultado el 30 de agosto de 2026.
- BACnet International, BTL Certification, alcance de la certificación y verificación de implementaciones BACnet concretas: bacnetinternational.org/btl-certification, consultado el 30 de agosto de 2026.
- U.S. Department of Energy, Lighting Controls Solutions, evaluación de instalación, configuración, puesta en marcha, rendimiento y resultados de controles: energy.gov/cmei/ssl/lighting-controls-solutions, consultado el 30 de agosto de 2026.
- CISA, ICS Recommended Practices, prácticas de seguridad para entornos de tecnología operacional, incluidas segmentación, acceso remoto y credenciales: cisa.gov/resources-tools/resources/ics-recommended-practices, consultado el 30 de agosto de 2026.
- NIST, IoT Device Cybersecurity Capability Core Baseline, capacidades de seguridad para identificación, configuración, protección de datos, interfaces y actualizaciones: nist.gov/publications/iot-device-cybersecurity-capability-core-baseline, consultado el 30 de agosto de 2026.
- Disano, DISMART 2.0 — Sistema, referencia de una arquitectura concreta de iluminación conectada; no evidencia universal de interoperabilidad o retorno: dismart.disano.it/sistema, consultado el 30 de agosto de 2026.
Lecturas relacionadas
También te puede interesar
Para explorar