TRMNL: Blog

Featured Community Plugin: Awair

2026-03-31T00:00:00+00:00

This post is part of a series, featuring the incredible work of plugin authors who grow the TRMNL plugin ecosystem with every contribution. The TRMNL team has individually selected these plugins and authors to be featured.

Awair Plugin

Community member Bryant created the Awair plugin; here are their words on how it was created.

Why did you want this plugin to exist?

I have air quality monitors spread out throughout the home. A smartphone app is great for something that should control a device. If I want something to display status across an array of devices, TRMNL is a great platform for that.

Why were you the person to make it?

This is probably most useful for people who have several Air Quality monitors and for folks who are a bit over-interested in their indoor air quality. I met this criteria.

How did you balance look vs functionality?

This needed to be glanceable. I don't want to have to calculate whether or not certain values were within an acceptable range when I glance at the screen. So I wanted a way to show many values across multiple sensors and easily show whether or not they are in an expected or acceptable range.

What, if any, challenges did you face while creating it?

ChatGPT was great for getting the wiring all hooked up between the TRMNL and the data providers. I had to iterate on my own to make sure that the UX on the layout was actually intuitive and glanceable.

Is there a tip you would give to a new plugin developer?

There isn't a single obvious way to approach each visualization. You just have to iterate through it multiple times.

What could be improved by TRMNL?

Like I said, creating and editing these plugins takes a lot of iteration. You want to see how it generally looks, you want to see how it looks on the actual devices. I would love to see improvements in the process and workflow for allowing for a development workflow that assists in making that painless.

Featured Community Plugin: Paul's Recipe recipe

2026-03-24T00:00:00+00:00

This post is part of a series, featuring the incredible work of plugin authors who grow the TRMNL plugin ecosystem with every contribution. The TRMNL team has individually selected these plugins and authors to be featured.

Paul's Recipe recipe

Community member Paul (Discord: DD_DE) created Paul's Recipe recipe; here are their words on how it was created.

Why did you want this plugin to exist?

We've had a party coming up and I decided to serve the drinks for the guests. So I needed a menu and list of recipes. Instead of printing it out, just to find a blatant typo, I decided to make use of my TRMNLs. First I searched the plugins and recipes and while I found one it didn't fit all my drinks and also was quite hard to read in the dim party environment. So I made my own. I first made the menu, which I then refined for the recipes. After a successful party, I improved my plugin a bit further, adding proper form fields and custom scaling. I hope you enjoy.

How did you balance looks vs functionality?

In my first iteration, looks were definitely more important than functionality. But in preparation to release it, I've expanded the functionality a lot, while keeping the design very similar.

What was your process for creating the plugin?

My development principals are to avoid using AI as much as I can. This is because I'd need as much time understanding the AI code as it would take me to write it myself. In addition, I feel like I can learn more by scouring the documentation or other plugins that by asking the AI.

What, if any, challenges did you face while creating it?

I've struggled a bit with the liquid syntax, since it's been a while since my last plugin and I usually don't use it. But over time I got better again and reworked my clunky code from the beginnings , if needed. Oh and I nearly bricked my plugin while adding form fields, so that was fun.

Is there a tip you would give to a new plugin developer?

Probably to just start coding, use whatever tool you want, but understand what the code does. It doesn't matter if you're code is clunky, finish it and then rework it if you think you know better techniques.

What is your favorite plugin that someone else created and why?

I think it might be the "useless fact" plugin.

Featured Community Plugin: Hardcover - Reading Buddy

2026-03-17T00:00:00+00:00

This post is part of a series, featuring the incredible work of plugin authors who grow the TRMNL plugin ecosystem with every contribution. The TRMNL team has individually selected these plugins and authors to be featured.

Hardcover - Reading Buddy Plugin

Community member Sumalyo Datta (Discord: sumalyo) created the Hardcover - Reading Buddy plugin; here are their words on how it was created.

Why did you want this plugin to exist?

