KNX Group Address Design: Structure, Naming & Best Practices

By /
KNX Group Address design

A well-designed KNX project is not only about selecting the right devices and programming their parameters. The Group Address structure is the logical backbone that connects KNX communication objects and determines how easily a project can be programmed, tested, expanded and maintained.

In small projects, an inconsistent Group Address structure may appear manageable. In a large villa, hotel, office, hospital or commercial building with thousands of Group Addresses, poor organisation quickly becomes a major engineering and commissioning problem.

This guide explains how to design a professional KNX Group Address structure, how to establish naming conventions, how Group Addresses relate to DPTs and communication objects, and how to create a structure that remains useful throughout the entire project lifecycle.

1. What Is a KNX Group Address?

A KNX Group Address identifies the destination of a group communication telegram. It is used to connect one or more KNX Group Objects logically, regardless of where those devices are physically located on the KNX network.

For example, a push button may send a telegram to a Group Address such as 1/2/15, while several lighting actuators can listen to that same address. This creates the logical relationship between the control device and the controlled function.

ETS uses the Group Address panel to create these logical links between Group Objects. The lowest-level element is the actual Group Address; Group Objects are linked to that address.

Individual Address vs Group Address

These two addressing systems serve completely different purposes.

AddressPurposeExample
Individual AddressIdentifies a specific KNX device1.1.25
Group AddressIdentifies a logical function1/2/15

Think of it this way:

INDIVIDUAL ADDRESS
       │
       ▼
Identifies the DEVICE

GROUP ADDRESS
       │
       ▼
Identifies the FUNCTION

A single Group Address can therefore be associated with multiple Group Objects.

Example: Lighting ON/OFF

Push Button
   │
   │ Group Object: Switch
   ▼
1/2/15  "Living Room Light ON/OFF"
   │
   ├────────► Actuator Channel 1
   │
   ├────────► Actuator Channel 2
   │
   └────────► Visualization

The physical devices may be on different KNX lines, but the Group Address provides the logical communication relationship.

Why Group Address design matters

A good structure should allow an engineer to answer these questions quickly:

  • What function does this Group Address control?
  • Where is the function located?
  • Is it a command or feedback?
  • What DPT is being used?
  • Which devices are linked to it?
  • Is it a local or central function?
  • Can another engineer understand it without asking the original programmer?

That is why Group Address planning should begin before detailed ETS programming.

2. KNX Group Address Structure: 2-Level and 3-Level

ETS supports different Group Address presentation styles. The commonly used structures are 2-level and 3-level.

In the 3-level representation, a Group Address is displayed as:

Main Group / Middle Group / Subgroup
       1       /      2      /    15

For example:

1/2/15 – Living Room – Light 1 – Switch

The 2-level representation combines the structure differently:

Main Group / Subgroup
       1       /    527

Importantly, KNX Association explains that the 2-level and 3-level structures are primarily presentation styles in ETS. They help engineers organise and view Group Addresses; they do not change the basic communication function of the Group Address.

3-level structure

A common representation is:

LevelTypical purpose
Main GroupBroad functional category
Middle GroupFunction/subsystem
SubgroupIndividual logical function

Example:

0 Lighting
   │
   ├── 0 Ground Floor
   │      ├── 1 Living Room Light 1
   │      ├── 2 Living Room Light 2
   │      └── 3 Dining Light
   │
   └── 1 First Floor
          ├── 1 Bedroom Light
          └── 2 Corridor Light

However, this is only one possible strategy.

KNX Association’s own guidance points out that there is no single Group Address structure that is universally superior; the important principle is that the structure should be clear, consistent and suitable for the project.

Do not confuse structure with functionality

A common mistake is to assume:

Main Group = Building
Middle Group = Floor
Subgroup = Room

This can work, but it is not mandatory.

Another project may use:

0 Lighting
1 Blinds
2 HVAC
3 Scenes
4 Central Functions
5 Status

The important question is not “Which numbering system is correct?”

The important question is:

“Can an engineer understand and maintain the project quickly?”

