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.