A responsibility drawing is not a wiring drawing

You have run the ETS preflight in Part 4. The obvious next move is to open ETS, point it at a KNXnet/IP endpoint and see what answers. This series does not do that here, and the reason is worth stating plainly rather than treating as caution for its own sake.

Everything in this guide is bounded by pinned sources: the KNXD Add-on 0.6.1 managed INI template, the Home Assistant KNX documentation snapshot, and a locked Home Assistant Core version manifest. Those sources support what a role is called and what it is documented to be responsible for. They do not support any claim about what is running, what is reachable, or what happened on a bus. Part 5 is where that distinction gets drawn on paper, once, so that it does not have to be argued about later while a blind is halfway down.

So three prohibitions run across all three chapters in this part, and none of them are softened by the fact that you are only drawing. One of the three is stricter in Chapter 12 than it is in Chapters 13 and 14, and the difference is not a wording accident — read it carefully before the four-card sheet.

Separating four words that get used as though they were one

The first sheet takes about fifteen minutes and needs a blank sheet of paper, four blank cards, and your offline review sheet from Chapter 11. Before anything goes on the paper, the boundary this chapter draws around itself:

That is the sheet that answers the temptation from the previous section. The move that feels productive right now — open ETS, point it at a KNXnet/IP endpoint, see what answers — is the one this chapter forbids outright, and it stays forbidden for the whole fifteen minutes. Title the paper:

Each card carries the role name and two columns, and nothing else.

Those two columns are the whole discipline of the sheet. The six steps below give the exact wording each card gets.

Then one sentence goes on all four cards, identically:

And the KNX bus goes outside the picture, with its own marking:

flowchart LR
  subgraph P["Concept Map on Paper"]
    direction LR
    A["ETS card"] ---|"concept
handover"| B["KNXnet/IP
card"]
    B ---|"concept
handover"| C["Listener
card"]
    C ---|"concept
