Pi Hole: “Disable Blocking” funktioniert nicht

Ich habe meinen Pi Hole auf einem bereits aufgesetztem Apache installiert (für meinen Slow Movie Player). Das ist laut How-To möglich:

  1. Run the Pi-hole install. When you get to “Do you wish to install the web server” select “Off”.
  2. Finish the Pi-hole installation process. Do not panic.
  3. Run “sudo usermod -a -G pihole www-data”
  4. Install “sudo apt install php-sqlite3”
  5. At a minimum, restart Apache “sudo service apache2 restart” or reboot the Pi.
  6. Enjoy.

und das ist auch so – aber 🙂 Wenn man das Pi Hole aktualisiert, muss man Schritt 5 wiederholen, sonst funktioniert irritierenderweise das temporär disablen nicht. Kein Fehler in der Konsole, keine Fehlermeldung, nur ein Error im Debug Log, dass der lighttpd nicht läuft.

Bluetooth Soundausgabe auf Raspberry Pi 3B (nicht 3B+)

Es ist 1 wenig tricky, Soundausgabe via Bluetooth auf einem pi3b (b, nicht b+!) ans Laufen zu bekommen. Und ich spreche hier von “auf der Kommandozeile”, auf dem Desktop habe ich das imho irgendwann mal recht schnell zusammengeklickt.

Warum ist das so knifflig? Erstens: Weil Raspberry Pi OS für den 3B, Stand heute, auf Debian 11/”Bullseye” basiert – was weder bei Release des 3B so war (da war es 8/”Jessie”, immerhin 3 Major Versions zurück!), noch die aktuellste Version ist (das wäre dann 12/”Bookworm”). Wikipedia behauptet zwar, auch 12/”Bookworm” wäre kompatibel, aber der Raspberry Pi Imager bietet für den 3B nur 11/”Bullseye” an. Es gibt auch kein “Tested image” von 12/”Bookworm” für den 3B, und meiner bootet dann auch mit keinem der dort angebotenen (oder findet vielleicht auch nur das WLAN nicht, was in meinem Fall auf dasselbe rauskommt).

(Diese UNSITTE, eingängige Nummerierung durch völlig willkürliche Strings zu ersetzen! Looking at you, macOS. Apropos Macs, auch schön: Auf meinem, zugegebenermaßen knapp 13 Jahre alten MacBook kann ich den Raspberry Pi Imager nicht mehr nutzen! Weil gegen eine inkompatible Version von qt kompiliert, wenn ich das richtig verstehe. Aber ich schweife ab.)

Man findet also drölf Tutorials, aber keines davon passt (es gibt sogar Stimmen, die sagen, das geht auf dem 3B gar nicht). Also schreibe ich halt noch eines 🙂 Und zwar explizit für Debian 11/”Bullseye”, bzw. “Raspberry Pi OS (Legacy, 32-bit) Lite (Veröffentlicht: 2023-12-05)”, wie es im Imager genannt wird – was laut lsb_release -a aber dasselbe ist. Achtung: Das System nicht upgraden (everybody says that)! Update: Da hatte ich in einem der Foren gelesen, und auch selber den Eindruck, dass ich nach einem apt upgrade keine Verbindung mehr bekam – jetzt wollte ich noch dieses Detail debuggen und lösen, da tritt es nicht mehr auf. Keine Ahnung.

Zuerst probiere ich stumpf, ob es vielleicht schon geht (ich überspringe hier der Übersichtlichkeit halber Scanning, Trusting, Pairing):

Das Internet ist voll von entsprechenden Meldungen mit n+1 Ursachen. Es hilft zur Eingrenzung, in einem zweiten Fenster btmon zu starten (erfordert sudo). Dort sehe ich:

= bluetoothd: src/service.c:btd_service_connect() a2dp-sink profile connect failed for FC:58:FA:3D:32:12: Protocol… 5.320743

“a2dp”? Ist quasi Audio-über-Bluetooth. Was Sinn ergibt, denn FC:58:FA:3D:32:12 ist ein Lautsprecher, ein “sink” von Audio. Wie bekommt man so ein “sink profile”? Über die Installation von PulseAudio oder PipeWire. Quasi das zweite Problem, denn beide haben ihre eigene Fan-Base (bzw. ihre eigenen Probleme, aus Sicht des jeweils anderen Lagers) und ihre eigenen Tutorials. Wie auch immer, die oben verlinkte Seite sagt, man solle PulseAudio verwenden:

PulseAudio is the default audio server in Debian. Unless you know what you’re doing, you probably want to follow these instructions

, und dieser Post sagt das auch. Also:

Und: Geht!

Die auf im Post genannten Module benötige ich nicht. Kurzer Test:

Auch das tut (haha: “tut”! Wie in “Sound”! TUUT TUUT!? Ich finde alleine raus …)

PS, das o.g. zusammenzustellen, hat mich einige Versuche mit frischen Images gekostet. Hier einige weitere Learnings aus diesen Versuchen:

  • Bei einem der Versuche hat dann der Lautsprecher angefangen, eine dritte Dimension von Problemen zu machen: Er wollte einen PIN haben 🙂 Zu sehen war das aber auch nur in btmon. Jedes Gerät kann hier seinen eigenen Unsinn veranstalten. Es kann dann helfen (wie gesagt, inzwischen benötige ich es nicht mehr), bluetoothctl mit einem anderen Agent zu starten. Die Idee ist, dem Gegenüber zu sagen, dass man keinen PIN eingeben kann, um in einen anderen Pairing-Modus zu gehen. Oder dass man einen eingeben kann, um den entsprechenden Prompt zu triggern. Bei mir half bluetoothctl --agent KeyboardDisplay, was zwar überhaupt nichts triggerte, aber dann ging es. Hier alle Agents.
  • service bluetooth status zeigt den aktuellen Status; dabei ist “active (running)” (in grün) gut, etwaige Fehlermeldungen (in Rot), wie bspw. “Sap driver initialization failed” oder “Failed to set privacy: Rejected” sind irrelevant. Mein Speaker tut (…) trotz dieser Meldungen.
  • busctl tree org.bluez zeigt die Devices:

(die beiden untersten Zeilen sieht man nur, wenn das Gerät verbunden ist; es können also sowohl bekannte, wie auch verbundene Devices angezeigt werden)

HTH!

Slow Movie Player: Casablanca

(Vorab: Anders als sonst linken dieses mal alle Bilder zu einer größeren Version)

Über diese News auf raspberrypi.com (und den zugehörigen Medium-Post) bin ich auf dieses Repo gestoßen (Fork). Was ich so cool fand, dass ich es nachgebaut habe, und just während ich diesen Eintrag tippe, steht meine Version vor mir und spielt Casablanca – in 1-Sek/24-Frames-Sprüngen alle 5 Minuten 🙂

Und eigentlich gibt es dazu nicht so viel zu zu sagen, das ist alles ziemlich straight forward. Ein paar Details wollte ich aber festhalten:

  • der Pi wird von hinten, das Display von vorn mit Heißkleber an die Rückwand des Rahmens geklebt
  • ergänzt wird der Rahmen um ein Passepartout und “Museumsglas” von arsvendo.de. Das Ikea-Passepartout habe ich genutzt, um das Display einzufassen (mit Aussparungen für den Heißkleber):

  • Casablanca ist natürlich eigentlich 4:3. Um mir die schwarzen Balken zu ersparen, habe ich ihn mit HandBrake und folgenden Settings gecroppt (tatsächlich habe ich auch Intro/Outro abgeschnitten, Ton/Subtitles/Kapitel weggeworfen, etc. Hier geht es nur ums Cropping, zum Rest siehe Wiki):

Und das funktioniert bildausschnittstechnisch meistens ziemlich gut:

MicroPython vs. HTTP Response Headers

Der Raspberry Pi Pico W ist pure Magie. Ein Microcontroller, in Python zu steuern, mit WLAN on board 😍 Super einfach, damit irgendwas im Netz zu machen – essentiell für IoT, looking at you, Arduino.

(Aber man muss|Außerdem kann man) viel über MicroPython lernen. Zum Beispiel, wie urequests Response-Header parst: Als Key/Value. Das ist uncool, da es durchaus Header gibt, die doppelt kommen können und sollen:

The optional replace parameter indicates whether the header should replace a previous similar header, or add a second header of the same type. By default it will replace, but if you pass in false as the second argument you can force multiple headers of the same type. For example:

Sagt PHP (replace Parameter).

