Vista previa de suelo radiante KNX
La vista de cross-check mantiene objetos KNX y candidatos Control4 visibles juntos para revisar zonas de calefaccion, setpoints, actuadores de valvula y feedback antes del export.
Suelo radiante no siempre es un termostato
Un sistema de suelo radiante puede exponer un room controller por zona, un actuador por colector, salidas de valvula separadas, demanda de bomba, enable de calefaccion y feedback de temperatura. Control4 no deberia recibir un termostato aparentemente limpio hasta que el instalador sabe que objetos van juntos.
Ese es el valor del preflight: la fuente KNX queda visible mientras se revisa la estructura candidata de Control4.
Senales a revisar desde ETS
El proyecto ETS debe mostrar como se controla y mide cada zona de calefaccion. Una lista plana de direcciones de grupo puede ocultar la relacion entre nombre de estancia, loop del colector, canal de valvula e interfaz de termostato.
CoduWorks debe agrupar candidatos para revision, no decidir en silencio que cada objeto de calefaccion es un climate device final de Control4.
- Temperatura ambiente medida, setpoint objetivo y feedback de setpoint.
- Sensor de temperatura de suelo, proteccion de solera o limite maximo si existe.
- Demanda de calor, valvula open/close o feedback de porcentaje de valvula.
- Enable de calefaccion, modos eco/proteccion, horarios y bloqueo por ventana abierta.
- Canal de colector, salida de actuador y alineacion con el nombre real de estancia.
Nombres de estancia y loops importan
El suelo radiante es sensible a errores de nombre porque el loop fisico puede no coincidir con el label visible en ETS. Un enlace incorrecto puede hacer que Control4 muestre la estancia correcta mientras controla la valvula equivocada.
Antes de exportar, el instalador debe confirmar la relacion entre estancia ETS, zona de calefaccion, salida de colector y cualquier termostato o sensor visible para el usuario.
Scope y pricing separados
El suelo radiante no pertenece al tier estandar de dispositivos por defecto. El conteo sigue centrado en luces, persianas, termostatos y gateways KNX/IP, mientras las zonas HVAC se acotan aparte porque el modelo de objetos cambia por proyecto.
Asi el build base sigue siendo predecible y el trabajo de calefaccion queda revisable en vez de esconderse dentro de un conteo generico.
Handoff a Composer despues de revisar
Composer solo deberia recibir scope de suelo radiante cuando el modelo de zonas, semantica de setpoints, feedback y mapeo de actuadores estan claros. Las zonas dudosas deben quedar como items de revision, no como dispositivos create-only automaticos.
El paquete .codu puede llevar la estructura revisada y notas para que el build del driver parta de decisiones explicitas en vez de supuestos sueltos de ETS.
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
El suelo radiante KNX entra en el conteo core?
No por defecto. El suelo radiante es scope add-on HVAC. El conteo principal sigue siendo luces, persianas, termostatos y gateways KNX/IP.
CoduWorks crea automaticamente suelo radiante en Control4?
No como build core a ciegas. Puede preparar candidatos HVAC revisables, pero el instalador debe confirmar zonas, DPTs, salidas de valvula, setpoints y feedback antes de crear.
Por que importan los actuadores de valvula?
Un actuador de valvula puede representar salidas fisicas del colector, no estancias visibles. Mapear esas salidas mal puede controlar la zona equivocada.
Que revisar antes del export?
Temperatura de estancia, comando y feedback de setpoint, estado de valvula, demanda, limites de sensor de suelo, bloqueo por ventana, canal de actuador y nombres zona-estancia.
Acota suelo radiante antes de Composer
Importa ETS, revisa zonas de calefaccion, room controllers y actuadores de valvula, y exporta .codu solo cuando el scope HVAC este claro.