KNXD 22-chapter offline tutorial

Task card for this chapter

You are already familiar with Home Assistant add-ons, integrations, and entities. This chapter does not require you to install or configure anything; it only explains four roles. Once those roles are clear, you will not have to guess when later chapters refer to KNX as the device communication path, ETS as the project-planning tool, or KNXD as the translation desk.

Purpose

Explain the differences between Home Assistant, ETS, KNXD, and the KNX device network in your own words.

Prepare

Know how to use Home Assistant; no knowledge of KNX, Linux or network engineering.

Time

About 10 minutes

System change

Do not modify Home Assistant.

Expected result

Distinguish Home Assistant, ETS, KNXD, and the KNX device network, and understand that a running process does not prove bus operation.

Stop conditions

• The task requires a real KNX address, host data, or a secret.
• Stop if the task would require a KNX bus connection or physical-device control.

Keep the safety boundary first

This chapter is a reading exercise about roles. Do not activate the Add-on, send a KNX telegram, or read or write a group address. Even if "Running" appears on screen, it means only that a process is running; it does not mean that the KNX device network is connected.

Remember: A running process does not prove that the bus is operational. A translator sitting at the desk does not prove that the telephone line is connected or that building equipment has received a message. This chapter does not certify any result for an ETS project, the Home Assistant KNX integration, or physical equipment.

Environment-identifying information includes real hostnames, IP addresses, individual addresses, and group addresses. Secrets or device identifiers include USB serial numbers, tokens, and credentials. Do not copy or share either type of data.

Learn about the four roles using the building counter

All you need to know before you start

You do not need to prepare hardware, ETS projects or network data. First use a piece of paper to write down four boxes: Home Assistant, ETS, KNXD, KNX device network. Then put a plain-language description of each role into the corresponding grid.

• Home Assistant is the control desk where you make your requests.
• ETS is a tool for planning and setting up KNX projects, not another name for KNXD.
• In the path described by this guide, KNXD is the translation desk; the Add-on lets Home Assistant manage it.
• In this site's responsibility diagram, the KNX device network is on the device side; the status of other software cannot prove its status.

Go through it in four sentences

This is only a verbal exercise; do not operate any interface. At every step, ask "Who is responsible?" Don't ask "What value should be filled in?"

1. Identify the control point. You make the request in Home Assistant, so it's the control desk.
2. Identify project planning. When it comes to describing how a KNX project is designed, that is the role of ETS, not the Home Assistant Add-on.
3. Identify the intermediary. The Add-on path used in this guide places KNXD between the Home Assistant management side and the KNX device network; the Add-on is responsible for managing this program in Home Assistant.
4. Finally, keep the result boundaries. The presence or execution of the KNXD program proves only the status of the process layer; whether the KNX bus is connected has not yet been confirmed.

If you can finish four sentences without mentioning any IPs, addresses, or settings, you've completed the plain-language thread of this chapter.

Completion check

Check yourself with the checklist below. The completion here is "mental model completion", not system deployment completion.

• I can tell that Home Assistant is the control desk and ETS is the building blueprint and configuration tool.
• I can tell that KNXD is the translation desk and KNX is the device communication network.
• I know that an Add-on appearing to run is not evidence that the KNX bus is operational.
• I'm not connecting to buses, operating ETS, reading or writing groups, or controlling physical equipment.

Next step: Go to Chapter 2, use the same building as a metaphor to understand which roles the data responsibilities will pass through in order.

What to do when the role is placed in the wrong place

This chapter does not troubleshoot service faults. It addresses the common mistake of confusing roles or evidence layers. Use the guidance below to correct each statement.

• ETS is mistaken for a Home Assistant integration: Separate the roles. ETS is the planning and setting tool for KNX projects, and integration is another role within Home Assistant.
• KNXD is mistaken for a KNX device: Put KNXD back at the translation desk; the device network remains downstream.
• When “Running” is mistaken for a bus connection: Limit the conclusion to process status; keep bus status unconfirmed.
• I feel that we must first obtain live-environment information: Stop collecting; this chapter only requires role names, not any environment-identifying information.

Advanced notes and FAQ

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

Task card for this chapter

Think of the KNXD Add-on as a translation desk ready to move into your building. Before opening it, confirm administrative permissions, backups, sources, artifact provenance, and the stop procedure. This chapter covers checks only: it does not add the repository, install or start the Add-on, or collect live-environment values.

Purpose

Complete a pre-installation checklist that does not include environmental data, and obtain a judgment of "can enter Chapter 4" or "stop and obtain the missing evidence first."

Prepare

Be able to sign in to Home Assistant and know who has Add-on management rights.

Time

About 15 minutes

System change

Do not modify Home Assistant; perform only a preflight review without live values.

Expected result

Classify all eight checks and clearly conclude that installation remains blocked while this site lacks an approved artifact digest.

Stop conditions

• A usable backup cannot be created or confirmed.
• The task requires disclosure of a host, address, USB serial number, credential, or device path.

First keep the boundaries between data and operations

The checklist only records categories and placeholder marks, such as "Administrative permissions: Compliant" or "Network planning: Unknown". Don't replace live values with abbreviations that appear anonymous but can still be traced back to the environment.

May not be copied or shared: Host name, IP, KNX individual address, group address, USB serial number, account, password, token, certificate and device path. When you see these contents, just mark them as "masked" or "unknown" and do not post them to documents, screenshots, chats or issues.

This chapter does not send a KNX telegram or perform group writes. Group reads, ETS programming or downloads that write engineering designs to devices, and physical control are also prohibited. Any check that requires wiring, powering on a device, or testing equipment response is outside this chapter.

Understanding preflight with the door opening checklist

Prepare a value-free checklist

Create an eight-row checklist: Home Assistant installation type, administrative rights, Home Assistant backup, source and version, interface category, network planning, stop conditions, and restore decision. For each row, select only "Met", "Not met", or "Unknown", and add a description that contains no live values. The source and version columns must both check the source lock, the approved artifact/image digest, and the source-to-build attestation that ties that digest to the pinned commit.

• The installation type only records "Supports Add-on management" or "Pending confirmation", but does not record the host information.
• The permissions only record whether the role can manage Add-on, not the account number or login information.
• The backup only records whether the time range and coverage have been verified, and no files or names are attached.
• The interface and network only record the solution type and whether it has been confirmed by the person in charge, but do not record any endpoint or identification value.

Complete safety preflight item by item

1. Confirm the Home Assistant installation type. Only determine whether the current environment provides an Add-on management interface. If you are not sure or the screen is different, mark "Unknown" and stop. Do not use other host methods to bypass it.
2. Confirm administrative rights. Have an authorized administrator manually verify that you can install, start, and stop the Add-on. Stop if the permissions are unclear and do not borrow or share credentials.
3. Confirm the backup or recovery point. Manually verify the timing, coverage, and restore responsibility of Home Assistant backups. Do not proceed with the installation without a backup that illustrates the scope.
4. Check the source and version. The expected repository (specified software library) identity is da-anda/hass-io-addons, the site source lock is fixed at commit (exact source revision) 60d4a702e2011e75c90a0f1012dfbd916eb24ce0, the source version boundary is Add-on 0.6.1. You must also obtain approved artifact/image digest and source-to-build attestation to prove that the image to be installed was built from this pinned source. The store shows that 0.6.1 cannot complete this proof. This site currently has no approved digest, so this column should be recorded as "Unknown", and the installation is still blocked.
5. Confirm the interface category. Only the responsible person may select a category such as "USB, serial, network, or undecided." Do not select a driver (interface communication method); leave the device, endpoint, and KNX-address fields blank.
6. Confirm the isolation plan. Record only whether there is a non-production Home Assistant test instance, no KNX/USB/device mapping, a disconnected physical bus, limited network exposure, assigned backup/restore roles, and an authorized administrator present. If anything is unknown, stop before adding to the repository and installing; do not scan the network, test endpoints, or log IPs to fill in forms.
7. Write down the stopping condition. At a minimum, this includes version inconsistencies, unclear backups, identification values, unexpected interface connections, unexpected program behavior, and any physical equipment reactions.
8. Write down the restore decision. Distinguish between "Stop Add-on" and "Restore Home Assistant Backup". Specify who will make the decision and what scope of change will be handled; don’t assume stopping equals restoring.

Completion check

Only when all eight rows are marked “met” may you proceed to Chapter 4’s conditional section. If any column is "Unknown" or "Not Compliant", stop. Do not add the repository or attempt installation merely to find the answer. Since this site currently has no approved artifact/image digest, the “source and version” item must remain unknown at this stage; you can read Chapter 4, but cannot perform lifecycle actions.

• The installation type and administrative rights are clearly classified, but the host or account information is not recorded.
• I've checked the timing and coverage of the backup and know that stopping does not equal restoring.
• I've separated the source version boundaries, artifact/image digest, and source-to-build attestation for Add-on 0.6.1; leaving it "unknown" without an approved digest.
• I only recorded the interface and network solution categories and did not copy any live values.
• I have written down the stop condition, operator and restore decision maker.

Next step: When every item is met, go to Chapter 4. If anything is missing, first review Check readiness before starting and When to stop and how to restore.

What to do when preflight is stuck

• Don't know the installation type: Please ask Home Assistant administrators to only reply whether they have Add-on management capabilities; do not ask for system screens or host information.
• Backup not found: Stop subsequent actions. First create and check the backup according to the official interface of the current Home Assistant version; this chapter does not involve guessing the button locations.
• Source or version different: Keep the "Not Conforming" category and stop. Do not apply settings declared in 0.6.1 to other versions.
• Someone asked for connection information: Refuse to copy and use categories such as "Network type, pending approval"; if you still need to provide actual values to continue, end this chapter.
• The stopping method is unclear: Read first Stop and restore entries, the manager will confirm the responsibility before repeating the preflight.

Advanced notes and FAQ

Task card for this chapter

This chapter considers the lifecycle of KNXD Add-on as "arrival, duty, shift change, and off duty". But the counter cannot be moved into the production building first: complete isolation, written approval, and proof of immutable build must be completed before being added to the repository or installed. This site currently has no approved artifact/image digest, so you can only read the conditional interface tour, but cannot actually install or start or stop it.

Purpose

Distinguish between installed, running, stopped and anonymous log evidence, and know when lifecycle operations are still blocked.

Prepare

All eight preflight checks in Chapter 3 are satisfied; the six isolation conditions, approval records and artifact provenance have been verified by authorized managers.

Time

About 20 minutes

System change

This site currently lacks an approved artifact digest, so no repository is added and the Add-on is not installed, started, or stopped. Any future exercise must first pass the complete isolated-test gate.

Expected result

Distinguish source, artifact, and process evidence, and stop before the first change whenever proof is incomplete.

Stop conditions

• Telegram transmission, group reads or writes, and physical control are prohibited.
• Unable to describe the impact of the change or how to revert it.

First confirm this chapter makes no changes

The evidence in this chapter is limited to process status and logs. In a future approved exercise, you could observe only that the Add-on is installed, the process is running or stopped, or a category of de-identified message appears in the log. A running Add-on does not prove that the KNX bus is connected and cannot establish results for ETS, the Home Assistant KNX integration, group operations, or physical control.

Do not connect to a KNX interface or bus or transmit a KNX telegram. Group reads and writes, ETS programming or downloads, and physical control are prohibited. Do not copy, collect, share or publish real hosts, IPs, addresses, USB serial numbers, credentials, tokens or device paths.

Adding repository, installing, starting, restarting, stopping, removing and restoring are all environment changes. Full isolated-test gate, written approval and immutable artifact provenance must be completed first. All actions are manually confirmed step by step only by the administrator present, without the use of shells, APIs, scripts or automation.

Understand status with a staffed desk

Complete gate before all actions

Interface navigation note: Home Assistant's add-on store, repository management, and backup interface can change between versions. Use the official Home Assistant add-on documentation to identify the controls and process for the current version. If a name or location differs, return to the official documentation; do not guess which control to use.

Before adding the repository or installing the Add-on, the administrator present must verify each of the following six conditions. Only a non-production Home Assistant test instance is eligible to continue:

• This is a non-production Home Assistant test instance, not a system providing services in a home, office, or customer site.
• The system has no KNX, USB or other device paths mapped.
• The physical interface and bus remain disconnected, and there are no alternative connections that would allow the test program to touch the field device.
• Any services that may be enabled remain within the bounded network test scope approved by the administrator and cannot be reached inadvertently from a general local network or the public internet.
• Pre-installation Home Assistant backups, minimal recovery methods, and roles responsible for stopping, removing, or restoring have been reviewed.
• Administrators with Add-on management rights are present throughout the process and can stop immediately in case of abnormalities.

