IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.
Abseits der Technik — persönliche Gedanken, Erlebnisse und alles, was nicht in die anderen Kategorien passt.
Ich habe grade eine E-Mail von unserem Vorsitzenden des Ortsausschusses Todenfeld – Rheinbach in meinem Postfach. Er leitet eine Warnung bezüglich einer Sichtung einer Großkatze weiter.
Öhm, also… Großkatze? Ich bin mal gespannt.
Fragen? Einfach melden.
Ich selbst habe kein Problem mit Spinnen – das ist aber beim Rest meiner Familie nicht immer gegeben. Wie auch immer: Ich bilde mir ein, die meisten Spinnenarten, die hier in NRW so im Garten vorkommen, schon mal irgendwann gesehen zu haben. In den letzten Wochen finde ich aber immer mal wieder ein paar – für meinen Eindruck – recht große Exemplare, wenn auch bisher immer nur tot.
Eines habe ich mal fotografiert und zum Größenvergleich neben eine 10-Cent-Münze gelegt. Die AI sagt, dass es eine Wolfsspinne ist. Da würde ich aber spontan eher nach Nordamerika schielen. Kurz: Ich habe keine Ahnung. Fällt jemandem von euch etwas ein? Was ist das für eine Spinne?!
Fragen? Einfach melden.
Ich bin beim sehen fast vor Lachen umgefallen. Nur gut, dass ich zwischendurch auch weinen musste. So hat es sich etwas ausgeglichen. Viel "Spaß"..
Fragen? Einfach melden.
Klimawandel… Joar, den gibt es. Das wir Menschen dran schuld sind wissen wir ebenfalls. Im Grunde ist es uns allen schon seit Jahren klar. Wir machen nur so schön die Augen davor zu.
Probleme zu ignorieren hilft leider nicht immer (ok in der IT geht es hin und wieder *lach*)… Ich möchte hier auf einen Vortrag verweisen, welcher es für normale Menschen, fachlich belegt zusammenfasst. Vorsicht youtube!
Ich habe seit dem Video schlechte Laune :-/
Fragen? Einfach melden.
Es ist wieder der System Administrator Appreciation Day 2022. Schaut doch einmal bei euren IT Menschen vorbei und freut euch mit ihnen.
In diesem Jahr möchte ich zu einer netten kleinen Präsentation von eaton verlinken.
https://www.eaton.com/explore/c/eaton-what-does-an-i?x=bevc72
Viel Spaß!
Fragen? Einfach melden.
Auf irgendeinem CCC Event bin ich über eine lustige Projektidee einer jammernden Pflanze gestoßen. Die hat mir und auch meiner größeren Tochter so gut gefallen, dass wir sie zusammen nachbauen wollten.
Ein kleines Gerät misst den Feuchtigkeitsgehalt der Blumenerde. Ist der Wert zu trocken, spielt ein MP3-Player eine Audiodatei ab. Ein Bewegungsmelder sorgt dafür, dass die Pflanze sich nur beschwert, wenn auch jemand da ist. Ist die Erde trocken und es wird eine Bewegung erkannt, jammert die Pflanze los.
Da es das erste Projekt dieser Art für meine Tochter ist, sollte es übersichtlich und einfach bleiben. Ein Arduino Nano (fast die gleichen Möglichkeiten wie der UNO, aber deutlich kleiner), ein DFPlayer-Modul als MP3-Player, ein HC-SR312 Bewegungsmelder und ein kapazitiver Feuchtigkeitssensor.
Gestartet haben wir mit einem Breadboard, um die Verschaltung Modul für Modul zu setzen und die Ansteuerung mit dem Arduino anhand der Beispiele zu testen. Beim DFPlayer haben wir per TTS Texte in MP3s umgewandelt und auf der SD-Karte im Ordner mp3 gespeichert. Diese werden zufällig abgespielt, wenn die Erde zu trocken ist und eine Bewegung erkannt wurde.
Als die Verschaltung zusammen mit dem Code funktionierte, haben wir mit KiCad eine Platine designt und fertigen lassen. So hat man weniger Kabelsalat und alles ist platzsparend aufgehoben.
Das Gehäuse haben wir in FreeCAD designt und mit dem 3D-Drucker gedruckt. Die Teile sind mit einem Tropfen Sekundenkleber fixiert.
Das Teil steckt in der Blume und meldet sich zuverlässig, wenn es Zeit zum Gießen ist. Da es von den MP3s auf dem Player abhängt, was die Pflanze „sagt“, sind lustige Reaktionen garantiert. Die Pflanze kann dich im Vorbeigehen voll jammern, um Wasser betteln oder anfangen zu schimpfen.
Meine Tochter wird nach dem Projekt nicht alles alleine wiederholen können, aber die einzelnen Schritte sind klar. Wie so ein Gerät entsteht, was nötig ist. Schnell findet man Verbesserungsmöglichkeiten: Den Feuchtigkeitssensor von der Elektronik trennen, mit einem NodeMCU ESP8266 WLAN-Statusdaten senden, oder mit Li-Ion-Akkus und einem BMS vom Stromnetz unabhängig werden.
Für den DFPlayer wird die DFRobotDFPlayerMini Library benötigt (lokal unter ~/Arduino/libraries ablegen).
#include <Arduino.h>
#include <SoftwareSerial.h>
#include <DFRobotDFPlayerMini.h>
/* --- Pins ---------------------------------------------------- */
const uint8_t PIN_DF_RX = 10;
const uint8_t PIN_DF_TX = 11;
const uint8_t PIN_PIR = 7;
const uint8_t PIN_SENSOR = A0;
/* --- Parameter ----------------------------------------------- */
const int schwellwert = 380;
const unsigned long PLAY_COOLDOWN_MS = 15000;
const uint8_t TRACK_JAMMERN = 1;
/* --- Objekte ------------------------------------------------- */
SoftwareSerial dfSerial(PIN_DF_RX, PIN_DF_TX);
DFRobotDFPlayerMini dfPlayer;
/* --- Laufzeitstatus ------------------------------------------ */
unsigned long lastPlay = 0;
/* ------------------------------------------------------------- */
void setup() {
pinMode(PIN_PIR, INPUT);
Serial.begin(115200);
dfSerial.begin(9600);
Serial.println(F("Initializing DFPlayer ..."));
if (!dfPlayer.begin(dfSerial)) {
Serial.println(F("DFPlayer init failed"));
while (true);
}
dfPlayer.volume(20);
dfPlayer.outputDevice(DFPLAYER_DEVICE_SD);
dfPlayer.EQ(DFPLAYER_EQ_NORMAL);
dfPlayer.setTimeOut(500);
Serial.println(F("DFPlayer Mini online"));
}
/* ------------------------------------------------------------- */
void loop() {
/* DFPlayer Events immer zuerst abholen */
if (dfPlayer.available()) {
handleDFPlayerEvent(dfPlayer.readType(), dfPlayer.read());
}
int messwert = analogRead(PIN_SENSOR);
bool bewegung = digitalRead(PIN_PIR) == HIGH;
bool trocken = messwert > schwellwert;
unsigned long now = millis();
if (trocken && bewegung) {
if (now - lastPlay >= PLAY_COOLDOWN_MS) {
Serial.println(F("Bewegung + Erde trocken -> spiele Sound"));
dfPlayer.play(TRACK_JAMMERN);
lastPlay = now;
}
} else {
logStatus(trocken, bewegung, messwert);
}
delay(100); // leichte Entlastung – kein Logik-Delay
}
/* ------------------------------------------------------------- */
void logStatus(bool trocken, bool bewegung, int messwert) {
if (!bewegung && trocken) {
Serial.print(F("Keine Bewegung, Erde trocken: "));
} else if (bewegung && !trocken) {
Serial.print(F("Bewegung, Erde ok: "));
} else if (!bewegung && !trocken) {
Serial.print(F("Keine Bewegung, Erde ok: "));
}
Serial.println(messwert);
}
/* ------------------------------------------------------------- */
void handleDFPlayerEvent(uint8_t type, int value) {
if (type == DFPlayerPlayFinished) {
Serial.print(F("Track "));
Serial.print(value);
Serial.println(F(" beendet"));
}
}
3D-Druck: STL Gehäuse | STL Deckel
Platine: Gerber-Dateien
Optional: Breadboard mit Kabeln, Multimeter, Lötkolben
Fragen? Einfach melden.
Datenschutz ist oft ein sehr langweilige und oft schwer verständliches Thema. Ein Bekannter (danke dir) hat mir den folgenden Link zukommen lassen:
https://www.datenschutz-leicht-erklaert.de/#videos
Die Link verweist einer Initiative vom Berufsverband der Datenschutzbeauftragten Deutschlands (BvD) e.V. mit dem Namen Datenschutz geht zur Schule. Die Zielgruppe sind dabei Schüler:rinnen um ihnen das Thema Datenschutz näher zu bringen. Dazu gibt es kurze, Themen bezogene Videos, welche wirklich gut verständlich sind.
Vielleicht ebenfalls etwas für euch?
Fragen? Einfach melden.
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:
<?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.
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 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
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).
Empfohlene Werte nach verfügbarem RAM:
memorysize = 500memorysize = 250readfactor = 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.
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
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.
Lieber Thorben,
vielen Dank, dass du uns so lange ertragen hast. Du hast unsere Arbeit leichter und bunter gemacht. Ohne dich hätten wir sicher schon die Raufasertapete mehr als einmal von der Wand gefressen.
Vielen Dank für deine Unterstützung in technischer und menschlicher Weise! Wir werden dich NIE vergessen!
Liebe Grüße
Die zwei „Dicken“
Den folgenden Link hat mir gerade ein Arbeitskollege gesendet. Absolut gut gemacht, darf man aber halt nicht schauen, wenn man Spanisch kann 🙂
Gott ist das gut und gleichzeitig so schlimm.
Fragen? Einfach melden.
© 2026 -=Kernel-Error=- — RSS
Theme von Anders Norén — Hoch ↑