KNX/EIB Open Source KNX IoT 3rd Party API Server

[Noschvie]

Hallo zusammen,

ich arbeite derzeit an einem Open-Source-Projekt zur Umsetzung eines KNX IoT 3rd Party API Servers gemäß der KNX IoT 3rd Party API Specification 2.1.0.

Ziel des Projekts ist es, bestehende KNX-Anlagen über eine standardisierte REST-Schnittstelle zugänglich zu machen und dabei die von der Spezifikation definierten Ressourcen und Datenmodelle bereitzustellen.

Motivation

Während KNX-Telegramme und Gruppenadressen für die Kommunikation auf dem Bus ideal sind, stellen moderne Anwendungen häufig andere Anforderungen:

• standardisierte REST-Schnittstellen
• einheitliche Ressourcenmodelle
• Zugriff auf aktuelle Zustände
• Zugriff auf historische Daten
• herstellerunabhängige Integration

Genau hierfür wurde die KNX IoT 3rd Party API spezifiziert.

Mein Ziel ist es, diese Spezifikation möglichst vollständig als eigenständigen Server zu implementieren.

Technischer Ansatz

Der Server verbindet sich über KNX/IP mit einer bestehenden KNX-Installation und nutzt den ETS KNX TTL Export als semantische Beschreibung der Anlage.

Aus diesen Informationen werden die in der Spezifikation definierten Ressourcen erzeugt und über die API bereitgestellt.

Beispiele:

HTTP-Endpunkte
GET /api/v2/locations
GET /api/v2/devices
GET /api/v2/functions
GET /api/v2/datapoints
GET /api/v2/timeseries

Die Plattform verwaltet dabei sowohl aktuelle Zustände als auch historische Werte.

Architektur

Die Implementierung basiert auf:

• Docker
• Node.js
• PostgreSQL / TimescaleDB
• KNX/IP Tunneling
• ETS KNX TTL Parsing

Der Fokus liegt bewusst auf einer sauberen Trennung zwischen KNX-Kommunikation, Ressourcenmodell und API-Schicht.

Aktueller Stand

Derzeit arbeite ich an:

• KNX/IP Runtime
• Verarbeitung von ETS-TTL-Exporten
• Aufbau des internen Ressourcenmodells
• Umsetzung der REST-Endpunkte gemäß Spezifikation

GitHub Repository

Der aktuelle Entwicklungsstand ist hier verfügbar:
https://github.com/Noschvie/semantic-knx-gateway

Austausch gesucht

Hat sich hier bereits jemand intensiver mit der KNX IoT 3rd Party API beschäftigt?

Mich würden insbesondere Erfahrungen zu folgenden Themen interessieren:

• praktische Nutzung der Spezifikation
• verfügbare Test- oder Referenzimplementierungen
• Erfahrungen mit ETS-TTL-Exporten
• mögliche Stolpersteine bei der Umsetzung

Ich freue mich auf den fachlichen Austausch und Feedback aus der Community.

[thewhobox]

Hey,
bin auch aktuell an dem IoT Thema dran. (Aktuell die IoT Point API, später dann IoT Router)
Auf der anderen Seite gehst du direkt auf Tunneling? Wird das später leicht Umbaubar sein für Routing oder als Knx IoT Router?

Praktische frage: Funktioniert der Semantic export, wenn man keine Funktionen und Gebäudetopologie in der ETS verwendet?

Werde mir das auf jeden Fall mal nächste Woche genau anschauen

P.s.: Generell vll das Naming überdenken?
Gateway finde ich nicht gerade passend, da ja nicht von KNX zu einem anderem Protokoll Umgewandelt wird. (KNX-Dali zum Beispiel).

ETS KNX IoT export

Das ist ein Semantic Export, nicht unbedingt nur für IoT.

[Noschvie]

Hallo thewhobox, danke für dein Feedback, habe das Naming geändert.

Funktioniert der Semantic export, wenn man keine Funktionen und Gebäudetopologie in der ETS verwendet?

Mit meiner .knxproj Datei funktioniert der Export im TTL Format.

Der KNX IoT Router als Feature klingt spannend, aber auch herausfordernd. Wie genau sieht dein Use Case mit der IoT Point API aus, und welche Hardware verwendest du zum Testen des Stacks? Mich interessiert außerdem schon länger, ob und wie sich der IoT Point Stack in die Tasmota-Plattform integrieren lässt.

Ja, Tunneling mit KNXUltimate als Library. Und ja, KNXUltimate unterstützt auch Routing.
Mein aber: KNXnet/IP Routing sendet Telegramme per UDP Multicast ohne Bestätigung (fire-and-forget), während KNXnet/IP Tunneling jedes Telegramm mit einem TUNNELLING_ACK quittiert und damit eine zuverlässigere Übertragung auf IP-Ebene gewährleistet.