The Set-Cookie HTTP response header is used to send a cookie from the server to the user agent, so that the user agent can send it back to the server later. To send multiple cookies, multiple Set-Cookie headers should be sent in the same response.

Sagt Mozilla.

Imho nicht unbedingt unseriöse Quellen, aber für MicroPython ist das trotzdem kein schlagendes Argument; Header duplicates werden weiterhin nicht unterstützt werden. Siehe meine längliche Diskussion ab hier.

Es gibt aber einen Workaround, und der ist imho nicht offensichtlich: Man kann nämlich urequests.post() mit einem Parameter parse_headers aufrufen, der erstmal ein Boolean ist – aber auch eine Callback-Funktion sein kann:

Das Fragment (ich hoffe, ich habe auf die Schnelle nichts vergessen) printed alle Cookies. HTH.

Uhrzeit auf dem Arduino

Wer auf einem Arduino die aktuelle Uhrzeit haben möchte, hat im Wesentlichen drei Optionen. Im Folgenden ein Überblick der Vor- und Nachteile, ohne Anspruch auf Vollständigkeit.

PS: Dieser Post ist eine Karteileiche, insofern kann ich (inzwischen) fast nichts mehr dazu sagen, aber vielleicht helfen die Links ja der einen oder anderen.

DS3231

Ein DS3231-Modul ist quasi eine klassische Uhr: Quarzbasiert, batteriebetrieben, ohne Funk. Beim 3231 wacht ein Temperatursensor darüber, dass eventuelle Abweichungen kompensiert werden (im Gegensatz zum DS1302, DS1307, …). Das Buzzword zu den genannten Modulen lautet “Real Time Clock” (RTC), und es gibt sie bsplw. von Adafruit oder auf Ebay aus China.

Der Vorteil ist offensichtlich: Alles in einem. Anschließen, auslesen, fertig. Allerdings wird die Zeit nur ein mal “gestellt”, und zwar beim Kompilieren. Ist die Batterie leer, oder die Gangabweichung über die Monate (Jahre?) zu groß, oder die Zeitumstellung wird nicht berücksichtigt, oder oder oder, heißt es neu zu kompilieren. Diese Lösung scheint mir die am wenigsten autarke zu sein, deshalb habe ich mich da nicht weiter mit beschäftigt.

NTP

Die für einen Softwareentwickler naheliegende Lösung ist das Auslesen eines Zeitservers. Dazu benötigt man eine Verbindung zu so einem Server, also vermutlich LAN oder WLAN. Die kostengünstigste Version (die praktischerweise auch sehr klein ist) für den Arduino lautet ESP8266, auf Ebay bekommt man welche für << 2€ inklusive Versand aus China 😄.

ABER: Die sind schon deutlich unübersichtlicher zu verwenden! Es gibt aktuell fast zwanzig verschiedene Versionen (plus Abversionen), und sie erfordern 3,3V, während die meisten (gängigen) Arduinos auf 5V basieren. Sie sind nicht mal originär für den Arduino, sondern standalone Bausteine! Es gibt Adapter, Anleitungen, etc.; man muss sich halt dieser Komplexität bewusst sein. Außerdem vermeidet man zwar das (erneute) Stellen der Uhrzeit, ist aber abhängig von genau diesem einen WLAN mit genau diesem Passwort.

DCF77

DCF77 ist das kluge Wort für eine Funkuhr. Es gibt entsprechende Module bei Pollin, Reichelt, Conrad, ELV, … (hier ein Vergleich), leider nicht aus China 🙃. Ich habe von früher noch den hier, der kann auch 5V. Das Auslesen ist nicht trivial, dafür ist man nur so wirklich autark.

