TRMNL X im Test: E-Ink wird salonfähig

Ich suche schon seit Jahren nach einem guten Infoscreen. Nicht nach einem weiteren Tablet, das mich mit Benachrichtigungen ablenkt. Nicht nach einem Fernseher an der Wand. Ich möchte eine ruhige Fläche, die mir im Vorbeigehen genau die Informationen zeigt, die gerade wichtig sind: Kalender, Wetter, Aufgaben, ein paar Kennzahlen und im Büro vielleicht den Zustand meiner wichtigsten Security-Systeme.

Mein erster ernsthafter Versuch war ein Raspberry Pi mit angeschlossenem Bildschirm. Technisch funktionierte das. Praktisch störte mich aber genau das, was bei normalen Displays kaum zu vermeiden ist. Der Bildschirm leuchtet dauerhaft, braucht Strom und wirkt selbst dann wie ein aktives Gerät, wenn man ihn gar nicht beachtet. Irgendwann hat man nicht mehr das Gefühl, eine Informationstafel zu besitzen, sondern einen weiteren kleinen Computer, um den man sich kümmern muss.

Deshalb hat mich E-Ink schon früh fasziniert. Die Anzeige wirkt eher wie bedrucktes Papier als wie ein leuchtender Bildschirm. Ein einmal dargestelltes Bild bleibt stehen, ohne dass das Panel permanent Energie dafür benötigt. Strom wird vor allem dann gebraucht, wenn das Gerät aufwacht, Daten über WLAN abruft und die Anzeige aktualisiert. Genau das passt zu einem Infoscreen, der nicht jede Sekunde neu zeichnen muss.

Das Problem war bisher der Preis. Größere E-Ink-Panels waren vor einigen Jahren extrem teuer und sind es zu einem erheblichen Teil noch immer. Ein kleines Panel ist bezahlbar. Bei 13 Zoll wird es bereits deutlich teurer, und wer in Richtung 25, 27 oder 32 Zoll schaut, landet schnell im vierstelligen Bereich. Bei kompletten großen Farbgeräten und professioneller Signage sind Preise in der Nähe von 2.500 Dollar keine absurde Ausnahme.

Dann kam TRMNL, ausgesprochen wie Terminal.

Vier Monate angekündigt, fast neun Monate gewartet

Ich hatte TRMNL schon lange im Blick, bevor ich schließlich bestellt habe. Bei der Bestellung war von ungefähr vier Monaten Lieferzeit die Rede. Daraus wurden am Ende fast neun Monate.

Trotz dieser deutlichen Verzögerung gab es allerdings keine monatelange Funkstille. Der Gründer meldete sich regelmäßig mit Updates und erklärte in Newslettern und Videos, weshalb sich die Auslieferung verschob, wo Lieferprobleme auftraten und an welchen Stellen die Qualität noch nicht seinen eigenen Ansprüchen genügte. Statt die Verzögerungen mit unverbindlichen Durchhalteparolen zu überbrücken, machte er nachvollziehbar, woran es gerade hing und welche Schritte noch nötig waren. Das verkürzte die Wartezeit natürlich nicht, wirkte auf mich aber sehr transparent und sympathisch. Ich wusste nicht immer, wann mein TRMNL tatsächlich eintreffen würde, aber immerhin ziemlich genau, warum es noch nicht unterwegs war.

Ich glaube, auf kaum ein anderes Technikprodukt habe ich nach einer Bestellung so lange gewartet. Mein Tesla Model Y war ebenfalls eine Geduldsprobe, aber dort lagen zwischen Wunsch und Auslieferung auch zwei oder drei Jahre. Bei einem kleinen E-Ink-Display fühlt sich jeder zusätzliche Monat etwas absurder an. Man bestellt ein überschaubares Gerät und beginnt irgendwann zu zweifeln, ob es tatsächlich noch kommt.

Als das Paket schließlich bei mir zu Hause ankam, war es deshalb eine kleine Geburt. Das klingt bei einem 10,3-Zoll-Display vielleicht dramatisch, aber nach neun Monaten war das Auspacken mehr als nur der normale Start mit einem neuen Gadget.

Mein Gerät habe ich selbst gekauft. Dieser Beitrag ist nicht gesponsert und enthält keinen Affiliate-Link. Meine Alltagserfahrung bezieht sich auf den neuen TRMNL X mit 10,3 Zoll. Ich habe die Variante mit dem größeren Akku bestellt, also mit insgesamt 12.000 mAh statt 6.000 mAh. Den aktuellen Stand der offenen Firmware, des Frameworks, der Plugins und der Self-Hosting-Optionen habe ich am 28. August 2026 anhand der Herstellerdokumentation und der öffentlichen Repositories geprüft.

Was TRMNL eigentlich ist

Die Hardware wirkt von außen bewusst unspektakulär. Das 10,3 Zoll große E-Paper-Panel löst mit 1.872 × 1.404 Pixeln auf, erreicht 227 ppi und stellt 16 Graustufen dar. Das Panel arbeitet somit mit 4 Bit pro Pixel. Auf der Vorderseite befindet sich kein Logo. Das passt gut zu einem Gerät, das im Raum eher wie ein ruhiger Bilderrahmen als wie ein beworbenes Gadget wirken soll.

Das verschraubte Gehäuse lässt sich öffnen und ist ausdrücklich moddingfreundlich gedacht. Das X misst 233 × 193 × 12 Millimeter. Mit einem Akku nennt der Hersteller 365 Gramm, mit den beiden Akkus meiner Konfiguration 450 Gramm. TRMNL strebt IP65 an, die Zertifizierung ist laut aktueller Spezifikation aber noch ausstehend. Dasselbe gilt beim X derzeit für mehrere weitere Prüfzeichen wie FCC, CE und RoHS. Ich würde es deshalb trotz des konstruktiven Staub- und Wasserschutzes noch nicht wie ein entsprechend zertifiziertes Gerät behandeln.

Geladen wird über USB-C oder über das magnetische Dock. Für die Aufstellung und Montage nennt TRMNL einen Standfuß, eine Wandhalterung und einen integrierten Magneten. Das Dock verbindet Stromversorgung und Zubehör über Pogo-Pins und dient auch für einen Hard Reset.

Das ist ein wichtiger Unterschied zu einem Tablet. TRMNL hält nicht dauerhaft eine Webseite offen. Es führt auch nicht im Hintergrund zwanzig Apps aus. Der Server bereitet den Inhalt als Bild auf, das Gerät holt dieses Bild ab, zeichnet es auf das Panel und verschwindet wieder in seinem stromsparenden Zustand. Der eingestellte Aktualisierungsrhythmus bestimmt deshalb wesentlich mit, wie lange der Akku hält.

