nickol-knx

nickol-knx-mcp

MCP サーバーとして公開された、設計時の KNX / ETS6 アシスタント。

これでできることは 4 つあり、いずれも実際の KNX バスに一切触れることなく行えます。

1. 仕様からプロジェクトを設計する — 機器リスト / プロジェクト仕様を、完全で検証済みのグループアドレス構造に加えて、実装ドキュメント一式(ETS にインポート可能な XML/CSV、人間が読めるレポート、Home Assistant YAML、受け入れテストプロトコル、竣工引き渡しパック)に変換します。
2. 既存プロジェクトを監査・修復・完成させる — 命名 · DPT とサブ DPT · コマンド↔ステータス · KNX Secure · Matter 対応状況を検証し、具体的な修正案(推定された DPT、合成されたステータス GA)を取得し、完成度を採点し、2 つのプロジェクトバージョンを差分比較します。
3. スマートホーム層を生成する — 実際のデバイス状態を読み取る、組み立て済みの Home Assistant エンティティ(カラーライト、空調、カバー、センサー)を生成し、曖昧なものはすべて人間によるレビューに委ねます。
4. パラメータ化された部屋テンプレートから新しいプロジェクトを構成する — 部屋のリスト(各スロットに basic/comfort プリセット付き)から、新しい検証済みプロジェクトを組み立てます → 割り当てマニフェスト + ETS GA XML/CSV + デバイス BOM 提案。ドライラン、新規プロジェクトのみ(R1)。

内部では、デバイスライブラリが各アクチュエータをその実際の通信オブジェクトへと展開します — 汎用レシピから、ETS アプリケーションプログラムから直接解析された正確なベンダーオブジェクトモデルまで対応します。

🇷🇺 ロシア語版: README.ru.md

---

🎬 ライブインタラクティブデモ & ダッシュボードを見る →

新着 — デモハウス全体。 examples/demo-home には、合成された 239-GA / 47 機能のプロジェクト、ツールが生成したレポート + Home Assistant 設定 + ETS エクスポート、 そしてスマートホームの完全な**「ブレイン」** — 概日リズム照明、8 要素の空調設定値、在室/季節/時間の ステートマシンと統計 — が含まれ、5 ビューのダッシュボードを動かします。すべては ライブサイト ↗ でご覧いただけます。

---

🖥️ ダッシュボード — Home Assistant でライブ動作

デモハウスを実行している実際の Home Assistant からの本物のスクリーンショットです。これらはツールが組み立てた エンティティが動作している様子を示しています: RGBW / RGB / CCT カラーライト、6 つの床暖房気候ゾーン (目標値、モード およびバルブ %)、概日 照明カーブ、そして手動で設定されたものではない 計算された 気候設定値です。

気候	照明
エネルギーと統計	在宅

▶ ライブサイトでインタラクティブに試す → · 設定は examples/demo-home/ha-brain にあります

---

🧪 ステータスとテスター募集

これは パブリックベータ です。パイプライン全体は合成プロジェクトでのエンドツーエンドのスモークテストに合格しており、 実際の数千 GA の ETS5/ETS6 プロジェクト (匿名化済み) に対しても検証されています — しかし実際の ETS プロジェクトは素晴らしいほど雑多で多様であり、より多くの現場からの報告があれば改善されます。

👉 ETS5/ETS6 プロジェクトをお持ちの方は、ぜひ試して何が起こるか教えてください。 実プロジェクトのテストレポート issue を作成してください。このツールは読み取り専用でバスに接続することはないため、テストは安全です (詳細は 安全性モデル を参照)。詳細は CONTRIBUTING.md をご覧ください。

💬 ディスカッションに参加する → — 挨拶したり、何でも質問したり、ツールがあなたのプロジェクトで見つけたことを共有したりしてください。

---

🗺️ ロードマップ — 実際のインテグレーターによって形作られています

現役の KNX インテグレーターからの最近のレビュー（Discussions 内）が、次に何が来るかを方向づけています：

