Welcome back to the Home Assistant & KNX series.

In the last part we connected Home Assistant to the KNX bus and added our first simple device: a basic on/off light. That’s already enough to prove that everything works, but in a real installation you’ll quickly run into more complex device types. In this part I want to cover:

• How to configure common KNX device types in Home Assistant
• How to keep your configuration scalable and maintainable once the number of group addresses explodes
• How I use CSV exports + ChatGPT to avoid writing hundreds of lines of YAML by hand

As before: this is not meant to replace the official documentation. Quite the opposite: I’ll link to it frequently and only show selected examples.

Configuring Different Device Types

The KNX integration in Home Assistant supports a wide range of device domains. You can find the full, up-to-date list in the official docs: 👉 https://www.home-assistant.io/integrations/knx/

Here, I only want to cover some of the most common device types that we used in our installation.

Lights

In the previous part we already added a simple on/off light with state feedback. But if you’re thinking about a KNX installation, you probably won’t be satisfied with simple on/off, right? Dimmable lights are a must have these days and tunable white or even RGB are nice add-ons. To control KNX dimmers via Home Assistant you’ll need:

• A switching address (on/off)
• A brightness address (absolute dimming)
• Optional state feedbacks for both

- name: "Office Light"
  address: "1/1/12"
  state_address: "1/1/22"
  brightness_address: "1/1/32"
  brightness_state_address: "1/1/42"

That’s all Home Assistant needs to expose the light with a brightness slider.

For all available options and details (like color temperature or full RGB support), check the official documentation: 👉 https://www.home-assistant.io/integrations/knx/#light

I’d recommend to check in the documentation which group address types (data point types) Home Assistant expects for each function. For example, KNX dimmer switches often use relative dimming instead of sending absolute brightness values (holding the button increases/decreases brightness in steps). To support both Home Assistant and the physical switch, you might need to configure (or tell your installer to configure) an additional group address for absolute brightness control.

While the *state_address group addresses are optional, they are highly recommended to keep Home Assistant in sync with the actual state of the light. Without state feedback, Home Assistant won’t know if the light was turned on or off via the KNX bus (e.g. by a physical switch or a scene).

Thermostats (Climate)

Another common device type in KNX installations are thermostats for heating and/or cooling control. This is also an area where you should review the documentation carefully to understand which group addresses are needed to control your thermostat properly via Home Assistant. For basic setup you only need a temperature_address (the current temperature) and target_temperature_state_address (the desired temperature setpoint, readonly). However, to actually set the target temperature from Home Assistant, you also need a target_temperature_address.

In addition, you probably want to support different operation modes (auto, economy, standby, comfort, building protection) that allow to quickly switch between predefined temperature setpoints. For this, you need to configure operation_mode_address and operation_mode_state_address.

KNX thermostats often use setpoint shift instead of absolute target temperatures to allow small manual adjustments to the configured base temperature with physical buttons in an easy way. If you use this, you might want to also configure setpoint_shift_address and setpoint_shift_state_address to allow Home Assistant to adjust the setpoint shift as well. Setpoint shifts support 1 byte signed integers with scale factor or 2 byte floats, so make sure to check which one your thermostat uses and configure setpoint_shift_mode accordingly.

With all these options I ended up with a configuration like this for my KNX thermostat:

- name: "Thermostat Kitchen"
  temperature_address: "1/2/18"
  setpoint_shift_address: "1/2/28"
  setpoint_shift_state_address: "1/2/38"
  setpoint_shift_mode: "DPT9002"
  setpoint_shift_min: -5
  setpoint_shift_max: 5
  target_temperature_address: "1/2/48"
  target_temperature_state_address: "1/2/58"
  operation_mode_address: "1/2/68"
  operation_mode_state_address: "1/2/78"

As with lights, please check the official documentation for all available options and details: 👉 https://www.home-assistant.io/integrations/knx/#climate

Shutters / Blinds

Shutters, blinds, and roller shutters are handled via the cover domain. The most common configuration includes up/down control, stop, and position feedback but absolute positioning or tilt control for blinds is also supported if your devices support it.

In contrast to KNX defaults, 0% means closed in Home Assistant and 100% means fully open, the KNX integration converts the values automatically, but be careful if you use position group addresses in automations or scripts directly.

My default configuration looks like this:

- name: "Shutter Bathroom"
  move_long_address: "1/3/12" # "Single Object Control", also used to stop!
  stop_address: "1/3/12"
  position_address: "1/3/22"
  position_state_address: "1/3/32"
  travelling_time_down: 15
  travelling_time_up: 17
  device_class: "shutter"

In this case there is one special thing to note: the address for moving up/down is the same as the stop address. This is because we use a MDT shutter actuator that allows to configure one group address for both functions (short press = move, long press = stop) which I find convenient for use with physical buttons. The device class is only for frontend representation and can be omitted if you don’t care about that.

