FHEM beschleunigen: So wird das Smart-Home schneller!

Tipp: Schicke Oberflächen für FHEM erstellen!

Der größte Vorteil des kostenlosen Smart-Home Programms FHEM kann auch ein großer Nachteil werden: Mit zahllosen Modulen lassen sich eine unüberschaubar große Anzahl an Geräten steuern, auslesen und überwachen um aus einem einfachen Haus mit etwas Bastelarbeit ein Smart-Home zu machen. Das überwacht die Temperatur im Kühlschrank und auf der Terrasse, fährt die Rolläden automatisch herunter, wenn die Sonne zu stark scheint oder macht das Licht an, wenn man ins Badezimmer geht.

Je mehr Module man aber in FHEM aktiviert, desto früher merkt man, wie langsam das System plötzlich werden kann. Hier hilft entweder schnellere Hardware oder ein bisschen Aufräumen, um FHEM auch auf einem Raspberry Pi wieder flott zu bekommen.

FHEM langsam: Logfile und Event Monitor prüfen

Auf der Weboberfläche gibt es unten im Menü die beiden Punkte “Logfile” und “Event-Monitor”. Das Logfile protokolliert alle Ereignisse, aber auch Probleme und Fehler. So findet man zum Beispiel veraltete Konfigurationen, die mit neueren Versionen für Probleme sorgen können – oder Geräte, die immer wieder einmal nicht erreichbar sind und dadurch FHEM langsam machen:

2016.11.15 08:53:12 2: HarmonySZ: disconnect
2016.11.15 08:53:14 3: HarmonySZ: connected
2016.11.15 08:53:19 3: HarmonySZ: new config 
2016.11.15 08:55:57 2: HarmonySZ: disconnect
2016.11.15 08:55:59 3: HarmonySZ: connected

Gerade das Harmony Modul trennt und öffnet die Verbindung sehr häufig – das kann aber auch auf Probleme mit zu schwachem WLAN hinweisen: Hier kann ein WLAN Verstärker in der Nähe des Harmony Hubs eventuell helfen.

Außerdem lassen sich so Fehler in der Konfiguration finden wie zum Beispiel dieser:

2016.11.15 03:38:18 3: kuehlmsg: Unknown command {, try help.

oder diese Warnung:

2016.11.14 23:54:28 1: WARNING: sleep without additional commands is deprecated and blocks FHEM

Hinter einem sleep-Befehl muss ein weiteres FHEM-Kommando kommen, sonst kann das ganze System aufgehalten werden, bis die in dem sleep-Befehl genannte Zeit-Spanne abgelaufen ist. Der Befehl muss also zum Beispiel so aussehen:

set Lampe_WZ on; sleep 5; set Lampe_WZ off;

 
Event Monitor

Im Eventmonitor werden alle ankommen Ereignisse aufgelistet: Das können die Funkdaten einer Wetterstation sein oder wenn ein Bewegungsmelder eine Person erkennt. Wenn die Daten hier sehr schnell durchlaufen, hat FHEM auch sehr viel zu tun – außerdem müssen die ganzen Daten in die einzelnen Log-Dateien geschrieben werden, und häufige Schreibzugriffe verkürzen schnell die Lebensdauer der SD Karte.

Hier macht es Sinn aufzuräumen und nur die Daten zu protokollieren, die man wirklich benötigt. Die meisten Devices schreiben einen erkannten Wert oder einen abgesetzten Befehl nicht nur in die normale Log-Datei, sondern legen ebenfalls eigene File-Logs an oder erstellen grafische Plots – wen das nicht interessiert, sollte diese wieder aus der FHEM Konfiguration löschen:

define SVG_Type1_21 SVG FileLog_Type1_21:SVG_Type1_21:CURRENT
attr SVG_Type1_21 label "Type1_21 Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_Type1_21 room Plots

Automatisch angelegtes Filelog – wer es nicht braucht, kann es einfach entfernen.

 
Nur neue Werte aufzeichnen: event-on-change-reading

Aber auch bei interessanten Werten ist es hilfreich, weniger Daten zu sammeln: In vielen Fällen wird, zum Beispiel bei einem Temperatur-Sensor, jeder empfangene Wert protokolliert. Wenn man aber nur an der aktuellen Temperatur interessiert ist und nicht einen Verlauf aufzeichnen möchte, kann man auch nur die Änderungen speichern: Jedes Mal, wenn der Sensor den gleichen Wert sendet, wird dieser ignoriert – bis sich der Wert ändert.

define SD_WS07_T_1 SD_WS07 SD_WS07_T_1
attr SD_WS07_T_1 alias Aussenthermometer
attr SD_WS07_T_1 event-on-change-reading .*

Wichtig ist hier der letzte Wert: Das Attribut “event-on-change-reading”. Dies sorgt jetzt dafür, dass nur noch neue Werte protokolliert werden, die sich auch geändert haben.

Fehler bei FHEM2FHEM: Gleiche Namen sorgen für viel Arbeit

Verbindet man zwei FHEM-Server mit dem Modul FHEM2FHEM miteinander, kann man auf die Daten des anderen Gerätes zugreifen. Dazu muss auf dem einen Gerät ein Device angelegt werden, dessen Daten man auslesen möchte, auf dem anderen Gerät wird ein “dummy” definiert, der automatisch immer die gleichen Werte enthält wie das eigentliche Device auf dem anderen FHEM-Server. So kann man mit einem zweiten Rechner vor Ort Sensoren auslesen (zum Beispiel Temperatur oder Bewegung) und die Daten an die Haupt-FHEM-Installation weitergeben.

Haben beide FHEM-Server aber gleiche Devices, die regelmäßig mit Daten gefüllt werden und die den gleichen Namen haben (zum Beispiel per autocreate angelegte Temperatursensoren), werden unermüdlich beide Daten protokolliert – hier hilft es, ab und zu im Event Monitor nach sehr vielen, schnell nacheinander auftauchenden und gleichnamigen Einträgen zu schauen und unter “Everything” oder in der fhem.cfg Datei (so behebt man den Schreibschutz) zu prüfen, ob neue Devices angelegt wurden, die hier Probleme machen könnten.