https://xkcd.com/1168/
Artikel
2 Kommentare

Cheat: Beispiele als Ergänzung zu Manpages

Man muss ja schon ein gewisses Faible für Manpages haben um so richtig mit Ihnen zurecht zu kommen. Es gibt sehr viele gute Manpages, aber auch einige miserable Exemplare. Diese Lücke schließt meiner Meinung nach cheat. Ich kann nur für mich sprechen, aber Beispiele bringen mich 10 mal weiter, als trockene Theorie. Cheat bietet eine stattliche Anzahl an Beispielen, die einfach in die bestehende Landschaft integriert werden können. Ein ‚cheat -l‘ bietet dann eine Auswahl an Befehlen, für die es Cheatsheets gibt. Mit einem ‚cheat tar‘ könnte man unter Umständen das nächste mal die Bombe entschärfen:

user@pc ~/ $ cheat tar
# To extract an uncompressed archive:
tar -xvf /path/to/foo.tar

# To create an uncompressed archive:
tar -cvf /path/to/foo.tar /path/to/foo/

# To extract a .gz archive:
tar -xzvf /path/to/foo.tgz

# To create a .gz archive:
tar -czvf /path/to/foo.tgz /path/to/foo/

# To list the content of an .gz archive:
tar -ztvf /path/to/foo.tgz

# To extract a .bz2 archive:
tar -xjvf /path/to/foo.tgz

# To create a .bz2 archive:
tar -cjvf /path/to/foo.tgz /path/to/foo/

# To list the content of an .bz2 archive:
tar -jtvf /path/to/foo.tgz

# To create a .gz archive and exclude all jpg,gif,... from the tgz
tar czvf /path/to/foo.tgz --exclude=\*.{jpg,gif,png,wmv,flv,tar.gz,zip} /path/to/foo/

Cheat installieren

Installieren lässt sich Cheat, indem man das git-Repository klont und anschließend die setup.py ausführt:

git clone https://github.com/chrisallenlane/cheat.git
cd cheat
sudo python setup.py install

Ich für meinen Teil habe das Repository geforkt und anschließend unter meinem ~/bin abgelegt. So kann ich die Cheatsheets auch mal anpassen und u.U. Pullrequests senden um meine Arbeit zu teilen. Der geneigte Archlinux User kann sich aus dem AUR bedienen.

Sonstiges

Cheat lässt sich über diverse Variablen konfigurieren. Somit lassen sich z.B. auch Rezept- oder Notizdatenbanken aufbauen (alternatives Verzeichnis mit Rezept- / Notiznamen als Dateinamen).

CC-BY 2.0 by http://www.flickr.com/photos/othree/
Artikel
3 Kommentare

Dotfiles (bashrc, vimrc,…) mit GitHub synchronisieren und aktuell halten

Wer kennt das nicht? Die schönen aliase oder die vimrc mal wieder nicht auf dem Server/PC/Notebook/Raspberry Pi vorhanden. Gerade wenn man öfter mal was auf X Rechnern testet, bekommt man häufig von der Shell gesagt, dass es den Befehl gar nicht gibt… eben weil die ganzen Dotfiles fehlen und der Mensch ein Gewohnheitstier ist (‚ll‘ tippt sich einfach schneller als ‚ls -l‘). Mir ging es immer so, dass ich pro Maschine zusammengeschusterte Dotfiles hatte. Und es fehlt immer etwas. Eben auch, weil das passende zentrale Management fehlt.

GitHub does dotfiles

GitHub hat als Einführung eine eigene Seite für die „Punktfiles“ online. Hier finden sich verschiedene Tools, Bootstraps und Beispiele, wie man seine Dotfiles verwalten kann. Unter anderem seien genannt: homesick, fresh,… Was mich abschreckte ist die Komplexität, die für eine relativ einfache Sache benötigt wird. Ja: die Tools können echt viel, aber ich hole mir viel Code ins Boot.

Mit ein paar Zeilen Code immer up to date bleiben

