Der Winter naht: OpenKNX Homematic-Gateway für Thermostate / Mitwirkende gesucht

[coko]

Das OpenKNX Homematic-Gateway ist als experimentelles Projekt für das OpenKNX Reg1-ETH entstanden, zur Evaluation und Demonstration der technischen Umsetzbarkeit auf RP2040 mit Netzwerkanbindung: Homematic-Geräte werden über die XML-RPC-Schnittstelle einer CCU2 (oder kompatibel) angebunden, Status-Werte können abgefragt und Kommandos gesendet werden.

Achtung: Das Projekt ist noch im Alpha-Stadium und die Firmware startet ggf. nach einigen Tagen Laufzeit durch den Watchdog neu. Außerdem werden blockierende HTTP-Requests verwendet, die die Bus-Kommunikation und andere Module beeinträchtigen und es ist nicht möglich, auf Ereignisse von Geräten zu reagieren.

Das enthaltene Homematic-Modul unterstützt bislang folgende Gerätetypen und Funktionen:

• Einen bestimmten Typ von Funk-Heizkörperthermostaten, u.A. mit:
  • Status: Raum-Temperatur, Batterie-Spannung, Ventilposition, Verbindungsstatus
  • Steuerung: Setzen von Soll-Temperatur und Auslösen der Boost-Funktion
• Einen bestimmten Typ von Funk-Zwischenstecker-Schaltaktoren
  • Status: Schalt-Zustand, Verbindugsstatus
  • Steuerung: Schalten, Sperren, Treppenhaus-Schaltbefehl
• Andere Gerätetypen durch eine benutzerdefinierte Konfiguration von Parametern.
  • 5 individuelle definierbare Datenpunkte mit verschiedenen Datentypen und Zugriffsarten

Jedes Gerät kann zudem noch 5 Gruppen zur Status-Aggregation zugeordnet werden.

Weitere in der umgesetzten Applikation enthaltene Module:

• OFM-InternetWeatherModule: Bereitstellung von Wetterdaten durch Online-Dienste
• OFM-LogicModule: Flexible Logiken und Zeitschaltuhren mit Feiertagsberechnung
• OFM-FunctionBlocks: Funktionsbausteine, u.A. zur Wertaggregation
• OFM-ConfigTransfer: Komfortable Konfigurationsübertragung

Mitwirkende gesucht

Da die vorhandene Umsetzung Ihren Zweck erfüllt hat, will ich mich nun gerne wieder anderen OpenKNX-Projekten widmen, die ich noch in der Pipeline habe. Falls überhaupt Interesse besteht (bitte hier melden!), so würde ich noch ein Alpha-Release mit den zuletzt erfolgreich getesteten Modul-Versionen bereitstellen, danach hoffe ich, wenn sich jemand findet zur Weiterentwicklung und Optimierung, insbesondere bei folgenden Punkten:

• Unterstützung für Zugriffsart Event (benötigt XML-RPC-Server; wahrscheinlich nur auf ESP32 möglich): Damit wäre z.B. auch die Nutzung von Geräten wie Tastern möglich, die sonst nicht sinnvoll verwendet werden können
• Asynchronen HTTP(S)-Requests (wahrscheinlich nur auf ESP32 möglich)
• Erweiterte Geräte-Unterstützung
• Konzept für Geräte-KOs
• Direkte Funk-Kommunikation ohne CCU
• Ressourcensparende XML-Verarbeitung
• Gerätescan (Prototyp zum Ermitteln der mit der CCU verbundenen Geräte liegt auch schon vor)
• Anlernen von Geräten aus der ETS-Applikation

OpenKNX-spezifisches Vorwissen ist nicht erforderlich, die Herausforderungen liegen eher außerhalb von KNX. Natürlich würde ich aber auch unterstützen beim Einstieg in die OpenKNX-Entwickler-Welt. Damit könnte das eine interessante Möglichkeit sein, für alle die aktuell Homematic-Geräte nutzen und zukünftig verstärkt KNX nutzen wollen.

Gruß Cornelius

[coko]

(Platzhalter)

[coko]

(Platzhalter für FAQs)

[coko]

(Platzhalter für weitere Informationen)

[tsb2001]

Hi coko,

