Mit FHEM zum Low Budget-Smart Home – Der neue Einsteigerguide von meintechblog

IM EINSATZ?

Dann schau dir UNSEREN LOXKURS an und profitiere von unserem Wissen!

Du bist neu im Umfeld von Smart Home, möchtest nachrüsten und vor allem auf Funklösungen setzen? Du möchtest mit einer kleinen, preiswerten Lösung starten, dir aber den Weg für eine wachsende Lösung nicht verbauen? Du stehst auf Open Source und willst richtig spannende Szenarien in deinem Zuhause automatisieren und mit deinem Smartphone steuern? Dann könnte FHEM deine Lösung sein!

Der Einsteigerguide von meintechblog führt dich an das System heran und hilft dir bei der Entscheidungsfindung.

Kernvorteile von FHEM vorab zusammengefasst

  • FHEM ist Open Source und somit kostenlos
  • FHEM läuft auf unterschiedlicher Hardware (z.B. dem preiswerten Raspberry Pi (Affiliate-Link), NAS oder Barebones)
  • FHEM verwaltet unzählige unterschiedliche Smart-Home-Systeme einheitlich unter einer Oberfläche mit einer zentralen Konfigurationslogik (aktuell gibt es in FHEM rund 420 Module, die hauptsächlich die Einbindung unterschiedlicher Smart-Home- oder Multimedia-Hardware verfolgen)
  • FHEM wird kontinuierlich von einer großen und wachsenden Community gepflegt und weiterentwickelt
  • FHEM ist durch verschiedene Visualisierungen erweiterbar

FHEM – die eierlegende Wollmilchsau?

FHEM was? So schwierig und wenig eingängig der Name zunächst klingen mag, so einfach lassen sich die zentralen Inhalte der Software erklären (Hintergründe zur Namensfindung gibt es im Blogpost Rudolf König im Interview – Der Erfinder von FHEM zum Thema Smart Home).

FHEM ist eine Software, die aus verschiedenen Computern einen Smart Home Server macht und Open Source erhältlich ist. Mit dieser Software ist es möglich, Smart-Home-Sensoren und -Aktoren von diversen Herstellern in einem einheitlichen Logikprogramm – dem Herzstück des Smart Homes – miteinander zu Smart-Home-Szenarien zu verbinden.

Ein Homematic Fensterkontakt (Affiliate-Link) spricht so z.B. mit einem EnOcean Heizkörperthermostat (Affiliate-Link) oder ein Technoline Temperatur-/Luftfeuchtesensor (Affiliate-Link) mit einem UFO-LED-Stripe-Steuergerät (Affiliate-Link).

Ein Smart Home ist dabei als ein vernetzten, intelligentes und vor allem selbst agierendes Zuhause zu verstehen, das durch verschiedene Sensoren Zustände erfasst (z. B. Temperatur, Luftfeuchtigkeit, Schließzustand von Türen und Fenstern, Energieverbrauch, An/Aus-Status von Lichtern etc.) und über diverse Aktoren Zustände verändert (z. B. Steuerung der Heizung, Schalten von Lichtern, Verbrauchern oder Rollläden etc.).

Exkurs: Intelligentes Smart Home Szenario am Beispiel der Rollladensteuerung

Rollladen sind ein gutes Beispiel, um ein echtes Smart Home von einem rein Smartphone-gesteuerten Zuhause zu unterscheiden. Rollladen können zahlreiche Zwecke erfüllen: Bei Kälte liefern sie zusätzlichen Wärmeschutz, bei Wäre tragen sie zur Kühlung eines Raumes bei, bei Sturm schützen sie Fenster vor Beschädigung durch herumfliegende Teile, bei Dunkelheit bieten sie Sichtschutz und bei Abwesenheit erhöhen sie die Sicherheit eines Gebäudes. Eine rein elektronische Steuerung per Taster oder Smartphone ist daher relativ unintelligent, weil keine der auslösenden Aktionen (Dunkelheit, Abwesenheit, Wärme, Kälte, Sturm etc.) von der Steuerung erkannt werden. In einem Smart Home hingegen, kommuniziert die Rollladensteuerung mit der Wetterstation, nutzt Online-Wetterdienste mit Sturmvorhersage, erkennt Abwesenheit von Bewohnern, nutzt Informationen zu Sonnenstand, Einstrahlwinkel, Kraft und Stärke der Sonne, kennt Temperaturen und reguliert automatisch die Helligkeit in einem Raum – alles ohne, dass der Anwender selbst die Steuerung vornehmen muss. Beispielszenarien zur Rollladensteuerung haben wir in den Blogartikeln HowTo: Elektrische Rolläden per FHEM und HomeMatic automatisieren und Smart-Home-Rolladensteuerung mit FHEM und Loxone: Howto und Praxistipps für Nachrüster beschrieben.

Damit derartige Aktoren wissen, wann sie welche Schaltaktion ausführen sollen, bedarf es der Definition von Smart-Home-Szenarien, die genau festlegen, welcher Aktor wie, wann, wo und bei welchen Sensor-Werten welche Schaltaktion vornimmt. Hierfür müssen Sensoren also mit Aktoren entsprechend festgelegter Vorgaben kommunizieren. All das wird mit FHEM realisiert.

