Hallo,
Die mir einzig geläufige methode variablen auszulesen ist die XML-API.
Da ich diese aber 10sekündlich polle, wollte ich alternativen ansehen
- XML-RPC-Server: der kann nur wired und funk, oder?
- syslog: ebenso
Oder hab ich was übersehen?
Danke für Eure Hilfe,
Marcel
Variablen extern auslesen (API, RPC, Syslog,..)
Moderator: Co-Administratoren
-
Herbert_Testmann
- Beiträge: 11062
- Registriert: 17.01.2009, 11:30
- Danksagung erhalten: 7 Mal
Re: Variablen extern auslesen (API, RPC, Syslog,..)
Hallo
das muss auch über BIN-RPC gehen und dann darüber die ReGa Schicht, die Variablen, Räume, Namen, Favoriten ... liefert.
Ich kenne das nur als Anwender, aber es gibt ja hier genug Programmierer die Details verraten können
das muss auch über BIN-RPC gehen und dann darüber die ReGa Schicht, die Variablen, Räume, Namen, Favoriten ... liefert.
Ich kenne das nur als Anwender, aber es gibt ja hier genug Programmierer die Details verraten können
---
Dieses Schreiben wurde maschinell erstellt und ist ohne Unterschrift gültig
Dieses Schreiben wurde maschinell erstellt und ist ohne Unterschrift gültig
-
hobbyquaker
- Beiträge: 3978
- Registriert: 12.07.2009, 20:01
- Hat sich bedankt: 17 Mal
- Danksagung erhalten: 176 Mal
- Kontaktdaten:
Re: Variablen extern auslesen (API, RPC, Syslog,..)
Es gibt von Haus aus erst mal nur 2 Möglichkeiten an Rega-Variablen ranzukommen:
Entweder mit dem tclrega Modul aus TCL Scripts heraus (so macht es auch das WebUI und die "XML API") oder über die "Remote Script Schnittstelle" der Rega auf Port 8181 (imho der "schönere" Weg, da hier direkt mit der Rega kommuniziert wird und nicht wie bei der XML-API zusätzlich noch der Lighttpd und der TCL Interpreter mitspielen müssen).
BIN-/XML-RPC geht nicht, das nutzt die Rega ausschließlich um mit den Schnittstellenprozessen (rfd/hs485d/CUxD/HMIPServer) zu kommunzieren, dabei sind aber nur Geräte/Kanäle im Spiel, die Rega stellt da nichts bereit, sie ist lediglich ein "Subscriber" an den Schnittstellenprozessen (führt einen RPC Init durch).
Denkbar wären natürlich noch andere "konstruierte" Wege, man könnte auch via Homematic-Script und System-/CUxD-Exec eine Datei erzeugen die man wieder via Lighttpd pollt. Oder man könnte den Variablenwert auch gleich anderweitig via Homematic Script und System-/CUxD-Exec übers Netzwerk verschicken, würde den Vorteil mitbringen dass man sich so ein "Push-Mechanismus" bauen kann und nicht auf Polling zurückgreifen muss. Sowas ist aber imho eher "umständlich" und das 10-sekündliche Polling von Variablen "sollte" die Rega (obwohl sie eine echt vollkommen Fehler-intolerante Mimose ist) auch dauerhaft überleben.
Noch ein anderer Ansatz: In CCU.IO hatte ich mal einen Mechanismus gebaut bei dem ein Homematic-Programm auf Variablen-Änderung reagiert und einen virtuellen Taster drückt. Diesen Event (den virtuellen Tastendruck) konnte CCU.IO dann via RPC gepushed bekommen woraufhin es dann via Port 8181 die Variablen gepollt hat. Quasi ein "Pseudo-Push".
Zuguter letzt noch mein obligatorischer Tipp: Meiner Meinung nach ist es am besten einfach völlig auf die Rega (und somit auf Homematic Programme, Scripte und Variablen) zu verzichten und die "Logikschicht" extern laufen lassen.
Entweder mit dem tclrega Modul aus TCL Scripts heraus (so macht es auch das WebUI und die "XML API") oder über die "Remote Script Schnittstelle" der Rega auf Port 8181 (imho der "schönere" Weg, da hier direkt mit der Rega kommuniziert wird und nicht wie bei der XML-API zusätzlich noch der Lighttpd und der TCL Interpreter mitspielen müssen).
BIN-/XML-RPC geht nicht, das nutzt die Rega ausschließlich um mit den Schnittstellenprozessen (rfd/hs485d/CUxD/HMIPServer) zu kommunzieren, dabei sind aber nur Geräte/Kanäle im Spiel, die Rega stellt da nichts bereit, sie ist lediglich ein "Subscriber" an den Schnittstellenprozessen (führt einen RPC Init durch).
Denkbar wären natürlich noch andere "konstruierte" Wege, man könnte auch via Homematic-Script und System-/CUxD-Exec eine Datei erzeugen die man wieder via Lighttpd pollt. Oder man könnte den Variablenwert auch gleich anderweitig via Homematic Script und System-/CUxD-Exec übers Netzwerk verschicken, würde den Vorteil mitbringen dass man sich so ein "Push-Mechanismus" bauen kann und nicht auf Polling zurückgreifen muss. Sowas ist aber imho eher "umständlich" und das 10-sekündliche Polling von Variablen "sollte" die Rega (obwohl sie eine echt vollkommen Fehler-intolerante Mimose ist) auch dauerhaft überleben.
Noch ein anderer Ansatz: In CCU.IO hatte ich mal einen Mechanismus gebaut bei dem ein Homematic-Programm auf Variablen-Änderung reagiert und einen virtuellen Taster drückt. Diesen Event (den virtuellen Tastendruck) konnte CCU.IO dann via RPC gepushed bekommen woraufhin es dann via Port 8181 die Variablen gepollt hat. Quasi ein "Pseudo-Push".
Zuguter letzt noch mein obligatorischer Tipp: Meiner Meinung nach ist es am besten einfach völlig auf die Rega (und somit auf Homematic Programme, Scripte und Variablen) zu verzichten und die "Logikschicht" extern laufen lassen.