Systemübersicht

Ein FHEM System besteht im Prinzip aus den in der nachfolgenden Übersicht aufgeführten Bestandteilen.

Systemübersicht

Server

Bei der Komponente Server muss unterschieden werden zwischen dem eigentlichen FHEM Hausautomations-Server (implementiert in der Perl-Datei fhem.pl) und der Hardware, auf der dieser Server ausgeführt wird.

Als Server Hardware sind (z. B.) möglich:

FHEM kann zwar prinzipiell auch auf einem Router (z. B. FritzBox) betreiben werden, in der Regel ist jedoch heute der Einsatz einer anderen Hardwarebasis zu empfehlen

• Windows Rechner
• Linux Rechner
• OS X Rechner
• Einplatinencomputer, wie Raspberry Pi, BeagleBone Black
• DockStar, PogoPlug, etc.
• diverse NAS Systeme wie Buffalo Linkstation, Synology Diskstation
• Virtualisierungslösungen einschließlich Docker sind ebenfalls möglich

(Diese Aufstellung ist nur eine unvollständige Auswahl; Details zu unterstützten Server Systemen finden sich in der Kategorie Server Hardware).

Perl

Auf dem Server muss Perl installiert sein. Zur erforderlichen Version gibt es widersprüchliche Aussagen, die vor allem daraus resultieren, dass verschiedene FHEM-Module von verschiedenen Entwicklern stammen und daher unterschiedliche Anforderungen stellen. Laut FHEM-Webseite wird mindestens Version 5.6 benötigt, faktisch setzen aber viele Module 5.10 oder sogar 5.12 voraus. Der Betrieb mit Grundfunktionen ist jedoch zumindest ab Version 5.8.8 mit Einschränkungen möglich.

Konfiguration

Das Hausautomations-System wird definiert über die Konfiguration, die im Regelfall aus der

• reinen Textdatei fhem.cfg (Standard nach der Erstinstallation) oder alternativ einer
• SQL-Datenbank

besteht.

Die Konfiguration enthält Definitionen für die Bestandteile (Geräte) und Funktionen des jeweiligen Hausautomations-Systems. Die verfügbaren Befehle und deren Syntax sind in der Befehlsreferenz (commandref) aufgeführt und beschrieben. Zu einigen Hilfsmodulen gibt es detaillierte Beschreibungen mit Beispielen.

Benutzeroberfläche

Der Zugriff auf FHEM erfolgt mittels Webbrowser oder App über die verfügbaren FHEM Benutzeroberflächen.

Vor featurelevel 5.9 wurden in der Regel mehrere FHMWEB-Instanzen für unterschiedliche Geräteklassen angelegt: Desktop-Darstellung = Port 8083, Smartphone-Darstellung = Port 8084 und Tablet-Darstellung = Port 8085. Dies ist immer noch möglich, insbesondere, wenn man in FHEMWEB einen anderen Style einstellt, der die Seite nicht automatisch auf die Bildschirmgröße anpaßt.

In den FHEM Server integriert ist ein Webserver (PGM2), der im Prinzip immer zur Verfügung steht. Diese häufig als FHEMWEB bezeichnete Schnittstelle ist über serverhostnameoderIP:8083/fhem erreichbar.

Eine Auswahl der Benutzeroberflächen:

• PGM2/FHEMWEB - das Standardinterface, das ebenfalls viele Möglichkeiten bietet, die Darstellung an die eigenen Bedürfnisse anzupassen
• FLOORPLAN
• FHEM Tablet UI, mit der Erweiterung FUIP
• SmartVISU
• diverse Apps für iOS und Android (Auswahl unter: FHEM Benutzeroberflächen)

Beispielhafte Screenshots diverser Benutzeroberflächen: http://fhem.de/fhem.html#Screenshots

Module

Die Funktionalität von FHEM kann über Module erweitert werden. Module können die unterschiedlichsten Aufgaben übernehmen vom Anbinden eines Hardwaresystems über die Bereitstellung eines Frontends bis zur Automatisierung von Aufgaben. Beispiele für Module:

