Crontab

Kleiner Crontab-Reminder

Weil ich es immer vergesse und es sich in Zukunft wahrscheinlich auch nicht ändert:

Vorbelegte Strings der Crontab:

Wiederholung:

Crontab Repeat by http://www.adminschoice.com/crontab-quick-reference/

Crontab Repeat by http://www.adminschoice.com/crontab-quick-reference/

Quellen / Links:

Weiterführende Informationen bzw. von dort kopiert: http://www.adminschoice.com/crontab-quick-reference/ und http://www.pantz.org/software/cron/croninfo.html

OWServer Help

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 OWServer 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

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 und Temperaturplots

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.

Weiterlesen

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:

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

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:

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:

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.

OWHTTP zeigt die Sensoren an

OWHTTP zeigt die Sensoren an

Anzeige eines DS18B20 über OWHTTP
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.

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!

1-Wire USB Adapter DS9490R

DS9490R bringt nach kurzer Zeit Fehlermeldungen unter Archlinux am Raspberry Pi

Ich habe mir vor 2 Monaten einen DS9490R zugelegt um meine Herde an DS18B20 über den Raspberry Pi zu verwalten und abzufragen. Die positive Bastlerstimmung wurde ziemlich schnell durch Kernelmeldungen ala

getrübt. Der Zugriff über die Verzeichnisse /sys/bus/w1/* funktionierte nur für eine gewisse Zeit und brachte dann keine (sinnvollen) Ergebnisse mehr.

DS9490R-Problem = Stromproblem?

Meine ersten Ideen gingen in Richtung Stromversorgung. Diese Vermutung veranlasste eine kleine Bestellarie von Netzteilen mit mehr Ampere über aktive USB-Hubs. Leider blieb das Phänomen bestehen. Ansonsten funktionieren die neuen Geräte einwandfrei und bleiben bei mir. Für einen stabilen Betrieb des Raspberry Pi tut eine gute Stromversorgung über ein starkes Netzteil und das abfrühstücken der USB-Verbraucher über einen USB-Hub sicherlich gut.

Andere Problemlösung…

Letzendlich brachte es nur was, das Kernelmodul ds2490 zu blacklisten und den Zugriff über OWFS durchzuführen. Aktuell habe ich 2 Temperatursensoren verkabelt und kann so fehlerfrei über OWFS zugreifen. Wie das geht, möchte ich auch noch kurz dokumentieren.

OWFS

Die Benutzung gestaltet sich recht unspektakulär und stabil. Mit einem:

lässt sich der 1-Wire Bus nach /mnt mounten. Die Option “allow_other” ist quasi selbsterklärend für den durchgereichten Parameter in FUSE. Mit “-a alias.txt” kann man sich nach einmaliger Erarbeitung der IDs der Sensoren über sprechende Namen der Sensoren freuen. Statt 28.XXXXXF050000 erscheint dann im eingebundenen Ordner ein freundliches “Wohnzimmer”. Die Datei folgt dem einfachen Aufbau: $SENSORID = $TEXT. Weitere (und ja wirklich ausführliche) Informationen bietet die Seite von OWFS zu Aliasen. Die Option “-u” gilt als Aufforderung den benannten DS9490R als Eingabe zu verwenden.

Fazit

Ich wollte beim Auslesen der Temperatursensoren eigentlich weitestgehend ohne Zusatzsoftware auskommen und direkt über die /sys/bus/w1-Daten gehen. Naja, letztendlich zählt, dass es funktioniert. Und das tut es in der Tat. Aktuell bin ich am austesten der Funktionen, die mir FHEM bietet. Hierbei setze ich auf den OWserver, der die Daten an FHEM ausliefert.

systemd Screenshot

WLAN unter Archlinux auf dem Raspberry Pi in Betrieb nehmen

Ich habe mir einen Mini-WLAN-Stick (EDIMAX EW-7811UN) für den Raspberry Pi zugelegt, den sicherlich noch mehr Leute im Einsatz haben. Für Raspbian finden sich einige Anleitungen, unter Archlinux ist das durch die Nutzung von systemd ein wenig anders.

Die einfachste Variante ist meiner Meinung nach über das Paket netctl. In diesem Paket findet sich der Befehl wifi-menu, mit dem sich passende WLAN-Profile anlegen lassen. Nachdem die Tour durchgeführt wurde, wird unter /etc/netctl/*NAME DES PROFILS* das Profil abgelegt, dass dann z.B. noch über einen Editor bearbeitet werden kann. Das kleine Tool legt bereits einen systemd-Service an, sodass hier keine Nacharbeiten nötig sind. Sollte mal was schief laufen, kann man über

den aktuellen Status abprüfen und etwaige Probleme erkennen. Der Befehl netctl bietet noch mehr Möglichkeiten wie z.B. das disablen eines Services oder auch das erneute enablen, wenn Änderungen am Profil nötig wurden.

Bottleneck. CC-BY-SA 2.0: http://www.flickr.com/photos/tswestendorp/

Dem Galaxy Nexus ordentlich einheizen mit fstrim und so die Performance verbessern

Ich habe vor Kurzem auf Android 4.4 mit Cyanogenmod 11 umgestellt, nachdem mein Bootloader aktualisiert war. Das Smartphone war allerdings unbenutzbar langsam. Bildschirmeingaben dauerten ewig, Apps öffneten sich langsam, Lags wohin das Auge schaute, von Tastaturreaktion konnte keine Rede sein; kurz gesagt: die Performance war einfach grottenschlecht. Eine Lösung habe ich in diesem Thread gefunden. Der Flaschenhals (Neudeutsch Bottleneck) war wohl der Storage in Verbindung mit der SSD-Trim-Problematik. Über die adb shell im Recovery habe ich dann mit fstrim alle Partitionen getrimmt. Die einfachere Variante ist die App LagFix (fstrim) Free. Die App setzt Root-Zugriff voraus. Ich habe mir die Pro Version gegönnt, da man hier automatische Schedules einrichten kann.

Beitragsbild: Bottleneck. CC-BY-SA 2.0: http://www.flickr.com/photos/tswestendorp/

Linux-Bibliothek. Quelle: http://www.flickr.com/photos/fsse-info/ (CC BY-SA 2.0)

Unterstützung beim Erstellen des freien Wiki-Books “Linux-Praxisbuch”

Heute mal ein etwas anderer Blogeintrag. Über unsere Mailingliste der LUG-Landau hat uns ein Hilfegesuch von Peter Littmann erreicht. Er ist Hauptauthor des Titels “Linux-Praxisbuch” bei Wiki-Books. Er lädt jeden herzlich ein das Buch zu lesen, zu kommentieren oder auch in der Gruppe weiter zu entwickeln. Peter fasst den Inhalt wie folgt zusammen: “Das Buch beschreibt Linux-Grundlagen, Anwendungen, Systemadministration und Netzwerkverwaltung und soll aus der Praxis für die Praxis geschrieben werden.”

Weiterlesen

yet another computer and stuff blog