KNX bus diagnostics: monitoring, telegram tracing and fault isolation
KNX bus faults range from a silent dead line to an intermittent noise source that corrupts telegrams once a day. Systematic diagnostics — starting with bus voltage and working through telegram tracing to EMC analysis — resolves most faults without replacing hardware.
KNX bus voltage: specification and measurement
The KNX TP bus operates at 29V DC (nominal). Voltage is superimposed with a differential signal at 9600 bit/s. The bus voltage is the first diagnostic measurement because it immediately identifies the most serious fault classes: no power, short circuit and overload.
| Bus voltage | Status | Likely cause | Action |
|---|---|---|---|
| 29V ±1V | Normal | Power supply healthy, line in spec | None — continue with telegram diagnostics |
| 21–28V | Acceptable | Line loaded to near capacity or cable drop | Calculate current budget; check for oversized stubs |
| < 21V | Overload warning | Too many devices for PSU rating; cable too long | Check current budget; add 640mA PSU or segment with coupler |
| 0V (PSU on) | Short circuit | KNX + and − shorted at device or cable junction | Isolate segments; locate short with segment disconnection method |
| 0V (PSU off) | No power supply | PSU failed, MCB tripped, or wiring error | Check MCB protecting 29V PSU; check PSU LED status indicator |
Where to measure bus voltage
Measurement point: KNX bus terminal block in the panel → Between KNX bus + (red) and KNX bus − (black) terminals → At the patch point closest to the power supply → Then at the furthest device on the line (check voltage drop) Tool: Digital multimeter, DC voltage range 50V or 100V → Acceptable voltage drop along the cable: max 2V → If drop > 2V: cable too long, too thin, or too many joints Never measure bus voltage with the bus carrying live telegrams using an analogue meter — the signal will deflect the needle and give a false low reading. Use a true-RMS digital meter.
Bus current budget calculation
Every KNX device draws current from the 29V bus power supply. The sum of all device currents must not exceed 75% of the PSU rated output — the safety margin accounts for inrush current during device startup and bus signal amplitude requirements.
160mA PSU
120mA max load
~8 devices at 15mA avg
MDT STC-0160.01
320mA PSU
240mA max load
~16 devices at 15mA avg
MDT STC-0320.01
640mA PSU
480mA max load
~32 devices at 15mA avg
MDT STC-0640.01
Individual device current draws: simple binary inputs draw 5–8mA; push button interfaces draw 5–12mA; actuators (4-fold, 8-fold) draw 10–20mA; DALI gateways draw 20–30mA; IP routers draw up to 50mA. Always check the device datasheet in ETS6 — the current draw is listed in the device properties window.
Current budget calculation example
Line 1.1 — Floor 1 lighting and blinds (28 devices): Device type Qty mA each Total ───────────────────────────────────────────────────── MDT BMK2.01 (binary input 2ch) 8 × 5mA = 40mA MDT AKD-0424.02 (4ch actuator) 4 × 12mA = 48mA MDT JAL-0410.01 (4ch shutter) 2 × 20mA = 40mA Gira 509000 (4-button sensor) 6 × 8mA = 48mA MDT STC-0321.02 (DALI gateway) 2 × 25mA = 50mA MDT SCN-IP200.02 (IP router) 1 × 40mA = 40mA ───────────────────────────────────────────────────── Total 23 = 266mA Safety margin (+33%) = 354mA Selected PSU: MDT STC-0640.01 (640mA) ← comfortable margin
Diagnostic tools: selection guide
| Tool | Type | Cost | Capability | Best for |
|---|---|---|---|---|
| ETS6 Group Monitor | Software (ETS6 free) | Free with ETS6 | Real-time GA telegram display, DPT decoding, source/dest filter | Live commissioning verification, GA flag testing |
| ETS6 Bus Monitor | Software (ETS Pro) | ETS Pro licence | Raw telegram trace incl. repeat, acknowledge, priority, NAK | Deep protocol-level debugging, ACK failure analysis |
| Wireshark + USB IP interface | Software + hardware | Free + ~€200 interface | Full KNXnet/IP packet capture over LAN or USB | Network-level IP routing problems, multicast analysis |
| MDT Bus Analyzer SCN-BA-U | Hardware | ~€400 | Standalone capture to SD card, no laptop needed on site | Intermittent faults on large sites; overnight capture |
| Lingg & Janke LK-BA4 | Hardware | ~€350 | 4-port bus analyzer with local SD storage and LED error indicators | Multi-line simultaneous capture; site without engineer |
| Digital multimeter (DC) | Hardware | €30–150 | Bus voltage (DC), continuity (Ohm), short circuit detection | First-on-site check; always required |
Telegram tracing with ETS6 Bus Monitor
The ETS6 Bus Monitor (available in ETS Professional) captures every telegram on the bus including acknowledgement frames, repeat requests and NAK responses. This level of detail is essential for diagnosing application-incompatibility errors and timing issues.
ETS6 Bus Monitor — reading a telegram
Telegram field structure: Time Source PA Dest GA APDU DPT value Flags ───────────────────────────────────────────────────────────── 12:04:01 1.1.5 1/1/1 Write 1 (On) C W - 12:04:01 1.1.10 1/1/1 Write 1 (On) C - T ← actuator confirms 12:04:03 1.1.5 1/1/2 Read ? C - R ← polling status 12:04:03 1.1.10 1/1/2 Response 1 (On) C - T Key fields: Source PA → Individual address of the sending device Dest GA → Group address the telegram is directed to APDU type → Write (command), Read (poll), Response (reply to poll) DPT value → Decoded data value — verify against expected DPT Flags → C = Communication; W = Write; R = Read; T = Transmit Repeat telegrams — warning sign: If same telegram appears 3 times in sequence → device did not acknowledge → possible bus collision or device unresponsive → Check individual address, re-download application
ETS6 Group Monitor filter syntax
Filter by group address (Group Monitor filter bar): 1/* → All telegrams to Main group 1 1/1/* → All telegrams to Main 1, Middle 1 1/1/1 → Exactly group address 1/1/1 Filter by source individual address: src:1.1.5 → Only telegrams sent from device 1.1.5 src:1.1.* → All devices on line 1.1 Combined filter: src:1.1.5 1/1/* → Telegrams from push button 1.1.5 to lighting GAs Filter by DPT: dpt:1.001 → Only boolean switch telegrams (on/off) dpt:9.* → All 2-byte float telegrams (temperature, etc.) Exclude heartbeat spam: !src:0.0.1 → Exclude telegrams from NTP time source
Common fault diagnosis
| Symptom | Likely cause | Diagnostic step | Fix |
|---|---|---|---|
| Bus voltage = 0V, PSU LED on | Short circuit on bus segment | Measure voltage at PSU terminals; disconnect line in sections | Use segment isolation — disconnect half the line, re-check voltage; repeat until short located |
| Bus voltage < 21V under load | Current overload — too many devices for PSU | Calculate total current budget; check ETS6 device properties for each device mA draw | Add second KNX PSU with choke separator, or split line with line coupler |
| Device offline in ETS / no response to download | Individual address not programmed, or address conflict | Press programming button on device — LED lights; ETS6 → Topology → Read Individual Addresses | Re-programme device PA via programming button mode; check for duplicate PAs on same line |
| Button pressed but actuator does not respond | Group address not linked, Write flag missing, or wrong GA assigned | Open Group Monitor; press button; check if telegram appears and destination GA is correct | Verify GA assignment in ETS6; check Write flag is set on button communication object |
| Actuator responds locally but not from visualization | Read flag or Transmit flag missing on status GA | Group Monitor → check if status telegram is transmitted when actuator operates | Enable Transmit flag on actuator status communication object; re-download |
| Cyclic telegram flood — bus 70%+ utilisation | Cyclic sending interval set too short on sensor or actuator | Bus Monitor → identify high-frequency source PA; check ETS parameters for cyclic sending | Increase cyclic sending interval to minimum necessary (60 min for status; disable for control) |
| KNXnet/IP programming not connecting | Multicast routing blocked, or IP interface busy with another tunnel | Ping IP interface; check ETS6 → IP interface connection; check router IGMP snooping | Restart IP interface; check max tunneling connections (usually 4); verify IGMP snooping enabled |
| ETS6 download fails with 'firmware version mismatch' | ETS6 application version does not match device firmware | Check device firmware version in ETS6 device properties → Application version field | Download matching .knxprod from manufacturer; import into ETS6 catalogue; re-assign application |
Hardware bus analyzers: MDT and Lingg & Janke
Software-only monitoring requires a laptop permanently connected to the installation. Hardware bus analyzers operate standalone: they connect directly to the KNX TP bus, capture all telegrams to an SD card or internal memory, and can be left overnight to capture intermittent faults that would never appear during a daytime site visit.
MDT Bus Analyzer SCN-BA-U
- USB-powered, DIN rail mountable
- Captures all telegrams including NAK and repeat frames
- Exports log to PC for post-analysis in MDT Bus Analyzer software
- Filters configurable by group address range or individual address
- Timestamp resolution: 1ms — sufficient for collision analysis
- Essential for intermittent faults on large commercial installations
Lingg & Janke LK-BA4
- 4-channel analyzer — monitors 4 KNX lines simultaneously
- SD card storage — leave on site for 24h+ capture
- LED error indicators: bus voltage, collision rate, ACK failure rate
- Analysis software: import CSV to ETS Bus Monitor or custom tool
- Particularly effective for multi-line installations with cross-line timing issues
- Compatible with ETS Bus Monitor log format for direct import
When to use a hardware analyzer: any fault that does not reproduce during a site visit — typically EMC-induced errors from VFD drives, bus resets coinciding with machinery startup, or intermittent ACK failures on a specific line. Software monitoring requires a permanently connected laptop; hardware analyzers run unattended and capture the exact fault timestamp for correlation with plant operational logs.
EMC interference identification and mitigation
Electromagnetic interference is the most insidious KNX fault source because it produces intermittent errors that vary with load conditions and time of day. The three most common EMC sources in building installations are leading-edge dimmers, variable frequency drives (VFDs) on HVAC motors, and LED drivers without EMI filtering.
Leading-edge (TRIAC) dimmers
Symptom: Random telegram corruption on adjacent cable runs; bus monitor shows frequent ACK failures on lighting lines
Fix: Replace with trailing-edge (MOSFET) dimmers or KNX DALI ballasts. Run KNX TP cable at least 50mm from any dimmer output cable. Add ferrite choke on dimmer output if re-routing is not possible.
Variable frequency drives (VFDs) on HVAC
Symptom: Bus errors correlate exactly with HVAC startup/shutdown; errors worse at 50Hz mains frequency multiples
Fix: Increase separation between KNX TP and VFD output cables to minimum 100mm. Route KNX in separate steel conduit. Add KNX choke filter (MDT SCN-EF.02) on the KNX line segment closest to the VFD. Bond VFD chassis to clean earth.
Switching LED drivers without EMI filter
Symptom: Bus noise increases after LED retrofit; errors worse on lines physically close to new LED fixtures
Fix: Replace LED drivers with EN 55015 Class B certified types. Specify drivers from established manufacturers (Tridonic, Philips Xitanium, Osram) rather than unbranded units. Check EMI certification marking on driver label.
Minimum separation distances (IEC 60364-5-52): KNX TP cable must be separated from 230V power cables by at least 50mm without shielding, or 10mm with an earthed metallic separation. KNX cable running parallel to VFD output cables requires 100mm separation minimum or dedicated shielded conduit.
Short circuit isolation: step-by-step
A KNX bus short circuit drops the line voltage to 0V and takes the entire line offline. The PSU enters current-limiting mode (indicated by the overload LED on most MDT and Siemens PSUs). Use the segment disconnection method to locate the fault without an oscilloscope.
Short circuit isolation procedure
Step 1: Confirm short circuit
→ Measure bus voltage at panel terminal: 0V with PSU LED on
→ PSU rated current exceeded: overload indicator lit
Step 2: Disconnect all KNX spur terminals at the panel
→ Remove all KNX TP cables from the distribution terminal block
→ Measure voltage at PSU output: should return to 29V
→ If still 0V: fault is in panel wiring or PSU itself
Step 3: Binary search — reconnect half the spurs
→ Reconnect spurs 1–4 (out of 8 total)
→ Measure bus voltage:
→ Drops to 0V: fault is on spurs 1–4 → reconnect one by one
→ Stays at 29V: fault is on spurs 5–8 → reconnect and test
Step 4: Repeat until fault spur is identified
→ Reconnect cables one by one on the fault spur
→ Voltage drops to 0V when faulty cable is reconnected
Step 5: Trace the faulty cable run
→ Disconnect devices one by one from the faulty cable run
→ Voltage recovers when faulty device or junction box is found
→ Common fault locations: pinched cable at conduit entry,
reversed polarity at device terminal, damaged cable at bend
Step 6: Line coupler isolation (multi-line installations)
→ If line coupler is in-circuit: set coupler to Block All mode
→ This isolates the sub-line without cutting bus continuity
→ Use ETS6 to put line coupler in block mode remotely
if the backbone is still liveNeed a KNX panel commissioned to spec?
We build and fully commission KNX panels — bus voltage verified, group address table tested, and fault-finding completed before the panel ships to site.
Request a quote →