KNX Communication Flags determine how a Group Object communicates with the KNX bus. They are configured at the Group Object level in ETS and control whether an object can communicate, respond to read requests, accept values, transmit changes, update its internal value, or request its value after initialization.
For KNX integrators, understanding these flags is essential. A device can be correctly programmed, linked to the correct Group Address and physically healthy, yet still fail to behave as expected because one communication flag is incorrectly configured.
ETS provides six important Group Object communication flags: C – Communication, R – Read, W – Write, T – Transmit, U – Update and I – Read on Init. KNX Association documents these flags as part of the Group Object configuration in ETS.
This guide explains what each flag does, how the flags work together, and how to troubleshoot real KNX communication problems using ETS.
1. What Are KNX Communication Flags?
A KNX Group Object represents a function within a KNX device, such as a switch command, temperature value, blind position or lighting status. The Communication Flags determine what that object is allowed to do when communicating with other KNX devices.
The flags do not replace the Group Address or DPT. Instead, they define the communication behaviour of the Group Object connected to that Group Address.
In ETS, the flags are:
| Flag | Name | Basic function |
|---|---|---|
| C | Communication | Enables communication for the object |
| R | Read | Responds to GroupValueRead |
| W | Write | Accepts GroupValueWrite |
| T | Transmit | Sends GroupValueWrite when object value changes |
| U | Update | Accepts GroupValueResponse |
| I | Read on Init | Sends GroupValueRead after initialization |
These definitions are documented directly in the current ETS documentation from KNX Association.
The basic communication model
KNX BUS
│
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
GroupValueWrite GroupValueRead GroupValueResponse
│ │ │
▼ ▼ ▼
W/T R UThe key point is that different flags correspond to different types of KNX group communication.
C is the foundation
The C flag enables communication for the Group Object. KNX Association specifies that when the C flag is set, the other communication flags can be enabled for that object.
Therefore, when troubleshooting a Group Object that appears completely inactive, the first question should be:
Is the C flag enabled?
Group Object direction
ETS also uses the flag combination to represent whether an object behaves as an input, output or bidirectional object. KNX Association describes:
- Input/output behaviour based on combinations of W/U and T/R.
- Bus input when W or U is used.
- Bus output when R or T is used.
This is important because the same Group Address can behave very differently depending on the Group Object’s flags.
2. C and W Flags – Communication and Write
The C and W flags are among the most important flags for everyday KNX control.
The C flag enables the Group Object’s communication capability, while the W flag determines whether the object reacts to a GroupValueWrite telegram received from the bus.
KNX Association defines the W flag as the ability of the Group Object to react to a GroupValueWrite and overwrite its object value. For an actuator, this can directly result in the associated function changing state.
C – Communication
Think of C as the basic communication permission.
C = OFF
│
└── Group Object communication disabled
C = ON
│
└── Other communication behaviour can operateIf C is disabled, the object will not communicate normally even if other flags appear configured.
W – Write
W determines whether the object accepts a GroupValueWrite from the bus.
Example:
Wall Switch
│
│ GroupValueWrite
│ "1"
▼
Group Address
│
▼
Lighting Actuator
│
│ W = ON
▼
Relay ONIf W is disabled on the receiving actuator object, the actuator will not react to that GroupValueWrite through that Group Object.
Typical lighting command
A wall switch may have:
Switch Object
C = ON
T = ONThe lighting actuator may have:
Switch Object
C = ON
W = ONThe resulting communication is:
Push Button
│
│ T
▼
GroupValueWrite
│
▼
Group Address
│
▼
Actuator
│
│ W
▼
Relay changes stateCommon mistake
An integrator sees that the push button is correctly linked to the Group Address but the actuator does nothing.
The Group Address is correct.
The DPT is correct.
The bus is working.
But the actuator’s W flag is disabled.
The result is a classic commissioning fault.
Practical rule
For a typical command object:
Sender → T
Receiver → W
This is a useful starting point, although actual flag configurations depend on the manufacturer’s application program and intended function.
3. R and I Flags – Reading Values and Initialization
The R and I flags are particularly important when devices need to obtain an existing value from another KNX device.
They are commonly involved in status retrieval, startup synchronization and device initialization.
The R flag determines whether a Group Object responds to a GroupValueRead telegram. The I flag causes the device to send a GroupValueRead after device reset so that it can obtain the current value through a GroupValueResponse.
R – Read
Consider a temperature or status object.
A device sends:
GroupValueRead
│
▼
Group Address
│
▼
Object with R = ON
│
▼
GroupValueResponseThe device holding the requested value needs the R flag enabled for that object to respond to the read request.
Example: actuator status
Suppose a visualization system wants to know whether a light is currently ON.
Visualization
│
│ GroupValueRead
▼
1/2/15
│
▼
Actuator Status Object
│
│ R = ON
▼
GroupValueResponse = 1The visualization can then update its displayed state.
I – Read on Init
The I flag works differently.
When the device initializes, the object sends a GroupValueRead.
KNX Association describes the purpose as obtaining the current object value through a GroupValueResponse after device reset. A reset can occur due to power failure, bus reset or an explicit device reset.
Conceptually:
Device Reset
│
▼
I = ON
│
▼
GroupValueRead
│
▼
Group Address
│
▼
Device with R = ON
│
▼
GroupValueResponse
│
▼
Initializing device receives valueWhy this matters in real projects
Imagine a visualization server restarts after a power interruption.
The lighting itself may still be ON.
If the visualization has lost its internal state, it needs a way to retrieve the actual KNX value.
Read/response communication can provide that synchronization.
R vs I
These flags are often confused:
| Flag | Question it answers |
|---|---|
| R | “Should this object respond when somebody reads its value?” |
| I | “Should this device request the value when it initializes?” |
They are therefore complementary rather than interchangeable.
4. T and U Flags – Transmit and Update
The T and U flags are particularly important for understanding the difference between a device transmitting a value and a device updating its internal value from a response.
KNX Association defines T as transmitting an updated object value using a GroupValueWrite telegram, while U allows the object to react to a GroupValueResponse and overwrite its object value.
T – Transmit
T means that the Group Object transmits its updated value onto the KNX bus.
A common example is a push button.
User presses button
│
▼
Button object value changes
│
│ T = ON
▼
GroupValueWrite
│
▼
Group AddressThe receiving devices can then react to that value if their corresponding objects accept the write.
U – Update
U is different.
The U flag allows the object to react to a GroupValueResponse and update its internal value.
GroupValueResponse
│
▼
Group Object
│
│ U = ON
▼
Internal object value updatedT vs U
| Flag | Direction | Telegram/value behaviour |
|---|---|---|
| T | Object → Bus | Sends changed object value as GroupValueWrite |
| U | Bus → Object | Updates object from GroupValueResponse |
A useful example
Consider a visualization object that needs to know the current light state.
KNX BUS
│
┌──────────┴──────────┐
│ │
GroupValueRead GroupValueResponse
│ │
▼ ▼
Status Object Visualization Object
│ │
R = ON U = ONThe status object responds because R is enabled.
The visualization object accepts the response because U is enabled.
Why U is not simply “Read”
This is an important distinction:
R enables responding to a read.
U enables accepting the response.
The two flags operate on opposite sides of the read/response exchange.
5. Understanding Flag Combinations in Real KNX Applications
The flags become much easier to understand when viewed as complete communication paths rather than individually.
The correct combination depends on the device manufacturer’s application program and the intended behaviour of the object. ETS can show whether a Group Object is behaving as a bus input, bus output or bidirectional object based on its flag configuration.
Example 1: Simple ON/OFF push button
A typical sending object may use:
C = ON
T = ONThe actuator receiving the command may use:
C = ON
W = ONCommunication:
Push Button
C,T
│
▼
GroupValueWrite
│
▼
Group Address
│
▼
Actuator
C,W
│
▼
RelayExample 2: Lighting status feedback
A lighting actuator may transmit its current state:
Actuator Status
C = ON
T = ONA visualization object may accept the transmitted value:
Visualization
C = ON
W = ONThe exact configuration depends on how the manufacturer’s application implements the status object.
Example 3: Readable status
For a device that should provide a response when another device requests its value:
Status Provider
C = ON
R = ONThe requesting device may use:
C = ON
I = ON
U = ONThe sequence becomes:
Requester
│
│ Initialization
▼
GroupValueRead
│
▼
Status Provider
│
│ R
▼
GroupValueResponse
│
▼
Requester
│
│ U
▼
Object value updatedExample 4: Bidirectional object
Some objects both transmit their own value and accept values from the bus.
Conceptually:
Group Object
│
┌────────┴────────┐
│ │
Receive Transmit
│ │
W / U T / RKNX Association’s ETS documentation describes bidirectional Group Objects using C together with combinations involving W/U and T/R.
Important warning
Do not assume that every device should be configured manually to a particular flag combination.
Manufacturers define default Group Object behaviour in their application programs. ETS may allow certain flags to be changed while others may be fixed or constrained by the application.
Therefore:
Understand the flags, but always check the manufacturer’s object definition before changing them.
6. Communication Flags and DPTs Work Together
Communication flags determine how an object communicates. The DPT determines what the communicated value means and how it is represented.
These are separate concepts.
For example:
Group Object
│
├── Communication Flags
│ ├── C
│ ├── W
│ └── T
│
└── Data Point Type
└── DPT 1.001The flags do not determine whether a value is ON/OFF, temperature or percentage.
Example: Temperature
Suppose a temperature sensor sends:
Temperature Object
C = ON
T = ON
DPT = 9.001The T flag controls transmission.
DPT 9.001 defines the temperature value format.
Example: Dimming
A dimming object might use:
C = ON
T = ON
DPT = 5.001Again:
T = communication behaviour
DPT = data format
Why this distinction matters
If a telegram appears in the Group Monitor but the receiving device does not behave correctly, investigate both:
- Communication flags
- DPT compatibility
Do not assume that a correct DPT automatically means the Group Object is configured correctly.
Likewise, correct communication flags do not make an incompatible DPT work.
7. Troubleshooting Communication Flags in ETS
Communication flag problems are often easy to diagnose once the telegram path is understood.
The first step is to determine whether the telegram is being generated, transmitted onto the bus, received by the intended Group Object and acted upon.
Problem 1: Button works locally but actuator does not respond
Check:
Push Button
│
├── C?
├── T?
└── Correct Group Address?
│
▼
KNX BUS
│
▼
Actuator
│
├── C?
├── W?
└── Correct Group Address?If the button does not transmit, inspect T.
If the actuator receives the telegram but does not act, inspect W and the application parameters.
Problem 2: Status is missing
Suppose the actuator changes correctly but the visualization does not show the correct state.
Check:
- Does the actuator actually transmit status?
- Is T enabled where appropriate?
- Is the visualization object configured to accept the value?
- Is the Group Address correct?
- Is the DPT compatible?
Problem 3: Device does not synchronize after restart
Check the read sequence:
Device Restart
│
▼
I flag?
│
▼
GroupValueRead
│
▼
Source object
│
▼
R flag?
│
▼
GroupValueResponse
│
▼
Receiving object
│
▼
U flag?If any required stage is missing, the synchronization process may fail.
Use ETS Group Monitor
The ETS Group Monitor is particularly useful because it lets the integrator observe group communication and identify whether the expected telegram is actually present on the bus.
For example:
Expected:
Button → GroupValueWrite → 1/2/15
Actual:
No telegram
↓
Investigate sender
Expected:
Actuator → Status → 1/2/16
Actual:
No feedback
↓
Investigate actuator/status objectETS also provides Device Info with Group Communication, which can show Group Objects, their flags, lengths and associated Group Addresses for devices where this information can be read.
Troubleshooting matrix
| Symptom | First things to check |
|---|---|
| No telegram from button | C, T, object parameters |
| Actuator receives but does not react | C, W, application parameters |
| Read produces no response | R on source object |
| Device does not synchronize after reset | I on requesting object |
| Response is not accepted | U on receiving object |
| Status feedback missing | T/status object and Group Address |
| Telegram present but wrong behaviour | DPT, W/U and device parameters |
| Object appears inactive | C flag |
8. KNX Communication Flag Best Practices
Communication flags should not be changed randomly during commissioning. A professional KNX integrator should understand the intended communication path first and then verify the relevant flags.
Best practice 1 — Start with the communication direction
Ask:
Is this object supposed to send, receive, or both?
Then identify the required flags.
SEND
→ T
RECEIVE
→ W / U
RESPOND TO READ
→ R
REQUEST VALUE AT INITIALIZATION
→ IC must support the object’s communication.
Best practice 2 — Distinguish Write and Response
Do not treat W and U as interchangeable.
- W → reacts to GroupValueWrite.
- U → reacts to GroupValueResponse.
This distinction becomes particularly important for status synchronization.
Best practice 3 — Understand the source of a value
When troubleshooting, identify whether the value came from:
- A button
- A sensor
- An actuator
- A visualization
- A logic controller
- A read/response exchange
- Another automation system
Then determine which flag should allow that communication.
Best practice 4 — Do not change flags without understanding the application
Changing a flag may alter the communication behaviour of the device.
Always consider:
- Manufacturer application
- Existing Group Addresses
- DPT
- Communication direction
- Existing automation logic
- Feedback loops
Best practice 5 — Check the actual telegram
Do not rely only on the ETS configuration screen.
If a function does not work:
Configuration → Group Address → Telegram → Receiving Object → Device Behaviour
Follow the complete chain.
Best practice 6 — Document intentional flag changes
If a project uses non-default flag configurations, document why.
For example:
Object:
Living Room Temperature Status
Flags:
C = ON
R = ON
T = ON
W = OFF
U = OFF
Reason:
Dedicated temperature source object.
Readable and periodically transmitted.This can save significant troubleshooting time during future maintenance.
KNX Communication Flags Quick Reference
| Flag | Full Name | What it does | Typical role |
|---|---|---|---|
| C | Communication | Enables communication for the object | Almost all active objects |
| R | Read | Responds to GroupValueRead | Value/status provider |
| W | Write | Accepts GroupValueWrite | Command receiver |
| T | Transmit | Sends GroupValueWrite when object value changes | Sensor/button/status sender |
| U | Update | Accepts GroupValueResponse | Read-response receiver |
| I | Read on Init | Sends GroupValueRead after initialization | Startup synchronization |
These definitions follow the current KNX Association ETS documentation.
KNX Communication Flag Commissioning Checklist
Before closing a KNX commissioning issue, check:
- C flag enabled where communication is required.
- T checked on intended transmitting objects.
- W checked on objects intended to accept GroupValueWrite.
- R checked on objects intended to respond to reads.
- U checked where GroupValueResponse must update the object.
- I checked where initialization should trigger a read.
- Group Address is correct.
- DPT is compatible.
- Communication object length is correct.
- Manufacturer parameters support the intended behaviour.
- Group Monitor confirms the expected telegram.
- Device behaviour matches the telegram received.
Conclusion
KNX Communication Flags are small settings with a major impact on how a KNX installation behaves.
The easiest way to understand them is to think in terms of telegram direction and purpose:
C → Can the object communicate?
T → Does the object transmit a changed value?
W → Does the object accept a write?
R → Does the object respond to a read?
U → Does the object accept a response?
I → Does the object request its value after initialization?
Once these relationships are understood, many KNX commissioning problems become much easier to isolate.
A professional KNX integrator should therefore analyse Group Address + DPT + Communication Flags + Telegram + Device Behaviour as one complete communication chain rather than troubleshooting each element independently.