Der Hersteller nennt für das X bei typischer Nutzung ungefähr drei bis sechs Monate Laufzeit. Das Gerät unterstützt eine oder zwei automatisch erkannte 6.000-mAh-LiPo-Batterien. In meiner Konfiguration stecken somit 12.000 mAh. Solche Angaben hängen immer von WLAN-Empfang, Bildinhalt und Aktualisierungsintervall ab. Ab Werk ist ein Refresh alle 15 Minuten eingestellt, der Rhythmus lässt sich anpassen. Der entscheidende Punkt ist für mich nicht, ob es am Ende exakt drei, vier oder sechs Monate sind. Entscheidend ist, dass ich kein Stromkabel zum Standort führen und das Gerät nicht jeden Abend laden muss.

Es gibt keinen klassischen Touchscreen, keine ständig offene Verbindung und keine App-Oberfläche auf dem Display. Das X besitzt stattdessen eine Gestenleiste und einen Bosch-Beschleunigungssensor, der unter anderem die Ausrichtung im Hoch- oder Querformat erkennt. Die eigentliche Konfiguration findet weiterhin im Web-Dashboard statt.

Diese Reduktion ist kein fehlendes Feature. Sie ist der Kern des Produkts.

Was bei einem Refresh technisch passiert

Der TRMNL X ist kein verkleinertes Linux-System und erst recht kein Browser im Bilderrahmen. Als Hauptprozessor arbeitet ein ESP32-S3 mit 16 MB Flash und 8 MB PSRAM. Das öffentliche Firmware-Projekt bestätigt diese Bestückung mit dem Buildprofil esp32s3_n16r8. Das reicht für WLAN, TLS, PNG-Decoding, Display-Ansteuerung und Firmware-Updates. Eine moderne Webanwendung mit JavaScript, mehreren Tabs und lokalem Rendering wäre auf dieser Hardware dagegen völlig fehl am Platz.

Was ein ESP32-Controller eigentlich ist

Ein ESP32 ist ein Mikrocontroller. Auf einem kleinen Chip sitzen Rechenkerne, Arbeitsspeicher, Flash-Speicher sowie Schnittstellen für WLAN, Sensoren und andere Elektronik. Er führt eine speziell für das Gerät geschriebene Firmware aus. Es gibt kein vollwertiges Desktop-Betriebssystem, keinen normalen Browser und keine ständig laufende Sammlung von Hintergrunddiensten. Nach dem Einschalten erledigt der Chip eine klar definierte Aufgabe und kann sich anschließend fast vollständig schlafen legen.

Ein Raspberry Pi ist dagegen ein Einplatinencomputer. Er besitzt wesentlich mehr Rechenleistung, kann Linux starten, einen Browser ausführen, Datenbanken betreiben und Inhalte direkt lokal rendern. Diese Flexibilität war bei meinem früheren Infoscreen praktisch, bringt aber auch den typischen Ballast eines Computers mit: Das Betriebssystem muss booten, Prozesse und Netzwerkdienste laufen weiter, Updates wollen installiert werden und die SD-Karte beziehungsweise das Dateisystem kann bei einem unsauberen Ausschalten Probleme verursachen.

Für TRMNL wäre diese zusätzliche Leistung meistens ungenutzt. Das Gerät muss keine Webseite berechnen und keinen Kalender lokal zusammensetzen. Der Server erledigt Rendering, Plugins und Zeitplanung. Der ESP32 wacht lediglich auf, verbindet sich mit dem WLAN, lädt ein fertiges Bild, überträgt es an das E-Paper-Panel und wechselt wieder in den Deep Sleep. Dadurch ist das Wachfenster kurz und der Energiebedarf im Ruhezustand sehr gering. Genau dieser Ablauf ermöglicht eine Akkulaufzeit von Monaten statt eines dauerhaft angeschlossenen Netzteils.

Auch die Startzeit und Wartung sprechen für den Mikrocontroller. Ein ESP32 kann nach dem Aufwachen beinahe sofort seine Firmware starten, während ein Raspberry Pi zunächst Linux und seine Dienste laden müsste. Gleichzeitig ist die Angriffs- und Fehlerfläche kleiner, weil keine allgemeine Linux-Installation mit zahlreichen Paketen gepflegt werden muss. Ein Raspberry Pi ist die bessere Wahl, wenn Inhalte direkt auf dem Gerät gerendert, komplexe Anwendungen ausgeführt oder mehrere Dienste betrieben werden sollen. Für einen E-Paper-Client mit einer einzigen, gut definierten Aufgabe ist der ESP32 dagegen das passendere Werkzeug.

Für 5-GHz-WLAN sitzt zusätzlich ein ESP32-C5 als Modem im Gerät und nutzt eine externe Antenne. Das 2,4-GHz-WLAN des ESP32-S3 bleibt als Rückfallebene erhalten. Laut Datenblatt werden 802.11 b/g/n/ac und BLE unterstützt. Neben Beschleunigungs- und Gestensensor ist auch ein Temperatursensor eingebaut. Für eigene Erweiterungen gibt es einen Qwiic-Anschluss. Über USB-OTG kann das X Zubehör am Dock mit 5 Volt und bis zu 1,2 Ampere versorgen. Diese Schnittstellen sind im normalen Dashboard-Betrieb nicht nötig, machen das Gerät aber für eigene Sensoren, Zubehör und Hardware-Mods deutlich interessanter.

TRMNL verschiebt die schwere Arbeit deshalb auf den Server. Ein kompletter Aktualisierungszyklus sieht vereinfacht so aus:

1. Ein Timer weckt den Controller aus dem Deep Sleep.
2. Das Gerät verbindet sich mit dem bekannten WLAN und ruft den Display-Endpunkt des eingestellten Servers auf.
3. Die Anfrage enthält die Gerätekennung beziehungsweise MAC-Adresse, einen Zugriffsschlüssel sowie Betriebsdaten wie Firmware-Version, Batteriespannung und WLAN-Signalstärke.
4. Der Server bestimmt anhand von Playlist, Zeitplan und Bedingungen, welcher Plugin-Inhalt als Nächstes angezeigt werden soll.
5. Daten aus Kalendern, APIs, Webhooks oder anderen Plugins werden mit Liquid und dem TRMNL Framework in ein E-Paper-taugliches Layout eingesetzt. Der Server rendert daraus ein PNG in der Auflösung und Farbtiefe des gewählten Gerätemodells.
6. Das Display lädt die Bilddatei, schreibt sie mit dem passenden Panel- und Temperaturprofil auf das E-Paper und fällt anschließend wieder in den Schlafzustand.

