staging.inyokaproject.org

Derzeit laufen Kampagnen, die Open Source Software angesichts der weltweiten Entwicklungen wieder stärker in den Vordergrund rücken wollen. Ein hehres Ziel, das aber nicht über die Tatsachen hinwegtäuschen sollte. Auch die Open-Source-Welt wird von US-amerikanischen Strukturen dominiert.

Ältere Nutzer werden sich vielleicht noch an PRISM-Break erinnern. PRISM war eines der NSA-Programme, die Edward Snowden bei seiner Enthüllung der globalen Überwachungs- und Spionageaffäre aufgedeckt hatte. PRISM-Break war eine Seite, die Nutzer davon überzeugen sollte, quelloffene Alternativen zu nutzen. Der Sinn war angesichts der Überwachungsarchitektur der NSA schon damals mehr als fraglich.

Angesichts der Politik von US-Präsident Trump erfahren solche Kampagnen gerade eine Neuauflage (z.B. #UnplugTrump aber auch sehr prominent auf Mastodon) und wieder geht es darum, sich von der US-dominierten IT-Landschaft zu emanzipieren. Und wieder zielen solche Kampagnen vor allem darauf ab, Open-Source-Alternativen zu stärken. Was vermutlich schon daran liegt, dass die proprietären Alternativen aus Europa überschaubar sind.

Dagegen ist grundsätzlich nichts einzuwenden. Open Source kann immer einen Schub gebrauchen. Das Problem hinter solchen Kampagnen ist nur leider, dass hier ein Ziel vorgeschoben wird, das so unmittelbar gar nicht zu erreichen ist. Gegen die US-Dominanz im IT-Bereich hilft eine Hinwendung zu Open Source in der jetzigen Organisationsform nur bedingt. Denn Open-Source ist nicht staatenlos, darauf habe ich in der Vergangenheit schon hingewiesen.

Gehen wir einige problematische Beispiele durch.:

1. Signal: Wird entwickelt von der Signal Foundation mit Sitz in den USA. Die Daten sind vollständig verschlüsselt, laufen aber über Service von AWS.
2. Suchmaschinen: MetaGer und andere Alternativen zu Google greifen im Hintergrund immer noch auf die US-Dienste wie Google, Bing & Co zu.
3. MyCroft wird eine Foundation mit Sitz in den USA entwickelt. Allerdins gab es hier positive Entwicklungen. OpenVoiceOS sitzt nun in den Niederlanden.
4. Linux: Die Linux Foundation sitzt in den USA und unterliegt US-Gesetzen. Wichtige Distributionen wie Red Hat / Fedora ebenfalls. Das gilt für Beteiligung, wie auch für Exportbestimmungen.
5. GitHub als zentrale Codeverwaltung für viele Open-Source-Projekte gehört Microsoft. Das löst immer wieder Schwierigkeiten aus. Jüngst wurde OrganicMaps wegen Beiträgen aus sanktionierten Staaten gesperrt (Siehe Meldung auf Mastodon).
6. Die Mozilla Foundation als Rückgrat des letzten freien Webbrowsers sitzt ebenfalls in den USA.
7. Die GNOME Foundation (wichtige Desktopumgebung und Spendenabwickler für Projekte wie GIMP) sitzt in den USA.
8. Die Apache Foundation sitzt in den USA
9. Das Tor Project hat seinen Sitz in den USA und wurde in der Vergangenheit stark von US-Regierungsstellen finanziert.

Zum Glück sitzen nicht alle Strukturen in den USA:

1. Manche Foundations wie OpenStreetMap oder Collabora haben ihren Sitz in Großbritannien. Das stärkt zwar die Unabhängigkeit von den USA, bedeutet aber keineswegs bessere Bedingungen im Bereich Überwachung und Datenschutz. Die jüngsten Schwierigkeiten von Apple sollten hier Mahnung genug sein.
2. Die GrapheneOS Foundation ist ziemlich versteckt, sitzt aber vermutlich aktuell in Kanada.
3. BigBlueButton Inc. sitzt ebenfalls in Kanada.
4. Nur sehr wenige Entwicklungen wie LibreOffice oder Nextcloud sitzen wirklich in der EU.

Das bedeutet natürlich nicht, dass eine Hinwendung zu Open-Source falsch ist. Den Kopf in den Sand stecken und einfach dem US-Tech-Oligopol mit seinen opportunistischen politischen Wendungen zu folgen, kann mit Sicherheit nicht die Lösung sein. Letztlich bietet nur eine kollaborative Entwicklung und offene und transparente Strukturen genug Unabhängigkeit vom Tech-Oligopol, das sich (hauptsächlich) in den USA formiert hat. Es sitzen natürlich auch nicht alle Hauptentwickler und Contributors im Land, in dem die jeweilige Stiftung/Foundation angesiedelt ist.

Ich halte es nur für falsch zu kommunizieren, dass eine Hinwendung zu Open-Source alleine alle unsere Probleme löst, denn auch innerhalb der Open-Source-Projekte haben die USA eine übermächtige Position und die meisten Projekte müssen sich direkt oder indirekt den US-Bestimmungen beugen. Wer das unterschlägt, betreibt billige Open-Source-Propaganda, um auf einer aktuellen Trump-Aufmerksamkeitswelle mitzugleiten.

Dieser Beitrag stammt ursprünglich aus dem Jahr 2014, wurde 2025 aber nochmal grundsätzlich überarbeitet, vor allem der Imagemagick- und ffmpeg-Abschnitt.

Ich finde, dass es kaum schönere Videos von Landschaften oder Städten gibt als Zeitrafferaufnahmen. Diese haben meistens eine Dynamik, die das gewisse Extra ausmachen.

Jetzt habe ich bei eine recht gute Kamera herumliegen (Canon EOS 550D), die sehr gute Fotos macht. Jetzt hat sich mir die Frage gestellt: Kann man die Kamera in einstellbaren Intervallen auslösen lassen, sodass sie für mich die Zeitraffer-Fotos erstellt? Man kann!

Die Kamera zeitgesteuert auslösen

Leider gibt es für die Canon EOS 550D keine interne Funktion, mit der man massenhaft Bildern in voreingestellten Intervallen machen kann.

Externe Hardware

Es gibt aber kommerzielle Systeme, mit denen das geht. Diese kosten etwa 25 Euro. Irgendwann versuche ich mal, mir selbst so ein Teil zu basteln, aber das wird dann ein eigener Artikel hier im Blog

Gphoto2

Die Mühen und das Geld kann man sich aber sparen, wenn man einen Laptop zur Verfügung hat, auf dem z.B. Ubuntu läuft. Denn mit einem kleinen Helferlein kann man diese Aufgabe auch über den PC steuern!

Das Paket nennt sich Gphoto2 und lässt sich in den meisten Distributionen sehr leicht installieren.

sudo apt-get install gphoto2

Nach der Installation kann man seine Kamera über USB anschließen. Vermutlich wird sie automatisch eingehängt, das umgeht man, indem man die Kamera auf PTP stellt oder sie einfach wieder aushängt. Das geht zum Beispiel in Nautilus, indem ihr den Escape-Button anklickt.

Jetzt kann man überprüfen, ob gphoto2 mit der Kamera zusammenarbeitet. Das macht man mit dem folgenden Befehl, der die Typenbezeichnung der angeschlossenen Kamera ausgeben sollte (siehe meine Ausgabe).

$ gphoto2 --auto-detect
Modell                         Port                                            
----------------------------------------------------------
Canon EOS 550D                 usb:002,003

Jetzt kann es losgehen. Die Kamera hatte ich im M-Modus (manuell) und habe folgendes manuell eingestellt:

• ISO,
• Blende,
• Verschlusszeit,
• Weißabgleich und
• Fokus

Ist man im Halbautomatik-Modus (Av oder Tv) können sich die Bilder in der Helligkeit unterscheiden. Den Autofokus kann man am Anfang verwenden, sollte ihn dann aber abschalten. Das sieht auf dem Video sonst nicht schön aus!

Mit dem folgenden Befehl werden die Bilder für das Zeitraffer aufgenommen.

gphoto2 --capture-image-and-download -I 5 -F 600

Die Einstellungen:

• –capture-image-and-download  → Die Bilder werden geschossen und sofort auf den Computer geladen. Auf der Speicherkarte sind die Bilder nicht mehr!
  Alternative: –capture-image  → Die Bilder werden auf der Speicherkarte abgelegt.
• -I 5  → Das Intervall der Aufnahmen beträgt 5 Sekunden
• -F 600  → Es werden 600 Aufnahmen gemacht.

Wer noch mehr einstellen möchte, kann sich über den folgenden Befehl all seine Einstellmöglichkeiten auflisten lassen:

gphoto2 --list-config

 Aus einer Bilderserie ein Timelapse-Video machen

Der schwierigste Schritt ist gemacht. Den Rest übernimmt für uns mal wieder Imagemagick, das Bildverarbeitungsprogramm aus der Konsole. Das Herrliche daran: mit wenigen Zeilen kann man mit einem Rutsch alle seine Bilder bearbeiten lassen.

Bilder auf Full-HD Auflösung bringen

Da die Kamera die Bilder in einer sehr hohen Auflösung aufnimmt, muss man diese auf Videogröße skalieren.

Wenn man sich mit dem Terminal im Ordner der Bilder befindet, verkleinert man sie mit dem folgenden Einzeiler auf die Auflösung 1920×1280 (das Bildverhältnis zwingt uns zunächst dazu).

x=1; for i in *.jpg; do convert $i -resize 1920x1280 -shave 0x100 `printf "%05d.jpg" $x`; x=$(($x+1)); done

mit -shave schneiden wir oben und unten jeweils 100 Pixel ab, um auf die finale Auflösung von 1920×1080 Pixel (Full-HD) zu gelangen.

Weiteres Beispiel: Bilder zurechtschneiden und drehen (crop und rotate)

Die Bilderserie wurde mit einer Gopro aufgezeichnet. Der Bildausschnitt muss noch zurechtgeschnitten werden und um 90 ° gedreht werden. Das kann man mit folgendem Befehl durchführen.

$ x=1; for i in *.jpg; do convert $i -crop 3380x1900+300+730 +repage -rotate 90 `printf "%05d.jpg" $x`; x=$(($x+1)); done

Die Geometrie-Angaben für imagemagick Breite x Höhe geben die Größe des fertigen Bildes an. Der Offset x und y wird von der oberen linken Ecke gemessen. Ich habe sie mittels Bildbearbeitungssoftware herausgemessen. Mit +repage stellt man sicher, dass Leinwand und Bild richtig zueinander ausgerichtet sind. Am Ende rotiert die Flagge -rotate das Bild um 90° im Uhrzeigersinn.

Einzelbilder zu Video konvertieren

Mit diesem letzten Befehl verbindet man nun alle Einzelbilder zu einem Video. Ich habe hier eine Framerate von 25 fps (Frames per second) gewählt. Man kann auch weniger nehmen, dann dauert das Video etwas länger, ruckelt allerdings.

ffmpeg -r 25 -f image2 -i 0%04d.jpg -c:v libx264 -profile:v high -level 4.0 -pix_fmt yuv420p -movflags +faststart zeitraffer.mp4

Zu beachten ist der Punkt -i 0%04d.jpg . Die Dateien müssen z.B. 00001.jpg genannt sein, das haben wir oben mit imagemagick sichergestellt. Mit der genannten Flagge teile ich das ffmpeg mit, dass eine vierstellige Dezimalzahl in den Dateinamen vorkommt, nach der es die Bilder aneinandersetzen soll.

• -profile:v high -level 4.0: das stellt die Kompatibilität zu Handys (z.B. mit Android) sicher
• -movflags +faststart: Stellt den Metatag „moov“ an den Beginn der Datei, sodass das Video schon starten kann, bevor es vollständig geladen ist. Das ist wichtig für Handykompatibilität
• -pix_fmt yuv420p: Das ist das am weitesten verbreitete Pixelformat.
• optional: -vf scale=1280:720 für eine niedrigere Auflösung
• optional: -b:v 2M für eine niedrigere Bitrate

Einstellungen für 4K-Videos

4K-Videos haben eine Auflösung von 3840×2160 Pixeln und sind nur auf wenigen Geräten in voller Größe abspielbar.

Tipps und Tricks

Zeitraffer planen

Bevor ihr ein Zeitraffer aufnehmt, solltet ihr es planen. Es ist wichtig zu wissen, wie lange das fertige Video dauern wird und wie schnell sich die Objekte darauf bewegen sollen.

Für ein 30-Sekunden-Video sind  30×25= 750 Fotos notwendig. Wenn in diesen 30 Sekunden ein Zeitraum von 60 Minuten abgebildet werden soll, muss man das Intervall auf 4,8 ~ 5 Sekunden stellen.

Spiegelreflex-Kameras vermeiden

Wer professionell oder zumindest häufiger Zeitraffer aufnehmen möchte, sollte sich eine Alternative zu einer Spiegelreflex-Kamera überlegen. Meine Kamera ist laut (dubioser) Foren im Internet auf 50.000 Bilder ausgelegt, danach beginnen die Probleme. Die Kamera hat also starken Wertverlust durch die Zeitraffer, da hier in kurzer Zeit viele Bilder gemacht werden.

Anzahl der Auslösungen der Kamera anzeigen

Die Anzahl der Auslösungen der Kamera kann man ebenfalls mit gphoto2 auslesen. Man startet es im Terminal in einer ncurses-Umgebung und navigiert durch das Menü: Statusinformationen → Auslösezahl

gphoto2 --config

 Weiterführende Links

• gphoto2 Dokumentation
• Fotoschnack Episode über Zeitraffer

The post Timelapse aufnehmen und mit imagemagick und ffmpeg zu einem Video umwandeln first appeared on bejonet - Linux | Smart Home | Technik.

Neue Terminal-Anwendungen vor allem im Gnome-Lager ersetzen die bisherigen Programme – und haben dabei neuerdings die Fähigkeit eingebüßt, den Hintergrund der Fenster durchscheinen zu lassen. Transparenz scheint out. Aber man muss nicht darauf verzichten. Der bislang vom Fedora-Projekt betreute Patch für das Gnome-Terminal ist zwar Geschichte, was auch Auswirkungen auf andere Distributionen hat – aber eine neue Lösung steht schon bereit: Ptyxis.

Ptyxis beherrscht Transparenz – und färbt die Titelleiste rötlich im Superuser-Modus

Wenn man sich auf eine Konstante verlassen kann in Desktopumgebungen, dann sind das die Terminalprogramme. KDE hat die „Konsole“, XFCE das XFCE4-Terminal und Gnome das Gnome-Terminal. Letzteres existiert weiter, hat aber vor einiger Zeit Konkurrenz im eigenen Desktop bekommen: Mit der „Gnome-Console“ kam eine schlichtere Anwendung als Standard-Terminal in die Desktopumgebung. Transparenz beherrschte dieses Programm nicht mehr.

Aber auch das Gnome-Terminal, das als Alternative weiterhin vorhanden war, hatte transparente Fenster in Wirklichkeit schon lange abgeschafft. Dass das z. B. unter Ubuntu oder Fedora den Anwendern noch nicht aufgefallen war, lag einzig daran, dass die Distributionen die früher enthaltene Transparenz-Einstellungen ins Gnome-Terminal wieder hineingepatcht hatten. Statt das Original-Gnome-Terminal wurde dort eine modifizierte Version angeboten. Für viele Anwender gehört die Transperenz zum Linux-Coolness-Desktop-Faktor einfach dazu. Auch andere Distributionen nahmen die Fedora-Version des Gnome-Terminals deshalb in ihre Paketquellen auf, damit auch dort Transparenz im Terminal möglich wurde.

Doch wer etwa unter aktuellem Fedora das Gnome-Terminal nutzt, konnte ebenfalls keine durchscheinenden Fenster mehr sehen. Die Einstellungen für Transparenz sind verschwunden. Der Grund: Die gepatchte Version wird nicht mehr weiterbetreut, es wird auch bei Fedora nun wieder das eigentliche Gnome-Terminal angeboten. Transparenz schien damit nun endgültig zu den Akten gelegt worden zu sein. Jedenfalls beim Gnome-Terminal.

Gesundheit!

Inzwischen ist aber auch das Gnome-Terminal nicht mehr erste Wahl bei Fedora, stattdessen wurde „Ptyxis“ zum neuen Standard-Terminal gemacht. Wer ein Terminal aufruft, sieht Ptyxis, das äußerlich der schob bekannten abgespeckten Gnome-Console ähnelt. Der Programmname klingt nicht nur wie eine verschleppte Erkältung, sondern das Terminal ist auch zunächst ungewohnt, da es auf den ersten Blick noch spartanischer daherzukommen scheint als die bisherigen Lösungen. Auf den zweiten Blick ist es aber ziemlich edel. Denn es ermöglicht eine Dash-Übersicht in der Dash-Übersicht: Terminal-Tabs lassen sich wie bei der Gnome-Shell verkleinern und auswählen. Und mit noch einem praktischen Detail fällt Ptyxis auf: Wenn man mit Root-Rechten im Terminal unterwegs ist, wechselt die Fensterleiste in die Farbe Rot.

Transparenz für Ptyxis

Einstellungen für durchscheinende Fenster scheint aber auch Ptyxis nicht zu haben – scheinbar. In Wirklichkeit ist die Funktion aber vorhanden, sie wird in den Einstellungen nur bislang noch nicht abgebildet. Die versteckte Option lässt sich jedoch relativ simpel aktivieren:

Mit dem Befehl

gsettings set 'org.gnome.Ptyxis.Profile:/org/gnome/Ptyxis/Profiles/'$PTYXIS_PROFILE'/' 'opacity' '0.85'

wird das Ptyxsis-Terminal leicht transparent. Je niedriger der gewählte Wert, desto durchscheinender ist das Terminalfenster.

Derselbe Befehl mit dem Wert 1.0 statt 0.85 hebt die Transparenz wieder auf und macht die Anwendung erneut standardmäßig undurchsichtig.

Bei Distributionen mit nichttransparentem Gnome-Terminal kann man alternativ zu Ptyxis auch noch zu Konsole oder Xfce4-Terminal raten. In diesen Programmen ist Transparenz ebenfalls weiterhin von Haus aus eingebaut und in den Programmeinstellungen aktivierbar.

Kurz notiert, weil ich es ganz spannend finde: Wer kann am besten die Anti-Spam-Mechanismen wie DMARC, SPF und DKIM erfüllen? Genau, Spammer. Damit ist – auch im Lichte der unterschiedlichen Anstrengungen der großen Provider zur Durchsetzung der Einträge – die Spamerkennung anhand Überprüfung der Authentizität des Absenders hinfällig.

Hintergrund ist, dass das E-Mail-System eigentlich wie ein System von Briefkästen aufgebaut ist. Jemand schreibt eine E-Mail und wirft sie in einem „Briefkasten“, der das SMTP spricht, ein. Anschließend findet die E-Mail den Weg zum Ziel, wo sie entweder abgeholt (POP3) oder zwischengespeichert (IMAP) wird. In diesem gesamten Konzept ist der Absender eher informativ und allen Beteiligten ist eigentlich klar, dass dieser gefälscht werden kann.

Offene Briefkästen, in die alle etwas einwerfen können, werden auch als Open Relay bezeichnet und sind heutzutage verpönt. Die wenigsten E-Mail-Server nehmen E-Mails von Open Relays an, weil sie – zu Recht – als Spamschleudern gelten.

DMARC, SPF und DKIM sind aber nicht als Spamschutz gedacht, sondern als Mechanismus, um die Legitimität von Absendern zu beweisen. Es hindert Spammer nicht daran, eigene Domains aufzusetzen, von denen sie legitim E-Mails versenden können. Es hindert nur Spammer, die Spam im Namen eines Anderen versenden.

Die Wirksamkeit ist im Übrigen auch dann begrenzt, wenn in SPF oder DMARC die Regeln nicht streng definiert werden. Wenn die SPF-Regel ist, dass jeder Absender gültig ist, hilft die Regel inhaltlich nicht. Sie besagt nur, dass der Domainbetreiber das Spoofing-Risiko akzeptiert. Die großen Anbieter prüfen nämlich nur, ob ein solcher Eintrag präsent nicht, nicht, wie streng er definiert ist.

Und so werden wir weiterhin beobachten, dass es immer schwieriger wird, einen eigenen Mailserver erstmals zu betreiben, während die Spammer darin Profis sind und ihr Tagwerk verrichten können. Beides treibt einen in die Fänge der großen Anbieter: Einerseits, weil sie die Anforderungen umsetzen können und andererseits, weil ihre Spamfilter genügend auf Spaminhalten trainiert werden können, um wirksam unerwünschten Nachrichten vorzubeugen.

Während wir im Server- und PC-Bereich mit Linux eine quelloffene Alternative zu proprietären Betriebssystemen haben, müssen wir uns bei mobilen Endgeräten mit Android als notwendigem Übel begnügen. Google versteckt die Entwicklung jetzt noch ein wenig mehr. Open Source ist nur noch Fassade.

Android hatte sich immer offen gegeben. Der Quellcode war über das Android Open Source Projekt verfügbar und anders als die proprietäre Konkurrenz bei Apple einsehbar und anpassbar. Um Android scharrte sich deshalb früh eine Community aus Entwicklern und Moddern.

Offenheit war jedoch immer mehr Ideal als Realität. Schon früh begann Google damit, zentrale Anwendungen und Dienste in proprietäre Komponenten auszulagern, die nicht Teil des AOSP waren. Meist als Play Services und Google Apps bezeichnet. AOSP wurde so immer mehr zu einem lauffähigen Rumpfsystem, das von der Community mit Alternativen angereichert werden musste. Trotzdem gelang es alternative Systeme wie LineageOS oder GrapheneOS zu erstellen.

Partizipativ war die Entwicklung auch nie. Hinter hochtrabenden Begriffen wie Open Handset Alliance stand immer vor allem eine Firma: Google. Googles Entwickler kontrollierten die Entwicklung und die Community konnte bestenfalls Fehler melden. In dieser Hinsicht unterschied sich Android nie von einem proprietären System.

Nun geht Google noch einen Schritt weiter und wird künftig Android hinter verschlossenen Türen entwickeln. Angeblich weil der Prozess dann effizienter ist und andere vorgeschobene Gründe. Letztlich wird der Community dann nur noch das fertige Produkt vor die Füße geschmissen.

Der nächste Schritt wird sein, dass dieser Code nicht mehr ohne proprietäre Google-Komponenten lauffähig ist. Viele wissen es nicht, aber der Kern von Apples macOS ist auch Open Source. Darwin ist nur kein lauffähiges Betriebssystem. Ich denke, dass Google diesen Weg mittelfristig auch bei Android gehen wird.

Eine Alternative haben wir leider nicht. Linux als wirklich quelloffenes System (nicht nur der Kernel wie bei Android) mit transparenter Entwicklung hat nie den Sprung auf andere Geräte als Server und PCs/Notebooks geschafft. Denn das ständige Forken und Parallelentwickeln bindet viele der ohnehin knappen Ressourcen und der mobile Bereich ist zu schnelllebig für diese ineffizienten Ansätze.

So bleibt nur zu hoffen, dass Projekte wie GrapheneOS weiterhin ein lauffähiges AOSP hinbekommen und trotz der intransparenten Entwicklung einen Überblick darüber behalten, was bei Google hinter verschlossenen Türen passiert. Vorerst bleibt alles einsehbar.

Halten Rolling-Releases länger als LTS-Releases? Dieser Artikel stellt Thesen auf, liefert aber keine Antworten.

Meine Lebenserfahrung mit Betriebssystemen kann man in vier Zeitalter einteilen:

1. DOS
2. Windows
3. Ubuntu
4. Rolling Distributionen

An die alten Zeiten mit DOS und Windows kann ich mich kaum noch erinnern, und darum soll es nicht gehen. Abgesehen von ersten Linux-Erfahrungen mit SuSE Linux 5.2 aus dem Jahre 1998 (das hiess damals noch so; heute: openSUSE), begann mein richtiger Einstieg in die Linux-Welt mit Ubuntu 6.10 (Edgy Eft) im Jahr 2006.

In den ersten Jahren habe ich jedes Ubuntu-Release installiert. Das war eine spannende Zeit, die von interessanten halbjährlichen Neuerungen geprägt war. In jedem April und Oktober habe ich mich wie ein Kind auf die Verbesserungen und Neuigkeiten im halbjährigen Ubuntu-Release gefreut; das war fast wie Weihnachten.

An diesen Feierlichkeiten habe ich ca. 10 Jahre lang teilgenommen. So ab 2015 wurde mir die Neuinstallation bzw. das Upgraden zu viel, weshalb ich auf den LTS-Pfad eingeschwenkt bin. Ab dann wurde nur noch alle zwei Jahre die Long-Term-Version neu installiert. Nachdem Canonical (die Firma hinter Ubuntu) ab den 2020er Jahren sich mit Eigenentwicklungen immer mehr von der Community entfernt hatte, begann bei mir die Zeit des Distro-Hoppings.

Letztlich bin ich bei der kuratiert-rollenden Distribution Manjaro gelandet. Während all dieser Jahre bin ich dem Gnome-Desktop treu geblieben, obwohl er bei Ubuntu auch einmal anders hiess (Unity). Ob das der Weisheit letzter Schluss war, wage ich zu bezweifeln. Nicht, weil ich Probleme mit Manjaro habe, sondern weil sich die Weltkugel der Linux-Distribution kontinuierlich weiterdreht. Wer weiss, was da noch kommt.

Genug des Vorgeplänkels; nun komme ich zum Thema.

Wie gesagt, wer sich auf ein LTS-Release-Modell verlässt, hat (theoretisch) zwei Jahre lang Ruhe und kann ein stabiles System geniessen: Nicht frickeln, sondern arbeiten ist hier die Devise. Die Release-Zeiten bei LTS-Modellen fallen unterschiedlich lang aus, aber da möchte ich jetzt keine Haarspalterei betreiben. Vorhin habe ich "theoretisch" geschrieben, weil man dennoch in hoher Kadenz mit Updates bespielt wird. Dabei handelt es sich in erster Linie um Sicherheitsupdates, was notwendig und gut ist. Je nachdem, welche Paketformate man verwendet (Flatpak), tritt die Update-Policy ohnehin in den Hintergrund, weil sich die Pakete selbst aktualisieren oder über die Flatpak-Paketverwaltung aus dem LTS-Zyklus ausbrechen.

These 1: LTS-Release-Modelle nerven durch häufige Updates genauso wie Rolling-Release-Modelle.

Obwohl Manjaro einem kuratierten rollendem Modell folgt, rauschen fast jeden Tag Updates herein. Ich fühle da kaum einen Unterschied zu einer reinen Arch-Installation. Die Updates kommen etwas später, aber sie kommen kontinuierlich.

These 2: Egal ob LTS oder Rolling, häufige Updates sind an der Tagesordnung.

Die entscheidende Frage ist, welchen Einfluss das auf die Systemstabilität hat. Rollende Distributionen haben zwei Vorteile:

1. Sie beheben spät erkannte Probleme schneller
2. Sie halten die Funktionalität auf dem neuesten Stand

Dem gegenüber gibt es Nachteile:

1. Sie führen nicht erkannte Probleme ein
2. Sie setzen höhere Kenntnisse der Anwender:innen voraus, um diese Probleme selbst zu beheben

Wie sieht der Vergleich zu LTS-Distros aus:

1. Anwendungen sind besser/länger getestet, weshalb sie weniger Probleme mit sich bringen
2. Spät erkannte Probleme hat man länger am Hals
3. Auf neue Funktionen muss man länger warten

These 3: Aufgrund der neuen Paketformate relativiert sich der Unterschied zwischen LTS und Rolling.

Nun stellt sich die Titel-Frage, wie lange Rolling Releases halten. Das Versprechen ist, dass man eine Distribution, die einem Rolling-Release-Modell folgt, nie mehr neu installieren muss. Bisher glaube ich nicht daran. Um das beurteilen zu können, muss man die Installationsdauer einer Distribution messen können. Das macht man mit diesem Befehl im Terminal:

Auf meinem Notebook:
stat -c %w / 
2023-11-17 15:04:12.000000000 +0100

Auf meinem Desktop:
stat -c %w / 
2023-04-14 08:48:38.000000000 +0200

Nun, in beiden Fällen liegt die Installation der Distribution weniger als zwei Jahre zurück, weshalb ein Vergleich mit einem 2-jährigen LTS-Update-Zyklus schwierig ist. Gelegentlich treten bei meinen Rechnern Probleme beim Update auf. In den meisten Fällen liegt es an Abhängigkeiten, die nicht aufgelöst werden können. Darüber habe ich erst neulich geschrieben. Auch heute bockte mein Desktop beim Update von ca. 125 Paketen. Wenn ich mich recht erinnere, waren es Abhängigkeiten von 32-Bit-Grafik-Bibliotheken von systemd. Durch das manuelle Löschen dieser Bibliotheken konnte ich das Problem schnell beseitigen.

These 4: Je länger man eine Rolling-Distribution betreibt, desto häufiger treten Fehler auf.

An dieser Stelle möchte ich die Fähigkeiten des Paketmanagers infrage stellen. Warum ist Pacman (bzw. Pamac) nicht in der Lage, solche einfachen zweistufigen Abhängigkeiten aufzulösen? Hier ist ein fiktives Beispiel:

Der Upate-Prozess kann nicht fortgeführt werden, weil Paket A von B abhängig ist, und Paket B von D1 und D2 benötigt wird.

Wenn ich mich recht erinnere, ist genau das die Kernaufgabe eines Paketmanagers.

Dieser Artikel bietet keine Antworten, sondern stellt Fragen. Was haltet ihr von meinen vier Thesen und wie sind eure Erfahrungen? Verrottet eine Rolling-Release-Installationen mit der Zeit? Schreibt es bitte in die Kommentare.

Titelbild: https://pixabay.com/photos/apples-rotten-apples-rotten-fruits-6694486/

Quellen: stehen im Text

Die digitalen Stromzähler (offizielle Bezeichnung: Moderne Messeinrichtung) sind inzwischen weit verbreitet. Viele können in zwei Richtungen zählen, was bei der Benutzung eines Balkonkraftwerks von großer Bedeutung sein kann. Ich habe vor einiger Zeit beschrieben, wie ich mit dem Impulsausgang auf der Vorderseite des Stromzählers den aktuellen Verbrauch ablese. Diese Methode klappt sehr gut, ist sehr einfach und braucht keine weitere Freischaltung des Netzbetreibers. Man kann einfach loslegen. Leider bringt der Impulszähler zwei Nachteile mit sich.

• Über den Impulsausgang sieht man ausschließlich den aktuellen Stromverbrauch, nichts Weiteres. Man erfährt nicht den aktuellen Zählerstand oder die Flussrichtung. Außerdem gibt es keine Kontrolle, ob alle Impulse richtig gezählt werden. Summiert man die Leistung auf, erhält man zwar einen Jahresverbrauch, kann sich aber nicht sicher sein, ob er stimmt.
• An sonnigen Tagen kommt es vor, dass man mit seinem Balkonkraftwerk mehr Strom erzeugt, als man im Haushalt verbraucht. In diesem Fall wird Strom ins Netz eingespeist. Der Impulszähler kann aber nicht unterscheiden, ob der Strom vom Netz kommt, oder ob er ins Netz geht. Folglich steigt scheinbar der Stromverbrauch im Haus, obwohl in Wirklichkeit ein Stromüberschuss erzeugt wird.

In diesem Artikel möchte ich eine alternative Auslesevariante vorstellen, die robuster und zuverlässiger arbeitet. Aussetzer in der Datenerfassung lassen sich durch späteres Zählerablesen wieder kompensieren, die Bilanz passt immer. Es können nicht nur der aktuelle Verbrauch, sondern auch die Zählerstände „in beide Richtungen“ erfasst werden. Das geschieht über das Auslesen von mehreren OBIS-Kennzahlen über die SML-Schnittstelle.

Die SML Schnittstelle des digitalen Stromzählers

Die digitalen Stromzähler haben eine zweite, wertvolle Schnittstelle: Die SML-Schnittstelle (Smart Meter Language). Über sie kommuniziert der Stromzähler mit einem genormten Protokoll (IEC 62056-6-1) mit uns Anwendern. In ihr werden die Zählerstände, der Momentanverbrauch und gelegentlich noch weitere Informationen bereitgestellt. Die Informationen sind als OBIS-Kennzahlen verfügbar und können leicht zugeordnet werden. Für mich sind die beiden OBIS-Kennzahlen 1.8.0 (Zählerstand, bezogen aus dem Netz) sowie 2.8.0 (Zählerstand, eingespeiste Energie ins Netz) relevant. Der OBIS-Kennwert 16.7.0 gibt mir die momentan bezogene Leistung aus.

Stromzähler vorbereiten: SML Schnittstelle freischalten

Standardmäßig ist diese optische Schnittstelle deaktiviert und mit einer PIN geschützt. Diese PIN erhält man meist kostenlos von seinem Netzbetreiber. Der Netzbetreiber (nicht verwechseln mit dem Stromanbieter!) ist auf dem Stromzähler und der Stromrechnung genannt. In meinem Fall sind es die Stadtwerke. Eine freundliche E-Mail mit der Bitte um Bekanntgabe der PIN unter Nennung meiner Zählernummer hat bereits gereicht.

Diese PIN muss nun mit einer Taschenlampe in die optische Schnittstelle eingeblinkt werden. Schaut euch das kurze Video von Extra 3 dazu an, darin wird der ganze Frust damit gut zusammengefasst.

Bei erfolgreicher Eingabe der PIN muss die Funktion „Inf off“ auf „Inf on“ gestellt werden. Das gelingt, indem man sich durch das Menü des Stromzählers „blinkt“ und beim entsprechenden Eintrag mind. 4 Sekunden mit der Taschenlampe leuchtet. Diese Funktion schaltet die erweiterte Funktion des Stromzählers frei. Man erkennt das später daran, dass nicht nur der Zählerstand im Display angezeigt wird, sondern auch der Momentanverbrauch.

Ist die PIN eingegeben und die erweiterte Informationsvergabe freigeschaltet, kann es endlich losgehen!

DIY Komponenten und Controller ESP8266 vorbereiten

Ich verwende für die optische Schnittstelle einen ESP8266 und das Bauteil TCRT5000. Beides erhält man für weniger als 5 Euro bei Ebay oder anderen Händlern. Der TCRT5000 ist ein optischer LED-Sensor für Infrarot, die sowohl eine LED als auch eine IR-Diode verwendet.

Die LED stört uns in diesem Fall, man muss sie vorher entfernen. Entweder zwickt man sie einfach ab, oder man lötet den Vorwiderstand von ihr weg. Ich habe mich für zweiteres entschieden. Der TCRT hat mehrere Vorteile gegenüber anderen Varianten. Manche Leute löten direkt eine IR-Diode an den ESP. Kann man natürlich machen, ich möchte nur auf die Vorteile meiner Variante hinweisen:

• die elektrischen Bauteile sind aufgeräumt auf einer Leiterplatte, keine Bauteile fliegen einzeln herum. Außerdem gibt er genügend „Angriffsfläche“, um ihn – zumindest übergangsweise – per Klebeband zu fixieren.
• die Schaltung enthält zwei kleine Status-LEDs: eine zeigt die Spannungsversorgung an, die zweite zeigt das Signal an der IR-Diode an. Vor allem die zweite Status-LED ist sehr, sehr hilfreich, wenn man die Bauteile installiert. Man erhält sofort eine Rückmeldung, ob die Diode ein Signal sieht oder nicht. Das ist besonders beim Ausrichten der Diode hilfreich, oder beim dritten Vorteil:
• über das eingebaute Potentiometer kann man die Empfindlichkeit der Diode einstellen. Das ist manchmal notwendig, wenn das Signal der Stromzähler-LED zu stark oder zu schwach ist. Dann dreht man am Poti so lange, bis man über die Status-LED ein sinnvolles Signal sieht. Weiter unten im Artikel zeige ich nochmal genauer, was ich damit meine.

Jetzt verkabelt man die Baugruppe mit dem ESP8266. Ich habe die Variante Wemos D1 mini. Dieses hat bereits die UART-Schnittstelle vorbereitet, die wir verwenden wollen. Dadurch ergibt sich folgendes Verkabelungsschema. Ob ihr das nun verlötet oder mit Jumper-Kabeln verdrahtet, bleibt euch überlassen.

ESPHome konfigurieren und aufspielen

Die Installation von ESPHome im Windows Service for Linux habe ich bereits in einem anderen Artikel beschrieben. Wir erzeugen uns eine Textdatei mit dem Dateinamen stromzaehler-sml.yaml und füllen sie mit folgendem Inhalt.

touch stromzaehler-sml.yaml 
nano stromzaehler-sml.yaml

esphome:
  name: stromzaehlersml

esp8266:
  board: d1_mini

# Enable logging
logger:
  level: VERY_VERBOSE # kann spaeter auf DEBUG verringert werden
  logs:
    sml: DEBUG
    text_sensor: DEBUG
# Enable Home Assistant API
api:
  password: ""

ota:
  password: ""

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  manual_ip:
    static_ip: 
    gateway: 
    subnet: 
  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Stromzaehler Sml"
    password: ""

captive_portal:

uart:
  id: uart_bus
  tx_pin: GPIO1
  rx_pin: GPIO3 # dieser GPIO ist wichtig, hier ist das Signalkabel angeschlossen
  baud_rate: 9600
  data_bits: 8
  parity: NONE
  stop_bits: 1

sml:
  id: mysml
  uart_id: uart_bus

sensor:
  - platform: sml
    name: "Total energy SML 180"
    sml_id: mysml
    server_id: "0123456789abcdef"
    obis_code: "1-0:1.8.0"
    unit_of_measurement: kWh
    accuracy_decimals: 3
    device_class: energy
    state_class: total_increasing
    filters:
      - multiply: 0.0001
  - platform: sml
    name: "Total energy SML 280"
    sml_id: mysml
    server_id: "0123456789abcdef"
    obis_code: "1-0:2.8.0"
    unit_of_measurement: kWh
    accuracy_decimals: 3
    device_class: energy
    state_class: total_increasing
    filters:
      - multiply: 0.0001
  - platform: sml
    name: "Stromverbrauch SML 1670"
    sml_id: mysml
    server_id: "0123456789abcdef"
    obis_code: "1-0:16.7.0"
    unit_of_measurement: W
    accuracy_decimals: 0
    device_class: energy
    filters:
      - multiply: 1.0
text_sensor:
  - platform: sml
    name: "Total energy text"
    sml_id: mysml
    server_id: "0123456789abcdef"
    obis_code: "1-0:1.8.0"

Es müssen folgende Zeilen angepasst werden:

• Wifi Zugangsdaten
• Feste IP-Adresse (kann auch erst im zweiten Schritt erfolgen)
• die server_id passen wir an, sobald wir sie kennen. Sie ist ggf. auf den Stromzähler aufgedruckt. Weiter unten im Artikel finden wir sie aber auch über die SML-Schnittstelle heraus.

Zur Erklärung: Die Kommunikation zwischen unserer IR-Diode und dem ESP erfolgt über ein Protokoll namens UART. Diese Schnittstelle wird in den Zeilen nach uart: konfiguriert. Der GPIO-Pin 3 ist dabei derjenige, der auf dem Wemos D1 Mini mit RX gekennzeichnet ist. Falls ihr einen anderen verwendet, müsst ihr diese Zeile anpassen. Die SML Schnittstelle wird ab Zeile sml: konfiguriert. Die meisten Einstellungen könnt ihr so lassen, wie es oben beschrieben ist. Die wichtigen Zeilen sind die mit server_id. Dort wird die Server-Adresse eingestellt. Vermutlich kennt ihr sie nicht von Anfang an, lasst also erstmal die Voreinstellung. Wir ändern sie später, sobald wir sie erfahren haben.

Speichert die Datei nun und kompiliert sie über den Befehl

esphome run stromzaehler-sml.yaml

Nach ein paar Augenblicken ist der Vorgang abgeschlossen und irgendwo wird eine Datei namens firmware.bin abgelegt. Der Pfad ist in der Textausgabe angegeben, bei mir war es

.esphome/build/stromzaehlersml/.pioenvs/stromzaehlersml/firmware.bin

Nun flashen wir die Datei auf den ESP8266. Dazu benutzen wir den Google Chrome (oder einen anderen kompatiblen Browser) und gehen auf die Webseite https://web.esphome.io Schließt den ESP mit einem USB-Kabel an den PC an. Auf der Webseite sollte ein Popup erscheinen.

Sollte dieser Schritt nicht funktionieren, liegt das sehr wahrscheinlich am USB-Kabel. Tauscht das Kabel gegen ein anderes, nicht alle Kabel sind dafür geeignet! Folgt den Anweisungen auf der Webseite, um die Datei firmware.bin auf den ESP zu flashen.

Kontrolliert nach dem Flashen, ob ihr den ESP in eurem WLAN findet. Falls ja, großartig! Wir binden ihn gleich in Home Assistant ein. Gehe in Home Assistant auf Einstellungen → Geräte und Dienste → Integration hinzufügen → ESPHome

Baut jetzt den ESP in der Nähe eures Stromzählers auf. Versorgt ihn mit Spannung (z.B. über ein Handy-Netzteil) und richtet die IR-Diode richtig aus. Jetzt hilft euch die Status-LED vom TCRT5000. Sollte sie regelmäßig blinken, habt ihr schon viel geschafft. Ich habe mit einem kleinen Schraubendreher das Poti noch so verstellt, bis ein wirklich sauberes Signal angekommen ist.

Auslesen der Daten und Einbindung in Home Assistant

Ruft die Logs des Controllers auf. Über Home Assistant gibt es die entsprechende Schnittstelle, über WSL geht das mit dem Befehl

esphome logs stromzaehler-sml.yaml

Wenn alles bis hierher geklappt hat, müsste die Ausgabe sich stetig erweitern. Darin müssten auch Einträge nach dem folgenden Format auftauchen:

Hier findet ihr auch die Server-ID, die wir anfangs noch nicht kannten. Sie steht in runden Klammern und ist im Screenshot rot eingerahmt. Kopiert sie euch und fügt sie in der YAML-Datei in Zeilen, wo die server_id eingetragen werden muss (insgesamt vier mal).

Zur Kontrolle der Validität der Daten, könnt ihr den HEX-Wert mal umrechnen und checken, ob der Stromzählerwert korrekt übertragen wird. Im Beispiel oben:

0x056f8b25 entspricht 91196197. Multipliziert mit 0,0001 ergibt 9119,6 kWh

Ändert nun die YAML-Datei auf die für euch wichtigen Werte (Server-ID und ggf. andere OBIS-Codes) und flasht sie kabellos („Over the air“) auf den ESP

esphome run stromzaehler-sml.yaml

Seht im Home Assistant, ob die Werte dort ankommen. In aller Regel kommen die Werte dort an und können weiter verarbeitet werden. Ich habe mir noch einen Helfer gebaut, der den aktuellen Verbrauch in Kilowatt umrechnet. Das lässt sich mit anderen Energiequellen schöner in Diagrammen darstellen.

Fertig, ihr habt es geschafft! Kommentiert gerne, ob ihr diese Werte für andere Zwecke weiterverwendet. Realisiert ihr damit eine Nulleinspeisung oder beobachtet den Strompreis in Echtzeit?

Weiterführende Quellen: https://esphome.io/components/sml.html

The post Digitalen Stromzähler auslesen mit SML und ESPHome first appeared on bejonet - Linux | Smart Home | Technik.