If any of these cannot be proven, stop before adding the repository and installing. Home Assistant in production use cannot install Add-ons that have not passed the above gate.

Written approval record

A privacy-safe change record must be established before operation. Only IDs without environmental clues are placed in public or educational records; private approval records, precise operational scope, and six isolation evidence remain in access-controlled records. If one of the following fields is missing, we will not continue.

Change/Approval Record ID

Use an organization-issued privacy-safe ID with no name, host, address or time clue; this site does not provide sample values that could be misused as real records.

Controlled record reference

Only controlled references that can be retrieved by authorized personnel are recorded; it must be tied to a private approval record, precise operating scope, and six items of isolation evidence, but no name, system path, or link to a public page.

Approver role

Record only the role, not a person's name—for example, "Home Assistant administrator." Evidence of the private approval remains in a controlled record.

Approval actions and scope

List item by item whether this includes adding repository, installing, starting once, restarting once, stopping, removing, or backup and restore; the precise operation scope does not include KNX interface, bus, telegram, ETS or physical equipment.

Isolation evidence reference

The controlled records linked to the six isolation checks above only disclose the conforming/non-conforming/unknown classifications and do not disclose the environmental values.

Approval date and time

Time is kept in a controlled record; the public guide displays only the "recorded" status to avoid cascading live-environment activities.

Stop conditions

Bind the applicable stop conditions this time; if the isolation fails, the status is unknown, the proof is inconsistent, or the unexpected behavior occurs, it must be stopped immediately.

Privacy boundaries

Do not record the host name, host ID, IP, KNX address, USB serial number, device path, account, password, token, certificate or other secret.

Immutable build/artifact provenance gate

The source lock pins da-anda/hass-io-addons at commit 60d4a702e2011e75c90a0f1012dfbd916eb24ce0, which declares Add-on version 0.6.1. This only proves the source content.The 0.6.1 shown in the store does not prove that the image to be installed is built from the pinned commit.

• The controlled record has an artifact/image digest approved by the administrator, and the algorithm has been checked against the full digest.
• There is verifiable source-to-build attestation, and the digest is tied to the above pinned commit and build process.
• The operator can verify that the artifact Home Assistant will retrieve is the approved digest; not just the name or version text.

Conditional interface navigation

The following items describe only interface landmarks, expected observable states, and stop points that accommodate version differences. An administrator may perform them manually, using the then-current Home Assistant documentation, only after controlled records satisfy every gate.

1. Add the repository. When the approval record and artifact/image digest evidence are both valid, find the Add-on management landmark from the Home Assistant configuration area, and then follow the official documents to enter the repository management. After joining, only accept the list of approved repository identities; stop if the items are different, the source is unrecognizable, or the interface requires guessing. This site currently lacks an approved digest, so do not execute it.
2. Manual installation. When the approval record and artifact/image digest evidence are both valid, find the KNXD details page for the approved source from the add-on store. After the installation is completed, the expected page can distinguish between the "installed" status and the lifecycle control area; do not use the store version to infer commits. If started automatically or if real KNX values are requested, stop immediately. This site currently lacks an approved digest, so do not execute it.
3. Manual start. While the approval record and artifact/image digest evidence remain valid, the administrator present may use the start control on the details page once. The expected observation is only that the Add-on process changes from a stopped state to a running state; wording varies by version. This does not prove that the bus is operational. This site currently lacks an approved digest, so do not perform this step.
4. Manual restart, once. Use the restart control on the details page only once, while the approval record and artifact/image digest evidence remain valid and the previous state can be explained. The expected observation is only a brief transition followed by a return to the running state. Stop rather than retry if the state is unclear. This site currently lacks an approved digest, so do not perform this step.
5. Manual stop. Use the stop control of the detail page when the controlled approval scope includes a stop and the preceding certificate is still valid. The expected state is no longer running, but a stopped state. Do not repeat operations when the screen has not changed, stay isolated and return Stop and restore. No operation has been performed on this site, so there is nothing to stop.
6. Manual removal. Only when the controlled approval scope includes removal and the Add-on has been stopped, the removal/uninstallation lifecycle action is identified from the details page. Expect the installed state and lifecycle controls for the instance to disappear, or the page to return to the installable state; this does not prove that Home Assistant as a whole has been restored. Nothing has been installed through this site, so there is nothing to remove.
7. Manual restoration. Only when the backup coverage is fully consistent with the controlled approval, the administrator can select the pre-verified recovery point from the Home Assistant backup management landmark, first review the scope of impact, and then confirm. Expect to return only to the state covered by this backup; recheck Add-ons with other affected items after restoring. This site currently has no lifecycle changes that need to be restored.

Complete examination and evidence interpretation

The correct result at present is "stopped before first change due to lack of artifact provenance". If all gates are satisfied in future, the log will only be viewed briefly in the Home Assistant screen. Follow safe log guidance to complete the de-identification and only record the time range, component and error category; remove the host, IP, address, account, token, session, certificate, device name, path and serial number, and do not publish the complete log.

• I know pinned commits only attest to sources, store versions cannot replace artifact/image digest with source-to-build attestation.
• I have checked six isolation conditions and complete approval records before adding the repository and installing; currently the digest is missing, so no changes have been made.
• I can explain the observable scope of installed, running, stopped, removed and restored respectively, without cross-layer inference.
• I don't connect to the interface or bus; I don't send telegrams; I don't perform group operations; I don't perform ETS programming or downloads; and I don't perform physical control.

Next step: Keep all KNX interfaces, device mappings, and buses disconnected. When you need to interpret process status, see Interpret Add-on status. Without artifact provenance, retain only a "blocked" record.

Stop, remove and restore decisions

1. Start by narrowing the scope of the change. If the problem in the future only involves this Add-on, stop the Add-on first, and then remove the Add-on. Afterward, confirm only that the process is not running and the Add-on instance has been removed; do not refer to the removal as all of Home Assistant has been restored.
2. Consider a broader restoration only when its scope matches. If changes other than Add-on have occurred, and the pre-approved backup does cover this scope, the administrator must first check the backup time, content and other changes that may be covered, and then manually confirm using the Home Assistant official backup and restore process. The interface and wording vary depending on the version. This chapter does not make up buttons.
3. Verify again after restoring. It is up to the administrator to confirm that Home Assistant is back in the expected range, that the KNXD Add-on is in the expected stopped or removed state, and that there are no unintended effects. If any result is unclear, remain in isolation and stop further operations.

• Missing digest or attestation: Remain blocked, do not add other repositories, and do not install similar versions.
• Process status unknown: Record only the de-identified error category and stop; do not fill in the bus value, change the driver, or connect to the interface to try.
• The log contains environmental information: Stop sharing and delete the copy; if the secret has been revealed, have it revoked or rotated by the administrator.

Advanced notes and FAQ

Chapter overview

Bottom line: This chapter creates only a candidate-classification table without identifying information. You will neither list devices visible to a computer nor identify suitable hardware. Completing the form does not establish hardware compatibility.

Purpose

Classify interface candidates by documented characteristics without guessing whether the hardware is suitable.

Prepare

A blank offline classification sheet, and safety boundaries for Chapters 3 and 4.

Time

About 15 minutes

System change

Do not modify Home Assistant; create only an offline interface-classification table without real device paths or serial numbers.

Expected result

Classify interface candidates by de-identified characteristics while keeping hardware availability unproven.

Stop conditions

• The task would copy or publish real device paths, USB serial numbers, or host identifiers.
• The task requires access to a KNX interface, KNX bus, or physical device.

Scope and safety boundaries

You are organizing only how data should be classified. Do not enumerate devices, view real device paths, or copy serial numbers. Do not publish real hostnames, IP addresses, endpoints, credentials, or time clues. If existing material contains any of these, stop transferring it and follow the safe log-sharing guidance.

This chapter does not add the repository, install or start it. These actions may only be evaluated separately after complete isolation, written approval, and approved immutable artifact/image provenance are established. This site currently lacks an approved artifact/image digest and must not be executed.

Also do not connect the interface or the KNX bus. Group reading, group writing, telegram transmission, ETS programming or downloads and physical control are prohibited.

Core concepts

There are only three judgments in the classification table: the source document has been explained, manual review is needed, and it is beyond this chapter. When seeing the existence of candidates, the most we can say is "there is a record to classify." Do not write "interface found" or "available".

Preparation and prerequisites

Prepare a blank sheet. Only create the following fields without filling in any environment values:

• Candidate codenames: Use meaningless labels like "Candidate A".
• Data categories: document facts, issues to be reviewed, or information prohibited from being disclosed.
• Field role: Whether this data may be an interface input.
• Current conclusion: Always start with "hardware applicability not proven".
• Reasons for stopping: unapproved records, data that may identify an environment, or a source-version mismatch.

Don't prepare terminal commands, device lists, or screenshots. There is no live enumeration program in this chapter.

Steps

The following are all classified on offline paper. You do not need to touch the execution environment.

1. Write the common conclusion first. Write in the header "This list is only for candidate classification; hardware compatibility, driver operation and bus status have not been confirmed."
2. Create a neutral code name. When you need to distinguish between existing de-identified records, write candidate A and candidate B in order. Do not generate codes from path, serial number, model, or location.
3. Classify each record by role. Put each content into "Document Facts", "Pending Manual Review" or "Not to be Disclosed". If there is not enough content, mark it as unknown.
4. Write down things that are not proven. For each candidate, mark hardware identity, driver family, usability, and KNX bus status as unconfirmed.
5. Apply the stop condition. If classification requires reviewing an actual path, serial number, host, or live device list, stop. Do not probe step by step to find the answer.
6. Give it to another person to review. Only de-identified classification sheets are delivered. Reviewers are asked to confirm that there is no environment-identifying information and no compatibility claims.

Verification and evidence

The correct result is a classification table, not an installation answer. Use the checklist below to keep the document within scope.

• My table only has candidate codenames, no real paths, serial numbers, hosts, IPs, or endpoints.
• I did not perform live enumeration, nor did I provide related programs.
• Each candidate remains "hardware suitability unproven".
• I did not install or start anything, connect to the bus, perform group or ETS operations, or control physical equipment.

Next step: Go to Chapter 6. Select only a driver-family candidate documented by the pinned source for later manual review; do not try to start it.

Troubleshooting

• Not sure where the candidates come from: Mark "Unknown Source" and stop. Don't go back to the live system to find answers.
• Candidate codenames imply model or location: Change it back to a meaningless letter code and delete the old copy.
• A colleague asked for the real path: Do not provide it. Convert the requirement into "Which field role needs to be reviewed?"
• The table looks like a compatibility list: Add "hardware suitability not confirmed" to each column and remove words such as "recommended" or "confirmed."
• Someone suggests starting candidates one by one: Stop. Starting software is outside this chapter's classification exercise and cannot bypass isolation, approval, or artifact-provenance gates.

FAQ

Chapter overview

Bottom line: Select only a driver family documented by the pinned source, and submit it for later manual review. This is not an installation recommendation, nor is it proof of hardware compatibility. If documentation is insufficient, stop.

Purpose

List a driver-family candidate for manual review based on a pinned source.

Prepare

De-identified classification results for Chapter 5, and documentation comparisons for the pinned versions.

Time

About 15 minutes

System change

Do not modify Home Assistant; only compare driver families offline based on pinned sources.

Expected result

List driver-family candidates for human review without presenting name matching as proof of hardware compatibility or availability.

Stop conditions

• The task asks you to infer driver or hardware compatibility directly from a product name.
• The task requires loading a driver, starting a service, or contacting a physical interface.

Scope and safety boundaries

This chapter reads only pinned sources. Do not guess a driver from a product name, appearance, connector, candidate codename, or online article. Do not try drivers one after another. Without clear documentation for the same version, the answer is "no selection; awaiting further evidence."

This chapter does not add the repository or install or start the Add-on. Any such action requires complete isolation, written approval, and approved immutable artifact/image provenance. This site currently lacks an approved artifact/image digest and therefore remains blocked.

Do not connect the interface or KNX bus. Group reading, group writing, telegram transmission, ETS programming or downloads and physical control are prohibited. Do not record any environment-identifying information.

Core concepts

Ask two questions: Does the pinned Add-on version accept this name? Does the locked upstream file explicitly document a family with the same name? Only when both answers are "yes" may it be listed as a candidate for later manual review.