Die Antwort des Servers ist klein. Sie enthält nicht den gesamten Kalender und auch kein HTML-Dokument, das erst auf dem Gerät ausgeführt werden müsste. Vereinfacht sieht sie ungefähr so aus:

{
  "status": 0,
  "image_url": "https://server.example/screens/next.png",
  "filename": "calendar-2026-08-26T08-30-00Z",
  "refresh_rate": 1800,
  "update_firmware": false,
  "reset_firmware": false
}

refresh_rate: 1800 bedeutet in diesem Beispiel, dass der nächste Abruf nach 1.800 Sekunden, also nach 30 Minuten, erfolgen soll. Über update_firmware und eine zusätzliche Firmware-URL kann derselbe Antwortpfad auch ein OTA-Update anstoßen. Für einen eigenen Server müssen im Kern nur wenige stabile Endpunkte nachgebildet werden, vor allem Setup, Display und Logs.

In der TRMNL-Cloud besitzt jedes Gerät einen eigenen API-Schlüssel, den der Client als access-token mitsendet. Ein Abruf von /api/display schaltet die Playlist serverseitig zum nächsten passenden Inhalt weiter. Zwei Geräte sollten diesen Schlüssel deshalb nicht versehentlich teilen, sonst würden sie abwechselnd unterschiedliche Playlist-Einträge abrufen. Für eine reine Spiegelung stellt TRMNL stattdessen einen Endpunkt für den aktuell gerenderten Screen bereit. Dieses Detail zeigt, dass Gerätekennung, Playlist-Zustand und Zugriffsschlüssel im Cloud-Modell eng zusammengehören.

Diese Trennung erklärt gleich mehrere Eigenschaften des Produkts. Der Client bleibt klein, stromsparend und vergleichsweise leicht auf andere Hardware zu portieren. Das Layout sieht auf allen gleichartigen Geräten identisch aus, weil das Ergebnis bereits ein Bild ist. Gleichzeitig wandert die Komplexität zum Server. Dort müssen Plugins ausgeführt, Datenquellen abgefragt, Bilder gerendert, Playlists geplant und Geräte verwaltet werden.

Warum der Akku Monate statt Stunden hält

E-Paper ist bistabil. Vereinfacht gesagt bleiben die schwarzen und weißen Pigmente nach dem Anlegen der elektrischen Felder an ihrer Position. Das Panel braucht deshalb keine dauerhafte Energie, um ein bereits gezeichnetes Bild sichtbar zu halten. Energie kostet der Wechsel des Bildes, und noch mehr Energie kostet das WLAN.

Ohne konsequenten Deep Sleep würde die Laufzeit trotz des großen Akkus massiv einbrechen. Die eigentliche Optimierung besteht deshalb nicht nur im E-Paper-Panel, sondern in einem möglichst kurzen Wachfenster: Controller starten, WLAN verbinden, TLS-Verbindung aufbauen, Bild laden, Panel aktualisieren, wieder schlafen.

Ein Batteriemanagement-Chip von Texas Instruments misst nicht nur einen groben Spannungswert, sondern verfolgt Ladezustand, Gesundheitszustand und Kapazität des Akkus. Gerade bei zwei automatisch erkannten 6.000-mAh-Packs ist das sinnvoller als eine Prozentanzeige, die lediglich aus der aktuellen Spannung geschätzt wird.

Darum wirken sich kleine Einstellungen stark aus. Ein Refresh alle fünf Minuten weckt das Funkmodul sechsmal häufiger als ein Refresh alle 30 Minuten. Schlechter WLAN-Empfang verlängert die Verbindungszeit. Große oder stark geditherte Bilder brauchen mehr Daten und mehr Zeit zum Decodieren. Kalender und Statusseiten mit großen einfarbigen Flächen sind für diese Architektur nahezu ideal.

Beim Display selbst nennt die aktuelle Spezifikation einen Bereich von ungefähr 200 Millisekunden bis 1,3 Sekunden, abhängig von der Art der Aktualisierung. Ein kompletter Bildwechsel bleibt damit als typischer E-Paper-Refresh sichtbar, dauert aber nicht lange. Partielle Aktualisierungen erlauben schnellere Änderungen einzelner Bereiche, ohne jedes Mal die gesamte Fläche neu aufzubauen.

Die Einrichtung ist erfreulich langweilig

Nach dem Einschalten stellt TRMNL ein WLAN für die Ersteinrichtung bereit. Man verbindet sich, hinterlegt die eigenen WLAN-Daten und verknüpft das Gerät mit dem TRMNL-Konto. Danach baut man im Browser eine Playlist zusammen.

Das Prinzip kennt man von Musikdiensten, nur dass statt Songs verschiedene Informationsseiten rotieren. Ein Kalender kann am Morgen häufiger erscheinen, eine Aufgabenliste während der Arbeitszeit und ein Foto am Abend. Inhalte lassen sich zeitlich steuern, und bis zu vier Datenquellen können als sogenannte Mashups auf einer gemeinsamen Seite landen.

Genau hier wird aus einem kleinen E-Ink-Panel ein nützliches Produkt. Die Hardware allein wäre nur ein hübscher Rahmen mit Akku. Das Web-Dashboard und die Plugins entscheiden darüber, ob das Gerät nach zwei Wochen in einer Schublade liegt oder täglich gebraucht wird.

Ich verwende TRMNL vor allem für meinen Kalender. Das ist ein erstaunlich guter Anwendungsfall, weil Termine nicht sekündlich aktualisiert werden müssen. Ich sehe im Vorbeigehen, was als Nächstes ansteht, ohne das Smartphone zu entsperren oder im Browser einen Kalender-Tab zu suchen. Wetter, Aufgaben, Fotos, Analytics und andere Informationen funktionieren nach demselben Muster.

Ein guter TRMNL-Screen beantwortet eine Frage in wenigen Sekunden. Wenn ich davor stehen bleiben, scrollen oder eine Legende studieren muss, habe ich zu viele Informationen hineingepackt.

Das Plugin-Ökosystem ist die eigentliche Stärke

Als ich meinen TRMNL bestellt habe, standen ungefähr 450 Plugins und Integrationen zur Auswahl. Schon während der langen Wartezeit kamen laufend neue hinzu. Mittlerweile sind es deutlich mehr als 1.000, die aktuelle X-Spezifikation nennt mindestens 1.231 vorgefertigte Integrationen. Dazu gehören Kalender, Wetterdienste, Aufgabenlisten, Fotos, Finanzdaten, YouTube Analytics, Smart-Home-Informationen und zahlreiche Community-Projekte.