Was unterscheidet FHEM jetzt allerdings von sogenannten Smart-Home-Systemen, die teilweise bereits in Print und TV beworben werden? Aus unserer Sicht liegt der Unterschied vor allem darin, dass mit FHEM im Gegensatz zu geschlossenen und primär Smartphone-gesteuerten Systemen, „echte“ Smart Homes realisiert werden können, die sich weitestgehend selbst steuern können. Dies ist einerseits dadurch bedingt, dass FHEM ein quelloffenes System ist, das ständig von einer großen Community weiterentwickelt wird und somit laufend neue Hardwaresysteme mit FHEM kompatibel sind. Andererseits bietet FHEM dem Anwender maximale Freiheit in der Gestaltung von Smart-Home-Szenarien, da sämtliche Abläufe bei Belieben in PERL programmiert werden können. Das klingt gerade für Einsteiger abschreckend, sollte es aber nicht sein! Bei meintechblog setzen wir alles daran, die FHEM-bezogenen Szenarien nachvollziehbar und auch für Laien umsetzbar zu beschreiben!

Weitere Vorteile von FHEM liegen darin, dass durch die Unabhängigkeit von bestimmten Hardware-Herstellern sehr preiswerte Smart-Home-Lösungen realisiert werden können und dass FHEM auf verschiedenen, ebenfalls preiswerten Hardwaresystemen „läuft“, u. a. auf Raspberry Pi Einplatinencomputern (Affiliate-Link), auf NAS-Systemen (z.B. auf einem QNAP– oder Synology-NAS (Affiliate-Links)), auf Barebone-PCs (ich verwende einen Intel NUC (Affiliate-Link)), ja sogar auf AVM FritzBoxen, was allerdings aus heutiger Sicht nicht mehr empfohlen wird.

Exkurs: Low-Budget Smart-Home mit FHEM am Beispiel Raumregelung der Temperatur

Zu einer Temperaturregelung einzelner Smart-Home-Räume gehören mindestens die Komponenten Temperatursensor und Heizungsaktor/Stellantrieb (im Fall eines konventionellen Heizkörpers). Setzt man auf weitestgehend geschlossene Systeme, so ist es obligatorisch, den passenden Temperatursensor zum passenden Aktor zu erwerben. Häufig sind allerdings gerade Funk-basierte Temperatursensoren nicht gerade preiswert. Schnell kostet eine Temperaturregelung pro Raum dadurch zwischen 100 und 150 Euro (50 Euro für einen Aktor, häufig zwei Heizkörper pro Raum + 50 Euro für einen Temperatursensor). In einer 3 Zimmer-Wohnung können so bis zu 750 Euro für eine Temperaturregelung fällig werden. Durch die Hardwareunabhängigkeit, ist es hingegen mit FHEM möglich, hier für jedes Hardware-Teil das passendste und gegebenenfalls günstigste Element herstellerübergreifend auszuwählen und in FHEM miteinander zu verknüpfen. Im Blogpost FHEM mit JeeLink: Luftfeuchte und Temperatur zum Low-Cost-Tarif messen haben wir z.B. die Nutzung eines etwa 17 Euro teuren „Technoline“-Temperatur- und Luftfeuchtigkeitssensors (Affiliate-Link) beschrieben. Eine derartige Konfiguration kann die Hardware-Kosten für eine Heizungssteuerung bereits um bis zu 20% senken.

Prinzip verstanden? Dann steigen wir nun etwas tiefer in die technischen Details ein.

FHEM – der Aufbau aus logischer Sichtweise betrachtet

Eine häufig verwendete Variante in FHEM-basierten Smart Homes ist die Nutzung eines Raspberry Pi als Server. Einen Raspberry Pi gibt es ohne Zubehör schon für etwa 40 Euro. Wie man FHEM auf einem Raspberry Pi (Affiliate-Link) installiert, haben wir detailliert in unserem Blogpost FHEM-Server auf dem Raspberry Pi in weniger als einer Stunde einrichten beschrieben.

Wie bereits im ersten Abschnitt angesprochen, verarbeitet FHEM Informationen zwischen Sensoren, Aktoren und natürlich den Bewohnern des Smart Home. Das heißt, es müssen zunächst einmal Sensorsignale in FHEM empfangen und Steuersignale an Aktoren von FHEM gesendet werden. Hierfür wird der jeweilige FHEM-Server – je nach Hardware – mit den entsprechenden Gateways aufgerüstet. Diese Gateways sind in unterschiedlichen Varianten erhältlich. Gängig sind Transceiver mit USB- oder LAN-Anschluss z.B. bei Funk-Smart-Home-Systemen. Welche Gateways es gibt und welche Smart-Home-Systeme sich damit steuern lassen, haben wir bereits ansatzweise im Blogpost FHEM: Welches Gateway für welches System? aufbereitet. U.a. sind  das Homematic Funk-LAN-Gateway für Homematic (Affiliate-Link), der CUL USB für zahlreiche 868- oder 433-MHz-Systeme (Affiliate-Link) oder der BSC USB300 für EnOcean(Affiliate-Link) gängige Gateways.