Preparation and prerequisites

Create an offline decision card. Do not put product name, device path, serial number, host, IP or endpoint. The card only requires:

• Requirement category: Only write roles such as "device-type input" or "endpoint-type input".
• Add-on name evidence: Yes, No, or Unknown.
• Upstream file documentation: Yes, No, or Unknown.
• Manual review status: pending review or stopped.
• Non-conclusion: The local hardware compatibility, driver startup and bus status have not been confirmed.

If the version does not match, look first Versions and compatibility. Do not use other versions to make up your answers.

Steps

1. Write the required role first. Just write which type of input needs to be processed. Do not write the make, model, or actual value.
2. Check the Add-on name. Confirm that the candidate name is in the pinned enumeration for Add-on 0.6.1. If not, stop and don’t change the name on your own.
3. Check the upstream instructions. Confirm that the upstream 0.14.72 pinned source explicitly describes the driver family of the same name. Similar names don't count.
4. Keep at most one candidate. When both documents are clear, write "Documented candidate; pending manual review." If multiple candidates remain or there is no clear answer, make no selection.
5. Add non-conclusion. It states "Hardware compatibility has not been proven, drivers have not been loaded, services have not been started, and the bus has not been contacted."
6. Stop at the file level. Submit the decision card to the approval process. Do not try to start, and do not use live logs to favor a candidate.

Verification and evidence

The completion result must be "Document Candidate" or "Insufficient Evidence". It cannot be written as "Driver Applicable".

• The candidate has both Add-on 0.6.1 name evidence and upstream 0.14.72 explicit documentation.
• Decision cards have no products, paths, serial numbers, hosts, IPs, endpoints, or credentials.
• I left the hardware compatibility, loading, startup, listener and bus status as unverified.
• I didn't take a turn to test the driver, nor did I install, start, or connect the physical interface.

Next step: Go to Chapter 7, only recognize the configuration fields, placeholder text, house number and exposure responsibility.

Troubleshooting

• Only Add-on name, no upstream description: Indicates insufficient evidence and does not establish family correspondence.
• The names are similar but not identical: Treat them as different. Do not infer a match from prefixes, suffixes, or product descriptions.
• There are two documented candidates: Choose neither. List the document gaps and submit them to manual review.
• Some people regard the default value as a recommendation: Remove recommendation statements. A source default is just a schema fact.
• Someone asked to start and take a look: Stop. A test boot is not a file selection, nor does it prove hardware compatibility.

FAQ

Chapter overview

Bottom line: Configuration fields, placeholders, ports, and network exposure are distinct concepts. Create only a responsibility list; do not enter live values, open ports, or change networks.

Purpose

Distinguish configuration fields, file placeholder values, connection ports, and network exposure responsibilities.

Prepare

A blank responsibility sheet; no ETS project, host information, or network settings required.

Time

About 15 minutes

System change

Do not modify Home Assistant or the network; use only placeholder text to organize address fields, port roles, and exposure responsibilities.

Expected result

Distinguish configuration fields, placeholders, and responsibility for network exposure without entering any live-site identifiers.

Stop conditions

• Do not enter or expose real hosts, endpoints, individual addresses, or group addresses.
• Steps require opening listeners, firewalls, or establishing a live connection.

Scope and safety boundaries

This chapter only covers documentation classification. No real individual address or group address is allowed. You may not publish real client ranges, hosts, IPs, ports, URLs, interfaces, device paths, serial numbers, or credentials. Document placeholder text cannot be pasted into settings.

Do not enable listeners, modify firewalls, routing or network interfaces, or perform connection tests. This chapter does not add the repository, install or start it. Any changes still require complete isolation, written approval, and approved immutable artifact/image provenance; the site currently lacks an approved digest.

Group reading, group writing, telegram transmission, ETS programming or downloads and physical control are prohibited. Correctly formatted fields do not prove KNX bus, ETS, integration or device performance.

Core concepts

An individual address is also different from the group address. This chapter does not configure any kind of address, nor does it start an ETS project.

Preparation and prerequisites

Create a four-column accountability chart. Each column only contains concepts, not numbers or environmental values:

• Form field: Set the name and data role of the field.
• Placeholder: Use semantic placeholder text and mark it "Not deployable."
• Port role: Just say that this is port type information, without writing any numbers.
• Network access: List listeners, bindings, firewalls, routes and network ranges as separate review responsibilities.

If data comes from logs or screenshots, stop sharing it and follow the safe log-sharing guidance. Do not read the live environment merely to complete the form.

Steps

1. Mark the column role first. Separate the address class, range class, endpoint host class and port class. Just write categories.
2. Use placeholder text instead. In the public form, write only "individual-address placeholder," "client-range placeholder," "endpoint-host placeholder," and "endpoint-port placeholder," and mark each one as not deployable.
3. Separate the port from the listener. A port is like a door number; a listener is a service waiting for work. Do not represent them as a single state.
4. List exposure responsibilities. Treat binding scopes, firewalls, routing, and accessible networks as independent review items. All marked Not Evaluated.
5. Add non-conclusion. It indicates that the address has not been configured, the port has not been opened, the listener has not been established, the endpoint has not been verified, and the bus has not been certified.
6. Remove live values. If any numeric addresses, ports, hosts, URLs or environment names appear in the form, delete them before delivery.

Verification and evidence

Completion requires separated responsibilities and no live values. The result is not a usable configuration.

• I can explain that a field is a space, placeholder text is a prompt, a port is like a door number, and network exposure determines who can reach that door.
• All placeholder text is clearly marked "For document classification only; not deployable."
• The table has no addresses, ranges, hosts, IPs, port numbers, URLs, or other context identifying information.
• I did not modify Home Assistant, listener, firewall, routing or network, nor did I operate ETS or bus.

Next step: Go to Chapter 8, use the "reception desk" to understand the boundaries of responsibility between the listener and KNXnet/IP.

Troubleshooting

• Readers would like to see format examples: Use only semantic placeholder text. Don't provide numbers that seem directly applicable.
• Placeholder text is treated as a setting value: Add "Not applicable" next to each placeholder and remove copyable snippets.
• A port number is mistaken for a listening service: Return the conclusion to the door role. The listener state requires another layer of evidence.
• A listening service is mistaken for public exposure: State that bindings, firewalls, routes, and network ranges have not been evaluated.
• Someone asked to open a port for verification: Stop. This chapter does not do live network changes or detection.

FAQ

Chapter overview

Bottom line: A listener is a role that waits to receive work. Its presence in a configuration proves neither endpoint reachability nor an established connection or tunnel, and it says nothing about KNX bus status.

Purpose

Distinguish the responsibilities of listener, network interface, KNXnet/IP and KNX bus.

Prepare

Responsibility table for Chapter 7; no endpoints, web tools, or ETS required.

Time

About 15 minutes

System change

Do not modify Home Assistant or the network; only read the boundaries of responsibility for listeners and KNXnet/IP.

Expected result

Explain the separate responsibilities of the listener, network interface, and KNX bus without claiming endpoint reachability or connection success.

Stop conditions

• The task requires provisioning, probing, or connecting to a real network endpoint.
• The task would claim that a KNX interface or bus works; listener status cannot prove that.

Scope and safety boundaries

This chapter only reads the pinned template. Do not provide or probe endpoints. Do not perform connection, tunnel, socket or reachability procedures. Do not copy hosts, IPs, ports, URLs, network interfaces, credentials, or any environment-identifying information.

This chapter does not add the repository, install or start it. Any changes must still be preceded by complete isolation, written approval, and approved immutable artifact/image provenance. This site currently lacks an approved artifact/image digest, so all execution is blocked.

Do not connect to the KNX interface or bus. Group reads, group writes, telegram transmission, ETS programming or downloads, and physical control are prohibited. Neither listener status nor network messages can prove any result for those layers.

Core concepts

Keep the four layers separate: template declaration, process/listener status, endpoint reachability, and KNX bus results. The previous layer can never automatically prove the next layer.

Preparation and prerequisites

Draw four empty boxes without filling in endpoints or values:

1. Template role: Record whether the pinned file mentions server or listener.
2. Process role: Record whether independent evidence exists for the process or listener.
3. Network role: Record whether the endpoint is reachable; in this chapter, always write "not tested; not established."
4. Bus role: Record whether there is evidence about the KNX bus; in this chapter, always write "unconfirmed."

This picture limits only what the document may claim. It is not a network topology and cannot be used to establish connections.

Steps

1. Write the conclusion of the document first. Just write "Pinned template contains listener/server setting role". Do not write "Monitored".
2. Put it in the first box. Put this sentence in the template layer. The remaining three boxes remain unestablished or unproven.
3. Separate network interface. Note that the interface is only responsible for the entry and exit of network data; it is not equal to listener, nor can it represent bus.
4. Block the reachability inference. In the network box write "No endpoint data, probes, connections, or tunnels".
5. Block bus inferences. Write "No evidence of telegrams", "No evidence of group operations", "ETS programming or downloads not executed" and "No evidence of physical control" respectively in the bus box.
6. Limit each conclusion. Replace any unsupported assertion about an endpoint, connection, tunnel, or bus with a statement grounded in the pinned template.

Verification and evidence

The finished product is a four-layer responsibility map. The only ones with direct origins are the template roles. All other layers must remain unconfirmed.

• I can explain that the listener is like a reception desk waiting for incoming calls, which does not prove that the outside line is reachable.
• I divided templates, processes/listeners, reachability and KNX bus into four layers.
• My graph has no host, IP, port, URL, interface name, credentials, or other environment-identifying information.
• I did not provide probing, wiring, or tunneling procedures. Bus, ETS, integration and physical control results remain unconfirmed.

Next step: Continue to Chapter 9, responsibilities for classifying INI sections, options, and managed templates.

Troubleshooting

• The template looks fully configured: Continue to record it only as a template role. It does not prove that it was generated, applied, or listened to.
• The word "listener" appears in a log: This belongs only to the process/listener layer. Follow status interpretation guidance and leave reachability and bus status unconfirmed.
• Someone asked for the endpoint: Do not provide it. Public textbooks do not contain connection details.
• Someone wants to detect whether it is reachable: Stop. There are no reachability, wiring, or tunnel procedures in this chapter.
• Someone treats KNXnet/IP as a bus result: Return to the four-layer map. Network-side terminology does not establish KNX bus status.

FAQ

Chapter overview

Bottom line: Draw only an offline responsibility map and sort settings into labeled drawers. Do not enter values, write files, or apply settings.

Purpose

Use labeled drawers to separate INI sections, options, and generation responsibilities.

Prepare

A blank sheet of paper with the responsibility classifications for Chapters 7–8; no configuration files or execution data required.

Time

About 20 minutes

System change

Do not modify the INI or start or stop the Add-on; only read the pinned version of the managed template offline.

Expected result

Relate INI sections and options to the component that generates them without treating the template as deployable live configuration.

Stop conditions

• You need to fill in the real environment values or write the template directly into the system.
• Steps require applying settings, installing or restarting the Add-on.

Scope and safety boundaries

This chapter is only classified on paper. Do not paste hosts, addresses, ports, devices, serial numbers, secrets, or live settings. Do not read local results, and do not use the template as the current setting.

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.

Do not connect the interface or KNX bus. Group reading, group writing, telegram transmission, ETS programming or downloads and physical control are prohibited. Paper comparisons cannot prove daemon, listener, integration or bus results.

Core concepts

Your diagram only needs four drawers: "Main Responsibility", "Service Responsibility", "Record Responsibility" and "Interface Responsibility". If a piece of information cannot be classified based on pinned sources alone, it is put into "pending evidence".

Preparation and prerequisites

Take a piece of paper and draw five empty frames. The first four boxes are the four accountability drawers. The fifth box is "Evidence to be supplemented". Only put category words in each box.

• Write "Offline Responsibility Chart" at the top of the paper.
• Write "does not contain live values".
• Write "No execution results were generated, applied, or read."
• Address version differences under Versions and compatibility; do not mix content from other versions.

If the information at hand contains environmental identification content, do not copy it. Record only "requires confirmation by authorized personnel at a controlled location".

Steps

1. Put the main responsibilities first. Put the overall connection and coordination roles into the main drawer. Do not fill in any value.
2. Then put the service responsibility. Put roles waiting for handover from other software into the service drawer. Do not infer that the service exists.
3. Separate documentation responsibilities. Put message levels and record categories into the record drawer. Do not copy local logs.
4. Separate interface responsibilities. Write device, filter, or network inputs as categories only. Don't put paths or endpoints.
5. Mark source boundaries. Each category card indicates that it comes from an input schema or a managed template. Don't write two sources as if they were the same thing.
6. Write a limited conclusion. Finally, just write "Offline responsibilities have been compared" or "There are still gaps." Do not write deployed or ready for use.

