Introduction
In small KNX projects, poor naming is an inconvenience.
In large KNX projects, poor naming becomes a serious operational risk.
Bad naming causes:
- Slow troubleshooting
- Fear of making changes
- Accidental logic breakage
- Dependence on the original programmer
Good naming, on the other hand:
- Makes intent obvious
- Allows safe modification
- Enables multi-integrator collaboration
- Keeps projects maintainable for years
This article explains how to design ETS naming conventions that scale, not just for commissioning, but for the entire lifecycle of a KNX system.
First Rule: Naming Is Part of System Design
Naming is not documentation added later.
It is part of the engineering design itself.
If the name does not clearly describe:
- Where something is
- What it does
- How it is used
…then the system is already harder to maintain.
Core Principle: Names Must Answer Questions Instantly
A good ETS name should answer, without opening parameters:
- Location – Where is this in the building?
- Function – What does it control or represent?
- Type – Is it control, feedback, logic, or infrastructure?
If any of these are missing, the name does not scale.
Naming Devices: Be Boring and Consistent
Device names should be predictable, not creative.
Recommended Device Naming Pattern
[Building]-[Floor]-[Zone]-[Function]-[DeviceType]
Example
BLDG-A_F03_MR-02_Lighting_Actuator
Why this works:
- Sorting groups similar devices together
- Location is immediately visible
- Function is clear without opening ETS objects
Avoid short or ambiguous names like:
Actuator_3 RoomLight MainSwitch
These names fail completely at scale.
Naming Group Addresses: Structure Over Convenience
Group addresses are the nervous system of KNX.
Poor naming here spreads confusion everywhere.
Golden Rule
If you cannot guess what a group address does from its name, it is badly named.
Recommended Group Address Naming Layers
[Function] – [Area/Zone] – [Specific Action or Status]
Example
Lighting – Floor03_MeetingRoom02 – Switch Lighting – Floor03_MeetingRoom02 – Status
This instantly shows:
- What system is involved
- Where it applies
- Whether it is control or feedback
Strict Separation: Control vs Feedback in Names
This is non-negotiable in scalable projects.
Bad Naming
Light MR02
Good Naming
Lighting – MR02 – Switch Lighting – MR02 – Status
This prevents:
- Feedback loops
- LED confusion
- Logic ambiguity
- Future programming mistakes
Names must force correct usage.
Use Standard Keywords Across the Project
Choose keywords once — then never change them.
Examples of Standard Keywords
- Switch / Status
- Dim / DimStatus
- Scene / SceneActive
- Enable / EnableStatus
- Lock / LockStatus
Never mix:
Status / Feedback / State / FB
Pick one — and enforce it.
Consistency beats personal preference.
Naming Logic Objects: Make Dependencies Obvious
Logic is where naming mistakes become dangerous.
Bad Logic Naming
Logic_01 Auto_Light Special_Function
Good Logic Naming
Logic – MR02 – Occupancy Lighting Control Logic – Floor03 – HVAC Enable
Anyone reading the name should immediately understand:
- Scope
- Purpose
- Risk level
Hidden logic causes hidden failures.
Naming for Multi-Integrator Projects
Large projects often involve:
- Multiple vendors
- Multiple commissioning phases
- Future system handover
Recommended Practice
- Prefix logic or special functions with ownership or role
- Example:
INT-A – Logic – Floor02 – Energy Control
This helps teams understand:
- Who created it
- Who should modify it
- Where to ask questions
Avoid Encoding Too Much Detail in Names
Names should be clear, not overloaded.
Avoid:
BLDG-A-F03-MR02-LED-DIM-CTRL-01
Instead:
BLDG-A_F03_MR02_Lighting_Dimmer
Details belong in:
- Parameters
- Comments
- Documentation
Names should stay readable.
Folder Naming: Navigation Is Part of Naming
ETS folders should mirror how engineers think.
Useful Folder Structures
- By building / floor
- By function
- By commissioning status
Example:
Floor 03 ├── Lighting ├── HVAC ├── Shading
Avoid deep, confusing folder trees that hide devices.
Naming for Future Expansion
Always assume:
- New rooms will be added
- Zones will change
- Functions will grow
Leave room in naming:
MR01, MR02, MR03
Not:
MR, MR2, MeetingRoomFinal
Predictable patterns survive expansion.
Renaming in Live Projects: Be Careful
Renaming does not change logic — but it changes understanding.
Safe Renaming Rules
- Rename only after verifying functionality
- Never rename and reprogram logic at the same time
- Document major renaming phases
Clarity is good — stability is critical.
Common Naming Mistakes Seen on Real Sites
❌ Mixing languages
❌ Using abbreviations without standards
❌ Different styles for different floors
❌ Copy-paste names left unchanged
❌ No distinction between control and status
These mistakes make ETS projects fragile.
How to Audit Naming Quality Quickly
Ask these questions:
- Can a new engineer understand the system in 15 minutes?
- Can you search and filter logically?
- Can you identify risky objects instantly?
If not, naming needs improvement.
Why Naming Is an EEAT Signal
Good naming demonstrates:
- Experience (real projects)
- Expertise (system thinking)
- Authority (clear standards)
- Trustworthiness (safe maintenance)
Poor naming signals rushed or inexperienced work — even if logic is correct.
Conclusion
Naming conventions in ETS are not cosmetic.
They are structural engineering decisions.
A scalable naming strategy:
- Reduces errors
- Speeds up troubleshooting
- Enables collaboration
- Protects systems long-term
In large KNX projects, clear naming is one of the cheapest and most powerful reliability tools you have.
