프로토타입 · 미리 보기: 공식 레지스트리의 모든 서버를 담고 있으며 30분마다 동기화해요. 리뷰와 계정 기능은 다음 단계에서 열려요.
PopNx MCPAI를 쓰는 사람을 위한 MCP 서버 · 쉬운 말로 설명해요

nickol-knx

제작자: NickoScope버전 0.8.2i★ –i내 컴퓨터에서 실행
레지스트리 이름io.github.NickoScope/nickol-knx-mcp

설치

개요

제작자가 쓴 설명(영어 원문)

Read-only KNX/ETS project auditor: validates a .knxproj and generates Home Assistant YAML

PopNx MCP의 세 기둥

이 세 가지는 절대 하나의 점수로 합치지 않아요. 의견, 측정, 인기는 서로 다른 것이니까요.

할 수 있는 일

이 서버는 아직 쉬운 말로 된 요약을 쓰지 못했어요. 아래는 레지스트리에서 읽어 온 사실이에요.

  • 연결 방식: 내 컴퓨터에서 실행
  • 전송 방식: stdio
  • 카테고리: 개발자 도구

설치

쓰고 있는 AI 앱을 고른 다음 설정을 복사하세요.

설치하기 전에

  • 기본 점검: 1개 중 1개 통과
  • 내 컴퓨터에서 내 사용자 계정의 권한(파일, 네트워크, 앱)으로 실행돼요.
  • 직접 입력할 값: NICKOL_KNX_WORKSPACE, NICKOL_KNX_CATALOG

필요한 것

  • PyPIPython의 uv 설치(uvx 명령어용)

어떤 앱을 쓰세요?

위에서 앱을 고르세요. 기억해 두었다가 다음부터는 버튼에 “…에 설치”라고 표시해요.

Claude Desktop → Settings → Developer → Edit Config를 열고 claude_desktop_config.json에 이 내용을 붙여 넣으세요

{
  "mcpServers": {
    "nickol-knx": {
      "command": "uvx",
      "args": [
        "nickol-knx-mcp"
      ],
      "env": {
        "NICKOL_KNX_WORKSPACE": "your-value",
        "NICKOL_KNX_CATALOG": "your-value"
      }
    }
  }
}

터미널에서 이 명령어를 실행하세요

claude mcp add nickol-knx --env NICKOL_KNX_WORKSPACE=your-value --env NICKOL_KNX_CATALOG=your-value -- uvx nickol-knx-mcp

실행하기 전에 빈 값을 채워 주세요.

Cursor에서 열기

또는 설정을 직접 복사하기

프로젝트의 .cursor/mcp.json 또는 ~/.cursor/mcp.json에 붙여 넣으세요

{
  "mcpServers": {
    "nickol-knx": {
      "command": "uvx",
      "args": [
        "nickol-knx-mcp"
      ],
      "env": {
        "NICKOL_KNX_WORKSPACE": "your-value",
        "NICKOL_KNX_CATALOG": "your-value"
      }
    }
  }
}

브라우저가 앱을 열지 물어본 다음, 앱이 설정을 보여 주고 확인을 요청해요. 키 값은 비워 두니 직접 입력하세요.

VS Code에서 열기

또는 설정을 직접 복사하기

프로젝트의 .vscode/mcp.json에 붙여 넣으세요

{
  "servers": {
    "nickol-knx": {
      "type": "stdio",
      "command": "uvx",
      "args": [
        "nickol-knx-mcp"
      ],
      "env": {
        "NICKOL_KNX_WORKSPACE": "your-value",
        "NICKOL_KNX_CATALOG": "your-value"
      }
    }
  }
}

브라우저가 앱을 열지 물어본 다음, 앱이 설정을 보여 주고 확인을 요청해요. 키 값은 비워 두니 직접 입력하세요.

이 서버는 내 컴퓨터에서 실행되는데, ChatGPT는 인터넷에 있는 서버에만 연결할 수 있어요. 다른 앱을 고르세요.

선택한 앱은 이 기기의 쿠키에만 저장돼요. 계정은 필요 없어요.

직접 입력할 값

  • NICKOL_KNX_WORKSPACE env
    Directory the server may write generated files into (reports, HA YAML, ETS exports). Defaults to ./knx-workspace
  • NICKOL_KNX_CATALOG env
    Optional path to a local device catalog for exact vendor decomposition