Verification and evidence

The finished product must be a responsibility map without live values. It identifies which category owns each type of data but does not describe what a system is currently doing.

• I have five drawers: main, service, record, interface and pending evidence.
• I label input schemas and managed templates separately.
• My image has no host, address, port, path, serial number, secret or live settings.
• I did not write files, apply, install, start or stop, or read execution results, nor did I declare any bus or integration results.

Next step: Go to Chapter 10, use handover checkpoints to distinguish the evidence layers of driver, interface and bus.

Troubleshooting

• You do not know which drawer applies: Put the item in "Pending evidence." Do not guess from its name.
• Someone posted the official value: Stop sharing and remove content. Responsibility diagrams only keep categories.
• The template looks complete: Still marked as source material. A complete appearance does not mean it has been generated or applied.
• The input schemas do not match the template: Record the two sources separately and mark the gaps. Don't make up the relationship on your own.
• Someone asked for immediate application: Stop. There is no writing, installing, or starting or stopping programs in this chapter.

FAQ

Chapter overview

Bottom line: Draw only a handover checklist. Each checkpoint represents a documentation category, not a local observation or KNX bus result.

Purpose

Use handover checkpoints to separate the evidence layers of programs, drivers, interfaces, and buses.

Prepare

Chapter 9's offline responsibility map with a blank classification sheet; no hardware or logs required.

Time

About 20 minutes

System change

Do not modify Home Assistant; only use pinned sources to establish offline link layer and driver diagnostic models.

Expected result

Distinguish process, driver, interface, and bus evidence without treating startup messages as bus results.

Stop conditions

• The task requires diagnostic mode, hardware access, or a service restart.
• Telegram transmission and physical control are prohibited as driver-verification methods.

Scope and safety boundaries

This chapter only organizes the responsibilities in pinned documents. Do not enable diagnostic mode, do not read local logs, do not access hardware, and do not restart services. The states on the table are category names, not local observations.

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.

Do not connect to the interface or bus. Group reading is prohibited. Group writing is prohibited. Telegram transmission is prohibited. ETS programming or downloads is prohibited. Physical control is prohibited. No program or driver class can certify bus, integration, or device performance.

Core concepts

You can use three paper labels: "Document can be compared", "Document describes failure boundary" and "Insufficient evidence". These words only classify source content. They are not observing start, stop, retry, or hardware reactions.

Preparation and prerequisites

Draw four handover boxes: program, driver, interface, bus. Each box is further divided into two columns: "Pinned Document Description" and "Still Unable to Infer".

• Sources only use locked versions of pinned INI files.
• Use only category labels; do not write "observed on this system" or "occurred on site."
• Do not include paths, endpoints, addresses, hardware names, serial numbers, or log fragments.
• The bus column always remains "No evidence of this chapter".

If data comes from an execution environment, do not put it in this table. Handle it separately under the safe log-sharing guidance; do not rewrite it as a source claim for this chapter.

Steps

1. Draw four stations first. Write the program, driver, interface and bus in order. Write only the name of the responsibility.
2. Classify file relationships. Put each responsibility cited by the pinned source in the document-supported column. Do not claim that settings have been loaded.
3. Classify activation semantics. Place pinned source descriptions of driver settings and failures in the documented-boundary column. Do not write that the system has started or failed.
4. Block interface inference. Noting the driver family name does not prove that the interface exists, is compatible, or is available.
5. Block bus inferences. Note that neither the program nor the driver class can prove telegram, group operations, or bus results.
6. Complete the handover form. The conclusion simply states "Source classification has been completed" or "Insufficient evidence". Do not include local diagnostic conclusions.

Verification and evidence

The finished product is a document-classification table. It divides responsibility among checkpoints and separates supported claims from unsupported ones.

• I divided the process, driver, interface, and bus into four checkpoints.
• My diagnostic statuses are all source classifications, not local observations.
• I put no logs, devices, addresses, paths, endpoints, serial numbers, or live values.
• I did not upgrade the startup or failure semantics to driver, hardware, interface, bus or integration results.

Next step: Go to Chapter 11, use only classification to create an ETS offline preflight table.

Troubleshooting

• Write file semantics into local events: Change back to "Pinned File Description". Remove time, host and observations.
• The driver names seem to match: Only file family categories are retained. Don't claim hardware compatibility.
• Someone provided a forward log: Don't put it in the table. Forward messages also cannot prove the next handover point.
• Someone provides an error log: Don't determine the root cause. It will be handled separately according to the security log process.
• Someone asked for restart confirmation: Stop. This chapter performs offline classification only.
• Someone asked to use the bus to verify: Stop. Verification using telegram, group operations or physical control is prohibited.

FAQ

Chapter overview

Bottom line: Complete only one offline review form. There are only categories in the table and no engineering information. You will not start an ETS project, nor perform any KNX actions.

Purpose

Use classification to complete offline preflight review of ETS responsibilities, approvals and prohibitions.

Prepare

A blank review sheet with designated responsible persons; no ETS, project files or site data required.

Time

About 15 minutes

System change

Do not modify ETS, Home Assistant or KNX; only create a de-identified offline preflight checklist.

Expected result

Classify ETS responsibilities and approval items while keeping programming, download, and group operations outside automation.

Stop conditions

• The task requires opening a real ETS project or copying individual or group addresses.
• No ETS programming, downloads, or group reads or writes are allowed.

Scope and safety boundaries

This chapter performs only paper classification. 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 other identifying information.

Never automate: ETS programming or downloads, group reads or writes, telegram transmission, and physical control are prohibited. Testing is not an exception.

This chapter does not add the repository, install or start it. This site lacks approved immutable artifact/image digest and source-to-build proof. Any execution actions are blocked, and daemons, listeners, or integrated messages cannot be used in place of ETS or bus evidence.

Core concepts

Only four results are used in the entire table: "Classification completed", "Authorization confirmation pending", "Not applicable" and "STOP". They describe review status, not ETS, network, interface, or bus status.

Preparation and prerequisites

Create a worksheet that contains no live values. Put only the following fields:

• Responsibility categories: ETS engineering, Add-on setup, approval, evidence identification.
• Responsible role: Only write the role, do not write the person’s name or account number.
• Source status: documented in a pinned source, pending authorization confirmation, or not applicable.
• Safety classification: Available for offline review, or STOP.
• Prohibited matters: programming or downloading, group operations and telegram. Physical control is prohibited.

Do not attach project files, screens, exported data, or logs. When authoritative values are required, they are only checked in controlled locations by authorized roles; public tables still leave only classifications.

Steps

1. Write down the purpose of the review. Just write "Offline Responsibility and Approval Classification". Do not write any execution goals.
2. Assign four types of responsibilities. Create columns for ETS project, Add-on settings, approval and de-identification review. Just fill in the role.
3. Mark source status. Select only pinned sources, pending authorization confirmation, or not applicable for each column. Do not copy engineering values.
4. Add prohibited categories. Mark programming, downloads, and telegrams as STOP. Mark every group operation as prohibited. Physical control is prohibited.
5. Check identification data. Verify there are no addresses, names, endpoints, devices, serial numbers, secrets or project content.
6. Close with a limited conclusion. As a result, only the categories Completed, Pending Authorization Confirmation, Not applicable or STOP are selected. Do not claim that the ETS, interface, or bus is ready.

Verification and evidence

The finished product is a category review sheet. Another reviewer should be able to see responsibilities, gaps, and stopping points using classification alone.

• I only used the categories Complete, Pending Authorization Confirmation, Not applicable and STOP.
• I have separated responsibilities for the ETS project, Add-on configuration, approval, and evidence.
• There are no individual addresses, group addresses, names, endpoints, devices, serial numbers, secrets, or project contents in the table.
• Programming, downloads, group operations, telegram transmission, and physical control are all marked as never to be automated.

Next step: Go to Chapter 12, just organize the conceptual diagrams of ETS and KNXnet/IP on paper.

Troubleshooting

• You do not know which value applies: Do not look for a value. Enter "Pending authorization confirmation" instead.
• Someone sent a picture of the project: Stop sharing it. Public review forms do not retain screenshots or identifying information.
• Two responsible roles disagree: Mark the item "Pending authorization confirmation." Do not compare actual values in a public table.
• Someone asked to turn on ETS confirmation: Mark STOP. There are no ETS operations in this chapter.
• Someone asked to do a read: Mark STOP. Group reading is still never automated.
• Classification completion is written as System Ready: Change it to "Offline classification completed". All execution results remain unconfirmed.

FAQ

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

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

1. 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."
2. 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".
3. 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.
4. Put down the interface card. The responsibility only says "data transfer boundary". Do not include hardware, names, or settings.
5. Draw lines of responsibility. Write beside each line only "concept handover". Do not include directions, arguments, or action verbs.
6. 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

Chapter overview

Bottom line: Draw only this tutorial's candidate responsibility diagram on paper. Its five cards represent the Home Assistant KNX integration, xknx logic within that integration, the independent KNXD daemon, the KNX interface, and the KNX bus. The arrangement is neither a universal architecture nor a proven live path, and KNXD is not an inherent layer of the integration.

Purpose

Use this tutorial's five candidate responsibility cards to identify roles without drawing them as proven paths.

Prepare

One blank paper and five blank cards; no Home Assistant or onsite materials required.

Time

About 15 minutes

System change

Do not add or configure Home Assistant KNX integration; only read architectural responsibilities from pinned sources.

Expected result

Distinguish xknx logic in the Home Assistant KNX integration, the independent KNXD daemon, and KNX-side responsibilities while keeping candidate topologies and live results unproven.

Stop conditions

• The task requires adding the integration, entering endpoints, or reloading Home Assistant.
• Do not refer to the existence of a version or component as a working integration.

Scope and safety boundaries

Only paper and blank cards are allowed in this chapter. Do not open Home Assistant, KNXD, or ETS; connect or probe anything; reload software; or enter environment data. The five-card diagram is only a candidate responsibility topology, not configuration instructions, a universal layering rule, or evidence of a live path.

Do not add the repository or install or start the Add-on. Those actions may be evaluated separately only when complete isolation, written approval, an approved immutable artifact/image digest, and source-to-build attestation are all present; this chapter does not provide those conditions.

Group reads must not be automated. Group writing is not allowed. Telegrams may not be sent. ETS programming or downloads must not be performed. Do not control physical equipment. Paper diagrams do not prove anything about KNXD, interface, KNX bus, ETS or Home Assistant integration.

Core concepts

Write on all five cards: "Their states are independent; this arrangement is not a universal path." The existence of a file or component supports only its name and documented responsibility, not claims about loading, wiring, transmission, or control.

Preparation and prerequisites

All you need to do is prepare a non-valued worksheet. Draw five empty boxes and leave two columns for "Source Supported" and "Cannot Prove".

• The five cards only contain role names, not host, address, port, secret, project or device data.
• For each card, fill in "Status Unknown" first.
• The candidate relationship line only writes "conceptual responsibility", without drawing direction or parameters, nor does it imply that integration must go through KNXD.
• Have another person review the diagram; the review establishes no configuration steps or live results.
• If someone requests live-environment information, immediately stop the paper process and hand over to the approval process.

Steps

After completion, you only get a paper architecture diagram.

1. Put down the integration table. Write "Manage integration responsibilities within Home Assistant" and add "No evidence that it was added or loaded."
2. Put down the logic table. Write "xknx library/KNX logic is located within the Home Assistant KNX integration boundary" and add "Declaring dependencies does not prove that it is operational."
3. Put down the KNXD card. Write "standalone KNXD daemon; not an inherent layer of the Home Assistant KNX integration." Do not add daemon or listener status to the diagram.
4. Put down the interface table. Write "Keep handover boundaries" and do not include the interface type, name, or live-site status.
5. Put down the bus table. Write "Onsite network responsibility; no evidence of results in this chapter."
6. Mark candidate relationships. No directional arrows are used; each line is marked only with "Responsibility of this Teaching Candidate" and finally "Not a common or proven path; no settings, connections, or success claims."

Verification and evidence

The qualified results are five responsibility cards, not proof of implementation of the system diagram. You should be able to tell what each card is responsible for, and also tell which card it cannot vouch for.