• デバイス間のパラメーター整合性 （提供済み — check_device_parameters） — ETS のパラメーター設定が、同一の兄弟デバイス群と異なる 1 台のデバイスを検出します。設定値/ヒステリシスが異なるサーモスタット、検出時間が異なる在室検知器などです。デバイスごとのパラメーターを .knxproj から直接抽出し、実際の 42〜275 台規模のプロジェクトで逸脱している 1 台を見つけ出します — 読み取り専用で、ETS もバスも不要 — そしてクリーンなプロジェクトでは正しく何も報告しません（異なるベンダー／インテグレーター流派をまたいでも誤検出ゼロ）。
• プロジェクトポリシープロファイル （提供済み — check_policy） — 単一の普遍的な「プロフェッショナル標準」ではなく、あなた自身が合意したルール（命名、GA 分類体系、コマンド/ステータスの例外）に対してプロジェクトを検証します。慣例はインテグレーターごとに異なるためです。プロファイルがない場合は、プロジェクト自体から推測された分類体系に対して検証します。
• ルームテンプレートライブラリ — パラメーター化された部屋テンプレートから新しいプロジェクトを構成します。R1 提供済み（compose_rooms + validate_room_template：新規プロジェクト、ドライラン、割り当てマニフェスト + ETS XML/CSV + デバイス BOM）。R2 計画中：既存プロジェクトへのドッキング + 正確なデバイス選択。
• Logic Machine サポート （近日 — 調査中） — 同じ読み取り専用の設計時モデルを Logic Machine（Embedded Systems）のインストール環境にもたらします。LM ベースの KNX プロジェクトを解析し、同じ命名／DPT／ステータス／トポロジーの監査を実行して、同じ引き継ぎ出力を生成します。これにより LM インテグレーターは、生の .knxproj から得られるのと同じ証跡ベースのプロジェクトモデルを得られます。現在、実機の Logic Machine 5 を使って範囲を確定中です。
• ETS 内でのグループアドレスリンクについては、車輪の再発明を意図的に行いません。ETS 内で GA を通信オブジェクトにリンクするための ETS App-Store アドインはすでに存在し、ネイティブの Smart Linking が ETS7 で登場予定です — それらを案内し、私たちは読み取り専用の監査と証跡ベースのプロジェクトモデルに集中し続けます。

テストしたいプロジェクト、壊れるワークフロー、形にしたい機能がありますか？ → Discussions。

---

これが存在する理由

2026 年半ば時点で、既製の ETS6 ↔ Claude / MCP ツールは存在しません。KNX コミュニティは、 AI/CLI ワークフローを通じてプロジェクトを検査し、変更（デバイスやグループアドレスの追加／ 名前変更）を支援できる統合を明確に求めてきました。このパッケージはまさにその 設計時レイヤー — 欠けているレイヤー — を埋めるものです。

推奨される完全なセットアップは 4 つのレイヤーから成り、ゼロから構築する必要があるのは 1 つだけです：

レイヤー	目的	使用するもの	構築が必要？
1. ライブ	稼働中の住宅の状態、制御、デバッグ	公式 Home Assistant MCP Server + KNX（XKNX）統合	いいえ、すでに存在します
2. 設計時	.knxproj の解析、DPT／命名／ステータスの検証 + GA 意図のノイズ除去、HA YAML（カラー照明 + 空調を組み立て）と ETS XML/CSV の生成	nickol-knx-mcp（本パッケージ）	はい — これがギャップです
3. ファイル + Git	YAML/CSV/XML、アドレススキーマのバージョン管理	標準のファイルシステム + git MCP サーバー	いいえ、すでに存在します
4. プレイブック（任意）	AI クライアントが読む設計ルールの文書（GA 構造、命名、DPT、シーン）+ HA バックアップ手順	プレーンなファイル：CLAUDE.md + skills/ha-git-backup。MCP サーバーからは提供されず、これらがなくても動作します	いいえ、同梱済み

