Homematic mit Fhem

Am Anfang meiner Smart-Home Zeit war ich hauptsächlich mit der Suche nach brauchbaren Informationen und Problemlösungen beschäftigt. Teilweise zerstreuen sich diese aber auf viele verschiedene Webseiten, Wikis, Blogs, PDFs und Foreneinträge. Grundlegende Bausteine im Homematic-System schaffen bei den meisten Problemen Abhilfe, daher möchte ich euch zeigen wie meine Homematic-Geräte (einwandfrei) funktionieren und das Alles untereinander weg.

Inhalt

I/O-Device

Die Kommunikation zwischen den Homematic-Geräten und Fhem regelt immer ein sog. I/O-Device.

Dies kann

sein. Ich habe mich damals für einen CUL der Firma Busware entschieden, abgesehen vom vielleicht etwas höherem Preis, im Vergleich zu den anderen Optionen – eine Wahl, die gerne weiterempfehle. Bei der Bestellung eines CULs ist darauf zu achten, dass dieser im Frequenzbereich von 868 MHz arbeitet.

CUL: [An dieser Stelle gehe ich nicht auf den CUL selbst ein, dafür gibt es einen separaten Eintrag. Der CUL selbst sollte allerdings mit der entsprechenden CUL-Firmware geflasht und in Fhem bereits entsprechend eingerichtet sein um fortfahren zu können]

Homematic-Funkmodul: Dieses Modul ist speziell für den Einsatz mit dem Raspberry Pi konzipiert. Es wird auf die obersten GPIO Pins des Raspberry gesteckt und wird von dort mit Strom versorgt und kommuniziert über die serielle Schnittstelle (Tx/Rx).

Homematic CCU(2): Die CCU(2) ist die originale Zentrale des Homematic Systems. Systemintern wird man damit wohl die wenigsten Probleme haben. Im Prinzip hat man mit den Homematic-Geräten und der CCU auch eine Lösung, die ohne Fhem funktionieren würde.

zurück zum Inhalt

RF-Mode

Nachdem der CUL als Gerät in Fhem angelegt wurde, ist es bei der Verwendung von Homematic-Geräten in erster Linie wichtig den „rfmode“ einzustellen.

rfmode

zurück zum Inhalt

HMID

Die HMID ist eine eindeutige Nummer, die das I/O-Device für für die Homematic-Geräte erkennbar macht. Inbesondere für das Pairing von Geräten ist diese Nummer von Bedeutung.

Diese Nummer kann individuell vergeben werden, muss aber als 6-stellige-Hexadresse angegeben werden. Das Hexadezimalsystem verwendet sowohl Ziffern von 0-9, wie auch Buchstaben von A-F.

Eine HMID könnte also 5D9E4A sein. (Bitte diese Adresse aus Sicherheitsgründen, so nicht verwenden!!)

Diese HMID ist ein Sicherheitsbaustein und sollte natürlich auch so behandelt werden, notiert euch eure Nummer daher, für den Fall der Fälle kann man entsprechend reagieren.

hmId

zurück zum Inhalt

VCCU

Die VCCU ist ein Fhem-Modul, dass den Homematic-Geräten (unabhängig vom I/O-Device) vorgibt eine reguläre CCU(2) zu sein. Die VCCU übernimmt also die Verwaltung der Geräte. Inbesondere bei Homematic-Geräten, die eine AES-Verschlüsselung nutzen (wie die Keymatic oder der optische Tür-/Fensterkontakt z.B.) ist eine VCCU meiner Meinung nach unumgänglich.

Angelegt wird das Device mit

define VCCU VCCU

darauf folgen noch

attr VCCU model CCU-Fhem

&

attr VCCU IOlist CUL

Wer mehr als nur ein I/O-Device für Homematic nutzt, der kann z.B. einen zweiten CUL anhängen

attr VCCU IOlist CUL,CUL2

Die VCCU ist damit angelegt und kann verwendet werden.

zurück zum Inhalt

hmKey, hmKey2, hmKey3

Bei Geräten mit AES-Verschlüsselung sind diese Keys Pflicht um mit der Zentrale Kommunizieren zu können. Auch hier handelt es sich um Sicherheitsfeatures, die nicht weniger schlecht behandelt werden sollten, als die Pin Nummer der Bankkarte.

Die drei hmKeys darf man sich analog zu der hmId auch wieder selbst ausdenken (und natürlich dokumentieren).

Hmkeys könnten z.B. so aussehen: Key 1: 5B7E3F, Key 2: 2D9A3C, Key 3: 4B6C5A (Ich weise aus Sicherheitsgründen erneut darauf hin, nicht die hier beispielhaft gezeigten Keys zu verwenden!!)