이 설정은 제작자의 레지스트리 정보로 만들었어요. README와 다르면 README를 따르세요.

할 수 있는 일

내 컴퓨터에서 실행돼요. 설치하면 AI 앱에 도구 목록이 나타나요.

기본 점검i

누구나 볼 수 있는 정보를 점검했고, 코드는 읽지 않았어요. 해당하지 않는 항목은 개수에서 뺐어요. · 2026년 11월 8일 점검

  • ✓ 통과

    제작자와 저장소 일치

    레지스트리 이름이 GitHub 계정 NickoScope 기준으로 확인되었고, 이 계정이 저장소를 소유하고 있어요

  • … 아직 점검 안 함

    계속 관리되고 있음

    아직 GitHub에서 이 저장소를 읽어 오지 않았어요

  • … 아직 점검 안 함

    라이선스 있음

    아직 GitHub에서 이 저장소를 읽어 오지 않았어요

  • – 해당 없음

    엔드포인트 응답

    내 컴퓨터에서 실행되는 서버라 인터넷 엔드포인트가 없어요

  • – 해당 없음

    OAuth로 로그인

    내 컴퓨터에서 실행되며, 대신 로컬 설정을 사용해요

  • … 아직 점검 안 함

    도구 설명에 숨겨진 지시 없음

    내 컴퓨터에서 실행돼요. 도구 목록은 인터넷 엔드포인트가 있는 서버에서만 읽을 수 있어요

개발자 도구 카테고리의 다른 서버와 비교i

  • 이 카테고리의 다른 서버 4928개 중 0%보다 스타가 많아요
  • 이 카테고리의 다른 서버 4928개 중 46%보다 최근에 레지스트리에 공개됐어요
  • 기본 점검 결과가 이 카테고리의 다른 서버 4928개 중 100%와 같거나 더 좋아요

레지스트리에서 이 카테고리의 활성 서버 전체와 비교했어요. 스타는 게시자가 저장소를 소유한 경우에만 세요.

자주 묻는 질문

nickol-knx, 안전한가요?

해당하는 기본 점검 1개 중 1개를 통과했어요. 코드는 읽지 않았어요. 키나 토큰을 넣기 전에 서버가 어떤 권한을 요구하는지 확인하고, 꼭 필요한 권한만 있는 키를 쓰세요.

어떤 키나 코드가 필요한가요?

레지스트리에 필수 키가 나와 있지 않아요. 다만 처음 쓸 때 로그인을 요구하는 서버도 있어요.

내 컴퓨터에서 실행되나요, 클라우드에서 실행되나요?

내 컴퓨터에서 실행돼요. AI 앱이 필요할 때 실행하고, 데이터는 제작자의 서버를 거치지 않아요(서버 자체가 온라인 서비스를 호출하는 경우는 제외).

아직 관리되고 있나요?

GitHub 저장소는 마지막으로 – 변경됐고, 최신 버전(0.8.2)은 2개월 전 레지스트리에 올라왔어요.

어떤 앱에서 쓸 수 있나요?

Claude Desktop, Claude Code, Cursor, VS Code처럼 MCP를 지원하는 앱에서 쓸 수 있어요. 내 컴퓨터에 Python (uv)도 있어야 해요.

대신 쓸 수 있는 건 뭐가 있나요?

같은 카테고리에는: GitHub, Desktop Commander, Cloudflare MCP

대안

같은 카테고리에서 다른 제작자가 만든 서버예요. 스타 순으로 정렬했어요.

카드 보는 법:↓ 주간 다운로드i★ GitHub 스타i세 기둥: 리뷰 · 점검 · 사용 정도i업데이트 = 최신 버전을 레지스트리에 공개한 날i

GitHub

Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.

제작자: github널리 사용됨★ 3.4만5일 전 업데이트

컴퓨터 또는 클라우드

Desktop Commander

MCP server for terminal commands, file operations, and process management

제작자: wonderwhy-er널리 사용됨↓ 71만/주★ 1만17일 전 업데이트

내 컴퓨터에서 실행

Cloudflare MCP

Cloudflare MCP servers

제작자: cloudflare성장 중★ 4.4천14개월 전 업데이트

클라우드에서 실행✓ mcp.cloudflare.com

