diff --git a/docs/index.html b/docs/index.html index 8430928..bcee0b6 100644 --- a/docs/index.html +++ b/docs/index.html @@ -139,6 +139,7 @@
nickol-knx-mcp
What + Scenarios Demo house Dashboard The brain @@ -179,11 +180,48 @@

🔒 No bus access

Zero networking/bus libraries in the dependency tree. bus_access: false — structural, not a promise.

-

🧩 25 MCP tools · 3 scenarios

1 · Design from a spec: device list → exact object models → professional logic layer → full implementation kit (ETS XML/CSV · report · HA YAML · test protocol · handover pack) — field-checked at ~92% structural match vs a real 3,600+ GA as-built project. 2 · Audit & repair: validate (naming · DPT & sub-DPT · status · Secure · Matter), get concrete fixes (145 proposals on a real project), grade completeness, diff versions. 3 · Smart home: assembled HA entities (colour + climate) reading real state. All read-only.

+

🧩 25 MCP tools

Validate (naming · DPT & sub-DPT · status · KNX Secure · Matter) · repair (propose fixes, not just flag) · decompose devices into GA recipes or exact vendor models · diff two versions · grade completeness · generate HA YAML, ETS XML/CSV, handover pack, test protocol & KNX IoT. All read-only — see the three scenarios ↓.

🌍 EN / DE / RU

Classifies by DPT + multilingual name keywords. Validated on ETS 4.2 / 5.0 / 5.5 / 6 fixtures, a real signed ETS6 round-trip, and a 685-GA Zennio project (false errors there: 29 → 6).

+ +
+
What you can do
+

Three scenarios, one read-only toolchain

+

From a blank specification to a commissioned, smart-home-connected project — or straight + into an existing .knxproj that needs checking and finishing.

+
+

📐 1 · Design from a spec

Equipment list → real object models per device + (a dimmer channel is 5 objects, not one GA; a floor-heating zone is 8) → the professional + logic layer a bare spec never mentions: central & zone macros, scenes, presence logic, + sun/wind shutters, leak→shut-off chains, astro/meteo & date-time, reserves. Out comes the + full implementation kit: ETS-importable XML/CSV · report · HA YAML · acceptance test + protocol · as-built handover pack. Field-checked: reconstructing a real 3,600+ GA as-built + project from its spec alone → ~92% structural match, zero validation errors.

+

🔍 2 · Audit, repair & finish

Load any ETS5/ETS6 + .knxproj (password-protected too) → analyze_all: naming · missing status + objects · DPT & sub-DPT sanity · KNX Secure posture · Matter readiness. Then + concrete fixes, not just flags: inferred DPTs, synthesised status GAs, absolute-brightness + additions — 145 proposals on a real 3,646-GA project. Grade skeleton→as-built, diff two + revisions, regenerate the report, handover pack and test protocol.

+

🏠 3 · The smart-home layer

Assembled Home Assistant entities — + colour/dimmable lights (RGBW · RGB · CCT + statuses), climate (setpoint · mode · + valve), covers, sensors — every entity reading real device state, never assuming it. + Anything ambiguous goes to a review list instead of being guessed. Plus a date/time + expose block, Matter lint and a KNX IoT (Turtle/RDF) semantic export.

+
+

🧩 The foundation — a growing device library

+

parse_devices_from_project extracts exact vendor object models (object numbers · + DPTs · C/R/W/T/U flags · per-channel strides) from the manufacturer application programs inside any + .knxproj/.knxprod — deterministic and PII-safe (vendor catalog data only). + Point NICKOL_KNX_CATALOG at your catalog and decompose_device answers with + the exact model instead of a generic recipe; undeclared DPTs stay honestly + unverified. The design methodology is distilled from the KNX Association standard, + public manufacturer documentation and the study of real professional as-built ETS projects + (anonymised).

+
+
The demo house