Current ETS consideration

KNX Association has announced that the free-level Group Address structure is deprecated from ETS 6.3.0 onward for creating new projects. Existing free-level projects can still be edited.

For new projects, integrators should therefore base their standard templates primarily around the supported 2-level or 3-level structures.

3. How to Plan a Professional KNX Group Address Architecture

The best time to design Group Addresses is before programming devices.

Start by identifying the functional requirements of the project and then build a repeatable Group Address architecture. Do not simply create addresses while programming each device, because that often produces inconsistent numbering, duplicated functions and difficult documentation.

A good architecture should work for both a small residential project and a large commercial project.

Function-based structure

One approach is to organise Group Addresses primarily by function:

0  Lighting
1  Dimming
2  Blinds
3  HVAC
4  Scenes
5  Central Functions
6  Status
7  Energy
8  Alarms

For example:

0 Lighting
   ├── Ground Floor
   │      ├── Living Room
   │      ├── Dining
   │      └── Kitchen
   │
   └── First Floor
          ├── Bedroom 1
          ├── Bedroom 2
          └── Corridor

This approach is easy to understand when the project is strongly function-oriented.

Building-oriented structure

For larger commercial projects, another approach is to organise the structure around the building hierarchy:

Building A
   │
   ├── Floor 00
   │     ├── Room 001
   │     ├── Room 002
   │     └── Corridor
   │
   ├── Floor 01
   │     ├── Room 101
   │     └── Room 102
   │
   └── Floor 02

This can be useful where the building itself is the primary reference used by consultants and maintenance teams.

Function vs building structure

Neither approach should automatically be treated as the universal answer.

StructureAdvantagePotential limitation
Function-basedEasy to find system functionsPhysical location may be less obvious
Building-basedEasy for facility managementFunctions can become spread across many branches
HybridCan combine bothRequires stronger planning discipline

KNX Association’s published guidance similarly distinguishes function-based, building-based and device-based approaches and emphasises planning and documentation rather than prescribing one universal structure.

Recommended approach for large projects

For a professional integrator, a hybrid functional structure is often practical:

MAIN GROUP
   │
   ├── Lighting
   ├── Blinds
   ├── HVAC
   ├── Scenes
   ├── Central
   └── Status

MIDDLE GROUP
   │
   ├── Floor
   ├── Zone
   └── Room

SUBGROUP
   │
   ├── Switch
   ├── Status
   ├── Dimming
   └── Value

The exact numbering should be adapted to the project’s scale and documentation requirements.

Plan for expansion

Do not use every available address immediately.

Reserve logical space for:

  • Future rooms
  • Additional lighting circuits
  • HVAC expansion
  • New scenes
  • Central functions
  • Energy monitoring
  • Additional status objects
  • Future integrations

A Group Address structure that works today but cannot be expanded logically becomes difficult to maintain later.

4. KNX Group Address Naming Convention

The numerical address alone is not enough.

An address such as:

3/4/27

does not tell another engineer what the function actually does.

A descriptive name should make the purpose immediately clear.

Poor naming

3/4/27 = Light 27

Better naming

3/4/27 = GF Living Room Light 01 - Switch

Professional naming example

GF_Living_L01_CMD
GF_Living_L01_FB
GF_Living_L01_DIM
GF_Living_L01_VAL
GF_Living_L01_VAL_FB

The exact syntax is a project decision. The important thing is consistency.

Command and feedback should be clearly separated

For a lighting circuit, consider:

FunctionExample
Switch commandGF_Living_L01_CMD
Switch feedbackGF_Living_L01_FB
Dimming commandGF_Living_L01_DIM
Brightness valueGF_Living_L01_VAL
Brightness feedbackGF_Living_L01_VAL_FB

This makes the relationship between commands and feedback immediately visible.

Avoid ambiguous names

Avoid names such as:

  • Light 1
  • Channel 4
  • Object 12
  • Output 7
  • Main Light
  • Status

Instead include enough information to identify the function.

Use consistent abbreviations

For example:

AbbreviationMeaning
CMDCommand
FBFeedback
DIMRelative dimming
VALAbsolute value
SCNScene
AUTOAutomatic
MANManual
ALMAlarm
ENEnable
STStatus

The actual abbreviations should be documented in the project’s engineering standard.

Use descriptions for additional information

ETS also provides a Description field for Group Address elements. KNX Association documents this as a user-friendly longer description that can also be included in exports/imports.

For example:

Name:
GF_Living_L01_CMD

Description:
Living room ceiling lighting circuit 01.
Command from wall keypad and automation logic.
DPT 1.001 switching.

This becomes particularly useful during project handover.

5. Group Addresses, Communication Objects and DPTs

A Group Address does not operate independently. It connects Group Objects that exchange values over the KNX bus.

The communication object determines what information a device sends or receives, while the DPT defines how that value should be interpreted.

For example:

Push Button
Group Object: Switch
DPT: 1.001
       │
       ▼
Group Address: 1/2/15
       │
       ▼
Lighting Actuator
Group Object: Switch
DPT: 1.001

The Group Address provides the communication path; the DPT defines the meaning and format of the transmitted value.

Common examples

FunctionTypical DPTExample
ON/OFFDPT 1.xxxLighting switch
Dimming valueDPT 5.0010–100%
TemperatureDPT 9.001°C
Scene numberDPT 17.001Scene
2-byte floating valueDPT 9.xxxTemperature, humidity etc.
4-byte valueDPT 14.xxxPhysical value

The exact DPT should always be selected according to the required function and compatible device objects.

One function may require multiple Group Addresses

Consider a dimmable light:

             LIGHTING
                │
       ┌────────┼────────┐
       │        │        │
      ON/OFF   DIM      VALUE
       │        │        │
       ▼        ▼        ▼
      CMD      CMD      CMD
       │        │        │
       └────────┼────────┘
                │
          LIGHT ACTUATOR
                │
          ┌─────┴─────┐
          ▼           ▼
       ON/OFF FB    VALUE FB

Trying to force every function into one Group Address is therefore a common design error.

Check compatibility

Before linking Group Objects:

  • Check object length.
  • Check DPT.
  • Check whether the object is sending or receiving.
  • Check communication flags.
  • Check whether feedback is required.
  • Check whether the device supports the intended function.

ETS exposes Group Object properties such as Data Type and communication flags including C, R, W, T, U and I, which determine how the object communicates on the KNX bus.

6. Practical KNX Group Address Design Examples

A practical structure is easier to understand when applied to a real project.

Example 1: Residential villa

Consider:

  • Ground Floor
  • First Floor
  • 8 rooms
  • Lighting
  • Dimming
  • Blinds
  • HVAC
  • Scenes

A simplified structure could be:

0 Lighting
   ├── GF
   │   ├── Living
   │   ├── Dining
   │   └── Kitchen
   │
   └── FF
       ├── Master
       ├── Bedroom 2
       └── Corridor

1 Blinds
   ├── GF
   └── FF

2 HVAC
   ├── GF
   └── FF

3 Scenes
   ├── House
   └── Room

4 Central
   ├── All Lights
   ├── All Blinds
   └── Away

5 Status
   ├── Lighting
   ├── Blinds
   └── HVAC

Example 2: Lighting function set

For one lighting circuit:

Living Room Light 01

CMD
 └── ON/OFF

FB
 └── ON/OFF STATUS

DIM
 └── Relative Dimming

VAL
 └── Absolute Brightness

VAL_FB
 └── Brightness Feedback

This creates a repeatable Group Address Set.

KNX Association’s guidance specifically highlights the usefulness of defining reusable Group Address sets—for example Switch, Switch Feedback, Dimming, Value and Value Feedback—independently of the overall project structure.

Example 3: Blind control

A motorised blind may require:

Blind 01
│
├── Up/Down
├── Stop/Step
├── Position
├── Position Feedback
├── Slat Position
└── Slat Position Feedback

Each function should have a clear Group Address rather than combining unrelated information.

