FHEM-CCU-Homebridge-Datenbank

Um den Datenfluss zwischen Sensor/Aktor, CCU, FHEM, Homebridge und Datenbank zu konfigurieren, ist zuerst die Entscheidung zu treffen, ob FHEM oder die Homematic-CCU die Kommunikation mit den Sensoren/Aktoren gestalten sollen.

Bei neuen Projekten sollte dies über die CCU erfolgen, um die dort bereits integrierte Funktechnik (868MHz) zu nutzen.
Alternativ bei Priorisierung von FHEM wäre der Steuer-Raspi mit einem CUL-Stick zu bestücken.

Bei Kommunikation über die CCU werden die Sensoren/Aktoren in der CCU angemeldet und von dieser gesteuert.
Die CCU ist dann an den FHEM anzubinden.

Verbindung CCU - FHEM

Um die Verbindung zum FHEM herzustellen, ist das Modul HMCCU in FHEM einzubinden.

Eine gute Beschreibung hierzu ist unter https://wiki.fhem.de/wiki/HMCCU zu finden.
Ergänzende Infos unter: https://wiki.fhem.de/wiki/HMCCU_Best_Practice

Wichtig sind wie in dem Artikel beschrieben die Installation des Moduls, die Aktivierung des RPC-Servers und ein korrektes Autocreate von FHEM-Devices für CCU-Geräte.

Verbindung zur Homebridge

Jetzt gibt es grundsätzlich 2 Möglichkeiten:

1. Homebridge wird auch direkt mit der CCU verbunden. Das erfolgt mit dem Plugin homebridge-homematic. Hier der direkte a title="Homematic Plugin für Homebridge"""""Link.
2. Alternativ kann man aber auch das homebridge-fhem Plugin verwenden und damit die über FHEM von der CCU geholten Geräte auch in Homebridge verfügbar machen. Auch hier der a title="FHEM Plugin für Homebridge"""""Link zum Plugin.

Man kann sogar beide Einrichtungen gleichzeitig machen, also in der Homebridge beide Plugins nutzen und das Gerät sowohl aus FHEM als auch direkt aus der CCU einbinden. Das funktioniert, halte ich aber nicht für eine gute Idee. Ich habe bei mir zwar auch beide Plugins in Homebridge installiert, sorge aber über die Raumangabe in FHEM dafür, dass das Gerät nicht doppelt in der Homebridge erscheint.

Datenbank (1) - Zugriff auf FHEM mittels URL

Um die Daten aus FHEM für die Datenbank auslesen zu können, ist zu beachten, dass der Zugriff auf die html-Schnittstelle von FHEM (erledigt das Programm HR und nutzt dafür curl) mittlerweile durch einen csrfToken verhindert wird. Es ist zwar möglich diesen Token auch mittels curl zu ermitteln und in folgenden Aufrufen dann zu verwenden, ich habe mich aber für eine einfachere, wenn auch etwas unsicherere Variante entschieden und zwar neben dem normalen Web-Interface von FHEM (welches über den csrfToken weiterhin geschützt bleibt) unter dem Port 8083 ein zusätzliches Web-Interface unter dem Port 8084 (den Port kann man natürlich frei wählen) angelegt. Unter diesem Port wird der csrfToken dann abgeschaltet und der Zugriff nur für bestimmte IP-Adressen freigegeben:

define WEBapi FHEMWEB 8084 global
(Anlegen)

attr WEBapi csrfToken None
(Token abschalten)

attr WEBapi allowfrom ^192\.168\.2\.([1-9]|[1-9]\d|1\d\d|2[0-4]\d|25[0-4])$|127.0.0.1
(Zugriff nur aus definiertem Adressbereich bzw. von localhost erlauben)

Den RegEx-Ausdruck für allowfrom kann man mit einem Generator berechnen:

Unter diesem Port kann man dann direkt per Browser auf die FHEM-Daten zugreifen. Hier mal ein paar Beispiele:

http://192.168.21.86:8084/fhem&cmd.WLAN={ReadingsVal("HKTH_Boden","ACTUAL_TEMPERATURE",0)}&XHR=1
Ergebnis: 20.5 (die derzeitige IST-Temperatur, die das Heizkörperthermostat HKTH_Boden ermittelt hat)

