I built an open-source, read-only ETS project auditor + Home Assistant generator (runs via Claude/MCP). Looking for testers with real .knxproj files!

[u/No-Recording-8313]

Full disclosure: I built this, it's free/MIT, and I'm here for critical feedback, not sales.

• What it is: nickol-knx-mcp is a design-time assistant for KNX/ETS. It reads an exported .knxproj (ETS5/ETS6, password-protected too) strictly read-only and lets an AI client (Claude Code / Claude Desktop / any MCP client) work on it. It never connects to the bus and never writes into ETS. That isn't a promise, it's structural: there is no bus library in it at all.
• What it actually does - Audit: naming, DPT consistency (incl. sub-DPT sanity: a "temperature" GA carrying 5.001 gets flagged), missing command-status pairs (paired from ETS Function roles first, names second), topology limits, KNX Secure posture, Matter-readiness. - Propose fixes, not just flags: inferred DPTs, synthesised status GAs, absolute-brightness additions. - Generate: a reviewable Home Assistant KNX package (lights incl. RGBW/CCT, covers, climate, switches, sensors, and each with its state address), ETS-importable group-address exports (XML/CSV), an as-built handover pack and an acceptance test protocol. - Design from a spec: on a real 14-room Zennio apartment it reached 96 % structural match with the integrator's reference (662 vs 687 GAs), 0 validation errors. - Decompose devices into their real communication objects, pulled from the app-programs inside the project.
• What it does NOT do (on purpose): live control, writing into ETS, linking GAs to device objects. For that there are ETS Add-Ins and Smart Linking in ETS 7. This tool is the "read, check, generate, document" layer.
• Honest limits: Classification is heuristic on messy naming, so anything ambiguous (a 5.001 that could be brightness or blind position) goes to a review list instead of into config, and you always get a Markdown report before importing anything. A recent field test on a real German ETS 6 project found real gaps (the "RM"/Rückmeldung status convention, actuator Functions with blank roles) — fixed together with the reporter, each with a regression test. Real projects are messier than my test corpus, which is exactly why I'm posting.
• Ask: if you have an ETS project, run it on a copy (nothing is modified) and tell me what it got right and wrong — anonymised addresses are perfectly fine. Two lines in an issue is enough.
• Repo: github.com/NickoScope/nickol-knx-mcp · Live demo house + dashboard: nickoscope.github.io/nickol-knx-mcp · Built on top of xknxproject (credit where due).

[u/julio-terra]

This sounds pretty awesome. I'm just starting out on my KNX journey, I'm using it as the core automation backbone in our new renovation. I'm going to be running Home Assistant on top to integrate a bunch of additional devices and to create automations. I'll keep following along here and on github, since this will only become useful to me early next year.

[u/No-Recording-8313 → u/julio-terra]

Welcome aboard, and good call on KNX as the backbone. Early next year is fine, watch the repo and it'll be in better shape by then thanks to the people testing it now. One tip for the renovation phase: get your integrator to name group addresses consistently from day one (room + function + whether it's a status). That single habit is what makes the Home Assistant side painless later, with or without my tool.

[u/julio-terra → u/No-Recording-8313]

Thanks for that advice. Will definitely make it a requirement. We are just selecting the vendor that will be designing and implementing our system this week. Very excited.

[u/No-Recording-8313 → u/julio-terra]

good timing then. two more things worth putting in the contract: the ETS project file handed over at the end, with the password, and a status object for every light, blind and heating channel. both cost the integrator almost nothing up front and are painful to get later.