Introduction
At its core, a KNX system is not about switches, actuators, or apps. It is about communication. Every light turning on, every blind moving, and every temperature change happens because a message is sent, received, and acted upon.
This article explains how KNX communication actually works, focusing on telegrams, communication objects, and group addresses—not as abstract concepts, but as a living system that must remain reliable for decades.
Understanding this communication model is what separates someone who configures KNX from someone who designs KNX.
The Philosophy Behind KNX Communication
KNX does not use a central controller to command devices. Instead, it follows a distributed communication model.
Each device:
- Knows what it should listen to
- Knows what it should send
- Acts independently
There is no master device required for basic operation. This makes KNX:
- Stable
- Fault-tolerant
- Scalable
Communication is event-driven, not continuously polled.
What Is a KNX Telegram?
A KNX telegram is a small data message sent on the KNX bus whenever something happens.
Examples:
- A button is pressed
- A sensor detects motion
- A timer expires
- A scene is recalled
A telegram is not a command like “turn light ON.”
It is more accurately:
“This value has changed.”
Who reacts to it depends entirely on configuration.
What Information Does a Telegram Carry?
A KNX telegram typically contains:
- Source address (which device sent it)
- Destination address (which group it is sent to)
- Control information
- Payload (the actual value, like ON/OFF, dim level, temperature)
The telegram itself does not know or care how many devices receive it.
Why KNX Uses Group Communication
KNX uses group communication, not direct device-to-device addressing.
This means:
- One telegram can control many devices
- Devices do not need to know each other
- Logic remains flexible
A single telegram can:
- Switch multiple lights
- Trigger a scene
- Update visualisation
- Drive feedback LEDs
All at the same time.
Communication Objects: The Device’s Language
Inside every KNX device are communication objects.
A communication object:
- Represents a function
- Holds a value
- Can send or receive data
Examples:
- Switch object
- Dimming value object
- Blind movement object
- Status feedback object
Objects are not addresses.
They are interfaces.
How Communication Objects Work Together
Think of communication objects as ports, not wires.
An object:
- Is linked to one or more group addresses
- Sends data when its value changes
- Updates its internal state when data is received
A single object can:
- Send to multiple group addresses
- Receive from multiple sources
- Be used by logic, scenes, and visualisation
This is why KNX is so flexible.
Group Addresses: The Meeting Point
A group address is the meeting place where communication happens.
It does not belong to any single device.
Instead:
- Sensors send to group addresses
- Actuators listen to group addresses
- Multiple devices can listen to the same group
Group addresses represent functions, not hardware.
Why Group Addresses Are More Important Than Devices
Devices can change.
Group addresses should not.
A well-designed system allows:
- Devices to be replaced
- Logic to be updated
- Visualisation to change
Without touching the core group structure.
This is why poor group address design causes long-term problems.
Data Types: Making Sense of Values
KNX communication uses standardised data formats (DPTs).
These define:
- How many bits are used
- What the value means
- How it should be interpreted
Examples:
- Boolean values (ON/OFF)
- Percentage values
- Temperature values
- Time and date values
Correct data type matching is critical.
Wrong data types cause silent failures, not errors.
Feedback and Status Communication
Professional KNX systems always separate:
- Control
- Feedback
Why?
Because:
- Actuators confirm real state
- Visualisations stay accurate
- Logic remains stable
Feedback telegrams usually travel on different group addresses than control commands.
This avoids loops and false states.
What Happens When a Button Is Pressed? (Real Flow)
- Button detects press
- Communication object changes value
- Telegram is sent to a group address
- Actuator listening to that address receives it
- Actuator changes output
- Actuator sends feedback telegram
- Other devices update their state
No central controller is involved.
Filtering and Traffic Control
In larger systems, not all telegrams should go everywhere.
KNX uses:
- Line filtering
- Area filtering
- Routing rules
This keeps:
- Traffic local
- Response times fast
- Networks stable
Poor filtering is a common cause of slow systems.
KNX Communication Across Media
KNX communication works the same way across:
- Twisted Pair (TP)
- IP
- RF
Only the transport changes — the logic remains identical.
This is why hybrid systems work reliably.
Common Communication Mistakes
❌ Mixing control and feedback
❌ Using device thinking instead of functional thinking
❌ Reusing group addresses randomly
❌ Ignoring data types
❌ Designing without future expansion
Most KNX problems are communication design problems, not hardware faults.
Why Understanding Communication Changes Everything
Once communication is understood:
- Troubleshooting becomes logical
- Expansion becomes safe
- Design decisions become clearer
- Systems become predictable
Without this understanding, KNX feels complex and fragile.
With it, KNX feels simple and powerful.
Conclusion
KNX communication is elegant because it is decentralised, event-driven, and function-based. Telegrams carry values, communication objects interpret them, and group addresses connect everything together.
When designed correctly, this model delivers:
- Stability
- Scalability
- Longevity
KNX systems fail not because the protocol is weak, but because communication is misunderstood.
In professional automation, communication design is system design.