設計による安全性： レイヤー 2（本サーバー）は物理的にバスに接続できません。ネットワーク／バスの依存関係は一切なく — .knxproj を読み取り、閉じ込められたワークスペースにファイルを書き込むだけです。「稼働中のバスには決して書き込まない」という要件は、約束ではなく構造的に強制されます。住宅との実際のやり取りはすべてレイヤー 1（Home Assistant）のみを経由します。

---

これでできること

📐 シナリオ 1 — 仕様からプロジェクトを設計する（仕様 → 実装キット）

プロジェクト仕様（設備スケジュール、ケーブルジャーナル、デバイスリスト）を、完全で検証済みの グループアドレス構造へ、そしてそれを実装するための完全なドキュメント一式へと変換します：

1. デバイスリスト → オブジェクトモデル。 各デバイスは、デバイスライブラリ（decompose_device）を通じて 実際の通信オブジェクトへと展開されます。調光チャンネルは on/off + ステータス + 相対調光（3.007）+ 絶対値（5.001）+ 明るさステータスであり、「1 つの GA」ではありません。床暖房ゾーンは 8 オブジェクト、 パルスメーターは 6 オブジェクトです。
2. プロフェッショナルなロジック層。 素の仕様には、プロジェクトを完全にするものが決して書かれていません： 中央 & ゾーンマクロ、シーン、在室ロジック、空調制御の足場、日射/風シャッター ロジック、漏水→遮断チェーン、天文/気象および日時ソース、あらゆる範囲における予備。この 方法論は、これらの完全性パターンを体系化しています — KNX Association 標準、 公開されたメーカードキュメント、および実際のプロフェッショナルな as-built ETS プロジェクト （匿名化済み）の研究から抽出されたものです。
3. 構造と規律。 3 レベルアドレッシング、ゾーン+機能の命名、コマンド↔ステータスのペアリング、 すべてのアドレスに DPT。
4. 成果物（それぞれ 1 コマンド）：ETS にインポート可能な XML/CSV · Markdown レポート · Home Assistant YAML · 機能受入テストプロトコル · as-built 引き渡しパック （インベントリ、GA マップ、カバレッジ %、Secure ポスチャ、QA 所見、トポロジ SVG）。

完全な方法論：docs/spec-to-structure.md。実際の 14 室の as-built ETS プロジェクトを、 その 42 ページの仕様書のみから再構築することで現場検証済み： 構造的一致率 96 %（662 対 687 GA）、ドメイン分類 10 / 10、検証エラーゼロ — 詳細な記事は**ケーススタディ**にあります。残りの差分は、インテグレーターによる デバイスごとのパラメータ設定であり、これはどの仕様にも書かれません。

🔍 シナリオ 2 — 既存プロジェクトの監査、修復 & 完成

• 読み取り & 分類。 パスワード保護された ETS5/ETS6 .knxproj を xknxproject 経由で解析します。すべての GA をカテゴリ （照明 / シャッター / 空調 / センサー / シーン / エネルギー / 診断）と種別（コマンド / ステータス / センサー）で、DPT + 多言語（EN/DE/RU）の名前キーワードから分類します。GA の目的タグ付け （functional / reserve / logic / scratch）により、意図的なプレースホルダーがエラー リストから除外され、レポートが誤報を出しません（実際の 685-GA プロジェクトで：誤検出エラー 29 → 6）。
• 検証（analyze_all がすべてを実行）：命名 & 構造 · 欠落したステータスオブジェクト （まず ETS-Function ロール、次に名前トークンのペアリング、位置によるペアリング — 1:1 の名前を持つ並列ステータス中間部 — および自己報告型 R+T オブジェクト）· 欠落/不整合な DPT + サブ DPT の健全性（5.001 を持つ「温度」GA はフラグが立てられます）· 相対のみの調光器 · KNX Secure ポスチャ（セキュア vs 平文、混在グループ、キーリングチェックリスト — 鍵素材は 決して読み取られません）· Matter 対応度 · エネルギードメインのカバレッジ。
• 修復、単なる指摘ではなく（suggest_repairs）：名前から DPT を推論し、疑わしい サブ DPT を修正し、空きアドレススロットに欠落したステータス GA を合成し、絶対明るさ GA を追加します。 あくまで提案です — 人間がレビューし、承認された GA が ETS エクスポートに反映されます。実際の 3,646-GA プロジェクトで：145 件の具体的な提案（32 件の DPT 推論、112 件の合成ステータス GA）。
• 作業を完了する：grade_completeness（素の骨組み → as-built スコア）、suggest_names、 diff_projects（2 つの .knxproj リビジョンのセマンティック diff：追加 / 削除 / DPT 変更 / 名前変更 / セキュア変更）、その後レポート、引き渡しパック、テストプロトコルを再生成します。