Noch vor etwa fünf Jahren war es in FHEM gängig, mit dem sogenannten CUL-Transceiver, der per USB mit dem FHEM-Server verbunden wurde, Funk-Systeme wie „FS20“ zu steuern. Heute hingegen genießt z. B. das bidirektionale System „HomeMatic“, welches mittels eines LAN-basierten Funk-Gateways (Affiliate-Link) an den FHEM-Server angebunden wird, große Verbreitung. Andere bekannte Namen in der Smart-Home-Branche wie EnOcean oder gar KNX können ebenfalls mit der entsprechenden Gateway-Hardware in FHEM eingebunden werden. So wird es beispielsweise möglich, dass eine HomeMatic-basierte Heizungssteuerung auf den Temperatur- und Luftfeuchtigkeitsinformationen eines EnOcean-Sensors basiert, oder eine KNX-basierte Rollladensteuerung die Helligkeitsinformationen und Sturm-Vorhersagen von Online-Wetterdiensten zur Steuerung verarbeitet. Mit diesem Prinzip lässt sich mit FHEM ein sehr effizientes, preiswertes und auf den jeweiligen Zweck ausgerichtetes Smart Home realisieren.

FHEM – Basics in der Softwarenutzung

Jede frische FHEM-Installation (z. B. wie hier für den Raspberry Pi beschrieben) bedarf der Einrichtung eines Gateways (wie z. B. im Blogpost Howto: HomeMatic Funk-LAN-Gateway mit FHEM verwenden für die HomeMatic-Schnittstelle „Funk-LAN Gateway“ (Affiliate-Link) erörtert). Zugegeben, ein optisches Highlight ist das FHEM-Webinterface nicht. Allerdings ist diese Sicht auf das System lediglich zu Programmier- und Verwaltungszwecken geeignet bzw. gedacht. Für die Nutzung auf Tablets oder Ähnlichem für den Betrieb im Smart Home kann FHEM durch Visualisierungssoftware (z. B. TabletUI oder SmartVISU ergänzt werden).

In FHEM wird jedes Objekt – und dazu zählen auch Gateways – mit dem Befehl „define“ angelegt, der in der sog. FHEM-Kommandozeile am oberen Bildrand abgesetzt wird, doch dazu später mehr. Ist ein Gateway einmal eingerichtet, kann damit begonnen werden, passende Geräte, also Sensoren und/oder Aktoren über das Gateway mit FHEM zu verbinden. Dies funktioniert entweder automatisch oder per Pairing-Befehl, wenn das entsprechende Hardware-Geräte entsprechend der Betriebsanleitung des Herstellers in den Anlern-Modus versetzt wurde. In diesem Blogpost werden alle Beispiele anhand der Smart-Home-Hardware HomeMatic erörtert.

Das HomeMatic-Funk-LAN-Gateway wird dabei z. B. mit dem define-Befehl

define HMLANGW HMUARTLGW 192.168.178.79

in FHEM eingerichtet, wobei 192.168.178.79 für die IP-Adresse des Gateways steht, die automatisch vom Internet-Router zugewiesen wird. Die vollständige Einrichtung des Gateways kann im Blogpost Howto: HomeMatic Funk-LAN-Gateway mit FHEM verwenden weiterverfolgt werden.

Bei einem Klick auf das neu angelegte Gateway entsteht nun die Möglichkeit, entweder per Klick oder erneut per Befehl in der Kommandozeile das Anlernen eines neuen und sich gerade im Lernmodus befindlichen Sensors oder Aktors durchzuführen. Hierfür wird der set-Befehl genutzt, der neben dem define-Befehl die zweite, wichtige Aktion in FHEM darstellt.

set HMLANGW hmPairForSec 60

Dabei wird das Gateway namens „HMLANGW“ für 60 Sekunden in den Anlernmodus versetzt und sucht binnen Bruchteilen einer Sekunde nach verfügbaren Hardware-Geräten. Gesucht und gefunden: Erkannte Geräte werden sofort in FHEM angelegt. In diesem Beispiel handelt es sich um eine HomeMatic-Funk-Steckdose (Affiliate-Link) mit Energiemessung mit dem „schönen“ Namen HM_25191B. Alle Geräte, die in FHEM angelegt sind, können über einen Klick auf den Raum „Everything“ eingesehen werden. Wie der Name schon vermuten lässt, wird hier einfach „Alles“, was in FHEM so angelegt ist, aufgelistet.

Um der HomeMatic Funk-Steckdose, über die wir im Blogpost HomeMatic Funk-Steckdose mit Leistungsmessung: Erweiterte Szenarien mit FHEM erstellen bereits etwas ausführlicher berichtet hatten, nun einen lesbaren Namen zu verpassen, kommt der dritte, wichtige Befehl in FHEM zur Anwendung: „rename“.

rename HM_25191B Wz.Stehlampe

In diesem Beispiel ist eine Stehlampe an die Funk-Steckdose angeschlossen, die sich im Wohnzimmer (Wz) befindet. Wir empfehlen bei der Benennung der Hardware immer den Raum in irgendeiner Form (z.B Wz für Wohnzimmer, Sz für Schlafzimmer, Az für Arbeitszimmer etc.) getrennt durch einen Punkt (.) vor dem Devicenamen zu verwenden.

