The middle box is where a wrong category becomes a wrong write

You have used ETS. You have terminated bus cable, and you have watched a commissioning go sideways because one line in a spreadsheet said something the installation did not. That experience is exactly the reason this part of the guide starts with a pencil rather than an editor.

The daemon sits between two worlds that do not speak to each other. On one side is the interface holding your twisted pair. On the other is a network full of software that expects to reach KNX over IP. Home Assistant is one of those pieces of software: its KNX integration talks to a KNXnet/IP endpoint, not to a serial adapter and not to the bus. Something has to hold the physical interface open and present it on the network, and that something is the daemon this guide is about.

Three earlier chapters — the four roles, the responsibility path, and the KNXnet/IP listener — established who owns what. Chapters 9, 10 and 11 take that and turn it into three working documents. All three are offline exercises, and that is a deliberate limit rather than a shortcut.

The limit this guide operates under

Every chapter in this series repeats the same boundary, and it is worth stating plainly once here rather than reading past it in every chapter. This site does not add the repository, install it, or start it. The reason given in the sources is specific: there is no approved immutable artifact or image digest and no source-to-build proof, so all execution is blocked.

That block is not decoration. It shapes what these three chapters can and cannot claim.

flowchart TD
  A["Chapters 9, 10 and 11:
three sheets of paper,
roughly 55 minutes"] --> G{"Does the step touch
a real system?"}
  G -->|"no"| P["Do it on paper.
Category words only,
no live values"]
  G -->|"yes"| S["Blocked on this site: no approved immutable
artifact or image digest, and no source-to-build proof"]
  S --> S1["Repository, install,
start or stop"]
  S --> S2["Writing or applying
the INI"]
  S --> S3["Diagnostic mode,
local logs"]
  S --> S4["ETS, the interface,
the bus"]

So across all three chapters, the following are prohibited, and they are prohibited in every one of them rather than in only the ETS chapter: connecting the interface or the bus, group reading, group writing, telegram transmission, ETS programming or downloads, and physical control. Paper comparisons cannot prove a daemon, a listener, an integration or a bus result, and the chapters say so in those words.

Chapter 9: sort the settings, do not fill them in

The bottom line of Chapter 9 is narrow and worth quoting before anything else: draw only an offline responsibility map and sort settings into labeled drawers. Do not enter values, do not write files, and do not apply settings. You are not modifying the INI, and you are not starting or stopping the Add-on. You are reading the pinned version of the managed template, offline, and deciding which component owns which kind of data.

Formally, this is the relationship between INI sections, options, and managed-template responsibilities. Options define input categories. Sections organize related settings. Managed templates are source material. None of the three represents a live result. A daemon is an execution role, and this chapter does not verify it.

What you need in front of you

A blank sheet of paper, and the responsibility classifications you produced in Chapters 7 and 8. No configuration files. No execution data. Draw five empty frames: the first four are the responsibility drawers, and the fifth is for evidence still to be supplied. Put only category words in each box.

Three lines go at the top of the sheet before you sort anything, and they are the lines that keep somebody else from misreading the finished map two weeks later:

One more rule about the paper itself. Version differences belong under Versions and compatibility, and you do not mix content from other versions into this map. If a piece of information in front of you contains anything that identifies an environment, do not copy it across. Record only that it requires confirmation by authorized personnel at a controlled location.

flowchart LR
  S1["Fixed input schema
Add-on 0.6.1 config.yaml"] --> P["Sort by responsibility.
Category words only.
No values."]
  S2["Managed INI template
knxd/rootfs/etc/knxd.ini"] --> P
  P --> D1["Main responsibility:
overall connection
and coordination"]
  P --> D2["Service responsibility:
waiting for handover
from other software"]
  P --> D3["Record responsibility:
message levels and
record categories"]
  P --> D4["Interface responsibility:
device, filter and
network inputs, as categories"]
  P --> D5["Pending evidence:
anything the pinned
sources cannot place"]

The six moves, in order

1. Step 1

   Put the main responsibilities in first

   Overall connection and coordination roles go into the main drawer. Do not fill in any value. This drawer is the one people are most tempted to write into, because the coordinating role feels like the one that "does" something. It still gets category words only.

2. Step 2

   Then the service responsibility

   Roles that wait for a handover from other software go into the service drawer. Sorting a role into this drawer does not infer that the service exists. You are describing a category of responsibility, not reporting that something is listening.

3. Step 3

   Separate the documentation responsibilities

   Message levels and record categories go into the record drawer. Do not copy local logs into it. The drawer holds the names of categories of record, not any record.

4. Step 4

   Separate the interface responsibilities

   Device, filter and network inputs go into the interface drawer as categories only. Do not write paths, and do not write endpoints. A card in this drawer says "a device input belongs here", not which device.

5. Step 5

   Mark the source boundary on every card

   Each category card records whether it came from the input schema or from the managed template. Do not write two sources as though they were the same thing. The next section of this article is entirely about why that distinction matters.

6. Step 6

   Close with a limited conclusion

   Two endings are allowed, and only two: Offline responsibilities have been compared, or There are still gaps. Do not write deployed. Do not write ready for use. Neither of those is a conclusion this exercise is capable of supporting.

Checking your own sheet

The finished product is a responsibility map with no live values in it. It says which category owns each kind of data. It says nothing about what any system is currently doing. Four things confirm it:

• Five drawers are present — main, service, record, interface, and pending evidence.
• Input schemas and managed templates are labeled separately on every card.
• No host, address, port, path, serial number, secret or live setting appears anywhere on the sheet.
• Nothing was written, applied, installed, started or stopped, no execution result was read, and no bus or integration result is declared.

A schema and a template are different kinds of evidence

Step 5 above gets its own section. Two pinned sources feed the responsibility map, they look similar on a screen, and merging them turns a careful map into a misleading one.

The first is the fixed input schema for Add-on 0.6.1. It describes the data type of an option, whether that option can be omitted, and whether the source declares a default. It is a source input contract.

The second is the fixed managed INI template. It describes the roles of the main, service, record and interface sections. It is managed source material.

flowchart TD
  A["Fixed input schema
Add-on 0.6.1 config.yaml"] --> A1["Data type, whether an option
can be omitted, and whether the
source declares a default"]
  B["Fixed managed INI template
knxd/rootfs/etc/knxd.ini"] --> B1["The main, service, record
and interface section roles"]
  A1 --> C["Supported together:
an offline comparison
of responsibilities"]
  B1 --> C
  C --> D["Not supported: how the template is generated,
what the current file holds,
read results, or applied results"]

Together, the two support offline comparison of responsibilities. Together, they still do not support any claim about how the template is generated, what the current file on a system contains, what a read returned, or what an apply did. Those are four different kinds of evidence and none of them is in the envelope.

The same asymmetry explains a question that comes up every time somebody first reads the managed template: does its completeness say anything about the settings currently on a system? No. The template and the current file are different kinds of evidence. One is pinned source material. The other is a live artifact this guide does not read.

Chapter 10: the checklist that stops evidence being promoted

Chapter 10 builds a handover checklist. Every checkpoint on it represents a documentation category — not a local observation, and not a KNX bus result. It takes about 20 minutes, it needs Chapter 9's map plus a blank classification sheet, and it needs no hardware and no logs at all.

The boundary here is tighter than it looks, so read it once slowly. Do not enable diagnostic mode. Do not read local logs. Do not access hardware. Do not restart services. The states you write on the table are category names. They are not observations. And telegram transmission and physical control are prohibited as methods of verifying a driver — that is called out explicitly, because reaching for the bus to settle a driver question is exactly the reflex this chapter exists to interrupt.

The four checkpoints are the program, the driver, the interface and the KNX bus. Each layer needs its own evidence. This chapter establishes the categories and collects no local evidence whatsoever.

flowchart TD
  A["Station 1
Program"] -->|"does not prove"| B["Station 2
Driver"]
  B -->|"does not prove"| C["Station 3
Interface"]
  C -->|"does not prove"| D["Station 4
KNX bus"]
  A --- A1["Pinned document
names the role"]
  B --- B1["Driver family and
failure boundary,
as documented"]
  C --- C1["Category name only"]
  D --- D1["No evidence in this chapter"]

Setting the sheet up

Draw four handover boxes — program, driver, interface, bus — and divide each into two columns. The left column is Pinned Document Description. The right column is Still Unable to Infer. Then four rules about what may go on it:

• Sources are locked versions of pinned INI files only. Nothing else is admissible on this sheet.
• Category labels only. Never write "observed on this system" or "occurred on site."
• No paths, endpoints, addresses, hardware names, serial numbers or log fragments.
• The bus column always stays "No evidence of this chapter". It is not left blank because you ran out of time. It is filled in with that phrase because that is the accurate answer.

Only three status labels are used, and they classify source content rather than describing anything that happened:

None of those three is observing a start, a stop, a retry, or a hardware reaction. If the data in front of you came out of an execution environment, it does not go on this table at all. Handle it separately under the safe log-sharing guidance, and do not rewrite it as a source claim for this chapter.

The six moves, in order

1. Step 1

   Draw the four stations first

   Program, driver, interface, bus — in that order. Write only the name of the responsibility. Nothing else goes down until all four boxes exist, because the shape of the sheet is what stops the later steps from wandering.

2. Step 2

   Classify the file relationships

   Every responsibility that a pinned source cites goes in the document-supported column. Placing it there does not claim that any setting has been loaded.

3. Step 3

   Classify the activation semantics

   Where the pinned source describes driver settings and failures, that description goes in the documented-boundary column. Do not write that the system has started, and do not write that it has failed. You are recording what a document says about a version, not what a machine did.

4. Step 4

   Block the interface inference

   Noting a driver family name does not prove that the interface exists, that it is compatible, or that it is available. Write the block down on the sheet rather than keeping it in your head.

5. Step 5

   Block the bus inference

   Note explicitly that neither the program class nor the driver class can prove a telegram, a group operation, or any bus result. This is the line the whole checklist is built around.

6. Step 6

   Complete the handover form

   The conclusion is one of two phrases: Source classification has been completed, or Insufficient evidence. Do not include a local diagnostic conclusion, because you did not perform a local diagnostic.

Checking your own sheet

• Four checkpoints exist — program, driver, interface and bus, divided as four separate stations.
• Every status on the sheet is a source classification, not a local observation.
• No logs, devices, addresses, paths, endpoints, serial numbers or live values made it onto the table.
• Nothing was upgraded — no startup or failure semantics were promoted into driver, hardware, interface, bus or integration results.

Chapter 11: write down the never-automate list while it is still cheap

Chapter 11 is the shortest of the three — about 15 minutes — and the one with the most consequence attached to it. You complete one offline review form. The table contains categories and no engineering information. You will not start an ETS project, and you will not perform any KNX action.

What you need is a blank review sheet and the names of the designated responsible roles. No ETS. No project files. No site data. And the prohibitions are stated without any softening: do not open ETS, do not view real projects, and do not copy individual addresses, group addresses, project names, device names, hosts, endpoints, credentials or any other identifying information.

The five lines that are never automated

This is the part of the whole article that should survive if nothing else does. Five categories are marked as never automated, and the source is explicit that testing is not an exception:

Group reading looks like the harmless one on that list, and it is the one people ask to be let off. The answer in the source is flat: group reading is never automated and there are no test exceptions. A test project is still a project on a bus.

What goes in the worksheet

Build a worksheet that contains no live values. Five fields, and nothing else:

Do not attach project files, screens, exported data or logs to the sheet. Where an authoritative value is genuinely needed, it is checked only in a controlled location by an authorized role, and the public table still keeps nothing but the classification.

Four results, and no fifth

The entire table uses four results. They describe the status of the review. They do not describe the status of ETS, the network, the interface or the bus.

flowchart TD
  A["One line on the
ETS preflight sheet"] --> B{"Is it programming, a download,
a group operation, a telegram
or physical control?"}
  B -->|"yes"| S["STOP
Never automated.
Testing is not an exception."]
  B -->|"no"| C{"Does a pinned source
document this responsibility?"}
  C -->|"yes"| D["Classification completed"]
  C -->|"no"| E{"Would filling it in need a real
value from a controlled location?"}
  E -->|"yes"| F["Pending authorization
confirmation"]
  E -->|"no"| G["Not applicable"]

The six moves, in order

1. Step 1

   Write down the purpose of the review

   The purpose line reads Offline Responsibility and Approval Classification. Do not write an execution goal. A sheet whose stated purpose is "get ready to commission" has already lost the argument it was written to win.

2. Step 2

   Assign the four types of responsibility

   Create a column for each: ETS project, Add-on settings, approval, and de-identification review. Fill in the role and nothing else.

3. Step 3

   Mark the source status

   For each column choose one of exactly three: documented in a pinned source, pending authorization confirmation, or not applicable. Do not copy an engineering value in to support the choice.

4. Step 4

   Add the prohibited categories

   Mark programming, downloads and telegrams as STOP. Mark every group operation as prohibited. Physical control is prohibited. Write all five down even when they seem obvious — the sheet exists so that the obvious is still on paper at the moment somebody is in a hurry.

5. Step 5

   Check the identification data

   Read the sheet back and verify there are no addresses, names, endpoints, devices, serial numbers, secrets or project contents on it. This is a separate pass, done after the writing, not a thing you trust yourself to have done while writing.

6. Step 6

   Close with a limited conclusion

   The result is one of the four categories: completed, pending authorization confirmation, not applicable, or STOP. Do not claim that the ETS, the interface or the bus is ready. Nothing on this sheet could support that claim.

Checking your own sheet

• Only the four permitted categories appear — complete, pending authorization confirmation, not applicable, and STOP.
• Four responsibilities are separated — the ETS project, the Add-on configuration, approval, and evidence.
• No individual addresses, group addresses, names, endpoints, devices, serial numbers, secrets or project contents are in the table.
• All five never-automate lines are marked — programming, downloads, group operations, telegram transmission and physical control.

Seventeen ways these three exercises go sideways

All three chapters carry a troubleshooting list, and they overlap in an instructive way: nearly every entry is somebody trying to upgrade a paper classification into a live claim, or somebody offering you information you must not accept. Grouped by sheet, they are as follows.

Chapter 9 — the responsibility map

Chapter 10 — the handover checklist

Chapter 11 — the ETS preflight sheet

The ones that come up on every one of these three sheets

Where to go from here