HVAC cross-check preview
The preview shows how KNX source context and Control4 device candidates can be cross-checked before export. For thermostats, setpoints, modes and feedback should be reviewed before they are counted into the build scope.
Why thermostats are separate from lights and blinds
A light or blind usually maps to a small, repeatable family of command and feedback objects. A thermostat is more stateful. It may expose measured temperature, target setpoint, comfort or economy mode, heating/cooling demand, valve state, fan speed, window contact logic and protection modes.
Because the object model changes by manufacturer and project design, a thermostat workflow needs a more careful review step. Treating it like a simple device count can create wrong modes, jumping setpoints or unreliable feedback in the Control4 interface.
Signals to review before Control4 creation
The review should group all thermostat-related KNX channels together before any Control4 device is created. The installer needs to see which address writes the setpoint, which address reports the actual temperature, and whether operating mode and status are separate.
Fan coil projects need extra care because fan speed, heating/cooling mode and demand state may be represented by different DPTs or vendor-specific objects.
- Measured room temperature and target setpoint.
- Setpoint command and setpoint feedback.
- HVAC mode, heating/cooling state and protection modes.
- Fan speed command and fan speed feedback where applicable.
DPT and mode assumptions
Thermostat problems are often caused by mode assumptions rather than a single wrong address. KNX projects may represent comfort, standby, economy, building protection, heating, cooling or auto mode differently.
A review-first workflow should mark unclear mode mapping as a decision for the installer, not silently convert it into a Control4 thermostat that looks complete but behaves incorrectly.
Pricing and device scope
Thermostats count as devices when they are included in the prepared Control4 build. They should still be reviewed with a dedicated HVAC scope because the mapping effort depends on the HVAC design, DPTs and feedback available in the ETS project.
This keeps the pricing logic clear: keypads, push buttons and sensors do not move the tier by themselves, while lights, blinds, thermostats and gateways do when they are built.
Composer handoff for HVAC
Before Composer receives an HVAC package, the installer should confirm the room controller source, mode semantics, feedback availability and what the driver is allowed to create.
If the thermostat mapping is uncertain, it should remain a review item instead of being merged into the main create-only build.
Official references checked
Technical claims on this page are kept close to official KNX, Control4, or manufacturer documentation.
Related tools and documentation
FAQ
Are KNX thermostats included in the core device count?
Yes. Thermostats count when they are included in the prepared Control4 build, and they still need a dedicated HVAC review because setpoints, modes and feedback vary by project.
Why are KNX thermostats harder than lights?
They combine setpoint, measured temperature, operating mode, demand state, fan speed and feedback. Those objects vary a lot between KNX manufacturers and projects.
Can AI still help with thermostat mapping?
Yes, but it should prepare a reviewable HVAC candidate instead of creating devices blindly. The installer still needs to confirm DPTs, modes and feedback.
Scope KNX thermostats before the build
Use the AI Assistant to review HVAC object families separately while keeping counted thermostats visible in the project scope.