• 00_CUL.pm - Implementierung der Unterstützung für den CUL

Sehr häufig stehen mehrere Varianten zur Verfügung, mit denen eine bestimmte Hardware in FHEM eingebunden werden kann, aber nicht immer alle Module der einen Variante einer Einbindung mit den Modulen der weiteren Variante kompatibel sein müssen. Entsprechende Hinweise, welche sog. Client-Module zu den jeweiligen Interface-Modulen (s.u.) passen, sind in der Regel der commandref zu entnehmen.

• 00_ZWDongle.pm und 10_ZWave.pm zur Einbindung von Geräten der in der ZWave-Alliance verbundenen Hersteller
• 00_HMUARTLGW.pm oder 00_CUL.pm zur Einbindung von HomeMatic-Geräten
• 88_HMCCU.pm und 88_HMCCUDEV.pm oder 88_HMCCUCHN.pm zur Einbindung von HomeMatic und/oder HomeMatic-IP-Geräten (benötigt eine CCU2 oder CCU3)
• 57_Calendar.pm zur Einbindung von ical-Dateien
• 95_FLOORPLAN.pm - Grundriss (oder Ähnliches) als Benutzeroberfläche
• uvm.

Module können unterteilt werden in

• Befehlsmodule (FHEM-Befehle sind teilweise eigenständige Module)
• Hilfsmodule
• Gerätemodule

Die offiziell in FHEM enthaltenen Module sind in der commandref beschrieben. Sie werden über den Update-Befehl von FHEM verteilt und aktualisiert. Voraussetzung für die Aufnahme als offizielles Modul sind Supportwille durch den Entwickler und Dokumentation des Moduls.

Zusätzlich existiert eine Vielzahl von inoffiziellen Modulen, die manuell in FHEM installiert werden können. Auch die Aktualisierung erfolgt nicht über den Update-Befehl, sondern muss durch den Nutzer selbst erfolgen. Inoffizielle Module sind an den verschiedensten Stellen zu finden:

• Contrib-Verzeichnis im offiziellen FHEM-Sourcecode-SVN [1]
• Beiträge im FHEM-Forum

Bei Quellen außerhalb der von FHEM e.V. bereitgestellten Infrastruktur erhalten Sie jedoch in der Regel wenig Support von der FHEM-Community.

• private Homepages

Interfaces

Die Verbindung zu den angeschlossenen Geräten der Hausautomation wird im Allgemeinen - geräteabhängig - über Interfaces (manchmal auch als Gateway bezeichnet) hergestellt. Das kann z. B. im Falle von HomeMatic ein HMLAN Konfigurator sein, ein mittels LAN mit dem FHEM Server verbundenes Gerät, das die FHEM Steuerbefehle in das HomeMatic Funkprotokoll umsetzt - und auch die Funktelegramme der HomeMatic Komponenten an FHEM zurückgibt. Bei HomeMatic-Komponenten ist der Einsatz von Interfaces des Hersteller dieser Geräte (eQ-3) zu empfehlen, da bei CUL und seinen Derivaten Probleme mit dem Timing auftreten können. Eine Übersicht hierzu ist hier zu finden. Auf der Übersichtsgrafik sind u.a. HomeMatic und 1-Wire beispielhaft dafür aufgeführt, dass es in vielen Fällen nicht nur einen ganz bestimmten Weg gibt, über den der Datenaustausch zwischen dem Interface und einem Sensor oder Aktor stattfinden kann, sondern gelegentlich sehr viele sehr unterschiedliche Wege zur Auswahl stehen, für HomeMatic (BidCoS) z.B. unterschiedliche IO-Typen (CUL, HMUARTLGW), bei denen die Sensoren oder Aktoren als CUL_HM-Geräte in FHEM repräsentiert werden, oder über eine CCU2 oder CCU3, die dann über die HMCCU-Modulfamilie eingebunden werden kann. In der Regel genügt es, wenn dem FHEM-Server ein Weg zur Datenübermittlung mit z.B. einem Aktor zur Verfügung steht.