• I have five separate responsibility cards, and the status of each card is unknown.
• I can tell that the xknx library/logic lies within the Home Assistant KNX integration boundary.
• I separated the standalone KNXD daemon from the Home Assistant KNX integration and did not draw KNXD as an inherent layer.
• I separated the interface from the KNX bus and marked the five cards as non-generic, unproven candidate responsibility topologies.
• The diagram does not contain any environmental information, settings, operating procedures or functional suggestions.
• I do not operate ETS or the Home Assistant integration. I do not read or write groups, send telegrams, or control physical equipment.

Next step: Go to Chapter 14, organize the setting requirements into an offline placeholder worksheet.

Troubleshooting

• xknx and KNXD appear to be the same thing: Rewrite the former as "library/logic used within the integration boundary" and the latter as "independent daemon, not an inherent integration layer".
• The arrows look like the execution flow: Remove directions and verbs, leaving only "candidate responsibilities for this tutorial; neither a universal nor a proven path."
• Component presence is described as operational: Replace the claim with "The pinned source defines this role; execution status is unknown."
• Someone wants to add connection information: Stop. Environmental information will not be collected for paper drawings.
• Someone asked to join the integration confirmation: Stop. There are no setup or test authorizations in this chapter.
• Someone wants to use the bus action to verify: Refuse. No automated group actions, no telegrams, and no physical control.

FAQ

Chapter overview

Bottom line: Create one offline configuration worksheet containing only placeholders, data classifications, and review statuses—never deployable settings, live values, or connection details.

Purpose

Create a Home Assistant KNX offline configuration worksheet with only placeholders and categories.

Prepare

A blank worksheet and paper responsibilities map for Chapter 13; without opening Home Assistant.

Time

About 20 minutes

System change

Do not save Home Assistant KNX settings; use only placeholder text in an offline configuration checklist.

Expected result

Recognize configuration responsibilities and pre-change gates without entering a live endpoint or claiming connection or integration results.

Stop conditions

• The task requires a real host, endpoint, address, secret, or device identifier.
• Steps require saving settings, reloading the integration, or testing the connection.

Scope and safety boundaries

The worksheet cannot be taken for execution. Do not open a running Home Assistant and do not provide YAML, API, pastable field shapes, connection details, or any actual values.

Do not add the repository or install or start the Add-on. Work outside this chapter may be evaluated only when complete isolation, written approval, an approved immutable artifact/image digest, and source-to-build attestation are present; this chapter grants no authorization.

Automated group reads, group writes, telegram transmission, ETS programming or downloads, and physical control are prohibited. The offline worksheet does not prove any results from the KNXD, KNX bus, ETS or Home Assistant integration.

Core concepts

The strongest permitted conclusion for a worksheet is "Field responsibilities are ready for manual review." It does not prove that Home Assistant can accept any settings or establish any connection, integration, or bus result.

Preparation and prerequisites

Draw the table header first without filling in the content value. Only the following governance categories are used in the header.

• Requirement name: write only the general purpose, do not write the environment name.
• Responsible role: record which role provided or reviewed, do not write personal information.
• Semantic placeholder: Use the fixed text "To be supplied by an authorized role."
• Data classification: Choose one from public, controlled, secret, or unknown.
• Source boundary: Record file snapshots and Core version metadata separately.
• Review status and stop reason: only the classification is recorded, not the execution results.

As soon as a cell requires real data or executable shape, stop immediately. Do not fill in from old files, images, memories, or online articles.

Steps

Each step deals only with paper sorting.

1. Write the worksheet title. Mark "Offline placeholder worksheet; cannot be imported, pasted, or executed."
2. Create a requirement column. Only general classifications such as connection responsibilities, integration responsibilities, data-model responsibilities, and approval responsibilities are used, and fields are not simulated.
3. Add placeholder text. Only fill in "To be supplied by an authorized role" in each column, and do not add format hints, default values or example values.
4. Add data categories. Mark it as public, controlled, secret, or unknown; controlled, secret, and unknown are not allowed to be added to the public sheet.
5. Separate the source column. The concepts supported by file snapshots and the integration boundaries supported by Core version metadata are noted separately, and are not written as compatibility guarantees.
6. Do an offline review. Confirm that there are no YAML, API structures, connection details, actual values, or action statements, and finally hand it off to another reviewer.

Verification and evidence

Completion means leaving blanks safely, not filling in the form. Each column must show the responsibility, classification, source, and reason for stopping.

• The worksheet is clearly marked offline and not executable.
• Each column only has general requirements, responsibility roles, placeholder text, and categories.
• File snapshots are recorded separately from Core version metadata.
• No YAML, API structures, connections, hosts, addresses, secrets, device data, or actual values.
• There are no saves, reloads, test connections, or claims about results.

Next step: Go to Chapter 15 and use label cards to organize the entity model.

Troubleshooting

• A placeholder looks like a live value: Change everything back to "To be supplied by an authorized role".
• The worksheet resembles settings that could be pasted: Remove hierarchy, syntax, data shapes, and field order, leaving only governance categories.
• Distinct sources are presented as one version: Split them into two columns that explain each source's supported scope and what it cannot prove.
• Someone asked to see the running settings: Stop the offline process and hand over the explicitly approved read-only scope evaluation.
• Someone asked to test the connection: Stop. This chapter does not provide testing or implementation authorization.
• Blank cells are mistaken for omissions: Add the reason for stopping, don’t guess the value.

FAQ

Chapter overview

Bottom line: Use label cards only to distinguish the roles of a Home Assistant entity, a KNX individual address, and a group address. Each card only records field roles and categories, not values, mappings, payloads, service calls, or control examples.

Purpose

Use record cards to distinguish the roles of entities, individual addresses and group addresses, without recording values or mappings.

Prepare

A few blank cards and the offline worksheet for Chapter 14; no Home Assistant or KNX material required.

Time

About 20 minutes

System change

No Home Assistant entities or group settings are created; only entity models are organized offline.

Expected result

Explain why entities, individual addresses, and group addresses are not interchangeable while recording only field roles and categories, never values or mappings.

Stop conditions

• The task requires providing or guessing a real individual address, group address, or home-device identifier.
• Creating entities, reading or writing groups, transmitting telegrams, and controlling physical equipment are prohibited.

Scope and safety boundaries

Cards only hold concept tags. Do not include identification strings, address values, corresponding values, mappings, data contents, payloads, configurations, control or service calls, nor any control context of the physical equipment.

Do not add the repository or install or start the Add-on. Work outside this chapter may be evaluated only with complete isolation, written approval, an approved immutable artifact/image digest, and source-to-build attestation; this chapter grants no authorization.

Group reads must not be automated. Group writes, telegram transmission, ETS programming or downloads, and physical control are prohibited. Cards do not certify any behavior or result for a Home Assistant entity, integration, KNX bus, ETS project, or device.

Core concepts

Even if the label text is clear, the field value, mapping, data direction, type, or state cannot be guessed from the name. In the absence of authorization evidence, always leave "pending confirmation".

Preparation and prerequisites

Draw only four spaces on each blank card. Don't imitate the settings screen of Home Assistant or KNX.

• Purpose label: write only general software usage.
• Data semantics: Just write "pending source confirmation".
• Field role: Record only the entity, device-identity, or shared-communication-topic classification; do not record any mapping.
• Evidence status: Use only “supported by a pinned source,” “pending confirmation,” or “not applicable.”
• At the end of the card page: write "Cannot be imported, cannot be called, and cannot be controlled".

If the general purpose also reveals home, room, person, or device information, switch to a more abstract label. You do not need to add examples to make the card look complete.

Steps

The finished product is an offline classification card, not an entity list.

1. Create purpose cards. Put only one general purpose per card and avoid family, room, equipment or person names.
2. Add data semantics. Record the type of meaning needed for the model; if there is no support from the pinned source, write "to be confirmed by the source".
3. Add the field-role section. Only classify as entity, device identity or shared communication topic role, do not write any value, mapping, direction, content or format.
4. Add the evidence-status field. Mark the file concept and Core version metadata separately, and do not write the two as execution evidence.
5. Do a de-identification check. Remove identification strings, home contexts, payloads, calls, configuration structures, and any control hints.
6. Close the card set. Write "Only for paper review; physical, integration, and bus status unknown" on the entire stack of cards.

Verification and evidence

Once you can distinguish the entity and device identities, shared communication topics and evidence at a glance, you are done. Any fields that require guesswork should remain pending confirmation.

• I can explain that the entity is the user-facing record card/semantic object, the individual address is the identity of a KNX device, and the group address is the shared communication topic that KNX is designed to use.
• I know that the three are not interchangeable. Each card only records the purpose, data semantics, field role and evidence status.
• All purposes use de-identified generic labels.
• Cards have no address values, mappings, identifiers, payloads, service calls, configuration structures, or control examples.
• Names are not to be relied upon as evidence of data direction, type, or site status.
• I didn't create the entity. I'm not allowed to perform group actions, send telegrams, or control devices.

Next step: Go to Chapter 16, perform safety classification before any action occurs.

Troubleshooting

• A label resembles a live field name: Change to general use, removing family, space, equipment and people clues.
• Someone wants to infer data meaning from a name: Replace the inference with "pending source confirmation." Names are not evidence of type.
• A value appears in the field-role section, mapping, or direction: Remove immediately, leaving only categories for entities, device identities, or shared communication topics.
• The card looks ready to import: Remove the setting shape and order, and add the unexecutable mark.
• Someone requests a service call or control example: Refuse. This chapter only deals with offline models.
• Screen status is treated as bus evidence: Limit the conclusion to a software observation; this chapter provides no live-environment results.

FAQ

Chapter overview

Bottom line: Classify everything first; this chapter performs no tests. You will divide the proposals into four categories: safe, isolated-test, approval-required, and never-automate; if a gate is incomplete, stop on paper.

Purpose

Use a four-category matrix before any action to determine whether the proposal can continue.

Prepare

A blank classification ticket with a placeholder-only text description of the proposal; no test environment is required.

Time

About 20 minutes

System change

No live-environment testing is performed; only test cases are separated offline into evidence and safety categories.

Expected result

Distinguish the four safety classes while keeping every environment-specific result unproven.

Stop conditions

• Connecting to a KNX bus, transmitting telegrams, reading or writing groups, and controlling physical equipment are prohibited.
• Evidence of isolation, written approval, stop conditions, or recovery is incomplete.

Scope and safety boundaries

A classification ticket is not permission to execute. This chapter does not connect, launch, reload, change, or collect live results. When a proposal contains multiple actions, they must be split and the most stringent category among them must be adopted.

• Safe: Offline read-only pinned sources, or stubs that do not access the execution environment at all; may not start daemons, touch endpoints or devices, or send KNX telegrams.
• Isolated test: Evaluate a proposal only when it has clear written approval, a non-production test environment, administrator presence, limited network exposure, and a proven stop-and-recovery plan. Physical bus-isolation testing is limited to separately approved exercises that genuinely require it. For lifecycle-only exercises, all KNX interfaces, USB/device mappings, physical buses, production KNX networks, ETS projects, and physical loads must remain disconnected. If any condition is missing, do not proceed.
• Approval required: Any proposal to review or change the running environment must first have clear written approval, limited maintenance scope and data identification. Even read-only viewing of the live/running environment requires approval and does not automatically make it safe; it cannot transmit KNX telegrams, perform ETS actions, or have physical control.
• Never automate: Guide or automation may not group read, group write, send telegram, execute ETS programming or downloads, connect to KNX interface or bus, collect or publish environment identification data, or physically control under any circumstances; the test bus is no exception. There are no gates to change this classification.

Joining the repository, installing or starting must also have all gates for isolation testing, as well as approved immutable artifact/image digest and source-to-build attestation. Stop if conditions are incomplete; this chapter does not perform these actions.

Core concepts

Evidence also has limits. The document only proves the content of the document; the approval only proves the scope of approval; the isolation plan only proves the preparation conditions. None proves a result for daemon, listener, KNX bus, ETS or Home Assistant integration.

Preparation and prerequisites

First make a completely offline classification ticket. If any field is unknown, write "Unknown and Stop."

• Goals and non-goals: Write in one sentence what you want to answer, and specify which systems you will not touch.
• Atomic actions: Each column can only have one offline reading, live/running environment viewing, change or transfer action; the two types of reading cannot be confused as safe.
• Environment category: Write offline, isolated-test candidate, or running environment; do not enter identifying information.
• Approval evidence: Record the approving role, scope, and validity policy; verbal consent does not count.
• Isolation evidence: Record physical isolation, non-production equipment, and physical loads disconnected from the production environment.
• Stop and recovery: First record trigger conditions, baselines, responsible roles, and escalation methods.
• Evidence limit: What can be said at most after writing is completed, and what must not be said.