🏠 シナリオ 3 — スマートホームレイヤーの生成 (Home Assistant)

• エンティティを保守的に組み立て: カバー → カラー / 調光可能ライト (オン/オフ + 明るさ + RGBW/RGB/色温度 + ステータス) → スイッチ → 空調 (現在温度、 目標温度ステータス、運転/コントローラーモード、バルブ値) → センサー/バイナリ。すべてのエンティティには、 デバイスが報告可能な場所に state_address が付与されます — HA は実際の状態を読み取り、決して推測しません。
• レビュー優先: 曖昧なもの (DPT 5.001 — 明るさかブラインド位置か?) は推測されません — 説明付きで review リストに入ります (アクチュエーター依存のカバーフラグ invert_position / 移動時間など、どの .knxproj にもエンコードされていないものを含む)。
• 追加機能: 日付/時刻ブロードキャスト用の expose ブロック (DPT 19.001)、Matter 対応リント、 KNX IoT (Turtle/RDF) セマンティックエクスポート。
• 家のライブコントロールは公式の Home Assistant 統合 (レイヤー 1) に残ります — この サーバーはその設定を準備するだけです。
• 運用コンパニオン: skills/ha-git-backup — デプロイ後の設定の ライフサイクル: /config の実際の git 履歴 (デプロイキー + pre-commit シークレットスキャナー) に加えて、 GitHub Releases への暗号化されたオフサイトバックアップ、毎月のリストア訓練付き。

🧱 シナリオ 4 — 部屋テンプレートから新しいプロジェクトを構成する

• 白紙ではなく部屋から: 6 つの組み込みパラメーター化された部屋テンプレート (寝室、 子供部屋、リビング、キッチン、浴室、廊下) から選択し、basic / comfort プリセットをスロットごとに 選び (1 つの家でコンフォート空調とベーシック照明を混在させることが可能)、compose_rooms が新しいプロジェクトを組み立てます。
• 出力されるもの: 割り当て manifest (メイン = ドメイン、ミドル = ロール、サブは連番)、既存の ジェネレーターによる ETS にインポート可能な GA XML/CSV、デバイスライブラリからのデバイス BOM 提案。
• 実際のリーダーによる検証: 生成された .knxproj は標準の load_project を通じて再読み込みされます — サードパーティプロジェクトに使用されるのと同じパス — そして 4 つのリンターすべて (命名 / 欠落ステータス / DPT / ポリシー) を0 エラー / 0 警告で通過します。
• デフォルトはドライラン、新規プロジェクトのみ。 テンプレート形式は公開契約です (room_templates/SCHEMA.md): 識別子はロケールに依存しない slot_id であり、人間が読む名前ではありません。
• _{R2: 既存プロジェクトへのドッキング + 正確なデバイス選択 — 計画中。}

🧩 基盤 — 成長するデバイスライブラリ

