KNX · Diagnostics · Bus Monitor · Fault isolation · 9 min read

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 voltageStatusLikely causeAction
29V ±1VNormalPower supply healthy, line in specNone — continue with telegram diagnostics
21–28VAcceptableLine loaded to near capacity or cable dropCalculate current budget; check for oversized stubs
< 21VOverload warningToo many devices for PSU rating; cable too longCheck current budget; add 640mA PSU or segment with coupler
0V (PSU on)Short circuitKNX + and − shorted at device or cable junctionIsolate segments; locate short with segment disconnection method
0V (PSU off)No power supplyPSU failed, MCB tripped, or wiring errorCheck 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

ToolTypeCostCapabilityBest for
ETS6 Group MonitorSoftware (ETS6 free)Free with ETS6Real-time GA telegram display, DPT decoding, source/dest filterLive commissioning verification, GA flag testing
ETS6 Bus MonitorSoftware (ETS Pro)ETS Pro licenceRaw telegram trace incl. repeat, acknowledge, priority, NAKDeep protocol-level debugging, ACK failure analysis
Wireshark + USB IP interfaceSoftware + hardwareFree + ~€200 interfaceFull KNXnet/IP packet capture over LAN or USBNetwork-level IP routing problems, multicast analysis
MDT Bus Analyzer SCN-BA-UHardware~€400Standalone capture to SD card, no laptop needed on siteIntermittent faults on large sites; overnight capture
Lingg & Janke LK-BA4Hardware~€3504-port bus analyzer with local SD storage and LED error indicatorsMulti-line simultaneous capture; site without engineer
Digital multimeter (DC)Hardware€30–150Bus voltage (DC), continuity (Ohm), short circuit detectionFirst-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

SymptomLikely causeDiagnostic stepFix
Bus voltage = 0V, PSU LED onShort circuit on bus segmentMeasure voltage at PSU terminals; disconnect line in sectionsUse segment isolation — disconnect half the line, re-check voltage; repeat until short located
Bus voltage < 21V under loadCurrent overload — too many devices for PSUCalculate total current budget; check ETS6 device properties for each device mA drawAdd second KNX PSU with choke separator, or split line with line coupler
Device offline in ETS / no response to downloadIndividual address not programmed, or address conflictPress programming button on device — LED lights; ETS6 → Topology → Read Individual AddressesRe-programme device PA via programming button mode; check for duplicate PAs on same line
Button pressed but actuator does not respondGroup address not linked, Write flag missing, or wrong GA assignedOpen Group Monitor; press button; check if telegram appears and destination GA is correctVerify GA assignment in ETS6; check Write flag is set on button communication object
Actuator responds locally but not from visualizationRead flag or Transmit flag missing on status GAGroup Monitor → check if status telegram is transmitted when actuator operatesEnable Transmit flag on actuator status communication object; re-download
Cyclic telegram flood — bus 70%+ utilisationCyclic sending interval set too short on sensor or actuatorBus Monitor → identify high-frequency source PA; check ETS parameters for cyclic sendingIncrease cyclic sending interval to minimum necessary (60 min for status; disable for control)
KNXnet/IP programming not connectingMulticast routing blocked, or IP interface busy with another tunnelPing IP interface; check ETS6 → IP interface connection; check router IGMP snoopingRestart 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 firmwareCheck device firmware version in ETS6 device properties → Application version fieldDownload 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 live

Need 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 →
Loading...
Back to top