I thought that I would be quite cool to see my (and other people's) reading progress on the TRMNL. Also it would give me the perfect dose of motivation to finish my book.

How did you balance look vs functionality?

I tried to keep it minimalistic. The idea of mashups looked quite interesting and I leveraged the idea of making my views appropriate for various sizes. As Book Club members would most likely combine various iterations of this plugin to track their buddies, I worked on a design that gave it a clean yet gamified look. I also worked on implementing a progress bar that would look clean.

What was your process for creating the plugin?

I used the service Hardcover.app that provided a nice clean API to retrieve user progress information.

What, if any, challenges did you face while creating it?

The design of the single page view which had to adjust based on the number of books the user was currently reading was quite challenging to design.

If I were to make this from scratch today, what would I have changed?

I made this plugin a long while ago when FrameworkV2 was not quite mature. Today I look a the cool features that the team have added for developers and I think I could incorporate some of that in this.

What is your favorite plugin that someone else created and why?

Movie Title Screens - Just so so cool!!

Featured Community Plugin: Who's That Pokémon?

2026-03-10T00:00:00+00:00

This post is part of a series, featuring the incredible work of plugin authors who grow the TRMNL plugin ecosystem with every contribution. The TRMNL team has individually selected these plugins and authors to be featured.

Who's That Pokémon? Plugin

Community member Sriniketh (Discord: amelogenin) created the Who's That Pokémon? plugin; here are their words on how it was created.

Why did you want this plugin to exist?

I was an early adopter and was so excited to receive my TRMNL that I started thinking about what I'd want to see on it every day. When I dove into the docs to learn how to build plugins, I needed a fun dataset to work with, and that's when I thought of Pokémon. I grew up watching the show, and one thing that always stuck with me was the "Who's That Pokémon?" segment during commercial breaks. They'd show a Pokémon's silhouette and challenge viewers to guess who it was. I wanted to recreate that little moment of nostalgia: glancing at my TRMNL and seeing a random Pokémon each day, just like the show used to do.

Why were you the person to make it?

Honestly, anyone could have made this. I thought it would be fun to learn the platform by building something that's inherently fun to me. As a developer, I also wanted to be thoughtful about the technical details. I initially used a webhook, but switched to polling since the data only changes once a day and it meant zero configuration for users. That ease of setup made it a natural fit for a recipe. It was a good excuse to tinker and learn how TRMNL plugins work end to end.

Were you inspired by any other recipes or plugin creators?

Absolutely. The community and Discord were a huge inspiration. I saw so many creative plugins that displayed something unique each day: Piet Mondrian generative art, Marvel character of the day, Calvin and Hobbes. That format of "one delightful thing per day" really resonated with me and made me think about what my version of that could be. I built this for fun and didn't anticipate so many people relating to it. It has way more installs than I could have imagined and was even featured in the TRMNL X video. Fun fact: the random selection has surfaced Gumshoos four times now, making it the unofficial mascot of the plugin!

How did you balance look vs functionality?

I wanted it to be simple but give me some extra details beyond just the name so I could improve my Pokémon knowledge. The image had to be front and center, so when the plugin is used as part of a mashup, details like abilities disappear but the image stays. That was a deliberate tradeoff.

Did you learn anything that you want to apply to future or past recipes?

Keep the infrastructure simple. A GitHub Action that runs once a day and commits a JSON file is about as low maintenance as it gets.

What, if any, challenges did you face while creating it?

I'm one of those who has searched "how to center a div" far too many times. So I spent quite a bit of time getting the UI to scale well across mashups without the image getting cut off. It was a lot of trial and error, but that's part of the fun.

What part of the TRMNL Framework, Liquid filters, or other documentation was most helpful?

I was impressed by how much tooling was already in place when I developed the plugin. I didn't even have my device yet, but I could use tools like trmnlp to get started with plugin development. The docs were well put together and helped me understand the finer details, including how refresh intervals affect battery life. That kind of context made it easier to make informed decisions about how the plugin should work.

Creator Fund - February 2026

2026-03-09T00:00:00+00:00

for more context see the Creator Fund announcement.

our 5th payout rewards community contributions between February 8, 2026 and March 9, 2026.

source of funds

each payout period, a portion of developer-specific revenue goes directly to creators.

source	revenue	share	amount
Stripe Developer Edition TRMNL+ Shopify Developer Edition Clarity Kit (X) Clarity Kit (OG) BYOD	$2,140 $560 $261.99 $14,961.11 $14,091.83 $12,716.19	15% 80% 15% 0% 10% 10%	$321 $448 $39.30 $0.00 $1,409.18 $1,271.62
	$44,731.12		$3,489.10

source

revenue

share

amount

Stripe

Developer Edition
TRMNL+

Shopify

Developer Edition
Clarity Kit (X)
Clarity Kit (OG)
BYOD

$2,140
$560

$261.99
$14,961.11
$14,091.83
$12,716.19

15%
80%

15%
0%
10%
10%

$321
$448

$39.30
$0.00
$1,409.18
$1,271.62

$44,731.12

$3,489.10

note that Clarity Kit (X) sales were excluded as this product is not yet released. these values will continue accruing for a future Creator Fund payout.

by the numbers

total payout: $3,489.10
plugin author share: $2,442.37 (70% of total)
strategic contributors share: $1,046.73 (30% of total)

plugin author earnouts are calculated automatically by a collection of factors including a plugin's age (on live playlists), presence (by % dominance on playlists), and impressions (times displayed on device), relative to all other community plugins. there is a minimum threshold of 50 total connections (installs + forks) to qualify for monthly payouts. see the algorithm in action here.

strategic contributors are those who contribute to TRMNL open source projects. these earnouts are calculated with a mix of automation + human touch. relative to the funding available, below are allocations by category:

Firmware, 25%
3D Models, 8%
BYOS, 39%
Localizations, 8%
BYOD, 20%
Documentation/Resources, 0%

note that these allocations change monthly based on contributions by category.

algorithm?

over time the above weights, revenue share percentages, and minimum thresholds may change. reporting will become more transparent. our goal is an open sourced algorithm and self-service calculations with daily (or faster) resolution.

candid feedback is welcome, email team@trmnl.com.

Model X Progress Report

2026-03-04T00:00:00+00:00

We introduced X on July 30, 2025. Below are live updates since launch.

Estimated Ship Date

As of March 18 we're now shipping! For more details watch this video or see the "March" section at the bottom of this post.

Tech Specs

Highlights below, or see everything here.

10.3" 1872x1404 EPD resolution with 16 shades of gray
Dust and basic waterproofing with a hacker-friendly enclosure
ESP32-S3 with 16MB of flash and 8MB of PSRAM as a core processor with fallback 2.4GHz WiFi
5GHz WiFi support via ESP32-C5 as a modem (external antenna)
Support up to 2x 6000mAh 3.8V LiPo batteries with automatic detection
Battery gas gauge from TI for battery SOC/SOH/capacity tracking
Bosch accelerometer for portrait/landscape orientation
Gesture touch-bar based on Azotech IC
Magnetic pogo pin-based mount for charging and accessories (Coming 2026)
OTG support with 5V 2A output

Dimensions

These values may change as we scale production. last updated December 15, 2025.

X enclosure dimensions (mm)

Weight (device only, no attachments)

1 battery - 362 grams
2 batteries - 448 grams

August 2025

Multiple boards and controllers support touch gestures, battery charging, and 5ghz WiFi
The circular area interfaces with a waterproof "puck" shaped charging connector, and several test points on the motherboard's bottom will let us build a QA jig for our warehouse
Prior to release we'll prototypes to your favorite creators for first-look reviews

September 2025

PCB preview

We ordered 50x more prototypes with stronger magnets so devices can attach directly to a surface (e.g. refrigerator) without mounts
Dual band WiFi will be powered by the ESP32-C5 and we've benchmarked faster speeds + better range with custom modem firmware
Orders with the Battery Upgrade (or Clarity Kit) will now enjoy 10,000mAh versus the announced 7,000mAh variant
Our "charging puck" (name TBD) now has a universal connector for kickstands and other peripheral accessories that will debut in 2026
The same firmware that runs all OG + BYOD devices has been extended and is already running my own X prototype, preview here

October 2025

Grayscale testing with a GOAT

The first batch of screens arrived at our USA warehouse, more en route to our Berlin warehouse
Gesture bar + charging pucks are in small batch production
Received and approved packaging samples. Model X packaging will be more premium and protective than OG packaging.
Consolidating WiFi antennas (2.4 + 5gh) to a single component
Added 3 angle options (degrees) to the kickstand
[Work in progress] battery options may grow another 20% to 6000/12000mAh variants pending more testing

November 2025

Full assembly (3D printed parts, not final)

Fully functional prototype (3D printed case, non-branded silicone pads)

Prototype running latest (public) firmware release

Added extra reset buttons to S3 and C5 MCUs for hacker friendliness, board design is final
Batteries are in production and we can confirm the improved 6k / 12kmAh sizing (announced size: 5k / 7k)
Enclosure injection molds are in production, purchase order placed for thousands of cases in different colors
Magnet deliveries from Chinese factories have been delayed due to recent Critical Mineral Export Bans

December 2025

Battery production complete, shipping to our warehouses next week
EC licenses underway at testing facilities
Packaging in mass production
Magnets in mass production
[New] OTG functionality - power other devices from your TRMNL's charging puck

January 2026

From my desk to yours, a video update.

February 2026

From our warehouse to your desk, a video update.

March 2026

From my desk to yours, a video update.

If you prefer not to watch the video, in summary we're shipping single-battery devices only from our USA warehouse because our magnet supplier ripped us off and sent thousands of weak magnets, following multiple sample shipments with the correct (strong) magnets.

As of Wednesday, March 18:

Berlin warehouse has all 3 types of PCBs
Berlin warehouse should receive device enclosures in 1-2 weeks
USA warehouse has everything and has begun assembly + fulfillment

To check your place in the queue go here:
https://trmnl.com/order-tracker

If you already have a TRMNL, install the Order Tracker plugin to stay up to date:
https://trmnl.com/recipes/260817

How can I estimate the time it will take to receive mine?

Devices will be shipped in the order they were purchased and we intend to scale to 100s of fulfillments per day, as we have done for past releases and back-in-stock periods.

Our 2x warehouses have trained 15+ individuals to flash, assemble, and ship devices. We do not outsource to 3rd party logistics companies. You can learn more about our end to end philosophy and technology here and here.

DIY Environment Sensors

2026-03-03T00:00:00+00:00

our most popular plugin is the weather. and not just those we maintain (1, 2, 3), but the greater community's. if i anticipated this before starting TRMNL i might have Googled "barometric pressure" before 5 minutes ago. but here we are.

as weather plugins have matured, one thing we've noticed is the importance of hyperlocal data. a postal code approximation is not always good enough. neither is one's personal backyard station.

now you can get all these measurements directly from your OG TRMNL by hooking up 1 or more environmental sensors.

requirements

TRMNL OG device (get one)
sensor + QWIIC connector (AHT20 - $6, BME280 - $17, SCD41 - $43, etc)
soldering iron
tenacity

a 3D printer is also recommended, as the sensor we're attaching to TRMNL won't fit inside the original enclosure. you could try cutting a hole in your case but we don't recommend it.

showcase

before digging in, a quick shoutout to community member JackR who managed to install an AHT20 directly inside his OG device, then close it back up without any funny business.

no ABS was harmed

another shoutout to member lanrat who modeled an exterior mount for a BMP280 sensor:

BMP280 mount

and some source code for a beautiful sensor plugin:

copy/paste sensor plugin

ok, let's get started.

understanding our sensors

behind all the magic below is a collection of environmental sensor libraries by our very own Larry Bank, for example:
https://github.com/bitbank2/b b_scd41
https://github.com/bitbank2/bb_temperature

these will be included in our 1.7.9+ firmware release but may be leveraged immediately by checking out the branch and building the binary yourself.

anyway, here's how it works in Larry's words:

When a compatible sensor is attached to your TRMNL OG it is automatically detected, activated, and sample data is gathered during each device wakeup. This ensures the power being used by the sensors doesn't impact the battery life. Not all environmental sensors can work this way (e.g. PM2.5 and some gas sensors need to be on for longer periods of time and use a lot of power). We will keep expanding the list of supported sensors, but the goal is to support low power sensors that can operate during the short wake periods of the TRMNL, then be shut down while the TRMNL sleeps.

what we're building

sensor support relies on test points on the bottom of your OG model's PCB. here was our early proof of concept:

Pimoroni SCD41

Environmental Sensor Data Stream

as you can see, 3 (or more) data types can come through a single I2C bus. which got us thinking... what if we made this available inside TRMNL?

solder time

from Larry:

The ESP32-C3 used on the TRMNL OG has very few available GPIOs. TRMNL doesn't need very many, so there are a few unused ones. Bogdan, the designer of the TRMNL board, had some forethought and exposed the unused GPIOs as test points on the bottom side of the PCB.

TRMNL OG solder points

In the photo above you can see the test points on the bottom of the OG PCB. The ESP32's IO matrix gives the flexibility to use almost any combination for I2C. I chose to use the RX and TX pins (GPIO 20 & 21). In the photo below you can see how I cut a QWIIC cable in half and soldered the leads to the OG PCB:

Black = GND
Red = 3.3V
Blue = SDA (TX = 21)
Yellow = SCL (RX = 20)

TRMNL OG + QWIIC Connector

that's a pretty nice solder job. but have no fear -- if your outcome is closer to what you see below, pat yourself on the back with a firm "it'll hold" in your best Southern accent.

Founders Who Solder

with your PCB rigged up to a sensor, the TRMNL firmware (v1.7.9+) will automatically detect and parse the make, model, etc data coming from each peripheral. you can even daisy chain multiple sensors if that's your thing.

let's put this back together, shall we?

OG assembly remix

as i mentioned earlier, the original enclosure is not going to fit your new sensor. so i printed one of my favorite community mounts, the Minimal stand by CtrlAltPrint.

the design features OG-specific screw holes to attach your PCB, and you only need 1-2 of them to make everything secure.

TRMNL OG, Sensor, Custom Enclosure

now that we're wired up, let's make a plugin.

environment sensor plugin development

log into your TRMNL account (or the open-source Terminus server) and make a new Private Plugin (Extension on Terminus).

inside the Markup Editor > Merge Variables accordion you'll see a new node, Sensor Readings.

inside is a collection of sensor readings, each bundled up and sent to TRMNL whenever your device wakes up for new content. here's an example data set:

{
  "device_1": {
    "temperature": [{"2026-02-22 13:03:48 UTC": 20.1}, {"2026-02-22 13:08:51 UTC": 20.2}, {{"2026-02-22 13:14:01 UTC": 19.9}],
    "humidity": [{"2026-02-22 13:03:48 UTC": 39}, {"2026-02-22 13:08:51 UTC": 42}, {{"2026-02-22 13:14:01 UTC": 41}],
    "carbon_dioxide": [], // same as temperature; timestamp => value
    "pressure": [], // ""
  },
  "device_2": {} // each of your TRMNL devices with sensors attached is accessible
}

under the hood we store the Make, Model, Kind (e.g. temperature) Unit (e.g. celsius), and Value for every reading sent by your TRMNL device. these readings may then be visualized inside custom plugins, and even shared on the marketplace for other users to install.

Sensor Reading logs

and there we have it.

TRMNL OG + Sensors

if you rig up an OG to report environment data, send me a pic (ryan@trmnl) for $50 in store credit that never expires. we'd love to see what you build.

Featured Community Plugin: Weird Patents

2026-03-03T00:00:00+00:00

This post is part of a series, featuring the incredible work of plugin authors who grow the TRMNL plugin ecosystem with every contribution. The TRMNL team has individually selected these plugins and authors to be featured.

Weird Patents Plugin

Community member Abdul (Discord: y2ee201) created the Weird Patents plugin; here are their words on how it was created.

Why did you want this plugin to exist?

Like all my authored plugins, I built this one for myself as the target user. The original idea was to display random or curated patents as a kind of memorabilia plaque for patent owners and inventors with a TRMNL. While researching APIs and building the backend, I revisited a website that releases an annual "funny patents" list; it was both amusing and inspiring in showcasing of human ingenuity. Instantly, the plugin pivoted from informational to inspirational+quirky. Also, patents are still published with those classic orthographic or knolling illustrations, which I felt would look beautiful on the TRMNL's e-ink display. Maybe I should call this art style "Patentcore".

Were you inspired by any other recipes or plugin creators?

I've been inspired by other plugin authors quite a bit; particularly Trump Quotes and Air Quality, to name a few. Some of my plugins borrow design patterns and visualizations from the TRMNL team or the community. That said, a few, like the fortune cookie plugin, are original designs including the graphics involved. I typically share prototypes on the community Discord server and get valuable feedback and encouragement from the TRMNL team and other authors. Once submitted, the team provides technical design feedback that helps me improve and learn.

How did you balance look vs functionality?

After the pivot from informational to humorous, looks took the lead. The plugin's "function" became abstract; it's there to inspire, amuse, or just make you smile. For most of the users, I’m pretty sure it's the Patentcore aesthetic on TRMNL’s e-ink display.

What was your process for creating the plugin?

Like any software project, a TRMNL plugin is a combination of frontend and backend. I design the frontend based on the idea, then build the backend to support it. The e-ink optimization was mostly handled through TRMNL's built-in image processing, which made rendering those detailed line illustrations straightforward. Since the patent images are third party, I decided to host them on my own server for reliability. I built a REST API to serve the images and metadata. My stack: Python, FastAPI, and Azure, along with TRMNL's Liquid templating framework.

Did you learn anything that you want to apply to future or past recipes?

With each plugin, I learn something new. This one taught me how to center-crop images in HTML/CSS, responsive auto-resizing within TRMNL's design framework, and handle various image rendering challenges. But the most important lesson came from the Discord community. Mario said, "Sometimes people just want a relief valve." That stuck with me; not every plugin needs to be utilitarian. Sometimes it's enough to make someone smile.

What is your favorite plugin that someone else created and why?

Shan Shui Chinese Landscape is one of the most aesthetically pleasing plugins on the platform. The procedurally generated ink-wash style looks stunning on the e-ink display. It's the kind of plugin that reminds me why I wanted a TRMNL in the first place.

Power Efficiency - why we care so much about it

2026-02-24T00:00:00+00:00

Challenges of a battery-powered device

Empowering your TRMNL to run for months between charges is a defining part of the user experience; managing cables, frequent charging and dead devices turn power management into another chore that steals your focus.

A general hardware rule: more efficient components are more expensive and more complex.

Below is an overview of the difficult decisions we've made on both the hardware and software side to leverage complexity and make TRMNL a maintenance-free device.

The Components

Let's begin with the anatomy of a TRMNL OG device.

ESP32-C3: This version of the ESP32 is less powerful and has less memory than other models, but is the lowest power version with WiFi support. The tradeoff is that software becomes more complex to work around the constraints of the MicroController Unit [MCU]. Other WiFi enabled MCUs use less power but also have a higher price-per-unit and software complexity.
Lithium Battery: There are other battery chemistries, but this type of battery can handle the high current demands of the ESP32 and can be recharged hundreds of times.
Voltage Regulator: The battery is rated 3.7-4.2V while the ESP32 and display require 3.3V. This necessitates adding a circuit to regulate the battery voltage to the MCU voltage. The inexpensive component choice would be a "linear regulator" which throws away the excess energy as heat. TRMNL chose to use a "switching regulator" which utilizes up to 20% more of the battery energy, but at a higher component cost and circuit complexity.
7.5" e-Paper display: This type of display retains its image without power and is readable in direct sunlight. The display is a large portion of the total component cost, but is also what makes TRMNL a unique product.

TRMNL's component choices can last multiple months on a single charge for our battery-powered digital device. The choices above dictate how much work (software) can be done on the device versus how much work must be done on the server.

TRMNL's balance of device / server effort lets us generate beautiful output using web UI programming, while having the TRMNL device itself receive and display those screens as compressed images (snapshots).

Where does the energy go?

After choosing components and designing a circuit, the biggest challenge to creating energy-efficient battery powered devices is the software.

The general idea for power usage on IoT devices is to get the work done quickly and then put the CPU into 'deep sleep' until needed again. For TRMNL firmware, power optimization is quite a bit more complex because we use WiFi, an energy-hungry task.

When the TRMNL wakes up to update the image, many different tasks must be accomplished. Software profiling tools won't be much help optimizing these tasks. An excellent tool which allows us to see the real-time power usage is the Power Profiler Kit II from Nordic Semi. This is a surprisingly affordable tool with very high precision. We can use the PPKII as a virtual battery for the TRMNL to see exactly how much energy is being used.

The image below is a screen capture from the PPKII software showing the current drawn from the battery during an image update:

TRMNL power draw during a refresh

After the initial peak of starting up the CPU, the next set of large peaks are caused by the WiFi usage. It's pretty clear that using WiFi communications is the most energy intensive task of the TRMNL. Here are the four tasks which use WiFi:

Connect to AP: Connecting to your local access point can take more than a second. That doesn't sound like much, but one second of maximum power drain is significant.
NTP: The device needs to know the correct time to record events and know the relative age of images. The Network Time Protocol is a standard way of getting the accurate time from servers at Google, NIST or other sources. This can take up to four seconds or more depending on network conditions.
API server: Our web servers which manage devices and playlists. This informs the device of firmware updates, users' settings (e.g. refresh time), and image links. The device also tells the web server its battery level for user-facing alerts and notifications. This communication usually takes about one and a half seconds.
AWS image cache: We cache plugin images on AWS to reduce latency and provide a broader global reach. We also compress images to make sure the payloads are small. Pending image size, this step can take one to five seconds.

Each step above uses significant power. They also take much longer than when done on more powerful PCs.

For example, a modest Linux machine like the Raspberry Pi Zero can accomplish each of those tasks in a fraction of a second because the CPU and network hardware trade time for higher power consumption. With the ESP32 family, one of the tradeoffs is that network tasks take a long time.

Software Optimization

This topic is quite broad, but the tl;dr is that there are thousands of different ways to write code which accomplishes a certain task, but not all are efficient. Put simply: If we didn't put the TRMNL's ESP32 to sleep between updates, your battery would last less than a day.

There are unpleasant consequences to using the ESP32's deep sleep mode. When the ESP32 is in its lowest power sleep mode, it turns off the power to the main memory. This complicates the software because the system essentially starts from a blank slate each time it wakes up.

So besides the obvious power optimizations like deep sleep, what are some other opportunities?

WiFi Connection

The WiFi connection to an access point can take more than a second; this is due to DHCP negotiation. This is where the access point assigns an IP address to your device. The deep sleep trade-off creates this renegotiation. We recently added support for fixed IP addresses. With a fixed IP your TRMNL can connect to your AP in a fraction of a second.

NTP Server

We recently made a change to the firmware which greatly reduces the time spent getting the time from NTP. The new logic only connects to the NTP server if the ESP32's internal (slightly imprecise) clock doesn't have a valid time or if it's been more than 24 hours since the last NTP fetch. This saves significant power since this step can take up to four seconds.

AWS Image Download

Another recent change to the firmware addressed image downloads. Each image name contains a unique identifier for the plugin/mashup that generated it, as well as a timestamp.

For images which don't change at every update (e.g. "Days Left Until..." plugins) we can compare the name and see if we recently downloaded the same image. If our local copy of the image (in FLASH storage) is the same as the current one from our playlist, we can skip this step entirely. Images older than 24 hours are automatically purged from local storage in case a user makes changes to their playlist.

Odds & Ends

The remaining device refresh tasks (image decoding and e-paper update) use significant power, but less than the WiFi tasks.

We've optimized this code to use as little power as possible; for example - putting the ESP32 into 'light' sleep while waiting for the e-paper to update. We need to wait for the update to complete to tell the display itself to sleep before the ESP32 can go into deep sleep. If we were to leave the e-paper display in idle/wake mode after the update, it would shorten the TRMNL battery life significantly.

Under your control

TRMNL's hardware and firmware provide a platform for personal, non-intrusive information.

By optimizing the platform we give you more freedom in how you use it. As described above, each update needs a certain amount of energy. Therefore it follows that more frequent updates will drain the battery faster. So we've even optimized the display updates themselves to be less visually disturbing (flicker-free).

Beyond the refresh rate and update type, the energy/time spent per update is highly variable as well. Local network conditions affect every step, but so do image choices. Smaller image files download and decode faster than larger images. An image's file size is highly dependent on the graphical content. We use PNG as our standard file format because it performs well on a variety of image content. Images like the weather, with large continuous areas of a solid color, compress quite well while dithered photos compress poorly. 2-bit grayscale images are generally larger than 1-bit bitonal.

For popular plugins, this translates to image sizes which range in size from 2K to 50K bytes. We recently added support for decoding full color images onto black/white displays. Color images can be much larger than black and white. To help manage the local storage and battery life, all images are limited to a maximum size of 90,000 bytes.

The increasing value of your investment in TRMNL

Your TRMNL hardware may not change after purchase, but we're continuously improving its software on both the device and server back-end to ensure your experience is the best it can be.

By making the software more battery-friendly we extend the time between charges, which extends the total life of the battery via fewer charge cycles.

Underscoring all of this is our commitment to open sourcing each of these discoveries. This ensures that not only can you see what's in the software, you're also able to control it.

Featured Community Plugin: Architectural Styles

2026-02-24T00:00:00+00:00

This post is part of a series, featuring the incredible work of plugin authors who grow the TRMNL plugin ecosystem with every contribution. The TRMNL team has individually selected these plugins and authors to be featured.

Architectural Styles Plugin

Community member XXCoder (Discord: XXCoder) created the Architectural Styles plugin; here are their words on how it was created.

Why did you want this plugin to exist?

I happened to see one of interesting building picture and description of style. Made me wonder if it could be a plugin. So I figured if there was pictures and styles I can make it.

Why were you the person to make it?

Dunno, I'm weird one I guess. I seem to tend to make plugins that require a lot of pictures processing and random image. Cats 😸 was first one of such, and this is third after dogs one.

Were you inspired by any other recipes or plugin creators?

I tend to just make plugins I want for myself and share it with others. I have gotten a massive amount from others to make my plugins exist and they all are awesome! (Thanks all!)

What was your process for creating the plugin?

Once I think up an idea, I figure what is best source of images that is as copyright-free as possible and process those images.

What, if any, challenges did you face while creating it?

Definitely processing images. Size, quality and ensuring it has no copyright text or memes is important to me. I also usually try to avoid pictures of people faces, though in this plugin's case it is unavoidable, being buildings that often have people around.

What is your favorite plugin that someone else created and why?

Oh I love so many plugins I currently use. Air quality forecast (I heavily modified mine, go fork and open source!), Weather Glance, Weather Chum.