Reading the KNX bus monitor like a detective

Open the Diagnostics panel in ETS6 and start the bus monitor. Every telegram on the bus appears in real time: source address, destination, command (group value write, read, response), value, and a timestamp.

A healthy bus has a steady but moderate stream of telegrams. Switch presses, occupancy events, scheduled scene triggers, periodic status reads from a visualization server. Quiet periods alternate with bursts. If the monitor scrolls so fast you cannot read it, something is wrong; one of the devices is generating too much traffic.

Filtering is your friend. By source address, to see what one device is doing. By destination group address, to confirm a specific function works. By command, to find unresponded reads (a common symptom of misconfigured status feedback).

Four patterns to recognize.

Flapping switch. The same switch press generates 5 to 10 telegrams in rapid succession. Likely cause: a noisy contact, or a debounce setting set too short. Fix: clean the contact or extend the debounce in the device parameters.

Feedback loop. Two actuators or a logic block keep writing the same group address back and forth. Symptom: a state ping-pong visible on the monitor. Fix: identify which two devices are involved (their source addresses appear in the loop) and break the cycle by removing the redundant write.

Polling overload. A visualization server reads every status address every few seconds. Bus saturates. Fix: increase the server's poll interval, or move from active polling to subscription-based status updates.

Missing response. ETS sends a read on a group address and the actuator never responds. Likely cause: status sending not configured. Fix: open the actuator parameters in ETS, enable status feedback, reload the device.

The bus monitor turns most field issues from guesswork into observation. Run it whenever something feels wrong; the answer is usually right there on the screen.