A KNX command and a KNX status are not necessarily the same thing. A wall switch can send an ON command to a lighting actuator, but that command does not automatically prove that the light actually reached the requested state.
This distinction becomes important in professional KNX installations where multiple switches, visualizations, logic controllers, scenes and automation systems interact with the same function.
A properly designed status feedback architecture allows the actual state of the controlled device to be distributed back to the devices that need it. This keeps push-button LEDs, visualization pages, logic functions and other controllers synchronized with the real installation.
KNX Association’s own programming guidance demonstrates this approach for lighting: a separate command Group Address is used for control, while a status Group Address carries the actuator’s actual state back to listening devices.
1. What Is KNX Status Feedback?
Status feedback is the communication of the current state of a device or function back onto the KNX bus.
Consider a simple lighting circuit:
COMMAND
Wall Switch ─────────────────► Lighting Actuator
│
│
▼
Light ON
│
│ STATUS
▼
KNX Status Feedback
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Wall Switch Visualization Logic
LED Screen FunctionThe command answers:
“What do I want the device to do?”
The status answers:
“What is the device actually reporting as its current state?”
These two functions should normally be treated separately in a professional KNX design.
Command example
1/1/10
GF_Living_L01_CMDThe wall switch sends:
0 = OFF
1 = ONStatus example
1/1/11
GF_Living_L01_FBThe actuator sends:
0 = OFF
1 = ONThe two Group Addresses therefore have different purposes.
Why feedback matters
Status feedback becomes particularly important when:
- Several switches control the same light.
- A light can also be controlled by automation.
- A visualization system displays device status.
- Logic changes the output independently.
- Scenes control several devices.
- A user operates the actuator directly.
- Central functions can change the device state.
Without feedback, a push-button LED or visualization may show the last command rather than the actual state.
2. KNX Command vs Status Group Addresses
One of the most important principles in KNX programming is separating command communication from status communication.
A typical lighting function may therefore use two Group Addresses:
| Function | Group Address | Purpose |
|---|---|---|
| Command | 1/1/10 | Request ON/OFF |
| Status | 1/1/11 | Report actual ON/OFF state |
The architecture becomes:
COMMAND GA
1/1/10
│
▼
┌───────────────┐
│ Lighting │
│ Actuator │
└───────┬───────┘
│
│ Actual state
▼
STATUS GA
1/1/11
│
┌───────┼────────┐
▼ ▼ ▼
Switch Visual. LogicKNX Association describes this exact principle in its programming guidance for synchronising push-button status LEDs with controlled lighting channels.
Why not use one Group Address?
It is technically possible for multiple Group Objects to share a Group Address, but using the same address indiscriminately for command and feedback can make the communication architecture difficult to understand.
For example:
1/1/10
Living Room Lightcould potentially contain both commands and status.
The problem is that an engineer later cannot immediately determine:
- Which device is the command source?
- Which device is the status source?
- Is a telegram a command or feedback?
- Could a feedback telegram trigger another device?
- Is there a risk of unintended feedback loops?
A dedicated command/status structure makes the project easier to troubleshoot.
Recommended naming
Use an obvious naming convention:
GF_Living_L01_CMD
GF_Living_L01_FBor:
GF_Living_L01_SWITCH
GF_Living_L01_STATUSThe exact convention is less important than applying it consistently.
3. How KNX Actuators Generate Status
A KNX actuator does not necessarily have only one communication object per channel.
Depending on the manufacturer’s application program, a channel may expose separate objects for:
- Command
- Status
- Position
- Position status
- Dimming value
- Dimming status
- Scene
- Lock
- Alarm
- Operating mode
ETS displays the Group Objects supplied by the manufacturer’s application program. Their flags, data type, length and available functions are device/application dependent.
Example: Switching actuator
A typical channel may contain:
Channel 1
Object 1 → Switching
Object 2 → Status Switching
Object 3 → Lock
Object 4 → Forced ControlThe first object may receive the command:
1 = ON
0 = OFFThe status object reports the actual channel state.
Typical communication
Wall Switch
│
│ ON
▼
Switching Object
│
▼
Relay Channel
│
│ Actual relay state
▼
Status Object
│
│ ON
▼
STATUS Group AddressThe status object is therefore connected to the actual output state, rather than simply repeating the command.
Why this distinction matters
Imagine:
- Wall switch sends ON.
- Actuator receives ON.
- Automation logic subsequently turns the output OFF.
If the switch only remembers its last command, it may still indicate ON.
If the switch listens to the actuator’s status Group Address, it can update to OFF when the actuator reports the new state.
That is the purpose of feedback synchronization.
4. KNX Status Feedback and Communication Flags
Status feedback is closely connected to the communication flags covered in the previous KNXHUB article.
The flags determine how the Group Objects participate in the communication.
ETS defines:
- C – Communication
- R – Read
- W – Write
- T – Transmit
- U – Update
- I – Read on Init
KNX Association specifies that T causes an object to transmit an updated value as a GroupValueWrite, while W allows an object to react to a GroupValueWrite. U allows an object to react to a GroupValueResponse.
Typical command path
Push Button
C + T
│
│ GroupValueWrite
▼
COMMAND Group Address
│
▼
Actuator
C + W
│
▼
Output changesTypical feedback path
Actuator Status Object
C + T
│
│ GroupValueWrite
▼
STATUS Group Address
│
├────────► Push Button
│ C + W
│
├────────► Visualization
│ C + W
│
└────────► Logic Controller
C + WThe exact flags exposed by a particular device can differ, so the manufacturer’s application program should always be checked.
Important distinction: T vs W
A common misunderstanding is:
“If the Group Address is linked, the value will automatically be transmitted.”
Not necessarily.
The transmitting object needs appropriate transmit behaviour, while the receiving object needs to accept the incoming telegram.
Read-based feedback
Feedback can also be obtained through a read/response mechanism.
Visualization
│
│ GroupValueRead
▼
Status Object
│
│ R
▼
GroupValueResponse
│
▼
Visualization
│
│ U
▼
Updated statusThis can be useful for synchronization after initialization.
5. KNX Status Feedback for Lighting and Dimming
Lighting is one of the clearest examples of why command and status should be separated.
ON/OFF lighting
A simple lighting circuit may use:
CMD
1/1/10
GF_Living_L01_CMD
STATUS
1/1/11
GF_Living_L01_FBCommunication:
COMMAND
Switch ────────────────► Actuator
│
│ Output
▼
Light
│
│ STATUS
▼
Feedback GA
│
┌──────────┼──────────┐
▼ ▼ ▼
Switch HMI LogicDimming
Dimming usually requires more than one logical function.
A typical structure may include:
| Function | Example |
|---|---|
| ON/OFF command | GF_Living_L01_CMD |
| ON/OFF status | GF_Living_L01_FB |
| Relative dimming | GF_Living_L01_DIM |
| Absolute brightness | GF_Living_L01_VAL |
| Brightness status | GF_Living_L01_VAL_FB |
The exact DPTs depend on the application, but commonly:
- Switching uses a 1-bit DPT.
- Relative dimming uses a dimming-control DPT.
- Absolute brightness uses a percentage/value DPT.
Why brightness feedback matters
Suppose the light is at 60%.
A user opens the visualization.
If the visualization only knows that the light is ON, it may show:
Light: ON
Brightness: ?With brightness feedback:
Light: ON
Brightness: 60%This is especially useful with:
- DALI gateways
- KNX dimming actuators
- Constant-light control
- Scenes
- Touch panels
- Visualization systems
Feedback after automation
Consider a lux-based lighting system:
Lux Sensor
│
▼
Logic
│
▼
Brightness Command
│
▼
KNX Actuator / DALI Gateway
│
▼
Actual Output
│
▼
Brightness Feedback
│
├──► Visualization
└──► LogicThe feedback provides the actual reported output to other KNX functions.
6. Status Feedback for Blinds, HVAC and Other Systems
The same command/status concept applies far beyond lighting.
Blind control
A blind can have separate communication objects for:
UP / DOWN
STOP / STEP
POSITION
POSITION STATUS
SLAT POSITION
SLAT POSITION STATUSFor example:
Blind Position Command
│
▼
Actuator
│
▼
Actual Position
│
▼
Position Status
│
├──► Touch Panel
├──► Visualization
└──► LogicA visualization showing a blind at 70% should ideally be based on a status/position value rather than simply assuming that the last command was executed perfectly.
HVAC
A room thermostat may have:
Temperature Setpoint Command
Temperature Actual Value
Operating Mode Command
Operating Mode Status
Heating/Cooling Status
Fan Stage
Valve PositionAgain, the command and actual state may be different.
For example:
Setpoint Command = 22°C
Actual Room Temperature = 21.4°CThese are completely different values and should not be treated as one function.
Fan coil example
Thermostat
│
│ Mode Command
▼
Fan Coil Controller
│
├── Operating Status
├── Fan Status
├── Valve Status
└── Actual TemperatureOther applications
The same principle applies to:
- Motorised curtains
- Gates
- Garage doors
- Pumps
- Fans
- Energy meters
- Presence systems
- Alarm systems
- DALI gateways
- AV control interfaces
- Modbus/KNX gateways
Whenever a command can produce a state, consider whether that state should be communicated separately.
7. Common KNX Status Feedback Problems and Troubleshooting
Status problems are often misdiagnosed because the controlled function itself may still work.
For example:
The light turns ON correctly, but the push-button LED remains OFF.
This is not necessarily a lighting-control problem.
It may be a feedback problem.
Problem 1: Command works, status LED doesn’t
Check:
COMMAND
Switch
│
▼
Actuator
│
▼
Light ON ✓
STATUS
Actuator
│
▼
Status GA
│
▼
Switch LED
│
✗Investigate:
- Is the actuator status object enabled?
- Is the status object linked to the correct Group Address?
- Is the actuator transmitting status?
- Is the push button listening to the status address?
- Is the DPT correct?
- Is the feedback telegram visible in Group Monitor?
Problem 2: Visualization shows the last command instead of actual state
This usually indicates that the visualization is using the command address as its state source.
A better architecture is:
COMMAND GA
│
└──► Actuator
STATUS GA
│
└──► VisualizationProblem 3: Feedback never changes
Use ETS Group Monitor.
Expected:
Command:
1/1/10 = ON
Status:
1/1/11 = ONIf you see:
1/1/10 = ON
No 1/1/11 telegraminvestigate the actuator’s status object.
Problem 4: Status is reversed
Example:
Light ON
Visualization → OFFCheck:
- DPT
- object mapping
- inversion parameters
- logic
- visualization interpretation
- whether the status object represents relay state or another logical state
Do not immediately change the Group Address.
Problem 5: Multiple devices transmit status
A Group Address can contain multiple linked objects. ETS identifies the Group Address and its linked objects, and the first Group Address associated with an object is its sending Group Address.
For a status Group Address, identify exactly which object is intended to be the status source.
For example:
STATUS GA 1/1/11
Actuator A → STATUS ✓
Push Button B → LISTEN
Push Button C → LISTEN
Visualization → LISTEN
Logic → LISTENThis is much clearer than having several unrelated objects transmit onto the same status address.
Problem 6: Feedback works after commissioning but fails after restart
Investigate the read/response path:
Device Restart
│
▼
I flag
│
▼
GroupValueRead
│
▼
Status Object
│
▼
R flag
│
▼
GroupValueResponse
│
▼
U flag
│
▼
Receiving object updatedThe exact behaviour depends on the devices and application programs.
8. KNX Status Feedback Design Checklist
Before completing a KNX project, review every important controlled function.
Command architecture
- Command Group Address defined.
- Command source identified.
- Receiving object identified.
- Correct DPT assigned.
- Communication flags checked.
Status architecture
- Status Group Address defined.
- Actual status source identified.
- Status object enabled.
- Status object linked correctly.
- Feedback DPT verified.
- Listening devices linked to the status address.
Visualization
- Visualization reads status rather than assuming command state.
- ON/OFF status verified.
- Dimming value verified.
- Blind position verified.
- HVAC status verified.
Commissioning
- Command telegram tested.
- Status telegram tested.
- Feedback tested after manual operation.
- Feedback tested after automation.
- Feedback tested after central command.
- Feedback tested after device restart where relevant.
- ETS Group Monitor checked.
- Groups Diagnostics checked where required.
ETS provides Groups Diagnostics specifically for checking functionality at Group Address level. It can check the devices associated with a Group Address, send/receive behaviour and bus traffic.
Documentation
For each important function, document:
Function:
GF Living Room Light 01
Command:
1/1/10
GF_Living_L01_CMD
Status:
1/1/11
GF_Living_L01_FB
DPT:
1.001
Source:
Lighting Actuator Channel 01
Listeners:
Wall Switch
Touch Panel
Visualization
Logic ControllerThis simple documentation structure can dramatically reduce troubleshooting time later.
Recommended Command / Status Architecture
For most KNX projects, a clean logical model is:
COMMAND
┌──────────────────┐
│ ▼
Controller ───────► Actuator
│ │
│ │
│ ▼
│ Actual Output
│ │
│ ▼
│ STATUS
│ │
│ ┌─────────┼─────────┐
│ ▼ ▼ ▼
└────► Pushbutton HMI Logic
LED │
▼
VisualizationThe critical concept is:
Command tells a device what to do.
Status tells other devices what state the function is actually reporting.
This separation becomes increasingly important as the KNX installation grows and more systems interact with the same functions.
Conclusion
KNX status feedback is a fundamental part of professional KNX programming.
A command alone does not provide a complete information model. In a simple installation, a button may appear to work correctly without dedicated feedback, but once multiple controllers, visualizations, scenes, logic functions and automation systems are involved, the distinction becomes essential.
A robust KNX architecture normally separates:
Command → Control the function
Status → Report the function
Feedback → Synchronize other devices
The same principle applies to lighting, dimming, blinds, HVAC, DALI gateways, motorised equipment and other KNX-integrated systems.
During commissioning, do not stop after confirming that the command works. Verify the complete path:
Command → Actuator → Actual State → Status Object → Feedback Group Address → Receiving Devices
That is the difference between a KNX installation that merely responds to commands and one that maintains a consistent, observable system state.