Example 4: Central functions

Central functions should have their own logical area.

For example:

Central Functions

All Lights OFF
All Blinds UP
All Blinds DOWN
Away Mode
Night Mode
Welcome Scene
Cleaning Mode
Emergency Lighting

This prevents central functions from becoming mixed with individual room functions.

7. Common KNX Group Address Design Mistakes

Many commissioning problems originate not from KNX hardware but from poor logical organisation.

1. Creating Group Addresses while programming

If every programmer creates addresses on demand, the final structure can become inconsistent.

Better approach: establish the Group Address architecture before device programming.

2. Mixing commands and feedback

For example:

1/2/10 = Living Light

and then using it simultaneously as command and feedback can make the system difficult to understand.

Use explicit command and feedback addresses where the application requires them.

3. Using device channels as the primary naming system

A name such as:

MDT AKK-1616.03 Channel 12

describes the hardware rather than the building function.

If the actuator is replaced later, the building function should still have the same logical identity.

4. Poor documentation

An undocumented Group Address becomes a debugging problem.

KNX Association notes that poorly structured and poorly documented Group Addresses make ETS programming, debugging, visualisation and project handover more difficult.

5. No future expansion space

If every available address is immediately occupied, future modifications become messy.

Reserve logical space for future functions.

6. Changing the hierarchy after commissioning

Be careful when restructuring already commissioned projects.

KNX Association notes that changing a Main or Middle Group can also change subordinate Group Addresses, meaning affected devices need to be re-downloaded.

Therefore:

Design first → commission second → restructure only when necessary.

7. Ignoring legacy compatibility

Modern ETS projects may use the extended Group Address range. KNX documentation notes that some older ETS3 plug-in devices may have compatibility limitations with Group Addresses using Main Groups greater than 15.

For projects containing legacy devices, check compatibility before adopting extended Group Address ranges.

8. KNX Group Address Design Checklist

Before starting ETS programming, review the following checklist.

Architecture

  • Group Address structure defined.
  • 2-level or 3-level ETS style selected.
  • Main Groups defined.
  • Middle Groups defined where applicable.
  • Expansion space reserved.
  • Central functions planned.
  • Status/feedback structure defined.

Naming

  • Naming convention documented.
  • CMD/FB terminology standardised.
  • Room names standardised.
  • Function abbreviations documented.
  • Descriptions added where useful.

Function design

  • Lighting Group Address sets defined.
  • Dimming structure defined.
  • Blind structure defined.
  • HVAC structure defined.
  • Scene structure defined.
  • Central functions defined.
  • Alarm/status structure defined.

DPT and object compatibility

  • DPT checked.
  • Object length checked.
  • C/R/W/T/U/I flags reviewed.
  • Sending objects identified.
  • Receiving objects identified.
  • Feedback requirements checked.

Commissioning

  • Group Addresses linked correctly.
  • ETS diagnostics checked.
  • Group Monitor tested.
  • Command telegrams verified.
  • Feedback telegrams verified.
  • DPT values verified.
  • Documentation exported.
  • Final Group Address list included in handover.

ETS can export Group Address information in XML or CSV, which can be useful for documentation and integration with external tools.

Conclusion

A professional KNX Group Address structure is more than a numbering system. It is a logical information architecture for the entire automation project.

The most important principles are:

  1. Design the structure before programming.
  2. Keep naming consistent.
  3. Separate commands, values and feedback logically.
  4. Use DPTs consistently with the intended function.
  5. Create reusable Group Address sets.
  6. Reserve space for future expansion.
  7. Document the structure throughout the project.
  8. Verify the final structure using ETS diagnostics and Group Monitor.

The actual 2-level or 3-level presentation is less important than the clarity and consistency of the engineering structure. KNX Association itself emphasises that Group Address organisation should serve the intended functionality rather than forcing functionality into a particular representation.

For large KNX projects, a well-planned Group Address architecture can save significant time during programming, commissioning, troubleshooting and future maintenance.

Related Posts

Scroll to Top