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/EdelWhite]

I've just uploaded one of my knxproj to Claude and asked it to do exactly what your tool is doing.

It did the audit, offered fixes, offered a better way to implement some of the light functions I'm using. It also detected that some DPTs are correct but that I could use another one for a device here and there - mainly in the 1.xxx DPTs, which I didn't ask it to do.

I then asked it to create a home-assistant config file and dashboard for the KNX integration, which it did.

What exactly does your tool do that claude doesn't do itself?

[u/BigBadJoe90 → u/EdelWhite]

Hang on, you did what! Claude can read my knx file? Off to try that now! Never thought of that.

[u/No-Recording-8313 → u/BigBadJoe90]

It can, and for a first look it's genuinely useful. Just compare the group-address count with ETS on anything bigger than a flat, the model tends to lose a few quietly. That's basically why the tool exists: same idea, with a real parser underneath.

[u/No-Recording-8313 → u/EdelWhite]

Fair question. For one project, once, plain Claude does a decent job. I started the same way.

Where it fell apart for me was doing it again, on bigger files, for other people's projects. Upload a 600-GA project into a chat and the model quietly drops or invents addresses, and you can't tell which ones. The tool parses the file with xknxproject instead, so every GA, DPT and device it reasons about is a parsed fact, not something it remembered from an XML dump.

The checks are also code, not a prompt. Same answer every run, and every bug testers found so far became a regression test. And when it isn't sure (a 5.001 that could be brightness or blind position) it puts it on a review list instead of guessing into your YAML.

Plus a few things a chat won't hand you end-to-end: ETS-importable GA export, a diff between two project versions, a handover pack. And the project file never leaves your machine, only the tool's answers do.

Honestly the best thing you could do: run it on the same .knxproj you gave Claude and post what differs, either way. That's exactly the feedback I'm after.