Zum Glück fand ich einen Blogeintrag von Michael Smalley, der sehr übersichtlich und verständlich erklärt, wie man sein eigenes Skript und GitHub-Repository aufsetzen kann. Aufbauend auf diese Anleitung habe ich mir zwei Shellskripts unter ~/.dotfiles angelegt.

#!/bin/bash
############################
# Init-Script
# This script creates symlinks from the home directory to any desired dotfiles in ~/.dotfiles
############################

########## Variables

dir=~/.dotfiles                    # dotfiles directory
olddir=~/.dotfiles_old             # old dotfiles backup directory
files=`ls -1 $dir/__*`    # list of files/folders to symlink in homedir

##########

# create dotfiles_old in homedir
echo "Creating $olddir for backup of any existing dotfiles in ~"
mkdir -p $olddir
echo "...done"

# change to the dotfiles directory
echo "Changing to the $dir directory"
cd $dir
echo "...done"

# move any existing dotfiles in homedir to dotfiles_old directory, then create symlinks 
for file in $files; do
    basename=`basename $file`
    targetname=`echo $basename | sed 's/__//'`
    echo "Moving any existing dotfiles from ~ to $olddir"
    mv ~/.$targetname $olddir/
    echo "Creating symlink to $file in home directory."
    ln -s $dir/$basename ~/.$targetname
done

Dieses Skript erledigt das Backup von „alten“ Dotfiles auf einer neuen Maschine und verlinkt jeweils die im Verzeichnis liegenden Dateien (jeweils mit Prefix „__“). Ich habe mich für diese Variante entschieden, da man relativ einfach neue Dateien integrieren kann. Mit einem „git init“ und dem Hinzufügen der Dateien per „git add $filename“ baut man sich ziemlich schnell sein „dotfiles“-Repository zusammen. Zu dem init-Skript habe ich mir noch ein Skript angelegt, dass nur die lokale Verlinkung übernimmt.

#!/bin/bash
############################
# 
# This script creates symlinks from the home directory to any desired dotfiles in ~/.dotfiles
############################

########## Variables

dir=~/.dotfiles                    # dotfiles directory
files=`ls -1 $dir/__*`    # list of files/folders to symlink in homedir

##########
# change to the dotfiles directory

# move any existing dotfiles in homedir to dotfiles_old directory, then create symlinks 
for file in $files; do
    basename=`basename $file`
    targetname=`echo $basename | sed 's/__//'`
    echo "Creating symlink to $file in home directory."
    ln -s $dir/$basename ~/.$targetname
done

Meine erste Datei war die .vimrc. Also habe ich mir mit vim eine neue Datei unter .dotfiles angelegt, die den Namen __vimrc bekommt. Nachdem ich diese Datei gefüllt hatte, konnte ich mit „init.sh“ die Datei installieren. Es wird im Homeverzeichnis ein Link auf die Datei unter .dotfiles/__vimrc angelegt. Siehe auch:

user@pc ~ $ ll .dotfiles/__vimrc 
-rw-r--r-- 1 user user 1,3K Feb 21 17:32 .dotfiles/__vimrc
user@pc ~ $ ll .vimrc
lrwxrwxrwx 1 user user 30 Feb 16 00:07 .vimrc -> /home/user/.dotfiles/__vimrc

Der Inhalt der vimrc wird absofort immer über .dotfiles/__vimrc verwaltet und im Git-Repository gesichert. Da ich nicht der Git-Profi bin, habe ich mich hier sehr stark an die oben genannte Anleitung gehalten.

Updaten und aktuell halten

Änderungen werden mit einem einfachen „git commit -a“ in das lokale Repository eingecheckt. Sobald man diese Änderungen zu GitHub übertragen möchte, kann man dies mit „git push origin master“ machen. Voraussetzung hierfür ist, dass man die Schritte von Michael zur Einrichtung durchgeführt hat. Einen neuen Rechner kann man dann per „git clone git://github.com/<usernameongit>/dotfiles.git“ aktivieren. Nachdem man seine Skripte ausführbar gemacht hat, kann man man mit „init.sh“ seine Dotfiles installieren. Sollte sich das GitHub Repository in der Zwischenzeit geändert haben, kann man mit einem „git pull“ die aktuellste Version von GitHub ziehen.

