Ausprobiert: Netzwerkweites Adblocking mit Pi-hole

Von Pi-hole hatte ich schon hin und wieder gehört, mich aber bisher nie so recht damit befasst. Auf Twitter flog der Name nun mal wieder an mir vorbei, was ich zum Anlass nahm, die Software mal auszuprobieren.

Was ist Pi-hole?

Pi-hole ist ein Werbeblocker. Jedoch nicht zu vergleichen mit Werbeblockern wie Adblock Plus oder anderen Browser-Erweiterungen.

Pi-hole blockiert Werbung für quasi alle Geräte im Netzwerk, ohne dass dort etwas installiert oder konfiguriert werden muss.
Die Software muss auf einem Linux-Gerät im Netzwerk installiert und im Router als DNS-Server eingetragen werden.

Wird nun beispielsweise eine Website aufgerufen, geht die Anfrage an das Pi-hole, wird dort mit einer Blockliste verglichen und entsprechend beantwortet. Versucht der Browser, eine Domain aufzurufen, die auf der Blockliste steht, wird diese Anfrage geblockt und die Werbung oder das Tracking-Script nicht geladen.

Dadurch, dass es nicht nur eine Browser-Erweiterung ist, blockt es auch Werbung in Apps und sogar im Smart-TV.

Was braucht man?

Die Hardware ist fast egal. Ich nutze einen Raspberry Pi 3. Als Betriebssystem wird offiziell Debian, Ubuntu, CentOS, Fedora und Raspbian unterstützt. Ich nutze der Einfachheit halber Raspbian ohne Desktop.

Nach der Grundinstallation kann bereits die Installation von Pi-hole erfolgen, hierfür muss lediglich der Webinstaller über die Konsole aufgerufen werden:

curl -sSL https://install.pi-hole.net | bash

Die Installation erfolgt geführt und Nutzerfreundlich und ermöglicht auch die Einstellung einer festen IP, was ja für den Betrieb als DNS-Server zwingend erforderlich ist, außerdem wird auch das Webinterface eingerichtet.

Wichtig ist, dass bei der Installation ein lighttpd auf Port 80 eingerichtet wird, hier wird das Webinterface angezeigt. Es sollte also kein anderer Dienst bereits Port 80 nutzen.

Und dann?

Nach der Installation ist das Pi-hole grundsätzlich fertig eingerichtet. Jetzt muss nur noch im Router der DNS-Server auf die IPs des Pi-hole eingestellt werden, damit alle DNS-Anfragen von diesem geprüft und beantwortet werden können.

Einstellungen? Statistiken?

Geht alles entweder über die Konsole, oder über das Webinterface. Das Passwort wird bei der Installation angezeigt.

Webinterface von Pi-hole
Webinterface von Pi-hole

Fazit

Ich habe das Gerät seit gestern Abend im Netzwerk und bin bisher echt zufrieden und habe nur zu Anfang beim Cache-Aufbau eine Verlangsamung der Anfragen gespürt. Seitdem laden Seiten deutlich schneller und sind bisher zuverlässig Werbefrei.

Ach ja, Seiten mit Adblock-Blocker wie bild.de kann man mit einem Pi-hole nicht mehr nutzen. Noch ein Vorteil.

Temperatursensor DS18B20 unter Linux per Pythonscript abfragen

Vor ein paar Tagen habe ich eine kurze Übersicht über die Benutzung der OneWire-Schnittstelle in CODESYS 3.5 auf dem Raspberry Pi veröffentlicht. Inzwischen habe ich per Mail von mehreren Lesern die Frage nach einer funktionierenden Lösung mit Python bekommen, daher möchte ich das noch schnell hinterher schieben.

Aufbau

Um das ganze noch ein kleines Bisschen spannender zu machen, sind dieses Mal drei Sensoren gleichzeitig angeschlossen. Auf dem Breadboard sieht das so aus:

Drei Temperatursensoren DS18B20 parallel an einer "Sensorleitung"
Drei Temperatursensoren DS18B20 parallel an einer „Sensorleitung“

Schnell in gEDA abgezeichnet sieht es so aus:

