Systemübersicht
Ein FHEM System besteht im Prinzip aus den in der nachfolgenden Übersicht aufgeführten Bestandteilen.
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:
![Info green.png](/w/images/thumb/0/02/Info_green.png/20px-Info_green.png)
- 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.
![Info green.png](/w/images/thumb/0/02/Info_green.png/20px-Info_green.png)
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
![Info green.png](/w/images/thumb/0/02/Info_green.png/20px-Info_green.png)
- 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
![X mark.svg](/w/images/thumb/a/a2/X_mark.svg/20px-X_mark.svg.png)
- private Homepages
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
Interfaces
Die Verbindung zu den angeschlossenen Geräten der Hausautomation wird im Allgemeinen - geräteabhängig - über Interfaces (manchmal auch als Gateway bezeichnet) hergestellt. Diese setzen die FHEM Steuerbefehle in das jeweilige (Funk-) Protokoll um - und geben auch die (Funk-) Telegramme der Komponenten an FHEM zurück. Häufig steht nicht nur ein ganz bestimmter Interface-Typ zur Verfügung, sondern mehrere, wie in der Übersichtsgrafik beispielhaft für einige Technologien wie ZWave, HomeMatic oder 1-Wire ersichtlich. Es genügt dabei, wenn dem FHEM-Server ein Weg zur Datenübermittlung mit z.B. einem Aktor zur Verfügung steht.
In der Regel ist es empfehlenswert, ein speziell für das verwendete Protokoll konzipiertes Interface zu verwenden, also z.B.
- ZWDongle statt ZWCUL für ZWave oder ein
- HomeMatic Funkmodul für Raspberry Pi, ein HMLAN Konfigurator (ein mittels LAN mit dem FHEM Server verbundenes Gerät) statt eines CUL.
Bei CUL und seinen Derivaten könnnen z.B. beim HomeMatic-Protokoll Probleme mit dem Timing auftreten.
Durch die Wahl einer von mehreren Interface-Varianten kann ein und diesselbe Komponente in FHEM im Ergebnis sehr unterschiedlich ausgestaltet und zu steuern sein. Nutzt man z.B. für HomeMatic (BidCoS) HMUARTLGW oder CUL als Interface-Typ, werden die Sensoren oder Aktoren als CUL_HM-Geräte in FHEM repräsentiert, wählt man eine CCU2 oder CCU3, werden die Komponenten dann über die HMCCU-Modulfamilie eingebunden.
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).
![Info blue.png](/w/images/thumb/7/7e/Info_blue.png/40px-Info_blue.png)
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.
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 | - | 2,4 GHz | HUE Bridge (o. RaspBee bzw. ConBee II, es existieren weitere alternative Methoden, z.B. auch über Bridges anderer Anbieter | HUEBridge | Neben Philips HUE wird potentiell eine Vielzahl von weiteren Produktlinien anderer Hersteller unterstützt | [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 ** = Produkte evtl. nur noch gebraucht erhältlich |
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.
![Info blue.png](/w/images/thumb/7/7e/Info_blue.png/40px-Info_blue.png)
FHEM und das Inter-/Intranet
FHEM kann mit Modulen in vielfältiger Weise Informationen mit und über das Inter- und/oder Intranet austauschen. Bereits die in der Übersicht enthaltenen Beispiel-Interfaces CCU3 und OWServer nutzen effektiv Netzwerkprotokolle zur Verbindung mit FHEM, entsprechendes gilt bei Nutzung des MQTT-Protokolls oder Kalendern. Weitere Beispiele wären
- Sprachsteuerungssysteme
- Messanger-Dienste wie Telegram oder Whatsapp
Insbesondere bei der Nutzung solcher Dienste zur Steuerung Ihrer Komponenten sollten Sie darauf achten, dass diese angemessen gegen Zugriffe von unberechtigten Dritten abgesichert sein sollten. Bereits im Auslieferungszustand enthält FHEM selbst hierzu einige Mechanismen, die erforderlichenfalls angepaßt werden sollten, insbesondere ist durch allowed der Zugriff auf FHEMWEB nur aus demselben privaten Netzwerksegment zugelassen. Beachten Sie hierzu vor allem die entsprechenden Hinweise in der commandref des jeweils genutzen Moduls.