Fazit

Für mich hat diese Vorgehensweise zweierlei Vorteile: ich werde so langsam aber sich mit git etwas warm. Weiterhin kann ich nun auf meinem PC, meinem Notebook und auf meinem Raspberry Pi die gleichen Dotfiles verwenden ohne manuell irgendwas durch die Gegend kopieren zu müssen. Veränderungen werden automatisch versioniert und können gezielt zurück geholt werden. Ich hoffe ich konnte Euer Interesse wecken und Ihr könnt mit meinen Infos etwas anfangen. Mein Dotfiles Repo findet sich unter: https://github.com/demaya/dotfiles und wartet nur darauf, von Euch geforked zu werden 🙂

Links

Beitragsbild: CC-BY 2.0 by http://www.flickr.com/photos/othree/

OWServer Help
Artikel
0 Kommentare

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 und Temperaturplots
Artikel
0 Kommentare

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]

Artikel
2 Kommentare

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:

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.

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.

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!

1-Wire USB Adapter DS9490R
Artikel
2 Kommentare

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

[ 1750.434431] Failed to read 1-wire data from 0x81: err=-110.
[ 1750.440617] 0x81: count=-110, status:

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:

[pi@pi ~]$ sudo owfs --allow_other -a alias.txt -u /mnt
DEFAULT: ow_usb_msg.c:(295) Opened USB DS9490 bus master at 1:6.
DEFAULT: ow_usb_cycle.c:(191) Set DS9490 1:6 unique id to 02 08 06 AF 00 00 00 01
[pi@pi ~]$

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
Artikel
1 Kommentar

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

netctl status *NAME DES PROFILS*

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.

Alarm. CC BY-NC 2.0: http://www.flickr.com/photos/h_is_for_home/
Artikel
3 Kommentare

Mit Perl und Jabber/XMPP mit dem Raspberry Pi kommunizieren – Senden

Wenn der Raspberry Pi im stillen Kämmerlein vor sich hin arbeitet, sollte doch ab und zu mal eine kleine Kommunikation stattfinden:

  • Temperatur der CPU über Schwellwert gestiegen
  • Backup erfolgreich erledigt
  • Die Temperatur im Rücklauf der Heizung ist unter einen Schwellwert gefallen
  • PIR Sensor schlägt Alarm
  • … der Fantasie sind keine Grenzen gesetzt…

Bei Emails habe ich immer das Problem,  dass diese in der Mailflut untergehen. Es gibt auch noch die Möglichkeit per Whattsapp Nachrichten zu senden, aber auch hier besteht die Gefahr des gekonnten Ignorierens.  Wie kann man also mit dem Raspberry Pi kommunizieren? Am besten noch ohne große Verzögerungen.

Ich finde die Lösung über Jabber/XMPP ganz gut. Clients gibt es quasi für jedes Betriebssystem: Android, Linux,… Und eben auch zahlreiche Schnittstellen für Programmiersprachen. In meinem Fall für Perl (Paket libnet-xmpp-perl unter Ubuntu). Im ersten Beitrag geht es mir erst mal um die Richtung Pi => Smartphone. Mit dem angehängten Code kann man nach dem Speichern per Kommandozeile einen Empfänger und einen Text dem Programm mitgeben.

#!/usr/bin/perl
use strict;
use warnings;
use Net::XMPP;

my ($recipient, $message) = @ARGV;

if(!($recipient) || !($message)) {
    print "Usage: $0  \n";
    exit;
}

my $hostname = 'host';
my $sender = 'user';
my $password = 'pw';

my $connection = new Net::XMPP::Client();
my $status = $connection->Connect(
    hostname => $hostname,
    connectiontype => 'tcpip',
    tls => 1,
    port => 5222
    );

die("XMPP connection failed $!") if ! defined($status);

my @result = $connection->AuthSend(
    hostname => $hostname,
    username => $sender,
    password => $password);

