In dieser Artikelserie soll der Raspberry Pi zur Schaltzentrale für Steckdosen aufgerüstet werden, so dass sich Steckdosen fernsteuern lassen. Nachdem wir im ersten Teil die Hardware angeschlossen und pilight installiert haben, wird in diesem Teil die Konfiguration von pilight beschrieben.

Konfiguration von pilight

Die Konfiguration wird ab pilight 6.0 die gesamte Konfiguration in der Datei /etc/pilight/config.json vorgenommen. Diese Datei ist im JSON-Format und hat folgende Abschnitte:

devices In diesem Abschnitt werden die Geräte definiert die mit pilight ausgelesen bzw. angesprochen werden sollen (siehe auch http://www.pilight.org/configuring/devices/).
rules Seit Version 6.0 können in pilight auch Events definiert werden, so dass Geräte in Abhängigkeit von Zuständen geschaltet werden können (siehe auch http://www.pilight.org/getting-started/eventing/).
gui Über die Einstellungen für die GUI wird festgelegt welche Devices in der GUI (also z.B. am Web-Frontend) angezeigt werden sollen (siehe auch http://www.pilight.org/configuring/gui/).
settings Über die “settings” werden die grundlegenden Einstellungen von pilight festgelegt (siehe auch http://wiki.pilight.org/doku.php/settings).
hardware Hier wird festgelegt, welche Hardware pilight verwenden soll, wie sie angesprochen wird, und wo sie zu finden ist (siehe http://www.pilight.org/configuring/hardware/).
registry Die Registry ist für dynamische Werte während der Programmlaufzeit vorgesehen und sollte daher nicht geändert werden (siehe http://www.pilight.org/configuring/registry/).

Die Standardkonfiguration von pilight sieht dabei in der Regel folgendermaßen aus:

Achtung: Bevor Änderungen an der Konfiguration von pilight vorgenommen werden können, ist der pilight-Daemon unbedingt zu stoppen (sudo service pilight stop). Andernfalls werden die Einstellungen von der config.json nicht korrekt gespeichert bzw. vom pilight-Daemon wieder überschrieben.

Ist der pilight Daemon beendet kann die Konfiguration angepasst werden:

Abschnitt Hardware

Im Hardware-Abschnitt der Konfiguration muss eigentlich nicht angepasst werden, wenn der Sender und der Empfänger so wie oben beschrieben angeschlossen wurden. Sollten sich die PINs ändern so sind die Werte für “sender” und “receiver” entsprechend anzupassen. Dabei muss die PIN-Nummer als WiringPi-Nummer des entsprechenden Ports angegeben werden.

Anmerkung: Wird kein Hardware-Filter genutzt, so sollte laut pilight-Wiki, in der Hardware-Config der “433lirc”-Modus aktiviert werden. Da ich diesen Modus nicht nutze, kann ich hierzu leider keine Tipps beisteuern. Hinweise wie dieser Modus zu nutzen ist finden sich ebenfalls im pilight-Wiki.

Abschnitt Settings

Auch in diesem Abschnitt muss in der Regel wenig geändert werden. Ich habe beispielsweise die Firmware-Updates für die Filter-Firmware aktiviert und dazu den Eintrag

ergänzt. Eine ausführliche Übersicht aller Settings-Parameter ist im Wiki abrufbar.

Abschnitt Devices

Bei der Einrichtung der auszulesenden und zu steuernden Devices ist die jeweilige Protokoll-Seite des Gerätes in der Regel die erste Anlaufstelle. Hier wird beschrieben, welche Optionen bei der Konfiguration verwendet werden können. In den folgenden Kapiteln gehe ich das für einige Devices exemplarisch durch:

Temperatursensor DHT22

Vergleichsweise einfach ist der Temperatursensor DHT22 einzurichten. Wie die DHT22-Protokoll-Seite beschrieben, muss hier lediglich das Protokoll, die ID, der initiale Luftfeuchtigkeitswert, die initiale Temperatur und das Abfrageintervall in Sekunden eingetragen werden. Wurde der DHT22-Sensor wie im 1. Teil beschrieben angeschlossen, kann das Beispiel von der Protokoll-Seite direkt übernommen werden. Ich habe in meiner Konfiguration lediglich das Poll-Intervall angepasst, sodass die Temperatur nur alle 30 Sekunden abgefragt wird.

Sollte der Temperatur-Sensor nicht ganz genau arbeiten, kann in der Konfiguration zusätzlich auch ein Offset-Wert für die Temperatur und die Luftfeuchtigkeit zum Finetuning des Sensors angegeben werden.

Elro AB440 Switches

Zur Einrichtung der Elro-Steckdosenschalter sollte zunächst die im Set mitgelieferte Fernbedienung wie in der Elro-Anleitung beschrieben in Betrieb genommen werden. Können die Steckdosen mit der mitgelieferten Fernbedienung geschaltet werden, kann das Signal der Fernbedienung mit dem Kommando pilight-receive mitgelesen werden. Dazu muss lediglich  eine der Taste an der Fernbedienung gedrückt werden, die eine eine der Steckdosen schaltet, nachdem pilight-Receive gestartet wurde.

pilight-receive erzeugt dann eine Ausgabe die so oder so ähnlich aussehen sollte:

Bei einem Blick auf die Ausgabe fällt auf, dass die Fernbedienung Codes für unterschiedliche Geräte aussendet. Da es sich bei den zu schaltenden Steckdosen um eine Elro AB440 handelt (siehe Protocol elro_400), dient der zweite Eintrag (“protocol”: “elro_400”) als Grundlage für die Device-Definition. Hier können die Werte für den System- und Unitcode in die Konfiguration übernommen werden. Der erweiterete Device-Eintrag sieht damit also folgendermaßen aus:

Falls noch weitere Elro-Steckdosen eingebunden werden sollen, ist der Schritt für jede weitere Steckdose zu wiederholen und der System-/Unitcode entsprechend anzupassen.

KlikAanKlikUit Dimmer

Da laut Homepage bisher nur Dimmer von KlikAanKlikUit bzw. Coco Technology unterstützt werden, habe ich davon zwei Dimmer besorgt. Zur Einbindung wird dabei grundsätzlich wie oben beschrieben vorgegangen und zunächst der Dimmer normal in Betrieb genommen, bis er sich mit der Fernbedienung schalten lässt.

Danach wird mit pilight-receive wieder die notwendigen Werte ausgelesen (diesmal die vom Protocol kaku_dimmer)verlangten Werte für “id” und “unit”) Unitcode:

Auch in diesem Beispiel werden wieder mehrere Codes von der Fernbedienung gesendet. Diesmal ist der Eintrag mit dem Protocol “arctech_switch” der Richtige. Da die Fernbedienung den Dimmer wie ein Switch anspricht, wird hier nicht das richtige Protokoll kaku_dimmer  erkannt. Daher muss der Devices-Abschnitt folgendermaßen ergänzt werden:

Auch hier gilt wieder: Sollen weitere Dimmer/Geräte hinzugefügt werden, so muss das Prozedere mit jedem Gerät wiederholt werden.

Anmerkung: Dieses Beispiel zeigt, dass der Name des Protokolls von den per pilight-receive ermittelt Werten abweichen kann. Hier hilft nur die Recherche auf der pilight-Protocol-Seite.

Abschnitt GUI

Jetzt  muss nur noch im GUI-Abschnitt festgelegt werden, welche Devices auf der  Web-Seite angezeigt werden sollen. Dabei dient der Device-Bezeichner aus dem Device-Abschnitt als Referenz. Über den Parameter Group können Devices auf unterschiedlichen Tabs im Browser zusammengefasst werden. Eine Ausführliche Beschreibung der Konfigurationsoptionen sind auf der entsprechenden pilight-Web-Seite.

Abschnitte Rules und Registry

Für den einfachen Schaltvorgang der Devices per Handy müssen hier keine Änderung vorgenommen werden.

Insgesamt ergibt sich damit also folgende Konfiguration für dieses Beispiel:

Debugging der Konfiguration

Wenn die Konfiguration abgeschlossen ist, kann der pilight-Daemon neu gestartet werden:

service pilight start

Wenn kein Fehler in die Konfiguration eingebaut wurde, wird der Start des Daemons mit einem grünen [OK] bestätigt. Wahrscheinlicher ist jedoch, dass im ersten Anlauf etwas mit Konfigurationsdatei noch nicht stimmt. Sollte also anstatt des [OK] ein [FAIL] auftauchen, heisst es: Fehlersuche.

Erster Anlaufpunkt ist dabei die Datei /var/log/pilight.err, in der alle Fehlermeldungen des Daemon gespeichert werden. Eine der häufigsten Fehlerquellen dürfte wohl die JSON-Syntax der Config-Datei darstellen. Erscheint im Log die Fehlermeldung:

sollte vor allem nach fehlenden oder überflüssigen Kommata ausschau gehalten werden. Der letzte Eintrag vor einer schließenden Klammer } darf z.B. kein Komma enthalten – eine bei mir beliebte Fehlerquelle.

Ein weiterer häufiger Punkt sind die Device-Bezeichner. Diese dürfen nur aus Buchstaben und Nummern bestehen. Sonderzeichen sollten vermieden werden. Der folgende Eintrag im Error-Log deutet auf einen solchen Fehler hin:

In den unterschiedlichen Versionen von pilight ändert sich ggf. auch mal die Protokoll-Bezeichnung:

Ich benötige in der Regel mehrere Anläufe bis die Konfiguration frei von Fehlern ist und der Daemon korrekt startet.

Danach sollte die Webseite unter http://<ip-des-raspberry>:5001 erreichbar sein und die im Abschintt GUI-konfigurierten Geräte sollten anzeigt und hoffentlich auch gesteuert werden können. Funktioniert alles, stellt folgendes Kommando sicher, dass der Daemon beim nächsten Systemstart automatisch gestartet wird:

sudo update-rc.d pilight defaults

Jetzt sollte direkt auch ein Reboot durchprobiert werden. Normalerweise sollte nach dem Reboot der pilight-Daemon und die Web-Oberfläche direkt wieder verfügbar sein.

Beheben von Boot-Problemen

pilight Web-GUIScheinbar gibt es in der Version 6.0 leider manchmal Probleme beim Systemstart. Bei einigen Installationen ist der Web-Server direkt nach dem Start nicht mehr erreichbar. Das lässt sich ziemlich einfach nachprüfen: wenn direkt nach dem Systemstart der Prozess startpar -f -- pilight läuft, dann wurde der Web-Server nicht korrekt gestartet (zu prüfen mit ps aux | grep pilight ). Wird in diesem Fall versucht die Web-Seite aufzurufen, dann wird die Web-Seite nicht korrekt angezeigt und der pilight-Daemon wird beendet. Wird der Daemon per “service pilight restart” neu gestartet funktioniert alles wie gewünscht.

Damit der Daemon auch direkt nach dem Systemstart funktioniert, habe ich als Workaround folgenden Zeilen in der Datei /etc/rc.local eingefügt:

Dadurch wird der Daemon 10 Sekunden nach dem Systemstart automatisch neu gestartet. Somit sollte pilight auch direkt nach dem Systemstart wieder erreichbar sein.

Zu guter Letzt

Bei den Funksteckdosen und Dimmern, die ich verwende, gibt es leider keine Rückmeldung, ob der Schaltvorgang erfolgreich ausgeführt wurde oder nicht. Das kann dazu führen, dass ggf. zweimal ein- oder ausgeschaltet werden muss. In der Regel funktionieren die Schaltvorgänge aber zuverlässig.

Wenn jemand von euch gute Erfahrungen mit anderen Hausautomatisiserungs-Lösungen hat, würde ich mich über einen Kommentar sehr freuen. Interessant sind auch Erfahrungen mit anderen Komponenten und deren Einbindung in pilight oder die Integration von pilight in andere Automatisiserungs-Lösungen wie FHEM.