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.

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.

Raspberry Pi als Spotify-Client, reloaded: Pi MusicBox

Nachdem despotify nicht mehr läuft, war es lange ruhig um die Idee. Bis ich vor einigen Tagen über Pi MusicBox gestolpert bin. Und, was soll ich sagen: Läuft wie ‘ne 1. Und:

  • hat dazu einen Webserver gleich mit an Board, der ein (mobiltaugliches) Interface (in iPhone-Optik) raushaut
  • hat last.fm-Support mit dabei
  • unterstützt iTunes-Streaming und Wifi
  • zumindest auf den ersten Blick ist es absolut transparent, woher der Track kommt. Sprich: Man hat alle Quellen in einer Suche vereint
  • klingt in 320kbps über HDMI an meinem Yamaha absolut bombe! 🙂

Basiert auf Mopidy, was ich ebenfalls noch nicht kannte. Mopidy kann wohl auch Soundcloud, was ich im Pi-Interface (und auch im Config-File) nicht sehe.

Was mir fehlt, ist die Möglicheit, das Gerät aus dem Webinterface heraus runterzufahren. Und, gut zu wissen, der SSH-Zugang ist nicht pi/raspberry, sondern root/musicbox… Shutdown dann per “shutdown -h now”, wie gehabt

[UPDATE] Über USB-WLAN (der Stick zu 7,77 € auf Ebay oder 8,84 € auf Amazon) funktioniert das ziemlich out-of-the-box, allerdings musste ich in /etc/network/interfaces die Zeile auto wlan0 einkommentieren (Quelle). Den WLAN-Key muss man übrigens ohne Bindestriche oder Leerzeichen hinterlegen.

Raspberry Pi: Probleme mit USB-Tastatur und LAN

Wer seinen Raspberry grundsätzlich eingerichtet hat, will vermutlich bald in’s Internet. Bei mir stellte sich gerade das Problem, dass meine Tastatur nicht mehr geht, wenn ich LAN einstöpsel… keine Ahnung, woran das liegt, irgendwelche Vorschläge? Vielleicht zieht sie zu viel Strom oder so.

Aber wie dem auch sei: LAN-Kabel wieder ab. Über “sudo raspi-config” öffne ich den Config-Screen und aktivere den SSH-Server. LAN-Kabel wieder dran, Tastatur ab. Über die Heimnetzwerk-Übersicht meines Alice-Routers (ok, über Umwege geht es auch über’s Terminal) finde ich heraus, dass das Rasperry (Netzwerkname “raspberrypi”) die IP 192.168.1.53 hat. Von meinem Macbook aus rufe ich im Terminal “ssh pi@192.168.1.53” auf (und bestätige beim ersten mal den Fingerprint), und gebe das von mir nicht geänderte Passwort “raspberry” ein. Schon bin ich auf dem System, und kann von hier aus so weitermachen, wie ich es eigentlich über die USB-Tastatur machen wollte.

Stellt sich raus: Das muss ich erst mal gar nicht 🙂 Ein “ping www.google.de” funktioniert direkt. DHCP muss im Router natürlich aktiviert sein, sonst wäre hier manuelle Konfigurationsarbeit nötig. Trotzdem ist es nett zu wissen, dass man so einfach per SSH draufkommt, denn schliesslich will man ja irgendwas machen können im LAN, und ohne Tastatur wird das knifflig. Außerdem muss mein Fernseher nicht mehr eingeschaltet sein, und ich kann auf dem Sofa sitzen^^