Obacht, kleines Update, der Remote Start Service darf natürlich erst gestartet werden wenn das System eine IP-Adresse hat. Auf Nummer Sicher geht man wenn man es z.B. nach Docker startet:
After=docker.service Description=Remote Start Schweizer Taschenmesser Service [Service] ExecStart=/home/christian/docker/smarthome/remote_start/remote_start.py [Install] WantedBy=default.target
Ein erster Schritt Richtung Chefinheimautomatisierungsintegration war es sie mit Meldungen zu versorgen wenn der Trockner bzw. die Waschmaschine fertig ist. Das kommt gut an. Jetzt kommt Schritt zwei, sie darf nämlich bald aktiv steuernd eingreifen und zwar gleich 6-fach. Wenn man da mal etwas recherchiert, dann finden sich recht schnell WLAN-Schalter, die man irgendwie integrieren kann, aber man muss aufpassen, i.d.R. ersetzten die nämlich nur Einzeltaster in Unterputzdosen, die fast nie zum eigenen Schalterprogramm passen.
Nach etwas hin und her wurde es jetzt ein 6-Fachschalter von Homematic, der schaut zwar auch scheiße aus und passt nicht zu Busch-Jäger Schaltern, aber er ist flach und braucht keine Unterputzdose, sondern kann einfach auf die Wand geklebt werden. Eigentlich ist der sau teuer, wie alles von Homematic, aber ELV verkauft sie auch als Bausatz, da kostet so ein Schalter dann statt 70 € nur 45 €. Der Zusammenbau beschränkt sich auf 8 Lötpunkte und etwas Plastikbausatzgedöns und dauert keine 10 Minuten. Das Ergebnis ist zwar hässlich, funktioniert aber und kann ja notfalls in den Küchenschrank gepappt werden. Läuft.
Die Lösung etherwake über SSH auf dem Host zu starten hat mir überhaupt nicht gefallen, vor allem weil man sie bei jeder Änderung am FHEM Image manuell nachziehen musste. Jetzt gibt es eine wirklich smarte Lösung, nämlich einen RemoteStart Dienst via HTML Schnittstelle, eingehangen in Systemd. Hört sich kompliziert an, ist aber relativ einfach.
Bottle, den Mini-Webserver in Python, hatte ich vor einem Jahr schon mal für die Aquariumsteuerung verwendet. Jetzt lauscht er auf Port 8080 vom Host und wartet dass ihm jemand aufruft (Zeile 14). Standardmäßig gibt er ein Smily zurück (Zeile 10-12). Ruft man aber den Pfad /startServer (Zeile 6) macht er einen Systemaufruf und versendet das Magic Paket (Zeile 8). Fertig ist der Lack:
#!/usr/bin/python
import os
from bottle import route, run, template
@route('/startServer')
def startServer():
return os.system("/usr/bin/wakeonlan 30:9c:23:46:36:xx")
@route('/')
def hello():
return ':-)'
run(host='192.168.178.3', port=8080)
Damit der Server auch bei jedem Neustart automatisch gestartet wird, muss man einen Systemd-Service einrichten. Dazu legt man eine kurze Service-Konfiguration an sudo vim /etc/systemd/system/remoteStart.service, das war es dann auch schon:
After=network.target
[Service]
ExecStart=/home/christian/docker/smarthome/remote_start/remote_start.py
[Install]
WantedBy=default.target
Sau coole Geschichte! Jetzt überlege ich schon was man damit noch anstellen könnte, das ist ja so eine Art Schweizer-Taschenmesser-Panzertape-MacGyver-Nummer in Code gegossen.
Es hat ein ganzes Stück gedauert um ein Haar in der Docker-Suppe zu finden, jetzt ist es so weit: Irgendwie kann man aus einem Docker-Container heraus kein WakeOnLan Magic Packet versenden. Und das trifft eines der coolsten FHEM/Telegram Features, nämlich dass man den Backup-/Seafile-Server von unterwegs in sage und schreibe 4 Sekunden aus den Standby zum Laufen bekommt.
Durch einen Umweg, von hinten mit dem Messer durch die Brust, geht es allerdings doch: Wenn mit Telegram der Befehl zum Starten rein kommt, dann startet FHEM im Container nicht mehr etherwake direkt, sondern loggt sich auf dem Host per ssh ein und startet es dort. Die Lösung ist nicht wirklich sauber und verstößt wahrscheinlich gegen die reine Docker-Lehre, funktioniert aber prima!
Seit Donnerstag ist der neue Rechner online und der Raspberry aus. Der Wechsel hat, abgesehen von ein paar Kleinigkeiten, eigentlich reibungslos geklappt. Das System ist pfeilschnell, Ziel erreicht! Und noch viel mehr: alles läuft in Docker-Containern, auf btrfs, mit Snapshots bei Updates und seit heute mit Git verwaltet auf einem eigenen Gitea-Server eingecheckt.
Die letzte Woche war nicht nur sehr lehrreich sondern auch kräftezehrend, mehr als 5 Stunden Schlaf waren es nie, dafür viel zu viel Kaffee. Aber das Ergebnis kann sich sehen lassen. DevOps@Home, so viel IT gab es hier schon lang nicht mehr. Ich bin stolz.
Bei Docker ist auch nicht alles Gold was glänzt, soviel vorab. Also das mit Docker ist so wie mit jedem anderen komplexen System, man muss sich schon etwas damit beschäftigen und es ist am Anfang noch recht unübersichtlich. Deshalb war der Plan eine grafische Oberfläche dafür zu installieren, z.B. Portainer. Wenn man da etwas sucht, findet man auch schöne Anleitungen. Aber irgendwie wollte sich das aktuelle Portainer-Image nicht mit Docker verbinden, zum Kotzen. Gestern wurde dann genau nach dieser Anleitung vorgegangen und wieder nichts! Auf Git habe ich dann den entscheidenden Tipp gefunden und kurzerhand mal eine alte Version installiert:
sudo docker run -d --name="portainer" --restart on-failure -p 9000:9000 -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer:1.16.2
Genau hier sieht man dann die Vorzüge und Nachteile von Docker – man kann ohne weiteres unterschiedliche Versionen parallel installieren, ist aber bei der Verwendung von fremden Images darauf angewiesen dass die auch fehlerfrei funktionieren. Langer Rede kurzer Sinn: Läuft endlich! Danach dann gleich noch MQTT hinterher, funktioniert auch. Und MySQL auch. Heute steht dann FHEM auf der Agenda, das wird kein Selbstläufer, aber ich bin guter Dinge!
Mühsam ernährt sich das Eichhörnchen. Heute wurde Ubuntu 18.04 LTS mit btrfs installiert, eigentlich sollten die Snapshots wie beim Server Anfang des Jahres umgesetzt werden, ganz zufällig bin ich aber auf apt-btrfs-snapshot gestoßen, ein Glückstreffer. apt-btrfs-snapshot ist ein „Hook for providing apt based btrfs snapshots“, macht also einen Snapshot bevor mit apt was installiert wird. Einen Rollback gibt es mit apt-btrfs-snapshot set-default Backupname. Funktioniert, sau cool!
Hier ist dann noch ganz schön beschrieben wie man VNC auf Ubuntu einrichtet und sich den Desktop dann am Mac anschaut. Das gsettings set org.gnome.Vino require-encryption false ist wichtig. Kann man bestimmt auch mal gebrauchen.
Portainer wollte heute wieder nicht laufen, verbindet sich zwar, kann aber nichts auslesen. Das ist ärgerlich, aber wenigstens konnte zurückgerollt werden und et voila schaut das System wieder so aus als ob es noch niemals Docker gesehen hat.
Die Sache mit dem Raspberry und der kaputten SD-Karte hat mir keine Ruhe gelassen! Bei Amazon gibt es günstige Mini-PCs als Raspberry-Alternative, bei ARLT sind sie etwas teuerer aber dafür gleich zum Mitnehmen und mit besserer Hardware. Läuft.
Das Ziel für dieses Wochenende war klar: Ubuntu LTS samt Btrfs drauf, dann Docker und danach eine Docker-basierte FHEM-Installation. Samstag Abend ist Ubuntu LTS mit Snapper gelaufen, Sonntag Mittag FHEM auf Docker, Sonntag Abend ist der Plan für Montag eine Neuinstallation. Fakt ist dass die Snapper-Snapshots unter Ubuntu bestenfalls nicht endanwendertauglich sind. Und diese Docker Installation schaut zwar gut aus, schlägt aber in die gleiche Kerbe. Neue Woche neues Glück.
Ach ist das ein Drama. Jetzt wo alle Steckdosen geflasht sind, der Bewegungsmelder Bewegungen meldet und die Früchte dieser Arbeiten mit FHEM fassbar gemacht werden sollen, raucht der FHEM-Raspberry ab. Der Filesystem-Check checkt und checkt und checkt und checkt. Ein Raspberry ist halt kein Server nicht. Heimautomatisierung, Raspberry und Backup das waren bis jetzt zwei getrennte Themen, das war Basteln am Feierabend. Strategisch betrachtet leichtsinnig.
Die Challange gestern Abend war einen Bewegungssensor (PIR) an einen ESP8266 NodeMCU anzuschließen. Die Bewegungsmelder gab es vor einiger Zeit mal im Internet für unter 1 € das Stück und seitdem warten sie darauf sinnvoll eingesetzt zu werden. Wenn man bei Google mal „ESP8266 PIR“ eingibt, dann merkt man schnell dass das Thema keine wirklich große Herausforderung darstellt, aber eben nur auf den ersten Blick, die Tücken stecken nämlich im Detail!
Die PIRs arbeiten mit 5 V und der ESP8266 mit 3,3 V. Schließt man den PIR an einem Arduino an, dann wird der immer funktionieren, schließt man ihn an einem ESP8266 NodeMCU an, dann nur wenn man ihn am VIN Pin anschließt, da liegen nämlich die 5 V vom USB Anschluss an. Von hinten mit dem Messer durch die Brust geht es aber auch, der PIR hat intern einen Spannungswandler, der die Eingangsspannung von 5 V auf die intern verwendeten 3,3 V runter regelt. Überbrückt man das Ganze, dann gehen die PIRs auch direkt mit den 3,3 V des ESP8266!.
Warum ist das wichtig? Wenn man die Schaltung klein halten will, z.B. weil sie in eine Unterputzdose soll, dann wird man nicht den großen ESP8266 NodeMCU mit USB nehmen, sondern eher den mit blanken ESP8266 und da muss man dann ohne 5 V auskommen.