Connecting a Viessmann Vitodens 200-W to KNX over Modbus TCP
The Vitodens 200-W's ViCare Modbus TCP interface exposes flow temperature, DHW setpoint, operating mode and fault status as Modbus registers that a gateway maps onto KNX group objects. Below is the wiring, the register-to-DPT mapping method and the zone-control logic needed to run heating circuits and domestic hot water from KNX thermostats without touching the boiler's own control loop.
What the ViCare Modbus TCP interface actually gives you
The ViCare Modbus TCP interface is a read/write Ethernet interface exposed by the Vitotronic control unit fitted to the Vitodens 200-W. It publishes the same measured values and setpoints the Viessmann control panel shows locally — flow and return temperature, DHW tank temperature, current operating mode, outdoor temperature (if a sensor is fitted) and active fault codes — as Modbus TCP registers. It does not replace the boiler's internal safety and combustion control, which stays entirely inside the Vitotronic; Modbus only gives you supervisory read access and a narrow set of setpoint writes.
KNX has no native Modbus TCP client, so you still need a gateway between the boiler's Ethernet port and the KNX TP line (or a KNXnet/IP router if the gateway itself only speaks KNXnet/IP). The gateway polls the boiler's registers on a schedule you configure and re-publishes each value as a KNX group object with the datapoint type you assign; writes work the other way, from a KNX telegram to a Modbus register write.
Wiring and network topology
Run the boiler's Ethernet port to the same managed switch or VLAN as the Modbus/KNX gateway; do not put the boiler on the building's general office or guest network, and do not expose the Modbus TCP port to the internet. Give the boiler and the gateway static IP addresses or DHCP reservations — the gateway's polling configuration references an IP address, and losing the lease after a router reboot is a common cause of a heating zone going silent.
On the KNX side, wire the gateway to the TP line with standard J-Y(St)Y 2×2×0.8 bus cable through a line coupler if the boiler plant room sits on a different line from the KNX thermostats, and give the gateway its own 640 mA (or as specified by the manufacturer) KNX bus power budget entry so it doesn't starve the line during peak actuator switching.
Keep the Ethernet run and any KNX TP cable in separate containment, spaced as your cabling standard requires for a screened control cable next to a bus cable — bundling them tightly with the boiler's 230 V supply wiring is a more common source of comms errors than the Modbus link itself.
Reading boiler values over Modbus TCP
Every value the gateway needs is a holding or input register on the boiler; the exact register address depends on the Vitotronic firmware revision, so pull the current register map from Viessmann's technical documentation for your unit before you configure the gateway rather than reusing a table from an unrelated boiler generation.
| Function | Register type | Data type / KNX DPT | Note |
|---|---|---|---|
| Flow temperature (actual) | Input register, read-only | °C, float → DPT 9.001 | Updates on the polling cycle, not in real time |
| Return temperature (actual) | Input register, read-only | °C, float → DPT 9.001 | Useful for delta-T diagnostics, not for control loops |
| DHW tank temperature (actual) | Input register, read-only | °C, float → DPT 9.001 | Confirm the address in the DHW section of the register map |
| DHW setpoint | Holding register, read/write | °C, float → DPT 9.001 | A value outside the boiler's configured min/max is rejected, not clamped |
| Operating mode | Holding register, read/write | Enumeration → DPT 20.102 | Map only the modes your firmware actually lists; older revisions expose fewer states |
| Active fault code | Input register, read-only | Integer → DPT 5.010 or DPT 14.xxx per gateway | Treat 0 as "no fault"; no code does not mean the boiler is running |
Mapping registers to KNX group objects
Give each mapped register its own group address and keep read and write objects separate even where the underlying register is the same, so a KNX read telegram can't accidentally trigger a write to the boiler. Group the objects by function (heating circuit, DHW, diagnostics) rather than by register order, so the KNX project stays readable once a second heat source or buffer tank is added later.
| KNX function | DPT | Object size | Convention |
|---|---|---|---|
| Flow temperature (status) | DPT 9.001 | 2 byte | Read-only, updated cyclically on the gateway's polling interval |
| DHW setpoint (control) | DPT 9.001 | 2 byte | Write-only from the KNX side, gateway echoes the confirmed value back as status |
| DHW setpoint (status) | DPT 9.001 | 2 byte | Separate object from the control one above, always reflects the boiler's accepted value |
| Operating mode select | DPT 20.102 | 1 byte | Constrain the KNX visualisation to only the modes present in the current register map |
| Fault / alarm | DPT 1.005 | 1 bit | Derived by the gateway from the fault-code register, wired into the building's alarm concept |
# Illustrative gateway mapping — addresses are placeholders. # Confirm every register address against the current Vitotronic # Modbus register map before entering it into the gateway. source: modbus-tcp, boiler-ip, unit-id: <per gateway manual> read <register per register map> -> GA 3/1/1 DPT 9.001 # flow temperature read <register per register map> -> GA 3/1/10 DPT 9.001 # DHW temperature actual write <register per register map> <- GA 3/1/11 DPT 9.001 # DHW setpoint read <register per register map> -> GA 3/1/20 DPT 20.102 # operating mode read <register per register map> -> GA 3/1/30 DPT 1.005 # fault bit
Multi-zone heating and DHW control from KNX thermostats
Each heating circuit the Vitotronic manages independently can take its setpoint from a KNX room thermostat instead of the boiler's own fixed schedule: the thermostat sends its calculated flow or room setpoint as a DPT 9.001 telegram to the gateway, the gateway writes it into that circuit's setpoint register, and the boiler's own weather compensation and pump logic keep running underneath that setpoint. The boiler still owns its safety limits, so a KNX telegram outside the configured range is rejected, not followed.
DHW works the same way but with one addition worth planning for: if the DHW setpoint is lowered from KNX during unoccupied periods, keep the boiler's own periodic anti-legionella heat-up cycle enabled in the Vitotronic rather than trying to schedule it from KNX logic, since that cycle is tied to the boiler's internal safety function, not to the Modbus interface.
- Sends a DPT 9.001 setpoint to the gateway, not directly to the boiler
- Reads flow-temperature status back for feedback display
- Should not poll faster than the gateway's Modbus cycle
- Setpoint write object kept separate from the status object
- Legionella cycle stays configured in the Vitotronic, not in KNX logic
- Confirm the boiler's minimum DHW setpoint before allowing a KNX write below it
Gotchas: firmware drift and bus loading
The two failures installers hit most often on this integration have nothing to do with KNX wiring at all: a register map that no longer matches the boiler after a firmware update, and a gateway polling cycle set aggressively enough to compete with the Vitotronic's own control loop.
Firmware dependency: a Vitotronic firmware update can shift, add or remove registers. Re-validate the register map against the installed firmware version after any service visit that touches the control unit, before assuming a silent KNX object is a wiring fault.
Bus and controller loading: polling every register once a second gives no operational benefit and adds load to both the KNX line and the boiler's own control loop. A 10–30 second polling interval is enough for flow temperature and mode status; only fault/alarm objects justify faster polling, and even those don't need sub-second updates.
Frequently asked questions
Does the Modbus TCP interface replace the boiler's internal safety controls?
No. The Vitotronic keeps full internal control of combustion safety, flow-temperature limits and pump protection; Modbus TCP only gives supervisory read access and a limited set of setpoint writes that the boiler can still reject if they fall outside its configured limits.
Can I connect the boiler's Modbus TCP interface straight to a KNX line?
No. KNX TP and KNXnet/IP do not speak Modbus, so you need a Modbus TCP/KNX gateway between the two. The gateway polls the boiler and republishes each value as a KNX group object with the datapoint type you assign.
Where do I find the exact register addresses for my boiler?
In the Modbus register map published in Viessmann's technical documentation for your specific Vitotronic control unit and firmware revision. Addresses are not standardised across boiler generations, so a table from a different model or an older firmware revision is not reliable.
Can KNX override the DHW anti-legionella heat-up cycle?
It shouldn't. That cycle is part of the boiler's internal safety and hygiene function. Leave it configured in the Vitotronic and use KNX only to adjust the normal DHW setpoint for occupancy changes, not to disable or reschedule the anti-bacteria cycle.
How often should the gateway poll the boiler?
Every 10–30 seconds is enough for temperature and mode-status objects; polling faster adds load to the KNX line and the Vitotronic's control loop without a usable operational benefit. Reserve faster polling for fault/alarm objects only.
Need this wired into a panel, not just a spec sheet?
PanelCraft pre-wires the Modbus/KNX gateway, line coupler and 24 V supply for a Vitodens plant-room integration into a CE-marked distribution panel, so the boiler side and the KNX side land on labelled terminals instead of a nest of accessory boxes.
Request a quote →