Was heißt also “nicht trivial”? Nun,

  • das Signal an sich wird sekundenweise binär übertragen, aber für die Dekodierung gibt es Libraries (aktuell drei offizielle). Man benötigt mindestens eine volle Minute, bis man ein mal alle nötigen Bits empfangen hat – und das unter Idealbedingungen!
  • die verschiedenen Module unterstützen unterschiedliche Spannungen, was man bei der Planung berücksichtigen muss.
  • um ein sekundenbasiertes Signal zuverlässig zu verarbeiten, muss man zuverlässig eine Sekunde erkennen. Dazu benötigt man einen Arduino mit Quarz (halt wie in einer Uhr), die meisten haben aber keinen. Den Pro Mini gab es in einer 5V-Version (damit fällt das Modul von Pollin schon mal raus) mit Quarz, aber den Pro Mini gibt es offiziell nicht mehr… auf Ebay gibt es aber noch welche für ebenfalls deutlich unter 2€ aus China.
  • die Module sind grundsätzlich störanfällig; die Antenne sollte waagerecht ausgerichtet sein, die Leitungen kurz, Röhrenbildschirme weit weg, Z-Dioden helfen. Das macht das Auslesen des Signals nicht schneller, und das Debugging entsprechend langwierig. Im o.g. Vergleich wurden bis zu 20 Minuten gemessen, bis das Signal erkannt war!

PS: Die Library von Udo Klein rühmt sich, besonders widerstandsfähig gegen Störsignale zu sein.

hf!

Pi-hole: Reset stats

Man kann die Fritzbox konfigurieren, dass sie ihre DNS-Auflösung über den Pi-hole macht. Man kann die Fritzbox aber auch so konfigurieren, dass sie den Pi-hole mittels DHCP als DNS-Server im LAN bekannt macht – Danke, Johann. Dann (und nur dann) werden Clients korrekt aufgelöst, statt dass die Fritzbox der einzige Client ist.

Das wäre so einer der Fälle, in dem man evt. die Statistik des Pi-hole zurücksetzen möchte:

Update: Oooder man geht in der Admin Console auf SettingsSystemFlush logs 🙃

Raspberry Pi Stromversorgung

Ich habe einen 3B hier, der vermehrt “Under-voltage detected” (Code 0x00050005) meldet – dabei aber (als einziges Gerät!) über einen wertigen USB-Hub direkt am Stromnetz hängt. Der Hub hat auch schon früher Raspberrys versorgt, darunter den eigentlich hungrigeren 3B+. Was also ist los?

Es kann natürlich ein Fehlalarm, bzw. ein defekter Pi sein. Vermutlich eher unwahrscheinlich 🙂 Es kann auch der Hub sein; tatsächlich sind minderwertige Netzteile oft ein Grund für (alle möglichen!) Probleme mit dem Pi. Ich hoffte allerdings auf das Kabel; ein Punkt, den man häufig vergisst. Nicht umsonst gibt es explizite “Quick Charging”-Kabel.

Also: Gegenprobe. Weitere Kabel, sowie das “originale” Netzteil (Danke, Nathan!) statt des Hub ausprobiert. Stellt sich raus:

  1. es scheint doch am Hub zu liegen
  2. das originale Netzteil liefert 5.1V statt den im USB-Standard spezifizierten 5V

In anderen Worten: Die Foundation bescheißt. So funktioniert natürlich kein standard USB Supply 🙄  Aber wie auch immer. Was das Ganze blogbar macht, ist ein kleines Skript, das ich hier gefunden und während der Tests genutzt habe:

Es stresst den Pi so sehr, dass er mit einigen der Kabel nach ein paar Schleifendurchläufen hart abgestürzt ist! Mit dem originalen Netzteil hatte ich keine Probleme (wobei da das Kabel fester Bestandteil ist). Also: Das obige Skript ist ein guter Lasttest für einen Pi.

RetroStone

Hab die Tage meinen RetroStone erhalten – witzige Geschichte, auf dem Paket klebte Zoll-Zettel usw., aber es lag einfach im Briefkasten. Egal, hier die bisherigen Erkenntnisse, die bei Bedarf ergänzt werden:

  • Out of the box ist keine Software installiert! Man muss sich RetrOrangePi in der Version “RetroStone Pi” runterladen und installieren
  • Spiele werden bspw. per Netzwerk installiert: Per smb verbinden, Volume rom, darin liegt pro Emulator ein Unterordner, wo die reinkommen
  • Der Ordner für den klassischen Game Boy ist nicht gameboy, sondern gb
  • Emulatoren erscheinen nur im Menü, wenn ihr ROM-Ordner mindestens eine Datei enthalten (einige enthalten deshalb Dummydateien)
  • Emulationstation (oder die ganze Konsole) müssen neu gestartet werden, um die Liste der vorhandenen Spiele zu aktualisieren: Start → Quit (mit Gelb) → …
  • Die Tastenkombi, um ein Spiel zu verlassen: Select+Start
  • Startet er, aber fährt nicht (mehr) hoch, mal testweise an Strom anschließen

