a9bcbb485e
from a running CCU using the TCL API and then builds a prototype config file for fhem git-svn-id: https://fhem.svn.sourceforge.net/svnroot/fhem/trunk/fhem@1065 2b470e98-0d58-463d-a4d8-8e2adae1ed80
130 lines
4.6 KiB
Plaintext
130 lines
4.6 KiB
Plaintext
HMRPC - xmlrpc-basierte Homematic-Integration fuer fhem
|
||
=======================================================
|
||
Von Oliver Wagner <owagner@vapor.com>
|
||
|
||
V0.4
|
||
|
||
Uebersicht
|
||
----------
|
||
HMRPC ist ein Modul zur Integration des Homematic-Systems der Firma EQ-3
|
||
mit fhem. Es verfolgt im Gegensatz zu den bereits vorhandenen CUL_HM/HMLAN-
|
||
Modulen einen anderen Ansatz: Statt direkt mit der Funk-Hardware zu
|
||
kommunizieren, verwendet es die offizielle bereitgestellte xmlrpc-basierte
|
||
API der EQ-3-Software (siehe [1]). Daraus ergeben sich Vorteile und
|
||
Nachteile: So sind implizit alle derzeitigen und auch zukuenftigen Geraete
|
||
vollumfaenglich unterstuetzt, auch die RS485 Wired-Module.
|
||
|
||
Der wesentliche Nachteil, oder zumindestens eine Vorraussetzung, ist, dass
|
||
man eine Instanz der xmlrpc-Server benoetigt. Dazu gibt es aktuell drei
|
||
Moeglichkeiten:
|
||
|
||
1) auf der CCU1 selbst laufen "rfd" fuer die Funkkommunikation und
|
||
"hs485d" fuer die Wired-Kommunikaiton.
|
||
|
||
Eine Uebersicht der Softwarearchitektur der CCU1 findet sich unter [2]
|
||
|
||
2) als Teil der Verwaltungssoftware fuer den HM-LAN-Aadapter (siehe [3]) gibt
|
||
es einen xmlrpc-Dienst fuer Funkkommunikation als Windows-Service. Dieser
|
||
entspricht dem "rfd" auf der CCU1.
|
||
|
||
3) Nutzung des "rfd" aus einem CCU1-Firmware-Image mittels "qemu-arm"
|
||
|
||
Es ist aber nicht auszuschliessen, das EQ-3 in Zukunft z.B. einen rfd fuer
|
||
Linux/x86 veroeffentlicht.
|
||
|
||
|
||
Geschichte und Status
|
||
---------------------
|
||
Diese Module sind aus der Middleware "HMCompanion" [4] entstanden, die ich mir
|
||
fuer die HM-Integration in meinen Haussteuerungswildwuchs geschrieben habe.
|
||
|
||
HMRPC hat aktuell eher experimentellen Charakter. Ohne genaue Kenntnisse
|
||
von fhem, perl und HM-Internas haben die Module nur eingeschraenkten Nutzwert,
|
||
die Veroeffentlichung dient erstmal nur dazu, fruehes Feedback zur
|
||
Implementierung zu bekommen.
|
||
|
||
Das ist im iebrigen mein erstes nicht komplett triviales Stueck perl-code --
|
||
ueber Hinweise diesbezueglich wuerde ich mich ebenso freuen wie ueber allgemeines
|
||
Feedback zu HMRPC.
|
||
|
||
|
||
Benutzung
|
||
---------
|
||
Es gibt zwei Module:
|
||
|
||
00_HMRPC.pm ist der Provider fuer die Kommunikation mit eineml
|
||
xmlrpc-Service
|
||
|
||
01_HMDEV.pm ist jeweils die Abstraktion eines einzelnen Devices
|
||
|
||
Beispielkonfiguration fuer fhem:
|
||
|
||
# Wired-Schnittstelle auf einer CCU1 mit IP 192.168.5.2)
|
||
define hmw HMRPC 192.168.5.2 2000
|
||
# Ein Kanal eines Wired-Aktors
|
||
define light_buero_olli HMDEV GEQ0009019:3
|
||
|
||
Nutzung dann z.B. mit
|
||
|
||
set light_buero_olli STATE false
|
||
|
||
Ein putParamset (Konfigurationsupdate) wird dann durch zus<75>tzliche Angabe
|
||
der Paramset-ID generiert:
|
||
|
||
set light_buero_olli MASTER LOGGING 0
|
||
|
||
Die Attribute eines Geraetes entsprechen den in dem Dokument unter [1]
|
||
"HomeMatic-Script Dokumentation: Teil 4 - Datenpunkte" beschriebenen.
|
||
Die Inhalte der Paramsets sind aktuell nicht dokumentiert, man muss diese
|
||
anhand des xmlrpc-Requests getParamsetDescription oder durch Browsen der
|
||
XML-Beschreibungen im /firmware-Verzeichnis der CCU-Software
|
||
ermitteln.
|
||
|
||
<EFBFBD>ber die set-Methode des HMRPC-Devices lassen sich auch andere weitere
|
||
Operationen durchf<68>hren:
|
||
|
||
set <hmlrpc-device> req <xmlrpc-request> <parameter>
|
||
|
||
generiert einen direkten XMLRPC-Request und gibt das Ergebnis in Textform
|
||
zur<EFBFBD>ck. Das dient im wesentlichen Diagnose/Entwicklungszwecken. Beispiel:
|
||
|
||
set hmw req getDeviceDescription IEQ0208603
|
||
|
||
Der get-Aufruf ist ebenfalls implementiert und fuehrt einen synchronen
|
||
"getValue()"-Aufruf durch:
|
||
|
||
get light_buero_olli STATE
|
||
|
||
Design
|
||
------
|
||
Ich habe ueberlegt, ob HMRPC als Provider f<>r CUL_HM dienen koennte, habe aber
|
||
keine praktikable Loesung daf<61>r gefunden -- HMDEV ist aktuell im Vergleich zu
|
||
CUL_HM sehr dumm und dient mehr oder weniger nur als Cache f<>r Adresse und
|
||
Readings.
|
||
|
||
HMRPC meldet sich beim jeweiligen Service per "init" an und erh<72>lt dann per
|
||
xmlrpc-Callback Mitteilungen <20>ber Zustandsaenderungen. Wird der Service neu
|
||
gestartet (CCU Reboot o.ae.), ist diese Anmeldung hinfaellig. Es gibt aktuell
|
||
keine gute Methode, dies festzustelle -- als Workaround meldet sich HMRPC
|
||
15 Minuten nach dem letzten empfangenen Callback neu an. Je nach Art der
|
||
verwendeten Aktoren in einer Installation kann diese Zeit sehr kurz sein
|
||
und daher unnoetige re-inits verursachen. Diese scheinen aber grundsaetzlich kein
|
||
Problem auf der Service-Seite darzustellen.
|
||
|
||
|
||
Aenderungen
|
||
-----------
|
||
V0.3 - get-Methoden implementiert, als Aufruf von XML-RPC getValue()
|
||
- bei Boolean-Werten wurde bei false bei jedem event-Empfang
|
||
faelschlicherweise eine Notification ausgeloest
|
||
|
||
|
||
Anhang
|
||
------
|
||
|
||
[1] http://www.homematic.com/index.php?id=156
|
||
[2] http://www.homematic-wiki.info/mw/index.php/HomeMatic_Software
|
||
[3] http://www.homematic.com/index.php?id=644
|
||
[4] http://www.fhz-forum.de/viewtopic.php?f=26&t=4639
|
||
|