Vista previa de cross-check HVAC
La vista muestra como cruzar fuente KNX y candidatos Control4 antes del export. En termostatos, setpoints, modos y feedback deben revisarse antes de contarlos dentro del scope de build.
Por que los termostatos van separados de luces y persianas
Una luz o persiana suele mapearse a una familia pequena y repetible de objetos de comando y feedback. Un termostato tiene mas estado. Puede exponer temperatura medida, setpoint objetivo, modo comfort o economy, demanda de calor/frio, estado de valvula, fan speed, logica de ventana y modos de proteccion.
Como el modelo de objetos cambia por fabricante y diseno del proyecto, el flujo de termostatos necesita una revision mas cuidadosa. Tratarlo como un dispositivo simple puede generar modos incorrectos, setpoints que vuelven atras o feedback poco fiable en la interfaz Control4.
Senales a revisar antes de crear en Control4
La revision debe agrupar todos los canales KNX relacionados con el termostato antes de crear ningun dispositivo Control4. El instalador necesita ver que direccion escribe el setpoint, que direccion reporta la temperatura real y si modo y estado van separados.
Los proyectos fan coil requieren mas cuidado porque fan speed, modo calor/frio y demanda pueden representarse con DPTs distintos u objetos especificos del fabricante.
- Temperatura ambiente medida y setpoint objetivo.
- Comando de setpoint y feedback de setpoint.
- Modo HVAC, estado calor/frio y modos de proteccion.
- Comando y feedback de fan speed cuando aplique.
Supuestos de DPT y modos
Los problemas de termostatos suelen venir de supuestos de modo, no de una unica direccion equivocada. Un proyecto KNX puede representar comfort, standby, economy, building protection, heating, cooling o auto de formas distintas.
Un flujo review-first debe marcar el mapeo de modos poco claro como decision del instalador, no convertirlo en silencio en un termostato Control4 que parece completo pero se comporta mal.
Pricing y alcance de dispositivos
Los termostatos cuentan como dispositivos cuando entran en el build Control4 preparado. Aun asi deben revisarse con scope HVAC propio porque el esfuerzo de mapeo depende del diseno HVAC, DPTs y feedback disponible en ETS.
Asi la logica de pricing queda clara: keypads, pulsadores y sensores no suben el tier por si solos, mientras luces, persianas, termostatos y gateways si cuentan cuando se construyen.
Handoff a Composer para HVAC
Antes de que Composer reciba un paquete HVAC, el instalador debe confirmar fuente del room controller, semantica de modos, feedback disponible y que puede crear el driver.
Si el mapeo del termostato no esta claro, debe quedar como item de revision en vez de mezclarse dentro del build create-only principal.
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
Los termostatos KNX entran en el conteo principal?
Si. Los termostatos cuentan cuando entran en el build Control4 preparado, y aun asi necesitan revision HVAC propia porque setpoints, modos y feedback cambian por proyecto.
Por que un termostato KNX es mas complejo que una luz?
Combina setpoint, temperatura medida, modo de operacion, demanda, fan speed y feedback. Esos objetos cambian bastante entre fabricantes y proyectos KNX.
La IA puede ayudar a mapear termostatos?
Si, pero debe preparar un candidato HVAC revisable, no crear dispositivos a ciegas. El instalador sigue confirmando DPTs, modos y feedback.
Acota los termostatos KNX antes del build
Usa el AI Assistant para revisar familias de objetos HVAC por separado, manteniendo los termostatos contados visibles dentro del scope del proyecto.