Diese Entwicklung sagt für mich fast mehr aus als die reine Zahl. Neun Monate lang konnte ich beobachten, wie neue Recipes, Integrationen und Ideen dazukamen, obwohl mein Gerät noch gar nicht ausgeliefert war. Hinter TRMNL arbeitet offensichtlich nicht nur der Hersteller an ein paar vorgegebenen Funktionen. Eine sehr aktive Community erweitert das System kontinuierlich und zeigt, wie unterschiedlich ein ruhiger E-Ink-Screen genutzt werden kann.

Schaut selbst in der TRMNL-Integrationsübersicht nach, ob für euch etwas dabei ist.

Nicht jedes Plugin ist für jeden sinnvoll, und eine große Zahl allein sagt noch nichts über Qualität aus. Trotzdem verändert die Breite des Angebots das Produkt. Ich muss nicht für jede einfache Anzeige erst eine eigene Anwendung bauen. Ich kann mit bestehenden Plugins beginnen, mehrere Ansichten zu einer Playlist kombinieren und nur dort selbst entwickeln, wo meine Anforderungen spezieller werden.

Das System ist außerdem offen genug, dass sich ein eigenes Plugin vergleichsweise unkompliziert umsetzen lässt. Ein Private Plugin kann Daten regelmäßig von einer HTTPS-URL abholen. Die Antwort kommt typischerweise als JSON. Das Layout wird mit HTML, CSS und Liquid-Variablen beschrieben. Im Markup-Editor stehen eine Echtzeitvorschau sowie bei Bedarf eigenes CSS und JavaScript zur Verfügung. TRMNL rendert daraus das Bild, das später auf dem Gerät erscheint.

Was das TRMNL Framework beim Rendering übernimmt

Das TRMNL Framework ist nicht bloß eine Sammlung hübscher CSS-Klassen. Es definiert die Struktur aus Screen, View, Layout, Titelzeile, Spalten und Mashups. Dazu kommen Komponenten für Tabellen, Diagramme, Fortschrittsanzeigen, Bilder und Typografie. Das ist wichtig, weil ein E-Paper-Layout weder scrollen noch nachträglich auf Benutzereingaben reagieren kann. Überlaufender Text muss vor dem Rendern gekürzt, verkleinert oder auf eine sinnvolle Zahl von Zeilen begrenzt werden.

Framework 3.1 war dabei ein wichtiger Schritt für das TRMNL X. Die Version führte unter anderem eine auf CSS-Variablen basierende Farbarchitektur, zusätzliche Graustufen, hochauflösende Render-Modi und responsive Hilfsklassen ein. Ein Plugin kann dadurch auf Gerätegröße, Hoch- oder Querformat und Farbtiefe reagieren. Ein Präfix wie lg: bezieht sich nicht einfach auf die aktuelle Browserbreite, sondern auf die Größenklasse des Zielgeräts. Mit 4bit: lässt sich gezielt die 16-stufige Graustufendarstellung des X ansprechen.

Das bedeutet nicht, dass das monochrome X plötzlich Farben anzeigen kann. Semantische Rollen wie Erfolg, Warnung oder Fehler werden auf die Palette abgebildet, die das jeweilige Zielgerät tatsächlich beherrscht. Ein bestehendes Plugin funktioniert grundsätzlich weiter, kann mit größeren Schriftstufen, Container-Abfragen, intelligentem Spaltenumbruch und eigenen Regeln für das Hochformat aber wesentlich besser an die größere Fläche des X angepasst werden.

Vor dem Screenshot läuft außerdem der JavaScript-basierte Framework Runtime Pass. Er misst den fertigen Screen, behandelt Überläufe, kürzt Text, passt Werte an den verfügbaren Platz an und richtet Schriften pixelgenau aus. Eigenes JavaScript eines Plugins läuft somit in der Renderumgebung, bevor das PNG erzeugt wird. Es läuft nicht als Webanwendung auf dem ESP32. Diese Trennung ist wichtig, weil sie flexible Layouts erlaubt, ohne den stromsparenden Client mit einem Browser auszustatten.

Die verlinkte Dokumentation 3.1 ist inzwischen nicht mehr die neueste Fassung. Mit Stand dieser Prüfung führt TRMNL Framework 3.3. Dort kommen unter anderem Themes, eine TRMNLPaint-Schnittstelle für JavaScript sowie an Geräte und Themes angepasste Diagramme, Karten und Icons hinzu. Der Grundgedanke bleibt gleich: Plugin-Autoren beschreiben die Information einmal, das Framework passt ihre Darstellung an die Fähigkeiten des Zielgeräts an.

Der Developer-Bereich von TRMNL geht außerdem über einzelne Plugins hinaus. Neben der normalen REST-API gibt es eine Partner-API für vorkonfigurierte Geräte, automatisches Provisioning und Flottenverwaltung. Ein Anbieter kann seine eigene Anwendung dadurch mit einem bereits zugeordneten Plugin und einer vorbereiteten Einrichtung ausliefern. Für meinen privaten Kalender ist das nebensächlich, für Statusanzeigen in Unternehmen macht es aus einem einzelnen Gadget jedoch eine grundsätzlich skalierbare Plattform.

Für ein persönliches Security-Dashboard könnte eine bewusst reduzierte API beispielsweise nur diesen Status liefern:

{
  "checked_at": "2026-08-26 08:30",
  "critical_incidents": 0,
  "open_incidents": 2,
  "vpn_status": "ok",
  "backup_age_hours": 9
}

Im Markup werden die Felder anschließend mit Liquid eingesetzt:

<div class="layout">
  <div class="columns">
    <div class="column">
      <span class="title">Security Status</span>
      <span class="value">{{ critical_incidents }}</span>
      <span class="label">kritische Vorfälle</span>
    </div>
    <div class="column">
      <span class="title">VPN</span>
      <span class="value">{{ vpn_status }}</span>
      <span class="label">Backup vor {{ backup_age_hours }} Stunden</span>
    </div>
  </div>
</div>

Das Beispiel ist absichtlich simpel. Man braucht keinen kompletten Frontend-Stack, keine native App und keinen Prozess, der permanent auf dem Display läuft. Wer bereits eine API oder ein kleines Skript hat, das sauberes JSON liefert, kommt schnell zu einer brauchbaren Anzeige.

