Wenn man seine FHEM Installation eine Zeit lang am Laufen hat, dann wird diese immer größer. Daher bietet es sich an die FHEM Größe im Blick zu behalten. [Weiterlesen]
0 Kommentare
FHEM: Umzug von SQLite nach MySQL / MariaDB
Der Einfachheit halber beginnt man bei FHEM mit dem Logging von Daten entweder in Logfiles oder in einer SQLite. So erging es mir mit Letzterem. Die immer größer werdende Anzahl von Einträgen, sowie neue Möglichkeiten rund um Grafana bewegten mich zu einem Wechsel der Datenbank. Wie ich von SQLite nach MariaDB gewechselt bin möchte ich Euch kurz beschreiben und die nötigen Informationen auf einer Seite bereitstellen.[Weiterlesen]
In FHEM eingeloggt bleiben – basicAuthExpiry
In FHEM wird man von Anfang an daran erinnert eine Grundabsicherung über Username + Passwort herzustellen. Das ist gut so und sollte in jedem Fall gemacht werden. Wenn man sich allerdings bei jedem Starten von FHEM über den Browser oder der Tablet UI mit dem BasicAuth Fenster rum schlagen muss, wird es mühsam. Nach etwas suchen bin ich auf das Attribut „basicAuthExpiry“ des allowed-Devices aufmerksam geworden. [Weiterlesen]
Import von Code Snippets in FHEM (Copy & Paste)
Bei mehreren gleichartig anzulegenden Geräten in FHEM können einem schon mal die Finger weh tun. Da muss man x mal klicken oder sich über Konstrukte wie Telnet behelfen. Kurzum: die Eingabeleiste in FHEMWEB ist für einzelne Befehle geeignet, aber nicht für einen Batchinput. Als Freund von modernen Editoren, wie z.B. Sublime, kann man jedoch recht einfach verschiedene Geräte mit dem selben Raum oder anderen Attributen über eine spaltenweise Modifikation versorgen. Ich möchte Euch kurz zeigen wie man fertige Snippets einfach per Copy + Paste in FHEM ausführen kann.[Weiterlesen]
OWServer systemd Service-File erstellen
In meinem Artikel über OW-Anwendungen (OneWire / 1-Wire) habe ich kurz die Einsatzszenarien von OWServer beschrieben. Da ich den Selbigen für die FHEM-Integration benötige, habe ich mir ein systemd-Service-File erstellt, welches mir den Dienst vor FHEM startet.
Das OWServer Service-File
[user@pi /]$ cat /etc/systemd/system/multi-user.target.wants/owserver.service [Unit] Description=OWServer After=syslog.target network.target [Service] Type=forking User=root WorkingDirectory=/root ExecStart=/usr/bin/owserver -p 3001 -u [Install] WantedBy=multi-user.target
Im systemd-File von FHEM findet sich dann in der Konfiguration von „After=“ ein owserver.service (siehe auch im FHEM-Artikel unter Nacharbeiten). Diese Konstellation funktioniert bei mir sehr stabil und ohne Ausfälle.
Andere Einsatzmöglichkeiten
Die Möglichkeit über FHEM ist natürlich nur eine von vielen. Mir fällt Adhoc der Zugriff über owfs oder die anderen Tools der OW-Palette ein. Hier sind der Kreativität keine Grenzen gesetzt.
FHEM unter Archlinux installieren
FHEM ist ein super System um das eigene Zuhause zu automatisieren. Auf meinem Raspberry Pi läuft Archlinux. Das AUR stellt auch ein Paket zur Installation bereit. Allerdings schmierte die Installation bei mir aber immer wieder ab. Da sich ein integrierter Updatemechanismus in der Software befindet, wiegt das Ausbleiben einer Paketmanagementintegration nicht so schwer. Also mache ich mich daran unter Archlinux die „Freundliche Hausautomatisierung und Energie-Messung“ manuell zu installieren.
FHEMinfo funktioniert aufgrund fehlendem Perl-Modul „HTTP::Request::Common“ nicht
Sollte Euer FHEMinfo mit der Fehlermeldung „Missing perl module ‚HTTP::Request::Common‘. Please install this module first.“ abbrechen, dann könnt Ihr Euch das Paket perl-libwww nachinstallieren. Unter Archlinux also z.B. mit:
sudo pacman -S perl-libwww
Unter anderem angeregt durch: http://forum.fhem.de/index.php?topic=14872.0
Mit OWFS und Konsorten Temperatursensoren (DS18B20) auf dem Raspberry Pi abfragen
In meinem Beitrag vom November „Mit Perl Skript 1-Wire Temperatursensor DS18B20 am Raspberry Pi abrufen“ habe ich beschrieben, wie man ohne großartige Software einen Temperatursensor des Modells DS18B20 per Skript abrufen kann. Mittlerweile bin ich aus dem Ultra-Alpha-Stadium (Ausnahme bildet hier die Verkabelung (da bin ich echt nicht gut drin)) raus und habe auf einen DS9490R und mehrere DS18B20 umgerüstet.
Temperatursensor DS18B20 über Lüsterklemme verkabelt
Hierbei bin ich auf ein paar Probleme gestoßen. Wie man Temperatursensoren noch ansteuern kann, möchte ich hier kurz erläutern. Meine Anleitungen basieren ab sofort auf dem DS9490R, es scheint hier ein paar Unterscheidungen zu der GPIO-Variante zu geben.
Variante 1: OWFS
Unter Archlinux lässt sich OWFS (1-Wire Filesystem) einfach über Pacman installieren. Nachdem man sich einen Mountpoint angelegt hat, lässt sich der 1-Wire Bus über folgenden Befehl einbinden:
owfs --allow_other -a alias.txt -u /mnt
Ich mounte immer als Root, deshalb empfiehlt sich der an FUSE durchgereichte Parameter „–allow_other“. Mit der Option „-u“ teilt man OWFS mit, dass er den DS9490R als Quelle verwenden soll. Mein absoluter Favorit bildet die Option „-a“, die es ermöglicht menschenfreundliche Namen hinter den IDs zu hinterlegen. Im eingebundenen Verzeichnis finden sich dann nicht mehr die kryptischen IDs, sondern die entsprechenden Namen. Weitere Informationen findet man in der ausführlichen Onlinehilfe. Zusätzliche Optionen habe ich bisher nicht benötigt. Zugriff ergibt sich dann z.B. über cat:
[pi@pi ~]$ cat /mnt/$NAME_DES_SENSORS/temperature; echo
20.4375
[pi@pi ~]$Die Temperatur wird immer eine gewisse Zeit – ich nenne es mal so – gecached. Ich teste immer ob ich den richtigen Sensor habe, in dem ich Ihn anhauche – da braucht man unter Umständen einen etwas längeren Atem. 😉
Variante 2: OWServer
Ich führe explizit den OWServer auf, da er im Zusammenspiel mit FHEM (Super Anleitung) genutzt wird. Es gibt aber auch noch weitere Usecases. So lässt sich OWFS auf einen OWServer verbinden, der im Netzwerk bereit steht. Es ergibt sich zum Beispiel der Anwendungsfall, dass die Verbindung nicht unbedingt kabelgebunden (über 1-Wire) erfolgen muss. Über den OWServer lässt sich auch direkt über meine Lieblingssprache Perl programmieren (auch über USB direkt möglich).
Variante 3: OWhttp
Die Oberfläche von OWhttp würde ich jetzt nicht gerade als „fancy“ bezeichnen, aber es passt irgendwie zu 1-Wire: stabil und funktional. Hier lassen sich alle Werte auslesen und gegebenenfalls auch setzen.
Anzeige eines DS18B20 über OWHTTP
Die Syntax wiederholt sich und wird sicherlich den ein oder anderen langweilen. Mit „-p“ habe ich OWHTTP auf Port 5000 zum Lauschen geschickt.
owhttpd -u -p 5000 -a alias.txt
Variante 4, 5, …
Es gibt noch zig andere Varianten auf 1-Wire Devices zuzugreifen. Es seien genannt:
- owftpd – Zugriff über FTP-Befehle
- owshell – Zusammenfassung von Befehlen für die Shell-Programmierung
Fazit
Am Anfang dachte ich: Warum zur Hölle all diese Programme um 1-Wire zu benutzen? Ich muss sagen, dass ich positiv von der Stabilität und Macht von 1-Wire und seinen Programmen überrascht bin. Selten so gut und leicht verständliche Dokumentation gelesen, was wahrlich keine Selbstverständlichkeit ist. Ich bin gerade am Testen von FHEM in Verbindung mit OWserver. Über OWserver kann ich dann natürlich dank OWFS Möglichkeiten einer Netzwerkverbindung parallel zu FHEM auf die Temperatursensoren zugreifen. Modularität for the win!
