Telegrams & group addresses
This is the single most important concept in KNX. Once group addresses click, the rest of the system — and the Group addresses page in KNX Clarity — makes sense.
Telegrams
Devices communicate by sending short messages called telegrams onto the bus. A telegram is tiny (a handful of bytes) and contains, in essence:
- who sent it (the sender's individual address),
- where it is going (a group address, not a device),
- what it says (a small payload — a bit, a percentage, a temperature…),
- and control/checksum fields.
KNX is an event-driven bus: a device only transmits when something changes (a button is pressed, a temperature crosses a threshold). There is no constant polling, so the bus stays quiet and deterministic.
The mailing-list analogy
A group address is not a device. It is best understood as a mailing list:
- A device can send to a group address (like posting to a list).
- One or more devices can listen to that group address (like subscribing to a list).
- The sender does not know or care who is listening.
When a push-button is pressed, it does not "tell the lamp" anything.
It posts a 1 to the group address 1/1/0. Every device subscribed
to 1/1/0 — possibly several lighting actuators — receives it and
acts. Add another lamp to the scene later by subscribing its actuator
channel to 1/1/0; the button never changes.
This indirection is why KNX is so flexible — and why the group-address list is the wiring diagram of the logic. Read the group addresses and you know what controls what, even without touching the building.
Group address structure
A group address is written with slashes. The most common style is three-level:
main / middle / sub e.g. 1/1/0
There is no rule the standard enforces about what each level means
— it is a convention the integrator chooses. A widespread convention
is main = function (lighting, blinds, heating), middle =
location or sub-function, sub = the individual datapoint. Other
projects use a two-level (main/sub) or a free style.
Because the meaning of each level is a convention, you cannot assume
1/x/x is "always lighting". The authoritative meaning lives in the
ETS project — which is exactly why having the versioned .knxproj
in KNX Clarity matters when someone new
inherits the building.
Group objects and flags
Each device exposes group objects (also called communication objects): the hooks you link to group addresses in ETS. A lighting actuator channel might expose "Switch", "Status", "Dim", and so on.
Every group object carries flags that decide its behaviour on the bus:
| Flag | Name | Meaning |
|---|---|---|
| C | Communication | The object is allowed on the bus at all. |
| R | Read | The object answers read requests with its value. |
| W | Write | The object accepts values written to it. |
| T | Transmit | The object sends a telegram when its value changes. |
| U | Update | The object updates its value from others' telegrams. |
| I | Init | The object reads its value on bus return. |
Mis-set flags are one of the classic causes of "the status is wrong"
or "it works one way but not back". They are part of the parameters
stored in the .knxproj.
What this means for a payload
A telegram's payload is not "just a number" — its size and meaning are defined by a datapoint type. A switch is one bit; a dim value is a byte; a temperature is a 2-byte float. Sender and listener must agree on the datapoint type for the group address or the value is nonsense. That is the subject of the next page.