[thewhobox]

Mit meiner .knxproj Datei funktioniert der Export im TTL Format.

Das schon^^
Aber die aktuellen Produktdatenbanken verfügen ja über keinerlei Semantik.
Funktionen habe ich das Gefühl, dass das auch kaum wer verwendet (sind auch teils sehr eingeschränkt nur nutzbar...).
Woher bekommt die ETS also die ganzen Infos, ob das KO nun SwitchOnOff oder InfoOnOff ist?

Wie genau sieht dein Use Case mit der IoT Point API

Ich entwickle aktuell auf einem ESP32S3.
Darüber teste ich KNX IoT über WLAN (ein H2 zum Testen von Thread liegt auch hier, aber erstmal soll es mit WLAN funktionieren).
Ziel ist es damit OpenKNX Applikationen einfach auf IoT portieren zu können.
Meiner Ansicht nach ist RF tot^^

UDP Multicast ohne Bestätigung (fire-and-forget)

Korrekt. Heißt aber auch, wenn du mehrere Linien hast, musst entweder alles auf durchleiten stellen, oder brauchst mehrere Interfaces.
Ist halt immer eine Pro/Contra abwägung.

[Noschvie]

Aber die aktuellen Produktdatenbanken verfügen ja über keinerlei Semantik.

Siehe Projekt https://github.com/Noschvie/semantic.../discussions/1

[thewhobox]

Hinweis: Der Artikel wiederholt sich iwie^^

[Noschvie]

Danke thewhobox, hab's korrigiert.

[thewhobox]

Super danke, war mir nicht klar, dass die ETS da so viel Arbeit rein steckt.


Habs gestern mal ausprobiert.
Erstellen hat geklappt, beim docker-compose.yml hat noch der Image key gefehlt. (dev hab ich nicht probiert)
Verbindung hat Geklappt und Telegramme werden scheinbar auch empfangen.

Der Rest ist ja noch in Entwicklung oder?
Die api reagiert aber gibt natürlich noch 404 zurück.

Wie leicht ließe sich denn der Knxnetip layer gegen einen iot layer austauschen?
Evtl build defines?

[Noschvie]

Gute Frage — ich habe mir das genauer überlegt und denke dass es sinnvoller wäre, das als eigenständiges Projekt umzusetzen statt den KNX/IP Layer direkt zu erweitern.

Die Architektur von semantic-knx-gateway ist bewusst in zwei Hälften geteilt — KNX Bus Zugang auf der Southside, REST API auf der Northside. Ein KNX IoT Router würde eine dritte Rolle einführen: CoAP/S-Mode Kommunikation mit KNX IoT Point API Devices und deren Anbindung an den bestehenden TP Bus. Das passt besser als eigenständiger Layer der semantic-knx-gateway als API Client nutzt — so bleibt semantic-knx-gateway unverändert und der KNX IoT Router ist unabhängig nutzbar.

Ich habe dazu ein neues Repo gestartet:

knx-iot-router — ein Software KNX IoT Router der KNX IoT Point API Devices an klassische KNX TP Installationen anbindet, ohne dedizierte Router Hardware.

Das Projekt ist noch in der Konzeptphase — aber die Architektur ist im README skizziert. Mich würde interessieren ob das die Frage richtig trifft, und ob es in der Community Interesse gibt das gemeinsam weiterzuentwickeln — insbesondere:

• Welche Teile der KNX Spec 3/10/5 sind für einen minimal funktionsfähigen Router zwingend erforderlich?
• Gibt es bereits CoAP/S-Mode Implementierungen die als Basis dienen könnten?
• Welche KNX IoT Point API Devices wären ein sinnvoller erster Interoperabilitätstest?

Freue mich auf die Diskussion hier oder direkt im GitHub.

[thewhobox]

Ein KNX IoT Router würde eine dritte Rolle einführen

