Homematic bietet für fast alle Situationen des häuslichen Lebens eine praktische Lösung: Das Home-Control-System erleichtert den Alltag und übernimmt wiederkehrende Vorgänge im Haus, wie z.B. das Einfahren der Markise, das Schließen der Rollladen oder das Öffnen des Garagentors.
Mehr Details dazu finden sie unter folgenden Links:
Was sie dort, und wahrscheinlich auch sonst nirgends finden werden, ist ein Modul für AMX. Die Controller von AMX sind frei programmierbar und bieten verschiedene Schnittstellen wie serielle Schnittstellen, Infrarot und I/O Ein-/Ausgänge. Dadurch eignen sie sich hervorragend um professionelle Steuerungen zu bauen. Egal ob Heimautomation oder nur ein Konferenzraum, diese Controller sind stets das Gehirn.
Wenn sie noch nie mit AMX zu tun hatten und kein AMX Integrator sind, dann wird die folgende Beschreibung für sie nutzlos sein. Für alle die nun doch noch weiter lesen, beschreibe ich wie das Modul eingebunden wird und wie man damit umgeht.
Damit dieses Modul überhaupt funktioniert, ist eine CCU2, oder etwas kompatibles,
notwendig. Die HomeMatic-Komponenten sollten angelernt sein und die Seriennummern
der einzelnen Komponenten bekannt sein.
Wenn die Befehle für das Addon XMLAPI genutzt werden sollen, dann
muss auf der CCU2 das Zusatzmodul
XMLAPI
installiert sein. Neben den Seriennummern der Komponenten werden dann auch noch die ISE-Nummern
jener Komponenten benötigt, die geschaltet oder ausgelesen werden sollen.
Sind diese Voraussetzungen erfüllt, kann die Integration in AMX beginnen.
Als erstes sollten sie das Modul herunter laden.
In der ZIP-Datei befinden sich die Files HomeMaticRPC_Comm.axs
und
HomeMaticRPC.axi
. In der Include-Datei befinden sich einige wenige
Definitionen der möglichen Datentypen. Diese werden später für das UI-Modul
benötigt.
Der folgende Code zeigt die notwendigen Definitionen zum Einbinden des Moduls:
DEFINE_DEVICE
dvClient = 0:4:0;
dvServer1 = 0:5:0;
dvServer2 = 0:6:0;
dvServer3 = 0:7:0;
vdvHomeMatic = 33000:1:0;
DEFINE_VARIABLE
volatile dev dvHomeMatic[] = { dvServer1, dvServer2, dvServer3, dvServer4, dvServer5 };
volatile integer nPort = 2001; // This is for RF components
// volatile integer nPort = 2000; // This is for IP components
volatile char sIP[] = '10.10.10.10'; // IP of your CCU2
DEFINE_MODULE 'HomeMaticRPC_Comm' HM_Comm(vdvHomeMatic, dvClient, dvHomeMatic, sIP, nPort);
Die Definition von drei Server-Devices (es können bis zu 10 definiert werden) erlaubt mehr als eine Verbindung zum AMX-Controller. Das Modul verwendet RPC (Remote Procedure Call) um Rückmeldungen von der CCU2 zu erhalten. Dabei wird die Client-/ Serverlogik umgedreht und der AMX-Controller wird zum Server. Da RPC im Prinzip wie HTML kommuniziert, wird nach jedem empfangenen Befehl von der CCU2 die Verbindung unterbrochen. Dann muss der Server neu gestartet werden. Damit keine Lücke entsteht, laufen stets mindestens 2 Server gleichzeitig. Diese lauschen auf dem selben Port.
Das AMX-Modul eröffnet als erstes einen Server der Lauscht. Danach wird sofort ein Befehl an die CCU2 gesendet, mit dem sich der AMX-Controller registriert. Dadurch werden von der CCU2 alle Ereignisse wie das Drücken eines Tasters, Temperaturänderungen, Fensterkontakte u.s.w. an den AMX-Controller gemeldet. Das AMX-Modul wertet die Informationen aus, verpackt sie in vereinfachte Befehle und sendet sie über das virtuelle Device an ein UI-Modul, welches die Meldungen entsprechend auf einem Panel visulaisiert.
Alle Befehle bestehen aus dem Befehl selbst und, optional, aus einem oder mehreren Parametern. Die Parameter werden vom Befehl und untereinander immer durch einen Doppelpunkt “:” getrennt. Jeder Befehl muss mit einem Strichpunkt “;” abgeschlossen werden. Das erlaubt die Angabe von mehr als einem Befehl pro Aufruf. Dabei darf die Gesamtlänge der Befehlszeile 255 Zeichen nicht überschreiten!
Beispiel:
SET VALUE:OEQ1234567.1:1:1;
Befehl | Parameter | Beschreibung |
---|---|---|
STATECHANGE | <ISE ID><Type><Wert> | Dieser Befehl sendet einen neuen Status an einen beliebigen Aktor. Die Parameter haben
folgende Bedeutung:
Der folgende Befehl setzt einen Dimaktor auf 65%: STATECHANGE:1234:2:0.65;
|
STATE | <ISE ID> | Dieser Befehl fragt die über den Parameter angegebene Komponente ab. Der Parameter < ISE ID > muss eine gültige ISE_ID enthalten. Als Antwortwird der Status, Level und weitere Informationen der Komponente geliefert. Wichtig: Dieser Befehl benötigt das Addon “XMLAPI” auf der CCU2! |
DEBUG | <Wert> | Dieser Befehl schaltet das Debugging ein oder aus. Wird als Parameter 1 übergeben, wird das Debugging aktiviert. Es werden verschiedenste Informationen in Form von Befehlen zurückgemeldet. Wird als Parameter 0 übergeben, wird das Debugging deaktiviert. Alle Rückmeldungen kommen über das virtuelle Device und beginnen immer mit |
SET VALUE | <ADDR><Type><Wert> | Dieser Befehl sendet einen neuen Status oder einen Wert an eine Komponente. Dieser Befehl wird als XML-RPC abgesetzt. Als Antwort kommt der neue Status der Komponente zurück. Die Parameter haben folgende Bedeutung:
SET VALUE:OEQ1234567.1:1:1;
|
GET VALUE | <ADDR><Type> | Dieser Befehl fragt die über den Parameter <ADDR> angegebene Komponente ab. Der Parameter <ADDR> muss eine gültige Seriennummer enthalten. Der Parameter <Type> muss dem erwarteten Typ des Werts entsprechen. Als Antwort wird der Status, Level oder ein anderer Wert der Komponente geliefert. |
Rückmeldungen des Moduls
In der folgenden Tabelle sind die (bisher) möglichen Rückmeldungen des Moduls dokumentiert.
Befehl | Parameter | Beschreibung |
---|---|---|
EVENT | <ADDR>:<Type>:<Wert> | Das ist die Antwort auf den Befehl STATECHANGE oder einem Ereignis wie die Statusänderung eines Schaltaktors, Dimaktors, … Ist der Parameter <ADDR> leer, dann handelt es sich um ein Ereignis auf Grund eines vom Modul abgesendeten Befehls. Das muss nicht zwangsweise ein vom UI-Modul ausgelöster Befehl sein, sondern kann auch von einem im Modul automatisch ausgelösten Befehl stammen. Die Parameter haben folgende Bedeutung:
EVENT:OED1234567.1:2:0.65;
|
RESULT | <ISE ID>:<Wert> | Diese Antwort erfolgt immer auf den Befehl STATECHANGE und enthält den aktuellen Wert oder Status der zuletzt geschalteten Komponente. Die Parameter haben folgende Bedeutung:
RESULT:1234:0;
|
WORKING | <ADDR>:<Type>:<Wert> | Zeigt an ob eine Komponente gerade beschäftigt ist, oder nicht.
WORKING:OED12345678.1:1:0;
|
PRESS | <Wie>:<ADDR>:<Wert> | Wird ein Wandtaster gedrückt, dann wird diese Rückmeldung gesendet. Das Ergebnis ist immer ein boolscher Wert. Die Parameter haben folgende Bedeutung:
PRESS:SHORT:OED12345678.1:1;
|
LEVEL | <ADDR>:<Wert> | Diese Rückmeldung kann von einem Dimaktor, einem Thermometer oder einer anderen Komponente stammen, die einen Fließkommawert zurückmeldet. Der Inhalt des Parameters <Wert> ist in jedem Fall eine Fließkommazahl. Bei Dimaktoren ist das ein Bereich von 0.00 bis 1.00.
LEVEL:NEQ1234567.2:0.65;
|
DIRECTION | <ADDR>:<Wert> | Datentyp Integer. Gibt die Richtung (Senden oder Empfangen) dieses Kanals in einer direkten Verknüpfung an. Die Parameter haben folgende Bedeutung:
DIRECTION:OEQ1234567.1:1;
|
ERROR | <Fehler>:<ADDR>:<Wert> | Meldet einen Fehlerzustand. Der <Wert> ist immer boolean und zeigt ob ein Fehler vorliegt. Die Parameter haben folgende Bedeutung:
|
PONG | <ID> | Diese Rückmeldung ist die Antwort auf ein intern abgesetztes PING. Dieser Befehl wird immer dann abgesetzt, wenn mindestens 10 Sekunden lang kein Befehl abgesetzt wurde. Als Parameter wird immer “20170622” übergeben. |
Zur besseren Lesbarkeit der einzelnen Datentypen gibt es in der Datei HomeMaticRPC.axi
einige
der wichtigsten Datentypen vordefiniert. Die Datei kann mit folgendem Befehl in ein eigenes Modul eingebunden
werden:
#include 'HomeMaticRPC'
Die folgende Tabelle erkärt die einzelnen Datentypen:
Wert | Name | Beschreibung |
---|---|---|
0 | RPC_TYPE_NONE | Kein oder unbestimmter Inhalt |
1 | RPC_TYPE_BOOL | Ein boolscher Wert. Kann 0 oder 1 sein. Wahlweise auch “false” oder “true”. |
2 | RPC_TYPE_INT | Ein ganzzahliger Wert. |
3 | RPC_TYPE_FLOAT | Ein Fließkommawert. |
4 | RPC_TYPE_STRING | Eine beliebige Zeichenkette. |
5 | RPC_TYPE_TIMESTAMP | Datum und Uhrzeit (Zeitstempel). Dieser Datentype ist derzeit nicht unterstützt! |
© 2006 − 2011 by Andreas Theofilu (theosys)