Hinter dem Wort Plugin verbergen sich dabei mehrere Modelle. Native Plugins werden von TRMNL gepflegt und übernehmen beispielsweise Google Calendar oder Shopify. Ein Private Plugin gehört nur zum eigenen Konto und erhält seine Daten per Polling, Webhook oder aus anderen Plugin-Instanzen. Eine veröffentlichte Recipe ist im Wesentlichen ein geprüftes Private Plugin, das andere mit einem Klick installieren oder als eigene Variante forken können. Installierte Recipes erhalten spätere Verbesserungen des Autors automatisch. Ein Fork lässt sich frei verändern, wird dafür aber nicht mehr mit dem Original synchronisiert. Das Screenshot-Plugin lässt TRMNL dagegen in Intervallen eine vorhandene Webseite rendern. Ein Third-Party-Plugin bringt schließlich eine externe Anwendung und einen vereinfachten OAuth2-Flow mit. Dort liegen Betrieb, Authentifizierung und der Umgang mit personenbezogenen Daten beim Plugin-Anbieter.

Für mein Security-Dashboard würde ich mit einem Private Plugin beginnen. Der Server kann JSON, RSS, XML, CSV oder Klartext abholen, optional mit eigenen HTTP-Headern. Alternativ schiebt ein interner Prozess die bereits verdichteten Werte per Webhook an TRMNL. Das ist meist sauberer, als einem externen Poller direkten Zugriff auf ein internes Monitoring-System zu geben.

Wichtig ist die Richtung des Datenflusses. Beim Polling durch die TRMNL-Cloud muss der Datenendpunkt von außen erreichbar sein oder über einen kontrollierten Vermittler laufen. API-Schlüssel liegen dann als Plugin-Konfiguration auf der Plattform. Bei einem Webhook sendet mein System die Daten aktiv an TRMNL. Mit BYOS kann der gesamte Ablauf im eigenen Netz bleiben. Dieselbe hübsche Anzeige kann also je nach Betriebsmodell eine völlig andere Sicherheitsarchitektur haben.

Die Herausforderung liegt weniger im Code als in der Auswahl. Die 1.872 × 1.404 Pixel des X bieten zwar erheblich mehr Platz als beim OG, die physische Fläche bleibt aber 10,3 Zoll groß. Jede zusätzliche Kennzahl ist deshalb weiterhin eine Entscheidung gegen die Lesbarkeit aus der Distanz. Gerade bei einem Security-Dashboard würde ich nicht versuchen, ein SIEM im Bilderrahmen nachzubauen. Besser sind wenige Zustände, die man sofort versteht: Gibt es einen kritischen Vorfall? Sind Backup und VPN in Ordnung? Wann wurden die Daten zuletzt geprüft?

Ein Security-Dashboard ist keine Alarmierung

TRMNL passt gut zu meinem Wunsch, bestimmte Security-Informationen im Büro proaktiv im Blick zu behalten. Es gibt aber eine wichtige Grenze. Das Gerät holt Inhalte in Intervallen ab. Es besitzt keine dauerhafte Push-Verbindung und soll genau das auch nicht haben. Ein TRMNL ist deshalb eine Übersicht, kein verlässlicher Alarmkanal.

Für einen kritischen Incident brauche ich weiterhin Push, E-Mail, Pager oder einen anderen aktiv überwachten Weg. Auf dem E-Ink-Screen kann ich den allgemeinen Zustand sehen und vielleicht früher bemerken, dass eine Kennzahl ungewöhnlich aussieht. Ich darf mich aber nicht darauf verlassen, dass die nächste Aktualisierung schnell genug kommt oder dass ich gerade in die richtige Richtung schaue.

Auch bei den Daten selbst würde ich streng reduzieren. Auf ein frei sichtbares Display gehören keine Benutzernamen, internen IP-Adressen, Kundendaten, Tickets mit vertraulichem Inhalt oder API-Schlüssel. Die Anzeige sollte nur bereits verdichtete Werte erhalten. Das Backend kann aus sensiblen Quellen lesen, aber der Endpunkt für TRMNL sollte daraus minimale, für den Screen bestimmte Informationen erzeugen.

Die Architektur hilft dabei. Das Gerät initiiert die Verbindung und zieht seinen nächsten Screen vom Server. Es muss nicht aus dem Internet erreichbar sein. Das reduziert die eingehende Angriffsfläche, macht das Gesamtsystem aber nicht automatisch risikofrei. Wer die TRMNL-Cloud nutzt, vertraut dieser Plattform die eingebundenen Datenquellen und die gerenderten Inhalte an. Wer mehr Kontrolle benötigt, kann den Server selbst betreiben.

Wie Open Source ist TRMNL wirklich?

Bei Hardware wird schnell mit Open Source geworben, obwohl am Ende nur ein alter Kernel-Fork oder ein kaum dokumentiertes Repository öffentlich ist. Bei TRMNL lohnt sich eine genauere Trennung der einzelnen Schichten.

Die Firmware für die Geräte ist unter GPL-3.0 verfügbar. Sie enthält die Logik für WLAN-Einrichtung, Kommunikation mit dem Server, OTA-Updates, PNG-Decoding, Panel-Ansteuerung, Temperaturprofile, Graustufen und Deep Sleep. Man kann sie einsehen, verändern, selbst kompilieren und auf unterstützte ESP32-Hardware flashen. Das Repository enthält eigene Buildziele für OG und X. TRMNL warnt allerdings, dass der main-Branch laufend weiterentwickelt wird und Breaking Changes enthalten kann. Für ein produktiv genutztes Gerät sind deshalb markierte Releases oder der offizielle Flash Assistant sinnvoller als ein beliebiger Stand von main.

Das TRMNL Framework für E-Paper-Layouts ist ebenfalls öffentlich und unter MIT lizenziert. Dazu gehören Sass-Quellen, Design-Tokens, Dither-Muster, die JavaScript-Runtime, die Dokumentationsseite und die Release-Werkzeuge. MIT gilt dabei für den eigentlichen Framework-Code. Schriften und einige Bildressourcen besitzen eigene Lizenzen. Highcharts wird für bestimmte Beispiele extern geladen und gehört nicht zur MIT-Lizenz des Repositorys. Wer das Framework vollständig forkt, muss solche Abhängigkeiten deshalb getrennt betrachten.

Die TRMNL-Organisation auf GitHub umfasst inzwischen mehr als nur Firmware und einen Beispielserver. Zum Zeitpunkt meiner Prüfung waren dort 53 öffentliche Repositorys aufgeführt. Dazu gehören mehrere BYOS-Server, Liquid-Erweiterungen, ein lokaler Plugin-Entwicklungsserver, Übersetzungen, OAuth-Vorlagen, API-Bibliotheken, alternative Clients für Kindle, Kobo, Android und Raspberry Pi sowie 3D-druckbare Halterungen. Nicht jedes Projekt stammt ausschließlich vom Kernteam, aber das öffentliche Ökosystem ist deutlich breiter als ein einzelnes Alibi-Repository.

