Trace responsibilities from Home Assistant to the KNX bus

Task card for this chapter

Chapter 1 distinguishes four roles. This chapter arranges the four responsibility points used in this guide: Home Assistant, KNXD, the KNX interface as the device-side gateway, and the KNX bus as the device communication path. You will learn about responsibility layers, not connections.

Purpose

Be able to identify who is responsible for each section of the data path, and know at which level to start looking for problems.

Prepare

Complete Chapter 1 first; no hardware, addresses, ETS project, or network parameters required.

Time

About 15 minutes

System change

Do not modify Home Assistant.

Expected result

State the responsibilities of Home Assistant, KNXD, the KNX interface, and the KNX bus in order without making cross-layer inferences.

Stop conditions

• The task requires a real KNX connection.
• The task would claim that the KNX bus works; neither upstream source content nor process status can prove that.

Keep the safety boundary first

A line in the diagram means that responsibility for one delivery request passes to the next station, not that live data has passed. The diagram does not show every possible direction of KNX data flow, so do not use it to infer other directions.

Evidence that one station exists or is running does not prove anything about the next station. For example, a running KNXD process establishes only process-layer status; it does not establish that the KNX interface is available, much less that the KNX bus is operational. This chapter contains no installation, configuration, startup, or wiring steps.

Let’s look at the responsibility path first

Just prepare a picture before you start

Just copy the four stations in the previous section into a blank flow chart. Do not write environmental connection information such as IP, address, or port on the diagram. Also don't write device and secret data, such as device paths, serial numbers, or credentials; these values are not prerequisites for understanding the hierarchy of responsibilities.

• Leave a box under each station labeled "What can this station prove?"
• Leave another box labeled "What can this station not prove?"
• Follow the rules of reading schematic diagrams and treat the connecting lines as a handover of responsibilities.
• If you still cannot distinguish ETS from KNXD, return to Chapter 1 and review the four roles.

Complete this blank image to continue.

Walk along the four stations

The following steps are only for identifying responsibilities on the diagram and are not a wiring procedure. At each stop, stop and talk about its work and evidence boundaries.

1. Start at Home Assistant. It's where you make your requests. At this time, we only know where the request starts, and the downstream status is still unknown.
2. Move to KNXD. It is the intermediate translator role. Even if the process layer has a known state, it cannot declare results for the interface or bus.
3. Go to the KNX interface. It is like a gate to the device network and is responsible for the handover between the KNXD and the device side. The existence of the interface name does not prove that the hardware is ready.
4. Finish at the KNX bus. This is the device communication path and the boundary that this tutorial does not cross. The status of the previous three stations cannot establish the status of this one.

After drawing the four stations, write "Responsibility path, not evidence of success" below the picture. This sentence can avoid cross-layer inferences in the future by just looking at a green state.

Completion check

You do not need screenshots or logs to complete this chapter. As long as you can look at the flow chart and answer the following questions, you understand the architectural responsibilities.

• I can name Home Assistant, KNXD, KNX interface, KNX bus in order.
• I understand that the connection line is a transfer of responsibility, not evidence of live-environment status.
• I know that the status of the KNXD process layer cannot prove the results of the interface or bus.
• I did not fill in connection values, start services, operate ETS, send messages, or control devices.

Next step: Go to Chapter 3, using a plain-language eight-item checklist to complete placeholder-only preflight. Passing the preflight only means that you can read the conditional process of the next chapter, but it does not prove that you can ignore isolation, approval, or artifact provenance.

When responsibilities cannot be clearly seen

What we are dealing with here is "misreading the picture", not a live-environment fault. A simple starting point is:Start classifying from the layer of responsibility closest to the symptom, rather than guessing at the entire path.

• Can't see the Add-on management screen: Attribute symptoms to Home Assistant management first.
• Just know that the KNXD process has no known state: It is first placed in the KNXD process layer, without inference to the interface or bus.
• Only know that the device gate has no status: It is first classified into the KNX interface layer.
• It remains unclear whether the device received the message: Keep it at the KNX bus/device layer. That is outside this chapter; do not attempt verification through physical control.

If you only view the connection line as a live-environment result, change the label back to "Responsibility Transfer". If KNXD and the KNX interface are combined into one station, they can be re-divided into two compartments: the translation desk and the equipment gate.

Advanced notes and FAQ