ich habe das Thema bis gerade übersehen.
Ich hätte eine CCU3, ein paar Rauchmelder, einen Türkontakt, einen Heizkörper-Stellantrieb aus dem Homematic-Portfolio und ein komplettes OpenKNX-Reg1-ETH-Modul, was komplett betriebsfertig im Karton rumliegt, da ich noch keinen Anwendungsfall dazu habe.
Aktuell macht das der HomeAssistant die Brücke zu Homematic, aber ich könnte das problemlos zum Testen davon trennen.

Wenn du Interesse hast; ich würde gerne damit experimentieren.

[coko]

Wenn du Interesse hast; ich würde gerne damit experimentieren.

Sehr gerne. Dann werde ich mal alles auf die neusten Modul-Stände hochziehen für ein aktuelles Release...

CCU3

Stand schon auf der Liste der Dinge die getestet werden sollten. Ich erwarte hier eigentlich höchstens Abweichungen bei der Konfiguration auf Seiten der CCU. Die genutzte Schnittstelle sollte immer noch vorhanden sein. Bisher hatte ich die Umsetzung nur mit einer einzigen CCU2 ausprobieren können.

ein paar Rauchmelder, einen Türkontakt, einen Heizkörper-Stellantrieb aus dem Homematic-Portfolio

Die Stellantriebe werden direkt unterstützt (wenn der bekannte Typ). Rauchmelder und Türkontakte sollten sich als benutzerdefinierte Geräte einbinden lassen. Es gibt ein Dokument in dem Parameter-Namen/-Typen für alle Homematic-Geräte aufgeführt sind. Auf dieser Basis kann dann die Konfiguration erfolgen. Was mit der aktuellen Umsetzung nicht funktionieren kann ist das Reagieren auf Ereignisse wie Tür öffnen/schließen. Das Auslösen von Rauchmeldern natürlich auch nicht (... wobei es klar sein sollte, dass man für nur explizit sichere Lösungen einsetzt). Reaktion auf Ereignisse wäre nach meinem Eindruck die interessante Funktionserweiterung, weil man dann Taster einsetzen könnte...

[tsb2001]

Dann werde ich mal alles auf die neusten Modul-Stände hochziehen für ein aktuelles Release

Wenn du das hast, kurze Info an mich. Dann würde ich das mal auf das Modul via USB bringen und mal gucken, was passiert.

Was mit der aktuellen Umsetzung nicht funktionieren kann ist das Reagieren auf Ereignisse wie Tür öffnen/schließen.

Wenn ich das richtig interpretiere, dann löst du das hier drüber https://www.eq-3.de/Downloads/eq3/do...XmlRpc_API.pdf, oder (über tinyxml)?
Nun habe ich auf dem Homeassistant aktuell das System eingebunden und da kommt alles in Echtzeit. Lösen die das ähnlich; oder gibt es eine andere API zum schnelleren Datenaustausch?

Edit: Ich sehe grade, die verwenden den pyhomematic und nutzen da den XML-RPC-Server und den Client.

[coko]

Wenn ich das richtig interpretiere, dann löst du das hier drüber https://www.eq-3.de/Downloads/eq3/do...XmlRpc_API.pdf, oder (über tinyxml)?
[...] [Homeassistant] verwenden den pyhomematic und nutzen da den XML-RPC-Server und den Client.

Korrekt interpretiert. Die Kommunikation mit der CCU erfolgt über XML-RPC. Die Antworten werden mit TinyXML2 verarbeitet. Wobei TinyXML2 aus dem Blickwinkel eines Mikrocontrollers gar nicht mal so klein ist wie der Name vermuten lässt.

Die aktuelle Implementierung fragt einfach für jedes konfigurierte Gerät regelmäßg (einstellbares Intervall) die aktuellen Parameter-Werte ab (AFAIR über getParamSet). Nach Steuerung des Gerätes erfolgt noch mal ein nachgelagerter Abruf mit verkürztem Intervall.

Der Weg zur Event-basierten Verarbeitung ist in dem von Dir verlinkten Dokument auch mit aufgeführt:

• Du brauchst einen HTTP-Server der die Benachrichtigungen per XML-RPC entgegennehmen kann, wie zu event() beschrieben. Dann kann auf die Kombination von Geräteadresse, Parameter-Name und Wert reagiert werden.
  • Technisch halte ich das für umsetzbar, zumindest auf dem REG1-LAN-TP-Base (mit ESP32). Evtl. kann ich den zumindest schon mal mit in den Release-Build aufnahmen, wenn das schnell machbar ist...
• Über init() kannst Du der CCU dann mitteilen, dass und wohin die Benachrichtigungen gesendet werden sollen