Über welches Protokoll mit der CCU3 per Skript reden

[wedoon]

Hallo zusammen,
ich habe seit 4 Tagen eine CCU3 und will darüber 3 HmIP-eTRV-2 und 2 HmIP-PS-2 per python schalten, bzw. deren Schaltzeiten ändern.
Leider finde ich nicht wirklich funktionierende Beispiele, wie man mit einer CCU3 über Skripte in Verbindung tritt.

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?

Ich will erstmal ohne Addons auskommen.

Alle Beispiele, die ich gefunden habe sind ca. 10 Jahre alt und lösen Thread Warnungen in der CCU aus (xmlrpc.Client / xmlrpc.SimpleXMLRPCServer).
Hilfe von eQ-3 gibt es auch nicht, da sie wohl nur die alten PDF's haben und nichts anderes veröffentlichen.

mfg
Thomas

[Silverstar]

Also, die xml-api v1 ist sozusagen deprecated. Es gibt aber eine V2: https://github.com/homematic-community/XML-API/

Ohne addons könntest du z.B. auf die remote script Schnittstelle zugreifen:
viewtopic.php?t=13027
http://www.wikimatic.de/wiki/HomeMatic_Script (Seite funktioniert nur über http also wenn "not found" kommt, Browser auf http zwingen)

[Fonzo]

Also, die xml-api v1 ist sozusagen deprecated.

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.

[Baxxy]

Kann man das "XML-API CCU Addon" eigentlich als richtige API bezeichnen?

Letztlich ist es doch eher ein (zusätzlich installierter) Wrapper der cgi-Scripte auf der CCU ausführt welche wiederum ReGa-Scripte ausführen.
Da kann man auch gleich Remote-Script nehmen.

Eine offizielle JSON-API gibt es auch.

[Silverstar]

Also, die xml-api v1 ist sozusagen deprecated.

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.

Vermutlich, weil eine RPC-Schnittstelle mit init und deinit komplexer anzusprechen ist, als eine xml-api, die beispielsweise mit einem einzigen curl request alles liefert oder schaltet, was man möchte.
Zudem haben eq3's Schnittstellen ja manchmal so ihre Probleme (mobile clients ohne deinit - virtual devices lockup).
Aber wer weiß, was der ursprüngliche Grund war. Keine Kenntnis der anderen Schnittstellen zur der Entwicklungszeit oder auch einfach nur "ich kann/weiß es besser"

Aber: das ist hier nicht die Frage. Ich möchte hier und jetzt nicht über Sinn und Unsinn weiterer Schnittstellen diskutieren.

Kann man das "XML-API CCU Addon" eigentlich als richtige API bezeichnen?

Letztlich ist es doch eher ein (zusätzlich installierter) Wrapper der cgi-Scripte auf der CCU ausführt welche wiederum ReGa-Scripte ausführen.
Da kann man auch gleich Remote-Script nehmen.

Eine offizielle JSON-API gibt es auch.

Eine Programmierschnittstelle [...], häufig nur kurz API genannt (von englisch application programming interface, wörtlich ‚Anwendungs­programmier­schnittstelle‘), ist ein Programmteil, der von einem Softwaresystem anderen Programmen zur Anbindung an das System zur Verfügung gestellt wird.

Ich würde sagen, das ist genau das.

Die json-api bietet leider beispielsweise nur Channel.getValue, aber nicht setValue, also für Steuerungszwecke leider ungeeignet.

[Fonzo]

Aber: das ist hier nicht die Frage. Ich möchte hier und jetzt nicht über Sinn und Unsinn weiterer Schnittstellen diskutieren.

Es geht ja auch nicht darum über den Sinn zu diskutieren, sondern eher auf das genau einzugehen, was der Fragesteller an Anforderungen hat.

Ich will erstmal ohne Addons auskommen.

Zu seinen Anforderungen gehört eben nicht, noch mal umständlich weitere Add Ons zu installieren.

[Fonzo]

Leider finde ich nicht wirklich funktionierende Beispiele, wie man mit einer CCU3 über Skripte in Verbindung tritt.

Abhängig vom genauen Anwendungszweck, ist es vielleicht einfacher gleich Systeme zu nutzten, die auf die HmIP-CCU3 zugreifen können. Home Assistant benutzt Python, Beispiel ist hier zu finden.

Für andere Sprachen wie PHP gibt es andere fertige Lösungen um mit einer HmIP-CCU3 zu kommunizieren, das erspart einem selber viel Arbeit und Zeit sich da einzuarbeiten.

[Baxxy]

Ich würde sagen, das ist genau das.

Ok, überzeugt.
Die XML-API ist, aus meiner "nicht Programmierer Sicht", auch am einfachsten zu nutzen.

Die json-api bietet leider beispielsweise nur Channel.getValue, aber nicht setValue, also für Steuerungszwecke leider ungeeignet.

Das wäre ja unschön... aber du hast nur nicht richtig geguckt.

Code: Alles auswählen

/usr/bin/wget -q -O - --post-data '{ "method": "Interface.setValue", "params": { "_session_id_": "VLuaqrzi75", "interface": "BidCos-RF", "address": "QEQ0011501:1", "valueKey": "STATE", "type": "bool", "value": "true" }}' http://127.0.0.1/api/homematic.cgi

[Silverstar]

Aber: das ist hier nicht die Frage. Ich möchte hier und jetzt nicht über Sinn und Unsinn weiterer Schnittstellen diskutieren.

Es geht ja auch nicht darum über den Sinn zu diskutieren, sondern eher auf das genau einzugehen, was der Fragesteller an Anforderungen hat.

Ich will erstmal ohne Addons auskommen.

Zu seinen Anforderungen gehört eben nicht, noch mal umständlich weitere Add Ons zu installieren.

Gut, dass ich ihm bereits in der ersten Antwort in diesem Thread einen Vorschlag gemacht habe, wie er ohne addons etwas tun kann:

Also, die xml-api v1 ist sozusagen deprecated. Es gibt aber eine V2: https://github.com/homematic-community/XML-API/

Ohne addons könntest du z.B. auf die remote script Schnittstelle zugreifen:
viewtopic.php?t=13027
http://www.wikimatic.de/wiki/HomeMatic_Script (Seite funktioniert nur über http also wenn "not found" kommt, Browser auf http zwingen)

Offtopic wurden wir dann ab der zweiten Antwort in diesem Thread...





Back2topic: json-api geht offenbar auch

[...]

Die json-api bietet leider beispielsweise nur Channel.getValue, aber nicht setValue, also für Steuerungszwecke leider ungeeignet.

Das wäre ja unschön... aber du hast nur nicht richtig geguckt.

Code: Alles auswählen

/usr/bin/wget -q -O - --post-data '{ "method": "Interface.setValue", "params": { "_session_id_": "VLuaqrzi75", "interface": "BidCos-RF", "address": "QEQ0011501:1", "valueKey": "STATE", "type": "bool", "value": "true" }}' http://127.0.0.1/api/homematic.cgi

Uff, das ist ja mal sowas von intuitiv... Interface.SetValue habe ich gesehen, aber gedacht, damit setze ich Interface-Einstellungen oder so, aber keine Geräte/Channels.
Das ist aber ein sehr guter Hinweis für mein aktuelles Projekt, Danke!

[Mathias]

Mal ein paar grundlegende Ausführungen, weil bestimmt auch zukünftig Programmierer über dieses Thema stolpern werden.

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:

• JSON-RPC-API

Ich will erstmal ohne Addons auskommen.

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.)

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.