• parse_devices_from_project は正確なベンダーオブジェクトモデルを抽出します — HDL/Ekinex のような ref レベル (ComObjectRef) パブリッシャーを含む — 任意の .knxproj / .knxprod 内のメーカー アプリケーションプログラムから: オブジェクト番号、名前、サイズ、DPT、 C/R/W/T/U フラグ、チャネルごとのブロックストライド — 決定論的に、かつ PII 安全 (ベンダーカタログ データのみ。ファイルのクライアントプロジェクト部分は決して読み取られません)。
• NICKOL_KNX_CATALOG をカタログに向けると、decompose_device は汎用レシピではなく正確な モデル (catalog-exact) で応答します — カタログは、あなたが投入するプロジェクトと製品データベースから オンデマンドで成長します。
• ベンダーが宣言された DPT なしで出荷するオブジェクトは、正直に unverified のままです — 決して推測されません。

すべての書き込みはワークスペースディレクトリ (NICKOL_KNX_WORKSPACE、デフォルト ./knx-workspace) にのみ行われます。それ以外への書き込みは拒否されます。

---

インストール

Python 3.10+ が必要です。

git clone https://github.com/NickoScope/nickol-knx-mcp.git
cd nickol-knx-mcp
python3 -m venv .venv && source .venv/bin/activate
pip install -e .

依存関係: mcp>=1.10、xknxproject>=3.8、PyYAML>=6.0。

Debian/Ubuntu で、pip が externally-managed environment について警告する場合は、venv を使用する (上記のように) か、pip install -e . --break-system-packages を実行してください。PyJWT が競合する場合は、最初に pip install mcp --ignore-installed PyJWT を実行してください。

確認:

python tests/test_pipeline.py     # synthetic 16-GA project, end-to-end smoke test
nickol-knx-mcp                    # start the MCP server (stdio)

---

Claude への接続

Claude Desktop

examples/claude_desktop_config.json は nickol-knx + filesystem + git + home-assistant をセットアップします。 最小限のフラグメント (macOS の設定パス: ~/Library/Application Support/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "nickol-knx": {
      "command": "nickol-knx-mcp",
      "env": { "NICKOL_KNX_WORKSPACE": "/path/to/your/knx-workspace" }
    }
  }
}

Claude Code

claude mcp add nickol-knx \
  -e NICKOL_KNX_WORKSPACE="$HOME/knx-workspace" \
  -- /absolute/path/to/.venv/bin/nickol-knx-mcp

任意で、CLAUDE.md をプロジェクトルートに配置してください。これは AI クライアントが読み取るプレーンなプレイブックです（設計ルール、安全ルール、3 レベルの GA 構造、コマンドとステータスのペアリング、DPT の規律、命名、KNX Secure キーリングの取り扱い、および推奨ワークフロー）。サーバーはこれを必要としません。解析、チェック、生成はすべて MCP サーバー内のコードとして実行されます。

---

MCP ツール (32)

読み取り

ツール	目的
load_project(path, password?, language?)	.knxproj を解析し（読み取り専用）、キャッシュします
load_ga_export(path)	ETS グループアドレスのエクスポート（ga-export/01 XML、例: ETS や TapPlan から）をデバイスのないプロジェクトとして読み込みます
list_group_addresses(category?, kind?)	分類とフィルター付きで GA を一覧表示します
get_devices()	デバイスとその通信オブジェクト
get_topology()	トポロジー（エリア / ライン / デバイス）
explain_ga(address)	1 つの GA の来歴: なぜこのように分類されたのか — 各判断の根拠と信頼度ティア（authoritative ETS 機能 > structural DPT > heuristic 名前）、ステータスがどのようにペアリングされたか、および競合（名前は「AC」、DPT は照明 → contested）

検証