제작자의 README

README 열기

제작자의 저장소에서 쓰인 그대로 가져왔어요. PopNx MCP가 검토하거나 보증한 내용이 아니에요. HTML, 이미지, 스크립트는 제거했어요. 링크를 누르면 이 사이트를 벗어나요.

nickol-knx-mcp

A design-time KNX / ETS6 assistant exposed as an [MCP](https://modelcontextprotocol.io) server.

Four things you can do with it — all without ever touching the live KNX bus:

  1. Design a project from a spec — turn an equipment list / project specification into a complete, validated group-address structure plus the full implementation document set (ETS-importable XML/CSV, human-readable report, Home Assistant YAML, acceptance test protocol, as-built handover pack).
  2. Audit, repair & finish an existing project — validate naming · DPT & sub-DPT · command↔status · KNX Secure · Matter-readiness, get concrete fix proposals (inferred DPTs, synthesised status GAs), grade completeness, and diff two project versions.
  3. Generate the smart-home layer — assembled Home Assistant entities (colour lights, climate, covers, sensors) that read *real device state*, with everything ambiguous deferred to human review.
  4. Compose a new project from parametrised room templates — from a list of rooms (with a basic/comfort preset per slot) assemble a new, validated project → an allocation manifest + ETS GA XML/CSV + a device BOM proposal. Dry-run, new projects only (R1).

Under the hood: a device library that expands each actuator into its real communication objects — from generic recipes up to the exact vendor object model parsed straight from ETS application programs.

-0b3d2e)

🇷🇺 Русская версия: README.ru.md


🎬 Explore the live interactive demo & dashboard →

New — a whole demo house. examples/demo-home ships a synthetic

239-GA / 47-Function project, the tool's generated report + Home Assistant config + ETS export, and a

full smart-home “brain” — circadian lighting, an 8-factor climate setpoint, a presence/season/time

state machine and statistics — driving a 5-view dashboard. See it all on the