Für Bring Your Own Server existieren mehrere offene Implementierungen. Terminus ist das offizielle Flaggschiff, steht unter MIT und wird aktiv gepflegt, befindet sich aber weiterhin vor Version 1.0 im Beta-Stadium. Daneben gibt es Lösungen für PHP/Laravel, Node.js, Next.js, TypeScript, Python mit FastAPI oder Django und Elixir/Phoenix. Der Developer-Bereich kennzeichnet einige davon als aktiv und andere als inaktiv. Die bloße Existenz eines Repositorys ist deshalb noch keine Garantie für Funktionsumfang, langfristige Pflege oder problemlose Kompatibilität.

Nicht alles ist bereits offen. Die gehostete Webanwendung, die TRMNL selbst als Core betreibt, ist weiterhin ein kommerzieller Dienst und nicht als vollständiger Quellcode veröffentlicht. Auch ein offenes Firmware-Repository macht ein fertiges Gerät nicht automatisch zu vollständig offener Hardware. Gehäuse, Fertigung, Qualitätskontrolle und das kommerzielle Produkt bleiben Leistungen des Herstellers.

Genau hier setzt die Unbrickable Pledge an. TRMNL hat öffentlich die Absicht erklärt, den Quellcode der Core-Webanwendung freizugeben, falls das Unternehmen insolvent wird. Das ist ein erfreuliches Versprechen und wurde zusätzlich über die Wayback Machine archiviert. Es ist aber kein Source-Code-Escrow mit automatisch auslösendem Vertrag. Ich würde es deshalb als glaubwürdige Absicht und nicht als juristisch garantierte Lebensversicherung behandeln.

Der praktisch wichtigere Schutz existiert schon heute. Offene Firmware und funktionierende BYOS-Server bedeuten, dass ich nicht auf die spätere Freigabe des kommerziellen Core warten muss, um mein Display unabhängig zu betreiben.

Vier Betriebsmodelle, die man auseinanderhalten muss

Die Abkürzungen klingen zunächst unnötig ähnlich. Inhaltlich beschreiben sie aber vier klar unterschiedliche Wege:

Der Standardweg ist das fertige Gerät. Man bezahlt einmal für den OG oder X und verwendet die gehostete Plattform ohne verpflichtendes Jahresabo. Das ist der bequemste Weg, weil TRMNL Rendering, Plugins, Playlists, OAuth-Integrationen und Updates betreibt.

Bei BYOD, also Bring Your Own Device, stammt nur die Hardware von einem anderen Hersteller oder aus dem eigenen Aufbau. Die offene TRMNL-Firmware oder ein kompatibler Client ruft weiterhin die TRMNL-Cloud auf. Dafür ist aktuell eine BYOD-Lizenz nötig. Sie enthält zugleich die Entwicklerfunktionen, sodass nicht zusätzlich Developer Edition gekauft werden muss.

Bei BYOS, Bring Your Own Server, bleibt die TRMNL-Hardware bestehen, zeigt aber auf einen Server im eigenen LAN oder in der eigenen Cloud. Für diesen Wechsel verlangt TRMNL keine zusätzliche Lizenz. Wichtig ist, dass BYOS den gehosteten Plugin-Stack von TRMNL umgeht. Native Cloud-Integrationen wandern nicht automatisch auf den eigenen Server. Die gewählte BYOS-Implementierung muss die benötigten Datenquellen, Playlists und Renderfunktionen selbst unterstützen oder nachbauen. Trotzdem ist das für mich der interessanteste Mittelweg: fertige und sparsame Hardware, aber Kontrolle über Datenquellen, Renderprozess und Betriebsdauer.

BYOD/S kombiniert beides. Das Display ist selbst gebaut oder wiederverwendet, der Server läuft ebenfalls selbst. In diesem Modell kann die gesamte Kette ohne Zahlung und ohne operative Abhängigkeit von TRMNL funktionieren. Kostenlos bedeutet hier allerdings nicht aufwandslos. Jemand muss Firmware, Server, Datenbank, Backups, Updates und Kompatibilität pflegen.

Was TRMNL und die Alternativen tatsächlich kosten

Mit Stand vom 28. August 2026 kostet der TRMNL OG 139 Dollar. Der größere TRMNL X kostet 229 Dollar. Der größere Akku kostet bei beiden Modellen 10 Dollar zusätzlich. Beim X verdoppelt er die Kapazität von 6.000 auf 12.000 mAh. Der optionale Entwicklerzugang kostet regulär 20 Dollar einmalig und schaltet die Entwicklung eigener Plugins sowie den API-Zugriff frei.

Für ein selbst gebautes oder wiederverwendetes Gerät kostet die BYOD-Lizenz 50 Dollar. TRMNL beschreibt sie als dauerhafte Einmallizenz für genau ein Gerät. Mehrere BYOD-Geräte benötigen mehrere Lizenzen, können aber im selben Konto verwaltet werden. Wer stattdessen BYOS verwendet, benötigt diese Lizenz nicht.

Der gemeinsam mit Seeed Studio entwickelte TRMNL 7,5-Zoll-DIY-Kit kostet aktuell 47,99 Dollar. Enthalten sind ein 800 × 480 Pixel großes E-Ink-Panel, ein XIAO ESP32-S3 Plus, ein 2.000-mAh-Akku und das Verbindungskabel. Ein fertiges Gehäuse gehört nicht dazu. Mit der 50-Dollar-BYOD-Lizenz landet man bei 97,99 Dollar zuzüglich Versand, Steuern und Gehäuse. Mit eigenem Server bleibt es bei der Hardware, dafür bezahlt man mit Zeit.

Damit wird auch das Geschäftsmodell verständlicher. TRMNL verdient an fertiger Hardware, Entwicklerfunktionen und der Nutzung seiner Plattform durch fremde Geräte. Wer die gehostete Infrastruktur nicht verwenden möchte, darf sie vollständig umgehen. Das ist deutlich fairer als ein Modell, bei dem offene Firmware nur als Marketing dient, während jede sinnvolle Nutzung an ein Abo gebunden bleibt.

BYOD ist mehr als ein billiger Nachbau

Der offensichtlichste DIY-Weg ist ein ESP32 mit kompatiblem E-Paper-Panel. Der Seeed-Kit nimmt einem die Auswahl von Controller, Treiberboard, Akku und Kabeln ab. Man muss die Teile noch montieren, die Firmware flashen, WLAN einrichten und ein Gehäuse bauen oder drucken. Wirtschaftlich spart man gegenüber dem OG weniger, als der reine Kit-Preis vermuten lässt. Für Bastler liegt der Wert ohnehin darin, die gesamte Kette zu verstehen und verändern zu können.