Entsprechende Interfaces gibt es auch für andere Funkprotokolle und für die drahtgebundenen Systeme.

Eine (unvollständige) Liste solcher Interfaces (siehe auch Kategorie Interfaces):

• CUL - je nach Einstellung für die Kommunikation mit FS20, FHT und andere SlowRF Protokolle, MAX! Heizungssteuerung oder HomeMatic und, mit Einschränkungen, InterTechno (nur senden)
• CUNO, ähnlich CUL, jedoch nicht per USB sondern per IP angebunden (z.Zt. -Stand Juli 2019 - nicht für HomeMatic empfohlen)
• HomeMatic LAN Konfigurations-Adapter - HomeMatic
• HomeMatic Funkmodul für Raspberry Pi - Homematic
• Homematic CCU2 - HomeMatic und HomeMatic IP
• MAX! Cube LAN-Gateway
• Schnittstellen(karten) für 1-Wire
• TCM(120/310) zur Anbindung von EnOcean
• Arduino mit Firmata über USB oder Netzwerk
• panStamp als Möglichkeit Arduinos mit diversen Sensor- und I/O- Boards per 868MHz Funk über das SWAP protokoll anzubinden
• JeeLink, ein weiteres USB-Stick Interface (ebenfalls arduino basiert) für diverse 433MHz und 868MHz Komponenten
• RFXtrx für InterTechno, RSL, ELRO etc., Wetter-Sensoren (Oregon-Scientific, Cresta, La Crosse, TFA, UPM) und andere 433 Mhz Geräte.
• manche Komponenten (IP Komponenten) können über TCP/IP (LAN) direkt vom FHEM Server aus angesprochen werden; hier ist dann kein weiteres Interface im eigentlichen Sinne erforderlich. Dies gilt auch für diverse Module die Geräte über WEB Dienste des Herstellers anbinden (z. B. Withings, netatmo, MQTT).

In manchen Fällen sind die Grenzen zwischen einem Modul und einem Interface noch weniger auszumachen oder ganz verschwunden. So stellt z.B. MQTT2_SERVER unmittelbar einen Serverdienst zur Verfügung, der nicht nur für FHEM genutzt werden könnte und eine reine Softwarekomponente darstellt. Beachten Sie auch, dass externe Interface-Geräte wie eine CCU3 oder eine HUE-Bridge auch von anderen Diensten her angesteuert werden oder eigene Logikbausteine enthalten können, und auch häufig die Möglichkeit besteht, dass mehrere Nutzer unmittelbar diese Interface-Geräte z.B. über eine Handy-App ansteuern. Dies ist insbesondere zu beachten, wenn man Ursachen für das beobachtete Verhalten der darüber gesteuerten Komponenten analysiert. Hier liegt ein wesentlicher Unterschied zu den in der Regel exklusiv dem Zugriff von FHEM unterstellten UART oder USB-Interfaces.

Protokolle

Der Kommunikation zwischen Interfaces und Geräten liegt jeweils ein bestimmtes Protokoll (in der Grafik: data exchange) zugrunde. Unterstützte Protokolle mit ihren Eigenschaften sind in der folgenden Tabelle aufgelistet.

Übersicht über unterstützte Funkprotokolle