[live site ↗](https://nickoscope.github.io/nickol-knx-mcp/).


🖥️ The dashboard — live in Home Assistant

Real screenshots from a live Home Assistant running the demo house. They show the tool's assembled entities at work: RGBW / RGB / CCT colour lights, six floor-heating climate zones (target, mode and valve %), a circadian lighting curve and a computed climate setpoint — not set by hand.

ClimateLighting
Energy & statsPresence

▶ [Explore it interactively on the live site →](https://nickoscope.github.io/nickol-knx-mcp/) · config in examples/demo-home/ha-brain


🧪 Status & call for testers

This is a public beta. The full pipeline passes an end-to-end smoke test on a synthetic project and has been validated against real multi-thousand-GA ETS5/ETS6 projects (anonymised) — but real ETS projects are wonderfully messy and diverse, and more field reports make it better.

👉 If you have an ETS5/ETS6 project, please try it and tell us what happens. Open a Real-project test report issue. The tool is read-only and never connects to a bus, so testing is safe (see Safety model). See CONTRIBUTING.md for details.

💬 [Join the discussion →](https://github.com/NickoScope/nickol-knx-mcp/discussions/1) — say hi, ask anything, or share what the tool found on your project.


🗺️ Roadmap — shaped by real integrators

Recent reviews from practising KNX integrators (in Discussions) are steering what comes next:

  • Cross-device parameter consistency *(shipped — check_device_parameters)* — flag the one device whose ETS parameter settings differ from its N identical siblings: a thermostat with a different setpoint/hysteresis, a presence detector with a different detection time. Extracts per-device parameters straight from the .knxproj and finds the odd one out on real 42–275-device projects — read-only, no ETS, no bus — and correctly reports nothing on a clean project (no false positives across a different vendor / integrator school).
  • Project Policy Profile *(shipped — check_policy)* — validate a project against *your own* agreed rules (naming, GA taxonomy, command/status exemptions) instead of one universal "professional standard", since conventions differ per integrator; with no profile it validates against the taxonomy inferred from the project itself.
  • Room Template Library — compose a new project from parametrised room templates. R1 shipped (compose_rooms + validate_room_template: new projects, dry-run, allocation manifest + ETS XML/CSV + device BOM). R2 planned: docking into an existing project + exact device selection.
  • Logic Machine support *(coming — in research)* — bring the same read-only, design-time model to Logic Machine (Embedded Systems) installations: parse an LM-based KNX project and run the same naming / DPT / status / topology audits and produce the same handover output, so LM integrators get the same evidential project model they already get from a raw .knxproj. Currently scoping against a real Logic Machine 5 unit.
  • On in-ETS group-address linking we deliberately *don't* reinvent the wheel: for linking GAs to communication objects inside ETS there are already ETS App-Store add-ins today, and native Smart Linking is coming in ETS7 — we point you to those and keep our focus on read-only audit and an evidential project model.

Have a project to test, a workflow that breaks, or a feature to shape? → [Discussions](https://github.com/NickoScope/nickol-knx-mcp/discussions).


Why this exists

As of mid-2026 there is no off-the-shelf ETS6 ↔ Claude / MCP tool. The KNX community has been explicitly asking for an integration that can inspect and help modify projects (adding / renaming devices and group addresses) through an AI/CLI workflow. This package fills exactly the design-time layer — the missing one.

The recommended full setup is four layers; only one needs to be built from scratch:

LayerPurposeWhat to useBuild it?
1. Livestates, control, debugging a running houseofficial Home Assistant MCP Server + KNX (XKNX) integrationNo, already exists
2. Design-timeparse .knxproj, validate DPT/naming/status + GA-intent de-noise, generate HA YAML (colour lights + climate assembled) & ETS XML/CSV`nickol-knx-mcp` (this package)YES — this is the gap
3. Files + GitYAML/CSV/XML, versioning the address schemastandard filesystem + git MCP serversNo, already exists
4. Playbook (optional)written design rules your AI client reads (GA structure, naming, DPT, scenes) + an HA backup routineplain files: CLAUDE.md + skills/ha-git-backup. Not served by the MCP server, which works without themNo, included

Safety by design: layer 2 (this server) physically cannot connect to a bus. It has no

network/bus dependency at all — it only reads .knxproj and writes files into a confined

workspace. The "never write to a live bus" requirement is enforced structurally, not by

promise. Any real interaction with the house goes only through layer 1 (Home Assistant).


What you can do with it

📐 Scenario 1 — Design a project from a spec (spec → implementation kit)

Turn a project specification (equipment schedules, cable journals, a device list) into a complete, validated group-address structure — and the full document set to implement it:

  1. Device list → object model. Each device expands into its real communication objects via the device library (decompose_device): a dimmer channel is on/off + status + relative dim (3.007) + absolute value (5.001) + brightness status — not "one GA"; a floor-heating zone is 8 objects; a pulse meter is 6.
  2. The professional logic layer. A bare spec never mentions what makes a project *complete*: central & zone macros, scenes, presence logic, climate-control scaffolding, sun/wind shutter logic, leak→shut-off chains, astro/meteo and date-time sources, reserves in every range. The methodology encodes these completeness patterns — distilled from the KNX Association standard, public manufacturer documentation and the study of real professional as-built ETS projects (anonymised).
  3. Structure & discipline. 3-level addressing, zone+function naming, command↔status pairing, a DPT on every address.
  4. Deliverables (one command each): ETS-importable XML/CSV · Markdown report · Home Assistant YAML · functional acceptance test protocol · as-built handover pack (inventory, GA map, coverage %, Secure posture, QA findings, topology SVG).

Full methodology: docs/spec-to-structure.md. Field-checked by reconstructing a real 14-room as-built ETS project from its 42-page specification alone: 96 % structural match (662 vs 687 GA), 10 / 10 domain taxonomy, at zero validation errors — full write-up in the [case study](docs/case-study.md). The remaining delta is the integrator's per-device parameterisation, which no spec encodes.

🔍 Scenario 2 — Audit, repair & finish an existing project
  • Read & classify. Parses password-protected ETS5/ETS6 .knxproj via xknxproject; classifies every GA by category (lighting / shutter / hvac / sensor / scene / energy / diagnostics) and kind (command / status / sensor) from the DPT + multilingual (EN/DE/RU) name keywords. GA purpose tagging (functional / reserve / logic / scratch) keeps intentional placeholders out of the error lists, so the report doesn't cry wolf (on a real 685-GA projec

앞부분만 보여 드려요. 나머지는 저장소에서 읽어 보세요

PopNx에게 묻기