Steps

After completing the process, no action will be performed.

1. Write down the smallest question. Remove sentences that preset live-environment outcomes, leaving only questions to review.
2. Break it down into atomic actions. Separate read, view, change, start and send; stop if not clear.
3. Identify never-automate actions first. Group reading and writing, telegram transmission, ETS programming or downloads, and physical control are not allowed. When any of these items appear, they are marked as never to be automated and removed.
4. Classify approval-required actions. All views or changes to the live/running environment are marked as requiring approval; read-only viewing is no exception. Stop without clear written approval, scope or de-identification.
5. Check the isolated-test gate. Verify written approval, a non-production test environment, administrator presence, limited network exposure, and a proven stop-and-recovery plan item by item. For lifecycle-only exercises, record that all KNX interfaces, device mappings, physical buses, production networks, ETS projects, and physical loads remain disconnected. Adding a repository, installing, or starting software also requires approved immutable provenance.
6. Confirm the safe class. Only offline read-only pinned sources, or placeholder work that does not access the execution environment at all and has no side effects, can be marked as safe.
7. Seal classified tickets. Note down the reasons for stopping, the evidence limit and pending items, and mark them as "not yet executed".

Verification and evidence

A valid classification ticket can prevent an unsafe action before execution. It contains no commands, test programs, or execution results.

• Each atomic action has only one four-category label, and in case of conflict, a stricter category is adopted.
• The safe-category items are all offline read-only pinned sources, or placeholder work that does not access the execution environment at all and has no side effects.
• Explicit approval, a non-production environment, administrator presence, limited network exposure, disconnection conditions, stop conditions, and recovery gates are all visible for an isolated-test candidate.
• Approval-requiring categories have clear written approval, limited scope, and de-identification requirements; read-only viewing of live/running environments is also listed in this category.
• Never automate items have been removed and there are no directives or alternative testing methods.
• All environment, bus, ETS and Home Assistant integration results remain unproven.

Next step: Go to Chapter 17, organize the paper management boundaries of backup and restore.

Troubleshooting

• A column acts like two categories at the same time: Break it down into smaller actions and apply the stricter categories first.
• Only verbal consent: Considered not approved and remains stopped.
• Only logical isolation: Does not count as isolation testing; must comply with canonical isolation gate. When only conducting lifecycle drills, all KNX interfaces, device mappings, physical buses, production networks, ETS projects and loads must be disconnected.
• No restoration baseline: Do not enter any change candidates, first complete the plan on paper.
• Add or install missing provenance: Stop, do not add the repository, do not install, do not start.
• Someone wants to change the prohibited action to a manual procedure: Refuse. Changing tools does not change the safety classification.
• Test results begin to appear on classified tickets: Remove results. This chapter only does pre-execution classification.

FAQ

Chapter overview

Bottom line: Define on paper the types of data you want to save, restoration roles, and the security evidence index. You do not create a backup in this chapter, nor will you press any backup or restore buttons.

Purpose

Define backup scopes, restore responsibilities, and evidence indexes without environment values.

Prepare

A blank worksheet and a pinned source; without opening a project or execution environment.

Time

About 20 minutes

System change

Do not create or restore real environment backups; only compile de-identified offline backup and restore drill lists.

Expected result

Define backup scope, custody, checks, and restoration gates without treating the existence of a backup as proof that it can be restored.

Stop conditions

• A backup or record contains confidential, environment-identifying, or unapproved content.
• The task requires restoring a backup or overwriting state in a real environment.

Scope and safety boundaries

This chapter works only on paper. Read only pinned sources and fill out forms with "Data Category" and "Responsible Role". Read-only views of any running environment are approval-required and will not become safe just because it makes no changes.

• Safe: Only offline read-only pinned sources, or no access to placeholder categories of the execution environment at all.
• Isolated test: Projects with clear written approval, a non-production test environment, administrator presence, limited network exposure, and a proven stop-and-recovery plan can be evaluated; this chapter does not perform them.
• Approval required: Viewing or changing the live/running environment falls into this category; the same goes for read-only. This chapter does not provide such procedures.
• Never automate: Do not read or write groups, send a KNX telegram, perform ETS programming or downloads, connect a KNX interface or bus, or control physical equipment. The test bus is no exception.

Joining the repository, installing or starting also requires full isolation gates, written approval, approved immutable artifact/image digest and source-to-build attestation. Stop if any item is missing; these actions are not performed in this chapter.

Core concepts

The backup role manages retention and expiration. The restoration role decides when a separate restoration exercise may begin. The independent-review role checks scope, evidence limits, and privacy. A statement that "someone is responsible" cannot replace these three distinct assignments.

Preparation and prerequisites

Prepare a blank index that does not contain live values. Only fill in each field with category, role or status.

• Purpose column: Only write save, audit or restore plan, do not default to restore.
• Scope column: Lists data categories, exclusion categories, and retention policies, but does not list project names or content.
• Responsibility column: lists the roles of creation, custody, restoration decision-making, independent review and exception approval.
• Evidence column: Lists source version, creation record type, completeness status, review status and evidence gaps.
• Privacy check: Confirm that there are no secrets, accounts, endpoints, hosts, networks, paths, serial numbers, addresses, scopes, or environment names.

Time data rules: Environment/event timestamps, log timestamps, backup creation times, execution times, or any time that can be associated with family activities/system events are not allowed. When there is a real need for governance, and the data is not derived from live events and the environment cannot be identified, the reviewed formalized policy deadline or abstract expiration status can be used. When precise dates are not required, relative/status classifications such as "not expired", "to be renewed", and "expired" are preferred.

Pinned sources do not have precise backup or restore procedures for ETS projects. Therefore, programs, formats, compatibility and restoration results are marked as unverified.

Steps

The following six steps only organize paper management information. You will not open a formal project, nor create, import, or overwrite any content.

1. Write down the purpose of saving. Explain in one sentence why backup management is needed, and state that this chapter does not perform backup or restore.
2. Define the backup scope. Only the data categories that need to be saved and those that must be excluded are listed. Do not fill in any live values.
3. Assign responsibilities. Assign custody, restoration decision-making, independent review and exception approval roles respectively. Then write the retention policy and handover conditions.
4. Create a privacy-safe index. Document status, source version, retention policy and evidence limit for each preservation category. Replace actual content with “Redacted” or "Pending Verification".
5. Mark the evidence limit. Separate "copy existence", "offline integrity record" and "recoverability". The first two items cannot endorse the last item.
6. Submit the index for independent review. Confirm that the index does not identify the environment or state unverified results as facts. If anything is missing, return it for correction.

When filling in the deadline: Environment/event timestamps, log timestamps, backup creation times, execution times, or any time that can be associated with family activities/system events are not allowed. When there is a real need for governance, and the data is not derived from live events and the environment cannot be identified, the reviewed formalized policy deadline or abstract expiration status can be used. When precise dates are not required, relative/status classifications such as "not expired", "to be renewed", and "expired" are preferred.

Verification and evidence

The completion criterion is that the index is safe for review, not that the environment is restorable.

• The purpose of preservation, inclusion and exclusion categories are all clear, and there are no environmental values.
• Custody, restoration decision-making, independent review and exception approval each have responsible roles.
• The evidence index only contains category, status, retention policy and source version.
• Environment/event timestamps, log timestamps, backup creation times, execution times, or any time that can be associated with family activities/system events are not allowed.
• When there is a real need for governance, and the data is not derived from live events and the environment cannot be identified, the reviewed formalized policy deadline or abstract expiration status can be used. When precise dates are not required, relative/status classifications such as "not expired", "to be renewed", and "expired" are preferred.
• A copy's existence and offline integrity are not described as proof of a successful restore.
• Accurate backup procedures, compatibility and restore results are still marked as unverified.
• All environment, KNX bus, ETS and integration results remain unproven.

Next step: Go to Chapter 18, check for minimum exposure with an offline worksheet.

Troubleshooting

• The scope reads like a list of contents: Replace it with data categories and remove names, locations, and values.
• The restore responsible role cannot be found: Leave unassigned and stop. Don't automatically assume that the custodial role is a restoration decision-making role.
• A copy is described as restorable merely because it exists: Limit the conclusion to “copy recorded,” and mark parsing, compatibility, and restoration as unverified.
• Index contains sensitive information: Stop sharing and withdraw the copy. Minimize it again and give it to a different role for review.
• Someone asked for the operation screen: Refuse. There is no live backup or restore procedure in this chapter.
• Someone asked to join or start the tool: Stop. In the absence of an approved immutable provenance gate, it will not join, install or start.

FAQ

Chapter overview

Bottom line: Use only offline worksheets to check secrets, permissions, network exposure, and approval records. You will not modify firewalls, credentials, accounts, networks, or running systems.

Purpose

Identify four categories of gaps in minimum exposure governance and assign responsibilities and stop states to each gap.

Prepare

A blank four-column worksheet with pinned sources; do not collect live-environment values.

Time

About 15 minutes

System change

Do not modify permissions, secrets, or networks; perform only an offline minimum-exposure review.

Expected result

Identify gaps in permissions, secrets, network exposure, and approval workflows without disclosing live-site data.

Stop conditions

• The task requires exposing credentials, tokens, endpoints, accounts, or network topology.
• The task requires relaxing permissions, opening a network, or disabling security controls.

Scope and safety boundaries

The worksheet is not a permission to change. Safe work is limited to offline, read-only pinned sources or placeholder classification that never accesses an execution environment. Read-only viewing of any live/running environment is approval-required.

• Safe: Only field categories, responsibility roles and gap status are sorted, and live-environment content is not read.
• Isolated test: The project must have clear written approval, a non-production test environment, administrator presence, limited network exposure, and a proven stop-and-recovery plan; not covered in this chapter.
• Approval required: Any proposal to view or change the running environment falls into this category, even if it is a read-only view.
• Never automate: Do not read or write groups, send a KNX telegram, perform ETS programming or downloads, connect a KNX interface or bus, or control physical equipment. The test bus is no exception.

Joining the repository, installing or starting also requires full isolation gates, written approval, approved immutable artifact/image digest and source-to-build attestation. Stop if any evidence is lacking.

Core concepts

Secrets grant access directly, while environment-identifying data reveals asset relationships. Neither belongs in public guides, screenshots, log excerpts, work orders, or submission records.

Preparation and prerequisites

Draw four columns before collecting any information. The column names are Secrets, Permissions, Network Exposure, and Approval Records.

• Each column has requirements, ownership roles, approval status, expiration policy, revocation method and evidence limit.
• The secret column only writes "exists", "not entered into the record", and "pending controlled review", and no values are copied.
• In the permission column, only the ability categories such as reading, changing, approving or reviewing are written, and the account number or person's name is not filled in.
• In the network column, only the trust boundary category, requirements, and deadline policies are filled in. Do not fill in the host, address, endpoint, or topology.
• In the approval column, only the approval role, controlled record reference, scope and abstract expiration status are written, and no signature or personal certification is included.

Time data rules: Environment/event timestamps, log timestamps, backup creation times, execution times, or any time that can be associated with family activities/system events are not allowed. When there is a real need for governance, and the data is not derived from live events and the environment cannot be identified, the reviewed formalized policy deadline or abstract expiration status can be used. When precise dates are not required, relative/status classifications such as "not expired", "to be renewed", and "expired" are preferred.

Immediately stop the worksheet process when secrets, environmental identification, unknown sources, requests to extend rights, or requests to modify security controls occur.

Steps

This review will only produce a list of gaps. It does not produce settings, commands, or live results.

1. State the necessary purpose first. Each column addresses only one requirement. Mark any item without an explainable purpose as a risk to remove.
2. Check the secret column. Confirm that public records only show confidential processing status. Sharing stops when any secret value appears.
3. Check the permissions column. Separate reads, changes, approvals and reviews. Record missing expiration policies, revocation methods, or owning roles as gaps.
4. Check the network-exposure column. Use trust boundary categories to describe necessary interfaces. Exposures that do not have a purpose, role, or duration policy are listed as gaps.
5. Check the Approval Record column. Verify that each exception has scope, approval role, expiration policy, revocation conditions, and controlled record references.
6. Do an independent review. Check four columns and data minimization by different roles. The conclusion should only be written as "complete", "with gaps" or "stopped due to insufficient data".

