Vor einiger Zeit hatte ich schon einmal einen Artikel zum Thema Luftraumüberwachung mit Flightradar24 geschrieben. An der eigentlichen Vorgehensweise der Installation und der einzusetzenden Hardware hat sich nichts gravierend geändert.
Der Befehl zur Installation des entsprechenden Pakets setzt jetzt allerdings SSL voraus.
Ich habe mich allerdings inzwischen für einen stärkeren Empfänger der Firma Nooelec mit RTL2832U/R820T2-Chip entschieden, was ein wenig mehr Reichweite bringt.
Standort sichtbar machen
Heute möchte ich zeigen, wie man auf der lokalen Karte den Standort der Station als Punkt markiert und Radien im Abstand von 50 NM um die Station einzeichnet (siehe Screenshot).
lokale Darstellung der empfangenen Flugzeuge
Hierfür ist es nötig die Konfigurationsdatei /etc/dump1090-mutability/config.js entsprechend anzupassen. Dazu werden die Einträge wie folgt geändert:
alte Konfiguration
// -- Map settings ----------------------------------------
...
// Default center of the map.
DefaultCenterLat = 45.0;
DefaultCenterLon = 9.0;
...
SiteShow = false; // true to show a center marker
SiteLat = 45.0; // position of the marker
SiteLon = 9.0;
SiteName = "My Radar Site"; // tooltip of the marker
...
// -- Marker settings -------------------------------------
...
SiteCircles = true; // true to show circles (only shown if the center marker is shown)
// In nautical miles or km (depending settings value 'Metric')
SiteCirclesDistances = new Array(100,150,200);
...
Unter DefaultCenterLat und DefaultCenterLon trägt man nun die Koordinaten der Empfangsstation ein, um die Karte bei Aufruf auf den entsprechenden Standort zu zentrieren. Die gleiche Vorgehensweise erfolgt unter SiteShow. Hierbei muss die Vorgabe jedoch noch von false auf true geändert werden. Die Radien legt man unter SiteCircles fest. In meinem Fall 50, 100 und 150 NM.
neue Konfiguration
// -- Map settings ----------------------------------------
...
// Default center of the map.
DefaultCenterLat = 51.44871;
DefaultCenterLon = 11.98762;
...
SiteShow = true; // true to show a center marker
SiteLat = 51.44871; // position of the marker
SiteLon = 11.98762;
SiteName = "My Radar Site"; // tooltip of the marker
...
// -- Marker settings -------------------------------------
...
SiteCircles = true; // true to show circles (only shown if the center marker is shown)
// In nautical miles or km (depending settings value 'Metric')
SiteCirclesDistances = new Array(50,100,150);
...
Smart Homes sind in aller Munde. Bei Neubauten sowieso, aber auch bestehende Immobilien werden gerne zu so genannten Smart Homes umgerüstet. Den großen Markt teilen sich natürlich kommerzielle Anbieter, aber gerade auf der Softwareseite konkurrieren auch freie und open source Software um die Kunden. Die bekanntesten Teilnehmer im open source Bereich sind FHEM, OpenHAB und Home Assistant (früher bekannt als hass.io).
Diese Software soll verschiedene smarte Geräte vereinen, so dass sie alle unter einer Haube stecken. Anstatt jeweils eine Anwendung für die Heizung, das Licht und die Energieversorgung zu verwenden, soll die Software übergeordnet sein. Sie bildet damit die Schnittstelle zwischen den Geräten und mir.
Ich möchte mein Haus mit dem Home Assistant smart machen, bzw. einige der vorhandenen Komponenten dort einbinden. In diesem Artikel möchte ich zunächst auf die Installation von Home Assistant Container eingehen.
Unterschied zwischen Home Assistant und Home Assistant Container
Der mächtige Home Assistant wird gerne auf einem Raspberry Pi installiert. In der Regel verwendet man dafür gleich ein ganzes Image für das Betriebssystem. Das bedeutet, dass man statt des üblichen Raspbian das „Home Assistant Operating System“ installiert.
Der Vorteil liegt darin, dass man den Home Assistant in vollem Umfang nutzen kann. Der Nachteil ist, dass man über ein stark angepasstes OS verfügt. Möchte man noch weitere Software darauf laufen lassen, könnte das zu Konflikten führen.
In meinem Fall laufen noch andere Prozesse auf dem Raspberry. Somit kommt für mich das OS nicht infrage. Stattdessen möchte ich auf Home Assistant Container setzen. Hier läuft die Software über Docker.
Benutzt man den Home Assistant Container, muss man mit Einschränkungen leben. Es ist beispielsweise nicht möglich, Add-ons zu installieren. Der Grund liegt meines Wissens darin, dass Add-ons als (Docker-)Container installiert werden. Und das geht nicht, wenn bereits die Hauptanwendung in einem (Docker-) Container läuft. [Falls das jemand genauer weiß, gerne einen Kommentar hinterlassen!]
Installation von Home Assistant Container
Was man als Vorbereitung braucht, ist ein installiertes Linux-System. In meinem Beispiel ist es Raspbian auf einem Raspberry Pi 4. Dort meldet man sich via SSH an.
Schritt 1: Docker installieren. Gegebenenfalls hat man eine alte Version bereits installiert. Diese muss man entfernen und die aktuelle Version installieren. Dazu wird das Docker-Repository hinzugefügt und die Software daraus installiert. Am Ende wird eine Benutzergruppe „docker“ erstellt (ggf. geschieht das automatisch). Der aktuelle Benutzer – hier nennt er sich pi – wird der Gruppe hinzugefügt.
Schritt 2: Home Assistant Container installieren. Der folgende Befehl holt sich das entsprechende Image aus dem Dockerhub, lädt es herunter und installiert es. Es ist wichtig, dass der Ordnerpfad für die Konfigurationsdatei korrekt angegeben wird. Wie oben bereits beschrieben, fehlt die Add-on-Funktion. Um die configuration.yaml bearbeiten zu können, muss man an diese Datei herankommen. Mit der Flag -v mountet man einen existierenden Ordner in den Docker-Container und kann damit die Datei weiterhin bearbeiten.
Schritt 3: Docker-Image verwalten. Die gesamte Home Assistant Installation kann man über den Container starten und stoppen. Ein Update führt man ebenfalls über das Docker-Image aus. Die Befehle hierfür lauten folgendermaßen.
Schritt 4: Auf Home Assistant zugreifen. Ab jetzt erfolgt die Verwaltung des Home Assistant über die Weboberfläche. Mit http://<IP-Adresse des Raspberrys>:8123 kann man von einem PC des gleichen Netzwerks auf die Installation zugreifen. Änderungen an der configuration.yaml müssen weiterhin über die Systemoberfläche, also z.B. mit nano oder vim über SSH erfolgen.
Wie schön wäre es doch, seine Daten sicher zu Hause aufzubewahren, sie immer und überall verfügbar zu haben und diese nicht an zweifelhafte Cloud-Dienstleister auszulagern. Geht das? Na klar, mit der Nextcloud!
Hierzu benötigt man nicht viel. Ein Raspberry Pi mit Internetanschluss und etwas Interesse sich mit dieser interessanten Materie zu beschäftigen reicht völlig aus. Ich bevorzuge generell die klassische Installation der Cloud-Software auf einem LAMP-Server.
Einen etwas einfacheren Weg zur eigenen Cloud geht OWN YOUR BITS. Die Entwickler stellen komplette Images zur Verfügung, um die Cloud ohne Linux-Erfahrung in den eigenen vier Wänden zu realisieren.
Installation
Ich habe mir nun einmal NextcloudPi für den Raspberry Pi etwas genauer angesehen. Das Image hierzu ist 4,3GB groß und kann direkt von der Webseite kostenlos heruntergeladen und eingesetzt werden. Dabei muss man natürlich aufpassen, dass das richtige Download-Paket ausgewählt wird. Ist dies geschehen, wird das Image entpackt und z.B. mit dem Raspberry Pi Imager auf eine mindestens 16GB-große MicroSD geschrieben.
Der erste Kontakt
Nachdem die MicroSD in den Raspberry Pi eingelegt und dieser gestartet wurde (ohne Bildschirm, Tastatur und Maus), erreicht man NextcloudPi über die lokale Adresse https://nextcloudpi.local im heimischen Netzwerk. Voraussetzung ist jedoch der vorherige Anschluss des Einplatinencomputers über LAN-Kabel an den Router.
Wenn alles funktioniert, wird man nach dem Booten von folgendem Bildschirm begrüßt.
NextcloudPi – Erstkontakt
Hier bekommt man Benutzernamen und Passwörter für das NextcloudPi Webinterface sowie die Nextcloud. Nach der Aktivierung gelangt man nun in den NextcloudPi-Maschinenraum. Dazu wird das erste Passwort benötigt, welches später auch geändert werden kann. Weiter geht es mit einem Installations-Wizard, welcher dabei hilft die Cloud mit einer Festplatte oder SSD über USB zu erweitern. Außerdem hat man nun die Möglichkeit das System über einen DynDNS-Anbieter von außen über das Internet erreichbar zu machen.
NextcloudPi – Installations-Wizard
Im Webinterface lassen sich serverseitig einige Einstellungen erledigen, ohne jedoch wirklich selbst Serverkenntnisse besitzen zu müssen. Das birgt allerdings die Gefahr, dass das System ungewollt beschädigt werden kann, was mir tatsächlich einige Male gelungen ist. Um nun in solch einer Situation zur Reparatur selbst Hand anzulegen, muss an den Raspberry Pi ein Monitor und eine Tastatur angeschlossen werden, damit auf den eigentlichen Server zugegriffen werden kann. Dies geht nun direkt auf dem Raspberry Pi oder nach SSH-Aktivierung von einem anderen Computer. Im letzteren Fall kann der RasPi wieder von den zuvor angeschlossenen Peripheriegeräten getrennt werden. Ohne ein wenig Linux-Erfahrung ist man aber hier aufgeschmissen.
Die Nextcloud
Die Nextcloud erreicht man nach erfolgreicher Beendung der Installationsroutine über https://nextcloudpi oder die vom Router für den Raspberry Pi vergebene IP-Adresse. In meinem Fall: https://192.168.178.32. Falls die DynDNS-Adresse zu diesem Zeitpunk schon eingerichtet und in die config.php über das Webinterface aufgenommen wurde, wäre die Nextcloud-Instanz auch über die vergebene Web-Adresse erreichbar, vorausgesetzt die Ports 80 und 443 sind am Router auf Port Forwarding gesetzt. Das Login erfolgt nun über das am Anfang vergebene zweite Passwort. Begrüßt wird der neue Nutzer nun erstmalig von der eigenen Cloud-Instanz. Ratsam wäre es hier, einen neuen Benutzer als Administrator anzulegen und den User ncp später zu löschen.
Auch in der Nextcloud sind Änderungen am System mit äußerster Vorsicht vorzunehmen! Die Erstellung eines Backups ist aus meiner Sicht vorher ebenfalls unverzichtbar. So wurde ich z.B. nach einem App-Upgrade komplett ausgesperrt, da die Cloud dauerhaft im Wartungsmodus verharrte.
Auch anzumerken ist, dass die verwendete Nextcloud-Version nicht up to date ist, wie auch das auf Debian basierende Raspberry Pi OS. Das ist aber nicht weiter schlimm, da diese Versionen eine Langzeitunterstützung seitens der Entwickler erfahren. Die aktuelle Nextcloud-Version ist die 23. Auf NextcloudPi läuft Version 21 und Raspberry Pi OS 10, aktuell v11.
Nextcloud – Fehlermeldungen
Wie man oben im Bild sehen kann, kommt es noch zu diversen Fehlermeldungen, die ebenfalls ohne Serverkenntnisse nicht beseitigt werden können. Es müssen Pakete nachinstalliert werden, bzw. sind Eingriffe in die Konfigurationsdatei der Nextcloud-Instanz notwendig.
Fazit
NextcloudPi ist mit Sicherheit ein interessantes Projekt, welches es dem User erlaubt, schnell eine eigene Nextcloud-Instanz auf dem Einplatinencomputer Raspberry Pi einzurichten und in Betrieb zu nehmen. Die Erreichbarkeit aus dem Internet wird bei Bedarf über eine DynDNS-Adresse realisiert. Wer nicht die neueste Version der Nextcloud einsetzen muss und bereit zu Abstrichen ist, für den ist das System durchaus empfehlenswert.
Meinen Zugang zur Cloud konnte ich problemlos via 2FA mit einem YubiKey absichern.
Leider fehlt ein Turn-Server im System, welcher es quasi unmöglich macht Videokonferenzen via nachinstallierter App Talk zu führen. Ein Turn-Server kann aber im Nachhinein auf dem Raspberry Pi noch nachinstalliert werden. Auch hierzu sind Linux-Kenntnisse von Vorteil.
Seit Ende Oktober 2021 ist die Raspberry-Pi-Familie um ein weiteres Mitglied gewachsen: Der Raspberry Pi Zero 2 löst die vorangegangenen Zero-Modelle ab. Das wichtigste Unterscheidungsmerkmal ist die wesentlich schnellere CPU im System-on-a-Chip (SoC) mit der Bezeichnung BCM2710A1. Dahinter versteckt sich eine Variante des SoC aus dem Raspberry Pi 3. Der Zero 2 glänzt jetzt mit 4 Cores und einer Taktfrequenz von 1 GHz. Damit ist die Rechenleistung um ein Vielfaches höher als bisher.
Persönlich war meine größte Befürchtung, dass sich die höhere Geschwindigkeit auch in einer spürbar höheren Leistungsaufnahme widerspiegeln würde. Tatsächlich ist dies aber laut Messungen von hackaday.com nur teilweise der Fall. Zwar fließen unter Volllast knapp 450 mA Strom (entspricht einer Leistungsaufnahme von 2,2 W). Die Leistungsaufnahme ist damit fast 2,5 mal höher als bei den bisherigen Zero-Modellen. Errechnet man allerdings die CPU-Leistung pro Watt, dann ist der Zero 2 der effizienteste Minicomputer, den die Raspberry Pi Foundation bisher produziert hat. Im Leerlauf sind Zero und Zero 2 fast genauso sparsam (rund 0,4 W beim Zero, rund 0,5 W beim Zero 2).
Der Raspberry Pi Zero 2
Wenn Ihnen die maximale Leistungsaufnahme des Zero 2 zu hoch ist, können Sie durch einen Kernel-Option drei der vier Cores sperren. Damit sinkt die Leistungsaufnahme unter Volllast auf die Hälfte, die Geschwindigkeit allerdings auf ein Viertel. Details dazu können Sie im Blog nachlesen.
Eigener Test
Ich habe den Zero 2 mit Raspberry Pi OS Lite (Bullseye) ausprobiert. Eigentlich wollte ich Hostnamen, WLAN und SSH-Zugang vorweg im Raspberry Pi Imager konfigurieren; beim ersten Versuch hat dies überhaupt nicht funktioniert. Beim zweiten Versuch wurden immerhin der Hostname und das Passwort korrekt gesetzt, aber die WLAN-Verbindung funktionierte wieder nicht. Es ist mir nichts anderes übrig geblieben, als den Zero 2 an einen Monitor und eine Tastatur anzuschließen und die Konfiguration manuell in raspi-config vorzunehmen. Das ist ärgerlich, weil gerade der Zero 2 mit seinen wenigen und exotischen Anschlüssen für eine Headless-Installation prädestiniert ist.
Nachdem diese Hürden gemeistert waren, verhielt sich der Zero 2 unauffällig. Gemessen daran, dass es sich um ein Zero-Modell handelt, läuft der Mini-Computer verblüffend schnell und (z.B. während Updates) ohne unangenehm heiß zu werden.
Eckdaten
Größe: 65 mm x 30 mm
SoC: BCM2710A1, 4 Cortex-A53-Cores
RAM: 512 MByte
Anschlüsse: 2 x Micro-USB (1 x Stromversorgung, 1 x Daten), Mini-HDMI, Mini-Kameraanschluss (erfordert Adapter)
WLAN 2,4 GHz 802.11b/g/n
Bluetooth 4.1
Leistungsaufnahme: 0,4 W (Leerlauf) bis 2,2 W (alle 4 Cores unter Volllast)
40 GPIOs (Lötkontakte, keine Steckerleiste!)
Beachten Sie, dass sämtliche Zero-Modelle, also auch der neue Zero 2, mit einem Mini-HDMI-Anschluss ausgestattet sind. Der Raspberry Pi 4B verwendet dagegen Micro-HDMI. Sie brauchen also für den Zero 2 ein eigenes Kabel oder einen Adapter.
Preis
Das ursprüngliche Zero-Modell wurde ursprünglich als Raspberry Pi für nur fünf Euro beworben. Tatsächlich war er aber nur schwer zu diesem Preis erhältlich (und wenn, dann nur bei der Abnahme hoher Stückzahlen). Beim Zero 2 sieht es aktuell noch schlimmer aus: Laut geizhals ist das Gerät aktuell (Dez. 2021) generell schwer erhältlich und kostet beachtliche 30 Euro — Schnäppchen ist das keines! Der hohe Preis hat mit Corona, dem allgemeinem Chip-Mangel, dem Brexit etc. zu tun, ist also nicht unbedingt die Schuld der Raspberry Pi Foundation. Trotzdem: Wer den Zero 2 kauft, tut dies sicher nicht wegen des günstigen Preises, sondern weil er/sie einen winzigen, leistungseffizienten, Pi-kompatiblen Mini-Computer sucht.
Fazit
tolle Hardware, aber mit 512 MB RAM nicht Desktop-tauglich
Die Raspberry Pi Foundation hat eine neue Raspberry-Pi-OS-Version auf der Basis von Debian Bullseye freigegeben. Damit ändert sich Einiges: Zum einen natürlich eine Menge Versionsnummern dank des modernisierten Debian-Unterbaus, zum anderen aber auch durchaus wichtige technische Details. Z.B. verwendet Rasbperry Pi OS nun standardmäßig GTK3 und den Displaymanager Mutter — zumindest auf Rechnern mit 2 GByte. Aber der Reihe nach …
Update 7.12.2021: Die alte Raspberry-Pi-OS-Version (Buster) wird bis auf Weiteres mit Updates versorgt und erhält die Bezeichnung Legacy. Damit wird niemand zum Update auf die neue Version (Bullseye) gezwungen. Mehr Details können Sie im Blog von raspberrypi.com nachlesen.
Der PIXEL-Desktop von Raspberry Pi OS
Desktop
Auf dem Desktop gibt es nur wenige optische Änderungen:
Hinweise (Notifications) werden jetzt am rechten Bildschirmrand angezeigt. Diese Funktion kann bei Bedarf deaktiviert werden. Dazu öffnen Sie im Panel das Kontextmenü und führen Leisten-Einstellungen / Erscheinungsbild aus.
Zu den neuen Notifications zählt auch der Hinweis auf anstehende Updates. Ein Klick auf den Hinweis öffnet einen neuen, grafischen Update-Manager.
Im Dateimanager gibt es nur mehr zwei Darstellungsmodis: die Icon- und die Listenansicht.
Raspberry Pi OS hat jetzt einen grafischen Update-Dialog
Grafiksystem und Gtk
Der erste Eindruck täuscht aber. Hinter den Kulissen hat sich wesentlich mehr verändert als an der Oberfläche:
Für die Aktivierung des richtigen Grafikmodus ist jetzt der Kernel zuständig (Kernel Mode Setting, KMS). Dabei kommen offizielle Funktionen des Kernels zum Einsatz, nicht mehr wie bisher Raspberry-Pi-spezifische Funktionen, deren Code nicht öffentlich war (Quelle raspberrypi.com).
Raspberry Pi OS verwendet nun standardmäßig GTK3-Bibliotheken (bisher GTK2). Das vereinfacht die Realisierung optischer Effekte (z.B. abgerundeter Fensterecken). Viel wichtiger ist aber: GTK2 ist eine veraltete, nicht mehr aktiv gewartete Bibliothek. Immer mehr moderne Programme setzen GTK3 voraus. Insofern war der Umstieg auf GTK3 überfällig.
Auf Raspberry Pis mit zumindest 2 GByte RAM kommt der Fenstermanager Mutter zum Einsatz (bisher openbox). Auch hier gilt: Mutter ist moderner, zukunftssicherer. Bie Raspberry Pi Organisation bezeichnet den Umstieg auf Mutter als den ersten Schritt hin zur Ablöse von X durch Wayland. Einen konkreten Zeitplan für den Wechsel zu Wayland gibt es allerdings noch nicht, und es ist unklar, ob dieser überhaupt möglich ist. Selbst Mutter braucht so viel RAM, dass es nur auf großzügig mit RAM ausgestatteten Geräten zum Einsatz kommt.
RDP zickt: In der Vergangenheit reichte es aus, xrdp zu installieren, damit man sich mit Remotedesktopverbindung oder einem anderen RDP-Client am Raspberry Pi anzumelden. Gleich aus mehreren Gründen funktioniert das mittlerweile nicht mehr. Abhilfe: Richten Sie einen weiteren Benutzer ein und melden Sie sich damit an (statt mit pi). Mehr Details: https://pi-buch.info/aerger-mit-rdp
Kamera-Software
In bisherigen Raspberry-Pi-OS-Versionen waren proprietäre Software-Treiber und die Programme raspistill und raspivid zuständig, um Fotos bzw. Videos von der Kamera aufzunehmen. Mit dem neuen Raspberry Pi OS wird die Kamera dagegen über die libcamera-Treiber des Kernels angesprochen. Dass im Zuge dieser Umstellung raspistill und raspivid einfach eliminiert wurden, wird viele Scripts vor Kompatibilitätsprobleme stellen. Ja, es gibt mit libcamera-still und libcamera-vid neue Kommandos, diese haben aber komplett andere Optionen. Dokumentation dazu finden Sie hier:
Aus dem Konfigurationsprogramm ist die Option zur Kamerakonfiguration verschwunden. Dafür enthält /boot/config.txt jetzt den Parameter camera_auto_detect=1, der sich um die automatische Treiberkonfiguration kümmern soll. Tests zur Nutzung der Kamerafunktionen reiche ich später in einem eigenen Artikel nach, sobald ein neues Kameramodul bei mir eintrifft. Das alte hat überraschend seinen Geist aufgegeben.
Update 11.11.2021: Mittlerweile habe ich auch die neuen libcamera-Tools kurz dokumentiert:
Viel getan hat sich bei den Versionsnummern des Software-Stacks. Die wichtigste Änderung für viele Raspberry-Pi-Anwender betrifft Python: Erstmals steht die veraltete Version 2 nicht mehr zur Verfügung. Das Kommando python startet nun Python 3.9 statt Python 2.7. Es ist zu befürchten, dass das bei vielen alten Programmen/Bibliotheken zu Problemen führt. Wirklich überrascht sollte aber keiner sein — vor dem Ende von Python 2 wurde ein Jahrzehnt lange gewarnt.
Ich hatte bei meinen Tests massive Probleme mit meinen Monitoren. Immer wieder passierte es, dass meine Monitore nach einer kurzen Darstellung des Raspberry-Pi-Logos einfach schwarz blieben. In allen Fällen lief der Raspberry Pi, d.h. eine SSH-Verbindung war möglich. Die Monitore erhielten offenbar auch ein Signal, d.h. sie wechselten nicht wie sonst automatisch in den Stand-by-Modus oder schalteten sich aus.
Für meine Tests habe ich einen Pi 4B der ersten Generation (1 GB RAM) sowie ein Modell 400 verwendet. Als Monitore kamen ein moderner LG-4k-Monitor (Modell 27UL850-W) sowie ein uralter Benq-Monitor (G2400-WT) zum Einsatz.
Dass während des Bootprozesses keine Meldungen des Kernels bzw. von systemd angezeigt werden, ist beabsichtigt, auch wenn ich mir nicht sicher bin, dass das eine gute Idee ist. Abhilfe: Entfernen Sie quiet splash aus der Datei /boot/cmdline.txt. Eine echte Lösung des Problems ist dies aber nicht: Während der ersten Sekunden sind nun diverse Meldungen sichtbar. Danach wird der Monitor schwarz. Eine Weile später (nach ca. 10 bis 15 Sekunden) erscheint der Desktop — oder auch nicht.
Manchmal half es, den Monitor einfach kurz aus und wieder ein zu schalten.
Sicher ist, dass die Probleme mit dem neuen Raspberry Pi OS zu tun haben; ich habe die gleiche Hardware auch schon mit der vorigen Version des Betriebssystems verwendet und hatte nie derartige Probleme. Trotzdem bleibt unklar, ob die Fehler nur spezifisch bei meiner Hardware auftreten oder ob auch andere Raspberry-Pi-Anwender betroffen sind. Ein diesbezüglicher Twitter-Post erhielt kaum Resonanz.
Problematisch ist in diesem Zusammenhang auch die Veränderung der Bildschirmauflösung: Bei Systemen mit 2 GB RAM oder mehr (also Gtk3) wird die Änderung erst nach einem Reboot wirksam. Das ist nicht nur unpraktisch, sondern auch äußerst problematisch, wenn die gewählte Auflösung am Bildschirm nicht angezeigt werden kann. Mit Pech bleibt der Bildschirm dann ganz einfach schwarz — ohne eine einfache Möglichkeit, die Änderung der Auflösung rückgängig zu machen. Definitiv nicht benutzerfreundlich!
Wenn »Mutter« als Window Manager läuft (auf allen Pis mit 2 GByte RAM oder mehr), erfordert der Wechsel der Bildschirmauflösung einen Neustart mit ungewissem Ausgang
Abhilfe schafft dann nur die Veränderung der Datei /home/pi/.config/monitors.xml via SSH oder auf einem zweiten Linux-Rechner. (Unter macOS oder Windows können Sie auf direkt auf der SD-Karte auf die Partition mit dem Linux-Dateisystem ja gar nicht zugreifen.)
Ich kann mich nicht erinnern, wann ich zuletzt so viel Zeit damit vergeudet habe, um einfach nur ein Bild am Monitor zu sehen. Meine Vermutung ist, dass der ganze Ärger mit dem neuen Kernel Mode Switching (KMS) zu tun hat, das in Raspberry Pi OS Bullseye erstmals aktiv ist und möglicherweise noch nicht in allen Fällen perfekt funktioniert. (Grundsätzlich ist KMS natürlich eine gute Sache: Es ermöglicht einen flicker-freien Bootprozess und erleichtert die Nutzung der Grafikfunktionen ohne Closed-Source-Treiber.)
Sonstiges
Bei RP-Modellen ab 2 GByte RAM ist eine Drehung der Bildschirmdarstellung nicht mehr möglich (z.B. für einen Monitor in Portrait-Modus). Laut der Diskussion auf raspberrypi.com liegt das Problem beim Window Manager Mutter.
Auch die neue Raspberry-Pi-OS-Version verbleibt in der 32-Bit-Welt. Eine 64-Bit-Version wäre möglich, aber die Entwickler sehen keine großen Performance-Vorteile. Außerdem würde eine 64-Bit-Version zwei unterschiedliche Betriebssystemversionen je nach CPU erfordern. (Nur die aktuellen Raspberry-Pi-Modelle haben eine 64-Bit-CPU.) Wer also Docker oder ähnliche Funktionen am Raspberry Pi mit einem 64-Bit-Stack ausführen muss, ist mit alternativen Betriebssystemen wie Ubuntu besser bedient.
Die CPUs auf aktuelle Raspberry-Pi-Modelle mit 2, 4 oder 8 GByte erreichen nun automatisch eine Taktfrequenz von 1,8 GHz. Voraussetzung dafür ist die auf den neuen Platinen integrierte Switch-mode Power Supply (Quelle: raspberrypi.com).
Die Raspberry Pi Foundation rät dringend davon ab, ein Update von Raspberry Pi OS Buster auf die neue Bullseye-Edition zu versuchen — und ich schließe mich diesem Ratschlag an. Grundsätzlich ist so ein Update relativ einfach möglich, in dem Sie in /etc/atp/sources.list jeweils buster durch bullseye ersetzen und dann ein Update aller Pakete durchführen. (So ein Update ist zeitaufwändig — rechnen Sie zumindest mit 30 Minuten, während der Sie immer wieder Rückfragen beantworten müssen.) Aufgrund der vielen grundlegenden Änderungen zwischen den beiden Versionen sind Kompatibilitätsprobleme zu erwarten. Deswegen ist es sicherlich vernünftig, ein Backup aller relevanten Dateien durchzuführen und dann (idealerweise auf eine zweite SD-Karte) die neue Version von Raspberry Pi OS zu installieren.
Fazit
Viele technische Änderungen, die zusammen mit dem Umstieg auf die neue Basis Debian Bullseye durchgeführt wurden, sind aus Open-Source-Sicht erfreulich: Es kommen mehr Open-Source-Treiber als bisher zum Einsatz, Raspberry Pi OS ist näher an Linux-Standards und es gibt sogar einen (vager) Ausblick Richtung Wayland.
Zumindest bei meinen Tests sind allerdings auch erhebliche Probleme aufgetreten. (Ich habe natürlich auch andere Tests gelesen. Deren Autoren hatten offenbar weniger Probleme. Vielleicht liegt es an mir oder an meiner Hardware?)
Wie auch immer: Sie machen vermutlich nichts verkehrt, wenn Sie noch ein, zwei Monate abwarten, bevor Sie auf das neue Raspberry Pi OS Bullseye umsteigen.
Neulich hatte ich Bedarf den SWAP eines Raspberry Pi, auf dem ein Raspberry Pi OS läuft, zu erweitern, da dieser ständig überlief. Hier sind per Standard 100MB eingerichtet. Diesen Wert galt es nun auf 1000MB anzuheben.
Diese Änderung kann ganz einfach wie folgt umgesetzt werden. Dazu ruft man mit dem Editor Nano die Datei /etc/dphys-swapfile auf
sudo nano /etc/dphys-swapfile
sucht den entsprechenden Eintrag und ändert den Wert, wie im Beispiel auf 1000.
CONF_SWAPSIZE=1000
Nach dem Abspeichern via Ctrl + o, dem Verlassen des Editors mit Ctrl + x und einem anschließenden Reboot, steht die neue Größe des SWAP-Speichers zur Verfügung.
Der Raspberry Pi 4 kann 4K@60Hz ausgeben. Unter LibreELEC muss dies über die config.txt aktiviert werden. Leider funktioniert die Methode (noch) nicht mit LibreELEC 10. Über den Texteditor: Steckt die SD-Karte in euren PC,...
Im vorherigen Beitrag habe ich euch gezeigt wie ihr den Hauppauge WinTV-soloHD oder Hauppauge WinTV-dualHD unter Linux einrichtet. Hinweis: Für Raspberry Pi OS 10 „Buster“ gibt es derzeit (Stand: Januar 2021) keine eigenen Tvheadend...
Ein NAS zu verwenden ist in vielen Situationen sinnvoll. Wenn man beispielsweise mehrere netzwerkfähige Geräte verwendet, seien es PCs, Tablets oder Fernseher, können alle Geräte auf den gleichen Speicher zugreifen. Dort gespeicherte Dateien, beispielsweise Urlaubsfotos, können dann auf allen diesen Geräten angezeigt werden.
Meine Motivation ist allerdings vor allem der redundante Festplattenspeicher. Ich verwende ein NAS mit zwei Festplatten. Ich werde sie so konfigurieren, dass beide Festplatten sich gegenseitig spiegeln, also exakt die gleichen Daten speichern. Das nennt sich RAID 1 (Redundant Array of independent disks). Fällt eine der beiden Festplatten aus, kann sie ersetzt werden und die Daten sind noch auf der zweiten Festplatte gespeichert.
NAS kaufen vs. Raspberry Pi Eigenbau
Das aktuelle Einstiegsmodell von Synology, DS218j, genügt für mich allemal. Ich werde einen relativ geringen Traffic darauf laufen lassen und brauche dort keine übermäßige Rechenleistung (momentan habe ich keinen Bedarf an Videocodierung oder anderen aufwendigen Berechnungen). Ich kann von meinen Geräten im Heimnetzwerk darauf zugreifen und haben die besagte Ausfallsicherheit durch das RAID 1.
Andere Hersteller kommen natürlich auch in Frage. Für meine Bedürfnisse ist es schon beinahe egal, wer das NAS herstellt. Ich habe mich für den Hersteller entschieden, der in meinem Bekanntenkreis bereits verwendet wird.
Prinzipiell gibt es sogar die Möglichkeit, das NAS über ein Raspberry Pi selbst zu bauen. Das Betriebssystem OpenMediaVault kann man das sogar recht komfortabel umsetzen. Ein halbwegs neuer Raspberry Pi und externe Festplatten genügen, schon kann man die Low Budget Variante selber bauen. Die Einrichtung funktioniert anschließend über den Browser, so wie es auch in den kommerziellen Varianten der Fall ist.
Ich entschied mich für die kommerzielle Variante. Das ist – zugegeben – eher untypisch für mich und das Blog. Normalerweise bin ich eher der Bastler, der gerne solche Systeme selber baut. In diesem speziellen Fall war mir die Kaufvariante allerdings lieber.
NAS-Festplatten vs. Deskop-Festplatten
Die zweite Frage, nachdem die Entscheidung auf die Diskstation DS218j gefallen ist, lautet: welche Festplatten werde ich verwenden?Die sogenannten NAS-Festplatten sind robuster ausgestattet als die typischen Desktop-Festplatten. Die wesentlichen Unterschiede zwischen den Typen sind die folgenden:
Drehzahl: NAS-HDD laufen langsamer als Desktop-HDD. Sie sind dadurch ruhiger, verbrauchen weniger Energie und erwärmen sich nicht so stark.
Montagebohrungen: Nicht jede HDD hat die passenden Befestigungsmöglichkeiten für die Rahmen in einem NAS.
Firmware: NAS-HDD können mit dem RAID-Controller über ausgefallene Sektoren kommunizieren.
Vibrationen: NAS-HDD haben manchmal einen Virbationssensor, der bei zu starken Vibrationen im Gehäuse die HDD herunterfährt. Außerdem sind die „besseren“ NAS-HDD zusätzlich mit Vibrationsdämpfern ausgestattet.
Ich habe mal letztendlich für die NAS-Version von Western Digital entschieden (WD Red). Aus meiner Sicht sind alle HDD-Hersteller gleichbedeutend, es hätte genauso gut Seagate oder Sandisk oder etwas anderes werden können. Die NAS-Festplatten kosten nur unwesentlich mehr als die Desktop-Version.
Seit Anfang des Jahres habe ich den 52PI Ice Tower CPU Kühler auf meinem Raspberry Pi 4. Dieser kühlt meinen Raspberry Pi bisher auch sehr zuverlässig. Der mitgelieferte RGB Lüfter ging mir mit dem...
Die Raspberry Pi Foundation hat vor wenigen Tagen das Tool “Raspberry Pi Imager” vorgestellt. Dieses Tool ermöglicht es Nutzern schnell und einfach das gewünschte Image auf eine (micro)SD-Karte zu schreiben. Den Raspberry Pi Imager...
Ich betreibe Pi-Hole nun schon seit einer längeren Zeit auf meinem Raspberry Pi. Immer wieder hatte ich dass Problem dass in der resolv.conf nach einem Neustart oder Update der Pi selbst als DNS Server...
Digital Signage oder „Digitale Beschilderung“ bietet auch für Schulen neue Möglichkeiten. Was früher mit Aushängen an sogenannten „schwarzen Brettern“ oder Informationstafeln gelöst wurde, wird zunehmend von Monitoren übernommen. Egal ob Hinweise zu kommenden Veranstaltungen, Vertretungspläne, Raumbeschilderung oder sonstige wichtige Informationen – vieles lässt sich flexibler auf Monitoren darstellen. Aktualisierungen kann man von zentraler Stelle aus vornehmen bzw. auch automatisieren (z.B. beim Vertretungsplan). Welche Open Source Digital Signage Lösungen gibt es? Was könnten Anforderungen sein, die man als Schule hat? Ich möchte heute einige Lösungen auflisten, die in späteren Artikeln noch einmal genauer beleuchtet werden sollen.
Was sollte ein Digital Signage System können?
Die Anforderungen werden sicher von Schule zu Schule verschieden sein, aber es gibt doch ein paar wesentliche Eigenschaften, die von einer Open Source Digital Signage Lösung erfüllt sein sollten:
einfach zu benutzen (z.B. Editor zum Erstellen von Folien / Slides)
einfache und schnelle Darstellung von Bilder, Videos und anderen Dokumenten
zentrale Verwaltung mehrerer Monitore (am besten mit verschiedenen Gruppen / Kanälen, um verschiedene Informationen auf verschiedenen Monitoren anzeigen zu können)
Möglichkeiten zur Automatisierung / Zeitplan
möglichst kostenfrei (Lizenzen oder monatliche Gebühren)
Welche Open Source Digital Signage Lösungen gibt es?
Wenn man sich nach Open Source Digital Signage Lösungen umschaut, wird man schnell fündig. Allerdings sind viele von den sogenannten „Open Source“ Lösungen eher Freemium – Lösungen bzw. nur teilweise Open Source. Ich habe keine dieser Lösungen bisher selbst im Einsatz gehabt. In den kommenden Monaten werde ich mir aber einige dieser Lösungen anschauen, da wir als Schule noch auf der Suche nach einem passenden Digital Signage System sind.
Screenly OSE
Wenn auf Github nach Digital Signage schaut, ist Screenly OSE mit Abstand das populärste System. Screenly OSE ist für den Raspberry Pi konzipiert. Es bietet grundlegende Features, allerdings muss beim Einsatz mehrerer Geräte, jeder Raspberry Pi einzeln verwaltet werden. Die Unterschiede zur Bezahlversion sind hier aufgelistet.auch
Xibo
Direkt hinter Screenly OSE folgt Xibo, wenn man nach der Anzahl der Sterne auf Github geht. Xibo gibt es schon eine ganze Weile. Im Gegensatz zu Screenly gibt es keine Pro vs. Open Source Version, sondern alle Features sind für alle verfügbar. Xibo besteht aus einem CMS, welches man auch in einem Docker-Container installieren kann und den zugehörigen Player, die auf den Anzeigegeräten selbst installiert werden. Der Player für Windows ist kostenfrei und Open Source, für alle anderen Player müssen Lizenzgebühren bezahlt werden. Es gibt den Xibo Player für Windows, Android und webOS. Ein Player für Linux ist wohl geplant, aber noch nicht verfügbar.
Concerto
Ebenfalls schon länger am Markt ist Concerto. Concerto bietet viele Features und kann selbst gehostet werden. Technisch basiert es auf Ruby. Wenn man sich in dem Projekt auf Github etwas umschaut, scheint die Entwicklung etwas zu stocken. Dem Webinterface sieht man sein Alter auch schon etwas an. Insgesamt aber eine 100% Open Source Lösung.
LibreSignage
LibreSignage ist noch recht neue Open Source Lösung und zu 100%, Browser basiert. Es braucht also keine speziellen „Player“, sondern kann über den Browser benutzt werden. Grundlegende Features und auch Mehrbenutzerbetrieb sind vorhanden.
Foyer
Foyer ist ein WordPress-Plugin. Man kann damit verschiedene Seiten erstellen, Kanäle und verschiedene Displays diesen Kanälen zuweisen. Es ist wie LibreSignage Browser basiert und braucht deshalb keinen besonderen Player.
tabula.info
Tabula.info ist die einzige Lösung, die ich gefunden habe, die speziell für Schulen entwickelt wurde. Es bietet viele nette Features, die in man in einer Schule braucht und ist auf die Anzeige von Vertretungsplänen, HTML-Seiten und zusätzlichen Infos spezialisiert.
Weitere Lösungen
Infobeamer
Infobeamer ist nur für den privaten, nicht öffentlichen Gebrauch kostenfrei. Sonst ist wohl eine der leistungsstärksten und flexibelsten Lösungen. Die Hardware eines Raspberry Pi’s wird maximal ausgenutzt (z.B. Hardwarebeschleunigung – ein Nachteil, den alle Browser basierten Lösungen haben).
Display Monkey
Display Monkey ist ebenfalls eine Open Source Lösung, die allerdings einen Windows Server voraussetzt. Die einzelnen Displays brauchen nur einen Browser.
piSignage
Eine weitere Lösung für Digital Signage ist piSignage. Der Server ist OpenSource und kann auch selbst gehostet werden. Für die einzelnen Displays / Players müssen aber Lizenzen gekauft werden (einmalig). Wie der Name vermuten lässt, verwendet piSignage Raspberry Pi’s als Player. Der Code dafür ist nicht Open Source.
Fazit
Auf den ersten Blick gibt es scheinbar viele Open Source Lösungen. Welche kennst du noch, die hier fehlen? Mit welchem Systemen hast du gute Erfahrungen gemacht? Der Praxistest wird zeigen, welche Lösung für unsere Situation am besten geeignet ist.
Vor ca. einem Jahr habe ich beschrieben, wie man mit einem Raspberry Pi und einem Feinstaubsensor die Luftqualität messen kann. Das Setup setzen wir so seit einigen Jahren bei uns in der Schule bzw. auch privat ein. Einen Nachteil hat dieses Projekt allerdings: es ist nicht mobil, sondern abhängig von einem WLAN-Netz bzw. einer Netzwerkverbindung. Wenn der Raspberry Pi und das Smartphone / ein Rechner nicht im gleichen Netz sind, kann man nicht auf die Messdaten zugreifen. Deshalb haben wir vor einiger Zeit den Raspberry Pi um einen kleinen Bildschirm ergänzt, sodass man die Werte direkt am Gerät ablesen kann. Wie man diesen Bildschirm für unser mobiles Feinstaubmessgerät einrichtet und welche zusätzlichen Konfigurationen notwendig sind, möchte ich in diesem Artikel kurz vorstellen.
Bildschirm für den Raspberry Pi einrichten
Auf Amazon oder AliExpress gibt es verschiedene Displays für den Raspberry Pi. Diese reichen von ePaper-Screens bis hin zu LCDs mit Touchfunktion. Wir haben uns für einen 3,5″ LCD mit Touch entschieden, welcher eine Auflösung von 320×480 Pixel hat (Modell MPI3501). Man kann diesen Bildschirm einfach auf die GPIO Pins stecken. Dazu kostet er gerade mal 10-15€. Schön ist auch, dass er mit 3,5″ genauso groß wie ein Raspberry Pi ist.
Wenn man den Bildschirm aufsteckt und den Raspberry Pi startet, bleibt der Bildschirm weiß. Man muss zuerst noch die passenden Treiber für das Display installieren. Dazu meldet man sich per SSH an und führt folgende Befehle aus:
Je nach Bildschirmmodell muss man nun den passenden Befehl ausführen um die Treiber zu installieren. In unserem Fall (für das Modell MPI3501):
$ sudo ./LCD35-show
Dieser Befehl installiert die entsprechenden Treiber und startet den Raspberry Pi anschließend neu.
Pixel-Desktop installieren und Autostart einrichten
Damit wir die Website mit den Messwerten direkt beim Start auf dem Bildschirm angezeigt bekommen sind noch einige Schritte notwendig. Zuerst muss man die Pixel-Desktopumgebung installieren (falls man bisher Raspian Lite verwendet hat) mit
$ sudo apt install raspberrypi-ui-mods
Dann fehlt noch der Chromium-Browser, um die Website anzuzeigen:
$ sudo apt install chromium-browser
Standardmäßig ist der Autologin für das Benutzer „pi“ nicht eingerichtet. Dies ist aber notwendig, damit die Messwerte direkt nach dem Start angezeigt werden können, ansonsten begrüßt einen nur der Anmeldebildschirm. Den Autologin kann man über das raspi-config Programm einrichten:
sudo raspi-config
Im Menü wählt man dann 3 Boot Options → B1 Desktop / CLI → B4 Desktop Autologin.
Zu guter Letzt fehlt noch die Einrichtung des Autostarts, damit Chromium nach dem Booten automatisch mit der AQI-Seite gestartet wird. Dazu legt man den Ordner /home/pi/.config/lxsession/LXDE-pi/ an:
$ mkdir -p /home/pi/config/lxsession/LXDE-pi/
Anschließend erstellt man in diesem Ordner die Datei autostart
#@unclutter
@xset s off
@xset -dpms
@xset s noblank
# Chromium im Vollbild beim Start öffnen
@chromium-browser --incognito --kiosk http://localhost
Möchte man noch den Mauszeiger ausblenden, muss man noch das Paket unclutter installieren und am Anfang der autostart das Kommentarzeichen entfernen:
$ sudo apt install unclutter
Da ich im letzten Jahr ein paar kleine Änderungen am Code vorgenommen habe, empfiehlt es sich das Skript und die Dateien der AQI-Website neu herunterzuladen (wie das geht, steht im Originalartikel).
Fazit
Durch das Display hat man nun ein mobiles Feinstaubmessgerät. Wir setzen sie an unserer Schule ein um z.B. die Qualität der Luft in den Klassenzimmern zu überprüfen oder um Vergleichsmessungen durchzuführen. Mit diesem Setup ist man nicht mehr auf eine Netzwerkverbindung oder WLAN angewiesen, sondern kann die kleine Messstation überall einsetzen – mit einer Powerbank sogar noch unabhängig vom Stromnetz.