ツール	目的
check_naming(name_regex?)	命名 / 3 レベル構造を検証します
check_missing_status()	ステータスオブジェクトを欠くアクチュエーター
check_dpt()	欠落 / 不整合な DPT + サブ DPT の妥当性（temp→9.001、power→14.056…）
check_topology()	トポロジーの容量 + 個別アドレスの妥当性（TP1 64/セグメント、256/ライン、有効かつ一意な A.L.D、カプラーの存在 — KNX ハンドブック）
check_secure()	KNX Data Secure の態勢 + キーリング引き継ぎチェックリスト
check_matter()	Matter 対応リント（どの機能が Matter クラスターにラウンドトリップするか）
check_energy()	メータリング / エネルギーの DPT チェック + PV / バッテリー / EVSE のスキャフォールド
analyze_all(name_regex?)	すべてのチェックを一度に実行します
check_policy(profile_path?, write_example_to?)	プロジェクトポリシープロファイル（あなたのメイングループ分類、命名、ペアリング）に対して検証します — または、プロファイルがない場合はプロジェクト自体から推論された分類に対して検証します。普遍的な標準ではなく、あなたの慣例から逸脱した GA をフラグします。write_example_to は、読み込まれたプロジェクト自身のメイングループからシードされたサンプルプロファイルを書き出します（プロジェクトに存在しないメインは決してリストされません）

修復と設計

ツール	目的
suggest_repairs()	フラグを立てるだけでなく修正を提案 — DPT を推論し、ステータス / 明るさの GA を合成します
suggest_names()	命名衛生の提案
decompose_device(order_number, channels?)	デバイス → GA 分解: ローカルカタログ（NICKOL_KNX_CATALOG）からの正確なベンダーモデル、または汎用レシピ
list_device_recipes()	組み込みデバイスライブラリ（Zennio + ABB ファミリー）
parse_devices_from_project(path, output_path?, password?)	.knxproj/.knxprod 内のアプリケーションプログラムから正確なデバイスオブジェクトモデルを抽出 → デバイスライブラリ YAML（ローカルカタログに供給）
check_device_parameters(path, password?, min_group?)	デバイス間パラメータ QA: 同一の N 個の兄弟デバイスと ETS パラメータが異なるデバイスを見つけます（はみ出したサーモスタット / センサー） — clear_outliers（おそらくミス）+ split_configs（バランスの取れたバリアント、要レビュー）
grade_completeness()	プロジェクトを評価します: 裸のスケルトンか、実施工どおりか
diff_projects(path_a, path_b, …)	2 つの .knxproj バージョン間のセマンティック差分
生成
ツール	目的
------	---------
generate_ha_package(output_path?)	HA KNX YAML(カラー + 空調 + エクスポーズ)+ レビューリスト
generate_ets_group_addresses(fmt="xml"|"csv", output_path?)	ETS にインポート可能な GA
generate_handover_pack(output_dir?)	as-built 引き継ぎ: インベントリ、GA マップ、カバレッジ、Secure、QA、topology.svg
generate_test_protocol(output_path?)	機能受け入れプロトコル(コマンド → 期待ステータス)
generate_knx_iot(output_path?)	KNX IoT セマンティックエクスポート(Turtle/RDF)
project_report(output_path?, name_regex?)	Markdown レポート
workspace_info()	ワークスペースパス + 安全性の保証

ルームライブラリ(R1 — ルームテンプレートから新しいプロジェクトを構成)

ツール	目的
validate_room_template(template?, path?)	ルームテンプレート(組み込みの slot_id またはカスタム YAML)を R1 スキーマに対して検証します
compose_rooms(rooms, language="ru", project_name?, output_dir?, dry_run=true)	ルームのリストから新しいプロジェクトを構築 → 割り当て manifest、ETS GA XML/CSV、デバイス bom 提案。生成された .knxproj は標準ローダーによって再読み込みされ、lint されます(0 エラー / 0 警告)。新規プロジェクトのみ、デフォルトではドライラン。

---

典型的なワークフロー

1. load_project → 自分の .knxproj を指定します(保護されている場合は + パスワード)。
2. analyze_all または project_report → 検出結果を確認します。まず人間によるレビューを行います。
3. ETS で命名/DPT/ステータスを修正します(生成された GA をインポートするか、手動で)。
4. generate_ets_group_addresses(fmt="xml") → 不足している GA を ETS にインポートします。
5. generate_ha_package → YAML を Home Assistant に配置します。review 項目は手動で解決します。
6. すべて(.knxproj エクスポート、HA 設定、アドレススキーマ)を Git で管理します。
7. 実際の住宅に触れるのは Home Assistant MCP(レイヤー 1)を通じてのみ行います。