Drei DS18B20 parallel als Schaltbild
Drei DS18B20 parallel als Schaltbild

Man sieht also, die Sensoren können parallel geschaltet werden, der Widerstand wird nur ein Mal benötigt.

Wenn, wie im oben bereits verlinkten Artikel die Kernelmodule über den Device Tree geladen sind (/boot/config.txt), sollten die drei Sensoren danach im Verzeichnis /sys/bus/w1/devices/ sichtbar sein, hier gibt es wieder für jeden Sensor einen Ordner, der mit seiner eindeutigen ID benannt ist:

Die Ordner der drei Sensoren, benannt nach der jeweiligen ID
Die Ordner der drei Sensoren, benannt nach der jeweiligen ID

Wie schon im ersten Artikel können auch hier die Werte mit der Datei w1_slave ausgegeben werden:

root@raspberrypi:/sys/bus/w1/devices/28-0216009b68ff# cat w1_slave 
2f 01 4b 46 7f ff 0c 10 a7 : crc=a7 YES
2f 01 4b 46 7f ff 0c 10 a7 t=18937

So weit waren wir beim letzten Mal auch schon, jetzt gehts ans Python-Script.

Programm erstellen

Zuerst müssen wir die bis dahin ja noch nicht existente Datei mit dem Editor unserer Wahl öffnen. Ich mag nano, öffne die Datei also mit

nano temp.py

Um das Programm später mit dem richtigen Interpreter direkt ausführen zu können, müssen wir jetzt im Shebang python als ebendiesen nennen, danach legen wir fest, welche Bibliotheken geladen werden sollen:

#!/usr/bin/env python
import os, time, sys

Um Fehlern aus dem Wege zu gehen, laden wir nun noch die Kernelmodule, die wir nutzen möchten:

os.system('modprobe w1-gpio')
os.system('modprobe w1-therm')

Am Anfang des Programmes legen wir nun noch ein paar Werte als Variablen fest, die wir später benutzen können. Ich habe als sensorcount die Anzahl des Sensoren angegeben, unter sensors die Kennung der drei Sensoren als Array, unter sensorpath den Pfad zu den Geräteverzeichnissen als String und unter sensorfile den Namen der Datei ebenfalls als String:

sensorcount = 3
sensors = ['28-0216009b68ff', '28-021600b769ff', '28-021600bb4dff'];

sensorpath = '/sys/bus/w1/devices/'
sensorfile = '/w1_slave'

Nun erstellen wir die Funktion, die die Sensordaten abfragt und verarbeitet:

def callsensor(sensor):
  f = open(sensorpath + sensor + sensorfile, 'r')
  lines = f.readlines()
  f.close()
  if lines[0].strip() [-3:] != 'YES':
    sys.exit('Fehler bei Sensor ' + sensor)
  temp_line = lines[1].find('t=')
  if temp_line != -1:
    temp_output = lines[1].strip() [temp_line+2:]
    temp_celsius = float(temp_output) / 1000
    return temp_celsius

Die Funktion öffnet die Gerätedatei im Lesemodus, schreibt den Inhalt auf lines und schließt sie dann wieder. Die Variable sensor wird dabei später als Parameter beim Funktionsaufruf mitgegeben.
Zeile 1 wird nun auf die letzten drei Zeichen gekürzt und geprüft, ob diese „YES“ sind, also ob die Prüfsumme des Sensors okay ist. Wenn nicht, wird das Programm mit einer Fehlermeldung abgebrochen.
Nun wird der Index (also die Position) des Strings t= in der zweiten Zeile ermittelt. Ist diese nicht -1 (das gibt find zurück, wenn nichts gefunden wurde), wird Zeile 2 auf die Zeichen nach t= gekürzt (das ist der fünfstellige Temperaturwert des Sensors), der Wert wird durch 1000 geteilt und wir erhalten so den Wert in °C. Die Funktion wird dann beendet und der Temperaturwert zurückgegeben.

Nun fehlt nur noch der Teil, der die Funktion beim Aufruf des Programms ausführt und die Werte an stdout (also momentan die Konsole) zurückgibt:

for i in range(0, sensorcount):
  s = sensors[i]
  print('Sensor ' + str(i) + ': ' + str(callsensor(s)))
sys.exit()

Hier haben wir eine for-Schleife, die die Funktion callsensor für jeden Sensor einmal aufruft und die Sensor-ID aus dem Array als Parameter an callsensor übergibt. Das Ergebnis wird ausgegeben und das Programm wird beendet.

Das Programm müssen wir nun nur noch speichern. Um es ausführen zu können, müssen wir es noch ausführbar machen:

chmod +x temp.py

Wenn wir es nun in der Konsole ausführen, bekommen wir drei Ausgaben für unsere Sensoren:

root@raspberrypi:~/tutorials/temperatur# ./temp.py
Sensor 0: 18.437
Sensor 1: 19.937
Sensor 2: 20.062

Zum Schluss hänge ich die Programmdatei (übrigens kommentiert) hier an: Python-Programm temp.py

Raspberry Pi: 1-Wire Temperatursensor 18B20 auslesen unter Linux und CODESYS

Wer sich mal etwas mit dem kostengünstigen verdrahten moderner Häuser oder Wohnungen auseinander gesetzt hat, wird schon auf den 1-Wire oder OneWire Bus gestoßen sein. Dieser Bus ermöglicht es, mit einem geringen Verdrahtungsaufwand zum Beispiel Sensoren an ein Gerät anzuschließen. Es werden mindestens zwei Adern benötigt, besser drei oder vier, es können jedoch mehrere Sensoren parallel angeschlossen werden.

Ein sehr beliebter Sensor ist der Temperatursensor 18B20 bzw. DS18B20, er misst die Temperatur auf 0,5°C genau und gibt diese als tausendstel aus, 21,5°C zeigt der Sensor also als 21500 an. Die Messung wird über eine Prüfsumme validiert.

1-Wire am Raspberry Pi aktivieren

Der Raspberry Pi bringt einen 1-Wire-Bus mit, der über die GPIO-Pins läuft. Der Bus mus jedoch zuerst eingeschaltet werden, dies geschieht über die Datei /boot/config.txt, hier muss eine Zeile mit folgendem Inhalt eingetragen werden:

dtoverlay=w1-gpio

Dies aktiviert im Device Tree die 1-Wire-Schnittstelle auf dem Standard-GPIO-Pin, also Pin 7. Nach dieser Änderung muss ein Neustart durchgeführt werden, der Bus ist nun aktiv.

DS18B20 an den Raspberry Pi anschließen

Der Sensor hat drei Beinchen. Schaut man auf die abgeflachte Seite mit der Beschriftung, ist das linke Beinchen die Nummer 1 und damit GND (also 0V), das mittlere die Nummer 2 und damit DQ (die Datenleitung) und das rechte Beinchen ist die Nummer 3 und stellt die Versorgungsleitung VCC (3,3V) dar.

Belegung der Pins des DS18B20
Belegung der Pins des DS18B20

In diesem Beispiel schließen wir den DS18B20 mit drei Adern an die 3,3V Versorgungsspannung des Raspberry Pi an. Bei größeren Leitungslängen empfiehlt es sich, für die Versorgungsspannung 5V zu nehmen und den Widerstand von DQ auf eine separate Ader mit 3,3V zu ziehen. Zum Testen reicht dieser Aufbau aber allemal.

So wird der Sensor DS18B20 an die GPIO-Pins des Raspberry Pi angeschlossen
So wird der Sensor DS18B20 an die GPIO-Pins des Raspberry Pi angeschlossen

Die Verkabelung kann entweder fliegend verlötet werden, oder aber (etwas eleganter und einfacher) auf einem Breadboard aufgesteckt werden. Ich tat letzteres, wenn auch wegen akuten Jumperwire-Mangels nicht besonders ordentlich:

Der DS18B20 auf dem Breadboard, verbunden mit dem Rsspberry Pi
Der DS18B20 auf dem Breadboard, verbunden mit dem Rsspberry Pi

Sensordaten abfragen im Linux-Terminal

