I Want to Build an E-Ink Dashboard with AI

James Devonport built a small device: an e-ink display on his desk that periodically shows train departures.

I like it. It is not a huge project, but it is useful. A quick glance gives you the information without unlocking a phone or opening another web page.

If I made one, I would probably start with my blog: whether the site is reachable, when I last published, and whether anything needs attention. Two or three things are enough. More would be too much to scan.

After reading his article, though, my first thought was not to buy the hardware. It was how to build this without creating a maintenance chore.

Keep cloud work out of the device

James uses an ESP32-based Note4C, Cloudflare Workers and help from Codex.

The approach is straightforward: fetch train data in the cloud, lay it out and generate an image. The device periodically downloads and displays that image.

I like that structure.

Let the little device handle display rather than data fetching, business rules and layout all at once. Changing fonts or moving things around can then happen in the cloud, without repeatedly reflashing firmware.

For private data, I would also check the image URL. A login-protected page does not help if anyone with the generated image link can see everything. An image is still data. Changing its format is no reason to make it public.

Do not start by demanding real time

It is easy to add “ideally, real-time updates” to a dashboard request.

But do I need that?

Learning about a new blog post a few minutes late is fine. A calendar needs even fewer refreshes. Constant API requests for a number that barely changes are unnecessary.

James says a full refresh on his device takes about ten seconds. That makes it a better fit for information you read at leisure than for a live trading display.

I would start with a longer update interval. If the data has not changed, there is no need to redraw it. If it feels too slow in use, I can adjust it.

For a personal tool, I would rather make it low-maintenance than chase impressive specifications.

What matters to me is whether the information is still current

An e-ink display can retain its image after power is removed.

Usually that is an advantage. On a status dashboard, it needs care.

A screen saying “website healthy” looks reassuring. The device might actually have lost its connection yesterday, with those words unchanged ever since.

So I would definitely show the update time, not hide it in tiny text in a corner.

Receiving a new image does not prove the data inside is new, either. The cloud service might have failed to fetch fresh data and rendered the old values again.

I would carry the data timestamp all the way into the final image. Once it is too old, say so rather than keep showing a green check.

Of course, a fully unpowered device cannot even change its message to “expired.” I would treat this screen as a convenient information tool, not the sole channel for important alerts.

I would build it a piece at a time

I would not hand the hardware, API and cloud service to AI at once and ask it to finish everything in one go.

The code might appear quickly. But if the display stays blank, debugging becomes tedious. Is it the network, the image format or the device driver? I would have to separate the layers anyway.

First I would ask AI to draw an image using mock data. Once it looks right on my computer, I would move on.

Then I would connect real data and decide what happens on a normal response, a timeout or an empty result.

On the device, I would first get a fixed image displaying reliably, then connect cloud updates.

Scheduled jobs and retries come last.

Is that slow? I do not think so. Knowing where each step stands is easier than guessing at a pile of code at the end.

Do less in version one

These projects grow very easily in conversation.

First it is train times, then weather, calendars and site traffic, and eventually a voice assistant. AI is accommodating: suggest a feature and it says it can build it.

I would hold back.

One page, one data source, a few days on the desk. Is the type too small? Is the information useful? Does a lost connection leave a misleading display? Using it will tell me.

If it proves useful, add more. If not, there is no point continuing just because some code already exists.

One practical change AI brings is that little tools like this are finally worth making yourself. Previously, just thinking about documentation, APIs and hardware setup could be enough to give up. Now it can help move the work along.

What makes it pleasant to use, and which information does not belong there at all, are still my decisions.