Home Assistant also supports blinds with tilt control. See the documentation for all available options: 👉 https://www.home-assistant.io/integrations/knx/#cover

Scaling Beyond a Handful of Devices

Everything so far is manageable when you have five lights and two shutters. That quicky changes when you’re dealing with a full house worth of devices with dozens of lights, thermostats and shutters for each room and hundreds of group addresses in total. This is where writing and maintaining the YAML configuration by hand becomes tedious at best and error-prone at worst. A thought-out structure and some tooling goes a long way to keep things manageable.

Structuring Group Addresses

Quick recap: KNX group addresses are used to identify communication objects on the KNX bus, they consist of three levels (main/middle/sub) and are usually represented in the format x/y/z (e.g. 1/2/30).

There a many valid ways to structure KNX group addresses and it often depends on the preferences of the installer or the specific use case. If you’re programming the KNX devices yourself, you have full control and can choose whatever structure you like. What matters most is consistency.

After some research and figuring out that there is no one-size-fits-all solution, I settled on the following structure for our installation. The main group is solely used to separate the different floors to make it easier to locate devices physically. The middle group is used to group devices by domain (lights, shutters, climate, sensors, etc.). This combination allows to quickly find relevant group addresses, for example when I want to change something about the lights in my office which is in the first floor, I know that all relevant group addresses are in the 1/1/* range. Finally, the sub group is used for function and location.

The sub group is where I fumbled a bit at first. Initially, I started to sequentially assign the group addresses in the order I added devices to the configuration. For adding a new light, I simply picked the next free sub groups in the X/1/* range: X/1/10 for on/off, X/1/11 for state feedback, X/1/12 for brightness, etc. This quickly makes things messy and hard to maintain, especially when you mix devices with different functions (e.g. dimmable lights, RGB lights, tunable white, etc.) or need to add new devices later on.

To combat this mess, I switched to a more systematic approach that is also shown in the examples above. Instead of sequentially assigning sub groups, I now use specific ranges for different functions. For example, for lights:

• X/1/10-19 — on/off control
• X/1/20-29 — on/off state feedback
• X/1/30-39 — brightness control
• X/1/40-49 — brightness state feedback

and so on. Increasing the sub group by 10 for each function allows for predictable and consistent group addresses that are easy to remember and locate. When I add a new light with the on/off control at 1/1/15, I know that the state feedback will be at 1/1/25 and the brightness control at 1/1/35 (if available) without having to look it up. This approach also makes it easier to spot mistakes or inconsistencies in the configuration, as any deviation from the expected pattern stands out immediately.

There is one downside to this approach: you are limited to 10 devices per function per floor. Otherwise, you would need to increas the sub group ranges which looses the gread predictability of the base-10 pattern.

Automating Configuration Generation

Once you have all group addresses for your KNX installation, its time to create the yaml configuration for Home Assistant. You could of course write it by hand, but you really shouldn’t, especially if there are better ways to do it that are less error-prone and waay faster.

The KNX programming software ETS allows to export the group address structure as CSV which is a great starting point. If all group addresses are properly named and described in ETS, the structured nature of the CSV makes it easy to use an LLM to generate the YAML configuration for Home Assistant. Here’s a simplified version of the prompt I use:

I’m using Home Assistant with KNX.
Below is a CSV export of KNX group addresses.

Please generate Home Assistant KNX YAML configuration for the light domain.
Rules:

• Use address for switching
• Use state_address for feedback
• Use brightness_address and brightness_state_address when available
• Group devices logically
• Use clear, human-readable names

CSV:

1/1/1,Living Room Light SW  
1//11,Living Room Light FB
1/1/21,Living Room Light VAL
1/1/31,Living Room Light VAL FB

SW = switching, FB = feedback, VAL = brightness value, VAL FB = brightness feedback

This alone can save hours of repetitive work. You still need to review the output, but it gets you 80–90% of the way there.

Splitting Configuration Files

As seen with the prompt to generate the YAML configuration, I like to separate the configuration by domain. This makes it easier to find and edit specific parts later on. Home Assistant makes it really easy to split the configuration into multiple files using the !include directive. My main configuration.yaml looks something like this:

knx:
  light: !include knx/light.yaml
  cover: !include knx/cover.yaml
  climate: !include knx/climate.yaml

Resulting in this file structure:

config/
├── configuration.yaml
└── knx/
    ├── light.yaml
    ├── cover.yaml
    └── climate.yaml

This way, every domain is neatly separated into its own file in the knx/ folder, keeping files smaller and more readable.

Wrapping Up

At this point, Home Assistant should have a solid understanding of your KNX installation, from simple switches to more complex devices like dimmable lights, shutters, and heating zones. And you should’ve learned how to simplify configuration using consistent structures and a bit of AI.

In the next part, we’ll turn things around and look at the opposite direction: how to expose Home Assistant devices back to KNX, for example when integrating Zigbee lights into a KNX-centric setup.