Jeder Sensor hat eine einmalige Kennung, unter dieser Kennung wird auch ein Geräteordner unter /sys/bus/w1/devices angelegt. In meinem Falle hat der Sensor die Kennung 28-021600bb4dff, daher ist der Geräteordner /sys/bus/w1/devices/28-021600bb4dff. In diesem Ordner befindet sich die Gerätedatei w1_slave. Lässt man sich diese Datei beispielsweise mit cat ausgeben, wird der Sensor abgefragt und die Checksumme, sowie die Temperatur ausgegeben:

Die Ausgabe der Gerätedatei des DS18B20
Die Ausgabe der Gerätedatei des DS18B20

Stimmen beide Checksummen überein, ist das Ergebnis plausibel und hinter der crc steht „YES“. Im Fehlerfall würde dort „NO“ stehen. In der zweiten Zeile wird die Temperatur angezeigt, teilt man diesen Wert durch 1000 kommt man auf die Temperatur in °C, bei mir also 20,125°C.

Das ist eigentlich schon alles. Diese Datei kann man natürlich über Scripte oder Programme auslesen und weiter verwenden.

Sensordaten abfragen unter CODESYS

Seit längerem gibt es ja von 3S die CODESYS Laufzeit für den Raspberry Pi, eine meiner Meinung nach für Privatanwender und Bastler schöne Lösung in die Automatisierung einzusteigen, ohne hohe Ausgaben für „echte“ SPS-Hardware zu haben.

Über CODESYS auf dem Raspberry Pi habe ich schon zwei Artikel verfasst. Im ersten Artikel wird unter anderem erklärt, wie die Laufzeit auf dem Gerät installiert wird und wie eine Verbindung zum Raspberry Pi hergestellt wird, im zweiten geht es eher um die Python-Bibliothek Pymodbus, die die Modbus-Kommunikation zum Beispiel zwischen einem Raspberry Pi und einem Controller mit CODESYS ermöglicht.

Wir benötigen also einen Raspberry Pi mit installierter CODESYS Laufzeit, sowie dem angeschlossenen und funktionierenden Sensor wie oben beschrieben.

Im CODESYS legen wir ein neues Projekt an und wählen als Zielsystem den Raspberry Pi.

CODESYS Projekt anlegen für DS18B20 auf Raspberry Pi
CODESYS Projekt anlegen für DS18B20 auf Raspberry Pi

Nachdem das Programm angelegt ist, baut sich automatisch die Struktur auf und man sieht auch schon den Punkt für 1-Wire (bzw. Onewire).

Zunächst muss eine Verbindung zum Raspberry Pi hergestellt werden, dafür werden per Doppelklick auf den Raspberry die Geräteeinstellungen geöffnet und die IP des Gerätes eingetragen (und die Zugangsdaten, falls nicht zuvor schon einmal geschehen). Wenn die Verbindung grün angezeigt wird, ist alles in Ordnung.

CODESYS verbinden mit dem Raspberry Pi im Device Manager
CODESYS verbinden mit dem Raspberry Pi im Device Manager

Nun kann mit der Konfiguration des 1-Wire Sensors begonnen werden. Per Rechtsklick auf den Eintrag „Onewire“ öffnet sich das Kontextmenü, hier wird über den Menüpunkt „Gerät anhängen“ das Gerät „Onewire_master“ angehängt.

Das Gerät Onewire_master anhängen
Das Gerät Onewire_master anhängen

Auf die selbe Art wird nun noch der Sensor DS18B20 angehängt: Rechtsklick auf Onewire_master, Gerät anhängen, DS18B20 auswählen.

Nun sind alle Geräte vorhanden, die benötigt werden. Der Sensor muss nun noch Parametriert werden, die Gerätekennung muss eingetragen werden. Hierzu öffnet man das Device per Doppelklick und trägt im Reiter „1-wire bus Parameter“ in der Spalte „Wert“ die Kennung ein, die eben schon in der Konsole angezeigt wurde, bei mir also 28-021600bb4dff. Das ganze als String, also in Hochkommata ‚.

