v0.3.0

Focus of this release: make the assistant reason like a KNX engineer, not just call the API. The MCP server surfaces parameter and communication-object meaning, validates before it mutates, and keeps large-project reads focused.

Highlights

• Parameter semantics — params.list returns each parameter's text (label), unit, access, enum options (value + label), and numeric min/max, plus documented isActive (post-visibility) meaning. Pick a valid value instead of guessing.
• Communication-object channel grouping — every ComObject is tagged with its channel/function label where the product exposes it. Where it does not, the channel is in the object's text (e.g. "Output A") and the function in functionText (e.g. "Move blinds up-down"); group by channel if present, else text.
• DPT-compatibility check on link — link returns a dptWarning when a com-object and group address have different DPT main numbers (the link still proceeds), catching wrong wiring early.
• Batch pre-flight validation — batch_apply(validate_only=True) runs read-only checks (required params, link com-object exists + active, GA exists, DPT match, GA address collision) and reports per-op issues without mutating. Validate a large batch, fix the flagged ops, then apply.
• Focused reads — list_parameters defaults to active_only=True (only currently-relevant parameters; pass active_only=false for the full set) and supports name_contains. list_comobjects supports name_contains (matches text/functionText/channel).
• Find by human label — list_devices and list_group_addresses gained a name_contains filter that also matches description/comment (device also product/order/address). A device whose label lives in its description, or a GA whose label lives in its description, is now findable.
• Engineering guidance baked in — the MCP server instructions are a compact KNX engineering guide (domain model, the parameter → com-object ordering trap, inspect → plan → apply → verify) and the assistant is told to ask the user for the device's technical-manual PDF for correct parametrization.

Fixes

• Linking a just-activated com-object — after a parameter change activates a com-object, linking it no longer wrongly fails with inactive_object; com-object lookup now uses the active collection (the full collection could retain a stale inactive flag).
• Large params.list — the transport frame limit was raised 4 MB → 16 MB so parameter-heavy devices (12k+ parameters) no longer overflow the client.

Reliable targeting on complex devices

• block on communication objects — each object now carries its authoritative ETS group-object-tree path (e.g. "Operation / Display > Push button functions > PB9/10: Push buttons 9/10"), so you can reliably tell which function/block an object belongs to instead of guessing from names.
• block on parameters — every parameter now also carries its UI path (parsed from the application-program dynamic tree, cached). On multi-function devices the same parameter name repeats many times; select by block + name + isActive (a unique triple) to target the correct instance instead of guessing.
• application.dynamic — returns the device application program's dynamic UI tree (ParameterBlock/Channel/ParameterRefRef) as XML, the authoritative source for mapping a parameter to its UI block/channel on multi-function devices.

Compatibility

• Runs on ETS 5 and ETS 6 (a single ETS 6 build covers 6.3 and 6.4). Additions are optional fields / new parameters.
• Note: link.create now returns { comObjectRef, gaRef, dpt?, gaDpt?, dptWarning? } instead of { ok }.

Install

Download knx-ets-mcp-v0.3.0.zip, extract the whole zip, run install.bat, then start Start-MCP-Server.exe. See the README for client setup.

v0.2.0

Full Changelog: https://github.com/knx-ai/knx-ets-mcp/commits/v0.2.0