Damit hab ich bewusst nicht von einem IoT Router gesprochen.
Meinte eher eben das Empfangen von IoT Telegrammen direkt, anstelle eben von KnxnetIP Telegrammen.
Dadurch bräuchtest auch keine IoT Point API, da du nur liest/schreibst und nicht selbst routen musst.
Der Rest vom 3rd Party Server (die Layer darunter würde davon ja unberührt bleiben.

Zum neuen Repo:

knx-iot-router is just another API client.

Das finde ich ist der falsche Einsatz. So machst du den Router dann nur für das semantic-gw nutzbar?

Welche Teile der KNX Spec 3/10/5 sind für einen minimal funktionsfähigen Router zwingend erforderlich?

3/10/5 und 3/10/6.
Beim Router kommen ein paar Ressourcen dazu, damit er die Zuordnung weiß von href<->ga, sowie wie er die Daten umwandeln muss.

Gibt es bereits CoAP/S-Mode Implementierungen die als Basis dienen könnten?

In C# und C arbeite ich daran. CoAP sollte es aber eig in jeder Sprache libs geben (OSCORE und ECHO sind dabei aber wichtig).

Welche KNX IoT Point API Devices wären ein sinnvoller erster Interoperabilitätstest?

Ich habe die Demo Applikationen von der KNXA genommen.
Ich hab auch mal selbst einen Docker Container erstellt, der einen 2fach Aktor + 2fach Sensor simuliert.

[Noschvie]

Erstellen hat geklappt, beim docker-compose.yml hat noch der Image key gefehlt. (dev hab ich nicht probiert)
Verbindung hat Geklappt und Telegramme werden scheinbar auch empfangen.

Der Rest ist ja noch in Entwicklung oder?
Die api reagiert aber gibt natürlich noch 404 zurück.

Im readme ist der docker compose Befehl unvollständig. Siehe Phase 4 vom RPi Dokument, damit kommen wir weiter. Die End Points sollten alle verfügbar sein.

Phase 4 – Start the Stack and Perform Basic Health Checks

cd ~/knx-iot-api-test

# Start stack with production overlay
docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d

# Check container status (both must be "Up (healthy)")
docker compose -f docker-compose.yml -f docker-compose.prod.yml ps

# Expected result:
# timescaledb Up (healthy)
# semantic-knx-runtime Up (healthy)

# Inspect health status in detail
docker inspect semantic-knx-runtime --format='{{json .State.Health}}' | python3 -m json.tool

# Follow logs
docker compose -f docker-compose.yml -f docker-compose.prod.yml logs -f --tail=50​

[Noschvie]

Von "KNX IoT Router" zu "CoAP/S-Mode Transport in semantic-knx-gateway"

Ja genau — die ursprüngliche Idee eines separaten Software-Routers ist vom Tisch.
Kurz zusammengefasst

Neuer Plan

semantic-knx-gateway
├─ KNXnet/IP Tunnel (existiert)
├─ CoAP/S-Mode Transport (neu) ← einfach nur ein 2. Southside-Adapter
└─ StateEngine (verarbeitet beide identisch)

✅ Vorteil: Schlank, no Router-Logic nötig, nur Transport-Layer

Die Kernidee deines Vorschlags (richtig verstanden?)

"Ein reiner Transport-Layer Switch — nicht Routing, sondern nur ein zusätzlicher Eingang für Telegramme"

Genau das. Der semantic-knx-gateway wird um einen CoAP Server erweitert, der:

1. CoAP PUTs von IoT Devices empfängt (Port 5683)
2. CBOR dekodiert
3. GA aus Datenbank-Mapping auflöst
4. stateEngine.processTelegram() aufruft — identisch wie KNXnet/IP

Keine Routing-Logik, keine Message-Transformation, keine separaten Subscription-Systeme.

Sind wir auf gleicher Wellenlänge? 🎯

[Noschvie]

KNX IoT 3rd Party API Server – v2026.06.24 verfügbar! 🚀

Liebe KNX-Community,

wir freuen uns, die neue Version v2026.06.24 unseres KNX IoT 3rd Party API Servers zu veröffentlichen!

HIGHLIGHTS DIESER VERSION:

✨ Semantic Datapoint Discovery – Datenpunkte aus ETS/TTL werden jetzt sofort erkannt, auch bevor KNX-Telegramme eintreffen

📡 Interactive API Documentation – Neue Swagger UI unter /docs für einfache API-Erkundung direkt im Browser

📊 Verbesserte Subscriptions-Metriken – WebSocket und Datenbankabonnements sind jetzt vollständig integriert im Monitoring

🔧 Offline Datapoint Support – Semantische Datenpunkte mit hasCurrentState Flag zur besseren Unterscheidung online/offline

HIER IST DER DOWNLOAD:
https://github.com/Noschvie/semantic...ag/v2026.06.24

ZUM TESTEN:
Ihr braucht nur die docker-compose.yml, docker-compose.prod.yml und die Konfiguration (env.example + TTL-Export) – das komplette Repo ist nicht nötig. Weitere Details zur Konfiguration findet ihr in der CONFIGURATION.md:
https://github.com/Noschvie/semantic...NFIGURATION.md

Testet gerne die neue Version und gebt uns Feedback!