Ich betone erneut: Es kann von hoher Bedeutung sein, die ausgedachten Hexadressen zu dokumentieren. Die Adressen sind nach dem Pairing eng mit den Geräten und der Zentrale verknüpft. Der Vorgang kann nicht durch einfaches zurücksetzen des Homematic-Geräts rückgängig gemacht werden, sondern nur kostenpflichtig beim Hersteller der Geräte!

Die Keys werden mit

attr VCCU hmKey 5B7E3F
attr VCCU hmKey2 2D9A3C
attr VCCU hmKey3 4B6C5A

hinzugefügt und von der Zentrale automatisch codiert – danach sind sie nicht mehr erkennbar!

Zur Kommunikation mit AES-Geräten benötigt das Betriebssystem des Fhem-Servers noch ein zusätzliches Paket

sudo apt-get install libcrypt-rijndael-perl

zurück zum Inhalt

Pairing

Das Pairing von Homematic-Geräten mit der Zentrale erfordert immer, dass man den Pairing-Modus der Zentrale und danach den, des Geräts aktiviert.

set VCCU hmPairForSec 300

aktiviert den Pairing-Modus der Zentrale für die angegebenen Sekunden. Wählt diesen Wert möglichst hoch (z.B. 300), damit das entsprechende Gerät die Zentrale in jedem Fall findet. Wie der Pairing-Modus für das Gerät aktiviert wird, steht in der entsprechenden Bedienungsanleitung.

Wenn die Zentrale das Gerät gefunden hat, wird dank autocreate automatisch ein neues Gerät inklusive Logfile und eventuellen Kanälen angelegt. Ob das Gerät korrekt gepairt wurde, lässt sich in den Readings ablesen.

pairing

Hier sind die Readings „PairedTo“ und „R-pairCentral“ zu beachten. Bei korrektem Pairing steht dort immer „0x“ – ist das Pairing nicht korrekt abgeschlossen steht dort „set 0xXXXXXX“

Mit dem Befehl

set <Homematic-Gerät> assignHmKey

kann man das Gerät dazu zu bringen sich vollständig zu pairen – oder das Pairing zu wiederholen. Es kann teilweise auch nötig sein, dass Gerät nochmal auf die Werkseinstellungen zurückzusetzen und dann nochmal zu pairen.

Natürlich klingt das eben beschriebene nicht unbedingt vorteilhaft, gar abschreckend. Allerdings ist auch nicht bei jedem Pairing-Vorgang ein Problem zu erwarten – hat das Pairing (in der Regel problemlos) geklappt, funktionieren Homematic-Geräte sehr zuverlässig und bieten einen hohen Funktionsumfang bei angemessenem Preis.

Generell ist nach dem Pairing nichts weiter zu tun, als das angelegte Gerät dem richtigen Raum zuzuweisen. Über Fhem können jetzt z.B. Peerings (das Verknüpfen mit anderen Homematic-Geräten) vorgenommen werden oder Heizpläne erstellt und an die Thermostate gesendet werden.

Mehr dazu, an anderer Stelle.

zurück zum Inhalt

Alternative Temperatursensoren

Hat man sich für Homematic Heizkörperthermostate entschieden, macht es Sinn diese mit Fensterkontakten und externen Temperatursensoren/Wandthermostaten zu „peeren“ um die Temperaturregelung zu verbessern.

Der interne Temperatursensor des Thermostats befindet sich stets sehr nah am Heizkörper, aus diesem Grund kann die Raumtemperatur nicht exakt ermittelt werden. Grade bei großen Räumen kann es da zwischen den gemessenen Temperaturen des Thermostats und der tatsächlichen Temperatur zu spürbaren Differenzen kommen.

Natürlich nimmt man hier im besten Fall das Wandthermostat von Homematic und verbindet es mit dem Heizkörperhermostat und hat eine saubere Lösung, die auch ohne Fhem funktionieren würde – allerdings schlägt so ein Wandthermostat mal eben mit knapp 50 € zu Buche und da wir Fhem nutzen, können wir uns auch um Alternativen bemühen.

Um dieses Problemchen mit der verfälschten Temperatur und den hohen Kosten zu lösen hilft ein externer Temperatursensor, der günstig im Raum platziert ist. In meinem Fall handelt es sich dabei um einen Xiaomi Temperatur- und Luftfeuchtigkeitssensor, der mittig im Raum an einem Regal befestigt ist. Man kann hier aber jeden x-beliebigen Sensor verwenden, der seinen Wert entsprechend an Fhem weiterleitet.

P_20180330_155555_vHDR_Auto

tempsens.png

Um den Wert des Sensors an ein Heizkörperthermostat weiter zu geben ist es erforderlich ein virutelles Homematicgerät anzulegen. Mit der VCCU ist das sehr einfach:

set VCCU virtual 1

legt ein virtuelles Homematic-Gerät an. Das Gerät ist im Ausgangszustand ein einfacher Button. Falls man schon ein- oder mehrere virtuelle Geräte angelegt hat, so müssen die vorherigen virtuellen Geräte hinzuaddiert werden, da sonst kein neues Gerät erstellt wird.

virt.png

Dieser virtuelle Button kann nun für alle möglichen Zwecke genutzt werden. Da wir hier einen Temperatursensor haben wollen, benennen wir den Button um, um dieses erkenntlich zu machen.

rename VCCU_Btn2 NAME

In meinem Fall heißt er „wz_Vt“ und befindet sich im Room – Wohnzimmer.

Damit der neue virtuelle Sensor auch eine Temperatur erhält muss die gemessene Temperatur des Xiaomi Sensors an den virtuellen Sensor weitergegeben werden, das geschieht mit einem kleinen „at“.

define NAME at +*00:02 { my $T=(ReadingsVal("Name des echten Temperatursensors","temperature",19.9));; fhem ("set Name des virtuellen Temperatursensors $T") }

Alle zwei Minuten wird nun der Wert des Xiaomi Temperatursensors an den virtuellen Homematic-Sensor weitergegeben.

vt

Zum Schluss muss der virtuelle Sensor nur noch mit dem Kanal _Weather des Heizkörperthermostat bekannt gemacht werden. Das geschieht mit

set Name des virtuellen Sensors peerChan 0 Homematic Heizkörperthermostat_Weather single

Ich habe den einen virtuellen Sensor direkt mit drei – in einem Raum befindlichen Thermostaten gepeered. Im folgenden Bild seht ihr alle Clima-Kanäle der Thermostate, den „echten“ Sensor und dem Virtuellen.

overview

zurück zum Inhalt

Alternative  Tür- Fensterkontakte

Tür- Fensterkontakte mit Homematic-Heizkörperthermostaten zu verbinden macht, meiner Meinung nach, die Heizungssteuerung überhaupt erst smart. Zudem kann man Tür- Fensterkontakte auch super für eine Alarmanlage nutzen.

Die Tür- Fensterkontakte von Homematic schlagen hier mit etwa 20 € (als Bausatz) zu Buche – hier die optische Version:

P_20180330_165620_vHDR_Auto.jpg

Die von mir verwendeten Xiaomi Sensoren liegen bei ca. 10 € (direkt aus China):

P_20180330_165637_vHDR_Auto

Um einen Tür- Fensterkontakt mit dem Thermostat zu verbinden gibt es, um es mit den Worten von Albus Dumbledore zu sagen, einen einfachen Weg – und einen Richtigen. Welchen man wählt, bleibt einem selbst überlassen, Anmerkungen dazu stehen am Ende der Seite.

Der einfache Weg

Dazu wird ein simples Doif angelegt, welches die Temperatur des _Clima – Kanals des Thermostaten bei geöffnetem Fenster auf den Wert 10 setzt und bei geschlossenem Fenster wieder in den Automatikmodus.

define Name des Doif DOIF ([Tür-Fensterkontakt:state] eq "open") (set Homematic-Thermostat_Clima desired-temp 10) DOELSEIF ([Tür-Fensterkontakt:state] eq "close") (set Homematic-Thermostat_Clima controlMode auto)

Damit das Thermostat möglichst schnell reagiert, wird der Burst Modus am Thermostat aktiviert, dazu wird der Kanal _Clima genutzt.

set Homematic-Thermostat_Clima regset burstRx on

Am Thermostat wird noch folgendes Attribut gesetzt

attr Homematic-Thermostat burstAccess 1_auto

Fertig.

Ich hatte so  vier Thermostate mit Tür-Fensterkontakten verbunden. Die Reaktionszeit der Thermostate ist dabei allerdings etwas unterschiedlich. Während das Umschalten der Temperatur in einem Raum exakt so schnell reagiert wie mein Referenzaufbau mit dem Homematic Tür-Fensterkontakt, dauert es in anderen Räumen zwischen 5 und 40 Sekunden bis der Wert umschaltet. Möglicherweise spielt die Entfernung zwischen Thermostat und IO-Device dabei eine Rolle. Ich bin mittlerweile komplett auf den „richtigen Weg“ umgestiegen.

Der richtige Weg

Hier führt der Weg über einen virtuellen Homematic-Kanal. Dieser wird erstmal in der VCCU angelegt.

set VCCU virtual X

Je nach Anzahl der bei euch bereits vorhandenen Kanäle (in meinem Fall „1“), weicht die Ziffer natürlich ab. Wenn schon drei virtuelle Kanäle vorhanden sind – so muss die Ziffer „4“ sein, um einen Weiteren anzulegen.