Schließlich wird das Device jetzt noch einem Raum in FHEM zugewiesen. Räume sind links in der Navigationsleiste zu finden. Die Zuweisung der Funk-Steckdose zu einem Raum „Wohnzimmer“ erfolgt dabei über den nächsten, zentralen Befehl: „attr“. Diese Abkürzung für Attribut kann einem Objekt in FHEM verschiedene Eigenschaften zuweisen, die häufig abhängig vom Gerätetyp sind. Eines dieser Attribute ist der Raum.

attr Wz.Stehlampe room Wohnzimmer

Mit diesem Befehl wird die Stehlampe in den Raum Wohnzimmer eingeordnet, der nun – falls es ihn bis hierher noch nicht gab – im linken Bereich des Webinterfaces erscheint.

Das Device ist jetzt korrekt bezeichnet, im richtigen Raum und lässt sich über das Webinterface von FHEM schalten.

Mit diesem Vorgehen lassen sich nahezu alle HomeMatic-Geräte in FHEM einbinden. Bei EnOcean hingegen ist z.B. der Pairing-Befehl leicht anders. Alle Infos hierzu findet man in unserem Blogpost Batterielose Funk-Hausautomation mit EnOcean und FHEM.

Abläufe automatisieren: Let’s do Smart Home

Wie eingangs schon angesprochen, muss ein echtes Smart Home sich selbst steuern können, also die Informationen von Nutzern und/oder Sensoren automatisiert verarbeiten und je nach Bedarf an Aktoren weiterleiten.

Zu diesem Zweck bietet FHEM unterschiedliche Funktionsmodule, also standardisierte Befehle, die um gewisse Attribute (z.B. auslösendes Event/Gerät, durchzuführende Aktion etc.) erweitert werden müssen. Dabei handelt es sich um Befehle wie „at“, „notify“ oder „watchdog“, die seit längerem weitestgehend durch ein zentrales Modul „doif“ (also „tue wenn“) ersetzt werden können. In diesem zentralen Einsteigerguide möchten wir uns auf DOIF beschränken, weil damit vor allem gerade für Einsteiger wirklich so ziemlich Alles umgesetzt werden kann, was es im Smart Home an Automatisierungsszenarien gibt. Um DOIF genauer zu erörtern, möchten wir allerdings vorab kurz noch ein paar andere relevante Begriffe vorstellen.

Dummy – virtuelles Objekt in FHEM

Ein nach wie vor wichtiges Element in FHEM ist der oder das DUMMY. Wofür man ein Dummy benötigt, ist am einfachsten anhand einiger Beispiele erklärt. Möchte man z.B. gewisse Schaltflächen (z.B. vorgefertigte Tasten für eine Lichtszenen-Steuerung) in FHEM im Webinterface zur Verfügung haben, müssen diese ja zu irgendeinem Device gehören. Gibt es allerdings kein „echtes“ Hardware Device, so wird ein Dummy, also eine virtuelle Definition eines Devices in FHEM angelegt. FHEM behandelt den Dummy dann wie ein echtes Hardwaregeräte: Es können z. B.On-/Off-Befehle gesendet, der Status ausgelesen oder aktualisiert werden. Ein weiterer, häufiger Anwendungszweck für Dummies ist die Nutzung als „Zwischenspeicher“ für gewisse Statuswerte. In einem unserer aktuellen Projekte hatte ein Anwender die Anforderung, die Vorlaufzeiten seine Nachtspeicheröfen nach gewissen Vorgaben zu steuern. Diese Vorgaben (z. B. manuelle Vorlaufzeit, die per Schieberegler im Webinterface eingestellt werden kann) wird ebenfalls mit Hilfe eines Dummies umgesetzt.

define mein_dummy dummy

Prinzip fast verstanden? Reicht an dieser Stelle! Später steigen wir hier in einige Beispiele ein, die das ganze Thema noch deutlicher machen.

Status-Werte in FHEM-Objekten

Ein zweites Thema, das wir noch genauer beschreiben möchten, bevor es an DOIF geht, sind die unterschiedlichen Werte bzw. Statusinformationen die ein Hardware-Device oder ein Dummy, also allgemein ein Objekt in FHEM besitzen kann. Da es hier um einen Einsteigerguide geht, sollten im Folgenden die beiden Werte „State“ und „Readings“ erörtert werden. Schauen wir uns dazu noch einmal die Funk-Steckdose an.

Im Screenshot ist der Status der Steckdose „on“, also der zentrale Status der Lampe lautet: „eingeschaltet“. Da wir uns im Folgenden mit der Automatisierung beschäftigen möchten, wobei es ja darum geht, auslösende und auszuführende Aktionen auszulesen und festzulegen, spielt der State eines Objekts eine zentrale Rolle. Dieser könnte ein interessanter Auslöser für einen Ablauf sein (z. B. wenn die Lampe angeht, soll der Rollladen herunterfahren) oder eine auszuführende Aktion (z. B. wenn der Bewegungsmelder eine Bewegung erkennt, soll die Lampe angehen) sein. Das Auslesen bzw. verändern dieses State ist daher zunächst einmal wichtig! Der State ist vor allem bei Aktor-Geräten zentral, weil sich dieser durch einen set-Befehl verändern lässt.

