How does the engine derive semantic meaning from an ETS project?

[Noschvie]

When people first encounter this project, a common question comes up:

"Current product databases have no semantics. Functions seem barely used and are heavily restricted. So where does the engine actually get the information whether a communication object is a SwitchOnOff or an InfoOnOff?"

It's a fair question — and the answer is that there is no external semantic database involved. The meaning comes entirely from the ETS project itself, assembled from three sources.

---

1. The device catalog (.knxprod)

The product database does not contain room structures or function assignments, but it does define for every communication object (CO):

• The datapoint type (DPT) — e.g. DPST-1-1 for Switch or DPST-1-8 for Up/Down
• A functional description — e.g. "Switching output", "Status feedback"
• The communication flags (Read, Write, Transmit, Update)

This is the only semantics that exists at the device level, and it comes directly from the manufacturer's .knxprod file.

2. The ETS project file (.knxproj)

In the project itself, the planner links:

• Group address → CO(s)
• Group address → DPT (inherited from the CO, but can be overridden manually)
• Function name, room assignment, building structure — all entered manually by the planner

The distinction between SwitchOnOff and InfoOnOff comes from which COs the planner connects to which group address, combined with the DPT of the CO and the set flags (T/W). A switching output CO with the Write flag mapped to GA 1/1/1 becomes a command datapoint. A status feedback CO with the Transmit flag on GA 1/1/2 becomes a state datapoint.

3. What the KNX IoT 3rd Party API derives from this

The engine reads the KNX TTL export and maps:

According to the KNX Association documentation:
"A Semantic export can be triggered via the menu item 'Export' and then save the project as 'Turtle File Export (.ttl)' or 'Json Linked Data (.jsonld)'."

Source: KNX Association, Semantic export

Source	API field
GA name entered in ETS	title
DPT of the linked CO	datapointType
Write flag on CO	writable: true
Read flag on CO	readable: true
ETS function group (if used)	function resource
Building structure in ETS	location hierarchy

---

The practical implication

The semantic quality of the API output is exactly as good — or as poor — as the ETS project was maintained.

If all group addresses are named GA_001, GA_002, no function groups are created, and room assignments are missing, the API will reflect exactly that. The engine has no way to infer meaning that wasn't put into the project by the planner.

This is not a limitation of this implementation — it is fundamental to the KNX data model. The .knxproj is the single source of truth. The KNX IoT 3rd Party API is a structured mirror of it.

---

What about Functions?

The Functions layer in the KNX information model (and in the API) maps directly to ETS Gewerke / Anwendungsfunktionen. You are right that in practice these are rarely configured in detail, and ETS support for them is limited and inconsistent across versions.

For this engine, function resources are derived from whatever the TTL export contains. In a minimal ETS project with no function assignments, the /functions endpoint will return an empty collection — which is accurate, not a bug.

If richer function semantics matter for your use case, the most practical path today is to enrich the TTL export externally or to map GAs to functions via a sidecar configuration file. This is something being considered for a future roadmap phase.

---

Feel free to comment below if you have questions or run into cases where the semantic mapping doesn't behave as expected.