HomeMatic

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.

Einbindung des Moduls

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.

Befehle an das Modul

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:
  • <ISE ID>  Die ISE_ID der Komponente.
  • <Type>   Die Type des Parameters. Siehe dazu TYPEN weiter hinten.
  • <Wert>   Der zu sendende Wert. Dieser muss dem Parameter Type entsprechen!
Wichtig: Dieser Befehl benötigt das Addon “XMLAPI” auf der CCU2!
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 Antwort
wird 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:
  • <ADDR>  Die Seriennummer der Komponente.
  • <Type>   Die Type des Parameters. Siehe dazu TYPEN weiter hinten.
  • <Wert>   Der zu sendende Wert. Dieser muss dem Parameter Type entsprechen!
Der folgende Befehl schaltet einen einfachen Schaltaktor ein:
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:
  • <ADDR>   Die Seriennummer der Komponente auf die sich die Antwort bezieht.
  • <Type>   Die Type des folgenden Parameters.
  • <Wert>   Der zurückgemeldete Wert.
Beispiel:
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:
  • <ISE ID>   Die ISE-ID der Komponente auf die sich die Antwort bezieht.
  • <Wert>   Der aktuelle Wert der entsprechenden Komponente.
Bespiel:
RESULT:1234:0;
WORKING <ADDR>:<Type>:<Wert> Zeigt an ob eine Komponente gerade beschäftigt ist, oder nicht.
  • <ADDR>   Die Seriennummer der Komponente auf die sich die Antwort bezieht.
  • <Type>   Die Type des folgenden Parameters (immer 1).
  • <Wert>   Der zurückgemeldete Wert.
Beispiel:
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:
  • <Wie>   Dieser Parameter kann “SHORT”, für einen kurzen
    Tastendruck, oder “LONG” für einen langen Tastendruck sein.
  • <ADDR>   Die Seriennummer der Komponente auf die sich die Antwort bezieht.
  • <Wert>   1 = Taste gedrückt, 0 = Taste losgelassen.
Beispiel:
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.
  • <ADDR>   Die Seriennummer der Komponente auf die sich die Antwort bezieht.
  • <Wert>   Fließkommawert.
Beispiel:
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:
  • <ADDR>   Die Seriennummer der Komponente auf die sich die Antwort bezieht.
  • <Wert>   Kann folgende Werte beinhalten:
    • 0 = DIRECTION_NONE (Kanal unterstützt keine direkte Verknüpfung)
    • 1 = DIRECTION_SENDER
    • 2 = DIRECTION_RECEIVER
Beispiel:
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:
  • <Fehler>   Kann folgende Werte annehmen.
    • OVERLOAD bedeutet bei einem Dimaktor, dass der angeschlossene Verbraucher zu viel
      Strom verbraucht.
    • OVERHEAT bedeutet, dass die Komponente überhitzt ist.
    • UNREACH Komponente war nicht erreichbar.
    • STICKY_UNREACH Komponente war irgendwann nicht erreichbar.
  • <ADDR>   Die Seriennummer der Komponente auf die sich die Antwort bezieht.
  • <Wert>   1 = Fehler liegt vor, 0 = Kein Fehler.
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.

Datentypen

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)