Der Sensor DS18B20 wird parametriert, die Gerätekennung wird eingetragen.
Der Sensor DS18B20 wird parametriert, die Gerätekennung wird eingetragen.

Das war eigentlich schon alles, der Sensor sollte nun im Programm benutzbar sein. Den Temperaturwert kann man recht einfach nutzen, indem man den String rTemp des Sensors ausliest und beispielsweise auf eine Variable schreibt. Der Wert rTemp ist ein REAL, die Variable muss also auch den Typ REAL haben.

Der Temperaturwert wird über rTemp ausgelesen.
Der Temperaturwert wird über rTemp ausgelesen.

Im laufenden Programm sieht das ganze dann so aus:

Die Livedaten des DS18B20 werden im laufenden Programm angezeigt.
Die Livedaten des DS18B20 werden im laufenden Programm angezeigt.

Eigentlich recht simpel. Da mehrere Sensoren parallel angeschlossen werden können, kann man so einfach die Temperatur in einem ganzen Haus messen und dank der HTML5-WebVisu von CODESYS 3.5 auch optisch ansprechend im Netzwerk abrufbar machen. Eine Heizungssteuerung wäre natürlich auch ein guter Anwendungszweck.

Raspberry Pi als „Cloud“ oder NAS?

Es geisterte ja heute durch das gesamte Internet und somit auch an mir vorbei: Western Digital plant, eine Vielzahl von Netzwerkspeichern auf Basis einer speziellen WD-Festplatte und einem Raspberry Pi auf den Markt zu schmeißen unter dem klangvollen Namen PiDrive. Das ganze ist derzeit in der Entwicklungsphase bei WDLabs (der aktuelle Stand lässt sich wohl aber in Amerika bereits kaufen) und soll mit OwnCloud ausgeliefert werden.

Ich bin ja ein großer Fan des Raspberry Pi und habe privat einen Raspberry Pi B, B+ und seit neuestem auch einen Raspberry Pi 2 B als Mediacenter. Die Dinger machen sich echt gut, sei es als 24/7 Monitor-Device, als Bastelgerät für SPS-Spielereien oder Modbus-Erweiterung derselben für Aufgaben, die ein Linuxrechner einfach besser hin bekommt.

Allerdings fingen schon beim Lesen der Überschriften bei mir die Warnlichter an zu leuchten: Der Netzwerkadapter (10/100 MBit/s) wird vom USB 2.0-Controller bereitgestellt. USB 2.0 hat eine theoretische Bandbreite von bis zu 480MBit/s, davon bleiben vielleicht so 400MBit/s tatsächlich übrig. Insgesamt können also über LAN und USB etwa 50MByte/s übertragen werden.
Der Ethernet-Port hat eine Übertragungsrate von 100MBit/s, was etwa 12MByte/s entspricht.

Das reicht natürlich. Für die Sachen, die man mit nem Raspberry Pi so macht: Webcamstream, Bastelcomputer, Mediacenter usw.
Wenn es aber darum geht, Daten im lokalen Netzwerk vorzuhalten, sind 100MBit/s nicht besonders schön. Erst recht nicht, wenn man beispielsweise das Netzlaufwerk auf einem anderen Rechner einbinden will. Da sind die Kapazitätsgrenzen schnell erreicht, vor allem, wenn eventuell zwei Rechner gleichzeitig Daten haben wollen. Wenn man Sachen aus dem Netz läd, ist sowas zu verschmerzen (da wären 100MBit/s ja fast das obere Ende), aber das will man ja eigentlich nicht auf Geräten haben, die im internen Gigabit-LAN Daten vorhalten sollen.

Klar, das Ding kostet auch nicht viel, da kann man nicht viel verlangen. Ich würde aber sagen, dass es einfach das falsche Gerät ist, um ein NAS oder eine Cloud wie OwnCloud bereitzustellen, auf der mehr als nur ein paar MP3 und Urlaubsfotos gespeichert werden (von der Datensicherheit mal abgesehen). Es gibt inzwischen viele andere Anbieter günstiger Mini-Computer, die dann auf andere Bereiche spezialisiert sind.

via: t3n, Heise

Bild: Owncloud