http://192.168.21.86:8084/fhem&cmd.WLAN={ReadingsVal("HKTH_Boden","SET_TEMPERATURE",0)}&XHR=1
Ergebnis: 22.0 (die SOLL-Temperatur, die am Heizkörperthermostat HKTH_Boden eingestellt ist)

http://192.168.21.86:8084/fhem&cmd.WLAN={ReadingsVal("HKTH_Boden","VALVE_STATE",0)}&XHR=1
Ergebnis: 0 (die Ventilstellung am Heizkörperthermostat HKTH_Boden)

http://192.168.21.86:8084/fhem?cmd.WLAN=set HKTH_Boden control 21
Ergebnis: keine Rückmeldung, denn mit diesem Aufruf wird eine neue SOLL-Temperatur an das Heizkörperthermostat HK_TH_Boden übermittelt

Zum csrfToken siehe auch:

https://heinz-otto.blogspot.com/2017/03/csrf-token-und-fhem.html
https://wiki.fhem.de/wiki/CsrfToken-HowTo

Datenbank (2) - Ablaufschema mit HR

HR ist das Hauptprogramm der gesamten Heizungs- und Haussteuerung. Es ist in C++ geschrieben und läuft als Dienst mit systemctl auf dem Raspi. Zur Funktionsweise könnte ihr auch hier weiterlesen: Steuern und Regeln mit MySQL

Nachfolgend nur kurz der prinzipielle Ablauf - oder wie kommen die Daten nun von FHEM in die Datenbank.

Jedes Gerät wird in der Datenbank initial angelegt. Nachfolgend ein paar Geräte als Beispiel. Die meisten Spalten erklären sich von selbst. Entscheidend ist hier die in der Spalte init angegebene URL. Hier seht ihr wieder den oben schon beschriebenen Aufruf für FHEM. Das vorweggestellte "FHEM_HM_GET#" wird vom Programm HR benutzt, das damit weiß, dass dieser Aufruf via curl abzusenden ist und ein Ergebnis liefert, was dann unter der Geräte-ID (z.B. 393) in der Messwerttabelle der Datenbank gespeichert wird. Durch "FHEM_HM_SET#" wird HR im Gegensatz dazu mitgeteilt, dass ein Wert zu senden ist. Dieser steht logischerweise auch in der Datenbank (sogenannter Sollwert) und wird nach "control " an die URL angehangen. Dann erfolgt der Aufruf auch dieser so gebildeten URL mit curl durch HR.

HR läuft zyklisch, bei mir im 3-Minuten-Takt. Dass heißt, alle 3 Minuten werden auf der Datenbank die neuen Sollwerte (die natürlich auch unverändert gegenüber den zuletzt ermittelten sein können) abgeholt und an die entsprechenden Geräte gesendet.

Die hier beschriebene Sendung an / Abholung von FHEM ist nur eine der möglichen Varianten, die aber äußerste stabil funktioniert. 

In den letzten beiden Jahren habe ich sehr viel und sehr gerne mit MQTT gearbeitet. Unter anderem hat meine Datenbank (mariaDB) Schnittstellen bekommen, die dafür sorgen, dass:

1. jeder in der Datenbank angekommene Messwert auch an einen mqtt-Broker gesendet wird, was seine beliebige Weiterverarbeitung ermöglicht (also aus der Datenbank an den Broker),
2. Messwerte beliebiger mqtt-fähiger Geräte (esp8266 zum Beispiel) von der Datenbank aufgenommen werden können (also vom Broker in die Datenbank),
3. auch Sollwerte auf diesem Weg an die Datenbank zur Weiterverarbeitung gesendet werden können.

Zielstellung war immer, dass FHEM, CCU, Homebridge, Datenbank und mqtt-Broker synchron sind, also die Soll- und Messwerte gegenseitig "durchreichen".

Zu mqtt gibt es irgendwann mal etwas mehr Beschreibung wenn ich Zeit dafür finde. Insbesondere der Weg der Daten aus der Datenbank an den Broker ist spannend.