When filling in the deadline: Environment/event timestamps, log timestamps, backup creation times, execution times, or any time that can be associated with family activities/system events are not allowed. When there is a real need for governance, and the data is not derived from live events and the environment cannot be identified, the reviewed formalized policy deadline or abstract expiration status can be used. When precise dates are not required, relative/status classifications such as "not expired", "to be renewed", and "expired" are preferred.

Verification and evidence

The valid result is a de-identified governance list. It does not indicate that any controls have been applied in a production environment.

• The secret field has no credentials, tokens, sessions, passwords, cookies, or retrievable connection information.
• The permission column separates read, change, approval and review, and records deadline policies and cancellation responsibilities.
• The network exposure column contains only requirements, trust boundary categories, owning roles, and expiration policies.
• Each exception has an approval role, scope, abstract expiration status, and revocation conditions.
• The record has no host, endpoint, account, path, serial number, address, topology or environment name.
• Environment/event timestamps, log timestamps, backup creation times, execution times, or any time that can be associated with family activities/system events are not allowed.
• When there is a real need for governance, and the data is not derived from live events and the environment cannot be identified, the reviewed formalized policy deadline or abstract expiration status can be used. When precise dates are not required, relative/status classifications such as "not expired", "to be renewed", and "expired" are preferred.
• All field controls, execution environments, buses, ETS and integration results remain unproven.

Next step: Go to Chapter 19, put the link symptoms in the file into the offline distribution table.

Troubleshooting

• A field appears to require live values: Change it to a data category and mark “Controlled review required.” Do not bring values into the worksheet.
• A permission has no owning role: Mark it as a governance gap and stop adding new permissions.
• Network exposure has no expiration policy: Mark it incomplete. Do not replace a missing decision with permanent exposure.
• Only verbal approval exists: Treat the item as unapproved and keep it stopped.
• Someone asked to modify the firewall or credentials: Refuse. This chapter is an offline worksheet and does not provide firewall, credential or live system change procedures.
• The environment can still be identified after masking: Remove more context, or use text-only category summaries instead.

FAQ

Chapter overview

Bottom line: You only put the symptom concepts in the pinned source into the offline triage table. You will not restart the service, try changing drivers, probe endpoints, connect to the bus, or post any previous internal errors.

Purpose

Classify link symptoms by evidence layer using pinned sources, and limit conclusions to what each type of evidence supports.

Prepare

A blank symptom triage sheet and two pinned sources; no logs or execution environment required.

Time

About 20 minutes

System change

Do not restart services or connect to the bus; only classify link-failure evidence offline.

Expected result

Classify symptoms by process, listener, driver, interface, and bus layer without presenting diagnostic attempts as success.

Stop conditions

• The task requires restarting a driver, service, interface, or KNX connection.
• A log still contains a host, endpoint, device path, serial number, or secret.

Scope and safety boundaries

This chapter only classifies documents, not the live environment. Safe work is limited to offline, read-only pinned sources or placeholder classification that never accesses an execution environment. Read-only viewing of any live/running environment is approval-required.

• Safe: Read only locked add-on and upstream files and copy abstract symptom categories.
• Isolated test: Alternative projects must first have clear written approval, a non-production test environment, administrator presence, limited network exposure, and a proven stop-and-recovery plan; they are not covered in this chapter.
• Approval required: Viewing or changing the running environment falls into this category; even read-only access is not safe. Observation procedures are not provided in this chapter.
• Never automate: Do not read or write groups, send a KNX telegram, perform ETS programming or downloads, connect a KNX interface or bus, or control physical equipment. The test bus is no exception.

Joining the repository, installing or starting also requires full isolation gates, written approval, approved immutable artifact/image digest and source-to-build attestation. Stop if any item is missing.

Core concepts

Process-level vocabulary can describe only process concepts. The listener layer vocabulary can describe only the listening responsibility. Driver family and file-level startup-failure concepts can only define the scope of the driver file. Neither the interface nor the bus results are included in the evidence in this chapter.

Preparation and prerequisites

Prepare only two pinned sources and a blank table. Don't bring in internal logs, screenshots, or memorized errors.

• The source column only records pinned source identification and version boundaries, not local data.
• The layer field uses five categories: process, listener, driver, interface and bus.
• The symptom column only writes the abstract state concepts in the file, not what has been seen in a certain environment.
• In the upper limit column of evidence, first write "Only supports documentation classification, not local results."
• Stop if a column has an unknown source, makes a cross-layer inference, requests a live-environment action, or contains identifying information.

Earlier internal link errors are not a public result of this chapter. Even if the text is obscured, it cannot be rewritten as having been observed, reproduced or verified by this site.

Steps

The following process performs documentation classification only. Every step stops on paper.

1. Pin the source. Confirm that symptom concepts are derived from the pinned versions listed in this chapter. Stop if the source is unknown.
2. Choose a layer. Put concepts into the process, listener, driver, interface or bus column according to the document responsibility. If there is insufficient information, mark it as unclassified.
3. Write an evidence limit. Program vocabulary cannot prove listener; listener vocabulary cannot prove endpoint; driver vocabulary cannot prove interface or bus.
4. List unknown items. Leave compatibility, hardware, wiring, endpoint reachability, and bus status as unknown without choosing a plausible root cause.
5. Exclude internal results. Delete any "seen", "reproduced", "displayed locally" or similar descriptions, leaving only the abstract classification supported by the document.
6. Submit to independent review. Make sure each column has source, level, evidence limit and unknown items, and there are no live action prompts.

Verification and evidence

The completed result must be a documented symptom classification table. This site has no local observation sources and no local link results.

• Each symptom concept can correspond to a pinned source and a single primary level.
• Programs, listeners, drivers, interfaces, and buses are not mixed into a conclusion about success or failure.
• Each column clearly states what is supported and what is not supported.
• Hardware, wiring, compatibility, endpoint reachability and bus status remain unknown.
• Early internal bugs have not been published as observations, reproduction or verification results.
• There are no hosts, endpoints, paths, serial numbers, accounts, secrets, addresses, ranges, or times in the table.

Next step: Go to Chapter 20, continue to sort out the offline fault classification of USB and serial interfaces.

Troubleshooting

• A symptom appears to fit two layers: Divide into two columns, or mark it unclassified. Don't choose the root cause by guesswork.
• Only generic error words are available: Retain the item as unclassified pending precise documentary evidence.
• Someone posted an internal error: Move out of public forms, stop sharing, and return to the controlled internal process.
• Someone asked for a reboot: Refuse. There is no restart procedure in this chapter.
• Someone asked to switch driver or detect endpoint: Refuse. There is no driver trial or endpoint probe procedure in this chapter.
• Someone asked to connect or test the bus: Refuse. There is no bus procedure in this chapter, nor is it verified by telegram or physical control.
• The classification text leaks environment details: Remove the column and recreate it using the abstraction from the source.

FAQ

Chapter overview

Bottom line: Use only three types of symptom cards without live-environment values, and the offline judgment evidence is "missing candidate item", "candidate path category change" or "driver-category clue". You do not look at the device list, copy paths or serial numbers, and you do not try the driver, reboot, or touch the bus.

Purpose

Complete an offline decision tree for USB/serial interfaces using three categories of de-identified symptoms.

Prepare

A blank three-branch worksheet with pinned sources; no USB device, logs, or execution environment required.

Time

About 20 minutes

System change

Do not access or restart a USB/serial interface; organize only de-identified offline fault classifications.

Expected result

Distinguish evidence of a missing device, changed path, and driver failure without claiming that an interface or hardware works.

Stop conditions

• Do not copy the actual device path, USB serial number or host data.
• Stop if the task would require reconnecting hardware, loading a driver, restarting a service, or accessing the bus.

Scope and safety boundaries

This chapter only compiles de-identified symptom cards. Safe work is limited to offline, read-only pinned sources or placeholder classification that never accesses an execution environment. Read-only viewing in any live/running environment is approval-required, and this chapter does not provide a viewing method.

• Safe: Read the locked source and create three types of blank cards: "Missing Candidate Item", "Candidate Path Category Change" and "Driver Category Clues".
• Isolated test: Alternative projects must first have clear written approval, a non-production test environment, administrator presence, limited network exposure, and a proven stop-and-recovery plan; they are not covered in this chapter.
• Approval required: This is true for viewing or changing any running environment; approval for read-only does not equal approval for attempts or modifications.
• Never automate: Do not read or write groups, send a KNX telegram, perform ETS programming or downloads, connect a KNX interface or bus, or control physical equipment. The test bus is no exception.

Joining the repository, installing or starting also requires full isolation gates, written approval, approved immutable artifact/image digest and source-to-build attestation. Stop if any item is missing.

Core concepts

The initialization source of Add-on 0.6.1 can describe the interface, USB value conversion and configuration preparation responsibilities of the required device; the upstream 0.14.72 file can describe the driver family and documented diagnostic concepts. Neither source provides a candidate, path, serial number, or result for a specific host.

Preparation and prerequisites

Draw the decision tree before looking for a device. The root node asks only, "Which symptom matches the existing de-identified description?" Mark every other branch "insufficient information."

• Missing candidate card: Just write "the expected category did not produce a candidate"; do not write the candidate content, enumeration results or occurrence position.
• Candidate path category change card: Only write "the reference type is different from the original record"; do not write the old value, new value or device relationship.
• Driver-category clue card: Record only the responsibility categories in the pinned source; list no trial order, compatible models, or loading methods.
• Unknown card: When information is mixed, from unknown sources, or when live-environment values are needed, stop classifying and leave it unknown.

Worksheets may not contain device paths, USB serial numbers, hosts, endpoints, addresses, accounts, secrets, environment names, or times that can be associated with a site. If the material you have contains these contents, do not copy them; return them to controlled privacy processes.

Steps

Each step only processes offline text. You do not need to ask the system to answer any questions.

1. Confirm source boundaries. Only the initialization responsibilities and driver documented concepts described in the locked version are accepted. If there is no source, it is marked as insufficient information.
2. Remove live-site details. Only retain abstract descriptions such as "missing", "different reference categories" or "driver responsibility category"; stop when the material can still identify the environment.
3. Evaluate the first branch. If the description only says that the expected category was not a candidate, add a missing-candidate card; do not guess at hardware, permissions, or reasons.
4. Evaluate the second branch. If the description only says that the reference category is different before and after, add a path-category-change card; do not remember any old values, new values, or enumeration methods.
5. Evaluate the third branch. If the description can only correspond to the driver responsibility or failure concept in the document, put it in the driver-category clue card; do not generate trial suggestions.
6. Limit conclusions. Each card says "Only document classification supported; all live-environment availability not confirmed."
7. Independent review. Confirm by another reader that the branch is single, from a pinned source, has no identifying values, and has no commands, enumerations, tryouts, restarts, or bus actions.

Verification and evidence

The finished product is an anonymous offline decision tree. It is not a diagnosis and does not indicate that any device has been viewed, detected or verified.

• The root node only accepts de-identified symptom statements supported by pinned sources.
• The three branches are precisely the lack of candidate items, candidate path category changes, and driver-category clues.
• Each card has a source category, symptom category, evidence limit, unknown matter, and responsible role.
• There is no device path, USB serial number, host, endpoint, address, environment name, or time to associate.
• There are no commands, device enumeration, driver testing, hardware plugging, service restarting, or bus actions.
• USB, serial interface, driver, KNX bus, ETS, integration, group and physical control results remain unconfirmed.

Next step: Go to Chapter 21, arrange offline source review, approval boundaries and evidence notes into a controlled maintenance rhythm.

Troubleshooting

• The narrative resembles both absence and change at the same time: Mark it as insufficient information and do not select a root cause for it.
• The description says only "USB is broken": This is a conclusion, not a classifiable symptom. Ask for an anonymous symptom category instead.
• Someone provides a real path or hardware identifier: Stop copying and sharing it, then return the material to the controlled privacy process.
• Someone asked for a list of devices: Refuse. There are no enumeration or live viewing procedures for this chapter.
• Someone suggests trying drivers one by one: Refuse. A driver-family name is not a trial list.
• Someone suggested unplugging or rebooting: Refuse. This chapter does not trigger hardware or service actions.
• Someone wants to use bus to prove classification: Refuse. This chapter shall not connect, read, write or transmit any bus data.

FAQ

Chapter overview

Bottom line: You create only an offline change record that lists source review, approval, observation boundary, stop, restore decision and evidence notes in sequence. This log does not provide commands, does not bypass approvals, and does not allow you to operate a running system.

