Mal ein paar
grundlegende Ausführungen, weil bestimmt auch zukünftig Programmierer über dieses Thema stolpern werden.
wedoon hat geschrieben: ↑15.01.2024, 18:52
XML-RPC wird in einer Doku für HmIP als Legacy beschrieben. War wohl früher Standard.
Aber was dann?
Was ist die aktuelle API für CCU3?
Die XML-RPC-API der Schnittstellenprozesse ist weiterhin Standard. Sie ist nicht abgekündigt. Eine Absicht des Herstellers, diese zu ersetzen, ist nicht zu erkennen.
Offiziell von eQ3 dokumentierte APIs für externe Applikationen:
- XML-RPC-APIs der Schnittstellenprozesse
- HomeMatic-Skript-API
Nicht offizielle APIs der CCU, die auch extern genutzt werden können:
wedoon hat geschrieben: ↑15.01.2024, 18:52
Ich will erstmal ohne Addons auskommen.
Fonzo hat geschrieben: ↑17.01.2024, 08:03
Zu seinen Anforderungen gehört eben nicht, noch mal umständlich weitere Add Ons zu installieren.
Die Aussagen sind für mich nicht nachvollziehbar.
Der einzige für mich relevante Nachteil, der bei den aktuell verbreiteten Add-Ons
nicht zutrifft, wäre eine Verminderung der Stabilität der CCU. Ich würde aber sogar behaupten, dass sie für die Stabilität förderlich sind.
(Weiteres siehe unten.)
Fonzo hat geschrieben: ↑16.01.2024, 19:07
Wozu man ein zusätzliches Add On braucht, wenn der Hersteller eQ-3 selber eine Steuerung per XML-RPC API ermöglicht, habe ich noch nie verstanden.
Das neuere XML Add On braucht man genauso wenig, wenn man einfach die Schnittstellen benutzt, die der Hersteller eQ-3 selber zur Verfügung stellt.
Ich gehe im Folgenden mal nicht von dem einfachen Anwendungsfall aus, nur sporadisch einige wenige Datenpunkte zu lesen oder zu beschreiben. Das ist am sinnvollsten, aber nicht am einfachsten, über die HomeMatic-Skript-API möglich. Das Setzen von Schaltzeiten, die zur Gerätekonfiguration gehören, ist schon herausfordernder. Aber dafür haben wir die HomeMatic-Skript-Experten hier im Forum.
Aber da müssen langsam die Alarmglocken angehen: Will man sich auf die eigentliche Anforderung, die Schaltzeiten nach bestimmten Kriterien vorzugeben, konzentrieren, oder sich zusätzlich mit den Netzwerk-APIs der CCU quälen. (Ok, es gibt hier Programmierer, mich eingeschlossen, die haben Bock darauf.)
Wenn der Datenaustausch mit der CCU umfangreicher wird, wenn instantan auf Änderung von Gerätedatenpunkten reagiert werden soll, wenn Gerätekonfigurationen gelesen und gesetzt werden sollen, wenn es auf Performance ankommt, wenn die CCU in ihrem Betrieb möglichst wenig beeinflusst werden soll, ..., dann wird die Implementierung zeitlich intensiv und qualvoll. Die Dokumentation vom Hersteller ist unvollständig und teilweise falsch oder veraltet. Die Rohdaten müssen auf Netzwerkebene mitgeschnitten und untersucht werden. Der (zugängliche) Quellcode der CCU und anderer Add-Ons muss gesichtet werden. Implementierungfehler in des APIs müssen umgangen werden. Rat von Experten muss eingeholt werden. Die CCU muss hunderte Male neu gestartet werden, weil während der Entwicklung und des Testens Prozesse auf der CCU abstürzen. Für den Zugriff auf eine CCU mit HM-, HM-Wired- und HM-IP-Geräten werden insgesamt
9 Netzwerkverbindungen, teilweise als Rückkanal und mit unterschiedlichen Protokollen, benötigt. Zudem sind die Netzwerkschnittstellen der CCU unverschlüsselt. Damit das nicht jeder Entwickler selber durchmachen muss, ist bei mir die Idee zum CCU-Jack entstanden.
Ach ja, warum macht der Einsatz eines Add-Ons, wie z.B. des CCU-Jacks, die CCU stabiler und sicherer? Wenn ungültige API-Anfragen oder Skripte (auch versehentlich) von der Fremdapplikation kommen, dann werden sie von dem Add-On abgewehrt: Die CCU wird nicht überlastet, die CCU stürzt nicht ab, die CCU-Projektierung wird nicht zerschossen, die CCU wird nicht gehackt, und Geräte können nicht in Elektroschrott verwandelt werden.
Das gebe ich neuen Entwicklern, die sich mit der CCU beschäftigen wollen, als erste Information zur Berücksichtigung mit. Jeder kann natürlich machen was er will. Und weitere Entwickler, die sich mit des APIs beschäftigen möchten, sind naturlich gerne willkommen.