Loxone Config
Programación en Loxone Config — Estructura, lógica y entrega
Cómo se estructura Loxone Config, cómo mantener la lógica legible y comprobable, y qué entregar para que otro ingeniero pueda mantener el proyecto.
Respuesta rápida
Config es el entorno de ingeniería donde se construye el proyecto del Miniserver: salas, funciones, entradas, salidas, lógica, horarios e interfaces de usuario. Una buena programación está estructurada, nombrada y documentada, de modo que otro ingeniero pueda leerla. No se trata de escribir bloques ingeniosos, sino de hacer que el comportamiento del edificio sea visible, comprobable y seguro de modificar.
El proyecto es un modelo del edificio
Config organiza el trabajo por sala y función, no por una lista plana de bornes. Una sala contiene sus luces, protección solar, clima y sensores; una función describe lo que hace la sala. Esa estructura es la diferencia entre un proyecto que se puede mantener y un montón de bloques que funciona por casualidad. Nombre los puntos desde la perspectiva del edificio, use prefijos coherentes y mantenga la jerarquía de salas y funciones alineada con la lista de puntos. Cuando la nomenclatura se desvía, cada tarea posterior se vuelve más lenta: alarmas, tendencias, gráficos, entrega y localización de fallos dependen de los mismos nombres. Una comprobación útil consiste en entregar el árbol del proyecto a alguien que nunca haya visto el sitio y pedirle que encuentre la sala de reuniones del tercer piso sin usar la búsqueda.
- Refleje el listado de salas en el árbol del proyecto
- Use una única convención de nombres desde el primer día
- Mantenga gráficos y alarmas con los mismos nombres
Lógica por capas
Coloque el comportamiento simple cerca del dispositivo: una luz sigue a su interruptor, una válvula sigue el valor de consigna de su sala. Sitúe el comportamiento entre salas y entre sistemas en una capa de edificio claramente identificada. Coloque la generación de informes y la optimización por encima. Esta estratificación evita que un pequeño cambio en una sala repercuta en todo el proyecto y permite probar por partes. Use máquinas de estados para secuencias con estados diferenciados, en lugar de un nido de condiciones que solo entiende su autor. Documente cada bloque no evidente con una nota breve: qué hace, qué lo activa y qué ocurre si falla un sensor. Si un bloque necesita un párrafo para explicarse, ese párrafo debe estar en las notas del proyecto junto al bloque, no en un documento aparte que nadie abre.
- La lógica de dispositivo, sala y edificio se mantiene separada
- Use máquinas de estados para secuencias de varios pasos
- Comente cada bloque no evidente
Evidencia de prueba, no confianza
Un proyecto no está terminado cuando la aplicación se ve bien. Pruebe las entradas una a una, fuerce fallos de sensores, compruebe el encaminamiento de alarmas, verifique los horarios en los distintos tipos de día y confirme que las anulaciones caducan. Registre el resultado contra la lista de puntos, no en la memoria de alguien. Pruebe la ruta de fallo: qué ocurre cuando desaparece un dispositivo de bus, un contador deja de responder o se cae la red. Una hoja de pruebas breve y escrita vale más que una demostración larga, porque sobrevive a los cambios de personal y abarata la siguiente visita de servicio. Incluya también la ruta humana: ¿sabe el operador qué hacer cuando aparece una alarma a las 02:00, y esa instrucción está en el paquete de entrega y no solo en la cabeza del instalador?
- Pruebe cada entrada y salida contra la lista de puntos
- Fuerce fallos y registre el estado resultante
- Verifique horarios, anulaciones y encaminamiento de alarmas
Entrega y control de cambios
Entregue el archivo del proyecto, la versión del software, la copia de seguridad, el diagrama de red, la lista de puntos y un registro de cambios. Proteja el proyecto con credenciales que controle el propietario, no con credenciales que se van con el instalador. Acuerde cómo se solicitarán, probarán y registrarán los cambios. Un pequeño cambio en un horario no debería exigir una visita al sitio si el acceso remoto y los permisos están bien diseñados. La medida de una buena configuración no es cuánta lógica se escribió, sino con qué seguridad el equipo del propietario puede operar y modificar el edificio después de que los ingenieros se marchen. Un proyecto que otra persona no puede restaurar, explicar y modificar en realidad no se ha entregado; solo se ha encendido.
- Credenciales y licencias controladas por el propietario
- Un proceso escrito de solicitud y prueba de cambios
- Una prueba de restauración antes de la entrega final
Capas de programación
5 rows| Capa | Qué contiene | Evidencia de prueba |
|---|---|---|
| Dispositivo | Entradas, salidas y comportamiento local ante fallo | Prueba de entradas y salidas punto por punto |
| Sala | Iluminación, protección solar, clima y escenas de sala | Prueba de escenas de sala y valores de consigna |
| Edificio | Horarios, interbloqueos, alarmas y lógica de energía | Prueba de secuencias, alarmas y conmutación por fallo |
| Interfaz de usuario | Páginas de la aplicación, controles táctiles y vistas por rol | Comprobación de acceso por rol y usabilidad |
| Entrega | Copias de seguridad, versiones, notas y registro de cambios | Prueba de restauración y revisión as-built |
Imágenes del proyecto
3 images
Preguntas frecuentes
01¿Config es programación o configuración?
Ambas cosas. Es un entorno gráfico, pero el trabajo es de ingeniería: estructura, lógica, nomenclatura y pruebas. La distinción importa menos que el hecho de que el resultado sea legible y mantenible.
02¿Es necesario escribir código?
La mayoría de los proyectos se construyen con bloques de función nativos. Hay lógica personalizada disponible para secuencias especiales, pero debe documentarse y justificarse, porque eleva la cualificación necesaria para mantener el sitio.
03¿Puede otro integrador mantener el proyecto?
Sí, si el archivo del proyecto, la convención de nombres, las notas y las credenciales se entregan correctamente. Debería ser un requisito contractual, no un favor después de la finalización.
04¿Con qué frecuencia deben hacerse copias de seguridad?
Antes y después de cada cambio, y en la entrega. Guarde una copia fuera del controlador y compruebe que se restaura. Una copia de seguridad no probada es solo una esperanza.
05¿Se puede personalizar la aplicación por usuario?
Sí. Las páginas de usuario y los permisos pueden estructurarse por rol, de modo que operadores, técnicos y residentes vean distintos niveles de detalle y distintos controles.
Siguiente paso
Tráiganos el edificio.
Cuéntenos el tipo de edificio, los sistemas incluidos y el resultado que necesita. Le mostraremos la ruta más corta hacia un sistema en funcionamiento.