die("XMPP authentication failed") if $result[0] ne 'ok';
die("XMPP message failed") if ($connection->MessageSend(to => $recipient, body => $message) != 0);
print "Message sent!\n";

Für meinen Testbetrieb habe ich mir unter http://jabber.hot-chilli.net/ zwei Accounts angelegt. Einen Account für den Raspberry Pi und einen Empfänger, der bei mir auf dem Smartphone angemeldet ist. Vielleicht ist diese Anleitung ja auch für Jemand anderes interessant. Der Code wird bei mir später in die Alarmierung direkt eingebunden und vermutlich nicht als eigenständiges Programm verwendet. Im Nächsten Teil möchte ich dann auf das Empfangen von Nachrichten eingehen, damit z.B. Befehle per XMPP/Jabber gegeben werden können.

  1. Teil – Senden von Nachrichten
  2. Teil – Empfangen von Nachrichten

Beitragsbild: Alarm. CC BY-NC 2.0: http://www.flickr.com/photos/h_is_for_home/

Raspberry Pi. CC BY 2.0: http://www.flickr.com/photos/gijsbertpeijs/
Artikel
0 Kommentare

Auf dem Raspberry Pi Systeminformationen beim Login anzeigen

Ich fand die Systeminformationen beim Login auf einem Ubuntuserver immer recht ansprechend und sinnvoll. Ich bin einfach nicht der Typ, der sich Informationen andauernd holt, ich brauche gelieferte Infos… Auf dem Raspberry kann man sich relativ einfach eine ähnliche Anzeige (quasi System Motto of the day (MOTD)) bauen. Vorweg: ich nutze Archlinux auf dem Raspberry, unter Umständen müsst Ihr meinen Code an Euer System anpassen.

[Weiterlesen]

Thermometer. CC-BY 2.0: http://www.flickr.com/photos/renaissancechambara/
Artikel
1 Kommentar

Mit Perl Skript 1-Wire Temperatursensor DS18B20 am Raspberry Pi abrufen

Ich habe vor ein paar Tagen mein GPIO-Test-Package für den Raspberry Pi bekommen. Heute bin ich beim Testen des Temperatursensors angekommen. Um den Sensor anzusteuern, müssen die Kernelmodule „w1-gpio“ und „w1-therm“ geladen sein. Verkabelung lässt sich bei Tante Google erfragen.

 

DS18B20 Temperatursensor an Breadboard

DS18B20 Temperatursensor an Breadboard

Zum Einlesen reicht einerseits die Shell, in dem man einfach das nötige File öffnet. Eleganter geht es natürlich über ein Skript, welches ich mir in ein paar Minuten zusammen geschustert habe:

#!/usr/bin/perl

use strict;
use warnings;

my $path   = '/sys/bus/w1/devices/';
my $sensor = 'sensor-id';
my $file   = $path . $sensor . "/w1_slave";

print "Open file: " . $file . "\n";
open(IN, $file) or die "Cannot open file $!\n";

while () {
	if($_ =~ /crc=.*YES/) {
		print "Temperature read, continue\n";
	}
	if($_ =~ /crc=.*NO/) {
		print "Temperature read error\n";
		exit(1);
	}	
	if($_ =~ /t=(\d*)/) {
		my $temp = sprintf("%.3f", $1/1000);
		print "Temperature: " . $temp . "° Celsius\n";
	}
}

Nachdem das Skript gespeichert und ausführbar gemacht wurde, kann man es aufrufen und erhält dann eine schön formatierte Grad-Zahl:

[user@pi bin]$ perl temp.pl
Open file: /sys/bus/w1/devices/sensor-id/w1_slave
Temperature read, continue
Temperature: 25.187° Celsius
[user@pi bin]$

Natürlich müsst Ihr die Sensor-ID an Eure Bedürfnisse anpassen!

Update: Mittlerweile habe ich einige Erfahrungen mit 1-Wire und den DS18B20 sammeln dürfen. Aktuellere Informationen finden sich hier und hier.

Beitragsbild: Thermometer. CC-BY 2.0: http://www.flickr.com/photos/renaissancechambara/