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
Send each symptom to the correct desk first. A desk label is neither a root cause nor proof of success.
Symptom triage table
Think of it this way: The triage desk first places the file into the process, listener, driver, interface or the most downstream desk based on the symptoms on the incoming file. The reviewer will not judge that the equipment inside is broken just by looking at the outer box, nor will they say that the entire road is open just because a certain document appears.
Formal term: Documented symptom classification for process layer, listener layer, driver layer, interface layer and KNX bus layer.
How this chapter uses it: Using the pinned source, create only an index of the layer to which a symptom may belong. You do not determine hardware, wiring, endpoints, compatibility, or live-site root causes.
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.
- Pin the source. Confirm that symptom concepts are derived from the pinned versions listed in this chapter. Stop if the source is unknown.
- 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.
- Write an evidence limit. Program vocabulary cannot prove listener; listener vocabulary cannot prove endpoint; driver vocabulary cannot prove interface or bus.
- List unknown items. Leave compatibility, hardware, wiring, endpoint reachability, and bus status as unknown without choosing a plausible root cause.
- Exclude internal results. Delete any "seen", "reproduced", "displayed locally" or similar descriptions, leaving only the abstract classification supported by the document.
- 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
Advanced note: The driver family listed in the file is not a compatibility list
Pinned upstream files support driver-family names such as tpuart, ft12, and ft12cemi, along with documented diagnostic-state concepts. They do not prove that an adapter is compatible or that those states occurred in any environment.
Can the listener vocabulary prove that the endpoint is reachable?
No. It only defines listener responsibilities and does not prove endpoints, drivers, interfaces or buses.
The file has the concept of a startup failure. Can it determine hardware failure?
No. Documentation concepts are not sufficient to locate hardware, wiring, compatibility, or environmental root causes.
Can masked internal errors be added to this chapter?
No. This chapter only publishes classifications of pinned sources, not internal or local results.
Can I reboot to see if the classification is correct?
No. This chapter does not provide or authorize any restart, switch or detection actions.
Does the completion of classification mean that the link is restored?
No. The classification table has no execution environment evidence and no link results.
Evidence and sources
Evidence class: source-bounded
Feature crosswalk: listener-knxnet-ip-boundary, upstream-driver-families, documented-driver-diagnostic-states
Pinned sources support only the documented scope. This page does not represent validation of any local environment, hardware, network, or KNX bus.