Purpose

Use a six-field offline record to establish a maintenance rhythm that can be stopped, handed over, and cannot bypass approval.

Prepare

A six-field blank change record and pinned source; do not bring in execution environment data.

Time

About 20 minutes

System change

Do not apply settings or start or stop services; only create offline change records and manual gates.

Expected result

Create an offline operating cadence and change-record template that preserves approval, evidence, stop, and restoration responsibilities.

Stop conditions

• Complete isolation, written approval, an immutable artifact/image digest, or source-to-build attestation is missing.
• Group operations, telegram transmission, ETS actions, and physical control are prohibited.

Scope and safety boundaries

Documenting a cadence is not a license to operate. Safe work is limited to offline, read-only pinned sources or placeholder records that never access an execution environment. Read-only access to any live or running environment requires approval and, when approved, must remain within the authorized data categories and scope.

• Safe: Review locked sources, design blank fields, mark evidence levels and responsible roles.
• Isolated test: Alternative projects must first have clear written approval, a non-production test environment, administrator presence, limited network exposure, and a proven stop-and-recovery plan; they are not covered in this chapter.
• Approval required: Viewing or changing the live/running environment falls into this category; read-only approval does not include modification, elevation of privileges, or expansion of data scope.
• Never automate: Do not read or write groups, send a KNX telegram, perform ETS programming or downloads, connect a KNX interface or bus, or control physical equipment. The test bus is no exception.

Joining the repository, installing or starting also requires full isolation gates, written approval, approved immutable artifact/image digest and source-to-build attestation. Stop if any item is missing.

Core concepts

Add-on 0.6.1's managed INI templates, initialization scripts, and service scripts can describe only the source structure, configuration preparation, and daemon calling responsibilities. They are not a deployment record and do not prove the status of the listener, KNX bus, ETS, Home Assistant or hardware.

Preparation and prerequisites

First create six fields, all of which are marked “stopped” by default. Fields that do not have qualifying content may not be filled by maintenance windows, conventions, verbal consent, or administrative authority.

• Source review: Record pinned sources, version boundaries, and the strongest conclusion each source supports.
• Approval: Approved roles, purpose, data categories, expiration policies and controlled record references are recorded, without names or environmental identifiers.
• Observation boundary: Only allowed and disallowed data categories are listed; live read-only still requires additional explicit approval.
• Stop: List stop conditions such as unclear scope, need to change, identification data, or invalid approval.
• Restore decision: Record only the decision-making role, independent approval requirements, stop-and-restore conditions and controlled plan references.
• Evidence notes: Distinguish source facts, approved observations, inferences and unknowns, do not post original content.

Environment or event time, log time, device path, host, endpoint, address, serial number, account number, secret or site name are not allowed. If governance requires a deadline, use reviewed abstract states such as "valid", "pending review", or "expired".

Steps

The six fields must be filled in sequentially offline. If any field is incomplete, stop at that field and return to the responsible role.

1. Complete source review. Document managed templates, initialization responsibilities and daemon calling responsibilities separately; do not treat source content as live-environment settings.
2. Check approval status. Confirm only whether there are controlled records, responsible role, purpose, data category and validity status. If one item is missing, mark it as unapproved and do not create an alternative path.
3. Draw observation boundaries. Use abstract data categories to describe allowable scope and explicit exclusions. If the proposal involves live read-only, it is still marked as approval-required, and this chapter does not provide a read method.
4. Apply the stop rules. Stop if the proposal requires writing or applying settings, starting or stopping services, elevating privileges, connecting systems, contacting hardware, or using ETS. Telegrams, group operations, and physical control are prohibited; record the responsible handoff roles.
5. Document responsibility for restoration decisions. Specify which role will determine whether to restore or not in the independent approval process, and the evidence that must be available before making the decision; do not list candidate actions.
6. Add evidence notes. Each column is marked as source fact, approved observation, inference, or unknown, and the evidence limit and concealment status are written.
7. Second-person review and record closure. A second person confirms the six-field sequence, verifies that approval was not bypassed, and checks for identifying data or operational content. The reviewer then marks the record "complete," "stopped because evidence is missing," or "referred for a separate decision."

Verification and evidence

Qualifying results are traceable to a six-field offline record. It proves only that document fields and manual gates have been reviewed, not that maintenance, changes, or restores have been completed in any environment.

• Source reviews only cite the pinned version and state that no inferences about deployment results can be made.
• The approval field contains purpose, data category, role, valid status, and controlled references; there are no verbal shortcuts.
• The observation boundary clearly indicates that live read-only is still approval-required.
• The stop field covers changes, privileges, connections, hardware, ETS, telegram, group and physical control requirements that are not allowed to be implemented.
• In the restoration field, only independent decision-making responsibilities and prerequisites are recorded, without execution instructions.
• Evidence notes separate source facts, approved observations, inferences, and unknowns.
• The record contains no commands, identifying information, ambient times, or any description of field successes.

Next step: Go to Chapter 22, put the same set of stop, handover and evidence boundaries into the offline incident runbook.

Troubleshooting

• Approval only says "routine maintenance": The purpose and data scope are incomplete and remain suspended.
• Some people say that read-only does not require approval: Refuse. Read-only viewing for live/running environments is still approval-required.
• The source is different from the live-environment statement: Only version or evidence gaps are recorded, and the system is not modified to achieve consistency.
• The maintenance window has begun: A time window does not authorize an operation; work must remain stopped while any field is incomplete.
• The restore decision-maker and executor are the same: Independent approval, stopping conditions and responsibility boundaries must still be left in separate columns and cannot be omitted.
• Someone asked for a quick command: Refuse. There are no operational commands or authorized detours for this chapter.
• Unsafe evidence summary: The original content will not be published, only "subject to controlled review" and the responsible role will be recorded.

FAQ

Chapter overview

Bottom line: When an incident occurs, first stop unauthorized activity and contact the responsible person. Then use an offline form to classify symptoms, record decisions that contain the risk, protect privacy and security evidence, and hand off escalation and recovery responsibilities. This chapter does not probe, restart, reconfigure, transfer data from, or repair any live system.

Purpose

Use the five-field offline runbook to get incidents to the right people without triggering a live-environment investigation or remediation.

Prepare

A five-box event table without environmental values and a list of existing responsible roles in the organization.

Time

About 15 minutes

System change

Do not restart, restore, or control a live system; create only a de-identified offline incident-response runbook.

Expected result

Classify incident symptoms, preserve de-identified evidence, and assign stop and recovery decisions without performing live response actions.

Stop conditions

• The incident involves unexpected physical movement or a safety risk, or requires the person responsible for the site to take over immediately.
• Unapproved service actions, telegram transmission, group operations, and physical control are prohibited.

Scope and safety boundaries

"Stop" means to stop your own unapproved activity and scope expansion, not to stop production services. Safe work is limited to offline read-only pinned sources, blank forms and anonymous categories. Read-only viewing of any live/running environment is approval-required; this chapter does not provide viewing, detection, or repair methods.

• Safe: Fill in the de-identified symptom category, human responsibility role, stop status, and controlled evidence reference.
• Isolated test: Alternative projects must first have clear written approval, a non-production test environment, administrator presence, limited network exposure, and a proven stop-and-recovery plan; they are not covered in this chapter.
• Approval required: Viewing or changing any running environment falls into this category; the urgency of the event does not automatically cancel approval.
• Never automate: Do not read or write groups, send a KNX telegram, perform ETS programming or downloads, connect a KNX interface or bus, or control physical equipment. The test bus is no exception.

Joining the repository, installing or starting also requires full isolation gates, written approval, approved immutable artifact/image digest and source-to-build attestation. Stop if any item is missing.

If there are concerns about the safety of people, buildings, door locks, lighting, air conditioners, actuators or other entities, stop using this technical form and immediately contact the live-environment person in charge and safety professionals in accordance with the organization's existing emergency procedures.

Core concepts

Pinned sources help distinguish initialization responsibilities, daemon-invocation responsibilities, and documented driver-diagnostic classes. They do not prove the cause, impact, or recovery of a real incident; the disappearance of error text or program-level descriptions does not prove the state of the KNX bus, ETS, integration, or hardware.

Preparation and prerequisites

Prepare a blank five-field form and a list of roles. Collecting excessive information during an incident can expose private data, and recording adjacent events can encourage an unsupported causal inference.

• Symptom classification: Only the function categories, source categories and unknown items that can be described by the user are recorded, and the equipment, address or site name is not recorded.
• Containment decisions: Record decisions about personnel activity, such as "Stop unapproved trial and error," "Restrict public sharing," or "Wait for the responsible role." Do not record system actions.
• Privacy security evidence: The disclosure list only records the evidence category, controlled storage reference, concealment status and evidence limit.
• Escalation responsibility: Use roles such as incident command, live-environment security, privacy review, product responsibility, or external expertise, and leave names and contact information blank.
• Recovery responsibility: Note who has the authority to make decisions outside of this chapter’s independent approval process and what restrictive statements are required to receive the results.

Environment/event timestamps, log timestamps, execution times, hosts, endpoints, device paths, serial numbers, addresses, account numbers, secrets, or details that may be associated with family activities are not allowed. The order only uses abstract labels such as "earliest known symptom", "follow-up notification", and "post-handover status".

Steps

This runbook only instructs personnel to stop, report and hand over. It does not direct the live system.

1. Stop and find someone first. Stop all unapproved trials and public posts; if there are physical safety concerns, immediately contact the live-environment person in charge and safety professionals in accordance with established emergency procedures.
2. Fill in the symptom-classification field. Select only "User Visible Function Category", "Initialization Responsibility Thread", "Daemon Call Responsibility Thread", "Driver File Type" or "Insufficient Information" without specifying the root cause.
3. Complete the containment-decision field. The incident-command role decides which personnel activities must stop, which public information must be restricted, and who takes over. Do not enter service start or stop actions, configuration changes, connection steps, or hardware measures.
4. Fill out the privacy-safe evidence form. Only the controlled evidence reference, evidence category, concealment status, fact and inference boundaries are recorded. Original material remains in a controlled location by authorized actors.
5. Fill out the escalation-responsibility form. Assign roles that should be taken over based on categories such as security, privacy, source version, or unknown responsibility; if a role is missing, stop and notify incident command.
6. Fill out the recovery responsibility form. Specify the role with authority to initiate independent approval decisions and the responsible role for reporting back the assessment results; do not propose candidate remediation or verification actions.
7. Review and handover. The second reviewer confirms that all five fields are complete, with no identification values or live procedures, and then hands the form to the incident command. The status only says "handover", "stopped because evidence is incomplete" or "waiting for responsible role".

Verification and evidence

The completion standard for this chapter is a clear chain of responsibility, not system recovery. Even if an independent process returns a status, this chapter only accepts handover summaries that have been reviewed, de-identified, and accompanied by an evidence limit.

• Symptom classifications describe only functional or documented responsibility categories and do not have root cause claims.
• The risk-containment decision limits only unauthorized personnel activity and information dissemination; it includes no live-system action.
• Public evidence only has controlled references, categories, masking status, unknown matters and evidence limits.
• Escalation responsibilities clearly identify incident command, site security, privacy review, or other responsible roles.
• Recovery responsibility lies with an independent approval process outside of this chapter, which does not have a remediation or verification step.
• There are no commands, probes, restarts, configuration, telegram, ETS, group, physical or bus actions.
• KNX bus, ETS, integration, group operation and physical control results remain unconfirmed.

Follow-up cadence: Review stop conditions regularly with the deployment assessment, and use Help and downloads for guidance on de-identifying records. These resources still do not authorize live-environment operations.

Troubleshooting

• The notification simply says "The system is broken": Rewrite it as the narrowest user-visible symptom category and the root cause remains unknown.
• Someone has started trial and error: Stop further unapproved actions and record the handoff of responsibility. Do not attempt another action as a remedy.
• The complete log has entered the public channel: Stop reposting, limit dissemination in accordance with organizational privacy procedures, and handle in a controlled location with authorized roles.
• Someone asked to probe the endpoint: Refuse. There are no commands or probes in this chapter.
• Some people suggested restarting or changing settings: Refuse. There are no restart, configuration, or remediation procedures in this chapter.
• Someone asked for ETS, group or telegram verification: Refuse. These actions are not within the incident form and must not be automated.
• Incident command role unknown: Stay stopped and find the person in charge according to the organization's existing reporting chain; do not take over the live system on your own.

FAQ