TRMNL kann auch vorhandene Geräte weiterverwenden. Es gibt Clients oder Anleitungen für Raspberry Pi, Kindle, Kobo, Android-Tablets und weitere Displays. Sogar aus einem eingestellten Meta Portal lässt sich ein TRMNL-Client machen. Das ist ökologisch interessant, weil funktionierende Hardware nicht nur wegen eines abgeschalteten Herstellerdienstes entsorgt werden muss.

Diese Varianten liefern aber nicht automatisch dieselbe Erfahrung. Ein Raspberry Pi braucht mehr Strom als ein ESP32 und läuft typischerweise dauerhaft. Ein LCD-Tablet leuchtet weiterhin und verliert damit den wichtigsten Vorteil meines E-Ink-Setups. Ein Kindle kann ein großartiger E-Paper-Client sein, benötigt je nach Modell aber einen Jailbreak und eine passende Softwareversion. Ein unterstütztes ESP32-Panel liegt dem Originalkonzept am nächsten.

Auch die Displayparameter müssen stimmen. Firmware und Server müssen Auflösung, Rotation, Farbtiefe und Palette des Gerätemodells kennen. Beim OG sind das 800 × 480 Pixel mit bis zu vier Graustufen, beim X 1.872 × 1.404 Pixel mit 16 Graustufen. Ein 7,3-Zoll-Spectra-6-Panel benötigt einen anderen Treiber und eine andere Aktualisierungslogik als ein monochromes 7,5-Zoll-Panel. BYOD heißt deshalb nicht, dass jede beliebige E-Ink-Fläche nach einem Firmware-Flash automatisch perfekt funktioniert.

Genau diese technische Offenheit gefällt mir trotzdem. Der Hersteller hilft aktiv dabei, günstigere oder bereits vorhandene Hardware an dieselbe Plattform anzubinden. Das kann den Verkauf des eigenen Geräts kannibalisieren, macht das Ökosystem aber langfristig wertvoller.

Was Self-Hosting in der Praxis bedeutet

BYOS klingt auf einer Produktseite schnell nach einem Docker-Container und fünf Minuten Arbeit. Bei Terminus steckt mehr dahinter. Das Projekt verwendet Ruby und Hanami, PostgreSQL, Sidekiq, Valkey, Puma, ImageMagick und einen eigenen Render- und Job-Workflow. Docker wird unterstützt, ebenso Installationen auf Raspberry Pi oder Kubernetes. Mit Stand dieses Beitrags bezeichnet sich Terminus noch als Beta und hat Version 1.0 nicht erreicht.

Das ist kein Grund, die Finger davon zu lassen. Es ist aber ein Grund, Self-Hosting nicht mit Wartungsfreiheit zu verwechseln. Firmware und Server teilen ein Protokoll. Wenn sich Setup-, Display- oder Log-Endpunkte verändern, müssen beide Seiten kompatibel bleiben. Datenbank, Uploads, Benutzerkonten, Hintergrundjobs und Backups liegen in der eigenen Verantwortung.

Je nach Anspruch kann eine leichtere Community-Implementierung besser passen. Wer nur eine feste Playlist und ein paar eigene Screens braucht, benötigt vielleicht keine vollständige Core-Kopie. Wer mehrere Geräte, Benutzer, Sensoren, Plugins, Vorschauen und automatische Firmware-Verwaltung erwartet, profitiert eher vom größeren Terminus-Stack.

Für mein Security-Dashboard wäre BYOS besonders reizvoll. Ein lokaler Server könnte Daten direkt aus internen APIs ziehen, daraus eine bewusst entschärfte Anzeige rendern und sie an das Display ausliefern. Kein Monitoring-Endpunkt müsste öffentlich erreichbar sein, und keine sensiblen Zugangsdaten müssten in einer externen Plugin-Konfiguration liegen. Dafür müsste ich den Server wie jede andere interne Anwendung patchen, überwachen und sichern.

Warum das Ökosystem wirtschaftlich funktionieren kann

Inzwischen können Entwickler ihre Plugins als Recipes oder Third-Party-Plugins veröffentlichen. Seit November 2025 vergütet TRMNL Beiträge über einen Creator Fund. Nicht nur Plugin-Autoren können davon profitieren, sondern auch Menschen, die Übersetzungen, Firmware-Code, Halterungen oder andere Teile des Ökosystems beitragen.

Das ist keine Wohltätigkeit. Es ist ein sinnvoller Kreislauf. Mehr gute Plugins machen die Plattform attraktiver. Mehr Nutzer kaufen Hardware, Developer Edition oder BYOD-Zugänge. Ein Teil des Umsatzes fließt an die Menschen zurück, die den Wert der Plattform erhöhen.

Genau deshalb finde ich das Modell spannender als ein klassisches Hardware-Abo. TRMNL verlangt Geld dort, wo echte Kosten oder Mehrwert entstehen, lässt aber einen technisch vollständigen Ausweg offen. Der Hersteller verdient daran, dass Nutzer bleiben wollen, nicht daran, dass sie technisch nicht gehen können.

Schnelle Refreshs und Platz für Hardware-Hacks

E-Paper hat eine typische Eigenheit: Bei einer vollständigen Aktualisierung blinkt das Panel kurz. Das ist technisch bedingt und bei einem Gerät, das nur alle paar Minuten aktualisiert, kein großes Drama. Beim X liegt die dokumentierte Aktualisierungszeit je nach Refresh-Methode zwischen ungefähr 200 Millisekunden und 1,3 Sekunden.

Die 16 Graustufen sind für Kalender, Schattierungen, Diagramme und Schwarz-Weiß-Fotos ein sichtbarer Fortschritt. Ein partieller Refresh eignet sich für kleine Änderungen, während ein vollständiger Refresh das Panel sauber neu aufbaut. Welche Methode sinnvoll ist, hängt damit nicht nur von der gewünschten Geschwindigkeit ab, sondern auch davon, wie viel sich auf dem Screen verändert und wie konsequent mögliche Geisterbilder vermieden werden sollen.

Auch mechanisch ist das X ungewöhnlich offen gedacht. Das Gehäuse ist verschraubt und kann geöffnet werden, der Qwiic-Anschluss lädt zu eigenen Erweiterungen ein und USB-OTG kann Zubehör über das magnetische Pogo-Pin-Dock mit Strom versorgen. Weil die Firmware offen ist, bleiben solche Erweiterungen nicht vollständig von der Produktplanung des Herstellers abhängig.

