ETS Project Structuring for Large KNX Projects

By /
nl-smarthome-728x90

Introduction

In small KNX projects, ETS structure often doesn’t matter much.
In large projects, ETS structure becomes the project’s backbone.

Poor ETS structuring leads to:

  • Confusing troubleshooting
  • Risky changes
  • Long commissioning time
  • Fear of touching the system later

Well-structured ETS projects, on the other hand, allow:

  • Multiple integrators to work safely
  • Easy expansion and modification
  • Faster fault diagnosis
  • Long-term maintainability

This article explains how to structure ETS projects for large KNX installations, based on real experience from hotels, offices, campuses, and multi-building systems.

Why ETS Structure Matters More Than Devices

In large projects:

  • Devices will change
  • Brands may be replaced
  • Functions evolve over time

But ETS structure stays for the entire lifecycle.

A good ETS structure:

  • Reflects the real-world building layout
  • Makes intent obvious to any engineer
  • Reduces dependence on the original programmer

ETS is not just a programming tool — it is project documentation in executable form.

Core Principle: Structure for Humans, Not for ETS

ETS allows many ways to organise a project.
The goal is not to satisfy ETS — it is to help future engineers.

Ask yourself:

“If I open this project after two years, will I understand it in 10 minutes?”

If the answer is no, the structure needs improvement.

Step 1: Define the Physical Hierarchy First

Always start with physical reality, not functions.

Recommended Hierarchy

  • Area → Building or Block
  • Line → Floor or Major Zone
  • Device → Logical placement within that zone

For example:

  • Area 1: Office Block A
  • Line 1: Floor 1
  • Line 2: Floor 2

Avoid mixing unrelated areas just to save lines or addresses.

Step 2: Separate Infrastructure from Function

Large ETS projects become messy when everything is mixed together.

Best Practice

Create a clear separation between:

  • Infrastructure devices (power supplies, couplers, IP routers)
  • Functional devices (actuators, sensors, keypads)

This allows engineers to:

  • Troubleshoot communication independently
  • Modify logic without touching infrastructure

Infrastructure rarely changes — functions change often.

Step 3: Use Consistent Naming Conventions (Non-Negotiable)

In large projects, naming is more important than programming.

Good Naming Answers These Questions

  • Where is the device?
  • What does it control?
  • What type of device is it?

Example

BLDG-A_F02_MR-01_Light-Actuator

Bad naming forces engineers to open parameters to understand intent — which wastes time and increases risk.

Step 4: Group Address Structure Must Mirror Building Logic

Group addresses should reflect how the building is used, not how ETS suggests.

Recommended Concept

  • Main Group: Function (Lighting, HVAC, Shading)
  • Middle Group: Area or Zone
  • Sub Group: Specific Control or Feedback

This structure allows:

  • Predictable expansion
  • Easy filtering
  • Logical navigation

Avoid creating group addresses based on “what comes next”.

Step 5: Strict Separation of Control and Feedback

Large projects break quickly when control and feedback are mixed.

Always Separate

  • Switch / Dim / Command → Control GA
  • Status / Feedback → Feedback GA

This improves:

  • LED feedback reliability
  • Multi-control-point behaviour
  • Logic clarity

It also prevents accidental feedback loops.

Step 6: Segment the Project for Multi-Integrator Work

Large projects often involve:

  • Multiple teams
  • Phased delivery
  • Parallel commissioning

ETS Structuring Tips

  • One area or line per team where possible
  • Clear ownership boundaries
  • Avoid cross-editing shared objects

This reduces merge conflicts and accidental overwrites.

Step 7: Plan for Expansion from Day One

Large projects will expand.

Your ETS structure should allow:

  • New floors
  • New wings
  • New tenants

How to Prepare

A “full” ETS project on day one is a future problem.

Step 8: Keep Logic Visible and Documented

Logic becomes dangerous when it is hidden.

Best Practices

  • Group all logic devices clearly
  • Add comments to logic objects
  • Avoid unnecessary complexity

Logic should be understandable without reverse-engineering.

Step 9: Use Folders and Views Intelligently

ETS folders are not decoration — they are navigation tools.

Useful Folder Types

  • By building / floor
  • By function
  • By commissioning status

Avoid deep nesting that hides devices.

Step 10: ETS Project Is a Live Document

Treat ETS like source code.

Good Discipline

  • Versioned backups
  • Change notes
  • Date and reason for modifications

This prevents fear-driven “don’t touch anything” systems.

Common Structuring Mistakes in Large ETS Projects

❌ One giant area for everything
❌ Random naming styles
❌ No separation of infrastructure
❌ Group addresses created on the fly
❌ Logic hidden across devices
❌ No documentation inside ETS

These mistakes make systems fragile and expensive to maintain.

How to Judge a Good ETS Structure

A well-structured ETS project:

  • Can be understood quickly
  • Can be modified safely
  • Supports multiple engineers
  • Survives years of changes

If changes require luck instead of confidence, the structure is wrong.

Conclusion

ETS project structuring is not about aesthetics — it is about engineering discipline.

In large KNX projects:

  • Devices will change
  • People will change
  • Requirements will change

Only a clear, logical ETS structure ensures the system remains reliable and maintainable over its lifetime.

Good ETS structure is invisible to clients — but priceless to integrators.

Related Posts

Scroll to Top