Über welches Protokoll mit der CCU3 per Skript reden
Moderator: Co-Administratoren
Über welches Protokoll mit der CCU3 per Skript reden
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
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
mfg
Thomas
Thomas
-
- Beiträge: 372
- Registriert: 11.02.2020, 12:14
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 96 Mal
- Danksagung erhalten: 68 Mal
Re: Über welches Protokoll mit der CCU3 per Skript reden
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)
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)
-
- Beiträge: 6821
- Registriert: 22.05.2012, 08:40
- System: CCU
- Hat sich bedankt: 25 Mal
- Danksagung erhalten: 497 Mal
Re: Über welches Protokoll mit der CCU3 per Skript reden
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
- Beiträge: 10968
- Registriert: 18.12.2018, 15:45
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 622 Mal
- Danksagung erhalten: 2264 Mal
Re: Über welches Protokoll mit der CCU3 per Skript reden
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.
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.
Grüße... Baxxy
- Raspberry Pi 4 als Homematic-Zentrale - Tipps und Informationen
- Analysescript für genutzte Funk-Adressen, Funkmodul-Hardware und Zentralen Hardware
- NANO CUL 868MHz - Stick zum AskSin Analyzer XS umflashen (Anleitung für ArduinoIDE unter Windows)
- Firmware Updates für IP-Aktoren / Sensoren... Info's, Tipps und Sonstiges
- CCU funkt nicht - CarrierSense (CS) Probleme erkennen und lösen
-
- Beiträge: 372
- Registriert: 11.02.2020, 12:14
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 96 Mal
- Danksagung erhalten: 68 Mal
Re: Über welches Protokoll mit der CCU3 per Skript reden
Fonzo hat geschrieben: ↑16.01.2024, 19:07Wozu 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.
Baxxy hat geschrieben: ↑16.01.2024, 19:31Kann 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.
Ich würde sagen, das ist genau das.Wikipedia hat geschrieben:Eine Programmierschnittstelle [...], häufig nur kurz API genannt (von englisch application programming interface, wörtlich ‚Anwendungsprogrammierschnittstelle‘), ist ein Programmteil, der von einem Softwaresystem anderen Programmen zur Anbindung an das System zur Verfügung gestellt wird.
Die json-api bietet leider beispielsweise nur Channel.getValue, aber nicht setValue, also für Steuerungszwecke leider ungeeignet.
-
- Beiträge: 6821
- Registriert: 22.05.2012, 08:40
- System: CCU
- Hat sich bedankt: 25 Mal
- Danksagung erhalten: 497 Mal
Re: Über welches Protokoll mit der CCU3 per Skript reden
Es geht ja auch nicht darum über den Sinn zu diskutieren, sondern eher auf das genau einzugehen, was der Fragesteller an Anforderungen hat.Silverstar hat geschrieben: ↑17.01.2024, 07:44Aber: das ist hier nicht die Frage. Ich möchte hier und jetzt nicht über Sinn und Unsinn weiterer Schnittstellen diskutieren.
Zu seinen Anforderungen gehört eben nicht, noch mal umständlich weitere Add Ons zu installieren.
-
- Beiträge: 6821
- Registriert: 22.05.2012, 08:40
- System: CCU
- Hat sich bedankt: 25 Mal
- Danksagung erhalten: 497 Mal
Re: Über welches Protokoll mit der CCU3 per Skript reden
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
- Beiträge: 10968
- Registriert: 18.12.2018, 15:45
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 622 Mal
- Danksagung erhalten: 2264 Mal
Re: Über welches Protokoll mit der CCU3 per Skript reden
Ok, überzeugt.
Die XML-API ist, aus meiner "nicht Programmierer Sicht", auch am einfachsten zu nutzen.
Das wäre ja unschön... aber du hast nur nicht richtig geguckt.Silverstar hat geschrieben: ↑17.01.2024, 07:44Die json-api bietet leider beispielsweise nur Channel.getValue, aber nicht setValue, also für Steuerungszwecke leider ungeeignet.
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
Grüße... Baxxy
- Raspberry Pi 4 als Homematic-Zentrale - Tipps und Informationen
- Analysescript für genutzte Funk-Adressen, Funkmodul-Hardware und Zentralen Hardware
- NANO CUL 868MHz - Stick zum AskSin Analyzer XS umflashen (Anleitung für ArduinoIDE unter Windows)
- Firmware Updates für IP-Aktoren / Sensoren... Info's, Tipps und Sonstiges
- CCU funkt nicht - CarrierSense (CS) Probleme erkennen und lösen
-
- Beiträge: 372
- Registriert: 11.02.2020, 12:14
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 96 Mal
- Danksagung erhalten: 68 Mal
Re: Über welches Protokoll mit der CCU3 per Skript reden
Gut, dass ich ihm bereits in der ersten Antwort in diesem Thread einen Vorschlag gemacht habe, wie er ohne addons etwas tun kann:Fonzo hat geschrieben: ↑17.01.2024, 08:03Es geht ja auch nicht darum über den Sinn zu diskutieren, sondern eher auf das genau einzugehen, was der Fragesteller an Anforderungen hat.Silverstar hat geschrieben: ↑17.01.2024, 07:44Aber: das ist hier nicht die Frage. Ich möchte hier und jetzt nicht über Sinn und Unsinn weiterer Schnittstellen diskutieren.
Zu seinen Anforderungen gehört eben nicht, noch mal umständlich weitere Add Ons zu installieren.
Offtopic wurden wir dann ab der zweiten Antwort in diesem Thread...Silverstar hat geschrieben: ↑16.01.2024, 19:03Also, 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)
Back2topic: json-api geht offenbar auch
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.Baxxy hat geschrieben: ↑17.01.2024, 08:37[...]Das wäre ja unschön... aber du hast nur nicht richtig geguckt.Silverstar hat geschrieben: ↑17.01.2024, 07:44Die json-api bietet leider beispielsweise nur Channel.getValue, aber nicht setValue, also für Steuerungszwecke leider ungeeignet.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
Das ist aber ein sehr guter Hinweis für mein aktuelles Projekt, Danke!
-
- Beiträge: 1802
- Registriert: 03.11.2010, 10:25
- System: CCU
- Wohnort: Aachen
- Hat sich bedankt: 60 Mal
- Danksagung erhalten: 266 Mal
- Kontaktdaten:
Re: Über welches Protokoll mit der CCU3 per Skript reden
Mal ein paar grundlegende Ausführungen, weil bestimmt auch zukünftig Programmierer über dieses Thema stolpern werden.
Offiziell von eQ3 dokumentierte APIs für externe Applikationen:
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.)
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.
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
- JSON-RPC-API
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.)
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.Fonzo hat geschrieben: ↑16.01.2024, 19:07Wozu 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.
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.