Vista previa de estacion meteorologica KNX y shading
La vista de cross-check mantiene objetos KNX y estructura Control4 generada visibles juntos para revisar viento, lluvia, luminosidad, persianas y feedback antes del export.
Una estacion meteorologica no es un dispositivo visible normal
Las estaciones meteorologicas KNX suelen publicar varios valores y alarmas binarias: velocidad de viento, lluvia, luminosidad, direccion solar, temperatura, helada, crepusculo o senales enable de sombreado. Pueden influir en persianas y toldos, pero no son lo mismo que una luz o shade simple en Control4.
La capa de revision debe conservar la evidencia ETS para que el instalador decida si cada senal sera contexto de programacion, logica de seguridad, dispositivo informativo o item excluido.
- Viento y lluvia deben tratarse como proteccion o seguridad, no como labels decorativos.
- Luminosidad y sol pueden influir en escenas de shading, pero necesitan umbrales y logica local revisada.
- Temperatura o helada puede cruzarse con HVAC o display meteorologico fuera del build core.
Que revisar en ETS antes de Composer
El proyecto ETS debe mostrar que direcciones vienen de la estacion meteorologica, que DPT usan, si son alarmas binarias o valores numericos, y que persianas o zonas de fachada dependen de ellas.
Aqui es donde un CSV plano o una nota manual suele fallar. La relacion entre una alarma de viento, un grupo de shading y un feedback de posicion puede ser dificil de reconstruir despues de crear dispositivos en Composer.
- Alarma de viento, velocidad de viento y objeto de reset u override si existe.
- Alarma de lluvia y si bloquea toldos, ventanas o sombreado de fachada.
- Luminosidad/lux, elevacion solar o senales por fachada.
- Temperatura, helada o crepusculo usados por escenas o horarios.
- Grupos de persianas que deben protegerse o excluirse de movimientos automaticos.
Scope Composer y limite del conteo
El build contabilizado de CoduWorks se mantiene centrado en luces, persianas, termostatos y gateways IP KNX. Valores de estacion meteorologica, sensores y objetos de proteccion no suben por si solos el tier.
Ese limite mantiene el build automatico predecible. Las senales meteorologicas pueden exportarse como items claros de revision o add-on para que el instalador programe Control4 con intencion.
No saltes la logica de seguridad KNX
Si la instalacion KNX ya protege toldos o persianas frente a viento, lluvia o helada, esa logica no deberia sustituirse a la ligera en Composer. Primero hay que entender que objetos KNX representan proteccion, override y feedback.
Un .codu revisado debe hacer visibles esas senales, mientras las decisiones finales de seguridad y programacion siguen siendo del instalador y de la documentacion oficial del proyecto.
Fuentes oficiales revisadas
Los claims tecnicos de esta pagina se mantienen cerca de documentacion oficial KNX, Control4 o del fabricante.
Herramientas y documentacion relacionadas
Preguntas frecuentes
CoduWorks crea automaticamente estaciones meteorologicas KNX en Control4?
No dentro del build core. Los valores meteorologicos son contexto de revision o scope manual/add-on salvo que el instalador confirme la representacion Control4 esperada.
Las senales meteorologicas pueden controlar persianas KNX en Control4?
Pueden formar parte de la logica de shading si se revisan DPTs, umbrales, proteccion, visibilidad de gateway y programacion Composer. La seguridad KNX existente no debe saltarse a ciegas.
Viento, lluvia y sol cuentan para el tier de licencia?
No. El scope de dispositivos contabilizados sigue siendo luces, persianas, termostatos y gateways IP KNX. Las senales meteorologicas se revisan aparte como contexto o add-on.
Que revisar antes del export?
Dispositivo fuente de la estacion, DPTs, alarmas de viento/lluvia, valores de luminosidad, grupos de persianas protegidos, feedback y si ya existe logica KNX.
Revisa clima y shading antes de Composer
Importa ETS, inspecciona senales meteorologicas junto a persianas y feedback, y exporta .codu solo cuando el scope este claro.