How KNX Group Addresses Should Be Designed

By /
nl-smarthome-728x90

Introduction

Group address design is the core logic layer of a KNX project. Wiring can be perfect, devices can be premium, and programming can be correct — yet a poorly designed group address structure can make a KNX system difficult to commission, hard to troubleshoot, and almost impossible to expand.

This article explains how KNX group addresses should be designed from the beginning, using engineering structure rather than habit or copy-paste methods. The goal is clarity, scalability, and long-term maintainability.

What a KNX Group Address Really Represents

A KNX group address is not a device address.
It represents a function, not hardware.

Examples of functions:

  • “Living Room – Main Light – Switch”
  • “Bedroom – Blind – Up/Down”
  • “Floor 2 – All Lights OFF”

Thinking in terms of functions rather than devices is the first step toward a clean design.

Why Group Address Design Matters More Than You Think

Poor group address design leads to:

  • Confusing ETS projects
  • Accidental logic conflicts
  • Difficult fault diagnosis
  • Risky future modifications
  • High dependence on the original programmer

Good design results in:

  • Faster commissioning
  • Easier troubleshooting
  • Safe expansion
  • Clean documentation
  • Transferable projects between engineers

Google aside — this is about professional survival on real projects.

Start With Functional Zoning, Not Rooms

A common mistake is designing addresses strictly room-by-room.
Instead, start with functional zoning:

Typical high-level functions:

  • Lighting
  • Dimming
  • Blinds / Shutters
  • HVAC
  • Scenes
  • Central functions
  • Feedback / Status

Rooms come after, not before.

Choosing Between 2-Level and 3-Level Group Addresses

KNX supports:

  • 2-level structure (Main / Sub)
  • 3-level structure (Main / Middle / Sub)

For anything beyond a small apartment, 3-level structure is strongly recommended.

Why 3-Level Works Better

  • Clear hierarchy
  • Easier filtering
  • Better scalability
  • Cleaner logic separation

2-level addressing becomes messy very quickly in medium projects.

Recommended 3-Level Group Address Structure

A proven professional approach:

Main Group → Function

Example:

  • 0 = Lighting
  • 1 = Dimming
  • 2 = Blinds
  • 3 = HVAC
  • 4 = Scenes
  • 5 = Central Functions
  • 6 = Feedback / Status

Middle Group → Area or Room

Example:

  • 0 = Living Room
  • 1 = Bedroom
  • 2 = Kitchen
  • 3 = Floor 1
  • 4 = Floor 2

Sub Group → Specific Action

Example:

  • 0 = Switch
  • 1 = Dim Value
  • 2 = Up
  • 3 = Down
  • 4 = Stop
  • 5 = Status

This structure keeps everything predictable.

Example: Lighting Group Address Design

Instead of random numbering:

❌ 1/23/5 (no meaning)

Use logical mapping:

  • 0/1/0 → Living Room – Light – Switch
  • 0/1/1 → Living Room – Light – Status
  • 0/2/0 → Bedroom – Light – Switch

An engineer should understand the project without opening documentation.

Separate Control and Feedback (Very Important)

Never mix:

  • Command objects
  • Status feedback

Bad practice:

  • Same group address for switch + feedback

Correct practice:

  • One address for control
  • One address for feedback

This prevents:

  • Telegram loops
  • False states
  • Visualisation errors

Scene Addressing: Keep It Centralised

Scenes should not be buried inside room logic.

Good practice:

  • One main group for scenes
  • Middle group per area
  • Sub group per scene number

Example:

  • 4/1/1 → Living Room – Scene 1
  • 4/2/3 → Bedroom – Scene 3

This keeps scenes reusable and clean.

Central Functions Need Their Own Space

Central commands like:

  • All Lights OFF
  • Panic OFF
  • Away Mode

Should always be:

  • Clearly separated
  • Never mixed with room logic

Example:

  • 5/0/0 → All Lights OFF
  • 5/0/1 → All Blinds Up

This avoids accidental triggers.

Design for Expansion (Even If Client Says “Final”)

Clients always say:

“No future expansion needed.”

Reality always proves otherwise.

Good group address design:

  • Leaves unused gaps
  • Avoids tight numbering
  • Allows new rooms or floors

Never design addresses “fully packed”.

Naming Conventions Are as Important as Numbers

Bad naming:

  • “Light1”
  • “Switch A”
  • “Output 3”

Good naming:

  • “Living Room – Main Light – Switch”
  • “Bedroom – Blind – Up”

Names are what humans read — numbers are what KNX uses.

Common Group Address Design Mistakes

❌ Copying addresses from old projects

❌ Mixing feedback and control

❌ Using device names instead of functions

❌ Overusing central logic

❌ Designing without documentation mindset

These mistakes don’t show immediately — they hurt later.

Group Addresses and ETS Project Health

A well-designed group address structure:

  • Makes ETS diagnostics easier
  • Improves filtering performance
  • Reduces commissioning time
  • Makes handover safer

ETS does not fix bad design — it only exposes it.

When to Redesign Group Addresses

Redesign is justified when:

  • Project is unmaintainable
  • Logic conflicts are frequent
  • Expansion is blocked
  • Original programmer is unavailable

In such cases, redesigning addresses is cheaper than living with chaos.

Conclusion

KNX group address design is not an administrative task — it is system architecture.

A good structure:

  • Communicates intent
  • Survives expansion
  • Protects system integrity
  • Makes engineers replaceable (in a good way)

In professional KNX projects, group addresses should be designed once — and designed right.

Related Posts

Scroll to Top