Der neue virtuelle Kanal heisst, wie üblich, VCCU_Btn (in meinem Fall VCCU_Btn2) – um ihn für seinen neuen Zweck eindeutig zu benennen, führt man ein rename durch.

rename VCCU_Btn2 neuer Name

Ich hab ihn „SzFv“ genannt, das steht für Schlafzimmer Fenster virtual. Man kann den virtuellen Kanal nun auch direkt dem entsprechenden Raum zuweisen.

Folgende Attribute werden dem virtuellen Kanal nun hinzugefügt

attr virtueller Kanal expert 1_allReg
attr virtueller Kanal model HM-SEC-SCo
attr virtueller Kanal webCmd postEvent open:postEvent closed

Der virtuelle Kanal ist jetzt fertig – nun fehlt noch ein Utility, dass den Status des realen Sensors an den virtuellen Kanal weitergibt. Hier kann man auf das Notify, aus dem Wiki zurückgreifen, oder ein Doif erstellen. Ich persönlich bevorzuge das Doif.

Das Notify lautet

define Name des Notify notify (echter Fensterkontakt_1|echter Fensterkontakt_2) {if(Value("echter Fensterkontakt_1") eq "open" && Value("echter Fensterkontakt_2") eq "open"){fhem("set virtueller Kanal postEvent open")}else{fhem("set virtueller Kanal postEvent closed")}}

Das obige Notify ist für zwei Fensterkontakte vorgesehen – falls ein Raum an Tür und Fenster je einen Sensor hat oder zwei Fenster und entsprechend zwei Sensoren – macht das natürlich Sinn.

In meinem Fall reicht mir ein Sensor, daher habe ich das Notify entsprechend verkürzt

define Name des Notify notify (echter Fensterkontakt) {if(Value("echter Fensterkontakt") eq "open"){fhem("set virtueller Kanal postEvent open")}else{fhem("set virtueller Kanal postEvent  closed")}}

Wenn man alles korrekt gemacht hat, dann sollte das Notify nun den Status des echten Sensors an den virtuellen Kanal triggern.

Ein Doif für einen Sensor würde wie folgt lauten

define Name des Doif DOIF ([echter Fensterkontakt:state] eq "open")(set virtueller Kanal postEvent open) DOELSE (set virtueller Kanal postEvent closed)

Was jetzt noch zu tun bleibt ist den virtuellen Kanal mit dem _WindowRec des Thermostaten zu peeren.

set virtueller Kanal peerChan 0 Thermostat_WindowRec single set

und dem Thermostat zu sagen, auf welche Temperatur (hier 5 °) runtergeregelt werden soll

set Thermostat_WindowRec regSet winOpnTemp 5 virtueller Kanal

Falls Fhem bei dieser Eingabe meckert, muss zwischendurch ein

set Thermostat_WindowRec getConfig

ausgeführt werden und der winOpnTemp Befehl erneut gesendet werden.

Wer möchte, kann noch die interne „Fenster-auf-Erkennung“  des Thermostaten abschalten – meiner Meinung nach funktioniert diese sowieso nicht allzu zuverlässig und ist daher verzichtbar

set Thermostat_Clima regSet winOpnMode off

Öffnet man nun das entsprechende Fenster mit dem „echten Sensor“ triggert das Notify oder das Doif den Status des „virtuellen Kanals“ – das Thermostat regelt auf 5 ° herunter und auf dem Display des Thermostaten ist auch das entsprechende Fenstersymbol zu sehen. Beim Schließen des Fensters triggert das Notify oder das Doif „closed“ an den „virtuellen Kanal“ – das Thermostat setzt sich wieder in den Automatik-Modus.

Die Reaktionszeit ist übrigens super!

Wozu das Ganze, wenn der einfache Weg auch funktioniert?

– Angenommen, ein Fenster wird um 15 Uhr geöffnet und bleibt bis 15:30 geöffnet. Ein Heizplan gibt vor, dass ab 15:15 Uhr geheizt werden soll. Beim „einfachen Weg“ wird um 15:15 Uhr die Temperatur vom Heizplan eingestellt, unabhängig davon, ob das Fenster tatsächlich geschlossen wurde – beim „richtigen Weg“ passiert das nicht.

– Die Umschaltzeit des Thermostaten im „einfachen Weg“ ist unterschiedlich lang. Mit dem „richtigen Weg“ verhält sich das System wie eine originale Homematic-Kombination.

– Beim „richtigen Weg“ muss ein Device mehr angelegt werden – bei entsprechender Anzahl an Sensoren macht man Einbußen bei der Übersichtlichkeit.

zurück zum Inhalt