tbc

(Runeaudio|moOde|Volumio) mit Hifiberry Amp2 auf Raspi 3B+

Setup: Ein Hifiberry Amp2 auf einem Raspberry 3 B+.

Frage: Welches OS nutzt man jetzt? Laut Internet stehen Volumio, RuneAudio und moOde. Alle drei basieren auf demselben Ursprungsprojekt, also ene mene muh:

Rune:

None of the existing Rune images will work on the new Pi 3B+.

  • Es gibt zwar einen (Stand heute; Tendenz steigend) 48 Seiten langen Thread zu einer “Beta”- (die sind alle beta, so what) Version aus Februar 2017, mit “Ich habe diese Datei geändert”, “Ich jenes Setting auskommentiert” – also das macht schon mal nicht viel Hoffnung… und tatsächlich: 0.4-beta_20170229 funktioniert auch nicht.

Also moOde:

  • muss kompiliert werden, direkt auf dem Pi, unter Raspbian Stretch Lite in der Version vom 13.3.2018 – “No other release is guaranteed to work.” 🙄 Die aktuelle Version ist vom 18.4.2018, aber ich habe die “alte” noch Rum liegen.
  • Also: 13.3.2018 installieren, starten, /boot wird zum Glück automatisch vergrößert, moOde benötigt mindestens 2.5GB. Dann:
    1. sudo wget -q http://moodeaudio.org/downloads/mos/mosbuild.sh -O /home/pi/mosbuild.sh
    2. sudo chmod +x /home/pi/mosbuild.sh
    3. sudo ./mosbuild.sh
    4. warten. Lange. Man bekommt keinerlei Fortschrittsanzeige. Und auch keinerlei Erfolgsmeldung; irgendwann ist der Pi halt aus 🙄
  • Ein Neustart zeigt:
    • Die Installation war tatsächlich erfolgreich
    • das UI ist Mist, bzw. nicht “mobile first” (was ja ok wäre), sondern eher ein “mobile only”
    • Lautstärke hängt bei 0%, lässt sich auch nicht ändern

Angesichts des UI habe ich dann auch keine Lust, mich weiter damit zu befassen.

Also Volumio:

  • Installation problemlos; als Device wird direkt “snd_rpi_hifiberry_dacplus” zur Auswahl gestellt, das ist korrekt:

If the software you’re using doesn’t provide the Amp2 as an output option, you should use the HiFiBerry DAC+ driver as the Amp2 is basically a DAC+ with an integrated power stage.

  • Aber: Lautstärkeregelung funktioniert wieder nicht!? Dieses mal hängt sie auf 100% 😐
  • Das UI hat ebenfalls Probleme: Es ist webbasiert und startet im Chromium, der dabei schon mal eine Fehlermeldung bringt, man hätte beim letzten mal nicht alle Tabs geschlossen. Hilfetexte sind hin und wieder leer. Ein WLAN, das auf 2.4 und 5 GHz sendet, wird doppelt angezeigt (ja, das liegt primär an den Einstellungen im Router, aber andere UIs bekommen das auch hin)
  • Es gibt “Plugins”, die sich aus dem Webinterface heraus installieren lassen – theoretisch. Das Plugin für TouchPanels etwa kann man nicht installieren, ohne vorher auf der Kommandozeile tätig zu werden. Warum? Das scheint mit 2.444 behoben zu sein!
  • Hat man das Touchpanel-Plugin installiert, bootet man aber automatisch in das Webinterface, wie kommt man dann in die Kommandozeile? Etwa per SSH, das aktiviert werden muss: Eine Datei “ssh” in der “boot”-Partition anlegen, oder unter http://volumio.local/dev/. User/Passwort sind volumio/volumio

Aber zurück zur Lautstärkenregelung: Laut Entwickler vom Hifiberry ist das ein Problem von Volumio, zumal alsamixer funktioniert. Und tatsächlich: Das Problem ist (indirekt) das UI. Man muss unter “Playback Options” → “Volume Options” → “Mixer Control Name” von “Analog” auf “Digital” wechseln und speichern. Das Pop Up a la “Alles gespeichert und neu gestartet” muss man ignorieren und den Pi neustarten.

Dann geht’s.