Chapter overview
Bottom line: Draw only a concept map on paper. It is used to separate the responsibilities of ETS, KNXnet/IP, listener and interface. It's not a setup map, and it doesn't walk you through any actions.
- Purpose
- Separate the responsibilities of ETS, KNXnet/IP, listener and interface on paper.
- Prepare
- Offline review sheet for Chapter 11 with a blank sheet of paper; no ETS or online materials required.
- Time
- About 15 minutes
- System change
- Do not modify ETS, Home Assistant or the network; only organize KNXnet/IP concept handover and manual approval points.
- Expected result
- Distinguish the responsibilities of ETS, KNXnet/IP, the listener, and the interface without claiming endpoint reachability or ETS success.
- Stop conditions
- Do not wire, probe or expose real KNXnet/IP endpoints.
- No ETS programming, downloads, or live network operations are allowed.
Scope and safety boundaries
This chapter only draws concept cards and lines of responsibility. Do not fill in the host, IP, port, address, interface name, certificate, project name or other environmental information. Do not open ETS and do not touch the network or running services.
This chapter does not add the repository, install or start it. This site lacks approved immutable artifact/image digest and source-to-build proof, so all execution is blocked.
ETS programming or downloads, group reads or writes, telegram transmission, and physical control are prohibited. Concept diagrams do not prove any result for the daemon, listener, interface, network, ETS, integration, or KNX bus.
Core concepts
Only department responsibilities are written on each card. Just because the cards are lined up does not prove that the department has started working.
Four department business cards on the table
Think of it this way: There are four business cards on the table: project planning, network-side vocabulary, reception window and handover interface. A business card can help you identify where responsibilities lie, but it doesn't prove that any work has been completed.
Formal term: Concept map for ETS, KNXnet/IP, the listener, and the interface.
The ETS card represents responsibility for engineering data. The KNXnet/IP card represents network-side vocabulary in pinned sources. The listener card represents a service role waiting for handoff from other software. The interface card represents a data-transfer boundary.
The same sentence must be added to all four cards: "Only conceptual responsibility, no evidence of implementation." The KNX bus is also placed outside the picture and marked "This chapter provides no evidence of results".
Preparation and prerequisites
Prepare a sheet of paper and four blank cards. Label the cards only ETS, KNXnet/IP, listener, and interface. Do not include values, names, or configuration syntax.
- Title the paper "Concept Map on Paper".
- Add two columns to each card: "Responsibility" and "Cannot Prove".
- The line of responsibility only represents the handover of concepts, not that work has occurred.
- Write STOP outside the diagram: Any ETS, network, service or KNX action stops.
- Assign another reviewer to review the operational and environmental information.
If what you really need is live-site information, this picture cannot be continued. Only the requirement classification is retained and returned to the independent approval process.
Steps
- Put down the ETS card. The responsibility only says "Project data is managed by authorized roles". In the Cannot prove column, write "This chapter provides no evidence of operation."
- Put down the KNXnet/IP card. The responsibility is only to write "the network-side vocabulary in the pinned template". The Cannot prove column says "No execution status".
- Put down the listener card. For responsibility, write only "service role waiting for handoff from other software." Do not claim that it is currently running.
- Put down the interface card. The responsibility only says "data transfer boundary". Do not include hardware, names, or settings.
- Draw lines of responsibility. Write beside each line only "concept handover". Do not include directions, arguments, or action verbs.
- Close the entire image. Write below "Concept on paper classified; all implementation layers and KNX bus results unproven".
Verification and evidence
The finished product is a paper concept drawing with only four cards. It describes the responsibility vocabulary and does not describe any site status.
- I have four responsibility cards: ETS, KNXnet/IP, listener and interface.
- Each card separates responsibility from what cannot be proven.
- There are no hosts, IPs, ports, addresses, interface names, credentials, projects, or production environment information shown.
- I provide no ETS, network, service, or KNX operations and claim no bus, integration, or device results.
Next step: Continue to Chapter 13, compare the division of responsibilities between Home Assistant integration and KNXD side.
Troubleshooting
- Lines of responsibility look like operational procedures: Change the text next to the line to "Concept Handover" and remove the sequence and actions.
- Someone wants to add network data: Stop. The diagram does not include the host, IP, port, or any live values.
- The listener is described as running: Change back to "Service role in pinned template". The execution status remains unknown.
- The ETS card describes a screen: Remove. Pinned source does not support ETS screens or operations.
- The interface card is treated as a hardware function: Change back to data handover responsibility. Both the hardware and bus remain unconfirmed.
- Someone asked for confirmation with live action: Mark it as STOP, no alternative method will be added.
FAQ
Advanced note: KNXnet/IP technology boundaries supported by pinned templates
Add-on 0.6.1's managed INI template contains server-side and listener related configuration vocabulary. This supports only how that version expresses the role in the template. It does not support post-generation settings, process status, network status or KNX bus results.
The pinned source provides no screenshots or evidence of operations from the ETS end. Therefore, ETS and KNXnet/IP must be juxtaposed with responsibility cards in this chapter. Any further execution claims must remain unknown rather than derived from the model vocabulary.
Do four cards lined up mean the system is working?
No. They are just words of responsibility.
Does the listener card represent that the service is executing?
No. The role and execution status in the pinned template are different kinds of evidence.
Can you put an internet example on the picture?
No. The diagram does not include usable network data or realistically formatted values.
Can you add a description of the ETS screen?
No. Pinned sources do not support ETS screens and operations.
Can the concept diagram prove that the KNX bus is operational?
No. The bus is outside the diagram, and there is no evidence of results in this chapter.
Evidence and sources
Evidence class: source-bounded
Feature crosswalk: listener-knxnet-ip-boundary
Pinned sources support only the documented scope. This page does not represent validation of any local environment, hardware, network, or KNX bus.