Weiter unten im Screenshot sind zusätzlich die sog. „Readings“ zu sehen, die den zentralen Status eines Objekts ergänzen. Bei der Funk-Steckdose werden hier keine wirklich wichtigen Zusatzinformationen geliefert, im Fall eines Fensterkontaktsensors werden allerdings neben dem zentralen State (offen/geschlossen) weitere, wichtige Informationen wie der Batterie-Status aufgelistet. Auch diese Informationen, die in den Readings versteckt sind, können als auslösende Events in einem DOIF-Programm verwendet werden. Das ist sehr schön, denn beispielsweise kann eine Angabe zum Batterie-Status genutzt werden, um bei geringem Energielevel eine Pushnachricht auf das Smartphone eines Nutzers zu senden.

DOIF – automate it like it’s hot!

Grundsätzlich sind zum Einstieg in DOIF einmal der „DOIF/Einsteigerleitfaden, Grundfunktionen und Erläuterungen“ im FHEM-Wiki und der Commandref-Eintrag zu empfehlen (https://fhem.de/commandref_DE.html#DOIF). Wir geben uns in den folgenden Zeilen alle Mühe, das Modul so verständlich wie möglich aufzubauen!

DOIF ermöglicht einfache aber auch komplexe Wenn/Dann-Szenarien, die entweder auf Basis von Zeitpunkten und/oder Objekt-Status-Informationen, also Ereignissen, erzeugt werden. Der Syntax-Code ist dabei z.B. wie folgt:

define mein_doif DOIF ([mein_Trigger] eq “state“) (mein_Befehl) DOELSEIF ([mein_AlternativerTrigger] eq “state“) (mein_AlternativerBefehl)

Ein DOIF beginnt dabei immer mit einem „define“ und einem frei wählbaren Namen (hier: „mein_doif“). Es folgt immer die Angabe des Moduls „DOIF“. Dann folgt in runden Klammern eine Wenn-Abfrage, die von einem DOELSEIF und/oder einem DOELSE gefolgt werden kann.

DOELSE sammelt dabei alle Alternativ-Status, DOELSEIF gibt noch einmal genauer an, was passieren soll, wenn die ersten Wenn-Bedingung nicht erfüllt ist. Zu kompliziert? Dann stürzen wir uns mal auf ein paar Beispiele.

Beispiel 1 – Der Klassiker: Lampe an auf Lichtschalter

Wer eine Lampe, z.B. angeschlossen an eine Funk-Steckdose, per Knopfdruck auf einen Funk-Taster anschalten möchte, kann dies über ein simples DOIF realisieren.

define mein_lichtszenario DOIF ([mein_lichtschalter:"on"]) (set mein_licht on) DOELSE (set mein_licht off)

Wird der Lichtschalter („mein_lichtschalter“) also betätigt und der Status lautet „on“, wird das Licht („mein_licht“) ebenfalls angeschaltet. Wird der Lichtschalter betätigt und der Status lautet „off“, wird das Gegenevent ausgelöst, nämlich das Ausschalten der Lampe mit „set mein_licht off“.

Beispiel 2 – Die simple Zeitsteuerung

Eine simple Zeitsteuerung, die in vielen Szenarien benötigt wird, kann ebenfalls mit DOIF realisiert werden. Beispielsweise kann zeitbasiert ein Licht zunächst aktiviert und dann wieder deaktiviert werden.

define mein_zeitschalter DOIF ([20:00]) (set mein_licht on) DOELSEIF ([21:00]) (set mein_licht off)

In diesem Beispiel wird um 20:00 Uhr das Licht „mein_licht“ aktiviert und um 21:00 Uhr wieder deaktiviert.

Beispiel 3 – Die erweiterte Zeitsteuerung

Eine etwas erweiterte Variante der Zeitsteuerung ist die Angabe relativer Zeitpunkte, also z. B. jede Stunde oder alle 30 Minuten. So etwas kann Sinn machen, wenn z. B. eine Webcam in regelmäßigen Abständen ein Foto anfertigen oder wenn z. B. ein Licht alle Stunden einmal für 5 Minuten angeschaltet werden soll.

define meine_einfache_anwesenheitssimulation DOIF ([+01:00]) (set mein_licht on-for-timer 300)
attr meine_einfache_anwesenheitssimulation do always

Alle Stunden wird dann ein Licht für 300 Sekunden, also 5 Minuten an- und wieder ausgeschalten. Weitere Zeitangaben können wie folgt genutzt werden:

  • [20:00] = um 20:00 Uhr (wie in Beispiel 2)
  • [+01:00] = immer nach einer Stunde (ab jetzigem Zeitpunkt, wie in Beispiel 3)
  • [:15] = jede Stunde um 15 nach
  • [+:15] = jede Stunde um 15, 30, 45, 00

An Hand dieses Beispiels soll auch gleich das verwendete Attribut „do always“ erklärt werden. Do Always stellt sicher, dass tatsächlich immer die gewünschte Aktion ausgeführt wird. Warum ist es aber notwendig das extra anzugeben? Ganz einfach. Man stelle sich ein DOIF-Programm vor, bei dem ein Temperatursensor alle 10 Sekunden Temperaturwerte liefert, die als Basis für die Aktivierung einer Heizungssteuerung verendet werden.

Wird ein Schwellwert (z. B. 21 Grad) unterschritten, soll die Heizung aktiviert werden, aber eben nur einmal. Liefert ein Sensor z.B. den Wert 20,9 °C, soll die Heizung aktiviert werden. Nach 10 Sekunden würde aber der nächste 20,9°C-Wert vom Sensor kommen und die Steuerung würde erneut aktiviert werden und erneut und erneut usw. Um dies zu vermeiden, arbeitet DOIF mit internen Statuswerten und mit „do always“ wird die beschriebene Standard-Logik bewusst außer Kraft gesetzt.

Beispiel 4 – Tages- und Wochenzeitsteuerung einer Heizung

Eine dritte Variante der Zeitsteuerung ist die Nutzung von Wochen- und Tageszeiten, z. B. klassischerweise im Rahmen eines Wochenprogramms für eine Heizung.

define meine_heizungssteuerung DOIF ([09:00|12345] or [10:00|60]) (set meine_heizung desired-temp 21) DOELSEIF ([21:30|12345] or [22:30|60]) (set meine_heizung desired-temp 17)

Im gezeigten Beispiel wird an Wochentagen (123456, 1 steht für Montag, 2 für Dienstag etc.) zwischen 09:00 und 21:30 Uhr die Heizung „meine_heizung“ aus „desired-temp 21“ also auf eine Wunschtemperatur von 21°C und nachts wieder auf 17°C zurückgestellt. An Wochenenden (60, 6 steht für Samstag und 0 für Sonntag) entsprechend von 10:00 bis 22:30 Uhr. Die Ganze Logik könnte auch über ein Zeitintervall darstellt werden. Die Zeitangabe sähe dann wie folgt aus:

define meine_heizungssteuerung DOIF ([09:00-21:30|12345] and [10:00-22:30|60]) (set meine_heizung desired-temp 21) DOELSE (set meine_heizung desired-temp 17)

Am besten bastelt man mit den Befehlen und Beispielen einfach ein wenig selbst, um die Syntax nachzuvollziehen.

Beispiel 5 – Verschachtelte, komplexe Abfrage: Pushmitteilung bei geöffneter Haustür und Abwesenheit von Montag bis Freitag zwischen 08 und 18 Uhr

Im folgenden Beispiel wird eine Haustür überwacht und falls diese bei Abwesenheit des Bewohners an einem Wochentag zwischen 08:00 und 18:00 Uhr geöffnet wird, soll eine Pushmitteilung durch das Modul Pushover an den Nutzer versendet werden.

define meine_pushmitteilung DOIF ([08:00-18:00|12345] and [meine_haustuer] eq "open" and [meine_anwesenheit] eq "absent") (set pushover msg Haustuer)

Meldet die Haustür also den Status „open“, die Anwesenheitserkennung (z. B. per Bluetooth) meldet „absent“, also die Abwesenheit des Bewohners, und es handelt sich um einen Zeitraum zwischen 8 und 18 Uhr an einem Wochentag (12345), wird mittels „set pushover msg Haustuer“ eine Mitteilung auf das Smartphone des Nutzers gesandt (eingerichtetes Modul „Pushover“ vorausgesetzt).

Beispiel 6 – Die Bewegungsmelder-Lichtsteuerung

Bei einer Bewegungsmelder-basierten Lichtsteuerung gilt es, neben der Bewegung auch zu analysieren, ob auf Grund gemessener Helligkeitswerte es auch Sinn ergibt, ein Licht bei erkannter Bewegung zu aktivieren. Der DOIF-Code dazu sieht wie folgt aus:

define mein_bewegungsmelder doif ([mein_Bewegungsmelder] eq "motion" and [mein_Bewegungsmelder:brightness] < 200) (set mein_Licht on)

Durch den Doppelpunkt hinter mein_Bewegungsmelder kann das Reading „brightness“ also die durch den Bewegungsmelder erfasste Helligkeit im DOIF-Programm abgefragt werden, da das Licht natürlich nur ab einem gewissen Helligkeitswert (also bei Dämmerung und Dunkelheit) aktiviert werden soll.

Optik und Visualisierung

Die gezeigten Einsteiger-Szenarien machen deutlich, dass in FHEM mit einer Vielzahl an Funktionen und Hardware gearbeitet werden kann. Für die Usability bzw. die manuelle Nutzung gibt es zahlreiche Erweiterungen.

Zunächst möchte ich noch kurz auf das Webinterface als solches hinweisen. Grundsätzlich gibt es hier die Möglichkeit, ein Set an Standard-Visualisierungen über “Select Style” im linken Menübereich zu wählen. Hier gibt es verschiedene Standard-Styles zur Auswahl, die z. B. für iOS oder grundsätzlich die mobile Nutzung optimiert sind.

Weiterhin möchte ich auf den Blogpost 5 Tipps um FHEM schöner zu machen! hinweise, in dem erörtert wird, wie das Webinterface von FHEM durch Strukturelemente und weitere Tricks übersichtlich organisiert werden kann.

Eine weitere Funktion, die die Visualisierung angeht, sind Plots, also Grafiken von Statuswerten. Derartige Grafiken zeigen den Verlauf von Werten schnell und überblicksartig in einer zentralen Grafik. Diese Grafiken eigenen sich z. B. ideal für die Visualisierung von Temperaturverläufen, wie im Screenshot unten aus dem Blogartikel FHEM mit JeeLink: Luftfeuchte und Temperatur zum Low-Cost-Tarif messen.

Ich habe das Vorgehen zum Erstellen eines Plots nachfolgend noch einmal anhand eines zweiten Beispiels, der Visualisierung des Schließzustands einer Haustür, gemessen mit einem HomeMatic Funk-Tür/Fensterkontakt, zusammengefasst. Zu jedem Device (gilt fast immer) wird in FHEM automatisch ein Logfile angelegt, das alle Statusänderungen mit Zeit und Datum erfasst. Dieses Logfile ist die Basis für eine Visualisierung. Über einen Klick auf das Logfile und “Create SVG Plot” kann im nachfolgenden Prozess eine Grafik erzeugt werden.

  • Als Titel der Grafik wurde hier im Beispiel “Haustür Schließzustand” verwendet.
  • Die “Y-Axis label” tragen den Wert “Schließzustand”.
  • Range as [min:max]: [-0.1:1.1] (gibt den Maximalen Wert “oben” und “unten” auf der Grafik an).
  • Tics as (“Txt” val, …): (“open” 1, “closed” 0) veranlasst die Umwandlung von “open” in den Wert 1 und “closed” in den Wert 0 in der Visualisierung.
  • In der Zeile “Input:Column,Regexp,DefaultValue,Function” werden der Reihe nach folgende Werte angegeben: Line1, 3, Ga.Haustuer.* (so heisst mein Sensor), 0, $fld[2]=~”open”?1:0 (veranlasst die Umbenennung von Closed in 0 und Open in 1).

Die Grafik wird dann gespeichert und ist ab sofort im Webinterface einsehbar.

Für die Nutzung von FHEM mit Smartphones, gibt es zahlreiche Apps. Eine häufig genutzte Anwendung mit iOS-Support ist die “FHEM APP zur Hausautomation“, die auch das Titelbild dieses Blogposts zeigt.

Hier ist u.A. auch ein Colorpicker integriert, der den Umgang mit RGBW-Lampen maßgeblich erleichtert.

Mit Addon-Lösungen wie z. B. smartVISU lassen sich auch sehr individuelle Tablet- bzw Smartphone-Lösungen entwickeln (siehe Screenshot aus dem Blogpost zu smartVISU: smartVISU mit FHEM – Die perfekte Visualisierung Teil 1: Basics).

Viele Nutzer schwören mittlerweile auf das Projekt TabletUI, mit dessen Hilfe noch schneller und effizienter Tablet-Visualisierungen erzeugt werden können (mehr Infos z. B. hier im FHEMWiki https://wiki.fhem.de/wiki/FHEM_Tablet_UI).

Aus meinem täglichen Leben

Mein Nachrüst-Smart-Home wächst von Woche zu Woche, was Funktionalität und Umfang der verbauten Hardware angeht. Dabei spielt FHEM nach wie vor eine zentrale Rolle, auch wenn ich mittlerweile Einiges mit dem kommerziellen System Loxone realisiere (siehe Blogpost 5 Gründe zur Erweiterung deines FHEM-Servers mit Loxone + Howto).

Gerade für Einsteiger, die eine preiswerte, skalierbare und unabhängige Lösung suchen, würde ich weiterhin FHEM uneingeschränkt empfehlen. Auch in meinem etwas professionellerem Setup mit Loxone ist FHEM allerdings weiterhin der zentrale Hardware-Sammler, da ich bisher kein anderes System finden konnte, das annähernd eine derart breite Hardware-Integration ermöglicht.

Als Einsteiger würde ich mit einem Raspberry Pi (Affiliate-Link), einem HomeMatic Funk-LAN-Gateway (Affiliate-Link) und ein paar Aktoren und Sensoren starten. Hier bieten sich z. B. die HomeMatic Funk-Steckdosen (Affiliate-Link), ein HomeMatic Funk-Stellantrieb (Affiliate-Link) für Heizkörper und ein HomeMatic Funk-Drehgriffkontakt (Affiliate-Link) bzw. HomeMatic Funk-Tür/Fensterkontakt (Affiliate-Link) an, um die ersten Basis-Szenarien zu realisieren.

Ich hoffe, dieser Einsteigerguide hilft euch bei der Entscheidung für FHEM und den ersten Schritten auf dem Weg zum eigenen Smart Home!

20 Kommentare
  1. Sehr schöner Guide. Ein kleiner Fehler ist mir aufgefallen.
    “define meine_pushmitteilung DOIF ([08:00-18:00|12345] and [meine_haustuer] eq “open” [meine_anwesenheit] eq “absent”) (set pushover msg Haustuer)”
    Hier fehlt das “and” zwischen der zweiten und der dritten Bedingung.

  2. Wie immer ein toller Beitrag! Gerade für Einsteiger sicher sehr hilfreich. Finde es super, dass Du so viele Beispiele zu DOIF gezeigt hast – so bekommt man ein richtig gutes Gefühl, was alles so möglich ist!

    Ich bin mit FHEM auch sehr zufrieden, auch, wenn wirklich mal ein Designer an das Thema ran müsste 🙂 Ich habe mir sogar für die Oberfläche meinen eigenen Style gebaut, da ich den default-Style nicht mehr sehen konnte… Gerade vom Look werden sicher viele Nutzer abgeschreckt, da es nicht so neu und stylisch aussieht, wie die ganzen Anbieter aus dem Fernsehen 🙁

  3. Hi.
    Obwohl auch ich noch immer Anfänger, möchte ich doch auf eine “Kleinigkeit” hinweisen.
    Ziemlich weit oben wird von peeren, bzw. peering geschrieben. We ich ich das richtig verstehe, dann wird dort aber das pairing!!! beschrieben, oder?

    Ansonsten ein super Beitrag zum ” anfixen”. Super beschrieben und zusammen mit den verlinkten Beiträgen , der Commandref und dem “Leitfaden für Anfänger” aus dem “fhem.forum.de” ein Top Einstieg.
    5 Sterne.
    Holger

  4. Danke für den Beitrag. Wie immer sehr hilfreich. Wie habt ihr in der App bei Wz.Wandthermostat die Batterieanzeige als auch das Fenster rein bekommen? Ist das ein Homematic Device?

    1. Ah, du sprichst von dem Wandthermostat. Sorry, da muss ich meine Aussage korrigieren. Das ist ein älteres Modell von FS20 und nennt sich FHT80b-Set mit Fensterkontakt. Wird über den CUL empfangen.

      Viele Grüße

  5. Danke für den tollen Beitrag. Eine Frage: was für eine Marke/Model sind die oben abgebildeten Schalter mit der schwarzen Glaseinfassung?

    1. Hallo Matthias,

      das sind EnOcean-Funktaster mit OPUS Green (Jäger Direkt) Abdeckung: “OPUS 55 Fusion Glas”.

      Viele Grüße
      Christoph

  6. Tja, nun fehlt doch nur noch ein Artikel, wie man schnell und einfach Amazon Echo integriert…. “Alexa, schalte das Wohnzimmerlicht an !”
    Gruß Axel

    1. Zu Alexa wird es in Kürze einen Artikel von mir geben. Bin echt begeistert, wie gut das Ganze funktioniert.
      Aber erstmal “nur” im Zusammenspiel mit habridge und Loxone. Wobei man die Lösung auch easy mit FHEM nutzen kann, da quasi nur http-Befehle von der habridge (hue-Emulation) übertragen werden – und da ist es ja im Grunde egal, welches System man damit ansteuert…

      Grüße
      Jörg

    2. Interessant ist natürlich auch das neuerdings neu implementierte SIRO Protokoll, welches z.B. die Ansteuerung von motorisierten Innensonnenschutz (SIRO ist hier der Hersteller kleinerer Rohrmotoren für Innenrollos) per Sprachsteuerung ermöglicht. Das Alexa Protokoll ist dort schon integriert.

      ,,Alexa, fahre meine Rollos hoch´´ ist mein Lieblingssatz in letzter Zeit.

      Beste Grüße

  7. Hallo, möchte nochmal auf den Hinweis eingehen, dass mit DOIF neben at und notify auch der watchdog ersetzt werden kann. Beim watchdog habe ich die Möglichkeit, Abfrageintervalle zu definieren. Wie oft ist das bei DOIF der Fall ? Wie oft wird die Abfrage wiederholt ? Bei meinen Tests mit dem watchdog stellte ich fest, dass meine verwendete Hardware anscheinend an Grenzen stößt, da plötzlich zeitgesteuerte Schaltvorgänge nicht mehr sauber durchgeführt wurden, deswegen habe ich die Anzahl der watchdogs wieder reduziert bzw. die Abfrageintervalle erhöht. Natürlich ist mir klar, dass eine Antwort hier nicht pauschal getroffen werden kann. Man könnte ja auch die Hardware wechseln und den Pi B+ gegen einen PI3 tauschen…nur überzeugt der kleine Kerl durch seine erfreulich hohe Stabilität mit tatsächlich 0 Abstürzen in den letzten 3 Jahren.
    Auf jeden Fall wäre eine Vereinheitlichung bei der Programmierung auf DOIF sinnvoll. Evtl. habt Ihr ja noch weitere Erfahrungen oder man kann sich in diesem Blog mit anderen hierzu noch weiter austauschen.
    Gruß Axel

  8. Hallo zusammen, ich habe folgendes Problem. ich habe mir ein einfaches DoIf für meine Receiver angelegt. Wenn der Receiver angeht Telegram Nachricht “An” wenn er ausgeht Telegram Nachricht “AUS”.
    Jetzt ist es bei mir so das die Nachrichten richtig ankommen aber immer 3-4 mal. muss da in der Regel noch etwas rein?

    define receiver_sz_telegram DOIF ([SZ.TV:”on”]) (msgtelegram @1234567Receiver ist an.) DOELSE (msgtelegram @1234567Receiver ist aus.)

    Danke Gruß Klaus

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Das könnte dir auch gefallen