How I built Timeframe, our family e-paper dashboard

TL;DR: Over the past decade, I’ve worked to build the perfect family dashboard system for our home, called Timeframe. Combining calendar, weather, and smart home data, it’s become an important part of our daily lives.

When Caitlin and I got married a decade ago, we set an intention to have a healthy relationship with technology in our home. We kept our bedroom free of any screens, charging our devices elsewhere overnight. But we missed our calendar and weather apps.

Initial prototypes

So I set out to build a solution to our problem. First, I constructed a Magic Mirror using an off-the-shelf medicine cabinet and LCD display with its frame removed. It showed the calendar and weather data we needed:

But it was hard to read the text, especially during the day as we get significant natural light in Colorado. At night, it glowed like any backlit display, sticking out sorely in our living space.

I then spent about a year experimenting with various jailbroken Kindle devices, eventually landing on design with calendar and weather data on a pair of screens. The Kindles took a few seconds to refresh and flash the screen to reset the ink pixels, so they only updated every half hour. I designed wood enclosures and laser-cut them at the local library makerspace:

Software-wise, I built a Ruby on Rails app for fetching the necessary data from Google Calendar and Dark Sky. The Kindles woke up on a schedule, loading a URL in the app that rendered a PNG using IMGKit. The prototype proved e-paper was the right solution: it was unobtrusive regardless of lighting:

A more reliable approach

The Kindles were a hack, requiring constant tinkering to keep them working. It was time for a more reliable solution. I tried an OLED screen to see if the lack of a global backlight would be less distracting, but it wasn’t much better than the Magic Mirror:

So it was back to e-paper. I found a system of displays from Visionect, which came in 6”/10”/13”/32” sizes and could update every ten minutes for 2-3 months on a single charge:

The 32” screen used an outdated lower-contrast panel and its resolution was too low to render text smoothly. The smaller sizes used a contrasty, high-PPI panel. I ended up using a combination of them around the house: a 6” in the mudroom for the weather, a 13” (with its built-in magnetic backing) in the kitchen attached to the side of the fridge, and a 10” in the bedroom.

The Visionect displays required running custom closed-source software, either as a SaaS or locally with Docker. I opted for a local installation on the Raspberry Pi already running the Rails backend. I had my best results pushing images to the Visionect displays every five minutes in a recurring background job. It used IMGKit to generate a PNG and send it to the Visionect API, logic I extracted into visionect-ruby. This setup proved to be incredibly reliable, without a single failure for months at a time.

First customer pilot

Visiting friends often asked how they could have a similar system in their home. Three years after the initial prototype, I did my first market test with a potential customer. At their request, I experimented with different formats, including a month view on the 13” screen:

Unfortunately, the customer didn’t see enough value to justify the $1000 price tag (in 2019!) for the 13” device, let alone anything I’d charge for a subscription service. At around the same time, Visionect started charging a $7/mo per-device fee to run their backend software on premises with Docker, after years of it being free to use. I’d have needed to charge $10/month, if not more, for a single screen!

An unexpected pivot

In late 2021, the Marshall Fire destroyed our home along with ~1,000 others. Our homeowner’s insurance gave us two years to rebuild, so we set off to redesign our home from the ground up.

Around the same time, Boox released the 25.3” Mira Pro, the first high-resolution option for large e-paper screens. Best of all, it could update in realtime! Unlike the Visionect devices, it was just a display with an HDMI port and needed to be plugged into power. A quick prototype powered by an old Mac Mini made it immediately obvious that it was a huge step forward in capability. The larger screen allowed for significantly more information to be displayed:

But the most compelling innovation was having the screen update in realtime. I added a clock, the current song playing on our Sonos system (using jishi/node-sonos-http-api) and the next-hour precipitation forecast from Dark Sky:

The working prototype was enough to convince me to build a place for it in the new house. We designed a “phone nook” on our main floor with an art light for the display:

We also ran power to two more locations for 13” Visionect displays, one in our bedroom and one by the door to our garage:

Backend overhaul

The real-time requirements of the Mira Pro immediately surfaced performance and complexity issues in the backend, prompting an almost complete rewrite.

While the Visionect system worked just fine with multiple-second response times, switching to long-polling every two seconds put a ceiling on how slow response times could be. To start, I moved away from generating images. The Visionect folks added the ability to render a URL directly in the backend, freeing up resources to serve the long-polling requests.

Most significantly, I started migrating towards Home Assistant (HA) as the primary data source. HA already had integrations for Google Calendar, Dark Sky (now Apple Weather), and Sonos, enabling me to remove over half of the code in the Timeframe codebase! I ended up landing a PR to Home Assistant to allow for the calendar behavior I needed, and will probably need to write a couple more before HA can be the sole data source.

With less data-fetching logic, I was able to remove both the database and Redis from the Rails application, a massive reduction in complexity. I now run the background tasks with Rufus Scheduler and save data fetching results with the Rails file store cache backend.

In addition to data retrieval, I’ve also worked to move as much of the application logic into Home Assistant. I now automatically display the status of any sensor that begins with sensor.timeframe, using a simple ICON,Label CSV format.

For example, the other day I wanted to have a reminder to start or schedule our dishwasher after 8pm if it wasn’t set to run. It took me about a minute to write a template sensor using the power level from the outlet:

{% if states('sensor.kitchen_dishwasher_switched_outlet_power')|float < 2 and now().hour > 19 %}
utensils,Run the dishwasher!
{% endif %}

In the month since adding the helper, it reminded me twice when I’d have otherwise forgotten. And I didn’t have to commit or deploy any code!

Today

Since moving into our new home, we’ve come to rely on the real-time functionality much more significantly. Effectively, we’ve turned the top-left corner of the displays into a status indicator for the house. For example, it shows what doors are open/unlocked:

Or whether the laundry is done:

It has a powerful function: if the status on the display is blank, the house is in a “healthy” state and does not need any attention. This approach of only showing what information is relevant in a given moment flies right in the face of how most smart homes approach communicating their status:

The single status indicator removes the need to scan an entire screen. This change in approach is possible because of one key difference: we have separated the control of our devices from the display of their status.

What’s next

I continue to receive significant interest in the project and remain focused on bringing it to market. A few key issues remain:

Hardening for deployment

While I have made significant progress in handling runtime errors gracefully, I have plenty to learn about creating embedded systems that do not need maintenance.

Home Assistant integration

There are still several data sources I fetch directly outside of Home Assistant. Once HA is the sole source of data, I’ll be able to have Timeframe be a Home Assistant App, making it significantly easier to distribute.

Hardware cost and complexity

The current hardware setup is not ready for adoption by the average consumer. The 25” Boox display is excellent but costs about $2000! It also doesn’t include the hardware needed to drive the display. There are a couple of potential options to consider, such as Android-powered devices from Boox and Philips or low-cost options from TRMNL.

Conclusion

Building Timeframe continues to be a passion of mine. While my day job has me building software for over a hundred million people, it’s refreshing to work on a project that improves my family’s daily life.