Warum mir selbst 10,3 Zoll noch nicht reichen

Das X ist mit 10,3 Zoll erheblich größer und schärfer als der ursprüngliche OG. Auf dem Schreibtisch oder in unmittelbarer Nähe funktioniert diese Größe sehr gut. In einer Küche, in der ich aus ein paar Metern Entfernung auf den Familienkalender schauen möchte, ist sie für mich trotzdem nur ein Zwischenschritt. Mehrere Informationen in einem Mashup sehen technisch beeindruckend aus, werden aber aus größerer Entfernung schnell zu fein.

Für die Küche wünsche ich mir ungefähr 13 Zoll. Das wäre groß genug für einen Wochenkalender, Wetter, Aufgaben und vielleicht eine kleine Notiz, ohne dass alles wie ein Kompromiss wirkt. Im Wohnzimmer oder Büro denke ich noch größer. 27 bis 32 Zoll wären für Fotos, Kunst, Familieninformationen oder ein Security-Dashboard eine ganz andere Erfahrung.

Mein TRMNL X ist ein deutlicher Schritt in diese Richtung. Das 4:3-Format passt gut zu Kalendern und Fotos, die hohe Auflösung sorgt aus der Nähe für feine Schriften und das fehlende Logo auf der Vorderseite lässt das Display angenehm neutral wirken. Mit 12.000 mAh muss ich für diese größere Fläche nicht gleich wieder ein permanentes Ladekabel einplanen.

Für einen Schreibtisch oder eine kleine Wandfläche ist das X für mich die sinnvollere Wahl. Für meinen Traum in der Küche bleibt aber auch 10,3 Zoll kleiner als gewünscht. Es löst das Größenproblem nicht, es verschiebt nur die Grenze.

Bei großen E-Ink-Flächen wird die Wirtschaftlichkeit brutal sichtbar. Ein einzelnes monochromes 13,3-Zoll-Panel kostet im offiziellen E-Ink-Shop derzeit 449 Dollar, und dabei sind Controller und fertiges Produkt noch nicht enthalten. Ein kompletter 25,3-Zoll-Monitor von DASUNG liegt je nach Ausführung ungefähr zwischen 1.548 und 1.649 Dollar. Große Farblösungen können noch teurer werden. Das erklärt die Preise, macht sie für eine Küche oder ein persönliches Dashboard aber nicht angenehmer.

Farbe ist ein weiterer Kompromiss. Für Kalender, Text und Statusanzeigen reichen Schwarz, Weiß und Graustufen erstaunlich weit. Für Fotos im Wohnzimmer möchte ich aber mehr. Farbige E-Paper-Displays sind faszinierend, wirken meist weniger brillant als LCD oder OLED und treiben den Preis weiter nach oben. Mein idealer 32-Zoll-TRMNL in Farbe existiert technisch vielleicht in Einzelteilen, wirtschaftlich ist er noch kein normales Consumer-Produkt.

Die Grenzen gehören zum Konzept

TRMNL ist kein Tablet-Ersatz. Animationen, Video, schnelles Scrollen und direkte Interaktion sind nicht seine Aufgaben. Wer jede Minute Aktienkurse aktualisieren oder auf einen Screen tippen möchte, wird mit einem normalen Display glücklicher.

Auch Fotos bleiben auf dem X eine Stilfrage. Mit 16 Graustufen und der hohen Auflösung können sie charmant und fast wie hochwertige Zeitungsgrafiken wirken. Farbverläufe, Hauttöne und dunkle Szenen werden aber nicht originalgetreu dargestellt, denn das Panel bleibt monochrom.

Die Akkulaufzeit ist ebenfalls kein Naturgesetz. Wer sehr kurze Aktualisierungsintervalle einstellt, schlechtes WLAN hat oder komplexe Bilder überträgt, weckt Funkmodul und Controller häufiger und muss entsprechend früher laden. Das ist kein Fehler, sondern die normale Abwägung zwischen Aktualität und Ruhe.

Am meisten stört mich persönlich weiterhin die Größe. Das ist fast ein Kompliment an den Rest des Produkts. Ich ärgere mich nicht über eine unbrauchbare Software, komplizierte Einrichtung oder ein geschlossenes System. Ich möchte einfach mehr Fläche, weil ich bereits weiß, was ich damit darstellen würde.

Mein Fazit nach der langen Wartezeit

Hat sich das Warten gelohnt? Ja, auch wenn fast neun Monate für ein ursprünglich mit vier Monaten angekündigtes Produkt sehr lang waren.

TRMNL löst mein altes Raspberry-Pi-Problem auf eine elegante Weise. Es leuchtet nicht ständig, braucht kein dauerhaftes Stromkabel am Einsatzort und verlangt im Alltag kaum Aufmerksamkeit. Der Kalender ist einfach da. Andere Informationen erscheinen nach Zeitplan. Wenn ich mehr will, kann ich Plugins kombinieren oder mit überschaubarem Aufwand selbst eines bauen.

Noch wichtiger ist mir das Ökosystem. Offene Firmware, dokumentiertes BYOD, mehrere Self-Hosting-Projekte, ein einfaches Plugin-Modell und eine aktive Community sind bei einem kleinen Hardwareanbieter nicht selbstverständlich. Das reduziert das Risiko, dass aus dem Gerät irgendwann Elektroschrott wird, nur weil ein Cloud-Dienst verschwindet oder die Firma ihre Strategie ändert.

Trotzdem würde ich TRMNL nicht jedem blind empfehlen. Auch das von mir getestete X ist mit 10,3 Zoll in erster Linie ein persönlicher Infoscreen für kurze bis mittlere Distanz. Wer eine Küche, ein Wohnzimmer oder ein Büro ausstatten möchte, sollte die gewünschte Lesedistanz sehr ernst nehmen. Für meine Vorstellung ist selbst das X noch nicht groß genug. Und sobald man 13 Zoll, 25 Zoll oder Farbe verlangt, verlässt man sehr schnell den angenehmen Preisbereich.

TRMNL ist für mich deshalb kein abgeschlossenes Ziel, sondern der überzeugendste Zwischenstand. Das Produkt zeigt, wie ein ruhiger, sparsamer und offener Infoscreen funktionieren sollte. Jetzt muss die Displayindustrie nur noch dafür sorgen, dass dieselbe Idee in 13, 27 oder 32 Zoll bezahlbar wird.

Wenn das passiert, weiß ich bereits, wo die Geräte hängen werden.

Bis zum nächsten Mal,
Euer Joe

FAQ