handover"| D["Interface
card"]
  end
  Z["KNX bus, left outside the diagram.
No evidence of results in this part"]

Six steps, in this order.

1. Step 1

   Put down the ETS card

   Responsibility reads only “Project data is managed by authorized roles”. The Cannot prove column reads “This chapter provides no evidence of operation.”

2. Step 2

   Put down the KNXnet/IP card

   Responsibility reads only “the network-side vocabulary in the pinned template”. Cannot prove reads “No execution status”.

3. Step 3

   Put down the listener card

   Responsibility reads only “service role waiting for handoff from other software”. Do not claim that it is currently running.

4. Step 4

   Put down the interface card

   Responsibility reads only “data transfer boundary”. Do not add hardware, names or settings.

5. Step 5

   Draw the lines of responsibility

   Write beside each line only “concept handover”. No directions, no arguments, no action verbs. A line that starts to read like a procedure has stopped being a responsibility line.

6. Step 6

   Close the whole picture

   Underneath the drawing, write: “Concept on paper classified; all implementation layers and KNX bus results unproven”. Then write STOP outside the diagram, meaning any ETS, network, service or KNX action stops here.

A candidate topology, drawn so it cannot be read as the only one

The second sheet is another fifteen minutes, another blank page, five blank cards. No Home Assistant, no KNXD, no ETS open on the desk; nothing connected, nothing probed, nothing reloaded, no environment data entered.

This diagram carries a risk the first one does not. Five boxes in a line look like a stack, and a stack looks like a rule. It is not one. The arrangement is this tutorial's candidate responsibility topology — not a universal architecture, not a proven live path, and not a claim that the Home Assistant KNX integration must go through KNXD, or through the interface, or through anything else.

The five cards are drawn as five empty boxes, and each one gets two columns before a word of content goes in. The column headers are fixed:

The cards hold role names only: no host, address, port, secret, project or device data. Every card starts life with Status Unknown filled in first, and every card carries the same sentence:

flowchart TD
  subgraph HA["Home Assistant KNX integration boundary"]
    direction LR
    I["Integration card:
integration responsibilities
inside Home Assistant"] ---|"conceptual
responsibility"| X["xknx card:
library and KNX logic
used inside this boundary"]
  end
  HA ---|"candidate responsibility"| K["KNXD card:
standalone daemon, not an
inherent layer of the integration"]
  K ---|"candidate responsibility"| N["Interface card:
keeps the handover boundary"]
  N ---|"candidate responsibility"| B["KNX bus card:
onsite network responsibility,
no evidence of results here"]

Six steps again, and the last one is the one that keeps the drawing honest.

1. Step 1

   Put down the integration card

   Under Source Supported, write “Manage integration responsibilities within Home Assistant”. Under Cannot Prove, add “No evidence that it was added or loaded.”

2. Step 2

   Put down the logic card

   Under Source Supported, write “xknx library/KNX logic is located within the Home Assistant KNX integration boundary”. Under Cannot Prove, add “Declaring dependencies does not prove that it is operational.”

3. Step 3

   Put down the KNXD card

   Under Source Supported, write “standalone KNXD daemon; not an inherent layer of the Home Assistant KNX integration.” Do not add daemon or listener status to the diagram — that status stays Status Unknown.

4. Step 4

   Put down the interface card

   Under Source Supported, write “Keep handover boundaries”. Do not include the interface type, its name, or any live-site status.

5. Step 5

   Put down the bus card

   Under Source Supported, write “Onsite network responsibility; no evidence of results in this chapter.”

6. Step 6

   Mark the candidate relationships

   No directional arrows. Each line is marked only “Responsibility of this Teaching Candidate”, and the diagram closes with “Not a common or proven path; no settings, connections, or success claims.”

The one confusion this whole sheet exists to prevent

Two names sit close together in every thread on this subject, and they are not the same thing.

Two consequences follow, and both matter more on a commissioning job than they look on paper. KNXD being present does not mean the integration is present; the two have different lifecycles and different evidence. And the five cards being drawn in a row does not mean the integration must go through KNXD — that inference is exactly what the wording on the cards is written to block.

There is a second reason to keep the cards apart, and it is about the sources rather than the software. The Home Assistant side of this part rests on two pinned artifacts with genuinely different scopes, and this guide keeps them in separate columns for that reason.

flowchart LR
  subgraph L["The documentation snapshot"]
    direction LR
    L1["knx.markdown,
pinned snapshot"] ---|"supports"| L2["The configuration concepts
present in that file"]
  end
  subgraph R["The Core version manifest"]
    direction LR
    R1["knx/manifest.json,
Core 2025.1.0"] ---|"supports"| R2["That version's integration registration
and xknx dependency boundary"]
  end
  Z["Correspondence not proven. The two columns do not combine
into a settings format, an API contract or a compatibility guarantee"]

Put the two side by side and you have two facts. You do not have a third fact about how they line up. The juxtaposition does not prove that the versions correspond exactly to one another, and it does not prove that the package has been loaded, that the integration has been established, or that the KNX bus has produced any result. On the worksheet, that pair keeps two separate columns and the notation “Correspondence not proven”.

Leaving the blanks safely is the deliverable

The third sheet takes about twenty minutes and is the one people find hardest, because it looks like a form and forms invite filling in. It is not a form to fill in. Completion here means every blank is left blank for a stated reason. Title it with the marking it has to carry:

Draw the header before you write anything under it. Only these governance columns are used.

flowchart TD
  A["A cell on the offline worksheet
is still empty"] --> B{"Does the cell want a host, endpoint, address,
secret, device identifier, YAML, an API shape,
or anything else that could be pasted?"}
  B -->|"yes"| S["Stop the paper process.
Write the stop reason in the cell and hand it
to the independent approval process"]
  B -->|"no"| C{"Is it one of the governance columns:
requirement, role, classification,
source boundary, review status?"}
  C -->|"no"| S
  C -->|"yes"| E["Write the governance value.
Every other cell keeps the fixed text
To be supplied by an authorized role"]

Six steps, and step six is not optional.

1. Step 1

   Write the worksheet title

   Mark it “Offline placeholder worksheet; cannot be imported, pasted, or executed.” The marking travels with the sheet, so anyone who picks it up later reads the boundary before they read the rows.

2. Step 2

   Create the requirement column

   Use only general classifications — connection responsibilities, integration responsibilities, data-model responsibilities, approval responsibilities. Do not simulate fields.

3. Step 3

   Add the placeholder text

   Fill in only “To be supplied by an authorized role” in each column. No format hints, no default values, no example values.

4. Step 4

   Add the data categories

   Mark each row public, controlled, secret or unknown. Controlled, secret and unknown are not allowed on the public sheet.

5. Step 5

   Separate the source column

   Note the concepts supported by the file snapshot and the integration boundaries supported by the Core version metadata separately. Do not write either of them up as a compatibility guarantee.

6. Step 6

   Do the offline review, then hand it on

   Confirm there is no YAML, no API structure, no connection detail, no actual value and no action statement anywhere on the sheet. Then hand it to another reviewer. A worksheet reviewed only by the person who wrote it has not been reviewed.

The drift you will actually meet, and the wording that pulls it back

None of these three sheets fail dramatically. They fail by drifting a word at a time, usually because somebody helpful wants to make the drawing more useful. Here is what that drift looks like on each sheet, and the correction that goes with it.

Then there is the category that is not drift at all, but a direct request. Five of them come up, and all five end the same way.

• “Just confirm it with a live action.” Mark it STOP. No alternative method gets added in its place.
• “Add the connection information so the drawing is useful.” Stop. Environmental information is not collected for paper drawings.
• “Let me see the running settings.” Stop the offline process and hand over the explicitly approved read-only scope evaluation. That is a different, separately approved piece of work.
• “Sign off the integration while you are in there.” Stop. There are no setup or test authorizations in these chapters, so there is nothing to confirm and nothing to sign.
• “Can we just test the connection?” Stop. These chapters provide no testing or implementation authorization — and no bus verification either: no group reads or writes, no telegrams, no physical control. Chapter 12 prohibits group reads as such, so “I will only read one, by hand” is not the exception it sounds like.

The ones that come up on every job

Where to go from here