---

制限事項(正直なところ)

• コマンド/ステータスおよびカテゴリ分類はヒューリスティックです(DPT + 名前 + ETS Functions)。Functions がなく 非標準の名前を持つ乱雑なプロジェクトでは、偽陰性/偽陽性が発生する可能性があります — だからこそレポートは常に人間によるレビューを前提としており、曖昧さは設定ではなく review に送られます。
• DPT 5.001 は構造的に曖昧です(明るさ vs 位置)。これはキーワードによって曖昧性が解消されます — 非標準の命名では再確認してください。
• HA ジェネレーターは保守的です。誤ったエンティティを出力するよりも、項目を review に送ることを選びます。
• サーバーはバスに決して書き込まず、ETS と直接通信することもありません — ETS とのやり取りは GA のファイル インポート/エクスポートのみです。
• 合成デモプロジェクトおよび実際の数千 GA の ETS5/ETS6 プロジェクト (匿名化済み)で検証されています — ただし実際の .knxproj ファイルは非常に多様であり、まだベータ版です。したがって テスター募集を行っています。

---

🔒 安全モデル

• 構造的にバスアクセスなし。 依存関係ツリーにネットワークやバスのライブラリはありません。 workspace_info() は bus_access: false を報告します。
• あなたのプロジェクトに対して読み取り専用。 .knxproj に触れる唯一のモジュールは project.py であり、それも 読み取りのみを行います。
• 書き込みの制限。 すべての出力は NICKOL_KNX_WORKSPACE に制約されます。その外側のパスは拒否されます。
• 敵対的なプロジェクトファイルに対する強化。 .knxproj は信頼できない XML の ZIP であるため、解析は safexml.py を通じて実行されます。DTD/エンティティ XML は拒否され(billion-laughs / XXE)、アーカイブは サイズ / エントリ / 解凍比率の上限に対して事前チェックされ、パストラバーサル名は拒否されます(zip 爆弾対策)。
• 人間参加型(Human-in-the-loop)。 project_report を生成し、ETS にインポートしたり Home Assistant にデプロイする前にレビューしてください。

セキュリティ上の問題を見つけましたか? SECURITY.md をご覧ください。

---

パッケージ構成

nickol-knx-mcp/
├── nickol_knx_mcp/
│   ├── dpt_map.py        # DPT → category / kind / HA platform / value_type
│   ├── project.py        # the ONLY module that reads .knxproj (read-only)
│   ├── safexml.py        # hardened ZIP/XML parsing of untrusted .knxproj (zip-bomb / XXE defense)
│   ├── pairing.py        # command↔status pairing by name tokens
│   ├── analyze.py        # naming / missing-status / DPT checks
│   ├── generate_ha.py    # Home Assistant KNX YAML generation
│   ├── generate_ets.py   # ETS XML + CSV generation
│   ├── report.py         # Markdown report
│   ├── room_library.py   # Room Library R1 — compose a new project from templates
│   ├── room_templates/   # built-in room YAML templates + SCHEMA.md (public contract)
│   └── server.py         # FastMCP server, 32 tools, confined writes
├── tests/test_pipeline.py
├── examples/claude_desktop_config.json
├── skills/
│   └── ha-git-backup/    # optional ops skill for your AI client: HA backup (git history + encrypted offsite)
├── CLAUDE.md             # optional playbook for your AI client (not part of the server)
├── pyproject.toml
└── README.md

---

コントリビューション

テスターとコントリビューターを大歓迎します — 特に実際のプロジェクトでのテストレポートを歓迎します。詳しくは CONTRIBUTING.md とイシューテンプレートをご覧ください。

ライセンス

MIT © 2026 Nikolay Miroshnichenko

KNX Association とは提携しておらず、承認も受けていません。「KNX」および「ETS」は KNX Association cc の商標です。これは独立したコミュニティツールです。