Name	rfMode	Frequenz	Modulation	Datenrate	Interfaces	Modul	Geräte (Beispiel)	Bemerkungen
FS20	SlowRF	868,35MHz	AM	1kHz	CU*, FHZ	FS20	-	-
FHT	SlowRF	868,35MHz	AM	1kHz	CU*, FHZ	FHTTK, FHT	Heizungsregelung	-
S300	SlowRF	868,35MHz	AM	1kHz	CU*, FHZ	CUL_WS	Temperatur-/Feuchtesensoren	-
HMS	SlowRF	868,35MHz	AM	1kHz	CU*O, FHZ	-	??	-
EM	SlowRF	868,35MHz	AM	1kHz	CU*, FHZ	CUL_EM	Energiemonitore (Strom, Gas)	-
HomeMatic	HomeMatic	868,3MHz	FM	10kHz	CU*, HMLan, HMUsb, HomeMatic Funkmodul für Raspberry Pi	CUL_HM, HMUARTLGW	diverse	Alternative Anbindung über HMCCU möglich!
HomeMatic-IP	HomeMatic-IP	868,3MHz	FM	10kHz	HMCCU	HMCCUDEV, HMCCUCHN	diverse	-
MAX!	MAX	868,3MHz	FM	20kHz	CU*, MAXLAN	MAX	Wandthermostat, Heizkörperthermostate, Fensterkontakt, Zwischenstecker	-
IT u.a. 433MHz-Protokolle	-	433MHz	AM?	1kHz	CU*433, SIGNALDuino	-	-	-
Firmata WiFi	-	2,4/5 GHz				FRM	Arduino	-
SWAP	-	868 (433/915) MHz	GFSK	38.3835 Kbps	panStamp (+panStick)	SWAP	RGB LED Driver, diverse Sensoren und Aktoren	-
EnOcean	-	315 / 868 / 902 / 928MHz	ASK	125 kbit/s	TCM	EnOcean	Batterielose Funksensoren, diverse Aktoren	-
PCA	-	868,35MHz	??	??	JeeLink	PCA301	PCA301	-
La Crosse	-	868,35MHz	??	??	JeeLink, LGW	Lacrosse	LaCrosse IT+ (Technoline) Sensoren	-
ZigBee Light Link	-	2,4 GHz			HUE Bridge (RaspBee), alternative Methoden	HUEBridge	Philips HUE und LightLink Lampen (auch Osram LIGHTIFY an der HUE-Bridge)	[2]
MySensors	-	2,4 GHz, 868/433 MHz, RS485 (2-Draht)			MySensors Gateway, MQTT	MYSENSORS_DEVICE	Selbstbau-Sensoren	auch LoRa möglich
Z-Wave	-	868MHz	2-FSK	9.600 bit/s oder 40 Kbit/s	ZWDongle, (experimentell: ZWCUL)	ZWave, Z-Wave	-	-
WMBUS	WMBus_T, WMBus_S, WMBus_C	868MHz	??	100 kbit/s / 32.768 kbit/s	CU*	WMBUS	Wasseruhren, Wärmezähler, Elektrozähler	-
Tabelle muss noch vervollständigt werden
Legende:		CU* = CUL, CUN, CUNO /

Übersicht über drahtgebundene Systeme

Name	Interfaces (Hardware)	Modul	Geräte (Beispiel)	Bemerkungen
1-Wire	diverse	OWX, OWServer	1-Wire	-
EIB/KNX	TUL	KNX	EIB/KNX	-
Firmata	RS-232, USB, Ethernet	FRM	Arduino	-
HomeMatic Wired	HM485 LAN Gateway	HM485_LAN	Präfix HMW	-
MySensors	MySensors Gateway	MYSENSORS_DEVICE	Selbstbau-Sensoren	Zu Funk: s.o.
Modbus	z.B. RS485 USB Adapter	Modbus	Relaisplatinen, Heizungssteuerungen	-
Tabelle muss noch vervollständigt werden

Komponenten

Der eigentliche Zweck eines Hausautomatisierungs-Projekts sind dann letztendlich die Geräte (Komponenten / Aktoren / Empfänger), die automatisch gesteuert werden sollen, bzw. auch Auslöser für Aktionen (Sender) und Lieferant von Datenmaterial (Sensoren) sind.

Diese Geräte - in der Übersichtsgrafik als Sensors & Actuators bezeichnet - sind, sofern es eine detaillierte Beschreibung dazu gibt, in den jeweiligen Unterseiten der Hardwareliste aufgeführt.

Weblinks

• EnOcean Homepage
• ELV, (Haupt-)Lieferant von FS20, FHT, HomeMatic, MAX!
• Firmata Protokoll
• panStamp, panStamp Hersteller
• Jeelabs, JeeLink Hersteller
• Zigbee Homepage